LoginSignup
7
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@Hitachi_Takumi(Takumi Misawa)in日立製作所 ミドルウェア本部

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

Last updated at Posted at 2025-05-30

はじめに

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

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

提供開始年 サービス名 特徴
2020年 Oracle Interconnect for Azure
(以下、Interconnect)		 OCIのFastConnectとAzureのExpressRouteとの相互接続サービス
2022年 Oracle Database Services for Azure
(以下、ODSA)		 Interconnectに加え、OCI上のOracle Database ServiceをAzure上で構築・管理できるサービス
2024年 Oracle Database Service@Azure Microsoft データセンターに併置されたOCI上で稼働する Oracle Database Service

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

今回新たに登場した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両方の理解が必要である。

Oracle Database@Azureとは

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

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

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

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

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

Azure VMのスペック

項目 Azure VM(Windows) Azure VM(Linux)
OS Windows Server 2022 Standard Red Hat Enterprise Linux 8.7
サイズ Standard_D4s_V3 Standard_D4s_V3
vCPU 4 vCPU 4 vCPU
メモリ 16 GB 16 GB
その他設定 高速ネットワーク有効 高速ネットワーク有効
用途 基幹システムを想定した業務のワークロードを実行 ネットワークレイテンシーを計測するツールを実行

Oracle Database@Azureのスペック

項目 スペック
サービス ExaDB-D - Quarter Rack - X9M
バージョン 23ai (23.6.0)
エディション Enterprise Edition Extreme Performance
OCPU 4 OCPU * 2ノード
構成 2ノード RAC(Real Application Clusters)

検証項目

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

検証観点 マルチクラウド採用時の課題 検証内容
性能 クラウド間の物理的距離による遅延が業務に与える影響は？ ・基幹システムを想定したワークロードの処理量、時間を測定
可用性 障害や災害発生時、即座に検知し切り替え可能か？ ・バックアップ、災対構成のベストプラクティス
運用 複数クラウドの運用知見が必要。複数クラウドのリソースを一元管理できるか？ ・監視ツール使い分けのポイント
・障害切り分け/エスカレーションルート
・利用コストの確認方法

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

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

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

検証項目 想定業務 検証内容
ネットワークレイテンシー 想定業務なし SockPerfを実行し、Azure VMとOracle Database@Azure間のネットワークレイテンシーを計測
オンライントランザクション処理のスループット 商品管理や、証券取引など、大量のユーザが同時にアクセスする業務 Swingbenchを実行し、秒間の実行回数(スループット)を計測
大量データ抽出処理時間 請求書作成、監査などのように、定期的に特定テーブルから大量のデータを一括で抽出する業務 大量の行をSELECTする処理を実行し、処理時間を計測
バッチ処理時間 期末の会計処理、日々の携帯電話の料金集計など、夜間バッチのような大量の行にアクセスし、データを更新する業務 UPDATE、COMMITを大量に繰り返す処理を実行し、処理時間を計測

検証結果

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

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

AP-DB間のネットワークレイテンシー(往復の通信時間)を計測しました。計測にはTCPのネットワークレイテンシーの”平均値”を測定するツール であるSockPerfを使用しました。

条件

30分おきに5分間SockPerfを実行し、95回(約48時間)計測

結果

マルチクラウド構成だが、APとDBがどちらもAzureデータセンター内にあるため、平均0.552msと専用線接続のInterconnectより高速だが、ネットワークリソースの距離が離れているため、OCI内部よりは遅くなりました。

測定項目 Oracle Database@Azure Interconnect OCI内部
同一AZ 別AZ
平均値[ms] 0.552 0.725 1.669 0.131

また、同一AZは別AZに比べ、物理的距離が近いことから、ネットワークレイテンシーのばらつきが少なく安定しており、約31.3%遅延が抑えられていました。

image.png

オンライントランザクション処理のスループット検証

商品管理や、証券取引などのように、大量のユーザが同時にアクセスするオンライントランザクション処理を想定しています。 Swingbenchを使用して秒間の実行回数を計測しました。

条件
  • Swingbenchのシナリオ：SOE(Simple Order Entry)
  • DBへのセッション(接続)数：20
  • Thinktime：0ms
  • 測定回数：4回
結果

オンライントランザクションはその特性上、それぞれのトランザクションを構成するSQLが比較的シンプルであり、かつ各トランザクションが並列で実行されます。このため、秒間の実行回数が同一AZでは平均2,157回、別AZの平均1,916回とそれぞれ安定しておりました。また、同一AZは別AZに比べ約11.2%の差がありますが、ネットワークレイテンシーに比べスループットは差が小さい結果となりました。

image.png

大量データ抽出検証

請求書作成、監査などのように、定期的に特定テーブルから大量のデータを抽出する処理を想定したワークロードです。大量の行をSELECTする処理を実行し、処理時間を計測しました。Oracle Databaseでは一度に取り出せる行数があらかじめ決まっており、この行数ごとにAP-DB間の通信(以下、図の赤矢印)が発生します。この行数をOracle DatabaseのパラメータであるARRAYSIZEで設定することができます。デフォルトは15行ですが、最大5,000行まで広げることができます。この値をワークロードに合わせて調整することで、AP-DB間の通信回数を減らすことができ、この結果、処理時間の短縮が期待できます。

image.png

条件
  • Swingbenchで作成した表を使用
  • 表の行数：135,000行
  • パターン：
    ①ARRAYSIZE=15(デフォルト値)
    ②ARRAYSIZE=1,000　
    ③ARRAYSIZE=5,000(最大値)
  • 測定回数：4回
コマンド例
SELECT * FROM CUSTOMERS;
結果

ARRAYSIZEがデフォルトの場合は処理時間が長くなっていますが、ARRAYSIZEを大きくし、一度に取り出せる行数を増やすことにより、AP-DB間の通信回数が減り、ネットワークレイテンシーの影響が改善しました。この結果から大量のデータ抽出処理は、ARRAYSIZEをチューニングすることで、処理時間の短縮が期待できます。

ARRAYSIZE 通信回数 処理時間[秒]
同一AZ 別AZ
15(デフォルト) 474,357 151.51 188.44
1,000 7,116 12.24 12.48
5,000(最大) 1,424 8.81 9.22
参考：arraysizeの変更方法
-- Oracle Clientで実行
SQL> SET ARRAYSIZE 5000
SQL> show ARRAYSIZE
arraysize 5000

詳細はOracle Clientのマニュアルを確認ください。

参考：プリフェッチ・サイズによるチューニング

ARRAYSIZEの拡張機能として、データベースから一度にプリフェッチするサイズをROWPREFETCH（行数）とLOBPREFETCH（LOBデータ量）で指定可能です。詳細は日本オラクルのブログを確認ください。

バッチ処理検証

期末の会計処理、日々の携帯電話の料金集計などのような、夜間バッチを想定したワークロードです。UPDATE、COMMITを大量に繰り返す処理を実行し、処理時間を計測しました。
バッチ処理は大量の行に繰り返しアクセスして処理を行い、それぞれの処理がシリアルに実行されるという特徴があります。バッチ処理は、APの作りによってAP-DB間の通信回数が異なります。例えば、同一列のデータを一括更新するようなシンプルな作りであれば、DB側で一括して更新(UPDATE)が可能なため、AP-DB間の通信は2回で済みます。一方で、APからDBへ1行だけ更新する処理を繰り返すような作りの場合、その回数だけDBからAPへ処理の結果を返すため、AP-DB間の通信が複数回発生します。このような作りになっている場合、クラウドの構成では処理時間が長くなる傾向にあります。この対策として、APの改修によりAP-DB間の通信回数を減らすことで、処理時間の短縮が期待できます。

条件
  • Swingbenchで作成した表を使用
  • 表の行数：80万行
  • パターン：
    　①1行UPDATEし、COMMITを実行→AP-DB間の通信は160万回
    　②1,000行まとめてUPDATEし、COMMITを実行→AP-DB間の通信は1,600回
    　③一括でUPDATEし、COMMIT実行→AP-DB間の通信は2回
  • 測定回数：5回
コマンド例　(パターン①)
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;
結果

AP側からUPDATEやCOMMITを実行し、その実行結果をDBからAPへ返す回数が多い場合、AP-DB間の通信回数が多くなり、またバッチ処理は各処理がシリアルに実行されるため、処理時間が長くなります。一方でAP-DB間の通信回数が少ない場合は、ネットワークレイテンシーの影響を受けにくいため、AZの配置に関わらず高速で処理されていました。この結果からAP-DB間の通信回数が多い場合は、回数を抑えるようにAPを改修することで、処理時間の短縮が期待できます。

実行パターン 通信回数 処理時間[秒]
同一AZ 別AZ
1行UPDATEし、COMMIT 1,600,000 2,804.91 3,147.57
1,000行まとめてUPDATEし、COMMIT 1,600 9.41 9.23
一括でUPDATEし、COMMIT 2 6.86 6.15

総括

基幹システムを想定したOCIとAzureによるマルチクラウド構成の性能を検証した結果は以下の通りです。

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

上記より、業務のワークロードの種類や作りによって業務の処理時間への影響度が変わるため、本記事のような観点を考慮し、PoCを実施ｓことをお勧めします。

参考

  • 日立製作所からのニュースリリース

  • マニュアル

商標、注意事項

Oracle®、Java、MySQL及びNetSuiteは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
Microsoft、Azureは、米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
その他記載の会社名、製品名は、それぞれの会社の商標もしくは登録商標です。

本資料に記載している内容については2025年5月現在のものであり、製品の改良などにより予告なく変更になることがあります。

  1. 検証結果は2023年12月に測定した値のため、本記事で検証した環境のスペック、構成に差異があります。 ↩

7
6
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
7
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?