Argo Rolloutsを用いたカナリアリリースの提供

メディア統括本部 サービスリライアビリティグループ(SRG)の谷成です。
#SRG(Service Reliability Group)は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
本記事は、従来の一括デプロイによる全ユーザーへの影響リスクを解消し、段階的トラフィック制御と自動監視により安全で迅速な機能提供を提供するためにArog Rolloutsを用いてカナリアリリースの機能を提供する過程を紹介する記事となっております。
 

なぜカナリアリリースが必要か


システムの生産性や信頼性を向上させることは、開発において重要な課題となっています。特に、新しい機能や修正をリリースする際には、予期せぬ不具合によってサービス全体に影響が及ぶリスクが常に伴います。
このリスクを最小限に抑え、安全かつ迅速にリリースを行うための手法の一つが「カナリアリリース」です。
カナリアリリースとは、新しいバージョンのアプリケーションをリリースする際に、まずは一部のユーザーだけに公開し、問題がないことを確認しながら段階的に全ユーザーへと展開していくデプロイ手法となっています。
カナリアリリースを導入することで、以下のようなメリットが期待できます。

リリースのリスク低減

問題が発生しても影響範囲を限定でき、迅速な切り戻しが可能です。

本番環境での品質検証

実際のユーザーアクセスがある本番環境で、新機能のパフォーマンスや安定性を検証できます。

ユーザー体験の向上

大規模な障害を防ぎ、安定したサービスを提供することで、ユーザーの信頼と満足度を高めます。

開発者の心理的安全性の確保

成果物にバグなどがあっても最小限の被害で留めることが見込めるため、開発者のリリース時の心理的負担を軽減できます。

カナリアリリース実現方法の調査


一口にカナリアリリースと言っても、実現するためのツールや手法は数多く存在します。
私たちは、既存のPlatform環境との親和性や導入コストを考慮し、最適な方法を調査しました。

様々なツールの比較

まず、カナリアリリースを実現できる可能性のあるツールをいくつか検討しました。
  • Linkerd
    • Istioと同様にサービスメッシュの機能を提供しますが、私たちは既にIstioを導入しているため、見送りました。
  • Consul Connect
    • こちらもサービスメッシュの一種です。マルチクラウド環境などでは強力な選択肢ですが、現在の要件とは合致しませんでした。
  • Spinnaker
    • CI/CDツールとして非常に高機能ですが、カナリアリリースという目的のためだけには導入が大掛かりすぎると判断しました。
  • Keptn
    • SLO(サービスレベル目標)の計測など、高度な運用自動化が可能ですが、今回のカナリアリリースを実現するだけには大掛かりすぎると判断しました。
これらのツールは非常に強力ですが、いずれも導入には相応の学習コストや運用負荷が伴います。
そこで、私たちは既にPlatformに導入されている技術スタックを最大限に活用する方針を採用しています。

Argo Rolloutsの選定

私たちの環境では、サービスメッシュとしてIstio、CDツールとしてArgo CDが既に利用されています。
Istioのを使えば、トラフィックの重み付けによるカナリアリリース自体は可能です。
しかし、Istio単体では、エラーレートなどのメトリクスを監視し、その結果に応じて自動的にロールアウトを進めたり、ロールバックしたりする「プログレッシブデリバリー」を実現することは困難となっております。
そこで注目したのが「Argo Rollouts」です。
Argo Rolloutsは、Kubernetesネイティブなプログレッシブデリバリーを実現するためのツールで、Argo CDとは別のコンポーネントとしてインストールします。
Argo Rolloutsを導入することで、既存のIstioと連携し、開発者体験を損なうことなく、安全で自動化されたカナリアリリースを実現できると判断しました。

Argo Rolloutsによるカナリアリリースの実践


ここからは、実際にArgo Rolloutsを導入し、カナリアリリースを試した手順を解説します。

Argo Rolloutsのインストール

まず、Argo Rolloutsのコントローラーをクラスタにインストールします。
基本的には公式ドキュメントに従い、以下のコマンドでインストールできます。

基本的なカナリアリリース

Argo Rolloutsでカナリアリリースを行うには、標準のリソースの代わりに、Argo Rolloutsが提供するというカスタムリソースを使用します。
リソースはとほぼ同じように定義できますが、フィールドでカナリアリリースの手順を細かく設定できる点が特徴です。
以下は、リソースと、分析に使用するの簡単な例です。
Rolloutリソースの例
AnalysisTemplateの例 (Datadog連携時)
この設定により、新しいバージョンをデプロイすると、まずトラフィックの10%が新しいバージョンに向けられます。
5分後、Datadogから取得したエラーレートをに基づいて評価し、問題がなければ次のステップに進みます。
しかし、この方法だけでは一つ課題があります。
Argo Rollouts単体でのトラフィック制御は、Podのレプリカ数に基づいています。
例えば、3つのPodがある状態で10%のトラフィックを向けようとしても、実際には新しいPodが1つ立ち上がり、トラフィックの約33%がそちらに向いてしまいます。
より厳密なトラフィック制御を行うには、Istioとの連携が必要になってきます。

Istio連携による高度なトラフィック制御

この課題を解決するため、リソースにIstioのを連携させる設定を追加します。
Istio連携を設定したRolloutリソース
連携するVirtualServiceとDestinationRule
リソースのフィールドでIstioとの連携を定義すると、Argo Rolloutsはデプロイの進行状況に応じてを自動的に書き換えてくれます。
これにより、Podの数に依存しない、パーセンテージに基づいた正確なトラフィック制御が可能になります。

Argo Rolloutsの運用ガイド


Argo Rolloutsを実際に運用していく上での基本的な操作方法を紹介します。

Argo Rolloutsの操作

のプラグインをインストールすると、CUIでの操作が非常に便利になります。
また、ローカルPCでダッシュボードを起動し、GUIで状況を確認することも可能です。
このコマンドを実行すると、でダッシュボードが開き、各Rolloutのステータスを視覚的に確認したり、(一時停止を解除して次のステップへ)や(全ステップをスキップしてリリースを完了)といった操作を行ったりできます。

注意点

調査の過程で、リリースを中断(Abort)している最中にオブジェクトを削除したところ、古いが残存してしまうという事象が発生しました。
大きな問題にはならないと思いますが、そのままにしておくと不要なリソースを保持することになってしまうため運用時には、リソースの削除タイミングなどは注意が必要そうです。

まとめ


本記事では、生産性と信頼性の向上を目的として、Platform上でカナリアリリースを実現する方法について調査と実践を行いました。
様々なツールを比較検討した結果、既存の技術スタックであるIstioと親和性が高く、プログレッシブデリバリーを実現できるArgo Rolloutsを採用しました。
Argo RolloutsとIstioを組み合わせることで、メトリクスに基づいた分析を取り入れつつ、パーセンテージベースの正確なトラフィック制御が可能になり、安全で柔軟なリリースフローを構築できることが確認できました。
今後も継続的に改善を進め、より安定したサービス提供を目指していきます。
 
SRGにご興味ありましたらぜひこちらからご連絡ください。