Buzzfeedのデプロイアーキテクチャの進化

Buzzfeedのエンジニアリングチームが、数日かかる一枚岩のアプリのデプロイから1日に150回もデプロイするようになるまでの進化の物語を共有した。彼らはrigと呼ばれる内製のフレームワークを使って、Docker、AWS ECS、Jenkinsのようなツールを活用し、サービス志向のアーキテクチャとより協力的なエンジニアリングチームに移行した。

多くのエンジニアリングチームが自分たちのアーキテクチャやデプロイ、DevOps文化についての話を共有している。メディアとテクノロジーのサイトであるBuzzfeedもその一員だ。Buzzfeedは、小さな一枚岩のアプリケーションからスタートして徐々に機能とユーザーを増やし、サイズもリリースのスコープも並列的に成長してきた。デプロイのプロセスは製品が拡大するに連れて難しくなり、さまざまな要求が生まれた。そして、デプロイ作業に数日がかかるようになってしまった。

インフラチーム内の数人がコンテナを使って改善をするという、内部的なPaaSプロジェクトを始めた。InfoQは同社のエンジニアリング部門のバイスプレジデントであるMatt Reiferson氏にこの転換点について話を聞いた。

構成管理システムと関連するツールを整理し改善することについてたくさんの議論を重ねました。最終的には既存のワークフローに対して大きな改善にはならないという結論になりました。私たちの仮説は、Puppet、Chef、Ansibleのようなツールからどれかを選択する、というよりは、ユーザーがそのようなツールとやりとりすること自体を無くすべきだ、というものでした。私たちには、チームが自分たちが取り組むべき課題に注力し、素早く繰り返すことができるようにする、高いレベルの抽象が欠けていたのでした。コンテナは自然な答えでした。コンテナによって"構成管理"は劇的に単純になり、統一された"サービス"の抽象を提供します。そして、私たちは、コンテナの構成管理には開発と構成の一貫した体験を提供するための糊が必要だということに気づきました。

このようなツールセットと共に、チームはサービス志向アーキテクチャ(SOA)モデルをアプリケーションに導入することにした。SOAへの移行には技術的、そして、文化的な困難が伴う。達成するためには、チームは動機付けられ、組織的な成熟が必要だ。氏はこの点についてのBuzzfeedの経験を次のように説明する。
 

私たちはSpotifyのモデルをベースにした組織構造を採用していました。つまり、ミッションに駆動された"グループ"に別れ、それぞれのグループは"分隊"で構成されます。分隊は目的を達成するために適切なスキルセットを持つ人員で構成されます。これによってインフラ投資の必要性が強調されました。Rigは、私たちが探していた、チームと個人が持つべき振る舞いを具体化し促進させてくれました。デプロイのワークフロー、運用のオーナーシップ、監視と一貫性についてです。"The BuzzFeed Guide To Computers"という内部向けの資料を作り、技術選択、ワークフロー、フロントエンド/バックエンド/モバイルアーキテクチャについて書きました。もっとも重要なのは、これらのドキュメントで、私たちが考えるトレードオフについて深く掘り下げたことです。これによって新しいシステムを作る時に良い選択をするための文脈を提供できました。また、チームが活用できるテンプレートと共に、アーキテクチャレビュー評議会を作りました。

Rigはオープンソースプロジェクトであるpaastaの影響を受けている。それぞれのサービスの要件はYAMLファイルで定義され、コンテナイメージの作成にはDockerfileが使われる。設計者はいくつかの規約を導入する。例えば、Twelve Factorの原則のようなものや、ローカルに状態を持たないこと、HTTPベースのサービスのヘルスチェックエンドポイントなどだ。インフラストラクチャレイヤはVMベースで、Webインターフェイスから展開され、プロビジョニングのためにTerraformを導入した。また、AmazonのElastic Container Service (ECS)を使ってコンテナの管理をし、DNSや負荷分散にもAWSのサービスを利用した。

旧システムで改善すべき点の中で、開発とデプロイのパイプラインを簡単にし、アプリのインターフェースを標準化し、全てのチームのデプロイ後のエンゲージメントを高めることが主眼だった。より良い協力とサイトの信頼性向上が目的だ。開発にも品質保証にも運用にも適切なツールセットが必要だ。特に見える化を強化する必要がある。Buzzfeedのチームにとってはツールと作る場合、監視ができることが重要な原則になっている。"システムとアプリケーションの分散ロギング、計測、モニタリングがそのままでできること"が重要だ。

Buzzfeedはメトリクスの収集にDatadogとNagiosベースのモニタリングツールを使う。NagiosはPagerDutyと統合され、Nagiosでは致命的でアクション可能なアラートを上げるようにしている。"アラートはそれぞれのサービスの構成で設定した、チームのSlackチャンネルにも通知されます。"と氏は言う。NagiosとDatadogの統合は効果的なエスカレーションポリシーを持つためにはより明確に定義する必要がある。この点はBuzzfeedもまだ模索中だ。

コードのコミットから始まる典型的なデプロイメントパイプラインは、Jenkinsベースのビルドサービスをで行われる。このサービスでは、コンテナイメージの構築もし、テストを実行する。テストが成功すると、イメージはコンテナレジストリに登録される。

チームが概念実証からプロダクションレベルのツールに移行するに従い、Dockerの運用能力が欠けているなどの課題にぶつかった。(その当時)AWS ECSは新しいサービスだった。しかし、ECSはAWSの実績のあるインフラストラクチャ要素の上に乗っていたため、コンテナのスケジューリングに関するトラブルに巻き込まれずに済み、コンテナの中で実行されるソフトウェアに注力できた。

移行は段階的に行われ、低リスクで小さなワークロードのシステムが最初に移行された。rigが稼働し始めてから、日に150回ものデプロイがされている。サービスの一貫性、実験コストの低減、オーナーシップの改善など文化的にも変化が起きた。

画像の引用元: https://tech.buzzfeed.com/deploy-with-haste-the-story-of-rig-ca9a58b5719a