Google Cloud
ゲスト投稿 : Spinnaker のマネージド パイプライン テンプレートと IaC で、本番システムに秩序をもたらした Waze
2017年9月26日
Google Cloud Japan Team
「抽象的な観点から言えば、デプロイメント パイプラインとは、ソフトウェアをバージョン管理の段階からユーザーの手に渡すまでのプロセスを自動的に表現したものです」 ― Jez Humble 氏の著書『Continuous Delivery : Reliable Software Releases through Build, Test, and Deployment Automation』（継続的デリバリ : ビルド、テスト、デプロイの自動化で実現する信頼性の高いソフトウェア リリース）より
とはいえ、デプロイメント パイプラインを実装する際に、組織に 100 以上のマイクロサービスが存在し（しかも増え続けています）、そのサービスをそれぞれ環境の数、リージョンの数、クラウド プロバイダーの数ごとに対応させるとなると、問題が発生することもあります。
- 数百ものクラスタやデプロイメント パイプラインの管理には大きな負荷がかかります。デプロイメント パイプラインの数が数百に及ぶと、それぞれを最新の状態に保ったり、すべてを大きく変更したりすることは、決して小さな作業ではなくなってしまいます。
- パイプライン間でコードが再利用されることはありません。その多くがおそらく同じであるにもかかわらず、再利用されないのです。たとえば、一部のパラメータを除き、ベイク ステージやデプロイ ステージ、さらにリサイズ / クローン / 破棄の各ステージは、すべて同じコードとなる傾向があります。
- デプロイメントに向けた道筋を整えるということは簡単ではありません。各開発チームがデプロイメント戦略を立てる必要があるのですが、それでも道の整備は重要です。大半のチームが活用できるような道を整えることで、時間と労力が削減できるのです。まずは道の整備から始め、必要に応じて変更してください。ただし、道筋を整え、システム内の関連パイプラインすべてに対応できるよう長期にわたってメンテナンスするのは容易なことではありません。
クラウド ベンダー固有のソリューションとは異なり、Spinnaker のマネージド パイプライン テンプレートは、サポートされているすべてのプロバイダーの上で稼働します（現在サポートされているのは、Azure、GCP、AWS、Kubernetes、OpenStack、App Engine で、今後も拡張される予定です）。
つまり、複数のパブリック クラウドやローカルでのオンプレミス Kubernetes、さらには混在環境にデプロイしていたとしても、これまでは夢だったマルチクラウドにまたがる IaC がようやく実現し始めているのです。自動化や AI のようなものがインスタンス タイプやその他要素の変更を決定し、コストを削減して利用率を向上させ、リアルタイムで本番環境のインシデントを緩和するといった未来がすぐそこまで来ているのです。
実行可能なパイプラインは、パイプライン テンプレートと（変数を使った）パイプライン設定の組み合わせで構成されています。複数の構成でも、同じパイプライン テンプレートをベースとして利用できます。また、パイプライン テンプレートは継承できるようになっています。
パイプライン テンプレートの利点とは
マルチクラウド / プロバイダーの継続的デリバリと IaC（ベンダー ロックインなし）本番システムをクリーンな状態に保つには、バージョン管理にてパイプライン テンプレートと構成を保存し、コード レビューを行い、各インフラストラクチャが変更された経緯を監査記録として残しておくことが非常に重要です。そうすることで、本番システムで行われたそれぞれの変更がわかりやすく、何か問題が起こった場合も追跡しやすくなり、再現可能となるのです。
インフラストラクチャを再現できるということは、再現可能なビルドなど既存の標準を拡張することにつながり、システム全体で安定性が増し、必要なときにデバッグすることを容易にします。たとえば、インスタンス タイプの変更やロード バランサの追加は、もはや Spinnaker の “クローン” 操作ではなくなりました。これは、コード コミット、コード レビュー、パイプライン テンプレートの構成を変更して Spinnaker にパブリッシュする Jenkins のジョブなのです。その後、結果としてできたパイプラインを実行し、インフラストラクチャの変更に適用させるだけです。これでインフラストラクチャの変更履歴の追跡も簡単です。
これはすべて、複数のクラウド プロバイダーをサポートする方法で行われます。このことは、単一のクラウド プロバイダー上で Kubernetes を利用している企業にも関係があるかもしれません。そのような場合でも、インフラストラクチャを管理するにあたって 2 セットの API と 2 つの制御プレーンが作用し合っているためです。Spinnaker にて Kubernetes が別のクラウド プロバイダーとして扱われているのはそのためです。他のソリューションのクラウドではベンダー ロックインにつながりそうなことですが、Spinnaker ではこれらすべてをうまく抽象化しています。
パイプラインのコード再利用
継続的デリバリの環境では、多くのパイプラインに同じコンポーネント（パラメータを除く）が含まれていることがあります。マネージド パイプライン テンプレートは、コードの重複を削減してパイプライン管理を集中化し、数百から数千にも及ぶパイプラインのダウンストリームを制御する方法を提供します。この手法は、間違いを減らして時間を節約し、ステージングや QA、本番用といった複数の同一環境を同じテンプレート ベースでプロビジョニングすることを可能にします。各インフラストラクチャの変更における自動チェックとカナリア分析
アプリケーションや構成変更の管理の際にデプロイメント パイプラインを利用することに慣れている人も多いと思いますが、デプロイメント パイプラインはインフラストラクチャの変更にも利用できます。インスタンス タイプやファイアウォール ルール、ロード バランサなどを変更するときに利用できるのです。アプリケーションごとに公式のデプロイメント パイプラインがあるため、インフラストラクチャの変更に対しても自動テストやカナリア分析が実行できるようになり、より安全にインフラストラクチャを変更できます。デプロイに向けた明確な道筋と、各アプリケーションによる機能のオーバーライドを定義
デプロイメント パイプラインは、ほとんどのケースで単純なパターンに当てはまることがわかってきました。
- 過去のグループを破棄するのではなく、ゼロへとリサイズしてしまう。
- デプロイ ステージ、待機ステージに数多くのパラメータが存在する。
- カナリア分析のステージが 2 つ存在する（最初は 1 % のトラフィック、次に 50 % のトラフィック）。
- カナリア分析にさまざまなパラメータが送られる。
条件付きステージでは、どのステージを有効化するかを変数で制御します。条件付きステージを活用することで、単一テンプレートを複数のユース ケースで利用できます。実際にどのようになるかは、こちらの動画を参照してください。
ステージを挿入すると、パイプラインの子テンプレートや構成により、パイプラインのステージ グラフにステージを追加できるようになります。たとえば、あるチームが基本的なベイク → デプロイ → 無効化 → 待機 → 破棄というパイプライン テンプレートを使用している場合、前のグループが無効化されたり破棄されたりする前に手動判断ステージを挿入し、人間が決定権を持つようにすることも可能です。実際にどのようになるかは、こちらの動画を参照してください。
新サービス用の自動デプロイメント パイプラインの作成
新サービスがオンラインになると、開発環境でもステージング環境でも本番環境でも、パイプライン テンプレートを使って最初のポイントとなる自動デプロイメント パイプラインを作成できます。これにより、テスト済みの完全なデプロイメント パイプラインをすぐに利用できるようになり、各チームの労力が軽減されます（必要に応じて、あとでカスタマイズすることも可能です）。トラフィック制御やカナリア分析により、この作業も自信を持って完全に自動化できます。全アプリケーションにわたって OS のローリング アップグレードを実行するパイプラインの自動生成
すべての本番システムに OS のセキュリティ アップデートを安全に適用することはとても大変です。しかも、基盤に影響を与えることなくアップデートを実行するとなると、さらに難易度は上がるでしょう。Spinnaker のパイプライン テンプレートとカナリア分析を組み合わせれば、こうした難しい作業を自動化するフレームワークを利用できます。私たち Waze は、ウィークリで OS をアップグレードするパイプラインを利用しています。これは、すべての本番アプリケーションの正式なデプロイメント パイプラインをローリング方式で生成するもので、重要度の低いものから高いものへとアップグレードを少しずつ適用し、最終的に全営業日にわたって適用します。パイプラインを繰り返す中で、前日よりも多くのアプリケーションをアップグレードしていきます。
Waze ではアプリケーションごとに正式なデプロイメント パイプラインを利用しており、「バイナリや設定を変更しないこと ―― 最新セキュリティ アップデートが施されたベースの OS を再構築するだけにとどめておくように」と書かれたランタイム パラメータを送信しています。こうすることで、セキュリティ アップデート以外は前のイメージと変わらない新しい不変のイメージが入手できるのです。これはすべて、通常のカナリア分析保護やロード バランサによるヘルス チェック、トラフィック監視が行われている中で実行されます。
パイプライン テンプレートは、このパターンをさらに次のステップへと進めることも可能にします。メイン OS のアップグレード パイプラインには、すべての新しいアプリケーションを自動的に追加できます。これにより、プロダクション基盤全体が常に OS の最新セキュリティ アップデートに対応しているという状態を保つことができます。
まとめ
Spinnaker のパイプライン テンプレートは、多くのデプロイメント パイプラインを稼働中の企業が抱える主な問題を解決します。また、複数プロバイダーの IaC を制御できるため、バージョンを管理してアプリケーションや構成と共存させることで制約がなくなり、オペレーションの “カオス” を収拾する大きなステップとなるかもしれません。初心者向けの参考文献
パイプライン テンプレートに取り組むにあたって、以下を参考にしてみてください。- Spinnaker のセットアップ ガイドはこちらにあります。
- パイプライン テンプレートの仕様を確認し、スターティング ガイドに目を通してみてください。
- 既存パイプラインをテンプレートに変換するコンバータを試してみるのも、最初のステップとしてよいかもしれません。
- Spinnaker の CLI である roer は、テンプレートと構成を検証してSpinnaker にパブリッシュするために使われます（より良いツールも間もなくリリースされます）。roer のパイプライン テンプレート プランは皆さんの味方になるということを覚えておきましょう。また、テンプレートをパブリッシュした後のデバッグには orca.log もお勧めです。
- 完全なデモの動画はこちらにあります。
- テンプレートの例をいくつか試してみてください。
- Slack の Spinnaker コミュニティに参加し、質問は #declarative-pipelines チャネルまでお寄せください。
* この投稿は米国時間 9 月 6 日、Waze の System Operation Engineer である Tom Feiner と Eran Davidovich によって投稿されたもの（投稿はこちら）の抄訳です。
- By Tom Feiner and Eran Davidovich, System Operation Engineers, Waze
