- AWSとDigitalOceanからHetznerへ移行することで、クラウドコストを76%削減し、リソース容量は3倍に増加
- 以前はAWSの安定性とDigitalOceanの手軽さを活かして、2つのクラウドサービスを併用
- 無料クレジットを使い切った後、月449ドル超の運用コスト負担が発生し、Hetznerのような代替案を模索
- コスト削減のため、Talos LinuxベースのKubernetes、CloudNativePG、Ingress NGINX、ExternalDNS、cert-managerなどを組み合わせたセルフマネージドなクラウドスタックを構築
- HetznerのARM共有vCPUサーバーとS3互換ストレージを利用し、性能と安定性を維持しながら大規模なリソース拡張を実現
- 管理のしやすさはやや落ちるものの、欧州における代替クラウドとしてコスト・性能効率は非常に高い
背景
- DigitalSocietyが開発するすべてのソフトウェアはクラウドベースで稼働
- 移行前は主要インフラを**AWS（主要サービスや認証・メールなどを管理）とDigitalOcean（軽量サービス、監視、Kubernetes）**の両方で運用
- AWSは、15年以上使ってきた慣れと高いAPIの安定性を理由に採用
- DigitalOceanは、シンプルなKubernetes環境、無料のコントロールプレーン、そしてコスト効率の高さから採用
- 当初はDigitalOceanのみを使っていたが、データ集約型SaaSであるtapのように多くのリソースと追加クレジットが必要になり、AWSのスタートアップクレジット（$1,000）を活用
クレジット終了とコスト負担
- AWSのFargate（サーバーレスコンテナ実行）のおかげで初期は安価に構築できたが、tapサービスのデータ集約的な特性上、性能維持のため最低でも2x CPU、4 GiB RAMが必要
- Fargate基準ではこのスペックのコンテナは月70ドル以上かかり、2つのワーカーインスタンスとその他インフラを合計すると月449.50ドルまで増加
- 提供された無料クレジットは6か月足らずで使い切られ、自己資本のスタートアップにとって深刻な固定費負担となった
代替案の検討プロセス
- 高い運用コストの削減と技術的独立性の確保を目的に、UK/EU拠点のクラウドプロバイダーを検討
- Hetznerの価格競争力に魅了され、セルフマネージドVPS環境と運用の複雑さがあるにもかかわらず、AWSとDigitalOceanの両方からの移行を決断
- すでに大半のサービスをKubernetesベースで運用していたため、Talos Linuxの簡便なクラスタ構築機能を活用し、Hetzner環境でも独自のKubernetesクラスタを構築
- AWSやDigitalOceanのようなマネージドDBサービスはないが、CloudNativePGによってPostgreSQLクラスタをKubernetes環境に安全に統合管理（監視、バックアップ、障害対応など）
新しいインフラスタック
- Hetzner: ARMサーバー、ブロックストレージ、ロードバランサー、ネットワーク、ファイアウォール、S3互換オブジェクトストレージを活用
- Talos Linux: 宣言的設定によるKubernetesノード管理で運用自動化を実現
- CloudNativePG: KubernetesマニフェストでDBクラスタを宣言し、自動バックアップや障害対応などを統合支援
- Ingress NGINX Controller: クラスタ内のHTTPルーティングを統合管理
- ExternalDNS: IngressリソースとDNSを自動連携
- cert-manager: HTTPS用TLS証明書を自動発行
- すべてのインフラをTerraformとHelmでコード化し、GitHub Actionsによる自動デプロイでDevOpsを実現
コスト比較
- 移行前の月額コスト: AWS + DigitalOcean = $559.36
- 移行後の月額コスト: Hetzner = $132.96 (−76%)
- リソース増加:
- CPU: 12 vCPU → 44 vCPU (+367%)
- RAM: 24 GiB → 88 GiB (+367%)
- リソースが増えたにもかかわらず、月額総コストは大幅に低下
移行プロセスでの課題と試行錯誤
- HetznerのネットワークゾーンはAWSの**アベイラビリティゾーン（Availability Zone）**と完全には同一ではない
- AWSは1つのリージョン内に複数のアベイラビリティゾーンを持ち、プライベートネットワーキングがリージョン単位で広範囲に接続される
- Hetznerでは1つのnetwork zone（eu-central）の下に複数の地域（location）があり、それらの間のネットワーク遅延（latency）が大きい
- 実際、複数地域に分散した場合、性能低下などの問題が発生することを監視を通じて確認
- 代替として、単一地域（ニュルンベルク）内でPlacement Groupを活用し、物理サーバー分散による障害耐性を確保
- コンテナベースのサービスであっても移植は簡単ではない
- AWS ECSからKubernetesへ環境を移す際、設定全体の自動化スクリプト（特にconfigファイル配布など）の修正作業に予想以上の時間を要した
- 最終的にはKustomizeで機微な設定連携とconfigファイル管理体制を改善し、追跡性とレビューのしやすさを高めた
結論
- Hetznerは手軽なマネージドサービスではないが、セルフマネージド運用が可能なチームにとって非常に効率的な選択肢
- 独自運用によって詳細な構成の制御権を確保しつつ、コスト当たりの性能を最大化
- この方法により、データ集約型SaaSであるtapを妥当なコストと安定した性能のもとで継続的に開発・運用できる基盤を整えた
1件のコメント
Hacker News の意見
ベアメタルに直接デプロイしたときに体感できる性能向上が本当にすさまじい、という点を強調したい。私たちのサービスでは性能が2倍になり、予測可能で安定したパフォーマンスが得られる。その理由はいくつもある:
低レイテンシ: ネットワークを直接管理すると、大規模データセンターの複雑な共有ネットワークを使わずに済むため、遅延が10倍以上減る
キャッシュ最適化: ハードウェアに最適化したデプロイにより、最新CPUの真の性能を十分に引き出せる
専用NVMeの利用: ディスクI/O速度が非常に高い
もう1つの利点は、オートスケーラーがほとんど不要になること。同じ価格でハードウェア性能が10倍高く、速度も2倍なので、フルサイズで運用するほうが合理的。システム全体が安定し、管理もしやすい
S3の料金を心配する必要もない。各サーバーに15TBのNVMeドライブを載せてMinIO/garageクラスターを動かせばよい。私たちは10ノードクラスターで毎秒20GiB、APIコール5万件を処理している。S3ならAPIコールだけで毎秒$20〜$250かかるという驚くべき差がある
月額固定料金だけで済む
さらに、安価で高速なストレージ、大型PostgreSQLインスタンスの低コスト運用、クラウドで感じる制約や無駄な苦労が大きく減る
こうした構成に投資しても、AWS比で10分の1のコストだ
自前管理が負担なら、私たち(https://lithus.eu)がAWSの半額で代行管理し、DevOpsも支援する。連絡先は adam@ ドメイン参照
技術的背景: ベアメタルとは「仮想化(VM)」ではなく、実際の物理サーバー上で直接動かす方式のこと
本当に、「機材を増やせば速くなる」「コストは大した問題ではない」という昔の時代に立ち返ってほしいと思う。私のキャリアでは、.NET時代に単一キャビネットのサーバーで数百万ユーザーまで耐えた経験がある。その後、クラウドベース、コンテナ、Nodeマイクロサービスを使う会社に移ったとき、請求書と性能問題の混沌を毎日のように経験し、今でも時々ぞっとする
変化というのはいつも繰り返されるものらしい。私たちの会社を見ると、新技術なしでは動かないこと自体が、むしろローカルクラウド/エッジ/社内IDCの流れの最前線にいるようにも感じる
S3 APIを使うのは、タマネギをむくような気分だ。使い続けるほど涙が出てくる
ベアメタルでは、ネットワーク管理、セキュリティ・監視、パッチ適用、更新などのための専任人員が必要になる。こうした専門人材の人件費は、ある程度以上の規模でないと効率が出ない。だから中小企業なら、依然としてクラウドのほうがセキュリティと運用コストの面で有利だ
AWSでもLambdaの1 vCPU割り当て基準では、実際には50%程度しか与えていないことをAWS自身がドキュメントで明かしている。メモリ・CPU割り当てを増やせば比率は改善するが、常に100%の性能が出るわけではない
以前から、専用サーバーを使えば効率を最大化できると思っていた。Hetznerでいくつかノードを運用しているが、3年落ちの旧型サーバーでもオークションで借りれば、VMとは次元の違う性能が得られる。サーバーハードウェアはコア数やI/O重視で最適化されており、たいていのクラウドはハードウェアを過剰にオーバーコミットして提供している。ディスクI/Oですら、NAS上に置いてローカルディスクのように見せかける妙な小細工をしていることがある。ほとんどのスタートアップには、こうした過度な仮想化やNASベースのディスクは必要ない。むしろHetznerのようなところでサーバーを借りたほうが、はるか先まで、より安く進める。北米、特にカナダで、Hetzner並みの価格と品質を出す事業者が気になっている。OVHは知っているので、似たところがあれば教えてほしい
多くの人はGoogleやFacebookの技術構成をそのまま真似すべきだと思っているようだ。私たちは欧州のVPSで地味に運用しているのだが、新しく入ってくる人たち(ビジネス、開発の両方)は毎回クラウド移行プロジェクトを始めるべきだと言う。毎回「うちもすでにクラウドは使っているし、君の履歴書のためのクラウド移行プロジェクトはやらせない」と説得することになる
実際にクラウドとベアメタルサーバーのCPU性能をベンチマークした記録があるので、参考になるかもしれない https://jan.rychter.com/enblog/cloud-server-cpu-performance-comparison-2019-12-12
最近見つけたサイトも役立つかもしれない: https://vpspricetracker.com コンセプトがとても印象的だ。ここに載っている事業者の多くは専用サーバーも提供している
「米国内のHetzner品質で、現地ブランドでなくてもよい」なら、Hetzner自身が米国にも2か所のデータセンターを持っている
カナダで参考になりそうな事業者としては https://www.hostpapa.ca/, https://www.cacloud.com/, https://www.keepsec.ca/, https://www.canspace.ca/ などがある
私たちも同じトレンドを経験している。多くのチームがHetznerへ移行して、価格対性能比の高さに感心する一方で、Postgres運用(バックアップ、フェイルオーバー、監視など)をすべて作り直さなければならないことに気づく。そこで、Hetzner上で動作するマネージドPostgresを自分たちで作った。同じハードウェア最適化の構成で、高可用性(HA)、バックアップ、ポイントインタイムリカバリ(PITR)まで備えている。オープンソースで、ハードウェアの近くで動き、AWSでよくあるI/O課金やデータ送信の隠れた落とし穴もない。興味があればブログを見てほしい 1, 2
こうした理由から、私はBig Cloud、特にPaaSやマネージドSQLの魅力を強く感じる(私が助言している開発チームも同じだ)。運用経験があまりなくても、データベースのバックアップ/復旧、パッチ適用、接続制限、ポート管理、異常検知、DoS攻撃対応などが自動で処理されるので、採用すると安心感がある。政治的にも技術的にも、人気のクラウド企業を使うことが心理的な安全網になる
自前設定・自前管理のPostgresで問題があるなら https://www.elephant-shed.io/ が参考になるかもしれない
こういう種類の記事やコメントが、助言の文脈をほとんど示さずに話しているのが面白い。空き時間に教会のニュースレターを1つ回しているのか、世界中に顧客を抱える高トラフィックのエンタープライズSaaSなのかで、必要条件はまったく違う。自分の環境について説明せずに価格、性能、可用性を語る助言は、実質的に無意味だ。Webインフラが過度に複雑になった理由も、要件の異なる人たちの助言を互いに真似しているからだ
「要件が違うのに助言を無批判に従うと現実を余計に複雑にするだけだ」という私の考えに付け加えると、ある企業ではクラウドのアカウントマネージャーがCレベル幹部のランチに入り込み、AWS利用を指示させることがある。その過程でAWSのアーキテクトが私たちのチームに直接派遣され、自然と最も高価なサーバーレスの選択肢ばかり勧めてくる。しかし実際には、毎回DockerのOSイメージを新しくデプロイし、普通のベアメタルサーバーのパッチ適用と同じように絶えず管理しなければならない
私個人のPastebinですら、ベアメタルでないと持ちこたえられない状況だ(冗談)
これがIT業界の典型的な姿だ
要求条件・技術水準・コスト構造・問題領域が完全に異なる。HetznerとAWSは表面的にはどちらもクラウドっぽいが、実際にはまったく違うサービスだ。両方使ったことがある者としてそう言える
激しく同意する。自分の意見をブログにも書いたので参考までに https://news.ycombinator.com/item?id=45616366 要するに「ホスティング事業者はDIYからエンタープライズまで価格表で理解し、使わなくて済むなら(YAGNI)無理に選ばないこと」だ
私は10年以上、SaaSをHetzner上で運用している。完全な専用ハードウェア、ドイツとフィンランドのデータセンターにクラスターを組み、ansibleで管理している。サーバー間VPN接続にはvpncloudを使っている(このソフトウェアは本当に素晴らしい)。月間ホスティング料金はAWSなどに比べてごくわずかで、サーバー速度ははるかに速い。単純な構成と少数のサーバーで十分に回る。必要ならサーバーを追加すればよいが、ベアメタルなので数分でスケールするわけではない。数時間から数日ほど前もって計画すればよい。データベースはRethinkDB(いまはFoundationDBへ移行予定)の分散構成で障害に備えている
私もrethinkdb構成で似たように運用している。だが、なぜあえてFoundationDBを選んだのか気になる。RethinkDBはいまも保守されており、時々新機能も追加されている。思った以上にSlackコミュニティにも利用者が残っている
まだRethinkDBを使っている人がいるのはうれしい
HetznerのDE/FIセンター間をvpncloudで直接つないでいるのか? Hetzner自身もそういう機能を安価に提供しているのだと思っていた
最近、AWSからHetzner(およびNetcup)へ移行するチームを多く支援してきたが、人々にとって最大の驚きはコストや性能そのものではなく、15層もの管理抽象化(サービス)レイヤーを取り払うと構成が一気に単純になることだ。S3/EFS/FSxの悩み、Lambdaのコールドスタート、EBSバーストクレジットなどを気にしなくてよくなる。ただ高速なNVMeにDockerをデプロイすればすぐ動く。もちろん、DevOpsの力量(監視、バックアップ、パッチなど)は少し余分に必要になる。だが、こうした運用作業は自動化すれば毎週変わるようなものではない。Elestioではこの単純化に注力し、400以上のオープンソースソフトウェアの完全マネージドスタックを、どのクラウドでも提供している(CI/CDも含む)。Hetznerなど、どこであっても本番運用までカバーする https://elest.io (参考: 私はElestioで働いており、マルチクラウドのオープンソースサービスを提供している)
キャリア初期に、とても良い会社で働いていたのだが、その頃はRDSが対応していないPostgresのバージョンが必要で、EC2にPostgresを何度も自分でセットアップしなければならなかった。Dockerもない時代だったので、設定にどんどん時間を浪費した。RDSがそのバージョンをサポートした瞬間、すべてが一気に楽になった。午前3時までPostgresのインストールを繰り返していた記憶が今でも鮮明だ。この記事は良いが、結局は月に数百ドル節約する程度だ。エンジニア1人が月1時間だけ管理しても、その節約額は相殺されうる。突然障害が起きれば、1年分の節約が1日で吹き飛ぶかもしれない。時間の価値が重要でない個人プロジェクト(大容量サーバーが必要な場合)なら、ベアメタル運用のほうが向いていることもある。しかし最終的には、自分の時間の価値のほうが高くなっていく。たとえばGhostブログなら公式ホスティングを使えば月$10で済むし、Hetznerインスタンスに複数立てることもできる。だが結局、何か壊れたときに2〜3時間かけて直すくらいなら、追加で$20払うほうがいいのではと思うようになる
Hetznerの(一部の)専用サーバーの最大の利点は、帯域無制限であることだ。私は画像中心のサイトをホスティングしているが、Hetznerへ移行して以来3年間、固定料金だけを払い、夜も安心して眠れている
Hetznerにはスケール拡張に明確な限界がある。私たちも初期にはHetznerベースで数百台のVMを動かし、ピーク時には千台以上に拡張する必要があった。ところがこのとき問題が起きた。ブラックリスト入りしたIPが割り当てられることがあり、AWSやGoogle(特にS3)への接続で苦労した。さらに、ある時点では私たちのリージョンでVMが枯渇し、新規割り当て自体が止まった。結局、大規模な拡張が必要でなければHetznerは素晴らしいが、本当にスケールが必要なときは別サービスを組み合わせる必要があった
リージョンでVMが完全に枯渇するのは、特定のクラウドだけの問題ではない気がする。GCPも数年前は似たような状況だった。ピーク時に数百台のVMを一気に要求すると、どのクラウドでも厳しいのだと思う
MicrosoftがHetznerやScalewayのサービスをブロックした件はよく知られている https://www.linkedin.com/posts/jeroen-jacobs-8209391_something-interesting-happened-today-it-activity-7382774062164516864-GSKT/. AWSやGCPもそうだったとは知らなかったが、あまり驚きはしない。ビッグクラウドは「スパム流入」を口実にこうした反競争的な行為を正当化するが、実際にはそうではない
ここで言っているのは、Hetznerの実サーバー(Server Auctionなど)の利用者と、仮想サーバー(VM)の利用者との話の違いかもしれない。実際の物理サーバーはコストパフォーマンスや速度がはるかに優れており、VMは画期的ではないにせよ、依然として競合より安い
この論争はHetzner Cloud製品(VM)についての話だ。Cloud製品は専用サーバーに比べると比較的新しい。多くのユーザーは、専用サーバーの価値を求めてHetznerを使っていることのほうが多い
純粋に気になるのだが、どんなサービスなら数百〜数千のVMが必要になるのか、そしてなぜ専用サーバーではなくVMを使ったのか知りたい。Hetznerの最大構成VMが(48コア、192GB RAM、960GB SSD)らしいので、それほどの規模が必要というのは興味深い
Hetznerを使う理由はあるが、いくつか注意点もある。AWSより可用性がやや低く、リージョンの多様性も不足している。だからCloudflareと組み合わせることを強く勧める。Hetznerではコアシステム(K8s)を運用し、データはR2/D1/KV、Edge Durable Objectsで分散処理している。顧客データを各DOごとにシャーディングし、コアデータベースの負荷分散とセキュリティ効果の両方を得ている
AWSも意外と大規模障害はかなりあった。結局、マルチリージョン設計でない限り、可用性の問題は構造的に避けにくい
私もHetznerに専用サーバーでコアとストレージを冗長化し、OVHに世界各地のエッジノードを追加して、自前CDNのように使う構成にしている
顧客データがエッジにあるなら、その「コア」は具体的に何を指しているのか気になる