翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
AWS AppConfig ブラウザとモバイルの使用に関する考慮事項
機能フラグを使用すると、アプリケーションストアリリースのオーバーヘッド、リスク、または剛性なしに、ウェブページとモバイルアプリケーションのエクスペリエンスをその場で更新できます。機能フラグを使用すると、選択した時点でユーザーベースに変更を徐々にリリースできます。エラーが発生した場合は、ユーザーが新しいソフトウェアバージョンにアップグレードすることなく、変更をすぐにロールバックできます。つまり、機能フラグにより、アプリケーションに変更をデプロイする際の制御と柔軟性が向上します。
以下のセクションでは、ウェブページとモバイルデバイスで AWS AppConfig 機能フラグを使用する際の重要な考慮事項について説明します。
設定データとフラグの取得
ブラウザとモバイルのユースケースでは、多くのお客様がウェブまたはモバイルアプリケーションと の間にプロキシレイヤーを採用することを選択します AWS AppConfig。これにより、 AWS AppConfig 通話量がユーザーベースのサイズから切り離されるため、コストが削減されます。また、 AWS AppConfig エージェントを活用してフラグの取得パフォーマンスを最適化し、マルチバリアント flags などの機能をサポートすることもできます。 を使用してプロキシ AWS Lambda を作成する AWS AppConfig ことをお勧めします。フラグを直接取得する代わりに AWS AppConfig、AWS AppConfig Lambda 関数内の機能フラグを取得するように Lambda 拡張機能を設定します。イベントリクエストから AWS AppConfig の取得パラメータを受け入れ、対応する設定データを Lambda レスポンスに返す関数を記述します。Lambda 関数 URLs。
プロキシを設定したら、データを取得する頻度を考慮します。モバイルユースケースでは、通常、高頻度ポーリング間隔は必要ありません。アプリケーションがプロキシから更新するよりも AWS AppConfig 頻繁にデータを更新するように AWS AppConfig エージェントを設定します。
認証と Amazon Cognito
Lambda 関数 URLs、 AWS_IAMと の 2 つのアクセスコントロール形式をサポートしていますNONE。Lambda 関数に独自の認証と認可を実装NONEする場合は、 を使用します。 NONEは、ユースケースでエンドポイントを公開することを許可し、設定データに機密データが含まれていない場合にも推奨されるオプションです。その他のすべてのユースケースでは、 を使用しますAWS_IAM。
重要
認証なしでエンドポイントをインターネットに公開する場合は、個人を特定できる情報 (PII)、ユーザー IDs、未公開の機能名などの機密データが設定データに漏れないようにしてください。
を使用する場合はAWS_IAM、Amazon Cognito で認証情報を管理する必要があります。Amazon Cognito の使用を開始するには、ID プールを作成します。ID プールを使用すると、認証されたユーザーまたはゲストユーザーのために、短期認証情報をアプリケーションに供給できます。ユーザーが Lambda 関数InvokeFunctionUrlに を使用できるようにするロールを ID プールに追加する必要があります。これにより、アプリケーションのインスタンスは、設定データを取得するために必要な認証情報にアクセスできます。
アプリケーションで Amazon Cognito を使用する場合は、 の使用を検討してくださいAWS Amplify。Amplify は、 とのモバイル/ウェブアプリケーションのやり取りを簡素化 AWS し、Amazon Cognito の組み込みサポートを提供します。
キャッシュ
を使用する場合は AWS AppConfig、常に設定データをデバイスまたはブラウザでローカルにキャッシュする必要があります。キャッシュには以下の利点があります。
-
レイテンシーとバッテリードレインを削減してパフォーマンスを向上
-
ネットワークアクセスへの依存関係を排除することで安定性を実現
-
データ取得頻度を減らすことでコストを削減
モバイルユースケースでは、インメモリキャッシュと永続オンデバイスキャッシュを実装することをお勧めします。インメモリキャッシュから必要な設定を取得しようとし、必要に応じてプロキシからの取得にフォールバックするようにアプリケーションを設定します。プロキシから正常に取得されたら、インメモリキャッシュを更新し、設定をデバイスに保持します。バックグラウンドプロセスを使用してキャッシュを反復処理し、各設定を更新します。アプリケーション起動後に初めて設定を取得する場合、取得に失敗した場合は、永続設定に延期します (それを使用してインメモリキャッシュをシードします）。
セグメンテーション
機能フラグを使用する場合、機能フラグ付けエクスペリエンスを顧客ベース全体でセグメント化できます。そのためには、フラグの取得呼び出しにコンテキストを指定し、提供されたコンテキストに基づいて機能フラグのさまざまなバリアントを返すようにルールを設定します。たとえば、iOS 18.X ユーザー用の機能フラグバリアント、iOS 17.X ユーザー用のバリアント、および他のすべてのバージョンの iOS 用のデフォルトフラグがあるとします。バリアントを使用すると、同じ環境で同じ設定をターゲットにするようにアプリケーションのすべての iOS バージョンを設定できますが、取得呼び出しで指定されたコンテキスト (「バージョン」：「iOS18.1」など) に基づいて、デバイスは設定の適切なバリアントを受け取ります。
注記
モバイルユースケースで AWS AppConfig 機能フラグバリアントを使用している場合は、 AWS AppConfig エージェントとプロキシを使用して機能フラグを取得する必要があります。
AWS AppConfig エージェントを使用して機能フラグを取得しない場合は、環境を活用して AWS AppConfig シンプルで低カーディナリティのセグメンテーションを行うことができます。環境は、ターゲットの論理デプロイグループです。設定を開発、テスト、本番環境に分割するだけでなく、デバイスタイプ (タブレットと電話) や OS メジャーバージョンなどのモバイル固有の環境を作成することで、顧客ベースを分割できます。個別の環境では、同じまたは異なる設定データのセットをデプロイして、顧客ベースの特定の要件を満たすことができます。
帯域幅 (モバイルユースケース）
一般的に、各フラグセットのサイズを小さくすることを目指します。モバイルユースケースでは、低帯域幅の制約が伴う傾向があります。データのサイズを最小限に抑えることで、ユーザーベース全体で一貫したエクスペリエンスを維持できます。また、モバイルデバイスは多くの場合、低帯域幅環境と無帯域幅環境の間で動作するため、デバイス上のキャッシュが重要です。設定データを取得できない場合に正常に失敗するアプリケーションコードも重要です。
その他のフラグのユースケース
機能フラグの機能は、機能リリースの利便性を超えて拡張されます。長期運用フラグを使用して、アプリケーションの運用体制を改善できます。たとえば、イベント中に追加のメトリクスを発行し、データをデバッグするパフォーマンスモニタリングトグルを作成できます。または、顧客ベースのセグメントのアプリケーション更新レートを維持および調整することもできます。
