ハクソク

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

DigitalOceanからHetznerへの移行：ゼロダウンタイムで$1,432から$233へ

5時間前原文(isayeter.com)

概要

  • DigitalOceanからHetzner専用サーバーへの大規模本番移行事例
  • MySQL 248GB/30DB、34サイト、GitLab EE、Neo4j、モバイルアプリの無停止移行
  • インフラコストの高騰と年間$14,388のコスト削減
  • CentOS7→AlmaLinux9.7へのOSアップグレードも同時実施
  • 詳細なゼロダウンタイム移行戦略と各種トラブル対応

DigitalOceanからHetznerへの移行背景

  • トルコ国内のインフラコスト高騰、為替変動によるドル建て請求負担の増加
  • DigitalOceanで月額**$1,432**支払い、性能に対してコスト効率が悪化
  • Hetzner AX162-R（256GB DDR5 RAM/1.92TB NVMe/48コアCPU）で月額$233、年間**$14,388**のコストダウン
  • DigitalOcean製品自体の品質には満足、だが長期利用で価格差を痛感

移行対象システム概要

  • 30個のMySQLデータベース（合計248GB）
  • 34のNginx仮想ホスト（複数ドメイン対応）
  • GitLab EE（バックアップ42GB）
  • Neo4j Graph DB（30GB）
  • Supervisorによるバッチワーカー管理
  • Gearmanジョブキュー
  • 数十万ユーザー対応のモバイルアプリ
  • 旧サーバー: CentOS 7（EOL、セキュリティ更新なし）
  • 新サーバー: AlmaLinux 9.7（RHEL9互換、CentOS後継）

ゼロダウンタイム移行戦略（6フェーズ）

  • Phase 1: 新サーバーに全スタック構築（Nginx, PHP, MySQL8, Neo4j, GitLab EE, Supervisor, Gearman）
    • SSL証明書は**/etc/letsencrypt/をrsyncでコピー、移行後certbot renew --force-renewal**で一括更新
  • Phase 2: Webファイル（/var/www/html, 65GB, 150万ファイル）をrsyncで同期
    • 切替直前に増分同期を実施
  • Phase 3: MySQLマスター・スレーブレプリケーション
    • mydumperで並列ダンプ、binlog位置を記録しリアルタイム同期
  • Phase 4: DNS TTL短縮（A/AAAAレコードのみ3600→300秒、MX/TXTは変更せず）
    • 1時間待機でTTL反映、5分以内で切替可能に
  • Phase 5: 旧サーバーのNginxをリバースプロキシ化
    • Pythonスクリプトで全34サイト設定をproxyへ自動変換
    • DNS伝播中も旧IPアクセスは新サーバーへ転送、ユーザー影響ゼロ
  • Phase 6: DNS切替＆旧サーバー停止準備
    • Pythonスクリプトで全Aレコードを新IPへ一括切替
    • 旧サーバーは1週間コールドスタンバイ後に完全停止

MySQL移行詳細

  • mydumper/myloaderによる高速並列ダンプ＆リストア
    • 48コア活用で従来mysqldumpの数日→数時間に短縮
    • コマンド例:
      • mydumper --threads 32 --compress --trx-consistency-only --skip-definer --chunk-filesize 256 -v 3 --outputdir /root/mydumper_backup/
      • myloader --threads 32 --overwrite-tables --ignore-errors 1062 --skip-definer -v 3 --directory /root/mydumper_backup/
  • MySQL 5.7→8.0アップグレード
    • mysqlcheck --check-upgradeで互換性確認
    • mysql.userテーブルのカラム不一致問題発生（45列→51列）、sysスキーマもテーブル化でエラー
      • sysデータベース削除後、mysqld --upgrade=FORCEで解決
  • レプリケーションエラー（重複キー）
    • ダンプ2回実行間のデータ差分で発生、slave_exec_mode = 'IDEMPOTENT'で重複エラー自動スキップ
  • SUPER権限問題
    • read_only=1でもSUPER権限ユーザーは書き込み可能、全アプリユーザーからSUPERをrevokeし正常化

切替前検証・DNS・プロキシ

  • /etc/hosts編集でローカルから新サーバー動作を事前検証
  • DigitalOcean DNS APIでTTL短縮、A/AAAAのみ変更
  • Nginxリバースプロキシ自動生成スクリプトで全サイト一括対応
    • proxy_ssl_verify offで自己管理環境下のSSL検証省略

本番切替手順

  • 新サーバー: STOP SLAVE, SET GLOBAL read_only=0, RESET SLAVE ALL, supervisorctl start all
  • 旧サーバー: nginx設定テスト＆リロード（プロキシ稼働）、supervisorctl stop all
  • ローカル: DNS切替スクリプト実行（10秒以内に全Aレコード更新）
  • 5分待機、旧サーバーのcrontabをコメントアウト
  • GitLabのwebhook IP修正もAPIスクリプトで一括対応

結果とまとめ

  • 月額$1,432→$233、年間$14,388節約
  • 全サービス無停止移行、サーバースペックも大幅向上
  • 移行自動化・スクリプト化・段階的検証による業務リスク最小化
  • 大規模本番環境のコスト最適化・最新OS/DB化・無停止移行ノウハウ

Hackerたちの意見

MySQLの移行やバックアップにはPercona xtrabackupが最高だよ。ソースにほとんどパフォーマンスの影響を与えずにライブで動くし。これがすごくうまくいくから、新しいMySQLのバージョンにアップグレードする前には、いつも新しい対応バージョンが出るのを待ってるんだ。
数ヶ月前に、LinodeからHetznerにサーバーを2台移動させたんだけど、かなりのコスト削減になったよ。しかも、その2台にはいろんな言語で作られた数十のサイトが動いてて、古いライブラリやMySQL、Redisのインスタンスがあって、めちゃくちゃだったんだ。まあ、Claude Codeが全部移行してくれたんだけど、ライブラリがもう使えなくなった部分は書き直してくれたこともあった。今は複雑な移行もずっと簡単になったから、プロバイダー間の移動がかなり楽になると思うよ。
└
わお、Claudeの広告がHetznerの広告に埋め込まれてる。これ、どこまで深いんだ？
└
そうだね、すべてのものが再評価される時期が来てる。
└
すべてのクソみたいな話がAIについてである必要はない。
└
それをローカルモデルでできると想像してみて。すべての面でロックインを打破してるってことだよ。素晴らしいね。デジタルエリートのためのデジタルギロチンだ！
AWSからHetznerに移ったことで、年間約1200ドル節約できたよ。マジでおすすめ。AWSは詐欺みたいになってる。
└
サービスについて何か悪い点はある？
└
Hetzner Cloudか、彼らのVPSサービスのこと？
└
AWSはずっと詐欺だよ。Oracleよりもひどいし、法律的な契約すら使ってない。技術自体が問題なんだ。
└
それぞれにトレードオフがあるよね。AWSは確かに高いけど、Hetznerにはちょっとしたクセがある。最近、いくつかのVMがオフラインになったんだけど、どうやら大容量ストレージプールのアップグレード中にディスクが壊れたみたいで、2つの大きなプールで突然故障したんだ。それを解決するのに3日かかったよ。Hetznerにはボリュームのバックアップを取る統合オプションがなくて、自分でやらなきゃいけない:/ それに、冗長性のためにストレージノードのボリューム配分をコントロールすることもできない。
└
詐欺？払った分の価値はだいたい得られるよね。確かに、AWSで1つのラムダを運用するのに月6ポンドかかってたし（多分月500リクエストくらい）。すごく良かったし「ちゃんとしてた」けど、めっちゃ高いよね。今はCloudflareで無料でホスティングしてるし、似たようなものを5つ運用してる。でもAWSが提供するものが必要なら、それを得られるってこと。だから、時にはコストパフォーマンスが良くないこともあるよね。
└
AWSを詐欺だって呼ぶのはフェアじゃないと思う。複雑でパワフルだし、DIYアプローチと比べると多くのサービスに対して高い料金を取る。でも、サイトで価格が透明に見えるし、ほとんどのサービスを試すための無料プランもある。長期的なサポートや、必要になったときの強制アップグレードの扱いもまあまあ良いし、何か予期しない悪いことが起きてもカスタマーサポートの評判は悪くない。便利さやブランドのためにお金を払ってるのは確かだけど、情報をもとに選んでるならそれは詐欺じゃないと思う。お金を節約したいなら、RDSをVM上のPostgresに置き換えればいいけど、その分自分でデータベースインフラを管理しなきゃいけなくなるよ。
└
それは詐欺じゃなくて、カジノみたいなもんだよ。全てがお金を引き出すために設計されてて、自分が得をしてると思わせるんだ。
└
メルセデスが詐欺だって言うのは、ホンダシビックで満足してるからってことだよ。それは全く正当な好みだけど、ターゲット市場にいないからって詐欺になるわけじゃない。
DBのバックアップはどうしてるの？レプリカやスタンバイはあるの？それとも毎時バックアップとか？この単一サーバーのセットアップだと、ハードウェア（例えばSSD）の故障でアプリがダウンしちゃうんじゃないかな。SSDが壊れたら、再設定するのに数時間や数日かかるだろうし。
└
Hetznerは通常、ハードウェアサーバーを2x 1 TB SSDとして宣伝してるよ。SWraid1で運用することが強く推奨されてるから、実質1TBになるんだ。（彼らのイメージインストーラーはデフォルトでそれになる）最初のSSDが数年後に故障して、監視でそれをキャッチしたら、新しいボックスに移行するか、別の中間ソリューションやレプリカを見つけるか、他のドライブが動いてる間にホットスワップしてもらうかだね。もちろん、物理サーバーに移行するとクラウドの冗長性が失われるけど、コスト削減を考えるとリスクモデルを決めるときにそれを考慮する必要があるよ。そして、リモートストレージへの毎日のスナップショットやバックアップなしでこれを運用するのは頭おかしいよね。クラウドでも同じことが言えるけど、そっちの方が設定は楽だし。
└
> こういうシングルサーバーのセットアップだと、ハードウェアのことを考えないわけにはいかないよね… うん。このブログ記事は、物事を考えずにコスト削減ばかりに目を向けた人が書いたみたいだ。彼らのDigitalOceanのVMはライブマイグレーションやスナップショットをサポートしてたと思うよ。Hetznerでもそれはできるけど、クラウド製品だけだし。Hetznerのベアメタルでは絶対に無理。もしHDや他のコンポーネントが壊れたら、そのまま終わり。HetznerはHDを交換してくれるけど、ゼロから復元するのは自分の責任だ。これについては、Hetznerもいろんなところで明言してるよ。
└
誰もそんなに気にしないかもしれないね、そんなに長くダウンしてても。例えば、私のHOAのモバイルアプリが1週間ダウンしてても、全然気にしないよ。すべてに常時稼働が必要ってわけじゃないし。
└
もしそれが彼らが選んだトレードオフなら、君が間違ってるって言える立場じゃないよ。すべてのアプリが24/7の可用性を必要としてるわけじゃないし。ほとんどのウェブサイトは、たまに数時間ダウンしても深刻な影響は受けないよ（予定外でも）。コスト削減がリスクを上回るなら、それは合理的なビジネス判断だと思う。もっと興味深いのは、彼らがどんなバックアップとリカバリ戦略を持っているか、そしてHetznerに移ったときにどの部分を変更したかってことだね。
└
一番簡単だったのはMongoDBのレプリケーション、シャーディング、フェイルオーバーで、これらはすごく簡単だった。最近はPostgreSQLでpg_auto_failoverを使ってやったよ。モニターノードが1つ、プライマリが1つ、レプリカが1つ。驚いたことに、PostgreSQLの設定やその注意点を理解すると、レプリケーションもすごく簡単になる。MySQLはPostgreSQLよりもさらに簡単だと思う。ゼロダウンタイムの移行も達成したよ。
移行の共有は素晴らしくて、役に立つ教えだね、ありがとう！DigitalOceanとHetznerの比較は、毎日いろんな分野でやってるトレードオフだと思う。自分で夕飯を作る代わりにDoorDashやUberEatsを使う感じ（コスト比も似てるし）。私は3つの主要なクラウドで働いてるし、オンプレミスもやってる。ちょっとした作業や概念実証のテストには、やっぱりDigitalOceanのコンソールに行くことが多い。ボタンをクリックするだけでサーバーやバケットが準備できて、アクセス情報もあって、デフォルト設定もまともで、バックアップが必要ならチェックボックス一つで済むっていうのは、すごく便利だよね。時間もお金に値するし。
└
何を言いたいのかよくわからないけど、Hetznerのコンソールもそんな感じで動くよ。
└
> ボタンをクリックするだけでサーバーやバケットが準備できて、アクセス情報もあって、デフォルト設定もまともで、バックアップが必要ならチェックボックス一つで済むっていうのは、すごく便利だよね。時間もお金に値するし。君が言ってるのは、Hetzner Cloudのことだね。これが何年も前からそうだった。少なくとも6年は。HetznerはHetzner Cloud APIも提供していて、ボタンをクリックしなくてもすべてをIaCで管理できるんだ。 https://docs.hetzner.cloud/
└
https://xkcd.com/2948/
└
投稿には二つの面白いポイントがある。一つはゼロダウンタイム移行の全ステップについて。これは広く応用できる。もう一つは、クラウドインスタンスをベアメタルに置き換える決断。コストを大幅に節約できるけど、速やかなフェイルオーバーやデータバックアップの損失も考慮しなきゃいけない。もし俺がやるなら、追加で200ドル払ってホットスペアを用意して、数日ごとにプライマリを切り替えて、両方がちゃんと動くことを保証するかな。大規模な障害リスクを大幅に減らすには、比較的安い価格だと思う。
└
自分専用のflyioスタイルのデプロイを作ったよ。デジタルオーシャンのAPIを使ってサービスを展開してて、ほとんど彼らのウェブサイトには行かない。全てターミナルからやってる。
└
ヘッツナーのサーバーでCoolifyを使ってるけど、ワンクリックでサービスが体験できるよ。
AWSはカードだけで済むけど、Hetznerに登録しようとしたらパスポートの写真が必要だった。
└
最近、こういうトレンドがどんどん増えてるよね。業界がもっとゼロ知識の方法を採用してくれたらいいのに。既に存在していて数学的にも証明されてるのに、実際にはあまり普及してないみたい。 - OpenAIは100ドルのチャージ時にパスポートが必要だって - Boltも最近、サービスを使うためにパスポート番号を求めてきた - Anthropicも新しいユーザーにパスポートを求めてるみたい - 近いうちにOSやウェブサイトで年齢制限がかかるのかな。こういう身分証明の方法を最小限にするか禁止する法律が（ヨーロッパやアメリカで）できてほしい。プラットフォームの悪用を防ぐために企業を支援したいけど、私のパスポートの全体写真が彼らの関心事であるべきではないと思う、特にB2Bビジネスにおいてはね。
└
それはクレイジーだね。なんでパスポートの写真が必要なんだろう。絶対に嫌だ - これが理由でAWSや他の選択肢に行くことにするよ。なんで人々はホスティングプロバイダーに喜んで渡してるの？もし彼らが侵害されたら、アイデンティティ盗難に無用にさらされることになるのに。
└
数週間前にヘッツナーに登録したけど、身分証明書は必要なかったよ。クレジットカードで支払ってる。俺たちのケースで何が違うのかは分からないけど、俺はEUにいる。
└
DOを使ってるけど、Heztnerでアカウントを開こうとしたら、Visaカードが通らなかった（DOの支払いに使ってるやつ）。だから、私からはビジネスなしだね。
└
私は何も悪いことしてないし、パスポートも特に秘密ってわけじゃないから、喜んでHetznerに提出するよ。
これは、いろんなクラウドプロバイダーから来たお客さんのために何度もやったことがあるよ。私たちの場合、Kubernetesを使って、Hetznerでマルチサーバー（時にはマルチAZ）デプロイに移行して、サーバー間でワークロードを分散させてHAを提供してる。KubernetesはOPみたいな単一ノードのデプロイにはちょっとオーバーかもしれないけど、複数ノードが関わるとすごく理にかなってくる。バックアップにはVeleroとアプリケーションレベルのバックアップを使ってる（つまり、PostgresのWALバックアップでPITRを実現）。HAのために、すべての状態が少なくとも2つのノードにあることを確認してる。一般的にベアメタルの方がパフォーマンスがいいと感じるね。AWSと比べると、サービスの応答時間が半分になることが多い。仮想化自体にそんなにオーバーヘッドがあるわけじゃなくて、他の要因が影響してる。例えば、ベアメタルは以下のような利点があるよ： - ディスクレイテンシの低減（NVMe対ネットワークブロックストレージ） - ネットワークレイテンシの低減（専用ファイバーを使ってるから、AZ間のレイテンシは約1/10） - キャッシュの競合が少ない、など。[1] もしこのことについて話したいなら、メールしてね：adam@会社のドメイン。[0] https://lithus.eu [1] 6ヶ月前にこれについてもっと書いたよ：https://news.ycombinator.com/item?id=45615867
└
k8sのデプロイを移動させるのはめっちゃいいね。クラウド系のサービスに比べて、ベンダーロックインがほとんどないし。俺のスタックは、k8s、ホスティングされたPostgres、S3タイプのストレージなんだ。自分でPostgresをホスティングすることもできるから、結局はk8sとS3に依存してる。ヘッツナーにはS3ストレージみたいなのがあるらしいけど、詳しくは見てないし、100TBの移動は手間がかかるんだろうな…。
2013年にDOを始めた時は、20GBのSSDと512MBのRAMが月5ドルだったんだよね。なんでか当時はVATを払わなかったけど、今は払ってる。今の4ドルのプランも512MBで1 vCPUだけど、SSDが10GBになった。だから、RAMやCPU、ストレージに関しては、価格が下がったりスペックが上がったりするはずの10年の技術進歩が全然反映されてない感じ。そうそう、AIがメモリを買い占める前にDOは高くなっちゃったね。
└
インフレを考慮してないね。2013年の5ドルは、今の価値で7ドルだよ。今の4ドルは、だいたい2013年の2.82ドルに相当する。だから、1つの要素が50%減っても、価格がほぼ44%下がってるってこと。進歩してるように見えるね。
こういう記事を見るたびに思うんだけど、誰もサーバーの冗長性やロードバランサーについて気にしないよね。たった1台の大きなサーバーが故障して、いくつかのサービスがダウンするのは大丈夫なの？お金はたくさん節約できたけど、メンテナンスや将来の頭痛の種に時間をかけることになるよ。
└
私も同じことを考えた！ちなみに、今はHeztnerで管理されたPostgresから自己管理に移行中なんだけど、[autobase](https://autobase.tech/)を使ってるよ。もちろん、高可用性を求めるなら、サーバーは1台以上必要だね。
└
サービスやそのウェブサイトの重要度によるよね。時には、10年間で1週間か1ヶ月のダウンタイムがあっても、サーバーが動き続けるのは全然許容範囲だよ。これは、あまり変更されずに過剰にプロビジョニングされた単一サーバーで見られる稼働時間だね。例えば、ウェブサイトが業務の中心ではなく、単なるショップフロントやパンフレットのような小規模ビジネスとか。趣味のウェブサイトも、たまに短時間ダウンしてもあまり気にしないよね。多くのフォーラムやブログも重要じゃないし、ダウンタイムは大したことじゃない。こういうウェブサイトはたくさんあって、明らかに市場の下位に位置してるけど、実際にはほとんどのウェブサイトがそうで、トラフィックが少ないウェブサイトのロングテールだよ。すべてが高可用性である必要はなくて、もしそれを求めるなら、こういうプロバイダーは通常ロードバランサーとかも提供してるよ。ホスティングには、Squarespaceから安い共有ホスティング、高価な自己ホスティングやAWSのようなプロビジョニングされたクラウドまで、幅広い選択肢があることを忘れがちだよね。
└
彼らは、実際には「メンテナンスや将来の頭痛が多い」という経験がほとんどない長い歴史に基づいてこの決定を下しているのかもしれないね。
└
こういう記事は、アプリケーションの要件と選ばれたソリューションの間にミスマッチがあるところで人気だね。趣味のプロジェクトや、小さなビジネスを運営してるのに、エンタープライズグレード（自分の定義を当てはめてね）に過剰に設計しちゃうと、たまにダウンタイムがあってもお客さんは翌日戻ってくるだけなのに、クラウドアーキテクチャに全力を注ぐ必要はないかも。だから、ダウンタイムは大したことないとか、アウトageのリスクを取るのは大丈夫って意見が多いのも分かる。そういうアプリケーションは結構あるからね。この文章の混乱するところは、実際には稼働時間に理想的じゃないサービスへのゼロダウンタイム移行を強調してるところ。ヘッツナー側にちょっとしたアーキテクチャを追加するのはそんなに高くないと思う。移行をやってるなら、給料もらってるか、時間がちょっと余ってるなら、ゼロダウンタイムで移行するのは賢い選択だね。ゼロダウンタイムを強調してるのに、選んだアーキテクチャが何も失敗しないことに依存してるのはちょっと面白いね。
ああ、そうそう、DBのレプリカを作って、レプリカをプライマリに昇格させる。簡単そうに見えるよね！これがうまくいくのは、製品に組み込まれた機能としてあったり、DevOpsの手順があって週に1回やるような場合だね。低レベルのコマンドで経験があまりない状態でやると、問題が出る可能性が高いよ。実際、ここでそうなったんだ。