AWSエンジニア視点で読む「システム設計50パターン」入門

システム設計で詰まらないための50パターンを整理してみた

はじめに

最近、システム設計に関する「50の設計パターン」を学ぶ機会がありました。

そのまま暗記するというより、
「どんな問題に、どのパターンを当てはめるか」
を考えるための整理として非常に役立つ内容でした。

この記事では、元記事の内容を参考にしつつ、
自分がAWS基盤・インフラ設計の実務で特に重要だと感じたポイントを中心にまとめます。

※この記事は学習メモであり、元記事の全文翻訳ではありません。

システム設計で大事な5つの問い

システム設計では、いきなり構成図を書くよりも、まず次の5つを考えると整理しやすいです。

1. データはどう流れるか

2. データはどう保存されるか

3. データへ高速にアクセスするにはどうするか

4. 障害時にどう耐えるか

5. システムをどう成長させるか

この5つを押さえると、設計の骨格が見えやすくなります。

1. データ保存のパターン

Primary-Replica

書き込みはプライマリDBに集約し、読み取りはレプリカに分散する構成です。

AWSで考えると、Aurora Replica や RDS Read Replica が近いです。

読み取りが多いシステムでは有効ですが、レプリカ遅延によって古いデータを読む可能性があります。

Sharding

データを複数のDBに分割して保存する方法です。

大量データや高い書き込み性能が必要な場合に使います。

ただし、シャードキーの設計を間違えると一部のDBに負荷が集中します。
また、複数シャードをまたぐ検索や集計は難しくなります。

2. キャッシュのパターン

Cache-Aside

アプリケーションがまずキャッシュを見に行き、なければDBから取得してキャッシュに保存する方式です。

RedisやElastiCacheを使う多くの構成で使われます。

シンプルで使いやすい一方、キャッシュとDBの不整合には注意が必要です。

Cache Stampede Prevention

人気データのキャッシュが同時に切れると、大量リクエストが一気にDBへ流れます。

これを防ぐために、ロック、早期更新、リクエスト集約などを使います。

個人的には、これは実務でもかなり重要だと感じます。
「キャッシュを入れれば速くなる」で終わらず、
「キャッシュが切れた瞬間に何が起きるか」
まで考える必要があります。

3. 通信パターン

Request-Response

REST APIやgRPCのように、リクエストしてレスポンスを待つ同期通信です。

ユーザーがすぐ結果を必要とする処理に向いています。

Message Queue

処理をキューに入れて、後続処理を非同期に行う方式です。

AWSであれば SQS、EventBridge、Step Functions などが関係します。

例えば、ユーザー登録後のメール送信、画像処理、バッチ処理などは非同期化しやすいです。

Pub/Sub

1つのイベントを複数のサービスに配信する方式です。

AWSなら SNS、EventBridge が近いです。

「注文作成」というイベントをきっかけに、
在庫更新、通知、分析処理などを並列に動かすイメージです。

4. 信頼性のパターン

Timeout

外部サービス呼び出しには必ずタイムアウトを設定する必要があります。

タイムアウトがないと、依存先が遅くなった時に呼び出し元も巻き込まれます。

これは地味ですが、かなり重要です。

Retry with Exponential Backoff

一時的な失敗に対して、間隔を広げながら再試行する方式です。

AWS SDKでも多くの場合、標準で実装されています。

ただし、リトライを増やしすぎると、障害中のサービスにさらに負荷をかけることがあります。

Circuit Breaker

依存先サービスが失敗し続けている場合、一時的に呼び出しを止める仕組みです。

失敗しているサービスを呼び続けると、呼び出し元まで落ちる可能性があります。

Idempotency

同じ処理を複数回実行しても、結果が変わらないようにする考え方です。

決済、注文、DB更新、Lambdaリトライなどでは必須です。

特にAWS LambdaやStep Functionsでは、再実行やリトライを前提にするため、冪等性はかなり重要です。

Dead Letter Queue

処理に失敗し続けたメッセージを退避するキューです。

AWSでは SQS DLQ や Lambda の失敗時送信先などが該当します。

DLQを作るだけでなく、監視と再処理手順まで用意しないと意味がありません。

5. スケーリングのパターン

Horizontal Scaling

サーバー台数を増やして処理能力を上げる方式です。

ECS、EC2 Auto Scaling、Lambdaなどはこの考え方と相性が良いです。

ただし、アプリケーションがステートレスであることが前提になります。

Load Balancing

複数サーバーにリクエストを分散する仕組みです。

AWSでは ALB / NLB が代表的です。

Auto-Scaling

負荷に応じて、自動でリソースを増減させる仕組みです。

CPU使用率、リクエスト数、キュー深度など、どのメトリクスを使うかが重要です。

6. API設計のパターン

API Gateway

APIの入口を集約し、認証、ルーティング、レート制限などを行う仕組みです。

AWSでは Amazon API Gateway がそのまま該当します。

Rate Limiting

一定時間内のリクエスト数を制限する仕組みです。

公開APIでは必須に近いです。

不正利用、バグったクライアント、過剰アクセスからシステムを守ります。

7. 運用・可観測性のパターン

Health Check

サービスが正常に動いているかを確認するエンドポイントです。

ALBやECSではヘルスチェックが非常に重要です。

ただし、単に200を返すだけでは不十分な場合もあります。

DB接続や依存先まで見る深いヘルスチェックは有効ですが、やりすぎると逆に障害を広げることもあります。

Distributed Tracing

リクエストが複数サービスをどう流れたかを追跡する仕組みです。

マイクロサービスでは、どこで遅延やエラーが発生したかを把握するために重要です。

AWS X-Ray、Datadog APM、OpenTelemetryなどが関係します。

Canary Deployment

新バージョンをいきなり全体公開せず、一部のトラフィックだけ流して様子を見るデプロイ方式です。

エラー率やレイテンシを見ながら、問題なければ段階的に広げます。

本番リリースの安全性を高める重要な方法です。

自分が特に重要だと思った15パターン

AWS基盤やクラウドアーキテクト視点では、特に以下が重要だと感じました。

1. Primary-Replica

2. Sharding

3. Cache-Aside

4. Message Queue

5. Pub/Sub

6. Circuit Breaker

7. Retry with Backoff

8. Timeout

9. Idempotency

10. Dead Letter Queue

11. Load Balancing

12. Auto-Scaling

13. API Gateway

14. Health Check

15. Distributed Tracing

特に、Lambda、Step Functions、ECS、Aurora、SQS、EventBridgeを使う構成では、
「非同期処理」「リトライ」「冪等性」「DLQ」「監視」は避けて通れません。

まとめ

システム設計は、個別サービス名を覚えるだけでは不十分です。

大事なのは、

• データをどう流すか

• どこに保存するか

• どう速く読むか

• どう障害に耐えるか

• どうスケールさせるか

という観点で、設計パターンを組み合わせることだと感じました。

AWSのサービスを学ぶ時も、
「このサービスはどの設計パターンを実現するものなのか」
という視点で見ると、理解がかなり深まります。

今後は、これらのパターンを自分の実務や設計レビューに当てはめながら、より実践的に使えるようにしていきたいです。

参考：
System Design Patterns Every Engineer Should Know in 90 Minutes [2026 Edition]
※本記事は上記記事を参考に、自分の学習メモとしてAWS実務視点で再構成したものです。