はじめに

こんにちは。SRE部ECプラットフォーム基盤SREブロックの大澤と立花です。

本記事ではマイクロサービスのカナリアリリースに関して私達が抱えていた課題と、それをFlaggerによるプログレッシブデリバリー導入でどのように改善したのかを紹介します。

ZOZOTOWNのマイクロサービス基盤におけるカナリアリリース手段の変遷については以下のテックブログで紹介しておりますので気になった方はご参照ください。現在はIstio VirtualServiceの加重ルーティングを用いたカナリアリリースに一本化しております。

カナリアリリースの運用課題

カナリアリリースすることで、新しいアプリケーションにバグがあった場合でもユーザへの影響を最小限に抑えられます。一方で、通常のリリースと比較して運用負荷が大きくなるデメリットも存在します。

こちらの図はカナリアリリースの進行を示したものです。

以下を繰り返すことでカナリア用Pod（以下、Canary Podとする）への加重を増やしていきます。

・n％デプロイ
　・Canary Podのreplicas拡張・加重増加の設定変更
・分析
　・Canary Podに流れたリクエストが問題なく処理されているか、レイテンシが悪化していないか判断
　　・問題がない場合、n％デプロイを進行する
　　・問題があった場合、旧バージョンにロールバックする

従来のカナリアリリースでは、これらのサイクルを人が担うことになります。Canary Podへの加重変更プルリクエスト作成、レビュー、CI/CDの待ち時間、エラー発生やレイテンシ悪化の監視といったことが加重変更の都度発生します。このため、カナリアリリースだけでリリース担当者の稼働を半日費やしてしまうことも珍しくなく負担が非常に大きい状態でした。

また、私達のチームではメインのリソースとカナリアのリソースでKubernetesのDeploymentのマニフェストを分けて管理していました。これら2つのマニフェストを日頃からメンテナンスすることになりますので、変更やレビュー対象の増加に繋がり、設定漏れといった人的ミスのリスク要因になりがちです。

解決手段としてのプログレッシブデリバリー

私達のチームが管理する検索APIはリリース頻度が比較的高く、カナリアリリースによる時間的拘束が顕著でしたので改善を目指すことにしました。

そこで挙がったのがプログレッシブデリバリーです。

プログレッシブデリバリーはリリースプロセスを自動化するために、メトリクスの取得・分析を行い、問題がなければデプロイの進行、基準を満たさなければロールバック、といった判断と実行を備えた仕組みです。

このプログレッシブデリバリー用ツールには、Argo Rollouts、Flagger、Spinnakerなどがありますが、私達のチームではFlaggerを採用することにしました。

Flaggerとは？

Flaggerとはプログレッシブデリバリーを実現するKubernetes Operatorです。

私達のマイクロサービス基盤で採用しているツール（Istio, Datadog, Slack）の場合ですと、Flaggerはカナリアリリースを自動で進めるために次のように連携します。

• 加重変更 : Istio VirtualServiceの設定変更
• スケールアウト/イン : DeploymentをオートスケールするためのHorizontalPodAutoscalerの設定変更
• メトリクス取得 : Datadogにクエリ発行
• 通知・アラート : Slackに通知

連携可能なツールについては公式ドキュメントのIntroductionで紹介されております。

続きはこちら