DigitalOceanからHetznerへ移行！クラウドコストを劇的に削減するサーバー移転ガイド

DigitalOceanからHetznerへのサーバー移行を検討しています。コストパフォーマンスとサーバー性能を最適化するためのベストプラクティスや、移行時に注意すべきポイントについて知見を共有してください。

数ヶ月前にLinodeとDOからHetznerにサーバーを2台移転したけど、同じくらいのコスト削減になったよ。最高だったのは、その2台のサーバー上で、異なる言語や古いライブラリ、MySQLやRedisのインスタンスを使って動いている何十ものサイトが混在していたこと。まさにカオスだった。でも、Claude Codeが全部移行してくれたんだ。ライブラリがもう使えないところは書き直したりしてね。今の時代、複雑な移行作業はずっと楽になったし、これでクラウドプロバイダー間の流動性がかなり上がるはず。

DBのバックアップはどうしてるの？レプリカやスタンバイは用意してる？それとも1時間おきとか、その程度？というのも、今回みたいなシングルサーバー構成だと、ハードウェア（SSDとか）が故障したらアプリが止まるし、SSDが逝ったら復旧作業に何時間も、あるいは何日もダウンタイムが発生すると思うんだけど。

移行のシェア、参考になるし素晴らしいよ。ありがとう！DigitalOceanとHetznerの比較は、日常のいろんな場面で直面するトレードオフと同じだよね。自分で夕食を作る代わりにDoorDashやUberEatsを頼むようなものだし、コスト比率も似たようなもんだ。自分は3大クラウド全部とオンプレミスもやってるけど、ちょっとした作業やPoC（概念実証）には今でもDigitalOceanのコンソールを使うよ。ボタン一つでサーバーやバケットがすぐ準備できて、アクセス情報もわかって、デフォルトの設定もまとも。バックアップが必要ならチェックボックス一つで済む。自分の時間だって金銭的価値があるからね。

これは自分たちも様々なクラウドプロバイダーからのお客様に対して何度か実施してきたことだよ。私たちの場合は、Hetzner上でマルチサーバー（時にマルチAZ）構成にして、Kubernetesを使ってワークロードを分散させ、HAを確保してる。OP（投稿者）のようなシングルノード構成にKubernetesはやりすぎかもしれないけど、複数ノードになれば理にかなってくる。バックアップはVeleroと、重要なワークロードにはアプリケーションレベルのバックアップ（PostgresのWALバックアップでのPITRなど）を併用してる。HAのために全状態を最低2ノードに保持することも徹底してるよ。ベアメタルの方が圧倒的にパフォーマンスが良いこともわかっている。AWSと比較してサービス応答速度が半分になることも珍しくない。仮想化にオーバーヘッドがあるというより、それ以外の要素が大きいんだ。例えば、ベアメタルならディスクレイテンシの低減（NVMe対ネットワークブロックストレージ）や、ネットワークレイテンシの低減（専用光回線を使えばAZ間の遅延は1/10になる）、キャッシュ競合の削減などが挙げられる。もし興味があればいつでもメールして：adam＠会社ドメインまで。

こういう記事を見るたびに思うんだけど、誰も冗長性やロードバランサーのことなんて気にしてないよね。1台の巨大サーバーが故障してサービスが全滅しても平気なの？コストは浮くだろうけど、その分メンテナンスや将来的なトラブル対応に追われることになるよ。

AWSからHetznerへの移行計画を練ってるところ。Amazonは高額な料金設定（競合の20倍になることもある）で縛り付けてくるし、まともな価格にするには長期契約を強いてくる。そのくせ、他へデータを移そうとすると法外な費用を請求してくる。今の自分には到底受け入れられない、顧客を無視したやり方だ。Amazonはエグレス料金でユーザーを囲い込んでいるつもりかもしれないけど、逆にユーザーを締め出してもいるんだ。一度どこか一部を競合に移すと、高いエグレス料金のせいで全部移さざるを得なくなる。移行は大変だろうけど、幸いにもAmazon独自のサービスに依存した構成にはしていなかったから、まだ少しは楽になるはず。

Claudeが書いた報告書をそのまま記事にしたような感じで、ちょっと読みづらいな。LLMの助けを借りてこれだけコスト削減できたのはお見事だけど、記事にするならせめて推敲して、冗長な部分やAI特有の言い回しは削ってほしい。

数ヶ月前、小さなSaaSの個人プロジェクトのためにAWSの代替を探してた。主な動機はコスト削減と、EUのクラウドプロバイダーを応援したかったから。最初はHetznerにするつもりで、面倒な作業は自分でやろうと覚悟してたんだ。でもね、結局ダメだったのはHetznerのIPアドレスの評判の悪さだよ。職場で学んだことなんだけど、AWSのマネージドファイアウォール設定で彼らのIPの多く（というか全部かも）がブロックされてる。職場のノートPCからだとHetzner上のサイトを開くことすらできないんだ（CloudFlareとか使えば別かもしれないけど）。調べてみたらDDoS対策もかなりお粗末みたいだしね。結局、EUリージョンのDO App Platformにしたよ。マネージドDBが使えるのも大きなプラスだったし。

まあ、Hetznerには気をつけたほうがいいよ。昔は好きだったんだけど、つい最近移行したんだ。たった36ドルの支払いトラブルで、CI/CDパイプラインに使っていた30台くらいのVMを全部停止された。銀行からの全額支払い済み証明を提出しても、彼らは検討も議論も拒否して、緊急連絡をしている最中にも問答無用でアクセスを遮断した。今はScalewayを使ってる。

このガイドで使われている手法は、ダウンタイムを最小限に抑えながらサイトをサーバー移行する時に自分もよく使うやつだ。DNS TTLの短縮（IP入れ替えをしない場合）、rsyncでファイル転送、/etc/letsencrypt/のSSL証明書のrsync、DBのコピー（更新頻度が低くて小規模ならレプリカなしで、移行中だけ読み取り専用にして済ませる）、ローカルの/etc/hostsを書き換えて新サーバーをテスト、旧サーバーのcronを停止、旧サーバーのnginxを新サーバーへのリバースプロキシに変更、DNS変更（またはIPの入れ替え）、新サーバーでcronを有効にする。これらだね。