小規模ながらスケールするシステムを考える必要があるので。
クラウドというよりは分散処理の話でした。
分散処理の時代
クラウド技術が進歩し、大量のサーバーを用意するのが容易になった。
複数台で分散して処理をさせることで、高いスループットを出せるようになった。
ただし、複数台を運用すると故障確率も跳ね上がるようになるため対応が必須
ScaleOutとScaleUp
本当にスケールアウトの方がコスパがいいのか？
- 一台で積めるメモリ・CPUコアに限界があるので、大規模ではそもそも不可能。
- CPU単価が圧倒的に安い。
- ハードでの調整はベンダーしかできないが、ソフトでの調整なら誰でもできる。
- ソフトウェアは無限に複製できる。
※ただし、サービスによっては一台の高性能マシンの方がコスパがいいケースも当然ある。
分散処理の分類
大まかに、
- マスタースレーブ系（全体を管理するマスターがいる）
- 並列ノード系（全体を管理するものはいない）
があるかと。（名称は適当）
マスタースレーブ系
トランザクション処理系も原理的に扱える。
扱いやすい反面、マスターがSPOFであり、マスターのスケールはできない。
例：
- RDBのレプリケーション
- Google File System
- load Balancer？
並列ノード系
全体を管理するものがいないため、無限にスケールできる。
データの整合性は、多数決原理(quorum)・結果整合性、などで決定される。
システムのバランスを取ることと、データの整合性の確保は難しそう。
例： * Dynamo * KVS系のDBMS * ネットワーク？
CAP定理
全てを同時に満たすことはできないという定理。
スケールするシステムの場合、分散処理（P）は必須。
CとPを選んだ場合
→マスタースレーブ系
AとPを選んだ場合
→並列ノード系
ACIDとBASE
ACID
→RDBの考え方。データは常に正しいとする。CAPのうちCA。
BASE
→Dynamo系の考え方。結果整合性があれば良い。CAPのうちAP。
物理的距離の問題
物理的に離れているとネットワーク遅延が無視できなくなり、可用性を犠牲にするととても使い物にならなくなる。
書き込みと読み込みの問題
書き込みの際にトランザクション系を実装するならマスターは必須だが、読み込みの場合はマスターを経由する必然性はない。（ただし同期に一定の遅延が生じる恐れがある。）
高レイヤーへの集中
技術が進歩するにつれ、低レイヤーのことを考えることが少なくなる。（あるいは低レイヤーの領域が拡大する）
- マルチスレッド→順序に依存しない設計へ。
- マルチプロセス→共有コンテキストを使わない設計へ。
- マルチマシン→状態を持たない設計へ。
- 信頼できないマルチマシン→一人を信頼しない（結果整合性的）設計へ。