Instagramでの継続的配置

Instagramは同社のコードを素早くプロダクションに発行したり、悪いコミットを特定したり、常にリリースできる状態にしておくための継続的配置(CD)パイプラインについての記事を公開した。このパイプラインの背後にはる原則は、高品質なテストスイート、悪いコミットの素早い特定、関係者からの支援をより得るための各ステージの見える化、そしてロールバックプランだ。

このシステムがなかったときは、同社のリリースプロセスは手動の複雑なステップとスクリプトでできていた。配置は最初はひとつのマシンに対して行われ問題ないかどうかを検証していた。そして、ひとつの画面とひとつのデータベースでできているSauronというリリースを追跡する原始的なアプリケーションでリリースの結果を確認する。リリースのスクリプトはFabricで作られていた。

Facebookが2013年にInstagramを買収し、AWSからFacebookの自前のデータセンターへインフラを移行を行った。Facebookのプロダクションエンジニアであり、今回の記事の筆者であるMichael Gorven氏によれば、Instagramは数千台のマシンを使っているが、1日に30回から50回の配置を行っている。氏によれば、大規模なインフラと将来の成長は配置に影響を与えない。Facebookの分散SSHシステムでリリースを行っているからだ。

当初の継続的配置のふたつの障害は脆いテストスイートと巨大なコミットのバックログだ。信頼できない遅いテストと複数の配置の失敗によって生まれた障害だ。そして、配置の失敗はインフラが拡張すればするほど増えた。テストスイートを最適化しカナリア用の環境を用意する必要があった。カナリア配置はサーバー群の一部に配置を行いテストし、結果によって、配置をロールバックするか全台に展開するかを決める配置手法だ。

Instagramはこのシステムを改良しどのコミットをプロダクションに配置するかを決めれるようにした。また、Jenkinsと統合してテストの結果によってコミットを分類の良い、悪い、に分類するようにした。この分類の結果をSauronへ渡すようにした。Sauronは関係者へ情報を見せるためのツールとして動いている。

Sauronの画面は、コミットとリリースの情報を見せます。リリースはチャットで告知され、配置される新しいコミットの作者をメンションします。作者はメールとSMSでも通知を受けるので、変更がリリースされることを検知できます。また、これらの情報はオペレーションイベントデータベース(Graphiteのイベントの仕組みに似た)に記録され、グラフにオーバーレイできるようになっている。

CDのパイプラインでは、データベースのマイングレーションが難しい。解決策はふつう、プロダクトやインフラごとに異なる。Instagramも同様に独自のシステムを持っている。新しいロケーションにデータベースを移行するための基本的な原則は単一のシャード(しかし稼働はしている)をコピーし、デルタが小さくなるまでコピーを繰り返す。そして、シャードを無効化し、最後のコピーをしてから新しいロケーションでシャードを有効にする。

スキーマの変更はフィーチャートグルによって行われている。Gorven氏によれば、

古いバージョンのスキーマでも新しいバージョンのスキーマでも読み書きができるコードを配置します。そして、データベースの変更(列の追加など)をして、新しいスキーマへの書き込みを有効にします。可能な場合は段階的に行います。必要であれば、既存のデータのアップデート処理を実行します。最後に古いスキーマではなく新しいスキーマの読み取りを有効にします。これも可能であれば段階的にします。古いスキーマへの書き込みは維持します。問題があったときのためです。

Instagramのリリースエンジニアリングチームの次の注力は、悪いコミットの検知とリリーススピードの維持だ。