Netflix でのマイクロサービスの導入: 建築デザインのためのレッスン

最近のブログ投稿では、アプリケーションがマイクロサービスのセットとして開発およびデプロイされる4 層アプリケーション アーキテクチャを採用することが重要であると考える理由について説明しました。 10 年前に問題なく機能していた開発プロセスとアプリケーション アーキテクチャを使い続けると、増え続けるアプリの中から選択できるモバイル ユーザーの関心を捉えて維持するのに十分なスピードで対応できないことが、ますます明らかになっています。

マイクロサービス アーキテクチャに切り替えると、企業にとって市場で刺激的なチャンスが生まれます。 システム アーキテクトと開発者にとっては、革新的な新しい Web エクスペリエンスを顧客に提供する際に、これまでにないレベルの制御と速度が実現します。 しかし、息切れするようなペースでは、ミスを許す余地がほとんどないように感じられるかもしれません。 現実の世界では、プロセスを再構築しながらアプリの開発と展開を停止することはできません。 将来の成功はマイクロサービス アーキテクチャへの移行にかかっていることはご存知でしょうが、実際にどのように移行するのでしょうか?

幸いなことに、マイクロサービスの早期導入者数名が、公開されたコードだけでなく、カンファレンスのプレゼンテーションやブログ投稿の形で、オープンソースの精神に基づき、専門知識を惜しみなく共有してくれています。 Netflix がその代表例です。 Web エンジニアリング ディレクター、その後クラウド アーキテクトとなった Adrian Cockcroft 氏は、100 人のエンジニアがモノリシックな DVD レンタル アプリケーションを作成する従来の開発モデルから、多数の小規模チームが連携して何百ものマイクロサービスのエンドツーエンドの開発を担当し、毎日何百万人もの Netflix 顧客にデジタル エンターテイメントをストリーミングするマイクロサービス アーキテクチャへの移行を監督しました。 現在、Battery Ventures のテクノロジー フェローであるCockcroft 氏は、マイクロサービスとクラウド ネイティブ アーキテクチャの著名な伝道者であり、NGINX 技術諮問委員会のメンバーでもあります。

2 部構成のブログ投稿シリーズでは、昨年 10 月に開催された第 1 回 NGINX カンファレンスと、その数か月前に開催された Silicon Valley Microservices Meetup で Cockcroft が行った 2 つの講演から、特に印象に残った点を紹介します。 （完全なビデオ録画も見る価値があります。）

• この投稿では、マイクロサービス アーキテクチャを定義し、それを設計するためのベスト プラクティスをいくつか概説します。
• Netflix でのマイクロサービスの導入: チームとプロセス設計の教訓では、ソフトウェア開発に新しい考え方を採用し、それに基づいてチームを再編成する理由と方法について説明します。

マイクロサービス アーキテクチャとは何ですか?

コッククロフトは、マイクロサービス アーキテクチャを、境界付けられたコンテキストを持つ疎結合要素で構成されたサービス指向アーキテクチャとして定義しています。

疎結合とは、サービスを個別に更新できることを意味します。つまり、1 つのサービスを更新しても、他のサービスを変更する必要はありません。 多数の小規模で特殊なサービスがあり、それらをまとめて更新する必要がある場合、それらは疎結合ではないためマイクロサービスではありません。 マイクロサービス アーキテクチャに移行するときに見落とされがちな結合の 1 つに、データベース結合があります。データベース結合では、すべてのサービスが同じデータベースと通信し、サービスを更新するとスキーマが変更されます。 データベースを分割して非正規化する必要があります。

境界付けられたコンテキストの概念は、Eric Evans の著書「Domain Driven Design」に由来しています。 適切に境界付けられたコンテキストを持つマイクロサービスは、ソフトウェア開発の目的で自己完結的です。 マイクロサービスとそのピアは API を通じて厳密に対話し、データ構造、データベース スキーマ、またはオブジェクトのその他の内部表現を共有しないため、ピアの内部について何も知らなくてもマイクロサービスのコードを理解し、更新できます。

インターネット用のアプリケーションを開発したことがあるなら、名前は知らなくても実践的にはこれらの概念にすでに精通しているはずです。 ほとんどのモバイル アプリは、ユーザーが Facebook で共有したり、Google マップから道順を取得したり、Foursquare でレストランを検索したりといった操作をアプリのコンテキスト内で実行できるように、多数のバックエンド サービスと通信します。モバイル アプリがこれらのサービスと密接に結合されている場合、更新をリリースする前に、すべての開発チームと話し合い、変更によって何も壊れないことを確認する必要があります。

マイクロサービス アーキテクチャで作業する場合、インターネット バックエンドのような他の社内開発チームを、マイクロサービスが API を通じて対話する外部サービスとして考えます。 マイクロサービス間で一般的に理解されている「契約」は、API が安定しており、前方互換性があるということです。 Google Maps API が予告なしに変更され、ユーザーに支障をきたすようなことは許されないのと同様に、API は進化しても以前のバージョンとの互換性を維持する必要があります。

マイクロサービス アーキテクチャ設計のベスト プラクティス

コッククロフト氏は、Netflix のクラウド アーキテクトとしての自身の役割を、アーキテクチャを制御することではなく、Netflix のエンジニアが構築する中で生まれたアーキテクチャを発見し、形式化することであると説明しています。 Netflix 開発チームは、マイクロサービス アーキテクチャの設計と実装に関するいくつかのベスト プラクティスを確立しました。

マイクロサービスごとに個別のデータストアを作成する

マイクロサービス間で同じバックエンド データ ストアを使用しないでください。 各マイクロサービスのチームがサービスに最適なデータベースを選択できるようにする必要があります。 さらに、単一のデータ ストアでは、おそらく作業の重複を減らすという名目で、異なるチームによって作成されたマイクロサービスがデータベース構造を共有することが非常に簡単になります。 あるチームがデータベース構造を更新すると、その構造を使用する他のサービスも変更しなければならないという状況に陥ります。

データを分割すると、個別のストレージ システムが同期しなくなったり、不整合が発生したりしやすくなり、外部キーが予期せず変更される可能性があるため、データ管理がより複雑になる可能性があります。 不整合を検出して修正するには、バックグラウンドで動作してマスター データ管理(MDM) を実行するツールを追加する必要があります。 たとえば、加入者 ID を格納するすべてのデータベースを調べて、すべてのデータベースに同じ ID が存在すること (どのデータベースにも欠落した ID や余分な ID がないこと) を確認します。 独自のツールを作成することも、購入することもできます。 多くの商用リレーショナル データベース管理システム (RDBMS) はこのようなチェックを実行しますが、通常は結合に関する要件が多すぎるため、拡張できません。

コードを同様の成熟度レベルに保つ

マイクロサービス内のすべてのコードを同様の成熟度と安定性のレベルに保ちます。 つまり、正常に動作しているデプロイ済みのマイクロサービスにコードを追加または書き直す必要がある場合、通常、既存のマイクロサービスはそのままにして、新しいコードまたは変更されたコード用に新しいマイクロサービスを作成することが最善のアプローチです。[編集者注: これは、不変インフラストラクチャの原則と呼ばれることもあります。]この方法により、既存のマイクロサービスで障害やパフォーマンスの低下が発生するリスクを冒すことなく、バグがなくなり、効率が最大限になるまで、新しいコードを繰り返しデプロイしてテストできます。 新しいマイクロサービスが元のマイクロサービスと同じくらい安定したら、実際に一緒に 1 つの機能を実行する場合、または組み合わせることによって他の効率性が得られる場合は、それらを再び結合できます。 しかし、コッククロフトの経験では、マイクロサービスが大きくなりすぎたために分割する必要があることに気づくことのほうがはるかに多いです。

マイクロサービスごとに個別のビルドを行う

各マイクロサービスごとに個別のビルドを実行し、適切なリビジョン レベルでリポジトリからコンポーネント ファイルを取得できるようにします。 これにより、さまざまなマイクロサービスが同様のファイルセットを異なるリビジョン レベルでプルする状況が発生することがあります。 これにより、古いファイル バージョンを廃止してコードベースをクリーンアップすることが難しくなる可能性があります (リビジョンが使用されなくなったことをより慎重に検証する必要があるため)。ただし、新しいマイクロサービスを構築するときに新しいファイルを追加するのが簡単になることを考えると、これは許容できるトレードオフです。 この非対称性は意図的なものであり、新しいマイクロサービス、ファイル、または関数の導入は危険ではなく、簡単に行うことが望まれます。

コンテナにデプロイ

コンテナにマイクロサービスをデプロイすることは重要です。それは、すべてをデプロイするのに 1 つのツールだけが必要になるからです。 マイクロサービスがコンテナ内にある限り、ツールはそれをデプロイする方法を認識します。 容器が何であるかは問題ではありません。 そうは言っても、Docker は急速にコンテナの事実上の標準になったようです。

サーバーをステートレスとして扱う

サーバー、特に顧客向けコードを実行するサーバーを、グループの交換可能なメンバーとして扱います。 これらはすべて同じ機能を実行するため、個別に考慮する必要はありません。 唯一の懸念は、必要な量の作業を生成するのに十分な数があるかどうかであり、自動スケーリングを使用して数を上下に調整できます。 1 つが動作しなくなった場合は、自動的に別のものに置き換えられます。 特殊な機能を実行するために個々のサーバーに依存する「スノーフレーク」システムは避けてください。

コッククロフト氏の例えによれば、サーバーをペットではなく牛のように考えるべきとのことです。 特殊な機能を実行する生産ラインのマシンがあり、そのマシンの名前を知っていて、そのマシンが故障するとみんなが悲しむなら、それはペットです。 代わりに、サーバーを牛の群れのように考える必要があります。 あなたが気にするのは、何ガロンの牛乳が手に入るかということです。 ある日、牛乳の生産量がいつもより少ないことに気づいたら、どの牛の生産量が少ないのかを調べて、新しい牛と交換します。

Netflix 配信アーキテクチャは NGINX 上に構築されています

Netflix は長年にわたり NGINX Open Source を利用しており、2011 年に NGINX, Inc. が設立されてから最初の顧客となりました。 実際、Netflix は世界最大級のコンテンツ配信ネットワーク (CDN) の 1 つであるOpen Connect の配信インフラストラクチャの中核としてNGINX を選択しました。 NGINX と NGINX Plus は、1 秒あたり数千、場合によっては数百万のリクエストを処理できるため、高パフォーマンスの HTTP 配信に最適なソリューションであり、Netflix などの企業が毎日数百万の顧客に高品質のデジタル エクスペリエンスを提供できるようになります。

ビデオ録画

迅速な配達
nginx.conf 2014、2014 年 10 月

マイクロサービスへの移行、パート 1
シリコンバレーマイクロサービスミートアップ、2014年8月

マイクロサービスへの移行、パート 2
シリコンバレーマイクロサービスミートアップ、2014年8月