QConカンファレンス。 カオスをマスターする: マイクロサービスに関する Netflix ガイド。 パート 4

Josh Evans が、Netflix マイクロサービスの混沌とし​​たカラフルな世界について、マイクロサービスの構造、分散システムに関連する課題、その利点といった基本的なことから始めて語ります。 この基盤に基づいて、彼はマイクロサービスの習得につながる文化、アーキテクチャ、運用の実践を探求します。

QConカンファレンス。 カオスをマスターする: マイクロサービスに関する Netflix ガイド。 パート 1
QConカンファレンス。 カオスをマスターする: マイクロサービスに関する Netflix ガイド。 パート 2
QConカンファレンス。 カオスをマスターする: マイクロサービスに関する Netflix ガイド。 パート 3

運用上のドリフトとは異なり、サービスの国際化のための新しい言語やコンテナーなどの新しいテクノロジーの導入は、環境に新たな複雑さを加えるための意識的な決定です。 私の運用チームは、Java と EC2 に基づいた事前定義されたベスト プラクティスに組み込まれた Netflix の最適なテクノロジー ロードマップに基づいて標準化しましたが、ビジネスが成長するにつれて、開発者は Python、Ruby、Node-JS、Docker などの新しいコンポーネントを追加し始めました。

私たちは、お客様からの苦情を待たずに、当社の製品が優れた機能を発揮することを最初に提唱したことを非常に誇りに思っています。 すべては非常に単純に始まりました。私たちは Python で動作するプログラムと、Ruby でいくつかのバックオフィス アプリケーションを使用していました。しかし、Web 開発者が JVM を廃止して Web に移行すると発表したとき、事態はさらに面白くなりました。アプリケーションを Node ソフトウェア プラットフォーム.js に変換します。 Docker の導入後、状況はさらに複雑になりました。 私たちはロジックに従い、私たちが思いついたテクノロジーは、非常に理にかなったものであったため、顧客に実装したときに現実になりました。 なぜそうなるのか説明します。

実際、API Gateway には、UI 開発者のエンドポイントとして機能できる優れたスクリプトを統合する機能があります。 これらの各スクリプトは、変更を加えた後に本番環境にデプロイしてからユーザーのデバイスにデプロイできるように変換され、これらすべての変更は API ゲートウェイで実行されるエンドポイントと同期されました。

ただし、これにより、API サービスがコードで過負荷になり、さまざまな障害シナリオが発生する新しいモノリスを作成するという問題が繰り返し発生しました。 たとえば、一部のエンドポイントが削除されたか、スクリプトがランダムに生成した何かのバージョンが多すぎて、そのバージョンが API サービスの使用可能なメモリをすべて占有したとします。

これらのエンドポイントを取得して API サービスから引き出すのは論理的でした。 これを行うために、Docker コンテナーで小さなアプリケーションとして実行される Node.js コンポーネントを作成しました。 これにより、これらのノード アプリケーションによって引き起こされる問題やクラッシュを切り分けることができました。

これらの変更のコストは非常に大きく、次の要素で構成されます。

• 生産性向上ツール。 新しいテクノロジの管理には新しいツールが必要でした。これは、UI チームが非常に優れたスクリプトを使用して効率的なモデルを作成したため、インフラストラクチャの管理に多くの時間を費やす必要がなく、スクリプトを作成して機能をチェックするだけでよかったからです。
  機会の洞察と分類 - 重要な例は、パフォーマンスを促進する情報を明らかにするために必要な新しいツールです。 プロセッサがどれだけ占有されているか、メモリがどのように使用されているかを知る必要があり、この情報を収集するにはさまざまなツールが必要でした。
• 基本イメージの断片化 - シンプルな基本 AMI はより断片化され、特殊化されました。
• ノード管理。 クラウドでノードを管理できる既製のアーキテクチャやテクノロジーは存在しないため、スケーラブルで信頼性の高いコンテナのデプロイメントと Amazon AWS とのクラウド統合を提供するコンテナ管理プラットフォームである Titus を構築しました。
• ライブラリまたはプラットフォームの重複。 プラットフォームの同じコア機能を備えた新しいテクノロジーを提供するには、それをクラウドベースの Node.js 開発者ツールに複製する必要がありました。
• 学習曲線と業界での経験。 新しいテクノロジーの導入により、必然的に新しい課題が生じ、克服し、そこから学ばなければなりません。

したがって、私たちは XNUMX つの「舗装道路」に限定することはできず、技術を進歩させるための新しい方法を常に構築する必要がありました。 コストを抑えるために、一元的なサポートを制限し、JVM、新しいノード、Docker に重点を置きました。 私たちは効果的な影響を優先し、意思決定にかかるコストについてチームに通知し、すでに開発した影響力の高いソリューションを再利用する方法を探すよう奨励しました。 私たちは、製品を海外の顧客に提供するためにサービスを外国語に翻訳するときにこのアプローチを使用しました。 例には、自動的に生成できる比較的単純なクライアント ライブラリが含まれているため、Python バージョン、Ruby バージョン、Java バージョンなどを非常に簡単に作成できます。

私たちは、ある場所や他の同様の状況で実績のある実証済みのテクノロジーを使用する機会を常に探していました。

最後の要素、つまり変更またはバリエーションについて話しましょう。 製品の消費量が、曜日ごと、および 9 日を通して時間ごとにどのように不均一に変化するかを見てください。 システムの負荷が最大に達する午前 XNUMX 時は、Netflix にとって最も困難な時間帯であると言えます。

サービス提供を中断したり、顧客に不便を与えたりすることなく、ソフトウェア イノベーションの高速実装、つまりシステムに常に新しい変更を加えるにはどうすればよいでしょうか? Netflix は、新しいグローバルなクラウドベースの管理および継続的配信 (CD) プラットフォームである Spinnaker を使用することでこれを達成しました。

重要なことに、Spinnaker はベスト プラクティスを統合するように設計されているため、コンポーネントを本番環境に導入する際に、出力をメディア配信テクノロジーに直接統合できます。

私たちは、自動カナリア分析と段階的デプロイメントという、私たちが高く評価している XNUMX つのテクノロジーをデリバリー パイプラインに組み込むことができました。 カナリア分析とは、少量のトラフィックを新しいバージョンのコードに送り、残りの実稼働トラフィックを古いバージョンに渡すことを意味します。 次に、新しいコードがタスクにどのように対処するかを確認します (既存のコードよりも良いか悪いか)。

段階的ロールアウトとは、あるリージョンのロールアウトに問題がある場合、別のリージョンのロールアウトに移動することを意味します。 この場合、上記のチェックリストを本番パイプラインに含める必要があります。 時間を節約しますので、このトピックについてさらに詳しく知りたい場合は、私の前回の講演「クラウドでのグローバル Netflix 運用のエンジニアリング」を参照することをお勧めします。 スピーチのビデオ録画は、スライドの下部にあるリンクからご覧いただけます。

講演の最後に、Netflix の組織とアーキテクチャについて簡単に説明します。 当初は、NRDP 1.x メディア ストリーミングの最初のバージョンである、Electronic Delivery と呼ばれるスキームがありました。 ここで「バックストリーム」という用語が使用されるのは、最初はユーザーが後でデバイス上で再生するためにコンテンツをダウンロードすることしかできなかったためです。 2009 年当時、Netflix の最初のデジタル配信プラットフォームは次のようなものでした。

ユーザーデバイスには、NRDP プラットフォーム (Netflix Ready Device Platform) に基づいた、UI インターフェイス、セキュリティ モジュール、サービスのアクティブ化と再生で構成される Netflix アプリケーションが含まれていました。

当時のユーザーインターフェイスは非常にシンプルでした。 これには Queque Reader と呼ばれるものが含まれており、ユーザーはサイトにアクセスして Queque に何かを追加し、追加されたコンテンツを自分のデバイスで表示します。 良い点は、フロントエンド チームとバックエンド チームが同じ電子配信組織に属しており、緊密な協力関係があったことです。 ペイロードは XML に基づいて作成されました。 同時に、DVD ビジネス用の Netflix API が作成され、サードパーティのアプリケーションがトラフィックを当社のサービスに誘導するようになりました。

ただし、Netflix API は、すべてのコンテンツのメタデータや視聴可能な映画に関する情報を含む革新的なユーザー インターフェイスを提供するために十分に準備されており、視聴リストを生成する機能が作成されました。 これには、JSON スキーマに基づく汎用 REST API、最新のアーキテクチャで使用されているものと同じ HTTP 応答コード、および当時フロントエンド アプリケーションに必要であった OAuth セキュリティ モデルがありました。 これにより、ストリーミング コンテンツ配信のパブリック モデルからプライベート モデルへの移行が可能になりました。

移行の問題は断片化でした。これは、現在、私たちのシステムがまったく異なる動作原則に基づいて XNUMX つのサービスを運用しているためです。XNUMX つは Rest、JSON、OAuth に基づいており、もう XNUMX つは RPC、XML、および NTBA トークン システムに基づくユーザー セキュリティ メカニズムに基づいています。 これは最初のハイブリッド アーキテクチャでした。

当初は API が NCCP でうまく拡張できず、これがチーム間の摩擦につながったため、XNUMX つのチームの間には本質的にファイアウォールがありました。 違いはサービス、プロトコル、回路、セキュリティ モジュールにあり、開発者は完全に異なるコンテキスト間を切り替える必要があることがよくありました。

この点に関して、私は会社の上級エンジニアの XNUMX 人と会話し、「長期的に適切なアーキテクチャは何であるべきですか?」という質問をしたところ、彼は逆質問をしました。組織への影響について – これらを統合して、私たちがうまくやろうと学んだことが壊れたらどうなるでしょうか? このアプローチは、「システムを設計する組織は、その組織のコミュニケーション構造を再現する設計によって制約される」というコンウェイの法則に非常に関連しています。 これは非常に抽象的な定義なので、もっと具体的な定義を好みます。「ソフトウェアはすべて、それを作成した組織構造を反映します。」 私のお気に入りの Eric Raymond の言葉は次のとおりです。「XNUMX つの開発チームがコンパイラーに取り組んでいる場合、最終的には XNUMX パスのコンパイラーが完成します。」 そうですね、Netflix には XNUMX パス コンパイラがあり、それが私たちの仕事のやり方です。

この場合、犬は尻尾を振っていると言えます。 私たちの最優先事項はソリューションではなく組織であり、私たちのアーキテクチャを推進するのは組織です。 徐々に、寄せ集めのサービスから、ブレード ランナーと呼ばれるアーキテクチャに移行しました。ここでは、エッジ サービスと、Zuul プロキシ、API ゲートウェイ、および対応する機能に直接分離して統合できる NCCP の機能について話しているからです。 「ピース」は、より高度なセキュリティ、再生、データ並べ替えなどの機能を備えた新しいマイクロサービスに変わりました。

このように、部門構造と企業のダイナミクスは、システム設計を形成する上で重要な役割を果たしており、変化を促進または阻害する要因であると言えます。 マイクロサービス アーキテクチャは複雑かつ有機的であり、その健全性は規律と導入されたカオスに基づいています。

いくつかの広告

いつもご宿泊いただきありがとうございます。 私たちの記事が気に入っていますか? もっと興味深いコンテンツを見たいですか? 注文したり、友人に勧めたりして私たちをサポートしてください。 開発者向けのクラウド VPS は 4.99 ドルから, 当社があなたのために発明した、エントリーレベルのサーバーのユニークな類似物です。 VPS (KVM) E5-2697 v3 (6 コア) 10GB DDR4 480GB SSD 1Gbps 19 ドルからの真実、またはサーバーを共有する方法? (RAID1 および RAID10、最大 24 コア、最大 40GB DDR4 で利用可能)。

アムステルダムのエクイニクス Tier IV データセンターでは Dell R730xd が 2 倍安い? ここだけ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV 199 ドルから オランダで！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 ドルから! について読む インフラストラクチャー企業を構築する方法730 ペニーで 5 ユーロの価値がある Dell R2650xd E4-9000 vXNUMX サーバーを使用したクラスですか?

出所： habr.com