Netflixの社員であるEd Bukoski氏、Brian Moyles氏、Mike McGarr氏の3人がブログで、同社が7500万人の視聴者に向けてテレビや映画を届けるために、どのようにコードをデリバリしているのかを説明している。
イミュータブルサーバパターンがNetflixの配置の基礎にある。各配置は新しいAmazon Machine Image(AMI)を使う。
Netflixのマイクロサービスアーキテクチャによって、チームは疎結合になっている。それぞれのチームにとって適したスピードで変更がプッシュされる。
Netflixではチームは使用するツールを指定されない。しかし、自分たちが実装したツールをメンテナンスする責任がある。中央のチームはNetflixの大多数のエンジニアの認知的負荷を軽減するために、“舗装道路”の一部としてツールを提供する。
“舗装道路”コードデリバリプロセスはいくつかのステップで成り立つ。まず、コードはローカルでNebulaを使ってビルド、テストされる。変更はGitにコミットされる。ひとつのJenkinsジョブでアプリケーションのビルド、テスト、パッケージ化が行われる。そして、Netflixのグローバルな継続的統合プラットフォームであるSpinnakerを使って、パッケージがAmazon Machine Images (AMI)に配置される。
ビルド
NebulaはJavaアプリケーションのビルド、テスト、パッケージをするGradleのプラグイン。NetflixのほとんどのコードはJavaで書かれている。依存の管理やパッケージングなどGradleの自動化機能をプラグインで拡張している。ひとつのプロジェクトのブルドファイルにはそのプロジェクトで使われる依存物とプラグインが宣言されている。
統合
次のステップではローカルでビルド、テスト、パッケージングされたコードをGitにプッシュする。具体的にワークフローはチームが選択する。
コミットすると、Jenkinsのジョブが動いて、ビルド、テスト、パッケージングが実行される。ライブラリがビルドされたか、アプリケーションがビルドされたかで、適切なパッケージタイプが選択される。
配置
Netflixの“Bakery”はAMIを作成するためのAPIを公開する。実際のイメージはAminatorで作成される。イメージとAMI内に配置するパッケージの元はユーザが指定できる。元となるイメージはLinuxで、Netflixのエコシステムに統合されるのに必要な汎用的な規約、ツール、サービスを搭載している。
Jenkinsの統合ジョブが成功すると、Spinnakerのパイプラインが動く。SpinnakerはNebulaのパッケージを読み込み、Bakery APIを使ってAMIを作成する。
SpinnakerはこのAMIをつかってたくさんのインスタンスを作ることができる。
最初の配置は、テスト環境だ。この環境では自動統合テストも行われる。テストに通過すると、Spinnakerはプロダクション環境への配置についてチームにカスタマイズの選択肢を定時する。マルチリージョン配置、カナリアリリース、レッド/ブラック配置などだ。
この方法だと、例えば、Janitor Monkeyなら、コードをチェックインしてからマルチリージョン配置が完了するまで、16分で終わるという。
今後の方向性
Netflixでは言語にとらわれないことが重要になりつつある。JVMではない言語でもビルドプロセスに統合する必要が出てきている。
また、配置時間の大部分は配置物の準備時間であり、この時間を削減しようとしている。
また、上のふたつの問題を解決するためコンテナ技術が使えないかどうかも検討している。
コンテナは現在のビルド、配置プロセスを改善する可能性し、配置、テストのサイクルがより良くなる可能性がある。ひとつのコンテナをローカルに配置し、変更せずにプロダクションに配置することで、環境差によるバグが発生するかどうかを判断できる。これによって開発者は新しい機能の開発に注力できる。