Harness Feature Flagsリレープロキシーを深掘り

この記事では、Feature Flagsリレープロキシーについて、アーキテクチャー、キャッシング、使用方法などを詳しく説明します。

リレープロキシーは、インフラストラクチャー内で動作する軽量のGoアプリケーションで、Harnessプラットフォームへの全てのストリーミング接続を処理します。起動時に全てのフラグ、ターゲット、ターゲットグループデータを取得し、キャッシュし、時間の経過とともに更新を取得し、接続された下流SDKに提供します。

全てのクライアント／サーバーがHarnessプラットフォームに直接接続して変更をストリーミングするのではなく、インストールされたプロキシーに直接接続してフラグの更新を受け取ります。プロキシーは、あなたのアカウントにある異なるプロジェクトにまたがる複数の環境への接続をサポートし、直接接続の代わりとすることができます。

アーキテクチャー

標準的なデプロイメント 

プロキシーをインストールせずにHarnessに直接接続することがデフォルトのオプションで、ほとんどのお客様が使用します。

全てのSDKは、Harnessプラットフォームに直接接続します。インフラストラクチャーのサーバーにとって、これはそれぞれにアウトバウンド接続を許可することを意味し、クライアントSDKを消費する顧客（モバイルアプリ経由など）はHarnessからフラグを取得します。
 

プロキシーを使ったデプロイメント

全てのSDKは、内部に配置されたプロキシーサーバーからフラグを取得します。このプロキシーサーバーだけがHarnessとアウトバウンド通信する必要があります。インフラストラクチャーのサーバーSDKは、アウトバウンド接続を必要としません。クライアントSDKは、ネットワークのファイアウォールルールによってプロキシーへのアクセスを許可される必要があります。

使うべきか

プロキシーは、特定のユースケースを支援するために利用できます。小規模なお客様や全ての構成に適しているとは限りません。解決を望んでいるユースケースがあるのでなければ、標準的な接続モデルから始める方がよいでしょう。

ここでは、お客様のセットアップにおいて価値があると思われる利点（それ以外も）をご紹介します。

1. ネットワークトラフィック／接続数の削減

標準的な構成では、実行するSDKインスタンスがHarnessプラットフォームに接続して全ての初期フラグデータを取得し、ストリーミング接続を維持して、その環境に対する更新を受信します。

アーキテクチャーによっては、ネットワーク上に数十台、数百台、あるいは数千台のサーバーがあり、それぞれがアウトバウンド接続を維持し、まったく同じデータの更新を受信することになります。また、各サーバーが外部に接続できる必要がありますが、これは構成セットアップやセキュリティー上の理由で実現不可能な場合があります。

プロキシーを使用すると、Harnessに接続するサーバーは１台だけで、SDKのトラフィックは全てデータセンター内にとどまります。

1. クライアントがHarnessをホワイトリスト登録する必要はない

クライアントSDKを実行している顧客が非常に厳しいセキュリティー要件を持っている場合、彼らはあなたのアプリがサードパーティーの接続を開くことを許可しない場合があります。

プロキシーは、お客様の環境内で実行され、お客様のサービスが属している既存のホワイトリストルールに乗っかることで、この問題を解決することができます。

1. 高可用性

多くのお客様にとって、Feature Flagsの標準構成は、必要な全ての可用性を維持するための十分なセーフガードを持っています。その内容は以下の通りです。

• 高い稼働率
• 接続が失われた場合に備えて、クライアント／サーバーSDKは値をキャッシュする
• 利用可能な接続がない状態で再起動した場合に備えて、サーバーSDKは値をディスクに保存する
• キャッシュや接続がない状態で起動する最悪のケースを想定し、適切なデフォルト値を定義する

しかし、これ以上のものが必要な場合（あるいは外部依存を減らす必要がある場合）には、リレープロキシーのインストールが理想的でしょう。プロキシーは、全ての環境のフラグ、ターゲット、ターゲットグループデータをキャッシュします。つまり、ダウンタイム、ファイアウォールの問題、その他の理由でHarnessプラットフォームへの接続が失われた場合でも、既存および新規に起動したクライアントおよびサーバーSDKの全てに、常に最新のデータを提供し続けることができます。

さらに優れているのは、接続の問題が解決されると同時に、プロキシーが自動的に全ての環境に再接続し、見逃していたアップデートを取得し、通常通り機能し続ける点です。

価格はどのくらいか

プロキシーのインストールと実行には、通常のサブスクリプション以上の料金はかかりません。

ただし、お客様の環境でこの追加サーバーを実行することに関連する運用コストとアーキテクチャーの複雑さは、全てお客様が負担することになります。これには、ホスティングや、追加サービスのセットアップ、設定、監視、最適化にかかる時間が含まれます。

このコストメリットは、セキュリティー意識の高い大企業（政府機関、医療機関、フィンテック企業など）にとって、フィーチャーフラグ機能を使い始めようとする小企業よりも魅力的でしょう。

後で変更できるか

はい。もし疑問がある場合は、まず標準の配置を使用し、ユースケースにメリットがある場合はプロキシーサーバに移行することをお勧めします。

プロキシーを後からインストールする場合、クライアントとサーバーのSDKに必要な変更は、純粋に設定ベースのみです。SDKはHarnessサーバーと通信する代わりに、プロキシーサーバーと通信することができ、現在依存している他の機能は全て同じままです。

例として、Golang SDKインスタンスがプロキシーを使用するよう移行するために必要な変更を以下に示します。 

// communicate with Harness directly

client, err := harness.NewCfClient(sdkKey)

// communicate with your proxy server

client, err := harness.NewCfClient(sdkKey, harness.WithURL(MY_PROXY_URL))

これは、大々的な移行である必要はありません。プロキシーをインストールし、一部のクライアント／サーバをプロキシー経由で実行し、残りはHarnessと直接通信することで、徐々に移行を進め、コストに見合う効果が得られるかどうかを評価することができます。

どのようなキャッシュオプションがあるか

インメモリー

デフォルトでは、プロキシーはフラグデータをメモリにキャッシュします。これはトライアル期間には便利ですが、実稼働環境では推奨しません。プロキシーは、Harnessとの接続が確立して最初の同期が完了するまで、 再起動時にフラグデータにアクセスすることができません。

Redis

キャッシュされたデータの永続的な保存先としてRedisがサポートされており、これが推奨されるオプションです。プロキシーを再起動すると、同期が完了するのを待つ間に最新のデータにアクセスできるようになります。

どこで試せるか

• 今すぐHarness Feature Flagsのトライアルにお申し込みください。
• プロキシーのドキュメントとインストール方法をご確認ください。

Feature Flagsのレベルアップを検討されているとのことで、大変うれしく思います。私たちがどのようにフィーチャーフラグ機能を実装するかについては、フィーチャーフラグをどのように大規模パフォーマンス向けに設計したかをご覧ください。

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