AWS 31：おわりに：構成を考える思考の型

思考の型：困りごとから始めて、困りごとで終わる

構成を考える思考の型は、図のような輪です。

5番目が大事です。部品を入れると、必ず新しい困りごとが生まれます。この本の中で、何度もそれを見てきました。

この輪を回すたびに、構成は少しずつ育ちます。逆に言えば、困りごとが無いのに部品を足してはいけません。足した部品は、必ず新しい困りごと（料金・手間・壊れる所）を連れてくるからです。

対応表1 つなぐ：届ける・区切る・名前を付ける

ここから6つの表で、本全体の「困りごと → 部品」の対応をまとめます。上の帯は、第0章で見た役割の色です。表の括弧の数字は章の番号です。

1つ目はつなぐ部品です。

ネットワークの部品は、どれも「何を通し、何を通さないか」を決めるためのものです。迷ったら、「この通信は、誰から誰へ、どの道を通るか」を線で描いてみてください。描けない線は、たいてい設定が足りない線です。

対応表2 計算する：処理を動かす場所を選ぶ

2つ目は計算する部品です。

選ぶときの軸は、第30章で見た3つです。

迷ったら、世話の少ないほう（Lambda や Fargate）から検討し、合わない理由が見つかったら世話の多いほうへ、という順が安全です。世話が少ないほど、あなたが守る範囲（第0章の責任共有モデル）も小さくなるからです。

対応表3 しまう：データの形と読み方で選ぶ

3つ目はしまう部品です。

データの部品は、データの形と読み書きのしかたで選びます。

データは、計算の部品と違って後から引っ越すのが大変です。第23章で見たように、DynamoDB は「アクセスのしかたから設計する」ので、読み方が決まっていないうちに選ぶと苦労します。迷ったら、要件の「どう読むか」をもう一度書き出してみてください。

対応表4 守る：誰が・何を・どこから

4つ目は守る部品です。

守りの部品を選ぶときの考え方は3つです。

どれも、ほとんどお金がかからないものから始められます。規模が小さくても、守りの柱だけは下げない。第28章で見たとおりです。

対応表5 見張る・直す：気づき、同じものを何度でも作る

5つ目は見張る・直す部品です。

見張る部品は、利用者から見た症状を見張るのが基本です（第17章）。CPU の使用率より、「エラーの割合」「応答の遅さ」のほうが、利用者の困りごとに直結します。

そして、直す部品の中心はコードです。構成をコードにし、変更を自動で届け、壊れたら前の版に戻す。手作業を減らすほど、夜中の障害で慌てることが減ります。

対応表6 速く・待たせない：つなぎ方を変える

最後の表は、部品そのものというより、部品のつなぎ方です。

ここに並んだものは、どれも部品と部品の間の工夫です。同じ部品を使っていても、直列につなぐか、キューを挟むか、並列に並べるかで、速さも止まりにくさも大きく変わります（第29章の直列と並列）。

構成図を描いたら、部品だけでなく線にも目を向けてください。「この線は、相手が止まっていたらどうなる？」「この線を流れるものが10倍になったら？」と聞くと、つなぎ方の改善点が見えてきます。

迷ったときの分かれ道：計算とデータ

設計でいちばん迷うのは、処理を動かす場所とデータの置き場の2つです。どちらも、要件の数字に「はい / いいえ」で答えていくと、たいてい候補が絞れます。

ただし、この分かれ道は入口にすぎません。最後は第30章の手順4のように、候補を2〜3並べ、要件の数字で比べ、捨てた理由を書きます。

また、1つのサービスの中で、置き場を使い分けるのは普通のことです。第30章の予約サービスでは、画面のファイルは S3、予約は Aurora、よく読む一覧はキャッシュ、というように組み合わせました。「どれか1つを選ぶ」ではなく、「データの種類ごとに選ぶ」と考えてください。

判断の問いのチェックリスト ①：作る前と、選ぶとき

第28章の6つの判断の問いを、場面ごとのチェックリストにしました。まずは前半の2つの場面です。

左の5つに答えられないうちは、まだ部品の名前を口にしない。これを守るだけで、設計の質は大きく変わります。

判断の問いのチェックリスト ②：図ができたら、動かし始めたら

後半の2つの場面です。

この20の問いは、どんな規模のサービスにも使えます。小さなサービスなら、多くの問いに「いまはやらない。理由はこう」と答えることになるでしょう。それで構いません。大事なのは、問いを飛ばさず、答えを持っていることです。

よくある考え違い

最後に、AWS を学び始めた人がよく持つ考え違いを、この本の章と一緒に並べます。

どれも、この本で「なぜそうするのか」を積み上げてきた人なら、理由を説明できるはずです。もし説明できないものがあれば、括弧の章に戻って読み直してみてください。

考え違いの多くは、責任共有モデル（第0章）と、直列と並列（第29章）の2つを思い出すと解けます。AWS が守ってくれるのはどこまでか。部品を足すと、全体は強くなるのか弱くなるのか。この2つは、設計で迷ったときの羅針盤になります。

次に学ぶこと：公式の資料が、いちばん確かな教科書

この本は、AWS で構成を考えるための考え方の入口です。細部と最新の情報は、公式の資料で確かめる習慣を付けてください。

公式の資料を読むときのコツです。

名前や置き場所は変わることがあります。見つからないときは、サービス名と「AWS ドキュメント」で検索してください。

資格を道しるべにする

学んだことを確かめる道しるべとして、AWS 認定（資格）があります。資格を取ること自体が目的ではありませんが、試験の範囲を見ると、自分に抜けている知識がよくわかります。

この本を読み終えた人には、アソシエイトが次の目標としてちょうどよいでしょう。アソシエイトの試験は、Well-Architected Framework に沿って設計できるかを問うもので、この本の第28〜30章がそのまま土台になります。IT の経験がまったく無い場合は、クラウドプラクティショナーから始めるのもよい順番です。

ほかにも、開発者向け・運用向け・セキュリティ・データ・機械学習など、分野ごとの資格があります。

試験の範囲・版・受け方・費用は、定期的に更新されます。受ける前に、公式の試験ガイドで最新の内容を確かめてください。

学び方：小さく作って、壊して、消す

最後に、いちばん効く学び方をおすすめします。手を動かすことです。読んだだけの知識は、画面の前で止まります。

手を動かすときの守りは、次の3つです。

この3つがあれば、失敗しても怖くありません。むしろ、壊して直した経験は、本を読んだ経験より何倍も長く残ります。

おすすめの練習は、第30章の演習4（オンラインの小テスト）を、実際に小さく作ってみることです。設計した構成が、本当に数字をさばけるか。料金は見積もりどおりか。作ってみると、紙の上では気づかなかった困りごとが、必ず見つかります。そして、それを解く部品を選ぶ。この本で何度も回してきた輪を、今度は自分の手で回してください。