ハクソク

世界を動かす技術を、日本語で。

「One Big Server」を使う (2022)

267日前原文(specbranch.com)

概要

  • 分散システム 導入は本当に必要かをコスト・運用面から再考察
  • 現代サーバーの 性能と価格 の実態
  • クラウド利用の利点と割高なコスト の理由
  • 多くのケースで 大規模単一サーバー が十分な理由
  • クラウドアーキテクチャ 採用時の注意点

モノリス vs. マイクロサービス：本質的な問い

  • 分散システム導入 の是非は、開発コストや運用負荷を正しく見積もる必要性
  • 仮想化やサーバーレス の流行により、実際のサーバー性能を見誤りやすい現状
  • 結局すべてのソフトウェアは 物理サーバー 上で稼働
  • 現代のサーバーは 高性能・低価格 であり、従来よりもはるかに大きな処理能力を持つ
  • 分散構成 が本当に必要か、実運用に即して再検討する重要性

現代サーバーの実力

  • 例： Microsoft Azure のAMDサーバー構成
    • 128コア/256スレッド、 4 TFLOPs の演算性能
    • 1TBメモリ （最大8TB）、200Gbpsのメモリ帯域
    • 128 PCIe Gen4レーン、 NVMe SSD最大30台 接続可能
    • ネットワークカード は50-100Gbps対応
  • 2000年代前半の スーパーコンピュータ並み の性能
  • 1台で 動画配信400Gbps、NoSQL 100万IOPS、nginx 50万リクエスト/秒など実現可能

サーバーのコスト比較

  • OVHCloud ：128コア/512GB RAM/50Gbps帯域で月$1,318
  • Hetzner ：32コア/128GB RAMで月€140
  • AWS m6a.metal ：192vCPU/768GB RAM/50Gbpsで月$6,055
  • 物理サーバー購入 ：同等スペックで約$40,000（8ヶ月でクラウドと損益分岐）
  • クラウド利用は 大幅な割高 だが、可用性・運用の容易さが利点

クラウド時代の変化

  • 2010年頃のサーバーは8コア/16スレッド、256GBメモリが上限
  • 分散システム が必須だった背景
  • 現在は 単一サーバーの性能向上 と SSD普及 で状況が一変
  • VMやコンテナのサイズは増えていないが、 実ハードウェア性能は大幅向上

単一サーバーで十分なケース

  • 動画配信以外で 10,000QPS未満 なら1台で十分な場合が多い
  • シンプルなWebサービスなら 100万QPS も可能
  • ベンチマークや類似サービスの性能表を参考に 必要スペックの見積もり が可能

「縦に伸ばす」方が「横に広げる」より有効

  • サーバーを増やすほど クラスタ管理のオーバーヘッド が増加（O(n)）
  • 少数の 大規模サーバー 利用が効率的
  • サーバーレスなど 極小単位の分散 はコスト増大の一因
  • 単一サーバーの管理は 極めて簡単

大規模サーバーと可用性

  • 単一サーバー 運用の課題は可用性
  • プライマリ＋バックアップ 構成が現実的（異なるデータセンター推奨）
  • 2x2構成 （本番・バックアップ各2台）で高い冗長性
  • 同一メーカー・バッチ のハードウェア故障リスクに注意
    • 異なるモデル・メーカーの併用でリスク軽減

クラウド利用の現実

  • 高可用性・運用容易性 がクラウドの主な利点
  • クラウドは 割高 だが、障害対応やリソース追加が迅速
  • レンタルサーバー は安価だが品質差・移行の手間あり
  • クラウド営業は「 クラウドネイティブ」な分散構成を推奨しがち
    • マイクロサービスやサーバーレスは ベンダーロックイン 要因にも

ピーク負荷課金の罠

  • 「 ピーク負荷分を常に支払う」のが単一サーバーの欠点とされる
  • だが、クラウドの「従量課金」も 実際はピーク負荷分のコスト が内包
  • 突発的なバースト型負荷 にはクラウド/サーバーレスが有効
  • 常時稼働型サービスなら 大規模サーバーの方が低コスト・開発容易

クラウドのコストプレミアム

  • クラウド利用は 5～30倍の価格差 も珍しくない
  • 長期契約や営業との価格交渉で「ピーク負荷プレミアム」を回避可能
  • ワークロードがバースト型なら「クラウド化」推奨、そうでなければ「大規模単一サーバー」推奨

このように、 現代の高性能サーバー を正しく活用すれば、多くのWebサービスは 単一または少数台構成 で十分運用可能です。 クラウドの便利さ は魅力的ですが、コスト構造や本当に必要な分散度合いを再考することが重要です。

Hackerたちの意見

いい記事だね。これを大規模にやるならCDNを追加するのも考えた方がいいかも。WAFやDNSフェイルオーバーも使えるしね。個人的にあまり好きじゃないのは、この非クラウドアプローチだと自分でデータベースを運用しなきゃいけないこと。クラウドデータベースを提供しているプロバイダーを考える価値があると思うよ。「アクティブ/パッシブ」構成にするなら、パッシブ部分にはオートスケーリングのあるクラウドVMを使ってもっとお金を節約するのもアリだね。最近のサーバーの価格はすごくて、4GB RAMのVPSが良いCPUと帯域幅で約6ドル、32GB RAMのクアッドコアのベアメタルが約90ドルで手に入る。serversearcher.comみたいなサイトを使って比較するのもおすすめ。

└

もし単一のマシンで運用してるなら、PostgresやMySQLの代わりにSQLiteを使った方がパフォーマンスがずっと良くなるし、データベースの管理もかなり楽になるよ。

└

Dockerコンテナ内でPostgresを動かして、普通にバックアップを取るのに何か問題ある？俺は全然問題なかったし、管理も比較的簡単だよ。

コストやキャパシティの分析に関係なく、業界のトレンドには逆らいにくいよね。「ハードウェアのことを考えなくていい」っていうメリットは本当にあると思う。資本支出（capex）はどんな手段を使っても避けるべきだという考え方もあるし、サーバーハードウェアは初期投資が高いからね。それに、AWSのリージョンがダウンしたら、組織の責任に見えないけど、プライベートホスティングがダウンしたら、やっぱり組織のせいにされる感じがする。

└

はっきり言うと、これは私の推薦じゃなくて、クラウド専用デプロイが一般的な理由の観察なんだ。履歴書重視の開発へのプレッシャーも無視できないと思うし、それがインフラの人たちのキャリアに影響を与えているのは間違いない。物理的なデータセンターで働いていると、時代遅れに思われるかもしれないね。私は自分のコードが動いているサーバーを見に行けるのが本当に恋しい。データセンターって面白い場所だと思ってたし。でも、今のところ、純粋なコスト分析だけで決める努力はあまり見られないね。人々のホスティング選択を決定づける他の業界の力もたくさんあるから。

└

128GB RAMまでなら、サーバーをレンタルするだけで簡単にcapexを避けられるよ。それ以上になるとちょっと難しくなるけど。

└

サーバーハードウェアは初期投資が高い そもそもサーバーハードウェアを買う必要はないよ！記事でもHetznerからのレンタルを具体的に言ってるし。 > 「ハードウェアのことを考えなくていい」っていうメリットは本当にある この記事で言及されている以上のことをこの主張について説明してくれる？

└

「本当に必要な場合を除いて分散システムを書くな」というメリットも本当にあるよ。

└

たしかに、キャピタルエクスペンディチャー（capex）はできるだけ避けるべきだって考え方もあるよね（サーバーハードウェアは初期投資が高いし）。そうだね。正直言うと、その考え方を持ってる人は計算が苦手だったり、電卓を使えない人が多い気がする。でも、確かに存在するよ。とはいえ、今の時代、サーバーのコストは企業にとってあまり影響を与えないと思う。むしろ、その周りのスペースが高いことが多いから、サーバーよりもそのスペースを借りる人が圧倒的に多いんだよね。

└

専用サーバーを借りてるなら、capexやメンテナンスの心配はしなくていいよね。

└

「資本支出（Capex）は絶対に避けるべきだという考え方があると思う。」 うん、それって主にVCの資金調達モデルが原因だよね。投資家がホッケースティック成長を求めるなら、スタートアップがその結果としてのCapexを正当化したり、支払ったりするのは無理だよ。対照的に、安定したビジネスでほぼ直線的な成長をしているところは、定期的な小規模なCapex投資を価格に組み込む余裕があるんだよね。

└

あなたの言う通りだと思う。企業が支払っているのは責任の抽象化だよね。スーツの連中は、MicrosoftやAmazonを選ぶことを批判することなんて絶対にないよ。

私は企業の自動化エンジンを立ち上げる手伝いをしたことがある。チームはサービスをSaaSとして提供して売上を伸ばしたかったんだ。マルチテナントのデータベーススキーマを使ってVPSでホスティングすれば済んだはずなのに、彼らはKubernetesを学んで「クラウドネイティブ」スタックに深く掘り下げることにした。完璧なDevOpsパイプラインを作るのに1年かけたけど、驚くことにその会社は数年後に倒産した。

└

そうそう、だから僕はPaaS派なんだ。実際に請求書が痛くなるまではね。HerokuやRender、Flyの料金を払って、プロダクトマーケットフィットに集中すればいいんだよ。もしくは、サーバーやK8sで遊んで投資家のお金を燃やして、次の仕事に移ってまた繰り返す…って感じ。

└

僕も同じ経験があるよ。5年後に問題が起きるかもしれないことを解決しようとするのに時間を無駄にしすぎなんだ。多くのプロジェクトや初期段階の会社は、PaaSかDockerコンテナの前にnginxがあれば十分だと思う。痛みのポイントに達したときにわかるよ。

└

驚くことではないけど、その会社は数年以内に倒産した。でも、エンジニアたちはk8sの経験のおかげで新しい仕事を見つけられた。

クラウド税のもっとも悪影響を及ぼす側面の一つは、エンジニアが考慮するソリューションの種類を制約することだね。例えば、月200ドルの価格帯を選ぶと、AWSで4(!) vCPUと16GBのRAMが手に入る。アーキテクチャは違うけど、これは約5年前の中スペックの開発用ラップトップと同じくらい。Hetznerでは同じお金で48コアと128GBのRAMを持つマシンをレンタルできる。これらのマシンの生の計算能力の差は本当に大きい。10倍のキャパシティを持つアプローチは、はるかに小さいノードでは意味がないこともある。重要なのは、そういったアプローチが、人工的な制約を管理するためにもっと複雑なシステムを構築するためにかかるエンジニアリング時間を節約できることもあるってこと。耐久性などの他の要素も考慮する必要があるけど、逆に専用ボックスはノイジーな隣人を気にせずに一貫したパフォーマンスを提供できる。

└

100%同意だね。SQLiteみたいな組み込みデータベースを追加して、書き込みをバッチ処理すれば、Hetznerでかなり遠くまで行けるよ。それに、「オーバープロビジョニングはどうなの？」って議論が馬鹿らしいと思うのもそのせい（AWSの外に目を向ければ、コスト/パフォーマンス比がすごいから）。それに、僕の経験上、複雑なシステムはシンプルな単一ノードシステムよりも信頼性や耐障害性が低い傾向があるよ。物事は孤立して失敗することはめったにないからね。

└

逆だと思うな。少人数の小さいサイトにはHetznerが大好きなんだけど、大きなプロジェクトにはクラウドが制約がまったくないように感じる。僕の時間にお金を払えるプロジェクトなら、月200ドルか2000ドルのホスティングコストは無視できる差だよ。AWS CDK / Terraform + GitHub ActionsとDocker / K8s / Ansible + どんなCIパイプラインの開発コストの違いは何だろう？よくわからないけど、僕の経験上、「ベアメタル」がエンジニアリングの時間を大幅に節約するとは思えない。IaCのFargate + RDSテンプレートを使うのも特に難しいとは思わないしね。もしファイルストレージを分離して耐久性とスケーラビリティを持たせる必要があるとか、動的にサブドメインを作成する必要があるとか、他にもいろいろなことがあったら…インフラレベルで異なる専用サービスを学んで統合するのは、もっと制約が多いように感じる。僕は「クラウド」が登場する前からこれをやってきたけど、もしお金を生むプロジェクトがあるなら、クラウドコストは投資する価値があるもので、プロジェクトを制約する最後の要素になると思う。もしクラウドコストがプロジェクトにとって制約に感じるなら、それはビジネスというより趣味のようなものかもしれない—少なくとも僕の経験ではね。複数のクラスターのファイルシステムやディスクアレイを維持することを考えると、それは大半の企業のリソースや自分の時間を使いたくないことだと思う。もしかしたら、Archを好んでEmacsを完璧に設定する人と、MacBookで満足している人の違いみたいなものかも。もしカーネルスケジューラを変更することが制約だと感じるなら、Archを勧めるかもしれないけど、そうでなければMacBookを勧めるよ。:) その一方で、予算がなくてスタートアップのアイデアを利益の出るプロジェクトにしようとしたこともあるけど、その場合、専用サーバーは絶対に正しい選択で、何千ドルも節約できた。でも、そのアイデアはうまくいかなかった。もっと traction が得られていたら、しばらくは垂直スケールしていたと思うけど、そんなのは珍しいことだね。

└

それだけじゃないんだ。ベアメタルサーバーを使うことで、遅延を全部取り除けるんだよ。ノード間のネットワーク遅延もないし、VMにあるようなメモリ帯域幅の遅延や競合も少ない。例えばPostgresにギガバイトのRAMを使うように指示すれば、Linuxのディスクキャッシュが残りを処理してくれるから、別のキャッシングアーキテクチャは必要ないんだ。

└

AWSでは、純粋な計算能力が欲しいならEC2じゃなくてLambdaを使うべきだよ。EC2はレガシーなワークロード向けで、Lambdaほどのスケーリング力やスピードはないから。俺は複数のワークロードを並行してLambdaで呼び出してる。これで実質1000コアのマシンを持ってる感じで、大きなワークロードも気にせず処理できる。維持するVMもOSイメージも考える必要もないからね。これが、君が言及しなかったもう一つの違いを強調してる。HetznerはそのVMを作るために「一回限りのセットアップ」料金を取るから、インフラの決定に大きなプレッシャーがかかるし、クラウドで享受できるスケーラビリティが失われる。サーバーを借りたいだけならHetznerはいいけど、「クラウドで運用したい」ならHetznerは選択肢にならないよ。

└

AWS EC2は全体的に見て高すぎると思う。しかも、「他人のサーバー」の利点もあまり提供してないしね。ただ、記事が言ってるマイクロサービスの観点から見ると、複数のサーバーのキャパシティを本当に使い切れるわけじゃないなら、Lambda（またはFargate、もしくはそのミックス）を検討すべきだと思う。ECS+EC2からLambdaに切り替えたら、コストが急激に下がったよ。1日で何百万ものリクエストを処理しても、特にサービス間でアイドル状態になる時間が多いからね。それに、ここ5年間でハードウェアの障害はゼロだった。エンジニアとして、これで生活の質がかなり良くなったよ。

└

何をしているかによるけど、ネットワーク機能やソリューションのスケール能力を考慮すると、$200/月のEC2デバイスの中にはたくさんのものが詰まってるよ。製品はVM以上のものだからね。ただ、変動やセグメンテーションのニーズがあまりない明確なワークロードがあれば、もっと安いソリューションを提供する方法はいろいろあるよ。

└

私も同意するけど、「コア」は計算能力の良い指標じゃないよね。

HNでは2台使ってるよ—1台は稼働中、もう1台はバックアップ用で、ハードウェアの問題が起きたときや何かをアップグレードする必要があるときにフェイルオーバーできるようにしてる。いいパターンだよ。ただ、互いにクローンみたいにしない方がいいよ、同時にダメになっちゃうかもしれないから！ https://news.ycombinator.com/item?id=32049205 https://news.ycombinator.com/item?id=32032235 https://news.ycombinator.com/item?id=32028511 （ここで解決されたんだ）--- 編集: これらのポイントはOPでも触れられてるよ。

└

SSDの故障ほど致命的ではないけど、AMDにも面白いエラッタがあって、CPUコアが約1044日後にCC6でハングすることがあったんだ。https://www.servethehome.com/amd-epyc-7002-rome-cpus-hang-af...

マイクロサービスとそうじゃないのは、N台のサーバーと1台のサーバーの話とは（ほぼ）無関係だよ。10個のマイクロサービスを作って、大きなサーバーを借りてその10個を全部動かすこともできる。これはデプロイの話というより、組織の話だね。でも逆はできないよ、モノリスを作ってそれを10台のサーバーに分散させるのは無理。

└

逆はできないよ、モノリスを作ってそれを10台のサーバーに分散させるのは無理。全然できるよ。何十年も前から、スケーリングのための最も一般的なやり方だよ。

└

逆はできないよ、モノリスを作ってそれを10台のサーバーに分散させるのは無理。できるよ。複数のアプリケーションサーバーを持つってことだ。みんな同じアプリケーションを動かしてるけど、数が多いだけ。もしかしたら同じDBに接続してるかもしれないし、そうじゃないかもしれないし、DBをシャーディングしてるかもしれない。

家のNAS/サーバーをレンタルボックスかクラウドサーバーに移した方がいいのかなってよく考えるよ。特に今は1Gbit/sのインターネットがあるからね。今でも、Hetznerで20TBのドライブスペースと6コア32GBの専用サーバーが、5年でハードウェアを買うのと比べて約2倍の価格なんだ。ハードウェアは実際にはそれ以上持つと思うし、レンタルの専用サーバーでも同じレベルの冗長性（RAID）があるから、バックアップのコストは同じなんだよ。Hetznerのクラウドとボックスストレージは専用サーバーより高いし、ハードウェアを所有して電気代を払うのの4倍もかかる。AWSやAzureは本当に高すぎる、ストレージに対して100倍以上の価格だし、ハードドライブでも料金がめちゃくちゃ高い。ContaboやNetcupではこれを扱えない、彼らにはストレージが多すぎる。これを見るたびに同じ結論に達するんだ。誰かのマシンを借りるオーバーヘッドは、ハードウェアと電力コストに比べてかなり高いし、帯域幅と遅延のためにローカルネットワークでそのパフォーマンスを持つ方が良いと思う。問題は計算性能じゃなくて、ストレージコストとデータ転送が痛いんだ。この記事の本題ではないかもしれないけど、クラウドは低スペックハードウェアに良いとされてるけど、実際はそうでもない。ストレージコストが高すぎるんだ、Hetznerのストレージボックスでもね。

└

両方が答えだと落ち着いた気がする。Hetznerは手頃な価格だから、NASの完全バックアップ（ZFSスナップショットと増分バックアップを使って）を取れるし、ボーナスとしていくつかのサービスを家ではなくそこにホストできる。家のネットワークはまだ遅延がずっと低いから、例えばLightroomのライブラリにはそっちの方がいいね。

└

それは電気代次第だね。ヨーロッパの一部では、電気代がめちゃくちゃ高いから、Hetznerの方が実は安くなることもあるよ（彼らは全機械とデータセンター級のインターネット接続を提供しているのにね）。

ビジネスの多くは、実はそんなに重要じゃないことが多いよね。稼働時間にストレスを感じてるところを見たことがあるけど、彼らが運営してるものは全然重要じゃない。真昼間に本番環境を落としても、確かに嫌な気分になるし電話もかかってくるけど、結局は生活は続くんだよね。こういう会社は、オフィスのサーバーで250人のユーザーを支えるのに十分だったのに、クラウドワークロードに切り替えることで予算を大幅に増やすことになった。クラウドは一部の用途には素晴らしいけど、他には純粋なマーケティングのBSだと思う。多くのエンジニアは、十分なものではなく完璧なスケーラブルなソリューションを目指している気がする。

└

難しい時期にそのことを繰り返すチームメンバーがいたんだ。彼らはもっと重要な仕事から来ているから、私たちが失敗しても少なくとも誰も死なないってよく言ってた。

自分もVPSで運用してるよ。クラウドはずっと前にやめた。プロジェクトが利益を上げ始めたら、絶対に自分のハードウェアを買ってコロケーションするつもり。クラウドはデートアプリみたいなもので、10年間楽しんだけど、そろそろ真剣になって、実際に物事を進めて生産的にならなきゃね。

100%の稼働時間を目指すことで導入する複雑さは、その目標をしばしば台無しにするよ。ほとんどのビジネスは、時々1時間か2時間のダウンタイムやデータ損失を許容できるからね。早い段階でこの期待を設定すれば、もっとシンプルなシステムを設計できるよ。シンプルなシステムは、より信頼性が高いからね。

└

それに、ずっと安く済むしね。でも、一般的にはデータ損失に関してその期待は受け入れられないと思う。エンジニア以外の関係者はそう思ってないから。エンジニアは独りよがりで決定を下すわけじゃないし、期待を管理できるならそれはいいことだけど、ほとんどの場合、それはかなり厳しい戦いで、データ損失を保証できないから無能に見えるかもしれない。