こんにちは。shuheiです。長年、大規模ブログサービスの運営に関わっており、その中で、サーバー移行を伴う大幅なコスト削減を行ったことがあります。当社でも、サーバー移行を事業として手がけているので、今回はコスト削減の視点でのノウハウを記事にします。
2010年代後半から、X（旧Twitter）やInstagramのような即時性の高いSNSの利用者が増えはじめ、ブログのようなストック型サービスの利用ユーザーは少しずつ減少傾向になっていきました。さらに、当時は広告収益が売上の中心でしたが、広告全般の見直しや検索サービスの仕様変更の影響もあり、さまざまな施策を行っても2020年以降はPV数が減少し、広告収益も下がっていきました。
一方で、サービスを支えるサーバーの規模はすぐには小さくなりません。売上が下がっていく中で、サーバー費用をどう見直すかが大きな課題になりました。
まずはサーバー費用のみなおし
当時は、AWSを利用して運営していました。最初に行ったのは、コストエクスプローラーを見ながら、どこに費用がかかっているのかを確認することでした。
見ていくと、いくつか気になる点がありました。まず、対策は行っていたものの、トラフィック料金はまだ大きな割合を占めていました。また、サーバーごとの役割に対してスペックが合っていないものも多く、必要以上に大きなインスタンスを使っている箇所が見受けられました。さらに、クラウド内で発生している通信費用も無視できない金額になっていそうでした。
クラウドは使った分だけ費用が発生するため、構成がそのままでも利用状況が変われば費用感は変わります。逆にいうと、利用状況に対して構成が合っていなければ、無駄な費用が積み上がっていきます。まずはそこをひとつずつ見直していくことにしました。
検討
サーバースペックの見直し
最初に行ったのは、現状のサーバースペックが過剰になっていないかの確認でした。
長く運営しているサービスでは、過去のピーク時や将来の伸びを見越して設定したスペックが、そのまま残り続けていることがあります。サービスの利用状況が変わっても、サーバー構成だけが当時のままになっていると、現在の負荷に対して大きすぎるリソースを使い続けることになります。
そこで、各サーバーの役割と実際の負荷を見ながら、過剰なものについてはスペックダウンを行いました。これは地味な作業ではありますが、リスクを抑えながら確実に費用を下げられるため、最初に取り組むべき内容でした。
他のクラウドサービスとの比較
サーバースペックの見直しと並行して、他のクラウドサービスへの移転も検討しました。ちょうどその時期に、OCIの話を聞く機会があり、AWSとOCIで同じような構成を置いた場合に、どの程度の費用差が出るのかを比較することにしました。
ここでは、AWSとOCIを比較対象として整理しています。以下の表は実際の請求額そのものではなく、当時と同じ観点を現在の公開価格（2026年7月時点）で試算し直した比較例です。費用差が出やすい項目に絞ってまとめています。また、表に記載しているサーバースペックは、実際に使用していたサーバーのスペックとは異なります。
前提は、東京リージョン相当、税別USD、1TB=1024GBで計算しています。AWSのComputeとDBは1年リザーブ完全前払いを月割り換算し、トラフィックはCloudFront利用かつ請求代行事業者（クラスメソッド）のEC2・CDN割引プランで公開されている割引率を適用した単価で計算しています。ロードバランサーはオンデマンド料金で計算し、OCIもオンデマンド料金で計算しています。CloudFrontの無料利用枠（月1TB）やリクエスト料金は含めていません。ストレージはAWS/OCIではなく外部のオブジェクトストレージサービスを利用していたため、この比較には含めていません。サポート費用、バックアップ、監視、NAT Gateway、IPアドレス、スナップショットなどの費用も含めていません。
| 項目 | AWS | OCI | メモ |
|---|---|---|---|
| トラフィック料金 30TB/月 | 約$1,230 | 約$510 | AWSはCloudFrontを利用し、クラスメソッドのEC2・CDN割引プランで公開されている全リージョン一律単価$0.0399/GB（東京リージョン定価$0.114/GB比で約65%割引）を適用して概算。割引プランを使わない定価の場合は約$2,990。OCIは日本/APACの最初の10TBが無料、超過20TBを$0.025/GBで概算。 |
| Compute 16CPU/32GB/50GB | 約$390 | 約$180 | AWSはx86（AMD/Intel）前提でc6i.4xlarge（16 vCPU/32GiB）の1年リザーブ完全前払いを月割り換算し、EBS gp3 50GBを追加。OCIはx86系のE4 Flexで8 OCPU/32GB（16 vCPU相当）とBlock Volume Balanced 50GBで計算。 |
| ロードバランサー | 約$18から | 約$8から | AWSはALBの時間料金のみの最低額。30TBがALBを通る場合、LCU課金の目安として約$250が追加でかかる。OCIはFlexible Load BalancerのBaseで概算。 |
| DB 16CPU/128GiB/700GB | 約$1,160 | 約$460 | AWSはRDS for MySQL db.r6i.4xlarge（16 vCPU/128GiB）の1年リザーブ完全前払いを月割り換算し、gp3 700GBを追加。OCIはMySQL HeatWaveの16 ECPUとストレージ700GBで概算。OCI側はメモリ量をスペック条件として扱い、料金はECPUとストレージで計算。 |
| 月額合計の目安 | 約$2,800 | 約$1,160 | ロードバランサーのデータ処理量課金を含めない最小構成の概算。 |
| 月額合計の目安（30TBがLBを通過） | 約$3,050 | 約$1,170 | AWSはALBのLCU、OCIは30TB相当の平均帯域を加味した概算。 |
この条件で見ると、差が大きいのはトラフィック料金とDB料金でした。
特にブログサービスのように画像や静的ファイルの配信量が多いサービスでは、Computeの単価差よりも、外向き通信量の見直しのほうが効きやすいです。今回の試算では請求代行事業者の割引プランを適用した単価を使っていますが、こうした割引を使わずCloudFrontの定価で計算すると、トラフィックだけで約$2,990、合計は約$4,560まで上がります。外向き通信が大きいサービスでは、移転の前にまずこうした割引プランの利用を検討する価値があります。ただ、割引を使ってもOCIとの単価差は残るため、外向き通信の単価差が費用差の中心になる構図は変わりません。プラン体系や割引率は改定されるため、検討時には最新の条件を確認する必要があります。また、DBはマネージドサービスの選び方によって差が大きくなるため、実際の移行時にはエンジン、冗長化、バックアップ保持、IOPSなどの条件をそろえて再計算する必要があります。
もうひとつ、比較時に見ておきたいのがサポート費用です。AWSはBasic Supportであれば追加費用なしで利用できますが、技術的な問い合わせをしながら本番運用していく場合は、有償サポートを検討することになります。公開されているAWS Supportの料金では、Business Support+は月額29ドルまたは月間AWS利用料の割合、Enterprise Supportは月額5,000ドルまたは月間AWS利用料の割合のいずれか大きいほうで計算されます。つまり、利用料が増えるほどサポート費用も増える構造になっています。
一方でOCIは、有料アカウントであればサポートリクエストを作成できます。AWSの有償サポートのように月間利用料に対して何%という形で別途サポート費用を積み上げる必要がない点も、コスト面では見逃せない差です。
なお、AWSのEC2はvCPU表記、OCIはOCPU表記なので、単位の違いにも注意が必要です。OCIのx86系では1 OCPUが2 vCPU相当、Arm系のAmpere A1では1 OCPUが1 vCPU相当として扱われます。今回の比較では、AWS側をx86前提とし、AWSは16 vCPU、OCIは8 OCPU（16 vCPU相当）でそろえました。
参考にした公開情報は、AWSのEC2 On-Demand Pricing、Amazon CloudFront Pricing、AWS Elastic Load Balancing Pricing、AWS Support Plan Pricing、AWS Price List API、クラスメソッド AWS請求代行 プラン詳細、OCI Cloud Price List、OCI Support Requestsのドキュメントです。料金は変更されるため、実際の移行検討では各社の料金計算ツールで再計算する必要があります。
AWSから移転が可能かどうか
費用面で差が出るとしても、実際に移転できなければ意味がありません。そこで、AWSからOCIへ移転できる状態かどうかも確認しました。
レガシーシステムを移転する場合、障害になりやすい項目はいくつかあります。今回のようなクラウド間移転でも、オンプレからクラウドへ移転する場合でも、事前に見ておきたい観点は大きく変わりません。
| 確認項目 | 障害になりやすい理由 | 見ておきたいポイント |
|---|---|---|
| DBのバージョン | 古いDBのままでは、移転先のマネージドDBで対応できないことがある。 | 事前に移転先で利用できるバージョンへ上げられるか、段階的な移行が必要かを確認する。 |
| 文字コード・古いデータ | 長く運用しているサービスでは、過去の文字コードや不正な文字列が残っていて、dump/import時に問題になることがある。 | データ移行のリハーサルを行い、エラーになるデータを先に把握しておく。 |
| OS・ミドルウェア | 古いOS、Webサーバー、言語ランタイム、ライブラリが移転先でそのまま使えない場合がある。 | 事前にバージョンアップできるものと、互換性確認が必要なものを分けて整理する。 |
| ファイルストレージ | 画像や添付ファイルがサーバーローカルやNFSに置かれていると、データ量や同期方法が移行の負担になる。 | オブジェクトストレージなどへ切り出せるか、移行対象から分離できるかを確認する。 |
| バッチ・cron処理 | Web画面以外で動いている定期処理は見落とされやすく、移行後の不具合につながる。 | 実行タイミング、依存しているファイルや接続先、失敗時の通知方法を棚卸しする。 |
| 外部連携 | メール、広告、解析、認証、決済などの連携先で、接続元IPや証明書、DNS設定の変更が必要になることがある。 | 連携先ごとに設定変更の有無と、切り替え時の確認手順を整理する。 |
| 監視・運用手順 | クラウドを変えると、監視項目やログの見方、障害時の対応手順が変わることがある。 | 移行後も同じレベルで検知・調査・復旧できるかを確認する。 |
対象のブログサービスは、20年以上運営されてきた歴史の長いサービスでした。もともとはオンプレで稼働しており、クラウドへ移転した際も、クラウドで正常に稼働させるための対応が中心でした。そのため、特定のクラウドサービスに強く依存するような作りにはなっていませんでした。
MySQLについても、オンプレからAWSへ移転する際にMySQL 8系へアップデート済みでした。RDSではMySQL 5.7系を動かし続けることが難しかったため、このタイミングでバージョンアップしていたことが、結果的に次の移転のしやすさにもつながりました。
また、移行のネックになりやすいストレージサーバーについては、すでに外部のオブジェクトストレージへ切り出し済みでした。そのため、AWSからOCIへ移転する際に、大きなストレージ移行を改めて行う必要がありませんでした。
こうした事情もあり、いわゆるベンダーロックイン状態にはなっておらず、AWSからOCIへの移転は現実的に可能だと判断できました。
OCIを使う場合の懸念点
一方で、OCIに移転する場合の懸念点もありました。費用だけを見ると魅力的でも、クラウドサービスを変えるということは、運用の前提を変えることでもあります。
企画側の立場でまず気になったのは、ベンダーロックインの問題でした。特定のクラウドが提供する機能に深く依存していると、別のクラウドへ移転するときに、同じ機能をそのまま使えるとは限りません。機能差を吸収するための開発が必要になれば、移転によるコスト削減効果が小さくなる可能性もあります。
あわせて見ておきたいのが、どこまでクラウドネイティブな構成になっているかです。たとえば、サーバー、DB、ストレージ、ロードバランサーのような比較的置き換えやすい構成であれば、移転先を変えても検討しやすいです。一方で、特定クラウドのマネージドサービス、サーバーレス、キュー、イベント連携、監視、権限管理などを深く組み合わせている場合は、単純なサーバー移転ではなく、アーキテクチャ全体の見直しに近くなります。
今回のサービスでは、もともとオンプレで長く運用していた経緯があり、AWSに移転した後もAWS固有の機能へ深く依存しすぎない構成になっていました。そのため、OCIへの移転は現実的な選択肢として検討できました。逆に、AWSのマネージドサービスや周辺機能に強く依存しているサービスであれば、同じような判断はできなかったと思います。
もうひとつの懸念は、社内のノウハウでした。AWSは利用経験のあるエンジニアも多く、障害対応や調査の進め方もある程度イメージしやすいです。一方で、OCIは社内での利用経験が少ない場合、運用開始後に調査や判断に時間がかかる可能性があります。コストは下がっても、運用チームが扱いにくい状態になってしまうと、サービス全体のリスクは上がってしまいます。
そのため、移転の判断では、単に月額費用だけを見るのではなく、移転後に誰が運用できるのか、障害時にどこまで自分たちで判断できるのか、サポートを含めて必要な体制を作れるのかも確認しました。今回のケースでは、技術メンバーが事前検証を進められたこと、サービスがベンダーロックインしにくい構成だったこと、そしてサポートを受けながら進められる見込みがあったことから、移転に踏み切る判断ができました。
結果
これらの検討結果を踏まえて、最終的にOCIへ移行することにしました。
サーバー費用は50%以下になる見込みで、実際に大きなコスト削減につながりました。単純にスペックを下げるだけではなく、クラウドサービスそのものを比較し直したことで、より大きな削減余地を見つけることができました。
もちろん、クラウド移転には作業コストや検証コストがかかります。移転中のトラブルも考慮する必要があります。それでも、月額費用の差が十分に大きい場合は、移転そのものが現実的な選択肢になります。
特に、長く運営されているレガシーシステムでは、移行前に確認しなければならない点は多いです。OSやミドルウェアのバージョン、DBの文字コード、古いデータ、バッチ処理、運用手順など、ひとつずつ確認しながら進める必要があります。
ただ、レガシーシステムだから必ず移行が難しいとは限りません。むしろ、オンプレ時代から運営されてきたサービスは、特定のクラウド機能に深く依存していないこともあります。その場合、現在の構成を整理し、移行のネックになる箇所を先に切り出しておけば、想像していたよりも現実的に移行できるケースがあります。
今回のサービスでも、事前にMySQLのバージョンアップやストレージの切り出しを進めていたことが、移行しやすさにつながりました。レガシーシステムほど、まずは「移行できない」と決めつけるのではなく、どこがクラウド固有の依存なのか、どこが単に古いだけなのかを分けて見ることが重要だと思います。
最後に
サーバーコストの見直しで取れる手段は、対象となるサービスの置かれている状況によって変わってきます。
今回のブログサービスでは、OCIに移転することで大幅な見直しができました。しかし、同じサービスで今後さらに大きな削減をしようとしても、同じようなインパクトをもう一度出すのは難しいです。今後できることは、サーバースペックを細かく見直すことや、運用の中で不要になったリソースを整理することが中心になります。
もちろん、より安いクラウドサービスへ再度移転するという選択肢も理論上はあります。ただし、一度大きな移転を行った後に、同じ規模の削減効果を生み出すことは簡単ではありません。
また、サービス内で特定のクラウドが提供している機能を深く活用している場合、移転の難易度は大きく上がります。いわゆるベンダーロックインの状態になっていると、移転先のクラウドで同等の機能をそのまま提供できるとは限りません。その場合は、利用している機能を自分たちで開発し直すか、移転ではなく現行環境のスペック見直しで対応するしかないこともあります。
サーバーコストの見直しは、単に安いサービスを探すだけでは終わりません。サービスの構成、運用体制、移行コスト、将来の変更しやすさまで含めて考える必要があります。今回のケースでは、長く運営してきたサービスが比較的クラウドに依存しすぎていなかったこと、DBやストレージの整理が先に進んでいたことが、大きなコスト削減につながりました。
一方で、すべてのシステムをすぐに移行すべきだとは考えていません。まずは今の環境を安全に維持しながら、どこにコストや運用上の課題があるのかを整理し、そのうえで移行するべきか、現行環境を見直すべきかを判断する進め方もあります。
レガシーシステムの運用を引き継ぎながら、移行のタイミングを一緒に見極めることも可能です。こうしたシステムの運用や移行に課題をお持ちの場合は、OCI移行支援やインフラ構築・サーバー移行のページをご覧の上、お気軽にご相談ください。