なぜフィーチャーフラグを使うとコンプライアンスと安全性が確保できるのか？

フィーチャーフラグは本当に安全なのでしょうか？はい、もちろんです。特に、セキュリティーを考慮して作られた製品を使う場合は安全です。

もしあなたがフィーチャーフラグについてよく知っているなら、フィーチャーフラグが製品デリバリー組織全体のステークホルダーにとって多くの利点があることは既にご存知でしょう。この記事では、その全てを網羅するつもりはありません。今回は、フィーチャーフラグを採用する際によくあるつまずきと、この問題を解決するためにHarness Feature Flagsがどのように構築されたかを紹介します。フィーチャーフラグを初めて使う方は、フィーチャーフラグ入門を読むことをお勧めします。

さて、今回取り上げるこの共通の問題とは何でしょうか？もちろん、アプリケーションのパフォーマンスやセキュリティーを気にする人の存在です。いつも邪魔をしてくる！念には念を押して、ね。機能フラグはコードの中で動作するので、深刻な依存関係、さらにはリスクとみなされることがあるのです。ですから、Harnessでフィーチャーフラグを作り始めたときから、そのことに真剣に取り組んできました。私たちは、お客様のアプリケーションに影響を与えず、上流への依存をなくし、リスクをゼロにすることを目標にしました。

なぜフィーチャーフラグを気にする人がいるのか？

では、なぜフィーチャーフラグが危険視されるのでしょうか。いくつか理由があります。

• コードの中で実行されるため。
• 設定変更を取得するために、外部サービスと通信する必要があるため。
• ユーザーエクスペリエンスがフラグの解決に依存するため。
• 重要なデータを扱うことができるため。

このような懸念は軽視できないので、どのように対処しているかを見ていきましょう。

耐障害性のための設計思想 

Harness Feature Flagsの仕組みは、とてもシンプルです。

1. アプリケーションに、クライアントまたはサーバーのSDKをインストールします。
2. Harnessでフラグを作成します。
3. フラグに設定したルールは、pushイベントまたはpullイベントでSDKに伝達されます。
4. SDKはルールセットをキャッシュすることで、Harnessとの常時通信を回避しています。 

人々が最初に知りたいのは、Harnessがダウンしたらどうなるのか？アプリケーションでの解決は失敗するのか？コード内でフラグをインスタンス化するとき、コード内でデフォルト値を提供することを知っておくことは重要です（方法は、特定のSDKの言語に関するドキュメントを参照してください）。 

このデフォルト値は常に存在するため、SDKがHarnessに到達できず、またキャッシュもない場合でも、SDKは何を評価すべきかの答えを得ることができます。つまり、Harnessはあなたのアプリケーションの上流依存関係にはなりません。

このワークフローに関して次によく挙がるのは、パフォーマンスに関する疑問です。Harnessとやり取りすることで、どのような影響があるのでしょうか？確かに遅延が発生し、アプリケーションのパフォーマンスに影響を与える可能性があります。

嬉しいことに、ローカルSDKのキャッシュのおかげで、Harnessへの通信はフラグルールの更新時のみとなります。このサーバー送信イベントは数百ミリ秒しかかからず、フィーチャーフラグ評価による遅延はそれ以上発生しません。

その結果、アプリケーションの劣化や速度低下、可用性への依存の可能性を排除した、信頼できるアプリケーションアーキテクチャーが実現します。詳しくは、フィーチャーフラグのドキュメントをご覧ください。

プライバシーのための設計思想

耐障害性についてはこの通りですが、もう１つよくある質問がセキュリティーに関するものです。SDKはアプリケーションで動作し、フラグをターゲットにするためにあなたが送信した情報に依存していますが、アプリケーションの情報はどれくらい安全なのでしょうか？

Harnessのフィーチャーフラグの仕組みは以下の通りです。

• SDKをインスタンス化する際に、Harnessにカスタム属性を送信します。メール、場所、計画など、フラグを評価するためのものです。
• Harnessでは、これらの属性に対してルールを構築します。例えば「州」という属性が送られてきたら「テキサスの全ユーザーのフラグをオンにする」というようにです。

このような設計上、Harnessがお客様から提供されない情報にはアクセスしないということが重要です。お客様が出したくない情報をHarnessが知ることはありません。Harness SDKは、お客様がSDKに明示的に渡さない情報を収集したり、Harnessに伝達したりすることはありません。個人情報を一切Harnessに渡さないために、お客様側で抽象化して機密情報をマスキングすることを強くお勧めします。

結論

結局のところ、Feature FlagsやCI/CDのようなツールのベンダーを評価する際に最も重要なことの１つは、信頼です。私たちは、安全でコンプライアンスに準拠した製品を作ることの重要性を理解しています。Harness Feature Flagsは、信頼する必要のあるものを最小限に抑え、あらゆる場合にデフォルトでプライバシーと耐障害性を優先するように構築されています。

より詳細な情報は、いつものように私たちのドキュメントで見ることができます。また、機能フラグに関するセキュリティー上のよくある質問についての記事も書いています。こちらも参考にしてください。

読んでくださってありがとうございます！

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