AKAMAI ホワイトペーパー

最新の展開手法を活かして商戦日の トラフィックに備える

フィーチャートグルとダークリリース

著者：Manuel Alvarez, Enterprise Architect, Global Consulting Services, Akamai

フィーチャートグルとダークリリース：最新の展開手法を活かして商戦日のトラフィックに備える 1

2 つめの、テストする時間が十分にとれない場合のリスクを考慮し、現在のマネージャー（製品マネージャー、スクラムマスター、またはタイムラインを監督するその他の管理者）はリリース日よりかなり前に締め切りを設定します。しかし、それでもコードまたは機能が間に合わなくなることもあります。そのような場合は 2 つの方策のどちらを選ぶか決めなければなりません。1 つは、その機能をリリースせず、マスターブランチからそのコードを削除し、部分的に機能する状態でリリースする方法（一部のスプリントケースに該当）。もう 1 つは、問題となっているコードも本番環境にリリースしますが、実行できないように機能を隠しておく方法です。

機能を隠してリリースした場合は、さらにもう 1 つ問題が生じます。そのコードが完成しても、本番環境でのテストやリリースができなくなります。この問題を解決するソリューションがダークリリースです。ダークリリースでは、そのコードまたは機能を隠した状態でリリースし、開発者だけが知っている認証 cookie を使用するなど、秘密の手段を使った場合にのみ有効になるようにします。ほかにも、新旧両方の環境を本番稼働できる状態にするブルー／グリーン展開方式や、サービスとしてのインフラストラクチャを使用して本番環境をテスト用にスピンオフする方法もあります。しかし、たとえ本番環境のコピーをスピンオフしたとしても、本番でのテストの代用になるとは思えません。なぜなら、テストスクリプトやテストケースと違って、実際のユーザーは予測不可能な行動をするものだからです。

ダークリリースとフィーチャートグルいずれにしても、早期のコードリリースが困難でリスクの高い目標であっては困ります。ごく普通にできることであってほしいものです。Jez Humble 氏はこう言っています。

「ユーザーが利用できるようにする前にソフトウェアを本番環境に展開することは可能ですし、そうすべきです。そうすれば、スモークテストはもちろん、キャッシュのウォームアップを待つといったその他のタスクも実行できます。スモークテストの目的は、正常な展開を確認すること、特に本番環境用の設定（データベースの接続ストリングなど）が正しいかどうかのテストです」。

ダークリリースで重要なのは、機能をリリースできることや、アプリケーションコードを変更しなくてもシステムの振る舞いを変更できる点です。このテクニックはフィーチャートグルまたはフィーチャーフラグと呼ばれています。このテクニックを使用すれば、ダークリリース（新機能に誰もアクセスできない状態）とライブリリースの間の切り替えが可能になります。

フィーチャートグルの課題フィーチャートグルの鍵となるのは、適切な「権限者」だけしかアクセスできないようにすることです。この権限者には、開発者、承認マネージャー、外部関係者、または自動化条件（日付／時間の一致）などが該当します。

たとえば、Tesla Model 3 は、強化されたオートパイロット機能（および近い将来実現される完全自動運転機能）に必要とされるハードウェアがすべて搭載された状態で販売されます。この機能は、無線でソフトウェアをダウンロードすることによって有効になります。つまり、出かけて行かなくても、電話をしてクレジットカードを使用すれば、この機能を取得できます。

私が言いたいのは、Tesla のエンジニアリングに関する知見ではなく、強化オートパイロット機能を有効にするコードの展開方法として、Tesla には 2 つのオプションがあるということです。1 つは、もちろん、ソフトウェア全体（数 GB になる可能性があります）を車にダウンロードすることを求める方法です。そしてもう 1 つはオフにしてあるフィーチャートグルを使用して、ハードウェアで実行するようなコードを展開する方法です。コードの統一性が維持され（機能の有無によって生じる複数のソフトウェアバージョンを維持しなくてもよい）、追加ダウンロードも不要である点を考えると、2 つめの方法の方が理にかなっているように思えます。しかし、この方法には課題もあります。

問題点 開発者がキャンプファイアーを囲んで、またはバーに集まって話をするとき、異口同音に語られる怖い話といえば ...自分のローカルマシンや開発環境で機能していたコードが本番環境にリリースした当日にクラッシュしたという経験です。そして、「本番環境でテストする方法がなかった」とか、「72 時間眠らずに作業をして本番当日にようやくコードを間に合わせたので十分にテストする時間がなかった」という話に落ち着くのがお決まりの展開です。

フィーチャートグルとダークリリース：最新の展開手法を活かして商戦日のトラフィックに備える 2

• 改ざんされたり不正利用されたりしないようにトグルのセキュリティを確保するにはどうすればよいでしょうか？

• この機能を有効にするためのアクセス権は、良く知られているセキュリティの AAA、つまり、認証（Authentication）、許可（Authorization）、アカウンティング（Accounting）に対応していなければなりません。

• 誤ってトグルが削除されたり無効化されたりしないように、適切なガバナンスが必要です（回帰テストでのテストケースなど）。

• シンプルであること、そして複数の部署全体の協力も必要です。この例では、承認側（電話で対応するサポートスタッフやセールススタッフ）は異なる部署に属し、技術者ではない場合もあります。したがって、トグルの変更は承認者がよく知っている使いやすいインタフェースを使用して実行できなければなりません。

これらの課題に加え、実装の分散、ダーティコード、フィーチャートグルのカスケードも懸念材料となります。トグルをコードに実装するのは簡単ですが、これを保守するのは容易なことではありません。機能をライブにしたら、再度作業に戻り、未使用のトグルを削除しておかないと、どれを有効にしたのかわからなくなります。

CI や CD では、本番環境へのリリースを必要とせずに機能を継続的に展開する方策として、フィーチャーフラグがよく利用されています。このテクニックはウェブイベントやマーケティングキャンペーンにも大いに役立ちます。数週間前にアセットをリリースし、適切なタイミングにライブになるようにトグルにスケジュールを設定しておくことができます。

CDN におけるフィーチャートグルCDN はアプリケーションやウェブ資産の最前線にあり、中央集中型の決定を可能にします。詳細な権限付与制御の自動化ツール（API サポート、日付の一致など）によって、フィーチャートグルに関連した制御やガバナンスの実装能力が強化されます。ここでは、Akamai がつけた機能名を使います。ご利用の CDN の機能や製品を調べて、そのエコシステムでの正確な名称を確認してください。

私は、一部を除いた残りのコードリリースをライブにするのではなく、メタデータのダークリリースの方がよいと考えていますが、その理由は次のとおりです。

• リスクの軽減：ダークリリースにすれば、顧客に影響を与えずに本番環境でテストすることができます。

• 簡単な実装：フィーチャートグルの実装は常に簡単であるとは限りません。CDN を利用すれば、着信する HTTP リクエストやクライアントの特性（デバイス、ロケーションなど）のうち、ほとんどすべてのものとの照合が可能になります。そのため、コード／インフラストラクチャを変更しなくても、複雑で固有の一致条件を定義できます。

• 統合性：API を使用することで、トグルの制御とリリースを、ご使用の CI／ CD ツールと統合できます。

• 制御性：役割およびユーザーに基づく許可により、設定変更やフィーチャートグルの有効化などの変更操作ができるアクセス権限者を制御できます。組織のニーズに応じた許可の制限と開放が可能となります。

• 可視性：新しい機能のローンチには常に大きな期待がかかります。何かが想定どおりに動かないかもしれないという怖さもあります。機能と同じ一致条件に基づいて新しい Content Provider Code（CP コード）を追加すれば、トラフィックを追跡し、レポートの的を絞ることができます。新しい CP コードには、定義されたしきい値に到達するとタイムアウトやエラーレスポンスなどのエラーを通知するオリジンアラートを設定できるというメリットもあります。

CDN を使用したダークリリースの方法フィーチャートグルに CDN を活用する方法はいくつかあります。

新しい URL パスまたは API

CDN をリバースプロキシとして使用し、リクエストに代替コンテンツを提供することができます。リリースする機能を新しい URL でライブにする場合、その新しい URL へのリクエストは代替ロケーション（イベント広告のマーケティングページなど）に送信するようにして、その URL へのアクセスは限定されたユーザー（開発者、テスターなど）のみに許可するのが最善の選択肢です。Akamai では、この機能を Visitor Prioritization（VP）または API Prioritization と呼んでいます。この機能を使用すると、リリースの準備が完了するまで、その URL を効果的に隠すことができます。この機能を利用するメリットは次のとおりです。

• 変更がほぼ瞬時に伝播されます。

• 機能へのアクセス権限を付与する人数など、きめ細かく制御できます（cookie の一致によって、特定の地域を対象とすることも、また無作為にすることも可能です）。

フィーチャートグルとダークリリース：最新の展開手法を活かして商戦日のトラフィックに備える 3

• 強力な API を使用することで、自動化やお客様の環境との統合が可能となります。

• ウェイティングルーム（トグルがオフの場合にクライアントが受信するレスポンス）にさまざまなオプションがあります（API カタログへのリダイレクト、魅力的なマーケティングページの提供など）。

以下はフローと制御を示した図です。

この他に、ユースケースによっては、以下の「組み込まれた機能」に記載する任意のオプションも使用できます。

組み込まれた機能URL パターンの照合ができない場合は、メタデータ（CDN 設定）での照合が必要となります。場合によっては、新機能にメタデータの変更が必要となることもあります。たとえば、新しい CMS やテクノロジースタックへの移行では、たいてい元の設定値の更新が必要となります。

このような場合、設定を構築し、別の方法でダークリリースを行うことができます。一般的に使用されているのは、変数を使用して動作の ON と OFF を設定する方法です。この変数のデフォルト値は FALSE です。開発者、テスターなど、アクセス権限の付与対象者は、秘密の cookie、IP ACL、または Edge 認証を使用することで、この制御を迂回できます。もちろん、機能をリリースすれば、この変数は ON になります。お客様の組織のほとんどのアーキテクチャ設計は文書化されていると思いますが、それと同様に、機能、その仕組み、変更方法は必ず文書化する必要があります。ダークリリースのサポートや保守について、主な担当者の考えや口頭でのやりとりに依存するのはよくありません。

最近は、標準でサポートされ、十分に文書化されている CDN 機能を活用するケースが増えています。つまり、カスタム設計の実装ではなく、製品を使うということです。ブルー／グリーン開発方式を採用しているお客様は、「オリジン」を切り替えて新しいコードをリリースします。CDN には、API やインタフェースを使用して即座にオリジンを変更する機能があります。重要なのは、ブルーとグリーンの両方のオリジンを同じ DNS エンドポイントに定義し、CDN のオリジン分割機能をフィーチャートグルとして活用できるという点です。新しい開発はトラフィックのないオリジンに実装されるので、ユーザーが事前にリリースを見ることはありません。Akamai では、この機能を Phased Release Cloudlet と呼んでいます。新リリース機能は、Cloudlet Origin 内に実装し、一部のトラフィックだけに適用されるようにすることが可能です。

以下の図は、このオプションのフローを示したものです。Phased Release は、開発者によって、または API を使用したオペレーションによって制御され、任意のアーキテクチャ管理ツールまたは展開ツールと統合できます。

いずれの方法を採る場合も、以下の点に留意してください。

1. 変数やオリジンには意味のある名前を使用します。これにより、混同するリスクが軽減され、整理しやすくなります。たとえば、ブルー／グリーン開発方式では新旧の混同が起こりがちです。

2. リリースが正常に完了したら、コードを整理し、ON のままになるフィーチャートグルを削除することを強く推奨します。1 つのリリースに複数のトグルがあり、過去のリリースのトグルと結合されているというようなケースも珍しくはありません。このような場合、現在ライブになっているものの判別が難しくなります。とにかく消去しておくことが重要です。これは間違いを避けるために大いに役立ちます。

User

EdgeServer

DeveloperTrafficControl

CloudStorage

Origin

フィーチャートグルとダークリリース：最新の展開手法を活かして商戦日のトラフィックに備える 4

3. cookie を使用してお客様の組織内のチームにアクセス権を付与するのが最も簡単な方法です。cookie を設定するための内部用のウェルカムページを用意して、QA、サポート、ビジネスパートナーが手動で cookie を追加しなくてもアクセス権を取得できるようにすることもできます（cookie の追加方法がわからないマネージャーもたくさんいます）。

注：cookie は安全なメカニズムではないので、外部に情報が漏えいするリスクによってビジネスや営業に重大な影響が及ぼされる可能性がある場合は推奨できません。

4. 知名度の高いイベントの場合は、地理的地域、ランダム一致、顧客カテゴリー（プレミアユーザーなど）、またはデバイス（デスクトップユーザーなど）に基づいてアクセス権を付与することで、緩やかにスイッチを切り替えるようにしてください。

5. 常にロールバックできるようにしておきます。偶然の出来事やバグが生じた場合に備えて、いつでも元に戻せるようにしておく必要があります。

6. 高速アクティベーションまたはリモートコントロールで機能を有効にします。高速アクティベーションでは、スイッチの値が変更された新バージョンを数分でアクティブにすることができます。リモートコントロールでは、瞬時に変更が可能です。

7. プロセスを自動化します。CDN 制御を、ご使用のリリースツールやプロセスと統合してください。ただし、自動化プロセスを変更する能力は維持する必要があります。これは、フィーチャートグルの変更に使用する API の文書化のように簡単な場合もありますが、キルスイッチのコーディングのように複雑になる可能性もあります。

Akamai の設計設計パターンが円熟していれば、新エンドポイント（URL）で新機能をリリースし、Akamai をプロキシとして使用して、古い SEO 対応パスを新機能のパスに替えることができます。前述のように、変数を使用することで、いつ誰が新機能にアクセスできるようになるかを制御できます。

ご質問があれば、詳しくご説明します。また、お客様自身のユースケースに応じた最善のオプションについても お話しさせていただきます。ぜひ Akamai アカウントチームにお問い合わせください。または E メールで consulting@akamai.com までご連絡ください。

User

EdgeServer

DeveloperFeatureToggle

Origin

Akamai は世界で最も信頼された世界最大のクラウド配信プラットフォームを提供しています。使用するデバイス、時間、場所を問わず、お客様が安全性に優れた最高のデジタル体験を提供できるようにサポートします。Akamai の大規模な分散型プラットフォームは、世界 130 か国に 20 万台を超えるサーバーを擁する比類のない規模を誇り、お客様に優れたパフォーマンスと脅威からの保護を提供しています。Akamai のポートフォリオに含まれる、ウェブおよびモバイルパフォーマンス、クラウドセキュリティ、エンタープライズアクセス、動画配信の各ソリューションは、卓越した顧客サービスと 24 時間体制の監視によりサポートされています。大手金融機関、EC リーダー企業をはじめ、メディアおよびエンターテイメントプロバイダー、政府機関が Akamai を信頼する理由について、www.akamai.com/jp/ja/ または blogs.akamai.com/jp/ および Twitter の @Akamai_GK で詳細をご紹介しています。全事業所の連絡先情報は、https://www.akamai.com/jp/ja/locations.jspをご覧ください。2017 年 10 月発行。