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台の大きなサーバー」方式は実サービスに非常に適した選択である

[GN⁺]

Hacker Newsのコメント

• クラウド料金（Cloud Tax）の最大の問題点の一つは、エンジニアが検討できるソリューションの幅そのものを人為的に狭めてしまうこと。たとえば AWS に月 $200 ほど払うと 4 vCPU、16GB RAM のサーバーが手に入るが、これは 5 年前の開発用ノートPC程度のスペック。一方 Hetzner なら同じ金額で 48 コア、128GB RAM のサーバーを借りられる。計算性能の差は桁違い。10 倍大きい容量があれば十分に有効な手法も、小さなノードでは意味をなさなくなる。こうした条件は、より複雑なシステムを作るためのエンジニアリング時間を節約する手段になることもある。もちろん耐久性など別の考慮も必要だが、逆に専用サーバーは noisy neighbor の心配なしに一貫した性能を保証してくれる
  • 2025 年には、利便性が高く複雑な手続きなしで fly.io のようなサービスを汎用用途に使えるようになっているし、特定のフレームワークなら Vercel のような選択肢もある（特定スタックに特化した良い選択肢）。それ以上が必要なら、OVH/Hetzner/Latitude で本物の怪物級マシンを安くレンタルできる。単にブログを運営する程度なら VPS は本当にたくさんある。従来型クラウドは、もはや規制や社内プロセス、非効率のためにしか使われていない。開発生産性もマシン単価もゼロだと思う。本当に何の制約もないチームで、DMV 風の認可システム、うるさい Intel ノード、高いマージン、ひどいサポートが好きでもない限り、ほとんど意味がない
  • これはそれ以上の話で、ベアメタルサーバーを使えばネットワーク遅延（latency）、VM のメモリ帯域遅延や競合、別個のキャッシュ構造などが不要になる。たとえば Postgres に RAM を大量投入して Linux のディスクキャッシュだけ使えばいい。ずっとシンプルで速い
  • どうして些細なサービスにもいきなり AWS を使わなければならないのか理解できない。私はあなたほど複雑なレベルではないが、クライアントが小規模な PHP Web アプリ + AWS サーバー/SQS/S3 の組み合わせを月 $100 で使っていた。これを Python/Django/PostgreSQL（当初は SQLite）で実装し直して、月 $25 の VPS に移した。PDF OCR、価格更新、欠品商品の検出、サイト提供など、すべて 4 コア 6GB RAM で問題なく動いている。ユーザーが 100 人を大きく超えることのない社内向けアプリなので、将来大きくなっても移行はとても簡単。今の規模なら AWS の $100 サーバーを使う理由はない。本当に大規模にスケールするまでは
  • 完全に同意する。sqlite のような組み込みデータベースを使い、書き込み（batch）を最適化すれば、Hetzner でも驚くほど遠くまで行ける。「過剰に容量を予約して無駄になる」という主張は AWS を離れれば成り立たない（コスパが別次元だから）。むしろシステムが複雑になるほど、単一ノードより信頼性や復元力が低くなる場合すら多い。何か一つだけが孤立して壊れることはほとんどない
  • 私の考えはむしろ逆だ。Hetzner は小規模サイトには非常に良いが、大規模プロジェクトではクラウドは事実上制約がないように感じる。自分の時間に価値があるプロジェクトなら、ホスティング費用が $200 でも $2000 でも大した意味はない。AWS CDK/Terraform + GitHub Actions と Docker/K8s/Ansible + CI パイプラインの開発時間の差も特に感じない。ベアメタル方式のほうがはるかにエンジニアリング時間を節約してくれるとは思わなかった。Fargate + RDS のような IaC も便利だ。本当にファイルストレージの分離、拡張、耐久性が必要だったり、サブドメインの動的生成など各種インフラ層の専用サービスをいくつも統合しなければならないなら、むしろ新しいサービスの学習や統合の負担のほうがずっと大きい。実際、クラウド以前の時代からこういう仕事をしてきたが、収益を生むプロジェクトならクラウド費用には投資する価値があると思う。コストが重すぎるプロジェクトなら、それはビジネスというより趣味だ。RAID や複数クラスタのファイルシステム管理なんて、たいていのスタートアップや会社のリソース、あるいは自分の時間ではやりたくない。Arch + Emacs をいじるのが好きな趣味か、MacBook で満足する趣味かの違いに感じる。カーネルスケジューラを変えたいなら Arch を勧めるが、そうでなければ MacBook を勧める。一方で、本当に予算がないなら raw throughput が重要なケースでは専用サーバーがぴったりだった経験もある（数千ドル節約できた）。もし成功していたら、その時点から垂直スケールしていたと思うが、これは稀なケースだ
• HN（Hacker News）は本番用サーバーとバックアップサーバーの 2 台で運用している。ハードウェアの問題やアップグレードが必要なときに即座にフェイルオーバーできるので便利なパターン。ただし、サーバーが完全に同一クローンだと両方同時に落ちる可能性があるので注意が必要
  • SSD ほど致命的ではないが、AMD CPU にも面白いエラーがあった。1044 日ほど経つと特定のコアが完全に停止するという問題だった AMD EPYC Rome CPU Hang の事例
  • HN（Hacker News）のダウンタイムに関する統計があるのか気になる。この 10 年で 1〜2 回落ちたのを覚えている程度で、体感では 99.99% 以上の稼働率に見える
• 私は 10 年以上ハイブリッドなコロケーション + パブリッククラウドを使ってきたが、ある規模を超えると常にコスト最適化に最適だった。ハードウェア効率も上がり続けている。ネットワーク/インフラ管理者は必要だが、実際には今どき管理はとても簡単だし、むしろ「クラウド」管理者も基本的には必要なので、人件費の削減効果はほとんどない。コロケーションの選択肢は多様で、事業者は帯域を束ねて売っている。以前、8 台の Dell VRTX クラスター、SAN、500+ VM（大規模 msSQL から kube まで）を回していたが、これがパブリッククラウドだったら予約割引を使っても請求額は 6 桁（万ドル単位）を超えていたはずだ。ところがコロケーション費用は月 $2,400（主に電力コスト）だった。パブリッククラウドノードの著しい性能低下にもいつも驚かされる（同じ CPU/vCPU 世代でも）。機器のディール、更新、ライセンス、サポート契約の把握はしっかりやる必要があるが、現実的には十分管理可能だ。そして今ではクラウドやネットワーキングとも簡単に接続できるので、fiber drop を引いて VPC につなげば終わりだ
  • コロケーションとは、自分のハードウェアを購入してデータセンターでは電力/ラック/回線だけを借りるものだと理解しているが、本当にそうなのか気になる。通常のベアメタルサーバーレンタルより何が良いのか知りたい
• 友人たちと何年もこのテーマを議論している。ローカルインフラの最大の欠点は、これをきちんと運用できる専門人材が必要なことだ。この記事は上位規模に焦点を当てていたが、下位市場でも、すでに多少の機材があるなら小規模ラックやネットワーキングで 1 年以内に損益分岐点に達する。今のクラウドプレミアムを考えると、管理者を 1 人雇ってもローカルインフラのほうが経済的だろう
• 私が創業に関わった会社では、エンタープライズ自動化エンジンを作っていたが、チームはソリューションを SaaS として配布して売上を最大化したがっていた。実際には multi-tenant DB スキーマ + VPS でも十分だったのに、チームは kubernetes の学習とクラウドネイティブスタックに没頭し、1 年間ずっと開発環境と運用自動化に専念していた。結局会社は長く持たずに潰れた
  • でもエンジニアたちはその経験で k8s の職歴がついて、新しい就職先をまた見つけられた
  • 私も似たような経験がある。5 年後に必要になるかもしれない問題を先回りして解決しようとして、時間を無駄に使いすぎた。ほとんどのプロジェクトや初期スタートアップは、ただ PaaS か nginx + docker コンテナ程度で十分だ。いつか本当の痛み（pain point）が来たら、その時に考えればいい
  • だから私は「請求書が本当に痛くなるまで」はただ PaaS が好きだ。heroku/render/fly にお金を払いながら PMF（Product-Market Fit）に集中する。あるいはサーバー遊びとして K8s に投資し VC の金を燃やしながら、次の職場へと同じことを繰り返すルートもある
• 多くのビジネスはそこまで重要ではない。サービス停止にひどくストレスを感じる人は多いが、実際には彼らが扱っているサービスはそこまで重大ではない。真昼間に本番環境が吹き飛んでも、少し面倒ではあるが世界が終わるわけではない。こうした企業は、単純なオフィスサーバーで 250 人が十分使えていたのに、わざわざクラウドに移して予算だけを爆増させている。クラウドは特定の作業には優れているが、それ以外はマーケティングの誇張に近い。ただ、多くのエンジニアは「完璧なスケーラビリティ」に執着して、ほどほどに良い解決策ではなく理想的なアーキテクチャばかり求める傾向がある
  • 昔一緒に働いたチームメンバーの一人は、いつもこう言っていた。「少なくとも、私たちがミスしても誰かが死ぬわけじゃないんだから、そんなに心配する必要はない」と。もっと責任の重い仕事をしていた経験のある人だったので、難しい状況でもその考え方が大きな助けになった
• 100% 稼働時間の達成を目指して複雑な構造を作ると、かえって信頼性を下げるミスを頻繁にするようになる。ほとんどのビジネスは、たまに 1〜2 時間のダウンやデータ損失があっても実際には耐えられる。こうした期待値を先に共有しておけば、ずっとシンプルで信頼性の高い構成にできる
  • コストもずっと安い。ただし、こうした期待値はエンジニアではなく、非技術系の経営陣には受け入れられないことが多い（特にデータ損失はほぼ許容されない）。エンジニアは環境を管理するだけだと言うが、現実にはそう簡単ではなく、ミスすると無能に見られかねない
• かなり良い記事だと思う。この方式（非クラウド）でスケールするときは CDN の追加も検討に値する。CDN を使えば WAF や DNS フェイルオーバーの効果もある。ただし、非クラウド方式だと自前で DB を運用しなければならない点が少し惜しい。だからクラウド DB も選択肢として提供する事業者を検討したり、アクティブ/パッシブ構成ならパッシブノードをクラウド VM + オートスケールでより安く運用するのも手だ。最近はサーバーレンタル価格が本当に安く、4GB VPS で $6 程度、32GB クアッドコアのベアメタルでも $90 前後。serversearcher.com のような価格比較サイトを使うと便利だ
  • Postgres を Docker コンテナに載せて、定期的にバックアップを回すだけでも特に問題はなかった。運用も簡単で、特に不便はない
  • 単一マシンでは Postgres/MySQL より sqlite のほうがはるかに高性能で、管理も簡単にできる
• 私も VPS でサービスを運用している。クラウドはもうずっと前に捨てた。自分のプロジェクトが収益を生み始めたら、機器を買ってコロケーションに入れるつもりだ。クラウドはデートアプリみたいなものだったが、もう楽しい時期は終わって、本当に何か生産的なことをしたくなった
  • コロケーション自体も問題だらけだ。データセンターの電源障害などでハードウェアが死ぬのは本当によくある。皮肉なことに自宅の電気のほうが安定している。数分のダウンタイムが数百万の売上に影響するような事業でなければ、たいていは地下室でサーバーを回しても特に問題ない。多くの人は 99.999% uptime や帯域の必要性をひどく過大評価している。コロケーションは思うほど安くもない。データセンターの電気料金が一般/事業用や住宅用より高いことも多い。本当に安いのはインターネット回線/光ファイバーだけで、今では国によっては 5〜10Gbit のビジネス向け回線も 100 ユーロで使えるようになっている（昔は 1Gbit でも 2000 ユーロ以上した）
• コストや容量の分析はさておき、業界トレンドそのものに逆らうのは簡単ではない。「ハードウェアを一切気にしなくていい」という利点は確かにある。しかも capex（資本支出）は絶対に避けるべきだという考え方も根強い（サーバーハードウェアは先行投資コストが大きい）。さらに AWS リージョンが障害を起こしても「自分たちの責任」には見えないが、社内サーバーが落ちると「自分たちの責任」に見える、というメカニズムもある
  • capex（資本支出）を極端に嫌うのは、ほぼ VC 投資の構造の影響だ。投資家が高速成長しか求めないなら、先行投資（サーバー購入）は論理的に正当化しづらい。一方、安定したビジネスなら毎年少額の capex は十分こなせる
  • サーバーハードウェアは必ずしも買う必要はない。Hetzner のようなところでレンタルすれば十分だ。「ハードウェアを気にしなくていい」利点とは具体的にどういうことなのか、もう少し説明を聞きたい
  • capex を節約したいという考え方は実際にある。電卓を使えるだけでも、今ではサーバー価格がビジネス全体にとって大した意味を持たないレベルだとわかる。本当に高いのはサーバーを取り巻く「空間」なので、多くの場合はサーバーではなく空間（ラック/電力）を借りているだけだ
  • 企業が実際に金を払っているのは、要するに「責任の抽象化（abstraction of responsibility）」だ。大企業の幹部は、MS や AWS のような大企業のソリューションを選ぶと安心する
  • ベアメタルサーバーをレンタルすれば、capex や保守の心配をする必要はない