独立したチームは、Indeed の開発において不可欠なものです。急成長をし続ける組織として、チーム間での依存性の数を減らすように努力しており、チームのデプロイのインフラを各チームに管理させています。こうすることで、開発の速度、品質、そして、アーキテクチャの大規模化などを得ることができます。
Apache Mesos は、運営上のボトルネックを削減し、そして各チームが各プロダクトへの裁量をさらに持つための手助けをしてくれます。
運営上のボトルネック
初期の Indeed は、人の手でアプリケーションのプロビジョニングと設定を行っていました。新しいアプリケーションができる度に、オペレーションチームにリクエストを送信し、この新しいアプリケーションが実行できるだけの容量があるサーバーを探して貰っていました。何も見つからなかった場合には、オペレーションチームは新しい仮想マシンを投入したり、追加サーバーを発注したりしていました。新規アプリケーションのプロビジョニングには、最長で 2 か月ほどかかっていました。
その後に続くデプロイはより短時間で済む、オペレーションチームから独立した作業でしたが、初めのプロビジョニングの行程が問題でした。このことから、開発者はアプリケーションデザインを代償にして開発速度を最適化するようになりました。時間のかかる新しいアプリケーション作成に着手するよりも、サービスをつなぎ合わせていく方が簡単だったので、アプリケーションは膨れ上がりモノリシックになっていきました。しかし、これでは大規模化できなかったため、何かを変える必要がありました。
Mesos の導入
3年ほど前に、Indeed は Mesos を利用し始めました。これにより、各チームには、担当アプリケーションの設定、デプロイ、そして監視する裁量が与えられました。現在は、アプリケーションが CPU、メモリ、ディスクをさらに必要とする場合には、担当チームがそれらを追加します。こうしたプロセスの利点は以下のようなことが挙げられます。
管理者が不要になる。これにより、開発速度があがり、スケーラブルなアーキテクチャとしての傾向が強化されました。
担当チームがアプリケーションのパファーマンスプロファイルを把握できる。各チームは、CPU、メモリ、ディクスの数などを指定する必要があるので、予想されるパフォーマンス、トラブルシューティング、そして改善できる部分について、熟知するようになりました。
信頼性が強化された。 サーバーが落ちた際に、アプリケーションは別の場所で再起動するので、エンジニアが個々のインスタンスを管理しなくて済むようになりました。
Indeed における Mesos のエコシステム
Mesos 単体では、確実にアプリケーションを実行できるわけではありません。私たちの Mesos のエコシステムは、多くのオープンソースプロジェクトと、チームがシームレスに開発出来るように作られた自社アプリケーションが統合されています。
デーモンのための Marathon
Indeed では、デーモンを実行するために Marathon を使用しています。ただし、ほとんどの開発者はこの事に気づいていません。Indeed は 10 か所のデータセンターで稼働していますが、 Marathon はそのうちの 1 か所でのみ実行されているため、全データセンター間のデプロイを調整する Marvin と呼ばれるシステムを作りました。開発者は独立して自身のリソース要件、実行するアプリケーションのバージョン、インスタンスの数、そして実行するデータセンターを指定します。そして、定義された設定と Marathon の設定を比較してくれるエージェントが各データセンター内で実行されます。もしそれらが一致しなければ、エージェントは直接 Marathon と連携し、インスタンスの大規模化・縮小化や、新しいデプロイを開始します。
バッチと単発ジョブ用の内製ツール
また、私たちは大量のバッチや、 ｢単発｣ のジョブを実行します。Marathon はこうしたユースケースには適していないため、Orc と言う Marathon と同様の Mesos のフレームワークを開発しました。これは、以前はオペレーションチームがタスクの担当をしていたような、上記のようなジョブを設定し予約するものです。このツールを開発したことで、最後にアクセスしたホストをできるだけ使うようにするなどの複数の最適化が出来るようになりました。これは Indeed の Resilient Artifact Distribution （RAD。障害発生時に回復機能を持つアーティファクトの分散）システムともうまく連携し、必要なデータの近くでジョブが実行されます。開発者はまた必要なタイミイングでジョブが実行されるように予約設定をすることが可能です。
Orcはバッチと単発ジョブの設定と実行予約を行うツールである。
ロードバランシングには HAProxy
Marathon が、異なるサーバー上や異なるポート上の新しいインスタンスを常に提示するので、これらインスタンスへのアクセスを簡単に行える方法が必要でした。その有名なパフォーマンスの特性から、 HAProxy をリバースプロキシとして使用しています。デーモンがどこで実行されているか検知し、一致する HAProxy の設定を生成する小さなアプリケーションを作りました。設定が変更されると、Runtime API を使用して、HAProxy の動的な更新を試みます。これが不可能な場合、パケットやリクエストが全く失われずに済むシームレスリロードのメカニズムを使用して、 HAProxy を再起動します。
設定には Vault
最後に、Indeed ではアプケーションを設定するのに堅牢な方法を必要としています。Indeed のほとんどのアプリケーションがシンプルでフラットなプロパティファイルで設定されています。Mesos 導入以前では、各データセンターにプロパティファイルを配布するために Puppet を使用していました。しかし、これは各チーム内で完結できない作業であり、タイムラグが数多く発生していました。速度を上げ、各チームが安全にそして担当アプリケーションを自分で設定するのを簡単にするために、機密情報を管理する HashiCorp 社のプロダクト、Vault に関連したシステムをデザインしました。アプリケーション実行の前に、プロパティを取得するための有効期限の短いトークンを生成します。Marvin のデーモンがこれを実行できるように小さな Marathon のプラグインを作り、また、Orc がバッチのジョブを処理できるように手を加えました。
結果: 独立したチームとスケール可能なアプリケーション
これらの変更はデプロイにかかる時間を 14% 削減しました。さらには、プロビジョニングに要する時間を数ヶ月から数分にまで削減し、開発チームが担当アプリケーションに、より責任を持てるようになりました。
設定とデプロイのチケットが急激に減少し、設定のチケットの解決までの平均時間が 15~6 日から 3~4 日にまで減少しました。結果として、オペレーションチームは、サイト信頼性のエンジニアリング技術を作成するためにリソースの割り当て直すなど、さらに急を要する案件などにフォーカスできるようになりました。
現在、私たちは Mesos 上での Docker のコンテナ型になったデプロイの実現にむけて取り組んでいます。開発者はいずれ、Docker イメージを自身で作動させ、脆弱性のスキャンを自動で行い、そして簡単にコンテナ型になったアプリケーションを自社のクラウド上でデプロイできるようになります。こうした進歩を目前に、Indeed では、エンジニアリングチームが独立してスケール可能なアプリケーションを開発できるように、引き続き新しい機能を Mesos 上で有効にしていきたいと思います。