AWS 30：設計演習：要件から構成へ

6つの手順：読む → 数字 → 困りごと → 部品 → 図 → 見直す

構成を考える手順は、次の6つです。

大事なのは、AWS の部品の名前が出てくるのは4番目からだということです。1〜3は紙とペンだけでできますし、AWS 以外のクラウドでも同じです。そして、構成の良し悪しは、この1〜3でほとんど決まります。

もう1つ大事なのは、1回で完成させようとしないことです。6で見直して足りない所があれば、1〜5のどこかへ戻ります。要件を読み違えていたら1へ、数字が足りなければ2へ戻ります。

次から、手順2と手順4のコツを先に見てから、演習に入ります。演習の中では、上の帯で「いまどの手順か」を示します。

手順2のコツ：わからない数字は、掛け算で見積もる

「数字にする」と言われても、最初から正確な数字を知っていることはまずありません。そこで、わかっている数字を掛け算して見積もります。

図の見積もりを、1行ずつ読んでみます。

結果は「平均で毎秒2〜3回、ピークで毎秒20回くらい」です。

この見積もりは、正確さより桁（けた）が大事です。毎秒20回か30回かは、構成をほとんど変えません。でも、毎秒20回か2万回かは、選ぶ部品がまったく変わります。

手順2で集める数字は、図の右の5つが基本です。

わからない数字は、依頼した人に聞きます。「わからない」と言われたら、「多めに見て何人くらい？」と桁だけでも聞きます。それでも決まらなければ、仮の数字を置き、「この数字を前提にした」と書いておきます。

手順4のコツ：候補を2〜3出し、捨てた理由も書く

部品を選ぶときは、いきなり1つに決めず、候補を2〜3個並べて比べます。そして、選んだ理由だけでなく、捨てた理由も書きます。

例として、処理を動かす部品（第9・21・22章）の比べ方を図に並べました。

この表は目安で、答えではありません。要件の数字を当てはめると、どの行が効くかが決まります。

捨てた理由を書く意味は2つあります。1つは、自分の考えの穴に気づけること。捨てた理由がうまく書けないなら、その候補のほうが良いのかもしれません。もう1つは、後で見直すときに、「前提の数字が変わったから、捨てた候補を拾い直そう」と判断できることです。

演習1 小さなブログ：要件を読んで、数字にする

1つ目の演習です。ヘアサロンチェーン「カミノ」から、次のような依頼が来ました（図の左のメモ）。

手順1で大事なのは、「要らないもの」を読み取ることです。コメント欄が要らない、管理画面も要らない。これだけで、利用者のデータを保存する DB も、ログインの仕組みも要らなくなります。

手順2で数字にすると、図の右のようになります。

月1万回を秒に直すと、平均で毎秒0.004回。ピークでも毎秒数回です。読むのは書くより数千倍多く、しかも読むたびに中身は同じ。これがこの演習の鍵になります。

演習1 困りごとを並べ、部品を選ぶ

手順3で困りごとを並べます。この要件では、難所はあまりありません。

手順4で部品を選びます。図の表で、緑が選んだもの、赤が捨てた候補です。

いちばん大きな判断は、「動くサーバー」を置かないことです。ブログ用のソフト（WordPress など）を EC2 と RDS で動かす方法もよく使われます。でも、読むたびに同じ記事を返すだけなら、記事を前もってファイル（HTML）にしておき、S3 に置いて CloudFront で配るだけで足ります（第15章）。このように、作っておいたファイルを配るだけのサイトを静的サイトと呼びます。

演習1 図にする：静的サイトの構成

手順5で、選んだ部品をつないで図にします。

図を見ると、サーバー（黄色の部品）が1つもありません。これがこの構成のいちばんの特徴です。

図の描き方にも1つコツがあります。左に利用者、右に向かって奥へという向きをそろえることです。リクエストの流れが左から右へ読めると、図を見た人が迷いません。また、色で役割を表しているので（青がつなぐ、緑がしまう、赤が守る）、黄色が無いことが一目でわかります。

演習1 見直す：6つの問いで確かめる

手順6で、第28章の判断の問いを使って見直します。

見つかったのは、予算アラート（第4章）が無いことでした。数分でできるので、すぐ足します。

見直しでは、足りないものだけでなく、やりすぎも探します。たとえば「念のため別のリージョンにも複製しよう」は、この要件（半日止まってよい）には過剰です。見直しの結果、何も足さないという判断も立派な設計です。

演習1で覚えておきたいのは、要件が小さければ、構成も小さくてよいということです。第16章の3層構成（ALB＋EC2＋RDS）は、よくある形ですが、いつも正解ではありません。

演習2 予約サービス：要件を読んで、数字にする

2つ目の演習です。ブログが好評だったカミノから、次の依頼が来ました。50店舗のネット予約です。

ブログとの一番の違いは、書き込みが大事なことです。ブログの記事は消えても書き直せますが、予約が消えたり重なったりすると、お客さんが来店して困ります。

手順2の数字は、図の右のとおりです。

毎秒20回は、AWS にとっては小さな数字です。つまりこの演習の難しさは、量ではなく、正しさと止まらなさにあります。

演習2 困りごとを並べる：数字から「難所」を見つける

手順3です。要件と数字から、「普通にやると困る所」を並べます。

困りごとを並べるコツは、要件や数字を1つずつ指さして、「これを普通に作ったら、何が起きる？」と聞くことです。第29章で単一障害点を探したのと同じやり方です。

並べてみると、この演習の難所は大きく4つ（二重予約・混雑・止まれない・個人情報）で、残りの2つは決まった部品で解ける「定番の困りごと」だとわかります。

時間をかけるべきなのは難所のほうです。特に1の二重予約は、部品を選んだ後で、改めて詳しく見ます。

演習2 部品を選ぶ：選んだ理由と、捨てた理由

手順4です。難所ごとに候補を比べて選びます。

予約の保存には、Aurora（PostgreSQL 互換）の Multi-AZ を選びました（第13章）。

アプリを動かす部品には、ECS on Fargate（第21章）を選び、2つの AZ に置きます。EC2 は OS の世話が残ります。Lambda でも作れますが、リクエストごとに DB へ接続すると接続数が増えすぎやすい点（第13章）と、チームが慣れている Web アプリの形をそのまま使える点で、コンテナにしました。Lambda が間違いなのではなく、この要件ではこちらを選んだ、という書き方をします。

ログインは Cognito（第26章）。パスワードの保存や再設定、多要素認証を自分で作るのは危険です。

前日のメールは、EventBridge Scheduler で毎日決まった時刻に Lambda を呼び、Lambda が明日の予約を読んで、Amazon SES（メールを送るためのサービス）で送ります。1日1回の短い処理なので、Lambda が向いています（第22章）。

演習2 図にする：ブログの構成に、動く部分を足す

手順5です。図を見てください。演習1の部品（Route 53・CloudFront・S3）が、そのまま上の段に残っています。S3 には、ブログの記事に加えて、予約画面のファイル（HTML や JavaScript）も置きます。

リクエストの流れは次のとおりです。

図の育ち方に注目してください。演習1の構成を捨てて描き直したのではなく、困りごとが増えたぶんだけ、部品を足しました。これが第28章の一般的な設計原則「育つ前提で作る」です。

演習2 いちばんの難所：二重予約を DB で止める

最大の難所、二重予約をどう防ぐかを詳しく見ます。

よくある失敗は、アプリの中で次のように書くことです。

2人がほぼ同時に来ると、2人とも「空いている」を読んでから、2人とも書いてしまいます。Fargate が2つあれば、別々のコンテナで同時に起きるので、アプリの中の工夫では防げません。

そこで、DB に止めさせます。予約の表に、「同じスタッフの同じ開始時刻は1行だけ」という一意制約を付けます。

CREATE TABLE reservations (
  id        bigserial PRIMARY KEY,
  staff_id  bigint      NOT NULL,
  start_at  timestamptz NOT NULL,
  member_id bigint      NOT NULL,
  UNIQUE (staff_id, start_at)
);

こうすると、図のように、先に書いた A さんだけが成功し、B さんの書き込みは DB が断ります。アプリは断られたら「その枠は埋まりました」と表示するだけです。確かめることと書くことを、DB が1回で同時にやってくれるのがポイントです。

施術の長さが人によって違い、時間帯が重なる場合は、PostgreSQL の排他制約など、より進んだ方法もあります。考え方は同じで、「重なりの判定を DB の中で、書き込みと同時に行う」ことです。

DynamoDB を選んだ場合は、条件付き書き込み（そのキーの項目がまだ無いときだけ書く）で同じことができます。

演習2 見直す：単一障害点と、お金と、混雑

手順6です。図を指さしながら、第28章の問いと第29章の単一障害点で見直します。

見直しで見つかった3つ（NAT、朝の混雑、SES）は、どれも図を描いたからこそ気づけたものです。特に朝9時の混雑は、手順2で数字にしていなければ見落としていた難所です。

演習2で覚えておきたいのは、正しさが大事な所は DB に任せること、そして混雑の時刻がわかっているなら、待たずに前もって備えることです。

演習3 動画の変換：要件を読んで、数字にする

3つ目の演習です。予約サービスが軌道に乗り、カミノから新しい依頼が来ました。

3つ目の要件、「30分以内に見られればよい」がとても大事です。これは、アップロードした瞬間に変換を終わらせる必要はない、つまり、処理を後回しにできる（非同期にできる、第24章）という意味だからです。

手順2の数字です。

演習2は「正しさ」が主役でしたが、演習3の主役は重くて長い処理です。

演習3 困りごとを並べる：サーバーの中で全部やると、どこで詰まる？

手順3です。今回は、「演習2の Fargate の中で、全部やってしまったら？」と考えると、困りごとが見つけやすくなります。

ここで見えてくるのは、予約の処理（速く・正しく）と、動画の処理（重く・長く）は、性質がまったく違うということです。性質の違うものを同じ場所で動かすと、重いほうが軽いほうを邪魔します。

だから、動画の処理は、予約のアプリから切り離します。受け付けるところ（アップロード）と、処理するところ（変換）も分けます。これが第24章の「待たせない」の考え方です。

演習3 部品を選ぶ：待たせず、流れ作業にする

手順4です。

受け取る：署名付き URL（第15章）を使い、スタッフのスマホから S3 に直接アップロードさせます。予約のアプリは「この URL に置いてね」と短い時間だけ使える URL を渡すだけで、5GB のファイルそのものには触りません。大きなファイルは、S3 のマルチパートアップロード（分割して送る仕組み）で送ります。

変換する：AWS Elemental MediaConvert を選びました。動画の変換（トランスコード）専用のマネージドサービスで、何本来ても受け付けて順に変換します。

以前は Amazon Elastic Transcoder というサービスもありましたが、2025年11月に提供を終えており、今は MediaConvert が後継です。

手順と再試行：S3 に原本が届いたことを EventBridge が受け取り、Step Functions（第24章）が「変換を頼む → 終わりを待つ → 状態を記録する」の手順を進めます。失敗したら決めた回数だけやり直し、それでもだめなら「失敗」として記録し、通知します。

状態を記録：新しく DynamoDB を足す案もありましたが、今ある Aurora に列を足すことにしました。予約画面は既に Aurora を読んでいるので、部品を増やさずに済みます。新しい部品を足す前に、今ある部品で済むかを考えるのも大事な判断です。

演習3 図にする：予約の部分は1つにまとめ、動画の流れを前に出す

手順5です。図では、演習2の予約の部分（ALB・Fargate・Cognito など）を1つの箱にまとめ、新しく足した動画の流れを大きく描きました。構成図は、何を伝えたいかに合わせて描き分けてよいのです。全部の部品を毎回描くと、伝えたいことが埋もれます。

番号の順に、流れを追います。

2つのことに注目してください。

1つは、予約のアプリは動画の重い仕事を一切していないことです。URL を渡し、状態を読むだけです。夕方に動画が大量に届いても、予約の応答は遅くなりません。

もう1つは、CloudFront と Aurora が、3つの演習をまたいで使い回されていることです。ブログのために置いた CloudFront が、動画の配信にもそのまま効いています。

演習3 見直す：失敗・お金・待ち時間

手順6です。非同期の構成は、利用者を待たせない代わりに、失敗が見えにくくなるという弱点があります。そこを重点的に見直します。

見直しで見つかった「失敗の行き先」は、非同期の構成では必ず確かめる項目です。第24章のデッドレターキューと同じ考え方で、「うまくいかなかったものが、どこかに溜まり、誰かが気づける」ようにしておきます。

3つの演習に共通した「型」

3つの演習をふり返ると、困りごとの形ごとに、よく効く部品の組み合わせが見えてきます。

そして、3つの演習すべてに共通していたのは、部品の名前から考え始めなかったことです。

この型は、次の第31章で、本全体の「困りごと → 部品」の対応表としてまとめ直します。

自分でやってみよう：演習4

最後に、自分で考える演習を出します。図のメモの要件を、6つの手順で構成にしてみてください。

考えるときのヒントです（図の右）。

答えは1つではありません。サーバーレス（API Gateway＋Lambda＋DynamoDB）で組む人もいれば、演習2と同じくコンテナと Aurora で組む人もいるでしょう。どちらでも、要件の数字を根拠に選び、捨てた候補と理由を書けていれば、それはあなたの設計です。

できあがった図は、第28章の Well-Architected Tool の問いにも当ててみてください。

よくある落とし穴

設計の演習で、よくある失敗です。

特に最後の項目は、演習2の二重予約、演習3の失敗の行き先で見たとおりです。構成図は、うまくいく流れを描くのは簡単で、うまくいかないときの流れで差が出ます。

迷ったら、手順1に戻りましょう。「誰の、どんな困りごとを解くのだったか」を読み直すと、たいていの迷いは消えます。

試作するなら：お金と片付け

設計は紙の上でもできますが、本当にその数字をさばけるかは、小さく作って確かめるのが早くて確実です。この章の演習は紙の上なので片付けるものはありませんが、試作するときの注意をまとめます。

特に、NAT ゲートウェイ・Aurora・ALB は、リクエストが1つも来なくても時間で課金されます。試作が終わったら、必ずその日のうちに消します。Aurora やバックアップは、削除の前にスナップショットを取るか聞かれるので、試作なら取らずに消します。

また、演習2の SES のように、本番で使うには申請が要る部品もあります。試作の段階で気づけるのも、作ってみる利点です。