導入
SAPの問題は「全部入りの理想解」を選ばせません。必ずどこかで何かを諦めさせます。プロの設計者は、要件の優先順位を読み取り、意識的にトレードオフを選びます。その思考の型を先に身につけましょう。
説明
現実の設計には、必ず相反する軸があります。代表的なトレードオフは次の通りです。
| 軸 | 一方を取ると | 他方が犠牲に |
|---|---|---|
| 可用性 ⇔ コスト | マルチリージョンで可用性最大 | 費用が数倍になる |
| 一貫性 ⇔ 性能/可用性 | 強整合で正確 | レイテンシー・可用性が下がる |
| 俊敏性 ⇔ ガバナンス | 各チームに自由を与える | 統制・監査が効きにくい |
| 運用負荷 ⇔ 柔軟性 | フルマネージドで楽 | 細かい制御ができない |
SAPの問題文には、どの軸を優先すべきかのヒントが必ず埋め込まれています。次のようなキーワードを拾って、優先軸を特定します。
- 「運用のオーバーヘッドを最小にしたい」→ マネージド／サーバーレスを選ぶ
- 「最もコスト効率よく」→ 過剰な冗長を削り、購入オプションやサーバーレスを検討
- 「ダウンタイムを許容できない」→ マルチAZ／マルチリージョンの冗長化
- 「最小限の変更で」→ リホスト寄り、既存を活かす選択
- 「監査要件がある」「複数チームを統制」→ ガバナンス（Organizations/SCP/Config）
flowchart TD
Q["長文の問題"] --> K["要件キーワードを拾う"]
K --> P["優先すべき軸を決める<br/>（コスト/可用性/運用負荷/俊敏性…）"]
P --> C["その軸に最も合う選択肢を1つ選ぶ"]
読んでみよう
「動くかどうか」で選択肢を切ると、SAPでは複数残ってしまいます。プロの設計思考は「どれが要件の優先軸に最も忠実か」で選び切ることです。以降の章で具体的なサービスを学ぶときも、機能の暗記ではなく「このサービスは、どのトレードオフを解決するために存在するのか」という視点を持ち続けてください。