カナリアデプロイとは ― 意味と戦略

カナリアデプロイとは

少し独特な手法を用いていますが、カナリアデプロイはブルーグリーン方式と同様に動作します。つまり、一度にサーバーやノードの一部だけを切り替え、残りは順次切り替える形で進め、全面的な環境切替えを待たなくても進行できます。

カナリアデプロイの実装には、ステージングやテスト環境を多様な形で整えることが可能です。最もシンプルな方法は、通常通りロードバランサの背後にエコシステムを設置しつつ、アプリの規模に応じて未使用のサーバーやノードを1台以上確保する方法です。

この予備のノードまたはサーバー群がCI/CDプロセスにおけるデプロイ対象となります。ビルド、デプロイ、テスト後、短時間だけこのノードをロードバランサに戻し、一部のユーザーで動作を確認します。これにより、クラスタ内の他のノードへ同様の手順を適用する前に変更の効果を検証できます。

もう一つの方法は、フィーチャートグルの開発パターンを活用することです。アプリに変更を加える際、フィーチャーフラグと呼ばれる設定でその機能を有効に管理します。

クラスタからノードを一旦外し、デプロイ後に再追加することで、ロードバランサを経由せずにテストや管理を行う方法もあります。全ノードが更新された後、一部のユーザー向けに機能を有効化し、問題なければ全体へと展開します。

ただし、この手法にはフィーチャートグル対応のため、開発コストや時間、資金が増加するという欠点もあります。アプリの規模や成熟度によって、実装の難易度は変わるでしょう。

‍

カナリアデプロイ vs カナリアリリース

カナリアリリースの意味について考える場合、まずその内容を確認してみよう。

全ユーザーへ配布されているものの、安定性に欠けるか新機能が未検証のアプリは「カナリアリリース」と呼ばれます。 

アルファ版、ベータ版、またはアーリーアクセス版が用いられることもあります。オープンソースコミュニティでは、新リリースの実験を促すために、安定版と開発版を分けて運用することが一般的です。

Mozilla Firefoxはナイトリーベータ版を提供し、Google Chromeもカナリアリリースを活用しています。Google Chromeには新バージョンへの早期アクセスを可能にするカナリアチャネルが設けられています。

一方、カナリアデプロイは、段階的なリリースを行うソフトウェア開発手法です。限られたユーザーにまずアップデートを提供し、テストとフィードバックを得る仕組みです。 

変更が承認された後、残りのユーザーへアップデートが展開されます。 

最後に、APIバージョンの最新リリースを、APIゲートウェイのカナリアデプロイとして展開するという優れた手法も存在します。

‍

カナリアデプロイの仕組み

カナリアデプロイでは、2つのバージョンのアプリが同時に稼働します。旧バージョンを「安定版」、新バージョンを「カナリア」と呼びます。アップデートのリリース方法には、ロールングとサイドバイサイドの2種類があります。

それぞれの動作を見ていこう。

1. サイドバイサイドデプロイ

ブルーグリーンデプロイとサイドバイサイドデプロイは非常に似ています。カナリア版は、既存マシンを順次アップグレードするのではなく、新たに複製した環境にインストールされます。

アプリがデータベース、複数のサービス、そして複数のコンピュータやコンテナを使用している場合、次の手順となります。

• アップグレードをインストールし、ハードウェアリソースを複製してからデプロイを実施する。
• 新環境で動作させた後、一部のユーザーにカナリア版を公開する。通常、ルーター、ロードバランサ、リバースプロキシ等の仕組みが用いられる。
• ロールングデプロイと同様に、徐々にユーザーを安定版からカナリアへ移行し、問題が出るか全ユーザーが切り替わるまで監視する。
• デプロイ完了後、リソースを解放するために旧環境を廃止する。この時点でカナリア版が安定版となる。

2. ロールングデプロイ

数台ずつ、段階的に変更をリリースする手法がロールングデプロイです。残りのユーザーは引き続き安定版を利用します。最もシンプルな方法の一つと言えるでしょう。

• まず、1台のサーバでカナリアを稼働させ、少数のユーザーがアップデートを受け取る。
• 担当者が、更新されたマシンの動作状況を確認し、エラーや性能問題、ユーザーからのフィードバックに注視する。
• 信頼性が確認され次第、他のマシンにもカナリアを順次導入し、最終的に全マシンが最新バージョンとなるよう展開する。
• 問題が発生した場合、または期待に沿わない結果が出た場合は、更新したノードやサーバを元の状態に戻すことが可能である。

以下は、こうしたデプロイがどのように動作するかの説明である:

• 初めは、全てのトラフィックが現行バージョンへ送られる。
• 例えば、全体の95%のユーザーは旧バージョンを使用し、新規ポッドでのカナリアデプロイではわずか5%のトラフィックを受ける。
• 新バージョンは、ほとんどのユーザーに影響を与えることなく、各種テスト（スモークテストなど）が実施される。
• 各時点でカナリアとして扱われるトラフィックの割合は、自動判断プロセスにより決定される。
• 新バージョンが期待どおりに動作する場合、5%、25%、50%、75%、100%と段階的にカナリアトラフィックを増やしていく。問題があれば、直ちに最新バージョンへ切り替える。
• カナリアトラフィックの中で最新バージョンに問題が発生した場合、デプロイは前のリリースに戻され、大多数のユーザーには影響がほとんど及ばない。カナリア版が撤回されると、全体が元の状態に戻る。
• 新バージョンが全トラフィックを受けた時点で、旧バージョンは削除される。

カナリアの歴史

カナリアは、英国鉱山において一酸化炭素などの有害物質を検知し、危険を知らせるために重要な役割を果たしていました（ソフトウェアのデプロイでも人間より感受性が高いことから『カナリア分析』という用語が使われています）。 

WallarmのDevOpsエンジニアは、CI/CDプロセスにおける新リリースが企業に影響を及ぼさないかどうか、事前に検証を行っています。

‍

カナリアデプロイの利点

• シンプルなロールバック

重大な問題が発生した場合、すぐにデプロイを元に戻すことができます。フィーチャーフラグの切り替えやトラフィックの旧バージョンへの再振り分けで実施されます。

• キャパシティテスト

旧システムに代わる新たなマイクロサービス導入時、プロダクション環境で必要な容量をテストできる点が有益です。カナリアモデルを小規模なユーザーで検証することで、システム拡張に必要なリソースを算出できます。

カナリアデプロイとKubernetes

多くの企業がKubernetesを利用しているため、AWSでの手法に似た形でカナリアデプロイを実施できます。しかし、用語は異なります。

サービスに「登録」されたポッドには、ロードバランサとして機能する仕組みがあり、またASGと同様の働きをする「デプロイメント」も存在します。

‍

カナリアデプロイの欠点

完全無欠な手法ではないため、以下のような欠点もあります:

• コスト

サイドバイサイドデプロイで必要な追加インフラのため、コストは高くなります。クラウドの利点を活かし、必要に応じてリソースの追加や削減を行い、費用削減に努めます。

• 複雑さ

この手法はブルーグリーン方式に近く、多数の製造マシンの管理、ユーザーの移行、新システムの保守など、負担が大きくなる場合があります。

‍

ブルーグリーンデプロイとは

ソリューションのインフラを、均等なリソースを持つ2つのゾーン「ブルー」と「グリーン」に分割します。ブルーゾーンではロードバランサが現在のアプリのトラフィックの半分を管理し、その後、新しいアプリやソリューションをグリーンゾーンに展開します。 

グリーンゾーンでテストと展開を進める間、ロードバランサがトラフィックを振り分け、ブルー環境には手を加えず、常にプロダクション用として維持します。 

すべてのアプリ展開とテストが完了した後、ロードバランサを利用してグリーン環境を完全に管理し、ユーザーに変化を感じさせることなく切り替えることができます。

‍

カナリアデプロイ vs ブルーグリーン

簡単に言えば、ブルーグリーンデプロイとカナリアデプロイの違いは次の通りです:

• カナリアデプロイは、本番環境で新機能を低リスクでテストする際に用いられる。
• ブルーグリーンデプロイは、主にプロセスのダウンタイムをなくすために活用される。

検討すべき点は多岐にわたり、全ての状況に万能な解決策は存在しません。以下のいずれかが当てはまる場合、ブルーグリーンデプロイを検討するのが一般的です: 

• 更新版に対する信頼が高く、十分なテストが行われているため、失敗の可能性が低い。
• 短時間で安全にイテレーションを重ねる。
• 全ユーザーを一度に切り替える必要がある。

一方、カナリアデプロイが適しているのは、

• 新バージョンに十分な期待を寄せられる場合。
• 性能やスケールに関する懸念が大きい場合。
• 大幅なアップデート、例えば全く新しい機能の追加などが行われる場合。

カナリアデプロイ計画の要素

• ステージ
• 期間
• 指標
• 評価

‍

カナリアデプロイが利用できない場合

カナリアデプロイは、以下の場合には利用できません:

• 障害が大きな経済的影響を及ぼす（例：銀行システム）場合。
• ユーザーのPC上のソフトウェアを遠隔で更新できない場合。
• 航空宇宙や医療など、継続的なデプロイが禁止されている分野で作業する場合。
• データベースやストレージバックエンドを大幅に変更する必要がある場合。
• 電力網や原子炉など、生命維持や重要ミッションのシステムを扱う場合。

結論

カナリアデプロイ戦略は、変更を本番環境に取り込むリスクを低減し、必要なインフラも少なくて済むため支持されています。全ユーザーへ一斉に展開するのではなく、実際の環境で新バージョンをテストできます。

環境の更新や変更時にダウンタイムを発生させないため、デプロイの自動化と一貫性は非常に重要です。CI/CDパイプラインを活用して、アプリ環境の自動デプロイ、テスト、切替えを管理することが有益です。

結論として、カナリアデプロイは思ったほど難しくありません。実施方法は多岐にわたりますが、Kubernetesを利用するのが自然に感じられるかもしれません。全てを自動化すれば、より迅速かつ安心して展開でき、結果としてビジネスにダウンタイムゼロをもたらします。