← コース一覧
AWSサービスの内部原理
DynamoDB や Lambda や S3 といったAWSのマネージドサービスは、ボタン一つで動く「魔法の箱」に見えます。しかしその中身は、SSDという物理的な記憶装置、Linuxが動くサーバー、OSのプロセス分離、ハッシュや木構造といったアルゴリズム、そして分散システムの一貫性という、あなたがすでに学んだコンピュータの基礎で組み立てられています。各サービスについて「内部で何が起きているか・なぜその設計なのか」を、AWS公式ドキュメントで裏取りできる範囲で1テーマずつ解き明かします。
公式ドキュメント: Amazon DynamoDB Developer Guide ↗導入
DynamoDB編
- 2DynamoDBはSSDに載っている — パーティションという物理の単位1つの「表」に見えるテーブルの正体は、SSD 上に散らばった複数のパーティションの集まりです。図で追っていきましょう。
- 3どのパーティションに行くかはハッシュが決める — パーティションキーの正体パーティションキーの値がどうやって物理的な格納先を決めるのか、図で追っていきましょう。
- 4パーティションは実はサーバーである — 3コピー複製と可用性「パーティション」の正体から可用性が成り立つ理由まで、箱と矢印で順に追っていきましょう。
- 5結果整合性とアトミックカウンター — 分散の一貫性と競合状態「複製の伝播遅延」と「並行更新の排他」——すでに学んだ2つの基礎で DynamoDB の挙動を図で追っていきましょう。
- 6アイテムの正体 — スキーマレスと400KBの壁DynamoDBのアイテムの正体を、入れ物の構造から400KBの壁まで図で追っていきましょう。
- 7ソートキーは物理配置を決める — 複合主キーとアイテムコレクションソートキーがデータの物理的な並びと検索の速さをどう決めるのか、図で追っていきましょう。
- 8QueryとScanの内部差 — ハッシュで1発 vs 全部読むQueryとScanの速度差の正体を、「ハッシュが使えるかどうか」から図で追っていきましょう。
- 9GSIは影の別テーブル — 非同期複製と結果整合の宿命GSIの不思議な挙動はすべて「影の別テーブルへ非同期にコピーされる」という一枚の絵から導けます。図で追っていきましょう。
- 10RCUとWCUの正体 — 課金単位はI/Oの量であるRCUとWCUを丸暗記の呪文ではなく、レプリカ群が消費する資源から図で再導出していきましょう。
- 11ホットパーティション問題 — バーストとアダプティブキャパシティ「1つのキーにアクセスが集中すると何が起きるか」を、パーティション=サーバーという前提から図で追っていきましょう。
- 12LSIは同じパーティションに同居する — ローカルであることの代償LSI(ローカルセカンダリインデックス)が「本体と同じパーティションに同居する」ことで得られる強整合と、その引き換えに支払う3つの代償を図で追っていきます。
- 13DynamoDB Streamsは変更のログである — CDCという発想DynamoDB Streamsは「テーブルへの全変更を時系列ログとして外へ流す」機能です。CDCという1つの発想が、順序保証からLambdaトリガーまでを支える流れを図で追いましょう。
- 14TTLは即座に消さない — バックグラウンド削除の設計DynamoDBのTTLは「期限が来たら即削除」ではなく「暇なときに数日以内で片づける」設計——その理由と、アプリ側が負う責任を図で追います。
- 15トランザクションの内部 — prepareとcommitの2段階書き込み条件付き書き込みを複数アイテムへ拡張したDynamoDBトランザクションの仕組みを、prepare/commitの2段階書き込みを軸に図で追っていきます。
Lambda編
- 16Lambdaは小さな仮想マシンで動く — Firecrackerと多層隔離「サーバーレス」の裏側で関数がどこで・どう隔離されて動くのかを、Worker→microVM→カーネル機構→運用ポリシーの4層で図解します。
- 17実行環境のライフサイクル — Init/Invoke/Shutdownと凍結・解凍Lambdaの実行環境はInit→Invoke→Shutdownという決まった一生をたどり、呼び出しの合間の「凍結・解凍」がウォームスタートの速さとクセの両方を生み出します。
- 18コールドスタートの解剖 — 何に時間がかかっているのか「コールドスタート」は一つの遅延ではなく、ハンドラが動く前の3つの作業(環境作り+初期化)の合計です — 分解して見れば、どの時間をどう削ればよいかが図で追えます。
- 19同時実行の正体 — 1環境1リクエスト、並行数だけ環境を複製するLambdaの同時実行は「スレッドを増やす」のではなく「実行環境を丸ごと複製する」——その仕組みを6つの図で追います。
- 20スケーリングの上限とレバー — アカウント上限・予約・プロビジョンドLambdaのスケーリングを「総量(水位)」と「速度(傾き)」の2軸で捉え、予約とプロビジョンドという2つのレバーが何を変えているのかを図で追います。
- 21呼び出しの3経路(1) 同期と非同期 — 内部キューとリトライの仕組みLambdaの呼び出しは「応答を待つ同期」と「待たない非同期」に分かれ、非同期ではキュー・リトライ・DLQ・宛先という仕組み一式がエラー処理の責任を肩代わりします — その内部を図で追っていきましょう。
- 22呼び出しの3経路(2) イベントソースマッピング — Lambdaが自分でポーリングするイベントソースマッピングは「Lambdaが自分でポーリングして、レコードをバッチにまとめてから関数を呼ぶ」プル型の呼び出し経路です。その仕組みを5つの図で追います。
- 23メモリという名のCPUダイヤル — リソース比例配分の設計Lambdaの性能設定が「メモリ1本」に見える理由を、比例配分の仕組み(cgroups)とコストの逆説まで図で追っていきます。
- 24デプロイの実体 — zipとコンテナイメージは何をどこに置くのか「Lambdaにデプロイする」とは、コードというファイルを実行ホストへ運べる1つの塊に固めて置くこと——その塊の作り方(zip/コンテナイメージ)、置き場所、そして運ぶコストが効く瞬間を図で追います。
- 25VPC接続の仕組み — Hyperplane ENIという共有の出入口Lambda関数はあなたのVPCに引っ越すのではなく、共有の出入口「Hyperplane ENI」を通じてあなたのVPCへトンネルします。その一本の通路が、スケール・コールドスタート・インターネット到達性のすべてを説明します。
- 26実行ロール — プロセスに一時認証情報を注入するLambda関数が秘密鍵をコードに書かずにAWSを操作できる原理を、実行ロールと一時クレデンシャルの流れで図解します。
S3編
- 27S3はファイルシステムではない — キーとフラットな名前空間S3はフォルダのある「ファイルシステム」ではなく、キー1本でオブジェクトを引き当てるフラットなキーバリューマップである — その原理を6つの図で追います。
- 28オブジェクトの正体 — データ+メタデータ+キー、そして丸ごと置き換えの世界S3のオブジェクトを「バイト列+メタデータ+キー」という構成と「変更は常に丸ごと置き換え」という性質の2本柱で、図を追いながら原理から理解します。
- 29マルチパートアップロード — 巨大データは分割して並列に運ぶマルチパートアップロードは「大きなデータを分割して並列に運ぶ」一手で、スループットの壁とやり直しコストを同時に解決する仕組みです。5枚の図で原理を追いましょう。
- 30イレブンナインの耐久性 — ディスクは壊れる前提で設計する「S3は壊れないから11ナイン」ではなく「壊れる前提で、コピーの分散・確率の掛け算・速い修復・チェックサム検証を積み重ねるから11ナイン」——その仕組みを6つの図で追います。
- 31耐久性と可用性は別物 — データが消えないことと、今すぐ読めることS3の比較表では耐久性が全クラス11ナインで横一線なのに、可用性だけクラスごとに差がつく——この「矛盾」を、二つの数字が測っている別々のものから図で解きほぐします。
- 32ストレージクラスの正体 — 安さは取り出しの遅さと引き換えの記憶階層S3のストレージクラスは複雑な料金表に見えて、実は「速い記憶は高い・遅い記憶は安い・層を移すにはコストがかかる」という記憶階層の物理法則がそのまま数字になったものです。
- 33S3の強い整合性 — 分散ストアが『書いたら読める』を保証する意味「書いたら読める」を分散ストレージで保証するとはどういうことか——S3の強い整合性の仕組みと、その保証の境界線を図で追います。
- 34プレフィックスとリクエストレート — 3,500/5,500の壁と自動スケールの仕組みS3の「3,500/5,500の壁」も自動スケールも503エラーも、内部の1つの仕組み — キー空間をプレフィックスで区切って並列に捌くパーティショニング — から図で追っていきます。
- 35バージョニングの内部 — 削除は削除ではなく『削除マーカー』の追記S3バージョニングの本質は「上書き・削除を一切せず、追記だけで状態を表現する」データ構造です——削除すら『削除マーカー』の追記である理由を、6つの図で追っていきます。
- 36サーバーサイド暗号化の内部 — オブジェクトごとの鍵と、鍵を包む鍵S3 のサーバーサイド暗号化を「オブジェクトごとの鍵」と「鍵を包む鍵」の二段構造で図解し、なぜその設計なのかを2つの理由から追います。
API Gateway編
- 37API Gatewayの正体 — マネージドなリバースプロキシAPI Gatewayの正体を「マネージドなリバースプロキシ」という一本の軸で捉え、3タイプの違い・WebSocketの仕組み・スロットリングの原理を図で追っていきます。
- 38リクエストはどこに届くのか — エッジ最適化・リージョナル・プライベートAPI Gatewayの3つのエンドポイントタイプは機能の違いではなく「DNSがどこを指すか」の違い — リクエストが最初に届く場所を図で追っていきます。
- 394段のリクエストパイプライン — メソッドリクエストから統合レスポンスまでAPI Gateway の REST API が 1 リクエストを 4 段のパイプラインでどう変換して返すかを、図で順番に追っていきます。
- 40統合タイプ — プロキシは素通し、非プロキシは翻訳API Gateway の5つの統合タイプは、同じ4段パイプラインの「真ん中2段」をどう扱うかだけの違い——それを図で追っていきます。
- 41認可の多層評価 — リソースポリシーとオーソライザーの合成API Gatewayの入口判断は一つの門番ではなく、リソースポリシーとLambdaオーソライザーという独立した部品の出力を規則で合成して決まります。その評価の順序と合成表を図で追いましょう。
- 42スロットリングはトークンバケット — レートとバーストの正体API Gatewayのスロットリングは「トークンバケット」アルゴリズムそのものです — バケツと水位の図を追うだけで、レート・バースト・429・多段制限のすべてが読み解けます。
- 43バケットは4階層 — 使用量プランとAPIキーによる客ごとの制限API Gateway の門番は「トークンバケット」1個ではなく4階層の入れ子で、APIキーと使用量プランで客ごとに配分する — その全体像を5枚の図で追う。
- 44ステージキャッシュ — 専用キャッシュインスタンスとキャッシュキーAPI Gatewayのステージキャッシュを、「実体のあるインスタンス」「TTL」「キャッシュキー」「無効化とフラッシュ」の5つの図で追っていく。
- 45デプロイは不変スナップショット、ステージはポインタ — ステージ変数とカナリアAPI Gatewayのデプロイ・ステージ・ステージ変数・カナリアリリースは、「不変のスナップショット」と「それを指すポインタ」という一つのモデルで全部つながります。
メッセージング編
- 46SQSは1台のキューではない — 冗長格納が生む at-least-once とベストエフォート順序SQSの「キュー」の正体は複数AZにまたがるサーバー群への冗長格納です。この物理的な事実から、なぜ同じメッセージが2回届き、なぜ順序が保証されず、なぜ1回のReceiveで全部が返ってこないのかまでを、上から下へ図で追っていきます。
- 47可視性タイムアウトはロックである — 削除されない、見えなくなるだけReceiveしたメッセージがなぜ「消えない」のか、そして消費側が途中で死んでも失われないのはなぜかを、1本のメッセージのライフサイクルを図で追っていきます。
- 48FIFOキューはなぜ遅いのか — メッセージグループIDが順序と並列性を分割するFIFOキューの「順序保証」が実は何のスコープで効いているのか、そしてそのスコープがそのままスループットの上限になる仕組みを、上から下へ図で追っていきます。
- 49SNSはpub/subの配達員 — トピックが1通をN通に複製するSNSのトピックに1通を発行すると、それがサブスクリプションの数だけ複製されて別々のエンドポイントへ配られる——その「1通→N通」の流れと、なぜSNS+SQSという定番構成が生まれるのかを、注文処理の例で図に追っていきます。
- 50プッシュ配信の宿命 — SNSは再試行し尽くすと捨てるSNSに送ったメッセージが受信側の障害でどう扱われ、最後にどこへ行き着くのかを、配信ポリシーの4フェーズを図で追っていきます。
- 51Kinesisは追記ログ — 読んでも消えないから複数の読者が独立に進めるKinesisが「読んでも消えないログ」であること、そして複数の読者が互いに邪魔せず同じデータを進めるしくみを、上から下へ図で追っていきます。
- 52パーティションキーとシャード — MD5ハッシュがストリームを水平分割するKinesisのストリームがどうやって1本の流れを複数のシャードに分け、なぜ「同じパーティションキーだけ」が順序を持つのかを、レコードが入る瞬間から図で追っていきます。
- 53拡張ファンアウト — 共有2MB/sの奪い合いをHTTP/2プッシュで解消するDynamoDB編・Lambda編で見てきた「追記ログを何者が読むか」の総仕上げとして、Kinesisのシャードから複数のコンシューマがデータを受け取る2つの経路——pullで帯域を分け合う共有スループットと、pushで専用帯域をもらう拡張ファンアウト——を図で追っていきます。
- 54EventBridgeはイベントルーター — ルールのパターンマッチが配線を置き換えるイベントが発行者から宛先へ届くまでを、「チャネルを選んで送る」のではなく「1本のバスに流してルールが仕分ける」流れとして図で追っていきます。
- 55配信保証の地図 — 4つのサービスを同じ物差しで並べるSQS・SNS・Kinesis・EventBridgeを『配信保証・順序・push/pull・保存の性質』という4本の物差しで並べ、どれをいつ使うかが暗記でなく導出になる様子を図で追っていきます。
認証暗号編
- 56IAMはデフォルト拒否の判定機である — 明示的Deny > Allow > 暗黙のDenyすべてのリクエストは最初から拒否されている、という前提から出発するIAMの判定コードが、どんな順番で「例外的に許可してよいか」を確かめていくのかを図で追っていきます。
- 57ポリシーには2つの役割がある — 権限を『与える』ポリシーと上限を『切る』ポリシーAWSのポリシーは現在9種類ありますが、その一つひとつを暗記する必要はありません。すべては「権限を与える」か「上限を切る」かの2分類に収まり、片方は和集合、もう片方は積集合という集合演算で評価されます。この2つの演算がそのまま許可判定のロジックになっている様子を、図で追っていきます。
- 58ロールは借りる帽子である — 信頼ポリシーと許可ポリシーの2枚で1つIAMロールが「パスワードを持たないのに、なぜAWSにアクセスできるのか」を、誰かがロールをかぶってから権限を得るまでの流れを図で追っていきます。
- 59STSは期限付きの鍵の発行所である — AssumeRoleが返す3点セット前レッスンで「ロールをかぶる」と言ったその瞬間、AWSの内部で何が返ってくるのか——AssumeRoleのレスポンスに詰まった一時認証情報の中身と、なぜそれが「配らない・埋め込まない・取り消さなくていい」を同時に満たすのかを、図で追っていきます。
- 60AWSへのリクエストは毎回署名される — SigV4のHMAC導出チェーンAWSにAPIリクエストを送るたび、シークレットキーは一度もネットワークに流れないのに「本人だ」と証明できます。その仕組みを、リクエストの正規化からHMACの鍵導出チェーンまで図で追っていきます。
- 61封筒暗号 — データはデータキーで、データキーはKMSキーで守る「鍵を暗号化する鍵も守らなければならない」という無限後退を、AWS KMSがどう断ち切るのか——大きなデータを暗号化する一連の流れを、上から下へ図で追っていきます。
- 62KMSキーは外に出ない — 鍵を渡さず『操作を頼む』APIの設計「鍵をください」ではなく「この暗号化をやってください」——KMSのAPIがなぜこの形になるのか、鍵が一度も外に出ない内部構造を上から下へ図で追っていきます。
- 63KMSの認可は二重扉である — キーポリシーが主、IAMは従すべてのKMSキーがちょうど1つ必ず持つ「キーポリシー」を軸に、IAM・グラントという3つの扉がどう協調して初めてキーが使えるのかを、上から下へ図で追っていきます。
- 64封筒暗号は現場で動いている — S3 SSE-KMSとEBS暗号化の内側S3編で「鍵を包む鍵」として学んだエンベロープ暗号化が、SSE-KMSとEBS暗号化という2つの現場で実際にどう動くのかを図で追っていきます。
- 65セキュリティ4つの問いの地図 — 誰か・何をしてよいか・改ざんは・盗み見は1本のAPIリクエストが AWS に届いてから許可されるまでを縦に追いながら、「誰か」「何をしてよいか」「改ざんは」「盗み見は」という4つの問いに、それぞれどの仕組みが答えているのかを1枚の地図にまとめていきます。
可観測性編
- 66メトリクスは名前つきの時系列である — 名前空間×名前×ディメンションが1本の線を決めるCloudWatchの「メトリクス」という言葉に身構える必要はありません。その正体は時系列データベースのデータモデル——「どうやって1本の線を一意に決めるか」というルールの集まりです。名前空間・名前・ディメンションの3つがどう組み合わさって1本の時系列を指し示すのか、そこから何が引けて何が引けないのかを、図で追っていきます。
- 67古い数値は粗くなる — 1分→5分→1時間へロールアップしながら15ヶ月残すメトリクスが「新しいうちは細かく、古くなると粗く」変わっていく仕組みを、解像度と保持期間の階段を図で追っていきます。
- 68平均は嘘をつく — p99が語る、平均が隠す遅いリクエストの世界CloudWatchが返すのは生のデータではなく「period内の統計」だけ——その要約が何を語り、何を隠すのかを、平均が嘘をつく瞬間から図で追っていきます。
- 69アラームは3状態の状態機械である — M out of N評価と欠落データの4つの流儀CloudWatchアラームがどうやって「鳴る/鳴らない」を決めているのか——状態の遷移、N個中M個の数え方、そしてデータが来なかったときの4つの流儀を、上から下へ図で追っていきます。
- 70ログは追記専用のストリームの束である — Lambdaの標準出力がロググループに届くまで関数のコードが print するだけで、なぜCloudWatchのコンソールにログが並ぶのか。その1行が「ログイベント → ログストリーム → ロググループ」という3階層をどう昇っていくのか、そして途中で失敗する最頻トラブルまでを図で追っていきます。
- 71ログとメトリクスの境界は溶ける — 抽出(メトリクスフィルタ)と埋め込み(EMF)という2つの変換「イベントの記録」であるログから「数値の時系列」であるメトリクスが生まれる2つの経路を、上から下への変換の流れとして図で追っていきます。
- 72トレースIDはリレーのバトンである — 相関IDが分散システムに因果の鎖を通す1本のリクエストが複数のサービスをまたいで走るとき、X-Rayがどうやって「これは全部同じリクエストだ」と束ね直すのかを、IDがヘッダで運ばれていく様子から図で追っていきます。
- 73サービスマップは観測から自動で描かれる — セグメントの集計が有向グラフになる誰もアーキテクチャ図を描いていないのに、なぜX-Rayのコンソールにサービスの地図が現れるのか——1本1本の観測データがどう突き合わされて1枚の有向グラフになるのかを、図で追っていきます。
- 74観測は主役を邪魔しない — リザーバ+固定レートのサンプリングとUDPの割り切り全リクエストを追わずに、それでも代表的な像を得る——X-Rayのサンプリングと、観測データをアプリの外へ逃がすデーモンの設計を、リクエスト1本がたどる道として図で追っていきます。
- 75可観測性は3本柱の地図である — 数える・記録する・つなぐ、そしてこのコースの答え合わせ1つの遅いリクエストの調査を題材に、可観測性の3本柱(メトリクス・トレース・ログ)がどう繋がって「いつから・どこで・何が」を突き止めるのかを図で追っていきます。そして最後に、このコース全編で見てきた「マネージドサービスの中身はコンピュータの基礎でできている」を1枚の地図で答え合わせします。
コンテナ編
- 76コンテナは隔離されたプロセスである — namespacesが見える世界を分け、cgroupsが資源を配るコンテナの正体は「特別な箱」ではなく「隔離されて動く普通のプロセス」です。ホストのカーネルを共有しながら、namespacesで見える世界を分け、cgroupsで使える資源を配る——その2つのカーネル機能の役割分担を図で追っていきます。
- 77イメージはレイヤーの積み重ねである — 読み取り専用の差分とcopy-on-writeが不変を支えるDockerfileの命令がどうやって読み取り専用の層に変わり、その上で走るコンテナが下の層を一切汚さずに動くのか——イメージの断面を上から下へ図で追っていきます。
- 78ECRは内容のハッシュで引く倉庫である — タグは動く名札、ダイジェストは動かない指紋ECRのなかで、なぜ「タグは動く名札」で「ダイジェストは動かない指紋」になるのか、イメージの指し方が2通りある理由を図で追っていきます。
- 79タスク定義は設計図、タスクは実体である — クラスター・サービス・タスクの3層と宣言の分離DynamoDB編のパーティションキー、Lambda編の関数設定と実行環境と同じ「宣言と実体の分離」が、コンテナではどう現れるか。ECSの登場人物を、宣言側(何を動かしたいか)と実体側(いま動いているもの)に仕分けながら、1枚ずつ図で追っていきます。
- 80スケジューラは差分を埋め続ける制御ループである — desired countと現実のずれが仕事のリストECSサービスの中心には「望ましい状態」と「現実」を突き合わせて差分を埋め続ける1つのループがあります。この回では、そのループが何を観測し・どう差分を計算し・どんな順序で行動するのかを、上から下へたどる図で追っていきます。
- 81Fargateは1タスク=1つの小さなVMである — Lambdaと同じFirecrackerが境界を引くECSの起動タイプを「分離の境界線はどこに引かれているか」という1つの問いで貫きながら、EC2起動タイプの同居からFargateのmicroVMまでを図で追っていきます。
- 82タスクは2枚のロールを持つ — 荷物を運ぶ胴元の権限と、中で働くアプリの権限Lambdaでは実行ロールは1枚でしたが、ECS/Fargateのタスクには性質の違うロールが2枚あります — なぜ2枚に分かれるのか、その2枚がどう配られ、どちらが足りないと何が壊れるのかを図で追っていきます。
- 83サービスはロードバランサに自分で名乗り出る — ターゲットグループへの動的登録と自己修復の連携タスクは数分で入れ替わり続けるのに、なぜ利用者はずっと同じURLで届くのか——「名前は安定、実体は流動」を支える動的登録と、二系統の健康判定がどう連携して自己修復になるかを、図で追っていきます。
- 84デプロイは健康なタスクの入れ替え算である — 最小/最大ヘルス率、そしてBlue/Greenのポインタ切り替え新しいリビジョンへの移行を「制約付きの入れ替えアルゴリズム」として、2つのつまみ・丸めの落とし穴・失敗検知・そして環境ごと差し替えるBlue/Greenまで、図で追っていきます。
- 85コンテナはコンピュータ基礎の見本市である — OSの隔離から分散の制御ループまでの地図1つのWebアプリが「イメージのビルド」からユーザーに届くまでを1本の縦断図で追い、その各段に本編で学んだCS基礎(隔離・ハッシュ・宣言と実体の分離・制御ループ・最小権限・自己修復・アトミック切り替え)がどう再登場するかを図で確かめていきます。これはコンテナ編の総括であり、このコース全体の答え合わせです。
Step Functions編
- 86ワークフローは有限状態機械である — 状態と遷移を宣言するとコードから制御の流れが消えるStep Functionsの正体は「有限状態機械の実行系」です。ワークフローを状態と遷移の集まりとして宣言すると、なぜコードからif/for/try-catchが消え、コンソールが図を自動で描けるのか——その仕組みを図で追っていきます。
- 87実行は追記されるイベントログである — 出来事の記録が『途中から再開』を可能にするStep Functions の Standard 実行が「クラッシュしても続きから」を実現できる理由を、実行の内部で積み上がる出来事のログを図で追っていきます。
- 88StandardとExpressは帳簿の付け方が違う — exactly-onceは毎遷移の永続化の対価であるStep Functionsの2つのワークフロータイプの違いを、「実行状態を毎回の状態遷移ごとに永続化するか、しないか」というたった1つの設計判断から図で追っていきます。
- 89タスクには3つの待ち方がある — 即答・完了待ち・呼び戻しをResourceの接尾辞が切り替えるTask状態が外部サービスと付き合うとき、実は「いつ次の状態へ進むか」という1つの問いしかありません。その答えがResourceフィールドの接尾辞に現れる——この対応を図で追っていきます。
- 90RetryとCatchはエラーの分類器である — 指数バックオフとジッターが宣言で書けるエラー処理を「エラー名で分類 → 分類ごとに方針を宣言」という仕組みとして、Step Functionsのステートマシン定義の中で図で追っていきます。
- 91Parallelは分岐して合流する — 全ブランチの完了を待つAND合流と道連れの失敗Parallel状態がひとつの入力を複数のブランチに配り、全ブランチの完了を待ってから合流し、そのうち1つが失敗したときに何が起きるのかを、fork/joinの図で追っていきます。
- 92Mapは反復を子に分ける — インラインの40並列と、履歴ごと分離する分散モードの10,000並列同じステップをデータの数だけ並べる「データ並列」が、なぜ2つのモードに分かれるのか——インラインの40並列と分散モードの10,000並列を、履歴という追記ログの設計問題として図で追っていきます。
- 93タスクトークンは呼び戻しの合言葉である — ポーリングせずに人間の承認を1年待てるワークフローを止めて外の世界(人間の承認・サードパーティ・レガシー)に仕事を投げ、「合言葉」を持った者だけがそれを起こせる——waitForTaskTokenパターンの流れを、1枚ずつ図で追っていきます。
- 94Sagaは打ち消しで巻き戻す分散トランザクションである — 補償の連鎖をCatchで宣言する単一DBならロールバック1命令で消える「なかったこと」を、複数のマイクロサービスを跨ぐと自分で逆再生の物語として書かねばならない——その巻き戻しをStep FunctionsのCatchでどう宣言するかを、図で追っていきます。
- 95オーケストレーションは指揮者、コレオグラフィは群舞である — 中央の楽譜と疎結合なイベントの使い分け地図同じ「注文処理」を、中央の指揮者が楽譜を持って各サービスを順に呼ぶやり方と、指揮者を置かず各サービスがイベントを発行して勝手に踊るやり方の2通りに描き分け、どちらをどこで使うのかを図で追っていきます。
キャッシュ編
- 96キャッシュは局所性への賭けである — 遅延読み込みとライトスルー、2大戦略の対価表キャッシュとは「よく使うデータのコピーを、速い場所にあらかじめ置いておく」賭けだ——その賭けをどう管理するかで生まれる2大戦略(遅延読み込みとライトスルー)と、両者の欠点を埋めるTTLを、公式の擬似コードを箱と矢印に翻訳しながら図で追っていきます。
- 97MemcachedとValkey/Redisは速さの出し方が違う — マルチスレッドの単純KVとシングルスレッドのデータ構造サーバーElastiCacheがなぜ2系統のエンジンを提供するのか、「同じインメモリkey-valueストア」に見える2つが実は正反対の設計思想でできていることを、公式の選択基準と2つの証拠(リーダーボードとpub/sub)を図で追っていきます。
- 98キー空間は16,384のスロットに切られている — ハッシュで住所を決める水平分割の再登場1台のサーバーに収まらなくなったキャッシュを、Valkey/Redis OSS のクラスターモードがどう分割するのか——キー→スロット→シャードという住所の決め方を、図で追っていきます。
- 99満杯のキャッシュは忘れることで生き延びる — maxmemoryポリシーのLRU/LFUとホットキーという偏りキャッシュのメモリが上限に達したとき「何を忘れるか」がどう決まるのか、そしてハッシュで均しても残る2つ目の偏り=ホットキーがどこで生まれるのかを、図で追っていきます。
- 100DAXはDynamoDB専用のライトスルーキャッシュである — 結果整合性しか返せない理由まで設計から導けるレッスン1で並べた「ライトスルー・TTL・LRU・レプリケーション」という語彙が、DAXという1つの製品にどう全部実装されているか、そして「なぜDAXは強い整合性を自分では返せないのか」を、リクエストが流れる図で上から下へ追っていきます。
- 101CloudFrontは多段のキャッシュでオリジンを守る — POP・リージョナルエッジキャッシュ・Origin Shieldの三段構え世界中に散らばったキャッシュが、ユーザーとオリジンのあいだにどう「木」を作るのか——1台のキャッシュではなく階層で守るしくみを、3枚の図で追っていきます。
- 102キャッシュキーは『同じリクエスト』の定義である — キーを最小にするほどヒット率は上がるキャッシュ設計は「何を保存するか」より先に「何をもって同じリクエストとみなすか」を決める作業だ、という原理を、CloudFrontのキャッシュキーを図で追っていきます。
- 103エッジのコンテンツ更新には3つの伝え方がある — 期限で待つ・無効化で消す・名前を変えるCloudFrontのエッジに一度置いたコンテンツを「どうやって新しくするか」——期限で待つ・無効化で消す・名前を変える、という3つの手段がそれぞれ何を犠牲に何を買っているのかを、図で追っていきます。
- 104署名付きURLとOACは2枚の通行証である — ビューワーの入口とオリジンの裏口を別々に閉めるキャッシュから速く配りつつ、選ばれた人にだけ配る——CloudFrontのプライベート配信を「守るべきドアが2つある」という一点で図に追っていきます。
- 105キャッシュはどの層にも置ける — ブラウザからDB前段までの地図と、新しさという対価1つのリクエストがあなたの指からDBに届くまでの全経路を1枚の地図にして、本編で学んだキャッシュを各層に置いていきます。そして「速さの対価に何を払っているのか」を、上から下へ図で追っていきます。
VPCネットワーク編
- 106VPCは32bitの数値空間の区画である — CIDRという『ネットワーク部/ホスト部』の線引きマネージドの仮想ネットワークを作るとき最初に求められる「10.0.0.0/16」という呪文が、実は32bitの整数をどこで折るかという2進数の算数だったことを、ビット列の図で追っていきます。
- 107サブネットは1つのAZに閉じた小区画である — AWSが各サブネットで先取りする5つのアドレスVPCという大きなアドレス空間を、さらに小さな区画に切り分け、その一つひとつを物理の場所(AZ)に貼り付ける——その仕組みを図で追っていきます。
- 108ルートテーブルは行き先ごとの案内板である — 最長プレフィックス一致と、サブネットを『パブリック』にする1行VPCの中で1つのパケットが「どこへ送られるか」がどう決まるのか、たった数行の表を上から下まで追いながら、その1行1行がパケットの宛先IPと照らし合わされていく様子を図で追っていきます。
- 109セキュリティグループは会話を覚えている門番である — ステートフルと『許可だけ』の設計リソースに一番近い防壁が「一度通した会話」をどう扱うのかを、往路と復路の2本の矢印で図で追っていきます。
- 110ネットワークACLは番号順の検問所である — ステートレスゆえに戻りの通行証も書くセキュリティグループの隣にもう1つある防壁「ネットワークACL」を、サブネットの入口に立つ番号順の検問所として図で追っていきます。
- 111NATは少ないパブリックIPを大勢で分け合う仕組みである — IGWの1:1変換とNATゲートウェイの多:1変換プライベートIP(10.0.x.x)はインターネットでは通用しない——では外と話すとき、誰がアドレスを書き換えているのか。境界で起きる2種類の付け替えを、上から下へ図で追っていきます。
- 112VPCエンドポイントはAWSサービスへの私道である — ルートで曲げるゲートウェイ型とENIを置くインターフェイス型「プライベートサブネットからS3に行きたい。NATを通るしかないのか?」——この問いに、VPCエンドポイントという2つの私道の作り方を図で追っていきます。
- 113VPCのDNSは+2番地に住んでいる — Route 53 Resolverと『VPCの中だけの名前』VPCの中でホスト名がどうやってIPアドレスに変わるのか、その問い合わせがどこに届いて誰が答えているのかを、住所と流れの図で追っていきます。
- 114LambdaとECSタスクはENIという足でVPCに立つ — Hyperplane ENIの共有とawsvpcの専用ENI「サーバーレスやコンテナはどうやってVPCに現れるのか」を、Lambdaの共有ENIとECSの専用ENIという2つの足の作り方で図で追っていきます。どちらも部品はENIひとつで、本編で組み上げたSG・ルートテーブル・NAT・DNSがそのまま全部効きます。
- 1151つのリクエストはVPCの中で何度も審査される — DNS・ルート・NACL・SGを貫く旅の地図プライベートサブネットのアプリが放つ3種類のリクエストが、VPCの中でどんな検問を何度もくぐって目的地に着き、そして帰ってくるのか——本編で組み立ててきた全部品を1枚の地図に置いて追っていきます。
デプロイ編
- 116CloudFormationは『あるべき状態』を書く言語である — テンプレート(宣言)とスタック(実体)の分離手作業やスクリプトが「この順でこのAPIを呼べ」と手順を書くのに対し、CloudFormationは「何が欲しいか」だけを書く——その宣言と実体がエンジンでどうつながるのかを、図で追っていきます。
- 117テンプレートは依存グラフ(DAG)である — Refが張る暗黙の辺と並列作成の順序「リソースはどの順で作られるのか?」——この問いの答えが実はグラフ理論だという話を、テンプレートを頂点と辺の集まりに読み替えながら図で追っていきます。
- 118変更セットは『実行前の差分』である — 更新の3段階(無停止・中断・置換)とロールバックテンプレートを直したときCloudFormationが「今の状態」と「提出された状態」をどう突き合わせ、どのリソースをそのまま書き換え・どれを作り直すかを事前に見せてくれるのか——更新を「差分計算」として図で追っていきます。
- 119ドリフトは宣言と現実のずれである — 検出という照合作業とスタックポリシーという安全柵CloudFormationのテンプレートに「こうあるべき」と書いた状態と、いま実際にAWS上にある状態がずれる問題を、検出の仕組みと防止の仕組みの両面から図で追っていきます。
- 120SAMはCloudFormationの方言である — Transformという『テンプレートを生成するテンプレート』SAMを「別のデプロイツール」ではなく「CloudFormationのマクロ」として、短い宣言が定型部分ごと展開されていく変換の前後を図で追っていきます。
- 121Lambdaのカナリアは重み付きエイリアスでできている — 確率でトラフィックを割り、アラームで引き返すLambda編で「バージョン=イミュータブルなスナップショット、エイリアス=可変なポインタ」と学びました。この回はその答え合わせ——1つのポインタの重みだけを動かして新旧を同時に生かす「カナリア」の仕組みを、下から上への確率の流れとして図で追っていきます。
- 122CodeDeployはデプロイをライフサイクルイベントの列にする — appspecという台本と3つの舞台デプロイという「止めて・配って・起動して・検証する」作業を、CodeDeployがどうやって固定されたイベントの列に変え、その各ステップの中身だけをappspecという台本で差し替えるのか——EC2・Lambda・ECSの3つの舞台で台本の意味がまるで違うところまで、図で追っていきます。
- 123パイプラインはステージを流れる工場のラインである — アーティファクトの受け渡しとbuildspecの4フェーズCodePipelineの「1つの変更がIDを持ってステージを順に流れ、ステージ同士はS3経由でファイルを渡す」という背骨を1枚の図で追い、後半はその中で実際にビルドを走らせるbuildspecの4フェーズを図で追っていきます。
- 124Elastic Beanstalkの5つのデプロイポリシーは『速さ・容量・安全』の交換である — all at onceからtraffic splittingまでElastic Beanstalkのデプロイポリシーは5つあるように見えて、実は「既存インスタンスをどう扱うか」という1本の軸の上に並んだ5つの点にすぎません。その軸を「箱の中身を入れ替えるか、箱ごと替えるか」で図に追っていきます。
- 125デプロイとは『宣言・差分・段階的切り替え』である — 1つの変更がリリースされるまでの地図1行のコード変更が、コミットからユーザーに届くまでにどんな部品を通り抜けるのか——この編で見てきた全部品を1枚の地図に並べ、上から下へ追っていきます。VPC編の総括が「1つのリクエストがどこを通るか」という空間の地図だったのに対し、こちらは「1つの変更がどう届くか」という時間の地図です。
アプリ認証編
- 126Cognitoは2つの別の仕事を1つの名前で売っている — ユーザープール(誰か)とIDプール(AWSへの切符)「Cognito」という1つの名前の裏で、まったく別の2つのサービス——「あなたが誰かを証明する窓口」と「その証明をAWSの一時認証情報に両替する窓口」——が動いていることを、公式の定義と2本の矢印で図に追っていきます。
- 127JWTは3つの箱がドットでつながった文字列である — 構造とJWKSによるオフライン署名検証ユーザープールが発行したJWTを1文字ずつ分解し、なぜ「中身は誰でも読めるのに偽造だけはできない」のか、そして受け取った側がCognitoに問い合わせずにその真正性を確かめる手順を、上から下へ図で追っていきます。
- 128Cognitoは3枚の切符を配る — IDトークン・アクセストークン・リフレッシュトークンの役割分担サインインに成功したユーザーへCognitoが手渡す3枚のトークンを、「それぞれ何のための切符なのか」で腑分けし、短命な2枚と長命な1枚という非対称な設計を図で追っていきます。
- 129パスワードを送らずに証明する仕組みがある — SRPというゼロ知識に近い認証と、OAuthの認可コードフロー「ログインする」という一言の裏で、パスワードそのものは本当にネットワークを流れているのか——SRPという「送らずに証明する」認証と、OAuthの「コードを引換券にする」認可コードフローという2つの経路を、リクエストのパラメータを1つずつ追いながら図で見ていきます。
- 130IDプールはトークンをSTSの一時認証情報に両替する — 拡張フローとロールマッピングIdPが発行したトークンがIDプールに入り、ロールが選ばれ、STSの一時認証情報になって出てくる——この一直線の変換パイプラインを図で追っていきます。
- 131API Gatewayはトークンを2つの流儀で検証する — CognitoオーソライザーとJWTオーソライザーAPI Gateway編では「オーソライザーがリクエストを通すか弾くか」までを見ましたが、今回はその一段深く、Authorizationヘッダーに載ったトークンの中身を、いったい誰が・どう検証しているのかを図で追っていきます。
- 132Secrets Managerのローテーションは4段階の手続きである — createSecret・setSecret・testSecret・finishSecretとAWSCURRENT/AWSPENDING/AWSPREVIOUSこれまでのアプリ認証編は「IAMのAWSアクセスキー」を扱ってきましたが、今回は主題を「DBパスワードのようなアプリ自身の秘密」のライフサイクルに移します。Secrets Managerがパスワードを自動で入れ替えるとき、内部では公式に定められた4段階の手続きが順に呼ばれ、3つのラベルが版を渡り歩きます。その様子を図で追っていきます。
- 133SSMパラメータストアは設定と秘密の両方が住める階層的な名前空間である — String/SecureStringと標準/詳細の使い分けアプリの設定値やDBの接続文字列を、コードに埋め込まず一箇所で管理したい——そのための「名前付きの値の保管庫」であるSSMパラメータストアが、プレーンな設定とKMSで暗号化した秘密をどう同居させ、Secrets Managerとどこで役割を分けるのかを、図で追っていきます。
- 134秘密はどうアプリに届くか — Lambda環境変数の暗号化・ECSのsecrets・buildspecの参照を1つのカタログにするLambda・ECS・CodeBuild という3つの現場で「秘密がどう実行環境に届くか」を図で追い、そこに共通する『設定と秘密の分離』という1本の設計原則を抽出していきます。
- 135誰かの認証からアプリの秘密まで — 1つのログインが動くための全部品の地図1人のユーザーがログインボタンを押してからデータベースに辿り着くまで、その裏で何が起きているのかを1枚の地図として上流から下流へ図で追っていきます。