この記事でCloudWatch Evidentlyについて調べていると、「機能フラグ」や「A/Bテスト」などインフラエンジニアには若干聞き慣れないリリース用語が出てきました。
アジャイル開発やCI/CDの台頭に伴い多数出現したこれらのリリース戦略用語をまとめて整理してみることにします。
インフラエンジニアやSREと呼ばれるロールの方々も、リリース戦略を知っておくとCI/CD環境の構築やIaC、はたまたミドルウェアのバージョンアップなどで役立つと思います。
以下ウェブサイトを参考に、各用語を「デプロイ戦略」と「テスト戦略」の大きく2つに分けて紹介します。
デプロイ戦略
従来型のデプロイ（インプレースデプロイ）
システム本番環境が一種類のみ存在し、新バージョンの資材デプロイによって旧バージョンの資材を上書いてしまうパターンです。
環境の設計や管理、維持コストをシンプルに抑えられるメリットがありますが、デプロイ中にユーザー利用に制約が生じるダウンタイムが発生する場合がある点や、新バージョンに不具合が見つかった際のロールバックが大変というデメリットがあります。
ローリングアップデート
本番稼働中のシステムを構成するサーバーやコンテナ等のコンポーネントを、一斉に更新するのではなく少しずつ新パージョンを並行展開してリクエストを徐々にルーティングしていき、時間をかけてすべてのコンポーネントを新バージョンに切り替える手法です。
まさにKubernetesのDeploymentはこの思想でPodのサブセットをデプロイしています。
他にもインフラ寄りの例としては、AWSのEC2 AutoScalingグループでインスタンス更新（Reflesh）という機能がありますが、これはグループ内のEC2インスタンスたちを少しずつサービスから切り離して置換していくもので、ローリングアップデートに近い手法と言えそうです。
※なお、Kubernetesを用いてローリングアップデートを体感できるハンズオン手順を以前に作成しましたので、興味ある方はぜひこちらもご活用ください！
ブルーグリーンデプロイメント
すごく雑に説明すると「本番環境をまるまる2セット（ブルー面とグリーン面）稼働させておき、現用系でない方の面に新バージョンをデプロイし、ユーザーリクエストをそちらへ向けてパチっとルーティング切り替えする」手法です。
従来型のデプロイに比べてダウンタイムが極小化できたり、問題があった際の切り戻しが容易というメリットがありますが、その分本番環境（の一部）をダブルで持たないといけないため設計や管理コストが大きくなります。
この手法を現場で採用する際、課題になりがちなのがデータベースの扱いです。
こういった「システム環境を複数セット持つ」系で必ずぶち当たるのが、「ご本尊たるべきデータベースに変更が入った場合、ACID特性を維持するにはその変更を各データベース間で即座に同期できないといけない」といった類の考えごとです。
データベースのリアルタイムな双方向同期はいい感じのソリューションも少なく、かなり大変でトラブルも起きやすいので、現実的にはB/Gデプロイの対象はWeb画面やAPサーバー相当のコンポーネントのみ（DBはB/Gスコープ外）とするケースも多いのではないでしょうか。
テスト戦略
カナリアリリース
昔むかし、欧米で炭鉱員が地下に降りる際にカナリアをカゴに入れて持ち込み、人間よりも早く有毒ガスの危険性を検知するために重宝されていたようです。（カナリアは毒物に敏感らしい）
これになぞらえて、本番システムに新機能をリリースする際、一部の限られたユーザーが被験体（カナリア）となるよう局所的に新機能を有効化していくことで、リリースに問題があった際の影響範囲を小さくとどめる手法です。
ダークカナリアリリース（DCR）
前述のカナリアリリースは実際のエンドユーザーに対して新機能をリリースしていきますが、実利用者ではなくシステム開発者などの身内に限定して新機能を本番システム上で利用開始するパターンもあり、こちらはDCRと言うそうです。
機能フラグ（Feature toggle）
本番システムに新機能をリリースする際、単純にアプリケーションコードを上書きするのではなく、条件分岐でいつでも新機能をオン/オフできるような機能フラグを埋め込む手法があります。
翻訳前の「Feature toggle」の方がトグルでオン/オフするイメージが湧きやすいかも知れません。
コードの複雑性は上がってしまいますが、前述のカナリアリリースがしやすかったり、とりあえず新機能オフのまま本番環境に予めデプロイだけしておくような手法もとれたり、問題があった際のバックアウトも容易になるというメリットがあります。
※機能フラグはリリース戦略そのものというより、各リリース戦略を実現するための実装手法の一つ、と捉える方が分かりやすいかも知れません。
ダークローンチ（シャドーテスト）
機能フラグやカナリアリリースと混同して語られがちのようですが、明確に区別する立場もあるようなので整理しておきます。
- 機能フラグを「オフ」にしたままコードを本番環境にデプロイして潜ませておく （＝ダークローンチ）
- そのフラグを少しずつ「オン」にして一部のユーザーで新機能をテストする （＝カナリアリリース）
- 新バージョンを現用系と並行してデプロイしておくが、新機能はユーザーリクエストに影響を与えないようにする。ただし本番トランザクションを新バージョンにもミラーリングして擬似的に発生させ、新機能をテストする （＝シャドーテスト）
ざっと上記の使い分けが似たようなキーワードで飛び交っているようでした。
ダークローンチについてはGoogleのCloudアーキテクチャセンターの記事が非常に分かりやすかったです。
A/Bテスト
アプリケーションに新機能をリリースする際、旧バージョン（＝A）と新バージョン（＝B）を比較してどちらの方が効果的か（ビジネス上の効果があるか）を見極める手法をA/Bテストと言います。
こちらも前述の機能フラグによって実現しやすいテスト手法となりそうです。
ちなみにプラットフォームとしてAWSを用いる場合、CloudWatch Evidentlyという機能を使えばA/Bテストと結果分析を行えます。
まとめ
各手法の概要をかなり雑にまとめてしまいましたが、インフラエンジニアなど初学者向けのとっかかりになれば幸いです。
もし誤った内容が含まれていた場合はお知らせいただけるとありがたいです m(_ _)m
参考文献
以下ウェブサイトは上記の各リリース戦略がかなり分かりやすく網羅的にまとまっていました。
また、デプロイに焦点を当てるとさらに多数の選択肢や手法に分類できそうです。