# スケーラビリティ評価 ## 定義 スケーラビリティ評価(Scalability Evaluation)は、分散システムやデータベースがノード数・負荷・データ量の増加に対してどの程度線形または超線形に処理能力を拡張できるかを定量的に測定する取り組みである。理想的なスケーラビリティはノード数 N に対してスループットが N 倍になる「線形スケーリング」だが、実際には startup コスト・相互干渉・データスキューという 3 つの脅威によって劣化する(DeWitt/Gray 1992)。 クラウドインフラ上でのスケーラビリティ評価は、複数のクラスタサイズ(例: 3・6・12・24・36 ノード)にまたがって同一ワークロードを測定し、スループットとクラスタサイズの関係を「ほぼ線形」「線形を下回る」「崩れる」等の定性評価と、回帰係数の定量評価で把握する。 ## 横断的知見 - **クラウド TSDB のスケーラビリティは CPU バウンドである場合に線形性が最も達成しやすい**: Goldschmidt ら([[@2014__IEEE CLOUD__Scalability and Robustness of Time-Series Databases for Cloud-Native Monitoring of Industrial Processes]])が 36 ノードまで拡張した実験では、[[KairosDB]] が CPU バウンド特性(KairosDB プロセスと Cassandra プロセスが各 ~50% を均等分担)を示し、ほぼ線形のスケーリングを実現した(最大 598 PMU、403,500 値/秒 @36 ノード、Figure 4)。対照的に [[Databus]] は 36 ノードで線形性が崩れ、その原因は特定できなかった。CPU バウンドかつ負荷分散が均等であることが、線形スケーラビリティの十分条件に近い。(Source: [[@2014__IEEE CLOUD__Scalability and Robustness of Time-Series Databases for Cloud-Native Monitoring of Industrial Processes]] §V-B・Figure 4) - **自己防衛(バックプレッシャー)の設計品質はスケーラビリティと独立した評価軸を形成する**: スケーラビリティが「最大容量の大きさ」を測るのに対して、ロバスト性評価は「最大容量を超えたときの挙動」を測る。[[KairosDB]] は Cassandra のキュー状態を監視してクライアントへの応答時間を増やすことで自然なスロットリング(グレースフルデグラデーション)を実現した。[[OpenTSDB]] は HBase がメモリ不足に陥ってもクライアントへの通知なく受け入れを継続し、信頼できる最大容量の測定さえ不可能にした。スケーラビリティ「評価」を行うためには、まずロバスト性が一定以上でなければならないという依存関係がある。(Source: [[@2014__IEEE CLOUD__Scalability and Robustness of Time-Series Databases for Cloud-Native Monitoring of Industrial Processes]] §V-A・§V-B) - **ワークロードの独立性(workload independence)はスケーラビリティ予測精度の鍵となる仮説である**: Goldschmidt ら(2014)は「スケーラビリティはデータ型ではなくデータ量のみに依存する」という仮説(仮説 3)を [[KairosDB]] と [[Databus]] の両方で確認した——PMU Write と SmartMeter Write の両ワークロードで同様の線形スケーリングが成立した(§V-D)。この独立性が成立すれば、一種のワークロードで測定したスケーリング係数を別ワークロードにも適用できる。逆に独立性が成立しない場合、ワークロードごとに個別のスケーラビリティモデルが必要になる。(Source: [[@2014__IEEE CLOUD__Scalability and Robustness of Time-Series Databases for Cloud-Native Monitoring of Industrial Processes]] §V-D, §III) - **読み書き独立性(Read/Write Independence)の欠如は「うるさい隣人問題(noisy neighbor problem)」としてスケーラビリティ評価を汚染する**: 読み取りクエリが書き込みスループットを低下させる場合(またはその逆)、複合ワークロードでの最大容量は書き込み専用ワークロードの測定値より小さくなる。[[KairosDB]] の PMU WRA プロファイル(書き込み 95%・読み取り 5%)では、複合時のスループットが書き込み専用より若干高い結果を示し、読み書きパイプラインが適切に分離されていることを確認した(Figure 6)。スケーラビリティ評価には単一ワークロードだけでなく複合プロファイルが必要である。(Source: [[@2014__IEEE CLOUD__Scalability and Robustness of Time-Series Databases for Cloud-Native Monitoring of Industrial Processes]] §V-B・Figure 6) - **実クラスタサイズでのコスト試算はスケーラビリティ評価を実用性判断につなぐ不可欠なステップである**: Goldschmidt ら(2014)は 600 万スマートメータ(大都市規模 AMI)を処理可能な 24 ノードクラスタのコストを AWS オンデマンド価格で月 4,147.20 ドル・3 年リザーブドで 1,468.80 ドルと算出した(§V-D)。これにより「線形スケーリング」という技術的知見が「産業規模の AMI をこの予算で運用できる」という事業判断に接続される。スケーラビリティ評価は性能だけでなくコスト効率の評価も含むべきである。(Source: [[@2014__IEEE CLOUD__Scalability and Robustness of Time-Series Databases for Cloud-Native Monitoring of Industrial Processes]] §V-D) ## 未解決の問い - スケーラビリティ評価における「線形性の崩れ」を事前に予測できる理論モデルはあるか。Databus が 36 ノードで線形性を失った原因は 2014 年時点で著者問い合わせでも特定できなかったが、後続研究で明らかになったか。 - クラウド仮想化環境のスケーラビリティ測定は CPU オーバープロビジョニングやエフェメラルディスクの変動に影響されうる。専用ベアメタルクラスタとクラウド VM でスケーリング係数はどの程度異なるか。 - KairosDB のキャッシュ外テーブルマッピング問題(SmartMeter Write で 200 万超から線形性が鈍化)のような「アーキテクチャ固有のスケーリング天井」を汎用ベンチマークで事前に検出できるか。 - TSM-Bench([[@2023__PVLDB__TSM-Bench - Benchmarking Time Series Database Systems for Monitoring Applications]])はオフライン評価とオンライン評価で異なるスケーラビリティ順位を示すが、産業ワークロード(高持続書き込み)でのスケーリング特性まで評価しているか。 ## 関連 - ソース: [[@2014__IEEE CLOUD__Scalability and Robustness of Time-Series Databases for Cloud-Native Monitoring of Industrial Processes]] / [[@2023__PVLDB__TSM-Bench - Benchmarking Time Series Database Systems for Monitoring Applications]] - 概念: [[時系列データベース]] / [[産業用監視システム]] / [[時系列データベースベンチマーク]] / [[クラウドモニタリング]] - エンティティ: [[KairosDB]] / [[OpenTSDB]] / [[Databus]] / [[ABB Corporate Research]] ## 出典 - [[@2014__IEEE CLOUD__Scalability and Robustness of Time-Series Databases for Cloud-Native Monitoring of Industrial Processes]](5 クラスタサイズ × 3 TSDB のスケーラビリティ評価・ロバスト性評価・ワークロード独立性検証・コスト試算)