オラクルへのクラウド移行検討　第２回　−決済システムのリフト検討−

Last updated at 2023-02-10Posted at 2023-01-19

OCLS（Oracle Cloud Lift Services)を利用して移行検討した内容を、お伝えできる範囲で提供していきます！**

今回のユースケースは・・・・

24h365dで稼働することが求められる決済システムの移行先としてOracle Cloud Infrastructure(OCI)を検討したケースです。

検討ポイント！！

高い業務継続性が求められる決済システムの検討ポイントは以下となります。

安定稼働
- 通常運用時はもちろんメンテナンス対応時にも安定稼働が必要
高い性能要件
- ピーク時の大量トランザクションに対応できる高い性能が必要
柔軟な拡張性
- 将来的なトランザクション増加に対応するため柔軟な拡張性が必要

１．移行検討の実施内容について

今回は ”移行先のサービス策定” 、”システム停止を伴わないメンテナンス実施方法”、 ”分散しているDBインスタンスの統合” の3点を実施しました。

２．クラウドの検討理由とOCLSの利用背景

そもそもなぜクラウドの検討が始まったのかという点ですが、
もともとオンプレミスで稼働していたシステムの性能限界が見えたというのが一番大きなポイントでした。

現在の構成では将来的に増大していくトランザクションに耐えられないことより、ピークタイムの瞬間風速に耐えられる基盤が必要だったということでクラウド化を検討いただいたところになります。

また、従来のHW購入型の基盤ではHWリソースの最適化が難しいという点も課題でした。
いわゆる在庫として負債化してしまうHWリソースは追加購入することで増強はできるものの過剰分を削減することが難しく、それによってシステムの柔軟性が損なわれていたということです。

今回のお客様はクラウドのノウハウが足りなかったため、ノウハウの穴埋めを目的としてOCLSのフィジビリティスタディを活用いただきました。

３．アーキテクチャの選定とシステム停止を伴わないメンテナンスの検討

①　Oracle Database実行基盤の検討

先に結論から申し上げますとOracle Databaseの実行基盤は
Exadata Database Service on Dedicated Infrastructure（ExaDB-D）を前提に検討を進めることにしました。
ExaDB-DはExadataをPaaSとして利用できるサービスです。

ExaDB-Dの特徴として

高速ストレージの利用とSmartScanを利用した従来の処理性能の向上が見込める
Oracle Databaseのための最適なHW構成が構築されているためシステムの可用性の向上も見込める
オンラインスケールアップ機能が提供されているためシステム停止を伴わずピークタイム時のトランザクションへの対応が可能
ピークタイム後のスケールダウンもオンラインで可能

などが挙げられます。
上記より 「高い性能要件」、 「柔軟な拡張性」 の2つの要件が満たせると考えます。さらにオートスケール機能によりコストの最適が可能です。

残りの 「安定稼働」 についてExadata基盤を利用することで通常稼働時の安定性に対する要件は満たせると考えますが、メンテナンス時にはどうしてもDBの再起動が必要となる場合があります。
DBの再起動が必要となる場合はシステムへの影響が避けられません。

そこでメンテナンスの影響を最小限にする方法について2つの案を検討しました。

②メンテナンス方法の検討　案1「 RACの機能を利用したローリングアップデート」

１つ目の案はRACの機能を利用したローリングアップデートでのメンテナンス方式です。
Oracle Database EnterpriseEdition Extreme Performanceの場合は
Oracle RACのサービスが利用可能です。

ExaDB-DはデフォルトでExtreme Performanceが選択されます。
RACの機能によりnode数を冗長化し、１台ずつメンテナンスを行うこと（ローリングアップデート）でシステム停止を伴わないメンテナンスを実現することが可能です。

今回は3Node RACが採用されました。
1台のメンテナンス中に、別のノードに障害が発生しても別の正常ノードが処理を継続/再開できる可用性が考慮されています。
ただしメンテナンス中はnode数が減少するため通常稼働時と比べると可用性が低下します。

②メンテナンス方法の検討　案2　ローカルスタンバイ構成によるPrimary/Standby切換え

２つ目の案はExaDB-DをPrimaryとStandbyの２台用意し１台ずつメンテナンスを行う方式です。
この場合、メンテナンス前後にDB接続の切り替えが必要となりますがメンテナンス中のnode数の減少がないため可用性を完全に担保した状態でメンテナンスが可能となります。

StabdbyDBはData Guardを同期モードで運用することで常に最新化された状態となります。
また、メンテナンス中のDataGuardレプリケーションはExaDB-DのRACの機能によりローリングアップデートが適用され稼働ノードが残りますのでメンテナンス毎レプリケーションを停止する必要はありません。

さらに、Data Guard ローリング・メンテナンスの順番と手順の確認について、既存稼働に影響がない様に最初にStandbyDBをメンテナンスし手順を確認し、その後にPrimaryDBのメンテナンスが可能となります。

上記ではメンテナンスにフォーカスしていますが、障害時にもData Guardは威力を発揮します。
Data Guardのスタンバイ構成としておくことで万が一、ActiveDBに障害が発生した場合でもStandbyDBにフェイルオーバすることで迅速な復旧が期待できます。

４．ローカルスタンバイ構成の採用

今回はより高い可用性を実現するためExaDB-Dのローカルスタンバイ構成で検討を進めることになりました。

判断ポイントは以下2点です。

RACのnode切り替えの際の継続中セッションの瞬断を防ぐ。　※１
ローリングアップデート中のnode数の減少に伴う可用性の低下を避ける　※２

注意
※１
セッションの瞬断が発生した場合の対処は様々あります。例としてApplication Continuityを利用する方法があります。アプリケーションの変更なしでトランザクションの継続性を担保します。

※２
RACのローリングアップデート中に可用性が下がるといっても3nodeRACの場合は1台が停止しても残りの2台でnodeの冗長性が担保されているので極端にRACの可用性が落ちるわけではありません。

Standby機をData Guardで同期化しておくことでメンテナンス時にPrimary、Standbyを切り替えてからメンテナンスを実施しシステム停止を伴わないかつ、可用性を担保した状態でメンテナンスが可能となります。

切換えイメージは以下の通りです。

以上で、検討ポイントとして挙げられた

安定稼働
高い性能要件
柔軟な拡張性

の3点をOCIで実現する検討が終了しました。

５．DBインスタンスの統合（副次効果）

今回ExaDB-Dを採用することによる副次効果としてマルチテナントを利用したデータベースの統合が挙げられます。
各インスタンスごとに実行基盤が分かれていると運用保守が煩雑になりますが、1つの基盤の上で複数データベースを運用することでデータベースの運用保守のシンプル化を図ることができます。

今回のケースでは「インスタンス分割」を採用しました。
各データベースインスタンスと各環境面をStandbyDBに統合した形です。

６．最後に

いかがでしたでしょうか。
今回の構成はOCIでOracle Databaseを運用する中でも上位の可用性を担保できる構成の例です。
さらに限界まで可用性を高めたい場合はMAA（Oracle Maximum Availability Architecture）よりOracle GoldenGate＋Data Guardの組み合わせで99.999％まで高めることが可能となりますので、高い可用性が求められるシステムをリフト検討する際は是非ご検討いただければと思います。

オラクルクラウドにおける可用性を担保するベストプラクティスについては以下にPDFで公開されていますので是非ご参照ください。