クラウド最適化の一手：ISV SaaSアプリをAWSからOCIに移行してコストを半分に削減

Last updated at 2025-09-17Posted at 2025-09-16

概要

AWSで稼働しているISV SaaS提供モデルをOracle Cloud Infrastructure(OCI)に移行して、クラウドの月額コストを約50％削減することに成功しました。

背景

円安によるクラウド費用の上昇やインフレの影響を背景にシステム構成の再検討が必要となりました
一方で、ISV ユーザー向けの提供環境はマルチテナントでのベストエフォートパフォーマンスではなく、コンピュートリソースを確保することを条件に提供しているシングルテナントのため、集約は困難でありユーザー数の増加に比例してコストも上昇します

	マルチテナント	シングルテナント
形態	1システムに複数ユーザーが利用	ユーザー毎に環境を準備
パフォーマンス	ベストエフォートセッション数制限等ある程度制限の余地はあり	リソース保証コンピュートリソース専有
ノイジーネイバーの影響	あり	なし
ユーザー環境毎のカスタマイズ	難	可能
費用	ユーザー数に比例しない集約効果期待	ユーザー数に比例

今回、既存の構成要件を維持したまま、他クラウドへの移行によってコスト最適化が図れるかを検討する方針としました。

移行前の構成

移行前の構成は以下のとおりです
ユーザー毎に環境を提供。これらを管理するセグメントを作成して監視サーバーや運用管理サーバーを設置しユーザー環境を管理しています

ユーザー用セグメント
ユーザー毎にVPCを区切り以下の構成を作成しています
- APサーバー: EC2
- MySQL DB: RDS for MySQL
- TLS終端: Network Load Balancer
システム管理セグメント
　ユーザー用セグメントを管理するためのシステム管理用にVPCを作成します
- 運用管理サーバー: EC2
- VPC間接続: VPC Peering
- Operatorからの接続: Site to Site VPN
画像などのユーザーデータやシステム管理のログ等保管
- Object Storage: S3
その他
- TLS証明書管理: AWS Certificate Manager
- DNS: Route53

クラウド費用比較

現状の費用と他社クラウドの費用を比較しました。
見積前提は以下の通りです。

ガバメントクラウドに認定されている
現在の構成と同等のサービスが提供されている
- VM
- DBaaS MySQL
- Load BalancerによるTLSオフロード
- VPC peeringやDNS等のNetworkサービス
可能であればリザーブドインスタンス1年を利用する
50ユーザーセグメント
クラウドサポート費用は試算対象外

試算にあたっては以下公式サイトから算出しています

AWS:AWS Pricing Calculator
https://calculator.aws/

Azure:料金計算ツール
https://azure.microsoft.com/ja-jp/pricing/calculator/

Google Cloud:Google Cloud Pricing Calculator
https://cloud.google.com/products/calculator?hl=ja

OCI: Cloud Cost Estimator
https://www.oracle.com/jp/cloud/costestimator.html

AWS費用合計を100とした時の各クラウド費用の比較は以下のような試算となりました

	AWS	Azure	Google Cloud	OCI
費用比較	100	72	83	48

さらにサービス毎のコスト比率を分析するため明細を算出しました
こちらもAWS費用合計を100として割合を算出しています

	AWS	Azure	Google Cloud	OCI
IaaS	25	19	22	12
DBaaS	56	39	50	33
Object Storage	1	1	1	1
Network	19	13	10	3
Total	100	72	83	48

IaaSおよびDBaaSについてはOCIが半額程度となりました
Object Storageについてはほぼ変わりありません
NetworkについてはOCIはかなり費用を抑えることができます
　こちらについては多くのサービスが無償または低価格であることが理由となっています

移行のための一時費用を捻出することや長期に渡って費用効果を出すことを考慮して、一番コストが抑えられるOCIを選択しました

移行後の構成

OCI移行後の構成は以下のとおりです。

ユーザー用セグメント
ユーザー毎にVPCを区切り以下の構成を作成しています
- APサーバー: Compute
- MySQL DB: MySQL HeatWave
- TLS終端: Flexible Load Balancer
システム管理セグメント
　ユーザー用セグメントを管理します
- 運用管理サーバー: Compute
- VPC間接続: DRG
- Operatorからの接続: Site to Site VPN
画像などのユーザーデータやシステム管理のログ等保管
- Object Storage: Object Storage
その他
- TLS証明書管理: Certificates
  - ただしTLS証明書の自動更新機能がないため一部手組
- DNS: DNS

移行手順

以下の手順に沿って、移行作業を実施しました

稼働検証

想定したOCIのサービスで現行構成が稼働するか基本的な検証項目を確認します
検証にあたっては以下のようなFree Tierの利用も可能です

機能の検証：動作検証
非機能テスト：レスポンス性能、同時接続、スループットなど
想定以内のコストになるか確認

待ち受け環境構築

移行するための待ち受け環境を構築します

運用管理セグメント構築
移行検証用ユーザーセグメント構築
運用の検証
- 監視・ログ取得
- バックアップ・リストア：障害時の復旧手順
AWS～OCI間VPN接続
- 公式資料AWSへのVPN接続を参考にAWSおよびOCIのVPNサービスを使用してAWS～OCI間VPN接続を行いました
- 移行時間を見積るためVPNのパフォーマンスを計測しています
  [Pingによるレイテンシー計測]

$ ping <oci ip address>
PING <oci ip address> (<oci ip address>) 56(84) bytes of data.
64 bytes from <oci ip address>: icmp_seq=1 ttl=61 time=4.45 ms
64 bytes from <oci ip address>: icmp_seq=2 ttl=61 time=4.04 ms
64 bytes from <oci ip address>: icmp_seq=3 ttl=61 time=3.99 ms
64 bytes from <oci ip address>: icmp_seq=4 ttl=61 time=3.85 ms
64 bytes from <oci ip address>: icmp_seq=5 ttl=61 time=4.07 ms
64 bytes from <oci ip address>: icmp_seq=6 ttl=61 time=3.94 ms
64 bytes from <oci ip address>: icmp_seq=7 ttl=61 time=3.88 ms
64 bytes from <oci ip address>: icmp_seq=8 ttl=61 time=3.94 ms
64 bytes from <oci ip address>: icmp_seq=9 ttl=61 time=3.86 ms
64 bytes from <oci ip address>: icmp_seq=10 ttl=61 time=3.97 ms
64 bytes from <oci ip address>: icmp_seq=11 ttl=61 time=3.90 ms
64 bytes from <oci ip address>: icmp_seq=12 ttl=61 time=3.92 ms
64 bytes from <oci ip address>: icmp_seq=13 ttl=61 time=3.91 ms
64 bytes from <oci ip address>: icmp_seq=14 ttl=61 time=3.94 ms
64 bytes from <oci ip address>: icmp_seq=15 ttl=61 time=3.99 ms
64 bytes from <oci ip address>: icmp_seq=16 ttl=61 time=3.97 ms
64 bytes from <oci ip address>: icmp_seq=17 ttl=61 time=4.01 ms
64 bytes from <oci ip address>: icmp_seq=18 ttl=61 time=3.87 ms
64 bytes from <oci ip address>: icmp_seq=19 ttl=61 time=4.03 ms
64 bytes from <oci ip address>: icmp_seq=20 ttl=61 time=3.99 ms
:

[SCPによる転送パフォーマンス計測]

SCP 1GB AWS->OCI	1回目	2回目
1重	63.6MB/s	60.9MB/s
2重 Session1 2重 Session2	33.6MB/s 32.9MB/s	39.0MB/s 33.7MB/s
3重 Session1 3重 Session2 3重 Session3	21.9MB/s 24.9MB/s 28.6MB/s	24.9MB/s 28.3MB/s 24.5MB/s

データ移行

基本的に以下のツールを使用してVPN経由でデータ移行を行います

VM Disk
NFS mountを使用してユーザー領域のファイルをコピー
MySQL
mysqldumpを使用したExport/Import
S3
rcloneを使用してAWS S3からOCI Object Storageにコピー

データ移行についてはかなりのOutbound費用がかかるものと予想されます
その場合は以下の手続きも紹介されています

切替

概ね以下の手順でDNSレコードを変更することにより切替を順次行います

Route53 DNS レコードTTLを60秒に変更
データ移行完了確認
Route53 DNS レコード変更しOCIに向ける
切替を確認
Route53 DNS レコードTTLを元の時間に変更

移行後の対応

DNSのAWS Route53からOCI DNSへの移行を検討しましたが、他の利用の都合によりRoute53を継続利用することにしました。現状でもOCI上で問題なく稼働しており、Route53の費用も全体から見れば少額であるため、DNSは将来的に最も適したサービスへ移行する方針としています。

切り替え結果

システム要件は変えずにクラウドにかかる月額費用を約半分へ圧縮することができました
AWSからOCIに切り替えてみて得られたメリットや苦労した点について挙げてみます

切り替えたメリット

Compute flexible shape
OCIのComputeでは、CPU（OCPU：1 OCPU = 2 vCPU）とメモリを柔軟に調整できるため、必要に応じて細かくリソースを最適化できます。エンドユーザー向けのサービスプランは松竹梅のようなメニュー化をしているため大きな変更は不要ですが、メモリだけを少量追加したい場合などに、低コストで対応できる点は非常に便利です。

Compute ライブ・マイグレーション
Computeにはライブ・マイグレーション機能があるため、ホスト変更のための再起動作業が大幅に減るものと期待しています

OCIのライブ・マイグレーションでVMワークロードの可用性を向上

低コスト
コンピュートリソースのコストを抑える手段として、Reserved Instance や Savings Plan の活用が一般的ですが、パフォーマンステストを行ったとしてもサービス前の正確なキャパシティプラン（CPUやメモリの見積）を行うのは容易ではありません。安全率を加味して見積もることも多く、結果として過剰なスペックでRIを購入してしまう可能性も否定できません。一方、OCIではRIの概念がなく、もともと価格が安価なうえリソースが不足した場合でも後から柔軟に追加できるため、設計担当者の負担が軽減されます。
さらに、ネットワーク関連サービスの多くが無料で提供されている点も魅力です。たとえば以下のようなサービスが無償で利用可能です：
　* NAT Gateway
　* Public IP Address
　* Dynamic Routing Gateway（DRG）
　* Site-to-site VPN
加えて、Outbound通信は月間10TBまで無料となっており、コスト面での制約が少ないため自由度の高い設計が可能です。これらの要素が、OCI上で設計する上での安心感につながっているのではないかと思います。

苦労した点

TLS証明書の自動更新がない
OCIは認証局がないのでAWS ACMのようなTLS証明書の自動更新機能が備わっていません。そのため、TLS証明書は外部で取得しOCIのCertificateに都度手動で設定する必要があります。
工数を削減する手段としては複数のロードバランサーから1つのCertificateを参照できるため、たとえばワイルドカード証明書（例:*.example.com）を1か所に登録すれば、すべてのロードバランサーに反映可能です。
とはいえ、3ヶ月ごとの手動更新は地味に手間がかかるため、Let's Encryptから定期的に証明書を取得し、OCI Certificateに自動登録する仕組みを構築しました。

ユーザーデータ内のS3 URIの置き換え
ユーザーデータの一部にS3 URIが含まれていたため、移行時にはURIの置き換えや、URIからファイル名のみを抽出するなどの対応が必要でした。
クラウド利用においては、ベンダーロックインを避けるためにクラウド固有情報を極力排除するか、逆にそのメリットを積極的に活用するかの判断が求められます。今後はそのバランスを見極めながら対応が必要と感じます。
技術情報が少ない
OCIはAWSと比較すると、ユーザー発信の技術情報（「〇〇をやってみた」系の記事など）が少ない印象を受けました。検索しても情報にたどり着けない場面では、生成AIに質問することで非常に精度の高い回答が得られました。実際にその内容を試しながら移行を進めた結果、工数を抑えつつスムーズに対応できました。ネット上にはOCIに関する技術情報が着実に蓄積されており、生成AIの活用によって、より自由度の高いクラウドジャーニーが可能になったと実感しています。

まとめ

OCIへの移行により、システム要件を維持したままクラウド費用を約半分へ削減することに成功しました。柔軟なリソース調整や無償または低価格のネットワークサービスにより、設計の自由度と運用効率が大きく向上しています。一部の技術的対応は必要でしたが、それ以上に得られたメリットは大きく、今後の拡張や構成の進化にも前向きに取り組めると思います。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up