導入
「本番が遅い、なんとかしてくれ」という依頼ほど厄介なものはありません。勘で手を打つと、直らないどころか別の問題を生みます。プロの改善は、必ず計測から始まります。
説明
パフォーマンス改善は、次の3ステップのループで進めます。
flowchart LR
M["計測する<br/>（CloudWatch/X-Ray）"] --> S["ボトルネックを特定する"]
S --> I["改善策を1つ適用する"]
I --> M
1. 計測する。 CloudWatch のメトリクス（CPU/メモリ/レイテンシー/キューの深さ）と、AWS X-Ray による分散トレーシングで、「どのコンポーネントが遅いか」を可視化します。勘や経験則で「たぶんDBが遅い」と決めつけず、まず数字で確認します。
2. ボトルネックの種類を特定する。 典型的な原因と対策は次の通りです。
| ボトルネックの種類 | 症状 | 典型的な改善策 |
|---|---|---|
| CPU/メモリ不足 | インスタンスのCPU使用率が高止まり | 適切なインスタンスタイプへ変更、Auto Scaling |
| DBへの読み取り集中 | DB接続数・レイテンシーが高い | キャッシュ（ElastiCache）、リードレプリカ |
| 同期処理の直列待ち | リクエストがタイムアウトする | 非同期化（SQS/EventBridge でキューイング） |
| 不適切なサービス選択 | 常時ポーリングでムダな待ち | イベント駆動（Lambda + EventBridge）への置換 |
| ネットワークの遠回り | リージョンをまたぐ通信で遅延 | CloudFront、リージョン内完結の設計に見直し |
3. 改善策を1つずつ適用し、再計測する。 複数の変更を同時に入れると、何が効いたか分からなくなります。1つ変えて、また計測する、を繰り返すのが定石です。
代表的な改善パターンとして、SAPで頻出なのが次の3つです。
- キャッシュを挟む: ElastiCache（Redis/Memcached）や DAX（DynamoDB用）、CloudFront（静的コンテンツ）で、DBやオリジンへのアクセスを減らす。
- 非同期化する: 即座に応答する必要がない処理は SQS でキューに積み、裏で処理する。リクエストの応答時間が短くなり、スパイクにも強くなる。
- 適切なサービスへ置き換える: 常時起動のEC2でポーリングしていた処理を、イベント駆動のLambdaに置き換えるなど、ワークロードの性質に合ったサービスへ移す。
読んでみよう
SAPの性能改善問題は「このサービスを使えば速くなる」という単純な暗記では解けません。問題文から「何がボトルネックか」を読み取り、「計測→特定→改善」の順で考える癖をつけてください。選択肢に「キャッシュを追加する」と「インスタンスを大きくする」が並んでいたら、まず「読み取りが集中しているのか」「計算量そのものが多いのか」を問題文から見極めるのがコツです。