AWS上で実際に試してみたSpinnakerの実力は？
続いて溝内氏は、AWS上で実際に行った簡単な検証について、Spinnakerの画面の動きを見せながら説明した。
検証内容は「GitHubにコードをアップロードするだけで、デプロイまで動くのか？」「それにどのくらいの時間がかかるのか？」「Red/Black Deployの実際の（切り替え・切り戻し）動作は？」の3点。手順としては、現アプリケーションで表示される「Hello World01」を「Hello World02」に変更した新アプリケーションをGitHubにアップロードし、正常に本番環境までデプロイできたら1つ前の状態に切り戻す、というものだ。
まず、GitHubに新アプリケーションのプログラムをアップロードすると、Jenkinsが変更を検知してSpinnakerに通知する。通知を受けたSpinnakerは、ステージング環境でBake→Deployを実行。なお、ステージング環境へのデプロイはRed/Black Deployではなく、現アプリケーションのサーバグループへの上書きとなる。
Spinnakerの画面では、タスクバーでこれらの進捗状況を確認可能だ。例えばBakeが完了し、Deployを実行中なら、前者は緑、後者は青で表示される。また、Bakeで実際に動いているのはイメージ生成ツールのPackerであり、そのログが出力されるので、それを見てBakeの詳細な実行状況を確認することもできる。
ステージング環境に新アプリケーションのデプロイが完了した後、SpinnakerはSlackで管理者に通知する。管理者がパイプラインを次に進めることを承認すると、ステージング環境のBakeで作成したイメージを使って本番環境でDeployを実行。ここではRed/Black Deployを行うので、新規でサーバグループが作成される。本番環境へのデプロイ完了後は、ブラウザで実際に「Hello World02」が表示されることを確認する。
ここまでの検証結果としては、「GitHubにコードをアップロードするだけで、デプロイまで動いた」、そして「所要時間は約14分」だった。
切り戻しについては、Spinnakerの画面で［Roleback］を選択して、切り戻し先のサーバグループを指定すれば自動実行される。こちらは、ブラウザで「Hello World01」が表示されることで切り戻しできたことを確認する。実際に行われる処理は、大まかにいえばキャッシュのクリアとロードバランサの向き先変更くらいであり、検証結果としては「2～3クリックの簡単な操作で切り戻しできた（所要時間約1分）」とのこと。
なお、Spinnakerの画面に表示されるアイコンの色により、サーバグループの状態を確認することも可能だ。正常なら緑、異常な場合は赤、また、ロードバランサから切り離された無効な状態では半透明で表示される。例えば、切り戻しの完了は、元のアプリケーションのサーバグループが半透明から緑色に変わった（有効になった）ことで確認できる。
溝内氏は今回の検証を通じて感じたSpinnakerのメリットとして、1つの画面で状況を把握できるうえ、さまざまな操作が行えることを挙げた。
「タスクバーの状態でGitHubへのアップから本番環境にデプロイするまでの進捗状況を確認できるのは、運用者の視点からしてありがたいこと。AWSのマネジメントコンソールにログインする必要がなく、Spinnakerの画面からELBやセキュリティグループ、オートスケーリンググループ、AMIを作成できるのも便利。また、今回の検証ではそれぞれ2台のサーバグループしか使っていないが、数百台を対象とする場合などは、異常なインスタンスをひと目で判断できる色分け表示の機能も重宝する」
一方で、今後の改善を期待したい点もあるという。具体的には、GUI上でプルダウンから選択する際に項目が表示されない場合があるなど若干動作が不安定なことや、AWS特有の問題でサブネット名の命名規則が決まっていること、同じくAWS特有の問題としてSpinnaker上でセキュリティグループを作るときに送信元・送信先がIPアドレスを指定できないことなどを挙げた。
とはいえ、SpinnakerはOSSとしてまだ発展途上にあるツールだ。NetflixやGoogle、Microsoftといった有名企業の開発者を中心に、現在も鋭意開発・改善が進められており、今後さらに便利で使いやすい機能が実装されていくことが期待できる。
溝内氏は最後に「クラウド環境へのデプロイに悩んでいる方は、一度検討してみる価値はある」と語り、セッションを締めくくった。
お問い合わせ
株式会社エーピーコミュニケーションズ
- TEL：03-5297-8011（代表）
- コーポレートサイト
