※このブログはTips for Developing High Performance Alexa Skillsの翻訳です。
音声インターフェースを開発する場合、応答速度が重要になります。通常、あなたが友人と会話する際、友人から早い応答があれば、あなたの話をきちんと聞いてくれていると安心することができるでしょう。同じように、お客様はAlexaと話すとき、Alexaから素早い応答が返ってくることを期待しています。Alexaスキルでお客様を引きつけ、関心を維持するには、ハイパフォーマンスが重要です。
このブログでは、AWS LambdaのベストプラクティスのリストとハイパフォーマンスなAlexaスキルを作成するために欠かせないAmazon DynamoDBおよびAmazon S3のリソースを紹介します。
あなたのニーズ、スキルのトラフィック、異なるリージョンによる可用性などに応じて、特定された問題に関連するベストプラクティスを実装し、全体的なユーザー知覚遅延(UPL:User Perceived Latency)を改善します。
もう一度学び直したい場合や、基本的な概念を知りたい場合は、AWS Lambda の使用開始とAlexa で AWS Lambda を使用するをご覧ください。
AWS Lambda
ヒント1: 適切なメモリ容量を割り当てることでAlexaスキルの遅延を改善させる
Lambdaは、関数に割り当てるメモリに比例してCPUを割り当てます。割り当てるメモリ容量が1.8GBを超える場合、複数のCPUが割り当てられます。 関数のメモリ量を選択するときは、以下のことを考慮してください。
関数がメモリまたはCPUにバインドされているかどうか。CPUを集中的に利用する関数の場合、より多くのメモリを割り当てておくと、割り当てられたすべてのメモリが使用されていなくても、関数が高速で実行され、コスト削減につながります。
コードと選択した言語によって、マルチコアプロセッシングの恩恵を受けるかどうか。マルチスレッドを使用しない場合、1.8GBを過ぎても改善が得られない場合があります。異なるメモリ値で関数をテストし、メモリ使用量と実行時間を比較して、最適なメモリ量を特定することが重要です。
ヒント2: 関数のタイムアウトを調整する
AWS Lambda関数のタイムアウト値は8秒未満である必要があります。これは、スキルが応答を返すまでAlexaが待機する最大時間です。
Lambdaスケーリングを処理するよう設定されていない他のサービスへのAPIコールを使って、関数の実行にかかる時間を把握し、問題を特定するためにスキルの負荷テストを実行します。
過剰なタイムアウトの設定によって、関数の実行時間が長くなり、結果として同時実行の要件とコストが増加する可能性があることに注意してください。
ヒント3: 同時実行数を制限してリクエストのスロットリングを回避する
あなたのAlexaスキルが使用するAWS Lambda関数は、ユーザーがスキルと対話するとき、イベントがスキルにディスパッチされたとき、または別のサービスによって呼び出されたときにリクエストを受信します。同時実行数とは、Lambda関数へのリクエストを同時に処理できるインスタンスの数を指します。 AWSアカウントにはデフォルトで、リージョン内のすべての機能で1,000回の呼び出しの同時実行制限があり、Lambdaはこの制限を超えるとリクエストのスロットリングを開始します。同時実行数の適切な値は、以下の式を使用して要件を推定します。
同時実行数 = 1秒あたりのリクエスト数 * 関数の実行時間
ConcurrentExecutions、Invocations、Duration といったCloudWatch の AWS Lambda メトリクスを使用して同時実行数を監視できます。また、メトリクスのしきい値を超えた場合に通知を受けるようにCloudWatchアラームを設定し、コストを監視するためにAWS Budgetを設定することもできます。同時実行数がデフォルトの制限を超える場合は、サポートセンターコンソールでリクエストを送信して、それを増やすことができます。また同時実行数のリサーブを使用して、実行数を制限し、関数呼び出しのサービスまたはデータベースに対するスケーリングとダウンストリームの影響を制御することができます。
ヒント4: 遅延を改善するためにキャッシュを追加する
ユーザーのリクエストに対する応答をキャッシュすることで、Lambda関数の呼び出し回数を減らし、スキルの待ち時間を改善することができます。こちらのブログ投稿を読んで、データを保存し、より速く応答できるようにAPI GatewayをパススルーAPIサーバーとして使用する方法を見つけてください。
ヒント5: クロスリージョンコールを避ける
ここでは、米国およびドイツで利用可能なスキルを想定します。これは米国東部 us-east-1 (バージニア北部) AWSリージョンにデプロイされたLambda関数を指定しているとします。ドイツのスキルユーザーは、スキルリクエストがスキルのLambda関数がデプロイされているリージョンからus-east-1へのリージョン間コールをトリガーするため、米国に比べて応答時間が長くなる可能性があります。
クロスリージョンコールは、スキルの遅延を増加させる可能性があります。複数の地理的エリアで利用できるスキルの場合、Alexaがサポートする最も近いAWSリージョンでLambda関数を作成することをお勧めします。開発者コンソールでスキルエンドポイントを構成する場合、各リージョンで使用されるARNを入力します。 たとえば、米国とドイツの場合、北米ではus-east-1のARN、ドイツではeu-west-1のARNが必要です。
ヒント6: 関数コードを最適化する
AWS Lambda関数を使用するためのベストプラクティス-関数コードに従ってください。 スキルでは、1.8GBを超えるメモリ（マルチコア処理）を使用しない限り、フロントエンドから全てのノンブロッキングコードを取り除くことを検討してください。
ヒント7: コールドスタートに対処してユーザーエクスペリエンスを向上させる
コールドスタートとは、Lambda関数がスキルへの最初のリクエストを処理するのに必要な時間で、その間にスキルのコードをダウンロードし、新しいコンテナーを開始し、ランタイムをブートして、スキルの関数を開始します。言語の選択、パッケージサイズ、およびコードがすべて影響します。コールドスタート時間を改善するには、以下のことを検討します。
関数コードの最適化: コードが最適化されていない場合、コールドスタート時間が長くなる可能性があります（前述のヒント6も参照してください）。
Lambdaパッケージファイルを削減: ASK SDKまたはAWS SDKに依存関係を追加するときは、完全なSDKではなく、必要なモジュールまたはサービスのみを選択します。SDKや他のライブラリなどの共通コードを共有する複数のスキルがある場合は、それらをAWS Lambdaレイヤーに移動し、デプロイパッケージから除外ですることができます。
割り当てメモリの追加: これによりCPU容量が増加し、コールドスタート時間が短縮される場合があります。
Javaを使用している場合は、Running APIs Written in Java on AWS Lambda のブログ投稿を参照してください。
Amazon Simple Storage Service (S3)
S3でファイルをホストする場合、AWS Lambda関数とS3の間のクロスリージョンコールは、レイテンシの観点からコストがかかる場合があります。 S3バケットがLambda関数と同じリージョンにあることを確認し、複数のリージョンでホストしている場合は、各リージョンにS3バケットを作成します。 リージョン間レプリケーションを使用して、異なるリージョンでコピーを維持できます。 それでも問題が解決しない場合は、ファイルのサイズを確認し、大きすぎる場合はサイズを小さくしてください。 オーディオファイルの場合、さまざまなコーデックとオーディオ圧縮技術を使用し、必要に応じてファイルを小さなファイルに分割し、連続して再生することができます。 それでも遅延が見られる場合は、リージョンエッジキャッシュを活用してパフォーマンスを向上させるAmazon Cloudfrontを使用することもできます。 Cloudfrontの料金も参照してください。
Amazon DynamoDB
データストレージにDynamoDBを使用する場合、テーブルのキャパシティモードを選択するオプションがあります。 トラフィックが一定している場合、または負荷をある程度予測できる場合は、プロビジョニングモード（デフォルト）が推奨されます。 プロビジョニングモードでは、スキルの読み取り/書き込みアクティビティに応じて、スループット容量のデフォルト制限を増減することができます。 オプションで、DynamoDBの自動スケーリングを許可してスループット容量を管理することもできます。 スキルトラフィックの予測が難しい場合、またはトラフィックが急激に増加することが予測される場合は、オンデマンドモードを検討してください。 オンデマンドキャパシティのパフォーマンステストについては、こちらのブログ投稿を参照してください。 パフォーマンスを改善する方法に関するさらなる提案については、DynamoDBのベストプラクティスをチェックしてください。
関連リンク