Parameter Store スループットの管理
Parameter Store スループットは、Systems Manager が処理できる 1 秒あたりの API トランザクション (TPS) の数を定義します。スループット設定は、個々の API ではなく、Parameter Store 全体に適用されます。デフォルトでは、Parameter Store は、少量から中程度のワークロードに適した標準スループットクォータで設定されています。大量のワークロードでは、より高いスループットを有効にできます。これにより、アカウントとリージョンで 1 秒あたりにサポートされるトランザクションの最大数を増やすことができます。必要に応じて、より高いスループットを有効または無効にできます。
Parameter Store のスループットクォータ
次の表に、デフォルトおよび高スループットを使用する API カテゴリ別トランザクション制限を示します。API アクションには、AWS コンソールの使用状況、AWS CLI コマンド、アプリケーションの読み取りが含まれます。クォータとレート制限の詳細については、「AWS Systems Manager エンドポイントとクォータ」を参照してください。
| API アクション | デフォルトのスループット | 高スループット |
|---|---|---|
| GetParameter、GetParameters、GetParametersByPath | 3つのAPIアクション全体で共有される 40 TPS |
GetParameter: 10,000 TPS、GetParameters: 1,000 TPS、GetParametersByPath: 100 TPS |
| DeleteParameter、DeleteParameters | 3 TPS |
5 TPS |
| DescribeParameters、GetParameterHistory、LabelParameterVersion、UnlabelParameterVersion、PutParameter | 3 TPS |
10 TPS |
この文脈において、トランザクションとは、単一のリージョン内の 1 つのアカウントに対する 1 つの API アクションを指します。例えば、次のコマンドはトランザクションを 1 つ作成します。
aws ssm get-parameter --name "/myapp/prod/log-level"
API アクションは複数のアプリケーションに分散させることができます。たとえば、以下の各シナリオではデフォルトのスループット制限である 40 TPS に達します。
-
1 個のアプリケーションが
GetParameter呼び出しを 1 秒あたり 40 回行う。 -
10 個のアプリケーションが
GetParameter呼び出しを 1 秒あたり 4 回行う。 -
40 個のアプリケーションが
GetParameter呼び出しを 1 秒あたり 1 回行う。
スループット制限は、カテゴリ内のすべての API に適用されます。たとえば、次に示す 1 つのアプリケーションに対する同時パラメータ呼び出しの組み合わせは、パラメータ取得 API のデフォルト制限である 40 TPS を満たします。
-
GetParameterが呼び出しを 1 秒あたり 25 回行う。 -
GetParametersが呼び出しを 1 秒あたり 10 回行う。 -
GetParameterByPathが呼び出しを 1 秒あたり 5 回行う。
DescribeParameters 呼び出しには個別のスループット制限があります。1 つのアプリケーションで、標準スループットの全体的な制限を超えることなく、前述の呼び出しを行いながら、1 秒あたり 3 回の DescribeParameters 呼び出しを行うことができます。
標準オペレーション中または高トラフィックの計画期間中に本稼働リクエストがスループット制限を超えた場合は、次の最適化手法を使用してください。
Parameter Store におけるスループットの最適化
Parameter Store が短い間隔で複数のパラメータリクエストを受信すると、アプリケーションでスロットリングが発生する可能性があります。例えば、CloudWatch Logs またはアプリケーションログには、GetParameter、GetParameters、または GetParametersByPath を呼び出すときに SDK によって発生した ThrottlingException エラーまたは RateExceeded エラーが表示されます。それ以外の場合、アプリケーションロジックが API コールを正常に再試行しますが、アプリケーションのレイテンシーは増加します。その結果、アプリケーションの停止、最適ではないユーザーエクスペリエンス、デプロイの失敗、複雑な回避策、開発者の時間の損失が発生する可能性があります。
次のような複数の要因により、アプリケーションが Parameter Store クォータ制限に達する可能性があります。
-
トラフィックの急増により、アプリケーションが急速にスケールアウトします。たとえば、アプリケーションは通常 5 つの Amazon EC2 インスタンスで実行されます。トラフィックが突然増加すると、Amazon EC2 Auto Scaling はさらに 50 個のインスタンスを起動します。各インスタンスが起動時にパラメータを読み取る場合、組み合わされたリクエストがデフォルトのリクエスト制限を超える可能性があります。
-
コンテナサービスは同時に多くのタスクを開始します。例えば、Amazon ECS サービスは更新中に多くの置換タスクを開始することがあり、各タスクは起動時に Parameter Store から設定を読み取ることがあります。
-
Lambda 関数は、同時に多くのリクエストを受信します。例えば、Lambda は増加したトラフィックを処理するために多くの関数環境を起動することがあります。各関数環境は、起動時にパラメータを読み取ることがあります。
-
ビルドまたはリリースプロセスは、短時間で多くのパラメータを読み取ります。例えば、ビルドジョブが複数のアプリケーションまたは環境の設定を読み取ることがあります。
-
アプリケーションは多くのパラメータをパスごとに読み取ります。例えば、アプリケーションは、必要な特定のパラメータのみを読み取るのではなく、
/myapp/prod/のすべてのパラメータを繰り返し読み取ります。これらの反復リクエストは、デフォルトのリクエスト制限を超える可能性があります。
Parameter Store スロットリングには、次の補完的な方法で対処できます。
-
スループットの削減
アプリケーションが、必要以上のデータを取得したり、非効率的な方法で取得したりしている可能性があります。
-
より高いスループットの有効化
指定したリージョンとアカウントのスループットクォータを増やすことで、アプリケーションの耐障害性を高めることができます。トラフィックが多い期間は、高スループット設定をいつでも有効または無効にできます。スロットリングエラーが定期的に生成される本番ワークロードの場合は、設定を完全に有効にすることを検討してください。
Parameter Store におけるスループットの削減
標準スループットを使用するか、より高いスループットを使用するかにかかわらず、Parameter Store への呼び出しの頻度とタイプを確認します。場合によっては、パラメータを変更せずにリクエストの数を減らすことができます。コストはサブスクリプションモデルや階層モデルではなく使用量に基づいて決定されるため、課金される API インタラクションが少なくなります。
-
リクエストのたびに同じ値を読み込むのではなく、アプリケーション内でパラメータの値をキャッシュします。
たとえば、アプリケーションが
/myapp/prod/log-levelを 1 分間に何度も読み取る場合、アプリケーションはその値を一度読み取って、短期間その値を再利用することができます。この手法により、Parameter Store の反復呼び出しが減ります。頻繁に変動する値には短い再利用期間を選択し、ほとんど変動しない値には長い再利用期間を選択します。 -
複数のパラメータの名前がわかっている場合は、GetParameters を使用します。
例えば、パラメータ
/myapp/prod/database/host、/myapp/prod/log-level、/myapp/prod/vendor/merchant-idに対して個別の GetParameter 呼び出しを行うのではなく、これらのパラメータのリストを 1 回のGetParametersリクエストで取得できます。 -
アプリケーションに必要なパラメータ数を上回る数のパラメータを読み取らないでください。
アプリケーションに必要なパラメータが少数しかない場合は、
/myapp/prod/などのパス全体を繰り返し読み取るのではなく、GetParameterまたはGetParametersを使用します。アプリケーションがパス下のパラメータのグループを必要とする場合は、GetParametersByPath を使用します。より高いスループットを使用する場合、GetParameterクォータはGetParametersByPathのクォータの 100 倍です。 -
多数のリソースが同時に起動する場合は、パラメータの読み取りを分散させてください。
例えば、更新中に多くの Amazon EC2 インスタンスまたは Amazon ECS タスクが開始される場合は、すべてのリソースがまったく同時にパラメータを読み取ることがないようにしてください。クォータは 1 秒あたりです。可能であれば、パラメータを 1 回読み取り、その値をアプリケーションにキャッシュするか、リクエストがすべて同じ秒以内に発生しないように少しの遅延を追加します。
-
Lambda 関数の場合は、AWS パラメータとシークレット Lambda 拡張機能の使用を検討してください。
この拡張機能では、関数で再利用するためにパラメータ値をローカルに保存できます。この手法により、Parameter Store への呼び出し回数が減り、パラメータ値の取得に必要な時間も短縮できます。この手法の具体的な手順については、「AWS パラメータとシークレット Lambda 拡張機能を使用したパラメータとシークレットのキャッシュ」
を参照してください。
スループットの増加
大量のワークロードに対しては、より高いスループットを有効にできます。この設定を行うと、アカウントとリージョンに対してサポートされる 1 秒あたりの最大トランザクション数が増加しますが、これには料金がかかります。次のシナリオでスループットの増加を考えてみましょう。
-
アプリケーションには一時的にスループットの増加が必要です。
例えば、ウェブストアは週末のセール中にパラメータを読み取る頻度が高くなることがあります。販売を開始する前により高いスループットを有効にし、販売終了後に標準スループットに戻すことができます。高スループットは、Parameter Store設定ページから、または AWS CLI を使用して、いつでも有効または無効にできます。
-
本番アプリケーションは定期的にパラメータを同時に取得するため、スロットリングの問題が発生します。
同時取得は、複数のインスタンス、コンテナ、関数、またはビルドジョブが Parameter Store から同時にパラメータを読み取るときに発生する可能性があります。次に例を示します。
-
アプリケーションがすぐにスケールアウトします。例えば、アプリケーションは通常 5 つの Amazon EC2 インスタンスで実行されます。トラフィックが突然増加すると、Amazon EC2 Auto Scaling はさらに 50 個のインスタンスを起動します。各インスタンスが起動時にパラメータを読み取る場合、組み合わされたリクエストがデフォルトのリクエスト制限を超える可能性があります。
-
コンテナサービスは同時に多くのタスクを開始します。例えば、Amazon ECS サービスは更新中に多くの置換タスクを開始することがあり、各タスクは起動時に Parameter Store から設定を読み取ることがあります。
-
Lambda 関数は、同時に多くのリクエストを受信します。例えば、Lambda は増加したトラフィックを処理するために多くの関数環境を起動することがあります。各関数環境は、起動時にパラメータを読み取ることがあります。
-
ビルドまたはリリースプロセスは、短時間で多くのパラメータを読み取ります。例えば、ビルドジョブが複数のアプリケーションまたは環境の設定を読み取ることがあります。
-
高スループットのコストに関する考慮事項
高スループットオプションの場合、追加料金が適用されます。現在の Parameter Store API 料金と例については、「AWSSystems Manager の料金
料金は Parameter Store API インタラクションに基づいています。API インタラクションは、API リクエストと個々のパラメータ間のインタラクションとして定義されます。例えば、1 つの GetParameter リクエストが 10 個のパラメータを返した場合、課金目的により、このリクエストは 10 個の Parameter Store API インタラクションとしてカウントされます。
トラフィックが増加する短期間に高スループットに切り替えるシナリオを考えてみましょう。ウェブストアで週末セールを開催し、セール中に 1,000,000 Parameter Store API インタラクションを行います。この例の高スループットのコストが 10,000 API インタラクションあたり $0.05 である場合、追加コストの合計は約 $5 です。セール終了時に標準スループットに戻せば、コストの発生を停止できます。
スループット層とパラメータ層の組み合わせ
スループットはパラメータ層とは無関係に動作します。パラメータ階層はストレージの制限と機能の可用性を制御しますが、スループット設定はリクエストボリュームを制御します。パフォーマンスとスケールの要件を満たすために、層とスループットを組み合わせて使用できます。
例えば、シンプルで低負荷のアプリケーションをサポートするために、デフォルトのスループットで標準パラメータを使用できます。大規模で高頻度のアクセスパターンをサポートするために、高度なパラメータをより高いスループットと組み合わせることができます。一般的に、使用するパラメータ階層に関係なく、アプリケーションがデフォルトの TPS 制限を超えた場合 (同時読み取りまたは書き込みのバースト中など）、スループットを引き上げる必要があります。
最大スループットやその他の Parameter Store クォータの詳細については、 AWS Systems Manager エンドポイントとクォータを参照してください。
Parameter Store におけるスループット設定の変更
次の手順では、Systems Manager を使用して Parameter Store が現在の AWS アカウント と AWS リージョン に対して処理できる 1 秒あたりのトランザクション数を変更する方法を説明します。この設定はいつでも変更できます。
