基幹システムを想定したOCIとAzureによるマルチクラウド構成を検証しました ～ Oracle Database@Azure ～ #oci

最近、ビジネス環境の変化に対応するため、異なるクラウドベンダーの多様なサービスを適切に組み合わせるマルチクラウドを検討する企業が増えています。基幹システムも例外ではなく、マルチクラウド化の検討が進んでいますが、情報系システムに比べ性能や信頼性の確保が重要です。

日本オラクル株式会社(以下、日本オラクル)と日本マイクロソフト株式会社(以下、日本マイクロソフト)はマルチクラウドへの取り組みとして両社のパートナーシップを拡大しており、Oracle Cloud Infrastructure (以下、OCI) とMicrosoft Azure(以下、Azure)の間をシームレスに連携する以下のサービスを現在まで拡充してきました。

このような背景の中、株式会社日立製作所(以下、日立)はこれまでもInterconnectやODSAの検証を通してノウハウを蓄積し、性能の検証結果を過去のQiita記事にて公開しています 。¹

今回新たに登場したOracle Database@Azureについても特性を把握すべく、日本オラクルと日本マイクロソフトの3社で連携し、OCIとAzureを使ったマルチクラウド構成の検証を以下の通り複数の観点で実施しました。

1. 性能
2. 可用性
3. 運用

これにより、お客様の要件や日本オラクルが公開しているベストプラクティスに合わせて構成を検討できるよう、日立はノウハウを蓄積しました。

検証結果は以下の通りです。

1. 性能

   • Oracle Database@Azure構成ではアプリケーション(以下、AP)とデータベース(以下、DB)が同じデータセンターにあることからInterconnectと比較して物理的距離が近いため、1ms未満のネットワークレイテンシーとなった。また、APとDBを配置する可用性ゾーン(以下、AZ)を同一にした場合、APとDBをそれぞれ異なるAZに配置した場合と比べ低いネットワークレイテンシーとなった。
   • 業務のワークロード特性ごとの処理時間に対する影響の大きさを確認できた。
     • オンライントランザクション系の業務
       トランザクションを構成するSQLが比較的シンプルであり、かつ各トランザクションは並列に処理されるため、AP-DB間のネットワークレイテンシーの影響が軽微である。
     • データ抽出系、バッチ系の業務
       各処理を構成するSQLがシリアルに処理されることで、Oracle Database@Azure構成でもAP-DB間のネットワークレイテンシーが積み重なるため、データ件数が増加するほど処理時間への影響が出やすい。そのため、影響を抑えるためのチューニングが必要である。

2. 可用性

   • 1つのリージョン内で複数のAZ、または複数のAzureリージョンでData Guardによる高可用性構成を構築可能である。
     ※国内のリージョンは2025/5時点で東日本リージョンのみ。

3. 運用

   • メトリックの管理はAzureで一貫して監視可能だが、DBの構成管理、コストの消費状況などOCIで管理が必要なため、AzureとOCI両方の理解が必要である。

InterconnectやODSAといったこれまでのマルチクラウドのサービスは、OCIのFastConnectとAzureのExpressRouteによる相互接続サービスですが、今回登場したOracle Database@AzureはMicrosoft データセンターに併置されたOCI上で稼働する Oracle Database Serviceです。
特徴は以下の通りです。

• Azure ポータルと OCI とのシームレスな連携、操作
• Azure内にOCIが配置されることで、AP と DB 間の通信がマイクロ秒単位の低遅延を実現
• Azureサービスと並行してOracleデータベースをフル機能で活用可能
• Azure Marketplaceから購入可能、請求も Azure で一元化可能
• Exadata Database Service on Dedicated Infrastructure(以下、ExaDB-D)、Autonomous Databaseが使用可能

Oracle Database＠Azureでは複数のネットワーク構成が取れます。
本記事では単一リージョンで構成できるネットワーク構成を紹介します。その他の構成含め、詳しくはマニュアルを確認ください。

ネットワーク構成例	特徴	構成図例
ローカルVNetトポロジ	・高パフォーマンスおよび低いネットワークレイテンシーが必要な場合に使用 ・シンプルなネットワーク・トポロジによってAPとDBを同じVNet上で接続 ・最も低いネットワークレイテンシー ・イングレス/エグレスのコストは発生しない
VNet ピアリング・トポロジ	・セキュリティや管理単位を分離しつつ、柔軟な接続を実現したい場合に使用 ・同じリージョン内の他のVNet上にあるAPからDBに接続 ・イングレス/エグレスのコストが発生
ハブ・スポークVNetピアリング・トポロジ	・中央のハブVNetを使用して、複数のVNetを管理し、共有サービスやセキュリティポリシーを集中管理する場合に使用 ・ハブVNetはAPとDBの間にある中間地点 ・ローカル・ルーティング・デバイス(NVA)は、委任されたサブネットからhub-and-spoke へトラフィックをルートするために必要 ・ローカルVNetトポロジに比べネットワークレイテンシーが大きい ・イングレス/エグレスのコストが発生

同じデータセンター内のサーバー間のネットワークレイテンシーは、AP-DBサーバー間の物理的距離が短く、また高速なネットワークインフラを持つため一般的には非常に低く、通常 1ms未満 です。基幹システムを想定したとき、これまでの日立の構築経験から1ms未満のネットワークレイテンシーを求められることが多いため、本検証では高パフォーマンスおよび低いネットワークレイテンシーを実現可能なローカルVNetトポロジで検証しました。

また、VNetが同じでもAZが別になることでネットワークレイテンシーの影響に違いが発生すると考え、APとDBを同一AZに配置したパターンと別のAZに配置したパターンで検証しました。

構成図は以下の通りです。

各サーバーのスペックは以下の通りです。

Azure VMのスペック

Oracle Database@Azureのスペック

基幹システムを想定し、マルチクラウド構成の採用に当たって課題となる観点を検証しました。
検証観点は以下の通りです。

以降は、性能検証にフォーカスを当てて、詳細の結果をご紹介します。

ネットワークや性能が求められる3種類の業務のワークロード特性からマルチクラウド構成のネットワークレイテンシーによる性能への影響を検証しました。

検証項目は以下の通りです。

性能検証について、結果の詳細をご紹介します。
なお、本検証結果は特定の環境・条件、及び特定のAPにて測定した結果です。
あくまでご参考値であり、環境や構成によって結果が異なる場合があります。

ネットワークレイテンシー

-- Oracle Clientで実行
SQL> SET ARRAYSIZE 5000
SQL> show ARRAYSIZE
arraysize 5000

UPDATE SOE.INVENTORIES SET QUANTITY_ON_HAND=1 WHERE WAREHOUSE_ID=1 AND PRODUCT_ID=1;
COMMIT;
UPDATE SOE.INVENTORIES SET QUANTITY_ON_HAND=2 WHERE WAREHOUSE_ID=1 AND PRODUCT_ID=2;
COMMIT;
UPDATE SOE.INVENTORIES SET QUANTITY_ON_HAND=3 WHERE WAREHOUSE_ID=1 AND PRODUCT_ID=3;
COMMIT;
-- 省略
UPDATE SOE.INVENTORIES SET QUANTITY_ON_HAND=799999 WHERE WAREHOUSE_ID=800 AND PRODUCT_ID=999;
COMMIT;
UPDATE SOE.INVENTORIES SET QUANTITY_ON_HAND=800000 WHERE WAREHOUSE_ID=800 AND PRODUCT_ID=1000;
COMMIT;