翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

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 関数 URL を使用して、プロキシをインターネットに公開します。

プロキシを設定したら、データを取得する頻度を考慮します。モバイルユースケースでは通常、高頻度ポーリング間隔は必要ありません。アプリケーションがプロキシから更新するよりも AWS AppConfig 頻繁にデータを更新するように AWS AppConfig エージェントを設定します。

認証と Amazon Cognito

Lambda 関数 の URL は、2 つのアクセスコントロール形式、AWS_IAM と NONE をサポートしています。Lambda 関数に独自の認証と認可を実装する場合は、NONE を使用します。エンドポイントを一般公開することを許可し、設定データに機密データが含まれていないユースケースでは、NONE も推奨されるオプションです。その他のすべてのユースケースでは、AWS_IAM を使用します。

AWS_IAM を使用する場合は、Amazon Cognito で認証情報を管理する必要があります。Amazon Cognito の使用を開始するには、アイデンティティプールを作成します。アイデンティティプールを使用すると、認証されたユーザーまたはゲストユーザーのために、短期認証情報をアプリケーションに発行できます。ユーザーが Lambda 関数の InvokeFunctionUrl を使用できるようにするロールをアイデンティティプールに追加する必要があります。これにより、アプリケーションのインスタンスは設定データを取得するために必要な認証情報にアクセスできます。

アプリケーションで Amazon Cognito を使用する場合は、AWS Amplify の使用を検討してください。Amplify は、 とのモバイル/ウェブアプリケーションのやり取りを簡素化 AWS し、Amazon Cognito の組み込みサポートを提供します。

キャッシュ

を使用する場合は AWS AppConfig、常に設定データをデバイスまたはブラウザでローカルにキャッシュする必要があります。キャッシュには以下の利点があります。

モバイルユースケースでは、インメモリキャッシュと永続オンデバイスキャッシュを実装することを推奨します。インメモリキャッシュから必要な設定を取得しようとし、必要に応じてプロキシからのフェッチにフォールバックするようにアプリケーションを設定します。プロキシから正常に取得されたら、インメモリキャッシュを更新し、設定をデバイスに保持します。バックグラウンドプロセスを使用してキャッシュを反復処理し、各設定を更新します。アプリケーションスタートアップ後に初めて設定をフェッチする際、取得に失敗した場合は、永続設定に従います (それを使用してインメモリキャッシュをシードします)。

セグメンテーション

機能フラグを使用する場合、機能フラグ付けエクスペリエンスを顧客ベース全体でセグメント化できます。そのためには、フラグの取得呼び出しにコンテキストを指定し、提供されたコンテキストに基づいて機能フラグのさまざまなバリアントを返すようにルールを設定します。例えば、iOS 18.X ユーザー用の機能フラグバリアント、iOS 17.X ユーザー用のバリアント、および他のすべてのバージョンの iOS 用のデフォルトフラグがあるとします。バリアントを使用すると、同じ環境で同じ設定をターゲットにするようにアプリケーションのすべての iOS バージョンを設定できますが、取得呼び出しで指定されたコンテキスト (「バージョン」:「iOS18.1」など) に基づいて、デバイスは設定の適切なバリアントを受け取ります。

AWS AppConfig エージェントを使用して機能フラグを取得しない場合は、環境を活用して AWS AppConfig シンプルで低カーディナリティのセグメンテーションを行うことができます。環境は、ターゲットの論理デプロイグループです。設定を開発、テスト、本番環境に分割するだけでなく、デバイスタイプ (タブレットと電話) や OS メジャーバージョンなどのモバイル固有の環境を作成することで、顧客ベースを分割できます。個別の環境では、同じまたは異なる設定データのセットをデプロイして、顧客ベースの特定の要件を満たすことができます。

帯域幅 (モバイルユースケース)

一般的に、各フラグセットのサイズを小さく保つことを目指します。モバイルユースケースには、低帯域幅の制約が伴う傾向があります。データのサイズを最小限に抑えることで、ユーザーベース全体で一貫したエクスペリエンスを維持できます。また、モバイルデバイスは多くの場合、低帯域幅環境と無帯域幅環境の間で動作するため、デバイス上のキャッシュが重要です。設定データを取得できない場合に正常に失敗するアプリケーションコードも重要です。

その他のフラグのユースケース

機能フラグのパワーは、機能リリースの利便性を超えて拡張されます。長期運用フラグを使用して、アプリケーションの運用体制を改善できます。例えば、イベント中に追加のメトリクスを発行し、データをデバッグするパフォーマンスモニタリングトグルを作成できます。または、顧客ベースのセグメントのアプリケーション更新レートを維持および調整することもできます。