- クラウドデータサービスの未来は「大規模・マルチテナント」構造
- S3のような最上位のSaaSサービスが、シンプルさ、信頼性、耐久性、スケーラビリティ、低価格を提供できるのは、これらを実現するために技術的にそのような構造で設計されているため
- 大規模なリソースプールを通じて顧客にサービスを提供することは、スケールによる効率性と信頼性を保証する
[サーバーレス・マルチテナント（Serverless Multi Tenant）システムの定義]
「Multi-Tenancy」の定義
- マルチテナンシーとは、共有ハードウェア上でワークロードを共同配置し、リソースを共有することに関するもの
- クラウドでシステムを構築することは、複数のテナントが共有コンピューティングインスタンス（例: Amazon EC2 または Google Compute）や共有PaaSサービス（例: クラウドオブジェクトストレージ）からサービスを受けることを意味する
- マルチテナンシーを「共有リソース（仮想化サーバー、ドライブ、PaaSのビルディングブロックサービスなど）上で複数のテナントにサービスを提供すること」と定義する
- 複数のリソース共有モデルを利用でき、一部のシステムではコンポーネント全体で複数の共有モデルを組み合わせている
- 共有プロセス: 同一のソフトウェアプロセスが複数のテナントにサービスを提供する。データとセキュリティの分離は論理的
- コンテナ: 単一テナントノードを実行し、1ホストあたり複数のコンテナをパッケージ化する。一般的には Kubernetes によって実現され、特定の K8s ノードが多数のテナントの Pod をホストする
- 仮想化: VM（例: QEMU）または microVM（例: Firecracker）で単一テナントノードを実行し、1ホストあたり複数の VM をパッケージ化する。Kubernetes は Kata Containers を通じて VM と併用することもできる
- テナントが同じ V8 プロセスを共有しつつ、別々の軽量コンテキストで利用できる V8 アイソレーションの方法もあるが、データシステムでこれを見たことはまだない
サーバーレスの定義
- 顧客はサーバータイプを選択せず、ハードウェアを明示的に選ぶこともしない
- こうしたシステムは、顧客がハードウェアサイズを明示的に調整しなくても、あらゆるワークロード需要に対応できるよう、ある程度の弾力性と可動性に依存している
- 弾力性: ワークロードの必要に応じてサービスをスケールアップ/スケールダウンし、縮小/拡張できる機能
- 可動性: パフォーマンスと安定性の要件を満たすため、内部的にワークロードを移動・平準化できるサービス機能
- サーバーレスモデルは、顧客にとってますます重要になっている従量課金モデルを採用する
- 多くの顧客は事前に大きなコミットメントを結ぶことを望まず、単に使った分だけ課金されることを好む
- 従量課金には、ワークロードや基盤システムの実装に応じて大きく異なるさまざまなバリエーションがある
- （100万）オペレーションごとに支払う
- ワークロードの CPU とメモリ使用量に対して支払う
- ストレージ GB ごとに支払う
- リソースや作業速度に関連する仮想的な性能/容量単位（例: DynamoDB の RCU/WCU）に対して支払う
- 一定の基本容量について料金を支払い、それを超えた使用量について追加で支払うハイブリッドモデル（「基本料金＋ピーク課金」）
[共通の課題]
ワークロードが課す制約条件の中で設計する
- 特定のデータシステムのワークロードが課す多くの制約条件は、基盤アーキテクチャの重要な駆動要因となる
- レイテンシ/可用性要件
- 一貫性要件
- リクエストとデータの相関/依存関係
- シーケンシャルアクセスパターンとランダムアクセスパターン
- リクエストごとに実行される作業の多様性
- データサイズ
- セッション指向プロトコルとリクエスト指向プロトコル、プッシュとプルの仕組み
- 作業の計算負荷
- 緩いレイテンシ要件や一貫性要件は、エンジニアにより大きな自由度を与える
- 低レイテンシシステムでは高レイテンシのコンポーネント導入に制約があるため、クラウドオブジェクトストレージの低コスト性と高耐久性を活用するのはその好例
- Eventually Consistent なシステムは、データを同期的なデータのホットパスに含めず、オブジェクトストレージへ非同期に書き込むことで、このジレンマを回避できる
- 低レイテンシかつ強整合性を求めるシステムには、そのような免罪符はない
- 短いレイテンシのような制約が組み合わさると、ワークロードの空間的・時間的局所性がアーキテクチャ選択に影響することがある
- たとえば、シーケンシャルスキャンが特徴のワークロードでは、ディスク上で高速かつ効率的にスキャンできるよう、連続したデータ範囲を一緒に保持するのが望ましい
- こうした範囲をさらに小さなサブレンジに細分化するとホットスポット管理には役立つが、両者はトレードオフの関係にあるため、そのバランスを取る必要がある
- 個々のリクエスト間の相関がほとんどないランダムアクセスパターンでは、複数サーバーに均一かつ薄く分散できるフラットなアドレス空間の利点を活用できる
- 永続接続を確立するセッション指向プロトコルは、各リクエストが前のリクエストから独立しているリクエスト指向プロトコルと比べ、一般により難しい
- 永続接続では接続プーリングが必要になる場合があり、ローリングノードやデータバランシングのような撹乱が発生すると、クライアント側に外部から見える影響を与えることがある
- オブジェクトストレージや Kafka API のようなシンプルなストレージ API のシステムもあれば、SQL データベースのような計算集約型システムもある
- これは、各リクエストの処理に必要な作業量の予測可能性と変動性というテーマにつながる
- 極端な例として、連続したレコードブロックを単純に取得するだけの Kafka のようなデータストリーミング API があり、反対側にはクエリごとに作業量が大きく変わり得る SQL がある
テナント分離
- リソース共有はハードウェア利用率を高める一方で、あるテナントのワークロードが他のテナントへ影響を与えるリソース競合を引き起こすことがある
- マルチテナントシステムでは、共有ハードウェアリソースからサービスを受けるテナントに対しても、あたかも自分専用のサービスを利用しているかのような保証を提供しなければならない
ストレージとコンピュートの分離
- ストレージとコンピュートの分離は、これまで調査されたすべてのシステムが何らかの形で実装している中核的な設計原則
- ハードウェアトレンドにより、ストレージとコンピュートの分離はますます現実的になっており、その一因はネットワークが以前ほどのボトルネックではなくなっていることにある
- ネットワークスループットは向上しているが、クラウドオブジェクトストレージが優先されることで、この分離には依然として新たな課題が存在する
- クラウドオブジェクトストレージは依然として比較的レイテンシが高い一方、高耐久で低コスト
- しかし、OLTP データベースのように通常は低レイテンシを求めるワークロードへ導入するのは難しい場合がある
- また、クラウドオブジェクトストレージの経済モデルは、多数の小さなオブジェクトに依存する設計には不利であり、より少ないリクエストで大きなオブジェクトにデータを蓄積する必要があるため、低レイテンシシステムのライフサイクルをさらに複雑にする
- エンジニアは、低レイテンシシステムにオブジェクトストレージを組み込みつつ、低速なオブジェクトストレージの前段に耐久性と耐障害性のあるライトキャッシュおよび予測型リードキャッシュを配置することで、そのレイテンシ問題に対処できる
- この耐久性のあるライトキャッシュは、基本的にはレプリケーションプロトコルを実装し、ブロックストレージにデータを書き込むサーバークラスタ
- バックグラウンドで、クラスタはより少ない回数で大容量ファイルを書き込むという経済的なパターンに従い、データをオブジェクトストレージへ非同期にアップロードする
- fault-tolerant なライトキャッシュは低レイテンシの書き込みをうまく支援する
- このアーキテクチャで問題になり得るのはリードキャッシュ
- イベントストリーミングのようなシーケンシャルなワークロードでは、これは単純で非常に効果的
- Aggregate Prefetching（集約プリフェッチ）が需要に追いついている限り、読み取りは常にローカルのリードキャッシュに到達するはず
- データベースは予測しにくいランダムアクセスパターンのため、これより難しい問題に直面するが、テーブルスキャンは依然として先読みの恩恵を受けられる
- レプリケーションプロトコルで分散耐障害ライトキャッシュを実装することは決して簡単ではなく、マルチ AZ 環境では AZ 間通信料金のような追加コストが発生することもある
- しかし現時点では、低コストで高耐久なオブジェクトストレージを基盤データストアとして使いたい低レイテンシシステムにとって、代替手段はない
- 別の低レイテンシシステムは、クラウドオブジェクトストレージの利用自体を避けるべきであり、何よりも予測可能な短いレイテンシを優先する
- クラウドストレージは広く使われているが、レイテンシのトレードオフにより普遍的ではない
ヒート管理
- ヒート管理とは、レイテンシの急増や秒間処理数の低下といった外部から見える性能問題を引き起こすホットスポットを避けるため、複数のストレージノードにできるだけ均等に負荷を分散すること
- これをロードバランシングと呼ぶこともできるが、通常ロードバランサという用語はステートレスノードに対して使われる
- ステートフルシステムでは、高需要のオブジェクトが特定のストレージノードに集まり、競合を引き起こすホットスポットが発生し得る
- ロードバランサは、ランダム、最小接続、あるいは何らかの FIFO 変種のような単純な戦略で、ステートレスノード群に負荷を均等分散できるが、ステートフルシステムではデータの所在に応じてリクエストをノードへルーティングしなければならない
- 負荷を再分配するためにデータを移動することは、一般にリバランシングと呼ばれる
- さらに複雑なのは、負荷分布が時間とともに変化し得る点
- データ分散は、小さなデータ部分集合に影響する短期的なピークから、複数テナントにまたがる日次パターンや季節イベントによるより大きな負荷変動まで、あらゆるものに対処しなければならない動的プロセスになる
- 大規模データベースや高スループットのイベントストリームのような大規模データセットは、負荷を効果的に分散するためにシャーディングする必要がある
- リバランシングはシャードのリバランシングとなり、システムは負荷分布の変化に応じてシャードを分割・統合することもある
- しかし、シャード数やサイズに関しては、データ局所性のような相反する課題が存在し得る
- 一方では、データの共置が多いほど取得は効率的になる
- 他方で、多数のシャードから取得しなければならない計算処理のコストが、より多くのサーバーへ負荷を分散することで得られる利点を上回ることもある
- ヒート管理はシングルテナントシステムでも必要になることがあり、マルチテナント固有の問題ではない
- しかし MT データシステムでは、テナントがサービス品質の変動を経験しないようにするため、ヒート管理はさらに重要になる
高いリソース利用率の達成
- サーバーレス・マルチテナントアーキテクチャを実装する主な動機の1つは、基盤ハードウェアリソースをより効率的に使い、より良い経済性を提供すること
- リソースプーリングを通じてリソース利用率を高めることが最も重要だが、テナント分離と予測可能な性能を保ちながらこれを達成するのは難しい課題
コールドスタート
- テナント単位でリソースをゼロまで縮小するサーバーレスシステムは、テナントがワークロードを再開するときにコールドスタートの問題に直面する可能性がある
- コールドスタートは当初からサーバーレス機能の焦点であり、一部のサーバーレスデータシステムにも影響を与え得る
- 一部のシステムではコールドスタートがまったく発生しない一方で、別のシステムではアーキテクチャや scale-to-zero の製品提供により、ある種避けられないものでもある
- 私が見たすべての事例で、コールドスタート問題は製品上の意思決定事項であり、料金プランや価格設定方式に応じてリソース縮小の度合いが異なり得る
- 最終的に顧客とベンダーは、それぞれのニーズに合わせてトレードオフを選択できる
調査したシステム
- Group 1 - Storage APIs (compute-light)
- Amazon DynamoDB (chapter 1)
- Kora - Serverless Kafka engine inside Confluent Cloud (chapter 2)
- Backblaze B2 (planned)
- Group 2 - SQL OLTP databases (compute-heavy)
- Neon - serverless PostgreSQL (chapter 3)
- CockroachDB’s serverless multi-tenant architecture. (in progress)
- Planetscale (planned)
- Group 3 - SQL OLAP databases and data warehouses (compute-heavy)
- Google BigQuery (planned)
- ClickHouse Cloud (in progress).
- この作業は今後も続くが、2024年1月/2月にある種の「結論」ポストを予定
まだコメントはありません。