1台の大きなサーバーを使え（2022）

• 論争の本質はモノリシック vs マイクロサービスではなく、分散システムが開発・運用オーバーヘッドに見合う価値があるかという判断である
• 現代の単一サーバーは数十〜数百コア、TB級メモリ、数十〜数百Gbps I/Oを備え、ほとんどのWebサービスを支えられる十分な性能余力を持つ
• 実際のベンチマークでは、1台のサーバーでNginx 50万RPS、PostgreSQL 7万IOPS、NoSQL 100万IOPS、4Kエンコード 75 FPSなどの高性能処理が可能である
• クラウドを使うと利便性と可用性は高まるが、コストのプレミアムも大きいため、投資対効果を見極める必要がある
• 利用パターンが極端に変動的な場合に限って、クラウドネイティブやサーバーレスアーキテクチャがコスト面で有利になる
• しかしサーバーレス／マイクロVM構成のコストプレミアムは大きく、ワークロードが継続的・予測可能であれば垂直スケーリングのほうが経済的である
• 可用性はプライマリ／セカンダリ（または2×2）冗長化と異種ハードウェア構成でかなりの部分を解決でき、CDN・バックアップだけを分散で購入する戦略が合理的である

---

概要: 分散システムより「大きなサーバー1台」の価値

• 「モノリシック vs. マイクロサービス」論争の核心は、分散システム導入に見合う実際の開発者時間とコストをどう評価するかにある
• 現代のソフトウェアはサーバーの仮想化やさまざまな抽象化レイヤーの上で動作しており、「サーバーレス」や「ベアメタル」も結局は物理サーバー資源の上に構築されている
• 今日のサーバーは、私たちが考えている以上に性能対コスト効率が高い
  • 以前と比べてサーバースペックはコア数・メモリ帯域幅・PCIeレーン・NVMeストレージの面で飛躍的に向上しており、多くのサービスが分散なしでも目標QPSを達成できる

サーバーハードウェアの強力な性能

• Microsoft Azure の例示サーバーはAMD第3世代サーバーCPUを2基搭載し、合計128コア256スレッド構成を持つ
• 単一サーバーで4 TFLOPs級の演算性能を実現し、2000年代初頭のスーパーコンピュータ性能を上回る
• 16スロットの DDR4-3200 RAM をソケットごとに搭載し、最大8TBまでメモリを拡張可能で、現実的な購入レンジでも1TBメモリをサポートする
• 合計128本のPCIe Gen4レーンを備え、30台の NVMe SSD と 50〜100Gbps のネットワークカードで高性能なストレージおよびネットワーク接続が可能

この単一サーバーでできること（ベンチマーク引用）

• 400–800 Gbps の動画転送、NoSQL 100万IOPS、PostgreSQL 7万IOPS、Nginx 50万RPSを達成可能
• Linuxカーネルを20秒でビルド、x264 4K 75FPS エンコードなど、CPU・メモリ・I/O集約型の作業でも高いスループットを示す

サーバーのレンタル・購入コスト比較

• OVHCloud: 128コア/512GB RAM のサーバーを月額約 $1,318 でレンタル可能
• Hetzner: 32コア/128GB RAM のサーバーを月額 €140 で提供しており、サイズに応じて価格帯が変わる
• AWS の m6a.metal: 96物理コア/768GB RAM のサーバーが時間あたり $8.29、月額約 $6,055 で、クラウドプレミアムが大きい
• Dell で類似仕様のサーバーを直接購入すると約 $40,000 で、約8か月でクラウドに対する投資回収が可能
• サーバーレスで同じ処理量を想定すると、インスタンス比で5.5倍、低価格ホスティング比で25倍のコストプレミアムが見積もられる

なぜ分散システムが注目されたのか

• 以前（2010年前後）は CPU・メモリ・ストレージ性能の限界から、大規模サービスには複数サーバーの組み合わせが必要だった
• 近年は大型単一サーバー・NVMe SSD・高いメモリ帯域幅によって単一ノード処理の限界が大きく向上したが、VM やコンテナ単位は依然として小規模サーバー資源を基準に設計されている

1台の大きなサーバーだけで十分なケース

• 10k QPS 以下の大半のWebサービスは1台で十分であり、単純なサービスなら100万QPS級まで可能
• 動画ストリーミングでさえコントロールプレーンは単一サーバーで現実的であり、ベンチマークや共通性能テーブルによって適切なサーバーサイズを算定できる
• 特殊な状況を除けば、プライマリサーバーとバックアップサーバーの構成だけでも可用性の確保には十分である

「広く」より「高く」: 大量のサーバー群より少数の大型サーバーを好む

• クラスターが必要でも、大きなサーバー数台のほうが小さなサーバー多数より**調整オーバーヘッド（O(n)）**が低い
  • つまり長期的には、サーバー台数を減らしてスペックを上げるほうが効率的である
• サーバーレスや短命コンテナベースでは、オーバーヘッド比率が特に大きくなる
• 欠点は単一障害点だが、**プライマリ／セカンダリ（別DC）**だけでもかなり緩和できる
• より堅牢にするには、2×2構成（主DC 2台 + 副DC 2台）と異なるハードウェア／メーカーの組み合わせで相関障害を回避する
• レンタル時はサーバーモデルを多様化することで、同一ロットのディスク・SSDによる連鎖故障リスクを減らせる

クラウド利用の利点と限界

• クラウドは可用性・復旧速度・運用のしやすさが強みであり、プレミアムコストを払う価値はある
  • ダウンせずに、費用内で迅速な再起動が可能であり、グリッド管理された大規模リソースプールを活用できる
  • レンタルサーバー事業者は価格は安いが、品質・ネットワーク・プレミアムサポートなどで限界がある
• ただしクラウドベンダーの営業は、オートスケールVM、サーバーレス、マネージドHA DBなどのベンダーロックイン型アーキテクチャを推奨するため、コストと複雑性には注意が必要である
• 大規模トラフィック処理そのものはクラウドネイティブの主な理由ではなく、単一の大型サーバーでも数百万人の同時利用を支えられる事例は多い

ピーク負荷のコストとバースティ負荷の基準

• 誰かがピークに合わせて容量を用意するので、結局ピークコストはサプライチェーンのどこかで請求される
• バースティで一時的な作業（例: 単発の大規模シミュレーション）はサーバーレス／オートスケールが経済的だが、継続的・予測可能な負荷は大きなサーバーの固定運用のほうがコスト効率が高い
• 1年契約／スポット／営業交渉を活用すればインスタンスコストはさらに下がり、サーバーレスに対するプレミアムはより大きくなる

「クラウドプレミアム」の定量評価

• AWS Lambda などのサーバーレスコンピューティングは、同等サーバー比で5〜30倍のコストプレミアムが発生しうる
• 仮定: $8.2944/時間のサーバーが1k QPS、768GB RAMを提供する場合、同じ処理量を Lambda に置き換えると約 $46/時間となり、5.5倍のプレミアムになる
• OVHレンタル比で25倍のプレミアムと推定され、利用率が5%しかなくても低価格ホスティングのほうがサーバーレスより経済的である
  • 長期契約、スポットインスタンスなどを活用すれば、プレミアム差はさらに広がる可能性がある
• QPS が異なってもメモリ時間換算ではプレミアム倍率は似通っており、ワークロード規模に合わせたサーバースケーリングが重要である

よくある反論と誤解

• 「クラウドならシステム運用人員は不要」: 役職名がCloud Opsに変わっただけで、文書化・変更追跡・廃止対応の能力が必要なため、人件費上昇要因になる
• 「クラウドならセキュリティ更新をしなくてよい」: 一部は不要になるが自動化しやすい領域に限られ、ライブラリ監査・構成検証は依然として必要である
• 「クラウドは高可用性設計だから安心」: 複雑性の増加が新たな脆弱性を生み、リージョン・プロバイダー冗長化でも相関障害は完全には排除できない
• 「クラウドは開発速度が速い」: 初期の俊敏性は利点なので活用すべきだが、コストの変曲点を監視し、適切な時期に移行する必要がある
• 「うちのトラフィックは非常にバースティだ」: この場合はサーバーレス／オートスケールが適している
• 「CDN は？」: レイテンシと帯域削減のための必須の分散購入対象であり、バックアップも同様に購入して使う領域である

モノリシック vs. マイクロサービスとサーバー構成

• 「大きなサーバー」はそのままモノリシックアーキテクチャに結びつきやすいが、1台のサーバー上で複数コンテナとしてマイクロサービスを構成することも可能である
  • しかしプロセス間通信・デプロイ・観測のオーバーヘッドは単一ホストでも負担となり、複雑性に対する実質的な性能上の利得は大きく減る
• 初期段階・中小規模では、モノリシックまたは少数サービスのほうが運用の単純さの面で有利である

結論

• ほとんどの場合、水平スケーリングやクラウド中心アーキテクチャよりも、垂直スケーリング（1台の大きなサーバー）を選ぶほうがシンプルで経済的である
• プライマリ／セカンダリ冗長化・異種ハードウェア・CDN/バックアップの外部化を組み合わせれば、実務的な信頼性を確保でき、継続的な負荷環境では**総保有コスト（TCO）**で優位性が大きい
• 堅牢なハードウェア冗長戦略さえ確保できれば、「1台の大きなサーバー」方式は実サービスに非常に適した選択である