PHPのカナリアデプロイでは、新しいバージョンをトラフィックの一部に限定して公開し、対象を拡大する前に挙動を評価できます。その価値はテストの代わりになることでも、変更の安全性を保証することでもありません。本番環境で問題を検出する際、当初の影響範囲を限定し、明確な判断基準を設けられる点にあります。
機能させるには、各バージョンが共存できること、トラフィックを制御して振り分けられること、チームが比較可能な結果を観測できることが必要です。インフラがこれらの条件を満たさない場合は、よりシンプルな段階的リリースや、慎重に計画したメンテナンス時間帯を選ぶほうが妥当なこともあります。
カナリアデプロイで抑えられるリスク
自動テストや本番前環境は不具合の発見に役立ちますが、実際の顧客、データ、連携先、負荷の分布を必ずしも再現できるわけではありません。カナリアでは、影響を受ける可能性のあるユーザー層をあらかじめ限定し、実際のリクエストでバージョンを検証します。
実際には、候補バージョンにトラフィックの一部を割り当て、残りは安定版で処理します。チームは両者の健全性を示すシグナルを比較します。重大な回帰がなければ公開範囲を拡大し、悪い兆候が現れた場合は拡大を止め、定めた手順を実行します。
カナリアは、単に複数の段階に分けて公開するプログレッシブデプロイとは異なります。カナリアでは、対象ユーザー層の評価と、判断前のシグナル比較を重視します。また、フィーチャーフラグによる段階的な有効化とも別のものです。フィーチャーフラグはコードをデプロイ済みの状態で新機能を非表示にできますが、アプリケーションの2つのバージョンを比較できるとは限りません。
使うべき場面と、よりシンプルな方法を選ぶ場面
変更の影響が大きく、シグナルを観測できるだけのトラフィックがあり、アーキテクチャが2つのバージョンの同時稼働に対応している場合に効果を発揮します。影響を受ける対象を限定でき、各リクエストを処理したバージョンと関連付けられる場合は、特に有用です。
常に見合うとは限りません。トラフィックが少なければ結果がはっきりしないことがあります。また、小規模なサービスで変更の影響範囲も限定的なら、ルーティングや可観測性の運用コストがメリットを上回る可能性があります。互換性のないマイグレーションや取り消せない操作に対して、カナリアだけで十分な保護になると考えるのも適切ではありません。
よりシンプルな選択肢には、利用の少ない時間帯のリリース、特定の機能を制御するフィーチャーフラグ、内部環境への先行デプロイなどがあります。それぞれ解決する問題は異なります。時間帯の選択は一時的な露出を抑え、フィーチャーフラグは機能の有効化を制御し、内部環境は事前検証に使えます。どの方法を選ぶかは、低減したいリスクと利用可能な機能によって決まります。
インフラと運用の要件
PHPのカナリアデプロイを自動化する前に、インフラ上で安定版と候補バージョンを並行稼働できるか確認してください。評価中に両方を動かすには、デプロイ成果物を分けること、PHPプロセスと設定の互換性を保つこと、十分な稼働容量を確保することが必要になる場合があります。
- 制御可能なルーティング：ロードバランサー、プロキシ、コンテナプラットフォームなどのコンポーネントを使い、割合または定義した対象に候補バージョンを振り分けられる必要があります。仕組みは元に戻せるもので、運用上の担当者も明確でなければなりません。
- バージョンの識別：ログ、メトリクス、トレースから、各リクエストをどのバージョンが処理したか判別できる必要があります。区別できなければ、比較に両バージョンの影響が混在する可能性があります。
- 互換性のある設定：シークレット、環境変数、セッション、キャッシュ、共有キューが共存中も機能する必要があります。バージョン間で互換性のない形式や契約を前提にしてはいけません。
- 判断に使える可観測性：リリース前にダッシュボードとアラートを用意してください。担当者が確認したり、適時に解釈したりできないメトリクスは、判断に役立ちません。
セッションの永続性とトラフィックのアフィニティも検討してください。ユーザーを常に同じバージョンに割り当てれば比較しやすくなる場合がありますが、アーキテクチャに左右され、結果に偏りをもたらす可能性もあります。いずれの場合も、ルーティングの判断によってバージョン間で予期しない状態変化が起きないようにしてください。
対象、段階、評価シグナルを決める
影響範囲を説明し、限定できる対象から始めてください。選定方法に一貫性があり、重要なケースが除外されないことを条件に、リクエストの割合や制御されたセグメントで対象を定義できます。どのサービスにも安全な特定の割合があると考えてはいけません。初期規模は、トラフィック量、潜在的な影響、対応能力によって決まります。
拡大の段階と観測時間を事前に定めてください。各段階は、関連する利用状況を観測するのに十分な長さにする必要があります。影響を受ける処理の発生頻度が低い場合、任意の時間だけ待っても不十分です。誰がデータを確認し、誰がプロセスを停止できるかも決めておきます。
技術的な障害とユーザーへの悪影響の両方を検出できるシグナルを使い、候補バージョンと安定版を比較します。
- エラー：バージョンごとの失敗応答率、PHP例外、依存関係のエラー、非同期処理の失敗。
- レイテンシ：応答時間。重要なルートやトランザクションごとに分けるのが望ましく、リソースの飽和を示すシグナルも確認します。
- ビジネス上の結果：処理の完了、決済の処理件数、重要なフローのエラーなど。定義とデータソースの信頼性を確保してください。
- 整合性：変更がデータやプロセスに影響し得る場合は、重複、状態の不整合、システム間の差異を確認します。
集計指標が改善または安定していても、特定のルート、顧客、依存関係に集中した問題は否定できません。エラーの状況や分布を確認し、可能であれば同等の期間と対象を比較してください。
しきい値を定め、ロールバックに備える
デプロイ前に、拡大できる条件、一時停止が必要な条件、ロールバックが必要な条件を合意してください。しきい値にはベースラインとサービスで許容できる影響を反映させる必要があり、共通の値はありません。たとえば、全体平均が安定していても、重要なルートでエラーが増加すれば一時停止の理由になります。
手順も文書化してください。誰がルーティングを変更するのか、候補バージョンをどう除外するのか、安定版へのトラフィック復帰をどのように確認するのか、インシデントをどう伝えるのかを明確にします。一時停止とロールバックは同じではありません。一時停止は調査中に公開や拡大を止めること、ロールバックは検証済みの手順に従ってサービスを以前のバージョンに戻すことです。
コードをロールバックしても、データの変更、送信済みメッセージ、外部操作が自動的に取り消されるわけではありません。そのため、迅速な切り戻しは計画の一部としてテストし、リリース後に残る状態も考慮してください。
共有データとバージョンの共存
最も慎重な対応が必要なのはデータベースであることが多いです。新バージョンが、安定版では理解できないカラムや形式を直ちに必要とする場合、安全な共存はできません。サービスを維持できる順序で、互換性のある変更を設計してください。まず互換性のある構造を準備し、次にそれを扱えるコードをデプロイし、その後、どのバージョンからも不要になってから旧構造を削除します。
キャッシュ、セッション、キュー、内部APIの契約にも同じ考え方を適用してください。移行中にコンシューマーとプロデューサーがどう動作するかを確認し、2つのバージョンが互換性のない状態を書き込まないようにします。互換性を保証できない場合は、マイグレーションとデプロイを分けるか、別の戦略を選ぶ必要があります。
手順とチェックリスト
運用サイクルを明確にしておくと、その場しのぎの判断を減らせます。候補バージョンをデプロイし、トラフィックを割り当てる前に正常性を確認し、初期対象を有効にし、合意したシグナルを観測し、拡大・一時停止・ロールバックを判断して、その判断を記録します。各段階の後に、バージョン、対象、観測時間帯、インシデント、担当者を記録してください。
開始前に次の項目を確認します。
- バージョンが共存でき、両方を稼働させる容量がある。
- ルーティングとその切り戻しをテスト済みである。
- 移行中、共有データと状態に互換性がある。
- メトリクスでバージョンを区別でき、有用なベースラインがある。
- しきい値、担当者、一時停止とロールバックの手順が合意済みである。
- 自動では取り消せない影響をチームが把握している。
これらの条件が複数欠けている場合は、複雑さを増やす前にテスト、可観測性、リリース制御を改善してください。カナリアデプロイはパイプラインの単なるオプションではなく、アーキテクチャと運用に関わる判断です。実トラフィックから学び、回帰が対象全体に及ぶ前に対応できる場合に価値を発揮します。
