OCLS（Oracle Cloud Lift Service)を利用して移行検討した内容を、お伝えできる範囲で提供していきます！
今回のユースケースは・・・
基幹システムのリフトにあたって、Oracle Cloud Infrastructure（OCI）のデータベースを複数パターンで検討したケースのご紹介です。
検討ポイント！！
クラウドリフトを検討しているお客様には、「スケジュールやアプリ部門との調整の難しさからなるべく変えずに単純移行をしたい」 「せっかくクラウドリフトするならアーキテクチャを刷新してクラウドのメリットを享受できるような構成にしたい」 という一見相反するような課題感を持たれている方も多いのではないでしょうか。
こちらを検討する上でのポイントは、以下のようなものがあげられると思います。
・移行する上で発生するアーキテクチャ改修等にかかる工数
・現行以上の可用性/ビジネス継続性を維持する構成が可能か
・移行/ランニングコストの比較
その中でも今回は 「移行する上で発生するアーキテクチャ改修等にかかる工数」 について重点的に取り扱います。
以下に検討した内容の詳細を記載していきます。ご一読いただければ幸いです！
1. クラウドの検討理由とOCLSの利用背景
よくある話ではあるのですが、このお客様ではオンプレミスで稼働しているシステムのハードウェアのEoLが差し迫っていて移行先を検討しなければならないという背景がありました。
また、カウンターであるお客様の インフラ部門では数年に一度発生する更改に対して大きな負荷を感じられており 、クラウド化によってそれをできる限りオフロードし、限りある社内リソースをより有効なタスクに充当したいという思いがありました。
ただし、そのために アーキテクチャを大幅に変更してしまうことはアプリケーション部門に負荷をかけてしまう という懸念もあり、どのようにクラウドリフトをするのが最適かを測りかねている状態で、その支援として OCLSのフィジビリティスタディを活用 いただきました。
2. アーキテクチャの比較検討
基幹DB移行先 IaaS vs PaaS
当初のお客様の状況では、 アプリケーション部門の稼働確保が難しいことからDBをIaaSに移す案を有力視 されていました。
一方でPaaSを選択されることで、可用性面、性能面、コスト面で様々なメリットを享受できることから我々としてはこちらを強く推奨していました。
最終的にはお客様が懸念する改修による人的コストの低減といったところもこの支援の中で説明させていただき、納得感を持ってアーキテクチャを選択いただきました。
IaaS案
データベースバージョンやOSを変更せずIaaSにデータベースを移行
IaaS案については現行のOracle Database 12cを使い続けられ、アーキテクチャの変更は最小限で済むというメリットはあります。一方で、 Real Application Cluster（RAC）が利用できない ことや定量課金のためコストの柔軟性が出ないといったデメリットが多くありました。
また、近い将来どちらにせよデータベースバージョンについてもアップグレードが必要で、解決すべき問題を後回しにするような構成となってしまいます。お客様としては アーキテクチャの変更を最小限 という箇所に重きを置かれていましたが、このあたりのデメリットについては支援を進める中で説明し、理解いただけました。
PaaS案
PaaSサービスであるExaDB-Dへデータベースを移行
PaaS案ではデータベースバージョンを最新の長期サポートリリースである19c（2023年3月現在）にする必要があり、それに伴ってクライアントの変更による改修コストは発生します。
しかし、こちらは Oracle Real Application Testing（RAT） を利用することで、移行における工数及び将来的なテスト工数を低減することが可能です。
RATは端的に言うとDB負荷や特定条件のSQL群をキャプチャし再現した上で性能比較する機能を提供するツールです。
本番機の負荷を別サーバで再現したり、システム変更時の性能影響を容易に確認することが可能です。
その他にもExaDB-Dによる可用性や性能面でのメリット（詳しくは過去のOCLSの記事「オラクルへのクラウド移行検討 第２回 −決済システムのリフト検討−」を参照してみてください）、コスト面での優位性についても支援の中で言及させていただきました。
ExaDB-Dというと高いのでは？というイメージが先行しますが実際はそのようなことはなく、特にイニシャルコストやPaaSならではのスケールの柔軟性によるコストの最適化により、IaaSと比較してもコストメリットが出るということもご理解いただきました。
3. 最後に
最終的にはこのお客様はPaaS案を選択いただきました。
理由としては、当初想定していたよりも ハイパフォーマンスかつマネージドなサービスをリーズナブルに利用可能 であること、また RATにより今回クラウドリフトにおけるDBバージョンの変更における工数を軽減でき、かつ今後のテスト工数も削減できることを評価 いただいたことになります。
冒頭でも述べた通り、このお客様は当初は移行におけるアプリ改修の工数を増やしたくないという思いからIaaS案を強く想定されていました。この状況からPaaSを選択いただけたことは 中長期で得を取ることができる 、また本移行を見ても 想定していた工数を下げることができる と判断いただけたということであり、支援した側としてもやりがいがあるものだったと感じています。
実際にPoCでのRATの評価も実施いただき、その有用性についてもご確認いただいた上で移行プロジェクトを進めていただいています。
今回紹介させていただいたような内容はクラウドリフトにおいてよくあるケースではないかと考えています。
移行プロジェクトにおいては目先のことに捉われがちで、さらにその先を見据えたアーキテクチャを検討するということは簡単なようで難しい話だと思います。
今回のようなケースで悩まれている際に参考になれば幸いです。
以上となります。