「リリース時にサービス一時停止」は過去の話――Argo Rolloutsによる今どきなノンストップ「デプロイ戦略」：Cloud Nativeチートシート（26）

Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する連載。今回は、「Argo Rollouts」の概要や、サポートする「デプロイ戦略」としてブルーグリーンデプロイ、カナリアリリース、プログレッシブデリバリーなどを紹介します。

[飯野拓人, 関谷祐亮, 岡本隆史, 正野勇嗣，株式会社NTTデータ]

　Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する本連載「Cloud Nativeチートシート」。今回から「Argo Rollouts」に触れ、数回に分けて、概要の理解からハンズオンを交えた使い方のイメージまでを紹介します。今回は第1弾として、Argo Rolloutsの概要とサポートされる「デプロイ戦略」についてです。

目次

• ダウンタイムは“ゼロ”が当たり前の今、「デプロイ戦略」を立てていますか？
• Argo Rolloutsとは
• Argo Rolloutsを支えるメトリクス分析とトラフィック管理
• コラム　Argo Rolloutsの最近の動向（v1.4）
  • ReplicaSet当たりの最小Pod数の設定が可能に
  • 高速ロールバックウィンドウのサポートが追加
• Argo CDとArgo Rolloutsの統合
• 代表的なデプロイ戦略
  • ローリングアップデート
  • ブルーグリーンデプロイ
  • カナリアリリース
  • （おまけ）プログレッシブデリバリー
• デプロイ戦略に共通して考慮すべき観点
  • リクエストロスト
  • セッション切断
  • 下位互換性
• デプロイ戦略をArgo Rolloutsのサンプルで実践

ダウンタイムは“ゼロ”が当たり前の今、「デプロイ戦略」を立てていますか？

　近年、クラウド技術によって著しくアプリケーションの性能が向上しました。これに伴い、トラフィックも増加し、少しのダウンタイムでも大きなビジネス機会を失い、莫大（ばくだい）な損失が発生するようになってきています。

　このような背景の下、アプリケーションのバージョンアップリリース時にダウンタイムを最小限にする工夫が進化しています。

　アプリケーションを停止することなくバージョンアップすることは当たり前とし、バージョンアップ後に不具合が判明した場合、速やかに古いバージョンにロールバックする仕組みなども要求されるようになっています。

　これらのダウンタイムを最小限にしてアプリケーションをリリースしたり、ロールバックしたりする方法を「デプロイ戦略」といいます。

　Kubernetesを利用する場合、Argo Rolloutsを利用すると、ブルーグリーンデプロイやカナリアリリース、さらには「プログレッシブデリバリー」といった、高度なデプロイ戦略を簡単に実装できます。

　本稿では、Argo Rolloutsを紹介しつつ、Argo Rolloutsがサポートするデプロイ戦略について見ていきます。

Argo Rolloutsとは

　Argo Rolloutsは、Kubernetesでブルーグリーンデプロイやカナリアリリースのようなデプロイ戦略をサポートするツールです。Kubernetes標準のデプロイでも「ローリングアップデート」はできますが、Argo Rolloutsを利用すると、より高度なデプロイ戦略を実装できます。

　利用イメージとしては、Deploymentリソースの代わりに、Argo RolloutsのRolloutリソースを定義します。Deploymentリソースを知っていれば、違和感なく利用できるようになっています。

　また、Argo Rolloutsはより先進的な「プログレッシブデリバリー」をサポートしています。「カナリアリリース」のように、システムの一部をリリースしたら、リリースしたシステムのメトリクスを分析します。

　メトリクスの分析によって、リリースが成功したか、失敗したかを判断し、失敗した場合、自動的にロールバックします。一部のみリリースし、リリース失敗時にロールバックすることで、本番環境への影響を最小限に抑えながら運用コストを抑えたリリースが可能になります。

　従来、メトリクスの分析やロールバックは手動でしたが、一連の作業には時間がかかり、オペレーションミスなども発生し得ます。Argo Rolloutsはそうした部分を自動化することでリリースプロセスを高速化し、デプロイリスクを低減できます。

Argo Rolloutsを支えるメトリクス分析とトラフィック管理

　Argo Rolloutsの真価はメトリクスの分析とロールバックにあるといえます。リリースとロールバックは、トラフィック管理によって実現します。ここでは、トラフィック管理とメトリクス分析に着目したArgo Rolloutsの特徴を見ていきます。

• ServiceMeshやIngressコントローラーのトラフィック管理機能を活用して、新しいバージョンのPodへのトラフィック流量をきめ細かく制御する
• ServiceMeshやIngressコントローラーを導入していない場合は、Argo RolloutsがReplicaSetのレプリカ数を操作して、トラフィック流量を制御する
• 「Prometheus」「Datadog」といったモニタリングツールと連携し、取得したメトリクスの値によってPodを昇格（プロモート）するか、ロールバックするかを自動で判断して実行する

　具体的には「10分間のHTTPリクエストの503エラーの割合が1％を超えていた場合はロールバックする」といったルールを設定すると、ルールに該当した場合は自動で新バージョンのPodへのトラフィックを遮断して、旧バージョンのPodにしかトラフィックを流さないようにしてくれます。

コラム　Argo Rolloutsの最近の動向（v1.4）

　2023年1月10日にv1.4がリリースされましたが、このリリースでは11の新機能と12のバグ修正およびその他多くの改善が追加されました。ここでは、リリースに含まれていた重要な事柄から幾つかピックアップして紹介します。

ReplicaSet当たりの最小Pod数の設定が可能に

　Argo Rolloutsは、カナリアリリース中にReplicaSetごとに最小Pod数を設定できるようになりました。

　例えば、最小Pod数が10で最大Pod数が100となるような水平スケーリングを設定されたPodが存在するとします。このPod数が20の時点でカナリアウェイトを5％に設定してカナリアリリースを実行してしまうと、一時的にカナリア側のPod数が「1」となるケースが発生してしまいます。これではカナリアトラフィック側の可用性を著しく下げてしまい、サービス全体の品質を下げることにつながりかねません。

　今回追加された最小Pod数を設定することで、特定条件下でのカナリアリリースにおける可用性を高めることが可能になりました。

高速ロールバックウィンドウのサポートが追加

　Argo Rolloutsは、過去世代数に基づいて高速ロールバック機能をサポートするようになりました。

　Argo Rolloutsではデプロイ工程の中に「分析」フェーズを追加でき、より高品質なデプロイ作業を実現できます。一方で、従来は「新バージョンのアプリケーションに問題がある」と判断されて旧バージョンにロールバックする際にも、「分析」フェーズが実行されてしまい、ロールバック完了までにかかる時間が長くなってしまう問題がありました（過去世代の品質は安定稼働していた実績から十二分に足ります）。

　今回追加されたロールバックウィンドウの値を設定することで、任意の過去世代数までは「分析」フェーズを行わずにロールバックが可能になりました（参考：公式Docs - Rollback Windows）。

Argo CDとArgo Rolloutsの統合

　デリバリーツールのArgo CDとArgo RolloutsはどちらもArgoプロジェクトの製品で混同することがあるので、Argo CDとArgo Rolloutsの違いと関係について説明しておきます。

　Argo Rolloutsは単独でも使用できますが、Argo CDと一緒に利用されることが多いです。そういった意味では、競合するものではなく相互に補完するツールといえます。

　一緒に利用する場合、Argo Rolloutsで定義したリソースとその他のKubernetesリソースをGitリポジトリで一緒に管理します。リソースに変更があった場合、Argo CDでデプロイします。その後、Argo RolloutsはRolloutオブジェクトに変更があった場合に、新旧バージョンそれぞれのReplicaSetを操作したり、Ingressなどのトラフィックルーティングを変更したりします。

Argo CDとArgo Rolloutsの関係図

　もしRolloutsの処理中にロールバックが発生した場合、Argo Rolloutsのマニフェスト上は新バージョンが指定されていますが、動作しているPodは旧バージョンです。この時、Argo CDのヘルスチェックからは、Rolloutリソースは「Degraded（劣化）」の状態に見えます。

　ちなみに、Argo CDにもロールバック機能はありますが、Gitリポジトリの特定のcommitの状態にロールバックするだけで「ブルーグリーンデプロイ」「カナリアリリース」といった細かいデプロイメントの制御はしてくれません。

代表的なデプロイ戦略

　さて、Argo Rolloutsの使い方に進む前に、デプロイ戦略についておさらいしておきます。

　一口に「デプロイ戦略」といってもさまざまな手法が存在し、プロダクト環境によってとり得る選択肢は大きく変わります。開発者はそれぞれの特徴をしっかりと理解し、アプリケーションの性質やリリースの目的、運用の条件などを考慮した上で次の観点から最適な戦略を選択できることが求められます。

1. デプロイの速度と安定性
   デプロイ戦略は、アプリケーションのデプロイの速度と安定性に大きく影響する。特定のデプロイ戦略を選択することで、デプロイの速度を向上させ、アプリケーションの安定性を高めることができる
2. ダウンタイムの最小化
   特定のデプロイ戦略を選択することで、デプロイのダウンタイムを最小限に抑えられる。これによって、アプリケーションの稼働時間を最大限に保つことができる
3. リリースの品質管理
   デプロイ戦略は、リリースの品質管理にも大きく関係する。特定のデプロイ戦略を選択することで、より効果的に品質を管理できる

　本記事では、代表的なデプロイ戦略として「ローリングアップデート」「ブルーグリーンデプロイ」「カナリアリリース」の3つを紹介します。

ローリングアップデート

　アプリケーションをデプロイする際に、徐々に新バージョンに置き換える方法です。旧バージョンから新バージョンにスムーズに移行でき、アプリケーションのダウンタイムを最小限に抑えることができます。

ローリングアップデートのリリースフロー

　更新の過程は次の通りです。

1. ユーザーからのトラフィックが常時旧バージョン（v1）で処理される
2. 新バージョン（v2）を新規にインスタンス作成完了後ロードバランサーにひも付け、旧バージョン（v1）のうち1台をロードバランサーから切り離す
3. 上記工程を全てのインスタンスが新バージョン（v2）に入れ替わるまで繰り返すことで、ユーザーからのトラフィックが全て新バージョン（v2）で処理される

　このように、既存の環境に変更を加える方式を採用しているが故に、新バージョンで障害発生した際には旧バージョンへの切り戻し作業に時間がかかってしまうという課題があります。

　また複数コンポーネントで依存関係のあるサービスを同時アップデートする際は、新バージョンと旧バージョン間での整合性の考慮が必要となり、実現が困難になります。

　これらを解消するのが次に紹介する「ブルーグリーンデプロイ」です。

ブルーグリーンデプロイ

　新バージョンのアプリケーションを別の環境にデプロイし、トラフィックを瞬間的に切り替える方法です。

　旧バージョンと新バージョンが完全に分離しているので、問題が発生した際に、迅速にロールバックできます。

ブルーグリーンデプロイのリリースフロー

　更新の過程は次の通りです。

1. ユーザーからのトラフィックが常時旧バージョン（v1）で処理される
2. 旧バージョン（v1）と同等の構成で新バージョン（v2）のインスタンスを作成する
3. ロードバランサーの宛先を新バージョン（v2）側に切り替えることで、ユーザーからのトラフィックが全て新バージョン（v2）で処理される
   →新バージョン（v2）に問題があると判断された場合には、再度ロードバランサーの宛先を旧バージョン（v1）側に切り替えることで、瞬時にロールバックする
4. 不要となった旧バージョン（v1）を削除する

　このように既存の環境に変更を加えない方式を採用しているので、新環境で万が一問題が発生した場合でもすぐに既存環境にロールバックできます。一方で、既存環境と新環境とで、一時的ではあるものの2面保有することになるので、コストはその分かかってしまいます。

　これまで紹介してきた「ローリングアップデート」「ブルーグリーンデプロイ」に共通しているのは、デプロイ作業における影響リスクを全ユーザーが一度に受けてしまう点です。

　これらを解消するのが次に紹介する「カナリアリリース」です。

カナリアリリース

　新バージョンのアプリケーションを一部のユーザー（カナリア）に対して展開し、徐々に全体に展開する方法です。新バージョンのアプリケーションの品質を評価し、問題が発生した際に迅速にロールバックできます。

カナリアリリースのリリースフロー

　更新の過程は次の通りです。

1. ユーザーからのトラフィックが常時旧バージョン（v1）で処理される
2. ユーザーからのトラフィックの一部（上図では10％）をカナリアトラフィックとして利用し、カナリアトラフィックのみロードバランサーの宛先を新バージョン（v2）側に向ける
   ※「新バージョン（v2）に問題がある」と判断された場合に、運作用作業で再度ロードバランサーの宛先を旧バージョン（v1）側に切り替えることで、ロールバック可能となる
3. 「カナリアトラフィックに問題がない」と判断されたので、適用割合を段階的に増加させる（上図では60％）
   ※この時新バージョン（v2）へのトラフィック増加と並行して、新バージョン（v2）のインスタンス作成と旧バージョン（v1）インスタンスの削除も行われる
4. 上記工程を全てのインスタンスが新バージョン（v2）に入れ替わるまで繰り返すことで、ユーザーからのトラフィックが全て新バージョン（v2）で処理される

　このように既存の環境に変更を加える方式を採用しつつも公開範囲を限定的にすることで、新バージョンで障害発生した場合でも影響を受けるユーザーの割合を抑制できます。

　しかしながら、本戦略が全てを解決する「最強の戦略」とはなりません。

　カナリアによって得られた品質指標は適切なのかどうか、それをどう評価するのかといった点から、運用作業者の負担はどうしても増えてしまいます。

　本章の冒頭でも話した通り、アプリケーションの性質やリリースの目的、運用の条件などを考慮した上で最適な戦略は何かを考えていきましょう。

（おまけ）プログレッシブデリバリー

　冒頭でも少し触れましたが、本戦略は上記3つに代表されるCD（コンティニュアスデリバリー）の次のステップとして位置付けられた比較的新しい手法です。

　CDでは、新環境の妥当性を人間が判断する必要があり、問題発生した場合はデプロイ作業とは別に手動のロールバック作業が必要になります。一方、PD（プログレッシブデリバリー）は、デプロイ作業の中に「分析」という観点を新たに加えることで、CDパイプラインによるデプロイスピードとデプロイに伴うリスク軽減を両立することを目指したものです。

　詳細説明は次回以降の記事で記載するので、お楽しみに！

デプロイ戦略に共通して考慮すべき観点

　さまざまなデプロイ戦略を紹介しましたが、ダウンタイムゼロなデプロイ戦略を選択する上で考慮すべき観点が多数あります。それら観点はインフラレイヤーの問題だけでなく、アプリケーションレイヤーにおいても対策が必要なものがあります。

　以下、代表的な観点と対策例を紹介します。

リクエストロスト

　リクエスト処理中でも更新処理が走ることを考慮し、保持しているリクエストを全て処理完了してからアプリケーションを停止させる必要があります。ご利用のWebサーバライブラリやミドルウェアが「Graceful Shutdown」に対応しているかどうかを確認しておきましょう。

セッション切断

　セッションが同じインスタンスで処理される必要がある場合、ロードバランサー側でスティッキーセッションを設定したり、セッション情報の保管先をアプリケーションから切り離したりする必要があります。

下位互換性

　従来の閉塞（へいそく）リリースと異なり、リリース作業中にもリクエストが引っ切りなしに飛んでくるので、異なるバージョン間のアプリケーションでデータの互換性を保証できる作りにする必要があります。

　特にDBデータの互換性は考慮から漏らさないように気を付けましょう。

デプロイ戦略をArgo Rolloutsのサンプルで実践

　今回は、Argo Rolloutsの概要とArgo Rolloutsでサポートされるデプロイ戦略を紹介しました。

　システムリリース時に一時的にサービスを停止するのは、もう過去の話です。今どきのエンジニアの間では、いかにしてシステム停止時間を0に近づけるか、新バージョンのリリースに不具合が発生したときに、いかにしてユーザーへの影響を少なくするかが課題であり、さまざまなデプロイ戦略が提案されているのが分かったと思います。

　次回は、今回紹介したデプロイ戦略を、Argo Rolloutsのサンプルを交えて実践します。次回もお楽しみに！