AWS上のシステム設計

パート III. システム設計の使用例

今提供される機能の90％は、決して提供されない機能の100％よりも優れている。

ブライアン・カーニガン、P・J・プラウガー

本書のパート III では、一般的なシステム設計のユースケースと例をいくつか取り上げており、AWS クラウド・コンピューティング・サービスの上に構築しスケールさせるために、一緒に取り組んでいく。すべてのユースケースについて、システム要件を把握することから始め、次にシステムコンポーネントの深堀りに移り、最後にAWSでのデプロイをDay 0アーキテクチャ（例えば1,000人の顧客を持つスタートアップのための最小実行可能プロダクト）とDay Nアーキテクチャ（数百万人の顧客へのスケーリング）で章を締めくくる。その過程で、設計で発生する可能性のあるボトルネック、大規模システムを設計するためのベストプラクティス、類似のAWSサービスの比較について議論する。

我々はMake It Work, Make It Right, Make It Fastの原則に従うことを推奨しており、パートIIIのすべての章はこの哲学に従っている。いつの日か10億人のアクティブユーザにサービスを提供する日が来ると楽観的に考えるのは良いことだが、この規模をサポートするために初日からシステムを構築する必要はない。巨大なスケールという目標があるからといって、製品の発売を躊躇するようなことがあってはならない。ただ、将来的にニーズがあれば、新しいユーザの加入や新機能の導入に合わせてシステムを進化させることができるよう、十分な拡張性を確保しておくことだ。例えば、以下のamazon.comの Webサイトのスクリーンショットは、Webサイトの初期化を示している。当時は、10億人の顧客に対してどのように機能させるかを考える意味はなかった。

Uberが元帳ストアを構築するためにAmazon DynamoDBを使い始めたが、後に特注のストレージ・ソリューションであるDocstoreに移行したように、システムを再設計する他の理由は、コストと演算子かもしれない。同じ原則が、あらゆるシステムのコンポーネントを考え出す際にも当てはまる。、目標は常に、システムを一般ユーザーの手に渡し、フィードバックを集めることであるべきだ。顧客の問題を解決し、最終的にそこから収益を得るというゴールに到達しないのであれば、システムを最適化しすぎても勝ち目はない。結局のところ、誰もが、設計したシステムから収益を得るか、（オープンソースプロジェクトのように）他の人々が収益を得るのを助けるためにビジネスをしているのだ。

第III部の各章は、この一般化されたアウトラインに従う：

1. はじめに

   1. 背景

   2. ビジネスユースケース

2. システム要件

   1. 機能要件と非機能要件

   2. システム規模

3. デザインから始める

   1. 概念と原則

   2. システム・コンポーネント

   3. 大まかなシステム設計

4. AWSでシステムを立ち上げる

   1. 0日目のアーキテクチャ

   2. 数百万人以上へのスケーリング

   3. N日目のアーキテクチャ

5. 結論

パートIIIが終わるころには、あなたはこうなっているだろう：

• システム設計の各問題に対するビジネスユースケースを理解し、要件を評価するための適切な質問方法を理解する。 ...