【ITニュース解説】The power of estimation in building reliable systems

信頼性の高いシステムを構築するためには、システム開発の初期段階で明確な要件定義と現実的な見積もりを行うことが非常に重要である。この見積もりを怠ると、システムの稼働後に予期せぬ問題や障害が発生し、結果として多大な時間とコストを費やすことになる。これはまるで、目隠しをして設計するようなものであり、システムの限界に気づくのは稼働後、しばしばシステム障害の最中である。

初期段階での見積もりは、システムが将来どれくらいの負荷に耐えうるか、どの程度のリソースが必要かといった不確実な要素を具体的な数値で把握する作業である。例えば、Instagramは2012年にFacebookに買収された後、急激なユーザー数の増加に対応できず、単一のデータベースでは負荷に耐えられなくなった。サービスは遅延し、システムクラッシュの危険にさらされ、結果としてデータを分割し、複数のデータベースに分散させる大規模なシステム再構築を緊急で行う必要があった。この事例は、事前の見積もりの重要性を示す典型的な例だと言える。

見積もりがなぜ重要なのか、その主な理由は以下の3点に集約される。一つ目は「キャパシティプランニング」である。これは、システムの日常的なアクティブユーザー数や利用パターンを予測し、それに基づいて必要なサーバー容量、データベースの規模、ネットワークインフラなどのリソース要件を見積もる作業である。現在のトラフィックに対応するだけでなく、将来の成長を見越した設計を行うことが目的となる。二つ目は「パフォーマンス最適化」である。見積もりを通じて、システムがピーク時にどれくらいのクエリを処理できるか、応答時間はどの程度になるかなどを計算することで、潜在的なボトルネックを早期に特定し、応答性の高いシステムを設計できる。三つ目は「コスト管理」である。リソースを過剰に用意すれば無駄な資本が消費され、不足すればユーザー体験が損なわれる。正確な見積もりによって、最適なリソース配分を実現し、費用対効果の高いスケーリングを可能にする。MetaやMicrosoftのような大規模組織では、わずかな見積もりミスでも数百万ドルものインフラコストの無駄につながることがある。これらの三つの要素は相互に関連しており、キャパシティプランニングの失敗はパフォーマンスに直接影響し、その両方がコストに大きな影響を与えるため、堅実な見積もりはすべてを適切にするための出発点となる。

これらの見積もりを効果的に行うためには、いくつかの技術が必要となる。まず「バックオブザエンベロープ計算」は、大まかな計算でアイデアの実現可能性を素早く確認する手法である。完璧な数値を目指すのではなく、そのアイデアが基本的に実現可能かどうかを判断することが目的だ。大きな見積もりを小さな部分に分割して考えることも含まれる。Googleのジェフ・ディーン氏も、設計レビューでこの手法を用いて提案の実現可能性を迅速に判断していたと言われている。次に「オーダーオブマグニチュード思考」では、詳細に入る前に、問題の規模が千、百万、十億といった10の累乗単位でどれくらいかを見積もる。これにより、システム全体のアーキテクチャの方向性が決まる。また「分解と集約」という手法では、複雑なシステムを認証サービスやデータ取り込みパイプラインといった個別のコンポーネントに分解し、それぞれに必要な要件を見積もり、それらを合計することで、システム全体を見積もるよりもはるかに正確な数値を導き出すことができる。さらに「履歴データ分析とベンチマーク」は、過去の類似プロジェクトのデータや、NetflixやUberのような企業が公開しているパフォーマンスベンチマークを利用する。これは最も信頼性の高い見積もりの出発点となることが多い。通常、これらの手法は、まずオーダーオブマグニチュードで大まかな見積もりを行い、データが増えるにつれて段階的に精度を高めていくのが最善の実践方法である。

しかし、見積もりにはいくつかの課題も存在する。一つは「要件の不確実性」である。プロジェクトの初期段階では、要件が漠然としていたり、変化しやすかったりする。市場の状況やユーザーの行動予測も難しく、長期的な見積もりを固定することは困難である。二つ目は「人的要因」だ。開発者は、複雑さを過小評価し、タスクの完了に必要な時間を短く見積もりがちである（楽観主義バイアス）。また、野心的な締め切りを達成しようとする組織的プレッシャーも、非現実的なコミットメントにつながることがある。大規模なITプロジェクトに関する調査でも、予算超過やスケジュール遅延が頻繁に発生し、期待された利益の一部しか得られないというパターンが見られるが、これは技術的な問題よりも初期のミスや過信が原因であることが多い。三つ目は「技術的制約」である。新しい技術を使用する場合、過去のデータや確立されたベンチマークが不足しているため、パフォーマンスやリソース要件を正確に予測するのが難しい。これらの不確実性に対処するためには、初期は広範な見積もりから始め、要件の進化に合わせて精度を高め、実際のデータに基づいて調整していく反復的なアプローチが不可欠である。

具体的な見積もりの例として、URL短縮サービスを考えてみよう。このサービスの設計を始めるにあたり、まずいくつかの基本的な前提条件を設定する。例えば、月に2億件の新しいURL短縮リクエストがあり、短縮されたURL1件あたり約500バイトのデータが必要で、これらを最長5年間保存すると仮定する。また、短縮されたURLが1回書き込まれるごとに、平均100回リダイレクトされるとする。これらの前提条件に基づき、バックオブザエンベロープ計算を行うことで、主要なメトリクスを算出できる。ストレージは、2億件/月 × 500バイト × 5年間で、およそ6テラバイトが必要となる。書き込みトラフィックは、月2億件を秒に換算すると、平均約77URL/秒となる。読み込みトラフィックは、77件/秒の書き込みに対して100倍のリダイレクトがあるため、平均約7.7Kリダイレクト/秒となる。帯域幅は、ピーク時に1リダイレクトあたり約1KBとすると、約60Mbpsが必要となる。サーバー台数については、ピーク時のトラフィックが平均の3倍と仮定し、1台のサーバーが5Kリクエスト/秒を処理できるとすれば、アプリケーションロジックのために約5～6台のサーバーが必要となる。さらに冗長性のための追加サーバーも考慮に入れる必要がある。これらの見積もりは完全に正確ではないが、システムアーキテクチャの方向性を定めるための基礎となる。例えば、高いリダイレクトレートはキャッシュ層の導入を必須とし、数十億ものリンクを保存する必要があるため、単一のリレーショナルデータベースではなく、スケーラブルなキーバリューストアを選択することになる。厳格な可用性目標のためには、冗長性と自動フェイルオーバーも不可欠となるだろう。このように、見積もりは実装が始まるずっと前から、具体的な設計上の選択肢を導き出す真の価値を持つ。

より複雑なシステムや高い精度が求められる場合には、バックオブザエンベロープ計算だけでは不十分であり、より高度な見積もりモデルが必要となる。例えば「BSP（Bulk Synchronous Parallel）モデル」は、データパイプラインや機械学習のトレーニングのような大規模な並列計算において、計算、通信、同期のフェーズをモデル化することで、完了時間やスケーリングのボトルネックを予測するのに役立つ。また、システム設計では、不完全または不確実な情報に直面することがよくあるが、このような場合に「ファジー論理モデル」が有効である。これは、二値的な真偽ではなく、「程度の真実」を用いて曖昧な要件や不足しているデータをモデル化し、リソース割り当てや可変負荷下でのパフォーマンス予測の決定を支援する。例えば、使用履歴のない新製品のサーバー容量を見積もる際に、ユーザーの関心を「低い、中程度、高い」といった定性的な入力として受け取り、それに基づいてリソースの潜在的な必要範囲を提供するような使い方がある。これらの高度なモデルは、基本的な見積もり手法を補完するものであり、問題を扱う上での不確実性のレベルに合わせて適切なツールを選択することが重要だ。

システム設計において正確な見積もりを追求することは、圧力下でも破綻しない堅牢なシステムと、そうでないシステムを分ける決定的な要素となる。自身が関わる設計において、まず3～5つの基本的な前提条件（ユーザー数、トラフィック、データ増加など）を定義し、それに基づいてストレージ、スループット、コストについて迅速なバックオブザエンベロープ計算を行うことが推奨される。要件の進化に合わせて見積もりを洗練させ、ベンチマークや過去のシステムデータと照らし合わせて数値を検証することが不可欠だ。これらの技術を適用することで、問題が発生してから対処する「リアクティブ」な対応から、成長を予測し、コストを管理し、パフォーマンスを保証する「プロアクティブ」なアーキテクチャ設計へと移行できる。開発において強力なエンジニアは、常に早期に数値を算出し、設計の進化に合わせてそれを洗練させる姿勢を持つものである。