AWSの「ビルディングブロック」という考え方をレゴブロック等で理解する

はじめに

AWSのサービスは、完成した商品というより「部品」として作られています。
AWSはこの部品を「ビルディングブロック」、あるいは「プリミティブ(基本部品)」と呼んでいます。
2024年4月に公開されたAndy Jassy氏の株主書簡には
「AWSは240を超えるこうした部品を持つ」
と書かれています。

この記事では、ビルディングブロックという考え方を、AWSの公式資料と経営陣の発言から調べて、中学生でも読める言葉でまとめました。
読んだ資料は次のとおりです。

• Andy Jassy氏の2023年分株主書簡(2024年4月公開)
• Werner Vogels氏のre:Invent 2024での発言(SiliconANGLEの記事経由)
• AWS Well-Architected Frameworkの「疎結合」の項目と、信頼性の設計原則
• Serverless Applications Lens
• Amazon Builders' Libraryの「Reliability, constant work, and a good cup of coffee」

先に、この記事が最後に答える疑問を書いておきます。部品が増えるほど、組み立ては難しくなります。
AWSはその難しさをどう扱っているのかの伏線回収は最終章でやります。

ビルディングブロックとは何か

完成品セットとバラのブロック

レゴで考えると分かりやすくなります。レゴの買い方は2種類あります。

• 完成品セットを買う。説明書どおりに組めばお城ができますが、別のものは作りにくいです
• バラのブロックを買う。何でも作れますが、何を作るかも、どう組むかも自分で決めます

AWSは後者を選びました。
AWS側の言葉では、前者が「フレームワーク」、後者が「プリミティブ」です。

Vogels氏は、フレームワークは完成するまでに数年かかり、その間に世の中が変わってしまうことがあると話しています。
ブロックなら、今すぐ使えるほど柔軟です。

公式の定義

Jassy氏の書簡は、2003年のAWSのビジョン文書を引いて、プリミティブを次のように説明しています。

• 開発者にとって一番基本になる部品です
• これ以上分けられません
• 一つのことをとてもうまくこなします
• 組み合わせ方は使う人が自由に決めます

最初のブロックはS3とEC2

書簡が挙げている最初期のブロックは次の3つです。

• S3: 2006年3月
• EC2: 2006年8月
• SimpleDB: 2007年

書簡には、最初の数個を出した時点では
「お客様から見て脈絡がないように見えることがある」
とも書かれています。
S3が出たときの戸惑いが例として挙がっています。
ブロックの価値は、組み合わさった後に見えてきます。

主なブロックを身近なものにたとえる

AWSの代表的なブロックを、学校のものに例えてみます。
この記事に出てくる例えは、Builders' Libraryのコーヒーポットを除いて、すべて私が考えたものです。
AWSの公式な説明ではありません。

ブロック	本当の役割	例え
Amazon S3	ファイルを保存する	学校の大きなロッカー室
Amazon EC2	借りられる仮想のコンピューター	必要なときだけ借りるパソコン
AWS Lambda	出来事が起きたらプログラムを動かす	呼ばれたときだけ働くアルバイト
Amazon SQS	メッセージの待ち行列	整理券つきの受付
Amazon SNS	1回の発信を多くの宛先に届ける	一斉連絡網
Amazon EventBridge	出来事を振り分ける	校内放送の担当
AWS Step Functions	複数の作業を順番に進める	手順書を持った現場監督
Amazon DynamoDB	データを表の形でしまう	カード式の名簿棚

どのブロックも、一つの仕事しかしません。S3は保存だけ、SQSは待たせるだけです。

ブロックが増えると何が起きるか

できること

• 好きな組み合わせで作れます
• 1つのブロックを入れ替えても、他のブロックを作り直さずに済みます

難しくなること

ここからが、冒頭の疑問につながります。

• Vogels氏自身が、ブロックが増えても互いにうまく組み合わさるよう設計されているわけではないため、複雑さが生まれると認めています
• Jassy氏は、ブロックを作れば成功するとは限らないと書いています。作れるブロックは多く、組み合わせはさらに多いからです
• Jassy氏が挙げる方位磁針は、実際のお客様の困りごとを選ぶことです
• 意図してブロックを作るには、忍耐が必要だとも書いています

部品を増やすと、組み立ては使う側の仕事になります。
では、つなぎ方は何を目安にすればよいのでしょうか。
次の節で、AWSの公式な指針を見てみましょう。

つなぎ方の約束事(Well-Architected)

Well-Architected Frameworkは、AWSが多くのお客様の設計を見てきた経験から、設計の良し悪しを確かめる質問と原則をまとめたものです。
点数をつける検査ではなく、設計について話し合うための枠組みだと説明されています。

手渡しをやめてロッカーを使う(疎結合)

「REL04-BP02 疎結合な依存関係を実装する」という項目があります。
「疎結合」は、部品どうしをゆるくつなぐことです。

例えば、友達に直接手渡しすると、相手が席にいないと渡せません。
ロッカーに入れておけば、相手は自分の都合で取りに来られます。

項目の内容は次のとおりです。

• 部品は、公開され、バージョンが管理された約束(インターフェース)だけを知っていればよいです
• 相手の中身が変わっても、約束が同じなら影響を受けません
• 返事をすぐ待たなくてよいやり取りは、非同期(返事を待たない形)にします
• 間に入れる道具として、SQS、Kinesis、Step Functions、EventBridge、SNSが挙がっています

避けるべき例(アンチパターン)も4つ書かれています。

• 全部を一体のプログラム(モノリス)として動かします
• 層どうしがAPIを直接呼び合い、失敗時の切り替えも非同期処理もできなくなります
• 同じデータベースを共有して、結びつきを強くしてしまいます
• 受け側が処理しきれないのに、送り側を止められません(バックプレッシャーの無視)

この項目を実施しない場合のリスクは、公式文書で「High(高)」とされています。

大きな1つより小さな複数

信頼性の設計原則には、大きな資源1つを小さな資源複数に置き換える、という考え方があります。
1つが壊れたときの影響が小さくなるからです。

大型バス1台より小型バス5台のほうが、1台が故障しても全員が足止めされません。
ビルディングブロックの発想と同じ方向を向いています。

サーバーレスの7つの原則(Serverless Applications Lens)

Well-Architectedには、分野ごとの補足資料があります。
それを「レンズ」と呼びます。
Serverless Applications Lensはサーバーレス向けで、公開日は2022年7月14日です。
設計原則が7つ書かれています。

1. 速く、小さく、1つの仕事だけにします。関数は短く、目的を1つに絞ります
2. 総数でなく、同時に何件来るかで考えます。設計の比較は同時実行数が基準です
3. 何も持ち越しません。実行環境は短命で、手元に置いたデータは保証されないので、残したいものは永続ストレージに置きます
4. 特定のハードウェアに頼りません。土台の機械は入れ替わる前提です
5. 関数をつなぐのでなく、状態機械で動かします。関数の中から別の関数を呼ぶ連鎖は、一体型で密結合になります
6. 出来事をきっかけに処理を動かします。S3にファイルが置かれた、データが更新された、といった出来事が合図です
7. 失敗と重複を前提にします。同じ指示が2回届いても、結果が変わらない作りにします

7番目をたとえると、エレベーターの呼び出しボタンを2回押しても、来るエレベーターは1台です。

5番から7番はブロックのつなぎ方の話です。
1番、3番、4番は、1つのブロックの作り方の話です。
2番は、全体を見積もるときの見方です。

部品そのものを丈夫にする考え方(constant work)

Amazon Builders' Libraryの「Reliability, constant work, and a good cup of coffee」は、部品の中身の作り方を扱っています。
つなぎ方の話ではありません。

これは、状況によらず常に同じ量の仕事をするシステムは、負荷が急に変わっても壊れにくい
ということを言っています。

学校のチャイムです。必要な人がいるときだけ鳴らすのでなく、時間になれば必ず鳴ります。
忙しい日も暇な日も、鳴らす手間は変わりません。
記事自体は、来客数にかかわらず淹れ続けるコーヒーポットに例えています。

Route 53のヘルスチェック

• ヘルスチェッカーは、最大サイズに合わせた固定サイズの結果を、常に送ります
• DNSサーバーは、サイズが決まった状態表を数秒ごとに受け取り、メモリに置きます
• 問い合わせに答えるときは、状態が変わっても、常に全候補を同じ手順で調べます
• アベイラビリティーゾーン(AZ)が停電して、数千件のチェックが一度に失敗しても、処理の量は変わらず、動作が遅くなりません

Hyperplaneの設定配布

• ノードは、数秒ごとにS3から設定ファイルを取得し、毎回同じ内容を処理します
• 設定ファイルはダミーの枠を含めて最大容量に合わせてあり、変更されたロードバランサーが1台でも数百台でも仕事量は一定です

この方式は、壊れても次の周期で自然に直ります。
出来事をきっかけに動く方式では、状態の管理や、たまった処理の整理に複雑な仕組みが必要になります。
constant workは、それを避けられる方式です。

部品が増える難しさへの答え

冒頭の疑問に戻ります。
部品が増えるほど組み立ては難しくなりますが、AWSはそれをどう扱っているのか。
ここまで読んだ資料から、次のように整理しました。
この表の分け方は私の解釈です。

層	やること	読んだ資料の例
ブロックを選ぶ	小さく、1つの仕事をする部品を用意する	S3、SQS、Lambdaなど
つなぎ方を決める	ゆるくつなぎ、順番は状態機械に任せ、重複を前提にする	REL04-BP02、Serverless Lensの7原則
ブロックの動きを安定させる	負荷が変わっても同じ量の仕事をする	constant work

AWSは複雑さをなくそうとしていません。
複雑さが生まれる場所を「つなぎ目」に絞り、そこに決まりを置いています。
ブロックを細かくするほど、つなぎ目の設計と運用は使う側の仕事になります。
共有データベースやバックプレッシャーの無視といったアンチパターンは、その失敗例に当たると考えます。

疎結合は、つなぎ目で影響を止める考え方です。
constant workは、部品の中身を負荷の変化に動じない形にする考え方です。
2つは別の層で、補い合う関係に見えます。

この記事で確認できていないこと

• Jassy氏の書簡が引く2003年のビジョン文書そのものは、確認していません
• Vogels氏の発言は、SiliconANGLEの記事を通して確認しました
• Serverless Applications Lensは2022年版です。LambdaやStep Functionsの最近の機能追加は反映されていない可能性があります
• Lensのシナリオ別ページ(RESTful microservicesなど6つ)の詳細は読んでいません

最近ビルディングブロックという言葉をよく聞くことがあったので、自分の理解のためにも平易な言葉でまとめてみました。

最後まで読んでいただきありがとうございました。

参考資料

• Amazon CEO Andy Jassy's 2023 Letter to Shareholders
• AWS re:Invent 2024: Builder ethos embraces simplicity(SiliconANGLE)
• REL04-BP02 Implement loosely coupled dependencies
• Design principles - Reliability Pillar
• Serverless Applications Lens: Design principles
• Reliability, constant work, and a good cup of coffee