DSOC Infrastructure Group の 大澤 です。今月から Infrastructure Group というグループができたのですが、新名刺が間に合ってないので Eight 上は旧部署のままです･･･！
先日３月７日に Google Cloud 主催の INSIDE Digital というイベントに登壇させていただく機会がありました。
テーマが「ここでしか聞けない GCP 商用活用の第一歩」ということで、プロジェクト進行中の Windows サーバの VM 移行と、Spinnaker を活用した継続的デリバリー (Continuous Delivery; CD) について話をさせていただきました。
上の写真は会場の様子です。参加者が 200 〜 300 名の大規模イベントなのですが、満員ですね。登壇机がなく、カンファレンスのキーノートみたいなフリーハンドスタイルだったので発表中はかなり挙動不審だったと思います･･･
私のセッションの後は、アイリッジ様の大量の位置情報の収集・分析・可視化の事例や、LIFULL 様の Auto ML を活用した物件画像の自動タグ付けの発表がありました。私の発表した事例よりも他社様の事例紹介の方が GCP を十分に活用されて素晴らしい内容だったのでトップバッターで早々に終わらせられてほっとしています。
発表した内容の中で、懇親会や Twitter で反響が大きかったのが Spinnaker でした。発表時間内に説明しきれなかった部分も含めて本記事で Spinnaker を導入した理由や、どのように活用して CD を改善したのかについて紹介していきます。
Spinnaker とは
Spinnaker は OSS の継続的デリバリープラットフォームで主に３つの特徴が挙げられます。
マルチクラウド・マルチプロバイダー
Spinnaker の導入事例やスライドを見ると、 Kubernetes へのデプロイとして取り上げられることが多いのですが、AWS EC2 や Google Compute Engine (GCE) といった Compute Engine や Google App Engine も対応しています。また、Azure, Openstack, Oracle Cloud などのクラウド環境に対応しており、マルチクラウド時代にマッチした CD ツールだといえます。
ビルトインされたデプロイ戦略・機能
Red/Black (Blue/Green) Deployment, Canary Release といった、デプロイ戦略がビルトインで組み込まれています。ロールバックや手動承認をフロー(パイプライン)に組み込むことも可能です。例えば、開発環境のデプロイまでは自動ですすめておいて、チーム内の承認を得てから本番環境のデプロイに進むといったことができます。
パイプラインを実行するトリガーも充実しており、Jenkins, Travis CI, Werker, Webhook, GitHub など数多く揃っているのでチームで使っている開発ツールや CI サービスと連携することができます。
Immutable Infrastructure
Immutable Infrastructure とは、一度構築されたサーバに対して二度と手を加えないという思想です。
Spinnaker は Hashicorp Packer や Docker Registry によってイメージを作成 (Bake) したのち、 Red/Black Deployment によって、新しいイメージから生成されたインスタンスもしくはDockerコンテナに置き換えていくため、 Immutable Infrastructure の思想に則っています。
Spinnaker を採用した理由
今回の事例で Windows Server on GCP へのデプロイに Spinnaker を採用したのは以下の４つの理由からです。
GCPとの相性の良さ
Spinnaker はもともと Netflix 社で開発されていたものが、2014 年に Google 社と共同開発となり、2015 年 11 月にオープンソース化されました。Spinnaker に触れてみると所々で GCP との相性の良さが出ていることが分かります。
Compute Engine のデプロイに対応している
今回の事例では Windows Server を GCE で稼働していますが、将来的にはコンテナ化も視野に入れています。Spinnaker であれば Compute Engine からコンテナに移行したとしても設定を変えるだけで済みます。また、私達のシステムでは Windows Server 以外にも Ubuntu Server など Linux も使っており、Linux / Windows 関係なく使えるツールとして Spinnaker は最適だと思います。
Red/Black Deployment
Red/Black Deployment の良さは、既存のサーバやコンテナに変更を加えることなくデプロイができ、問題が生じた場合はすぐにロールバックが可能な点です。元のサーバやコンテナに手を加えていないため、安全にロールバックできます。
Canary Release
Canary Release (カナリーリリース) とは、すべてのサーバやコンテナをデプロイするのではなく、まず一部だけをデプロイし、少しずつ段階的に広げていく手法です。一部だけをリリースすることで、より高速なロールバックと問題が生じた際の被害を最小限におさえることができます。
私達が取り扱っている名刺には、とても特徴的な(データ化しづらい)名刺も含まれます。開発はダミー名刺を用いますが、実データで正しい挙動になるかわからないことも多く、実際に本番にデプロイしてみて傾向を掴むことがしばしばあります。Canary Release を利用することで、一部のリリースを含めたデプロイフローを容易に実現できます。
デプロイフロー
Spinnaker を組み合わせたデプロイフローは以下の図になっています。
開発者は GitHub の Pull Request (=機能)単位でデプロイを行います。Pull Request のコメントに「Deploy」と入力すると、連携している Jenkins のジョブが実行され、テストが通るとビルド成果物が Google Cloud Storege (GCS) にアップロードされます。GCS にアップロードされたイベントが発火され Cloud Pub/Sub トリガーで Spinnaker のパイプラインが実行されます。パイプラインの過程で手動承認や Slack への通知が行われます。
CI 部分(GitHub → Jenkins → GCS) は元々あった CI フローをそのまま活用しています *1 。GCS + Cloud Pub/Sub トリガーにすることで、CI と CD を疎結合できる、GCS に再アップロードすることでパイプラインの手動実行ができることを狙っています。
Spinnaker のパイプライン (一部理想形あり)
Spinnaker のパイプランは以下の図になっています。ただし、Canary Release についてはまだ設計・設定の途中であり、詳しくお伝えすることができません。
「Create Image」ステージは Packer で GCE イメージを生成します。 Packer は予め作成したテンプレートファイルに沿って実行されイメージを作成します。イメージを生成する過程で、GCESysprep や PowerShell スクリプトで GCS にアップロードされたビルド成果物を Windows サーバに配置するといった処理をしています。
Spinnaker で使える、Windows Servrer on GCE 用の共通 Packer テンプレートを GitHub に公開しています。
「Canary Deploy」ステージで、Canary Release をします。先ほど申し上げたようにまだ設計・設定の途中であり、詳しくお伝えすることができません。運用に乗るようになりましたら当ブログでアップデートをお伝えする予定です。
「Wait for Manual Approval」ステージは、手動承認です。Canary Release を経て、一部のサーバがリリースされた状態で、検証などを行っていきます。 Canary Release の自動評価 を採用していないのは、先ほど申し上げた、実際の名刺データを用いた実行結果を見る必要があるため、フローを一時的にとめておく必要があるからです。
検証が問題ないことが確認できたら「Deploy to Prod」ステージで Red/Black Deployment で残り台数分をデプロイしていきます。
デプロイ完了後は不要になったサーバグループ（インスタンスグループ）を削除して完了となります。
Spinnaker を使ってみて
Spinnaker を採用してみて良い点と改善してほしい点がいくつかでてきました。
良い点
- パイプラインの組み立てが直感的である。画面ポチポチなので開発者自身で組み立てることが可能（要学習コスト）
- Red/Black の切り替えやロールバックまで Spinnaker が担ってくれるため、自分で制御しなくても済むのは楽
改善してほしい点
- ドキュメントが少ない。Spinnaker の開発スピードが早いこともあるが、ドキュメントに載っている GUI が古かったり、そのまま設定しても動かない場合がある。ログとGitHub Issue を活用して原因調査にあたることもしばしばある
- Spinnaker 自体がマイクロサービスで動いており、どこかの機能が動かない場合はどのサービスが原因なのかちょっと分かりづらい。ログとポート番号からサービスを突き止めることが多い
- Terraform との相性が悪い。Spinnaker でインスタンスグループごとつくりかえて入れ替えるため、 Terraform でインスタンスグループまで管理していると不整合を起こす
- GCP でマネージドサービスを出してほしい！（Google さん何卒！）
まとめ
イベント登壇についてと Spinnaker を活用した CD の改善ついて書かせていただきました。Spinnaker はまだ発展途上ですが、とても可能性を秘めたツールなのでどんどん活用していきたいと思います。
最後に宣伝になりますが、 CloudNative Days Tokyo 2019 で 「Spinnakerで実現する、クラウド開発者のためのデプロイパターン入門」というタイトルで CFP を出しました。もっと汎用的に Spinnaker でできること・デプロイパターンを紹介できればと思います。もし聞きたい！という人がいましたら、下記のツイートをリツイートもしくはいいね！をしてもらえると嬉しいです。
twitter.com#CNDT2019 @ohsawa0515 による「Spinnakerで実現する、クラウド開発者のためのデプロイパターン入門」を受け付けました。このプロポーザルを聞いてみたい人はいいねやリツイートでぜひ応援してください！ 公募セッション一覧はこちら #cloudnativehttps://t.co/IhZFbNrGI3
— CloudNativeDays (@cloudnativedays) 2019年3月1日
*1:元々 Amazon S3 にアップロードしていたのを GCS に変更してもらっただけです
