Feature Flagsを使用した本番環境でのキルスイッチの６つのユースケース

キルスイッチは、アプリ内の細かな機能や性能を制御したり、アプリ全体に影響を与える長期的な運用スイッチとしての可能性を生み出します。ここでは、キルスイッチをどのように活用できるかを探ります。

最近になってFeature Flagsに出会った方は、フィーチャーフラグという概念がかなり以前から存在し、アプリの設定システムが進化したものであることをご存じないかもしれません。しかし、まず最初に、フィーチャーフラグについて復習する必要がある場合は、「What Are Feature Flags?」という記事をご参照ください。

Feature Flagを使用したキルスイッチは、運用チームやSREチームにはあまり使われていませんが、最も強力な使用例の１つです。多くの人はこの可能性について考えたことがないと思いますが、フィーチャーフラグはエンジニアリング組織を最も変革する方法となり得ます。ソフトウェア開発の速度を上げ、リスクを低減するための素晴らしい方法なのです。

キルスイッチは、アプリケーション内の細かな能力や機能を制御すると同時に、アプリケーション全体に影響を与える長期的な運用スイッチとしても、非常に大きな可能性を持っています。また、フィーチャーフラグは直感的にフロントエンドやクライアント向けアプリケーションに影響すると思われがちですが、バックエンドでも同様に使用することができます。ここでは、キルスイッチを活用して、チームがソフトウェアを提供する方法の本質を変える方法を探ってみましょう。

ユースケース１：Feature Toggleによる本番環境での制御

これは、フィーチャーフラグを使ってキルスイッチを実装する基本的なケースだと考えてください。コンセプトはとてもシンプルで、本番環境（あるいはあらゆる環境）にプッシュされたあらゆる機能および変更をトグル、つまりキルスイッチで制御することができるのです。フィーチャーフラグは、その性質上、チームがアプリケーション内の機能を分離し、デプロイメントバンドルとしてではなく、個別に処理できるようにするためのものです。キルスイッチは、チームがいつでも本番環境でのコードを無効にできるようにするための制御を作成する方法です。

トグルを使って、ユーザーに不快な思いをさせないようにしましょう。

この基本的なキルスイッチは、ある機能がまだ準備できていないときに、その機能を停止させることができます。「Not ready」は、開発において２つの意味を持ちます。

1. 未完成の機能であること。
2. 故障した機能であること。

未完成の機能

１つ目、未完成の状態は、デプロイメントプロセスにおいて多くのチームの作業を減速させるものです。特に、多くのチームが異なるアプリケーションの異なる機能に取り組んでいるため、統合とデプロイに長い時間がかかってしまいます。リリースチームとそれを構築したソフトウェア開発チームの両方が、全てを取り込むことができなければ、遅れをとってしまうことになります。

この文脈でフィーチャーフラグをキルスイッチとして使用すると、チームは新しい機能を不完全な機能としてでも本番環境に投入することができ、結果として開発サイクルを短縮することができます。単に本番にプッシュすればいいのですが、キルスイッチを有効にして（機能をオフにして）、実際には何も影響を与えないようにする必要があります。

故障した機能

開発者におなじみのことがあります。それは、全ての開発前環境で動作していたのに、バグが発見され、それが本番環境に影響を及ぼしていることです。フィーチャーフラグを使用しない場合、開発環境に影響を与える故障した機能は、デプロイメントの完全なロールバックが必要になります。つまり、開発環境から全ての優れた機能を撤去し、最後に動作したバージョンに戻さなければなりません。

一方、各新機能や変更にフィーチャーフラグを付けることで、問題が見つかればすぐにキルスイッチを押すことができます。そして、正常に動作する機能は全て開発プロセスに残し、故障した機能は分離し、必要な処理を行います。

ユースケース２：インシデント管理

リリースした機能が壊れてしまい、本番環境に深刻な問題が発生した場合、どうすればよいでしょうか。あるいは、インフラの障害が本番環境全体に波及した場合はどうでしょうか。キルスイッチは、このようなインシデントを軽減し、担当チームのMTTR（平均解決時間）を改善するために使用されることが分かっています。ストレス管理について話してみましょう。

インシデント管理は悪夢になることはないのです。出典

シナリオ１

シナリオ１では、故障した新機能が実運用環境でインシデントを引き起こしています。良い点は、もしその新機能にフィーチャーフラグが設定されていれば、キルスイッチが作動し、その機能をすぐに本番環境で停止させることができ、結果として影響を最小限に抑えることができる点です。その機能が実運用に影響を与えないだけでなく、その問題に対処するために大規模な対応チームを編成する必要もありません。通常であれば、デプロイメント全体を撤収しなければなりません。その代わりに、その機能はオフにされ、担当チームが問題の修正に注力し、機能の修正が１つ完了すればロールフォワードすることができます。

シナリオ２

シナリオ２では、本番で起こりうることの一例としてインフラの障害を挙げます。しかし、本番環境の停止は、さまざまな問題によって起こる可能性があります。多くの場合、運用チームはフォールバックオプションあるいは「全てをオフにする」ためのランブックを用意していますが、ここでもキルスイッチを使用することができます。完全に新しいインフラの変更であれば、その変更全体をフィーチャーフラグで括り、問題が発生したときに古い設定にフェイルオーバーするキルスイッチをトリガーすることができます。また、長期間の運用フラグを作成し、例えばサイト全体やアプリケーションを「メンテナンスモード」にし、アプリケーション全体のキルスイッチを効果的に起動させるチームもいます。これは、P0シナリオで、物事が破綻しており、アクセスを一切許可しないことを希望する場合に有効です。

ユースケース３：アプリケーションの負荷管理

例えば、あなたがeコマース事業を展開しているとします。年末年始は、他の季節に比べて負荷が高くなります。いつも以上に、ダウンタイムが発生したり、顧客に問題が発生したりすることは避けたいものです。この問題を解決するには、フィーチャーフラグが非常に低コストな方法であることが判明しました。

この問題を解決する１つの方法は、単純に負荷を減らす機能をオフにすることです。これはキルスイッチを使うのに最適な場所ですが、最も効果的とは言えないかもしれません。また、ピーク時以外に役立つ特定のロードバランサーやサーバーを停止し、高負荷用に特別に設計されたインフラに切り替えるという解決策もあります。

複雑なインフラのカットオーバーやフェイルオーバーを１つのスイッチで行えるように配線します。

実際の事例

前職では、短期キャッシュからストレージに入る必要のあるログデータがあり、それらを収集・保存するシステムを持っていました。特にAWSの場合、ピークロード時や不安定な時期には、このストレージが非常に高価になったり、信頼性が落ちたりすることがよくありました。そのため、このような期間にはこのサービスを停止していました。しかし、これは手作業であり、停止と再有効化のために一連のAWSコマンドとデータベース変更を必要としました。これをフィーチャーフラグと結びつけることで、より軽量で目に見える、管理しやすい方法で、この機能を瞬時にオフにしたりオンにしたりすることができるようになりました。

ユースケース４：本番環境でのテスト

かつてはジョーク、今は一般的な使用例。出典はこちら

フィーチャーフラグを立てるチームにとって最も一般的なユースケースの１つは、実稼働環境でのテストです。つまり、特定の機能（または機能のセット）を実際の本番データに対してテストする必要がある場合です。結局のところ、非本番環境では、それほど多くのことをテストできないのです。ここでは、２つのユースケースがあります。

1. 機能または変更を実際のデータでテストし、期待通りに動作することを確認する。
2. 実際のユーザーの前で実装を行い、目標にどれだけ合致しているかを確認する。

ここでいうキルスイッチとしてのフィーチャーフラグの使い方は、とてもシンプルなものです。テストが実行されるまでその機能を生かしておき、その後オフにします。また、ある機能がテスト中に失敗し、その影響を最小にするためにオフにする必要がある場合もあります。本番環境でのテストについては、こちらの専用ブログで詳しく解説しています。

ユースケース５：プログレッシブデリバリー

ここでは、プログレッシブデリバリーについての基本的な知識を前提とします。これは、継続的デリバリーでカナリアリリースに使われる方法論と非常に似ており、機能リリースの方法論としてますます人気が出てきています。

プログレッシブデリバリーでは、キルスイッチの必要性が若干変化します。もちろん、主な用途は、壊れたり不要になったりしたものを消すことですが、ここでは、自動化を重ねる必要があるのです。その性質上、プログレッシブデリバリーは、チームが自動化された方法で実行するものです。そのためには、どのようなシナリオでフラグをオンにし、誰に対して、どのような条件でより多くのユーザーがアクセスできるようにするかをあらかじめ定義しておく必要があります。逆に、キルスイッチが作動して新機能がオフになったり、ユーザー数が減少したりするような失敗の基準も定義しておかなければなりません。

Harness Feature Flagsでは、パイプラインによってプログレッシブデリバリーを自動化します。チームは、リリースのスケジュール、承認の義務付け、プラグインとの統合、トリガーイベントの作成、ロールアウトのテンプレート化などを行い、それを自動化することができます。

ユースケース６：パーソナライゼーション

パーソナライゼーションは注目トピックです。フィーチャーフラグを使用したキルスイッチは、これを大規模に行う上で大きな価値を持ちます。ここでは、キルスイッチを利用して顧客の体験をパーソナライズする能力を向上させるための３つのシナリオを紹介します。

コンプライアンスと規制

規制といえば、モバイルアプリのリリースのように、各国の法律に準拠したり、特定の業種（政府、金融など）のクライアントのニーズに合わせて「パーソナライズ」できることは譲れない項目です。その最たるものが、データプライバシー、具体的にはGDPRの遵守です。

そのため、ある場所にはボタンを表示し、別の場所にはボタンを表示しないといった混乱が生じることがあります。主要な機能を永久的なフィーチャーフラグとして配線することで、北米のユーザーには何かをオンにし、GDPRの遵守が義務付けられているヨーロッパのユーザーにはしない、ということが容易にできるようになります。ヨーロッパでのデータ収集を停止させるスイッチを作るだけでなく、オプトアウトすることを決めた全てのユーザーに対してデータ収集を停止させることができるのです。さまざまなシナリオを全て解決しようとする設定ファイルを持つよりも、はるかに簡単です。

ユーザー定義のパーソナライゼーションと管理者設定

これは、ユーザーが使いたい機能を選択できるようにすることだと考えてください。これは、アプリの管理者設定にアクセスできるようにして、ダークモードを選択したり、受け取る通知を選択できるようにするのと同じことです。

フロントエンドでは、ユーザーがアプリでの個人的な体験のために必要なものと不要なものを定義しますが、バックエンドでは、フィーチャーフラグスキーマの一部をエンドユーザーに公開し、何を残し、何を消すかを判断してもらうだけなのです。

また、スクリーンタイムやペアレンタルコントロールのような機能を利用すれば、デバイス上の設定に基づき、特定のアプリケーションへのアクセスを制限することができます。もちろん、このような権限を使用して何を行うかを定義する責任をユーザーに負わせることは、解決すべき全く別の問題です。

Redditをはじめ、多くのアプリでユーザーがセルフパーソナライズできるようになりました。ソースはこちら

Harness Feature Flagsを利用したキルスイッチの実装

Harness Feature Flagsを使用することで、これらのユースケースをすぐに実装することができます。Harnessでフィーチャーフラグを設定すると、ビジュアルUIでもコードでも、キルスイッチを管理することができるようになります。また、ガバナンス、コンプライアンス、セキュリティへの配慮、CI/CD（Continuous Integration and Continuous Delivery）への重要な統合により、キルスイッチの使用やその他のフィーチャーフラグの使用事例を拡張したい場合にも安心です。

結局のところ、ソフトウェアのデリバリープロセスの他の部分と完全に切り離して優れたフィーチャーフラグシステムをセットアップする事態は避けたいものです。フィーチャーフラグプラットフォームによって、アクセスコントロール、セキュリティ、ガバナンス、そして統合のメンテナンスにかかる労力が倍増するのでは、ソフトウェアのデリバリーを加速するという本来の良さを生かせません。

Harnessがどのように組織に合うかを確認したい場合は、永久無料登録、または個別の製品デモのために私たちにご連絡ください。

この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。