1. はじめに

NTTドコモ情報システム部の鈴木遥香です。
現在、担当しているシステムでは複数のドコモサービスのバックエンド機能をAWSを用いて提供しています。

中でも私が担当してきたサービスには、Webやアプリ経由で多数ユーザが利用する「広域アクセス型」のものから、店舗や現場など特定の場所で利用される「拠点アクセス型」のものまで、多様な特性があります。

本記事では、API GatewayとLambdaという2つの制御ポイントに着目し、それぞれのサービス特性に応じたAPI設計の考え方を紹介します。 API Gatewayは「入口」でリクエスト量を調整し、下流のシステムを守る役割を担う一方、Lambdaは「処理の実行」で応答の安定性を確保する役割を持つため、それぞれで制御を行うことが重要と考えています。

2. サービス特性の違いがAPI設計に与える影響

広域アクセス型の特性（例：インターネットショッピング、オンライン決済、動画配信サービスなど）

以下のような性質を持つケースが多く、予測しづらい突発的負荷にも耐え、サービス全体を守る仕組みが必要になります。

・ユーザー数が多くアクセスの増減が激しい

・キャンペーンやアプリ更新によってスパイクが発生しやすい

・レスポンスの速さ、スケーラビリティが最重視される

・外部システムやデータベースへのアクセス集中が発生しやすい

拠点アクセス型の特性（例：店舗や窓口の手続き端末、受付端末）

業務フロー上「必ず応答が返ってくること」が求められる場面が多くあります。そのため、安定性を確保しつつ、運用コストとのバランスを取る設計が重要です。

・アクセスするユーザや端末は限定的

・特定時間帯にピンポイントでアクセスが集中する

・ “必ず応答が返ってくること” が重要

3.システム構成とリバースプロキシの役割

自担当システムでは、リクエストはユーザ／フロントエンド → ECS（リバースプロキシ） → API Gateway → Lambda → DB・外接システムという流れで処理されます。

ここで ECS（リバースプロキシ）は、複数のAPIへのリクエストを集約し、API Gatewayに渡す役割を担っています。主な目的は以下の通りです。

フロントエンドからの通信を統一的に管理

セキュリティポリシーの適用

ルーティングの簡潔化

重要なのは、リバースプロキシはリクエスト量を制御するポイントではないということです。

4. API Gateway：スロットリング戦略

API Gatewayはリクエスト量を制御する最初のポイントであり、下流（Lambda・DB・外接システム）を守るための重要なゲートとなります。

自担当サービスでは、予測トラフィックよりも実績トラフィックが上回ってしまったことからシステムが負荷に耐えられず、サービス影響を発生させてしまったことがありました。これの解消を目的にAPI Gatewayにスロットリングの設定をしています。

スロットリングの目的は「リクエストを拒否すること」ではなく、下流のリソースを守り、影響の長期化・広範囲化を防ぐことで安定してサービス継続を可能とすることです。

スロットリングの設計方針はサービス特性の違いにより大きく異なります。

広域アクセス型：高トラフィックは下流を守ることのできる範囲のみ受け止める

広域アクセス型サービスでは大量トラフィックや突発的スパイクが発生する可能性がありますが、以下の理由から「すべてを吸収する必要はない」と判断しています。

・DB や外部システムに過剰な負荷を与える

・スパイク前提の高スペック構成は平常時に冗長かつ高コスト

・無理な処理継続が全体障害を誘発し得る

・ユーザ側のリトライで利用継続が可能な設計としている

そのため、以下のように “受け止める量に上限を設ける” 考え方で値を設定します。

レート値（1 秒あたりの平均リクエスト数）

→ 下流が安全に処理できる量を基準に設定

バースト値（短時間の許容増加量）

→ 小規模スパイクだけ吸収し、大規模スパイクは意図的に弾く

API 単位のスロットリング

→ 重要導線の継続利用を優先し、下流システムが耐えられる範囲で API ごとに上限を設定する

つまり広域アクセス型のスロットリングは、

「守るべき下流リソースを優先し、吸収するスパイクを選別する」という考え方で設計します。

拠点アクセス型：確実に処理を通すことを優先しつつ過剰コスト発生を防止

拠点アクセス型サービスは利用ユーザが限定され、アクセス量も比較的少なく安定しています。さらに、店舗・窓口端末など、特定の場所・業務フローに紐づいて利用されるため必ず処理が通ることが業務継続の前提になるケースが多いです。

このため、過度に厳しいスロットリング値を設定すると、通信揺らぎや端末リトライで想定外にアクセス制限に引っかかり、業務処理が中断されるリスクがあります。

このため、拠点アクセス型では以下の方針が適切と考えています。

レート値、バースト値

　→ 実績平均トラフィックと比較して余裕を持たせた値とし、業務を止めないようにする

API 単位のスロットリング

→ APIごとに業務重要度と実績トラフィックを分析し、業務継続を最優先としつつ、過剰リソースによる無駄なコストを防ぐため、設定値を最小限に調整する

拠点アクセス型では、確実な処理通過を最優先しつつ、想定外の高負荷対策に投資しすぎないというバランスが重要になります。

5. Lambda：Provisioned Concurrencyによる安定化

スロットリングでリクエスト量を制御したとしても、Lambda はコールドスタート¹ による初期処理遅延が発生することがあります。

拠点アクセス型のように、連続的なアクセスが必ずしも発生しない場合にはコールドスタート率が高くなり、実際に処理時間が長くなってしまたケースもありました。この遅延が業務に影響する場合には対策が必要です。

そこで、Lambda では Provisioned Concurrency（プロビジョンドコンカレンシー）を活用します。

Provisioned Concurrencyは、あらかじめ指定した数の関数インスタンスをウォーム状態に維持することで、初回呼び出し時のコールドスタート遅延を回避する仕組みです。

拠点アクセス型

・業務処理のピークトラフィックに合わせて必要数をプロビジョン

・全てのAPIに設定する必要はなく、処理遅延を許容しないAPIにのみ設定することで過剰なコストを防止

広域アクセス型

・連続的なトラフィックが発生するAPIでは、常にウォーム状態のインスタンスが存在するため、コールドスタートは問題になりにくい

・コールドスタートの影響を最小限にしつつ、スパイク全体を吸収する設計を意識

こうして、スロットリングとプロビジョンドコンカレンシーを組み合わせることで、下流リソースを守りつつ、応答の安定性とコスト効率のバランスを取ることができます。

6. まとめ

ここまで述べてきたとおり、サービス特性によって求められる安定性や負荷特性は大きく異なります。そのため、API設計や設定は一律ではなく、それぞれに最適化することが重要です。

API Gateway のスロットリングとLambda の Provisioned Concurrencyを組み合わせることで、「守る・止めない・無駄にしない」設計を実現できます。

サービス特性別の設計方針

項目	広域アクセス型	拠点アクセス型
特徴	ユーザ数が多く、スパイク頻発	利用は限定的で、特定時間帯に集中
スロットリング	下流保護を優先し、レート値・バースト値に上限を設定	業務継続を最優先し、平均値に対して余裕ある値を設定
Provisioned Concurrency	高頻度アクセスで自然にウォームするため基本不要	処理速度が求められるAPIに設定し、遅延を防止