Netflixコードを書いたように

クラウドでの作業段階の前にNetflixのコードを正確に実装する方法は？ 前にこの話の一部を説明しましたが、今はさらに詳細を追加するときです。 この投稿では、ソースコードから、世界中の7,500万人以上の加入者が映画やテレビ番組を楽しむことができる包括的なサービスに移行できるツールと方法について説明します。







上の図は、グローバル連続データ転送プラットフォームであるSpinnakerを紹介した以前の投稿への参照です。 ただし、Spinnakerのコード行に入る前に、いくつかの手順を実行する必要があります。

• コードは、 Nebulaプラグインによってローカルで作成およびテストする必要があります。
• 変更は中央のgitリポジトリにプッシュされます。
• Jenkinsは、クラウド用のアプリケーションを作成、テスト、および準備するNebulaを起動します。
• ビルドはAmazon Machine Imageで「焼き付け」られます。
• Spinnakerは、変更されたコードのロック解除とアクティブ化に役立ちます。

この投稿の残りの部分では、これらの各段階で使用されるツールと方法について説明し、途中で遭遇した課題について説明します。

組織文化、クラウド、およびマイクロサービス

Netflixのコード作成プロセスを掘り下げる前に、組織の文化、クラウド、マイクロサービスなど、意思決定に影響を与える重要な要素を特定する必要があります。



Netflixの文化は、タスクの解決に適したツールを使用するという点で、エンジニアの能力を拡張します。 私たちの経験では、ソリューションが広く認識されるためには、ほとんどのNetflixエンジニアの推論、有用性、認知負荷を軽減する必要があります。 チームは問題を解決する方法を自由に選択できますが、これらの決定をサポートするために追加の責任を負います。 中央のNetflixチームからのオファーは、「舗装道路」の一部と見なされ始めています。 今、私たちの注目の的であり、私たちの専門家によってサポートされているのは彼女です。



さらに、2008年に、NetflixはデータストリーミングのAWSへの移行と、モノリシックJavaベースのデータセンターのクラウドベースのJavaマイクロサービスへの移行を開始しました 。 Netflixのアーキテクチャにより、Netflixチームは互いに強く結び付けられないため、お客様にとって都合の良いペースで問題の解決策を作成および推進できます。

開発

サービスやアプリケーションを展開する前に、最初に開発しなければならないことは誰も驚かないと思います。 開発中の主な問題に対処するために、 Gradle用のビルドシステムプラグインのセットであるNebulaを作成しました。 Gradleは、コードの基本的なニーズをカバーするため 、Javaアプリケーションを開発、テスト、およびデプロイするためのファーストクラスのツールです。 結果のファイルを減らしながら、テスト可能なプラグインを簡単に作成できるため、このツールが選択されました。 したがって、Nebulaは、Gradleの助けを借りて、関係、リリース、展開、および他の多くのツールを管理するための使用可能なプラグインのセットを使用して、信頼性の高い自動化機能を提供します。





シンプルなJavaアプリケーション。 Build.gradleファイル



上記のbuild.gradleファイルは、Netflixで通常のJavaアプリケーションを構築する例です。 このプロジェクトの本文には、Javaコマンドと4つのGradleプラグインがあり、そのうち3つはNebulaの一部であるか、プラグインに関連付けられた内部設定です。 'nebula'プラグインはGradleの一部であり、インフラストラクチャとの統合に必要な接続と設定を提供します。 プラグイン「nebula.dependency-lock」を使用すると、プロジェクトは変数の依存関係を構築するa.lockファイルを作成して、繰り返し実行することができます。 プラグイン「netflix.ospackage-tomcat」とospackageブロックについては以下で説明します。



Nebulaを使用して、各アプリケーションファイルのテンプレート速度を低下させることを目的に、再利用可能で互換性のあるビルド機能を提供しようとしています。 次の投稿では、Nebulaとそのさまざまな機能について詳しく説明します。コードは公開されています。 それまでの間、 NebulaのWebサイトにアクセスできます。

統合

Nebulaを使用してコードをローカルでテストした後、統合と展開に進むことができます。 最初に、必要に応じてチームが自由にワークフローを見つけることができるように、Gitリポジトリで更新されたソースコードを実行する必要があります。



変更を確認すると、Jenkins関数がトリガーされます。 Jenkinsを使用した継続的な統合は、長年にわたって進化してきました。 データセンターでは、1つの巨大なマスターJenkinsから始めましたが、その結果、AWSで25人のマスターJenkinsが使用されました。 Netflixでは、単純な継続的統合よりも複雑な多数の自動化タスクに使用されます。



Jenkinsのタスクは、Nebulaを呼び出してアプリケーションコードを作成、テスト、および準備することです。 リポジトリがライブラリになると、Nebulaは* .jarをリポジトリに公開します。 リポジトリがアプリケーションの場合、Nebulaはospackageプラグインを起動します。 ospackage（「オペレーティングシステムパッケージ」）プラグインは、作成されたアプリケーションのアーティファクトをDebianまたはRPMパッケージとして提示し、その内容は単純なGradleベースのDSLを使用して決定されます。 その後、NebulaはDebianファイルをパッケージリポジトリに公開し、次のステップであるベーキングに利用できるようにします。

「ベーキング」

注：「ベーキング」および「ベーカリー」とは、レシピ、シーケンス、必要な条件の遵守など、実際のベーキングプロセスとの類似性を意味します。 原作者はこの革命を本当に気に入っており、今後も頻繁に使用します。 残念ながら、これらの言葉に込められた意味からロシア語の類似語を見つけられませんでした。



私たちの展開戦略はサーバーパターンの不変性に焦点を合わせます 。 構成のドリフトの可能性を減らし、展開の繰り返しが同じソースから行われるようにするために、ファイルを手動で変更しないことを強くお勧めします。 Netflixでの各デプロイメントは、新しいAMI（ Amazon Machine Image ）の作成から始まります。 ソースから直接AMIファイルを作成するために、「Bakery」を作成しました



Bakeryは、AMIの作成を非常に簡単にするAPIを作成します。 次に、Bakery APIは、Animatorを使用して画像を作成する作業ノードのタスクを「スケジュール」します。 「ベイク」機能を呼び出すには、ユーザーは目的のパッケージのインストールと、このパッケージがインストールされるベースイメージをアナウンスする必要があります。 それ（基本AMI）は、Netflixエコシステムの大部分との完全な統合に必要な一般的な対流、サービス、およびツールで構成されたLinux環境を提供します。



Jenkinsが仕事の一部を正常に完了すると、彼は通常「 Spinnakerパイプライン 」を呼び出します。 これらは、JenkinsアクションまたはGitのコミットによってトリガーできます。 SpinnakerはNebulaによって生成されたオペレーティングシステムパッケージを読み取り、ベーカリーAPIを使用して開始します。

申込み

「ベーキング」の完了後、Spinnakerは、作成されたAMIを数十、数百、さらには数千のコピーに展開できます。 同じAMIは複数の環境で使用できますが、同時にSpinnakerは特定のインスタンスのランタイムを識別します。これにより、アプリケーションはランタイムをカスタマイズできます。 ベーキングが成功すると、Spinnakerパイプラインの次のフェーズであるテスト環境でのロールアウトが開始されます。



ここで、チームは自動化された統合テストの「バッテリー」全体を使用して展開を開始します。 この時点から、パイプラインの特異性により、展開プロセスは微調整の可能性がある人々に依存するようになります。 チームはSpinnakerを使用して、複数の展開領域、赤/黒の展開などを管理します。 Spinnakerパイプラインは、チームにコード開発を制御するための柔軟なツールを提供すると言うだけで十分です。

今後のパス

一般に、これらのツールは高レベルの生産性と自動化を提供します。 たとえば、クラウドの復元力とメンテナンスサービスであるJanitor Monkeyが登録ウィンドウから複数地域のスキャンに移行するのに16分しかかかりません。





Spinnakerは、Jenkinsによって呼び出されたパイプラインを焼いて展開します。



これは、開発者の経験を増やし、常に自分自身に挑戦する方法を模索していることを示唆しています。より良く、より速く、より簡単に。



Netflixでバイナリ依存関係をどのように扱うかについてよく聞かれます。 Nebulaは、Java依存関係緩和ツールを提供します。 たとえば、依存関係ロックプラグインを使用すると、アプリケーションがバイナリ依存関係のグラフィック全体を計算し、変数a.lockファイルを作成できます。 Nebulaの「 解決規則 」プラグインを使用すると、プロジェクトのすべての部分に影響する依存関係規則を作成できます。 これらのツールは、バイナリの依存関係の管理を容易にしますが、それでもパフォーマンスを許容レベルまで低下させることはできません。



また、ベーキング時間の短縮にも取り組んでいます。 少し前まで、16分間の展開は夢のように思えましたが、システムの他の部分の速度が向上したため、この夢は潜在的な障害になりました。 例として、Simian Armyの展開を考えてみましょう。ベイク処理には7分かかりました。これは、ベイク処理および展開プロセス全体の44％です。 ベイキングプロセスの（時間内の）リードは、パッケージのインストール（依存関係の解決を含む）とAWSコピープロセス自体であることがわかりました。



Netflixが成長し、成長するにつれて、仮想マシンなしでJavaScript / Node.js、Python、Ruby、Goのファーストクラスのサポートを提供する必要があるため、アセンブリおよび開発ツールの需要が増大します。 現在、これらの言語に対して、Nebula ospackageプラグインをお勧めします。これにより、その後の「焼き付け」のためにDebianパッケージを取得し、使用するプラットフォームのエンジニアとツールにアセンブリとテストを任せることができます。 これまでのところ、このソリューションは私たちに適していますが、特定の言語への依存を減らすためにツールを拡張しようとしています。



コンテナは、最後の2つの問題を解決する興味深い機会です。 現在、コンテナがアセンブリ、ベーキング、展開プロセスの改善にどのように役立つかを調査しています。 クラウド環境を正確に模倣するローカルコンテナ環境を作成できれば、開発およびテストサイクルに必要な「ベーキング」時間を短縮できるため、開発者の生産性が向上し、製品開発プロセス全体がスピードアップします。 「箱から出してすぐに」ローカルに展開できるコンテナは、認識負荷を軽減し、環境の違いによる間違いがないかどうかを確認するのではなく、エンジニアが問題やイノベーションの解決に集中できるようにします。