LoginSignup
12
7
@Hitachi_Takumi(Takumi Misawa)

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

Last updated at Posted at 2023-12-26

はじめに

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

このような背景の中、株式会社日立製作所（以下、日立）と日本オラクル株式会社様（以下、日本オラクル様）は、Oracle Cloud Infrastructure(以下、OCI)とMicrosoft Azure（以下、Azure）を使ったマルチクラウド構成の検証を共同で実施しました。本記事では、実施した検証の中で性能に関する検証の結果について紹介します。

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

提供開始年 サービス名 特徴
2020年 Oracle Interconnect for Azure
(以下、Interconnect)		 OCIのFastConnectとAzureのExpressRouteとの相互接続サービス
2022年 Oracle Database Services for Azure
(以下、ODSA)		 Interconnectに加え、OCI上のOracle Database ServiceをAzureから構築・管理できるサービス
2023年 Oracle Database Service@Azure
(2023年12月現在、国内提供時期未定)		 Azureのリージョン内にOCIのOracle Databaseを利用できるサービス

本記事では、Oracle DatabaseとWindowsを使用した基幹システムを想定し、日本オラクル様と共同でInterconnectとODSAの性能を検証しました。
結果は以下の通りです。

  • APをAzureに、DBをOCIに配置するマルチクラウド構成において、両クラウド間は専用線での接続が必須。
  • マルチクラウド構成では業務のワークロード特性によって業務の処理時間に影響がありうる。
    • オンライントランザクション系の業務
      トランザクションを構成するSQLが比較的シンプルであり、かつ各トランザクションは並列に処理されるため、AP-DB間のネットワークレイテンシの影響が軽微となる傾向である。そのため、OCI単独と遜色ない性能となった。
    • バッチ、データ抽出系の業務
      各処理を構成するSQLがシリアルに処理されることで、AP-DB間のネットワークレイテンシが積みあがるため、データ量が増加するほど処理時間への影響が出やすい。そのため、影響を抑えるためのチューニングが必要。

InterconnectとODSAとは

InterconnectとODSAは、 OCIのFastConnectとAzureのExpressRouteによる相互接続サービスであり、
OCIとAzure間でセキュアかつ低遅延なプライベート相互接続が利用できます。また、ネットワークプロバイダとの契約、プロバイダへの費用負担なしでマルチクラウド構成を構築できます。
それぞれの特徴は以下の通りです。

  1. Interconnect
    • 相互接続に特化しており、ODSAに比べOCI、Azureのリソースを自由に設定可能
    • OCI、Azureのそれぞれのサービスを全て利用可能
    • ネットワークレイテンシを下げる(高速化)ため、FastConnectやExpressRoute、およびVMを自由に構成可能
  2. ODSA
    • 相互接続だけでなく、OCI上のOracle Database ServiceをAzureからシームレスに構築可能
    • Azureの他のサービスと同様に使用でき、Oracle DatabaseをAzure環境として使用可能

その他の違いは以下の通りです。

Interconnect ODSA
構築されるリソース OCIとAzureの相互接続ネットワーク OCIとAzureの相互接続ネットワーク、およびOracle Databaseサービス(Exadata Cloudサービス、Base Database Service、Autonomous Database、MYSQL Heatwave)
クラウド間接続サービス費用 FastConnectポート速度、ExpressRouteポート、ExpressRouteゲートウェイのコストが必要 Interconnect・ネットワークのコストは不要
転送費用 ExpressRouteの無制限データプランであればingress/egressのコストは不要 Azure VNETのローカル・ピアリングに対するegress/ingressのコストが必要
可用性 ネットワークはサービス側で冗長構成 ネットワークはサービス側で冗長構成
対応リージョン グローバルに12ののInterconnect・リージョン
日本は東京リージョンのみ		 グローバルに12ののInterconnect・リージョン
日本は東京リージョンのみ
SLA/SLO 可用性に関するSLAあり(FastConnectのSLAに準ずる) 可用性に関するSLOあり

検証構成

基幹システムを想定し、以下の構成で検証しました。
image.png

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

Azure VM OCI Compute
OS Windows Server2019 Windows Server2019
vCPU/OCPU 8 vCPU 4 OCPU
メモリ 8 GB 8 GB
Database
サービス Base Database Service
バージョン 19c最新バージョン
エディション Enterprise Edition Extreme performance
OCPU 4 OCPU
構成 RAC(Real Application Clusters)

検証項目

基幹システムを想定し、ネットワークや性能が求められる3種類の業務のワークロード特性からマルチクラウド構成、およびOCI内部でのネットワークレイテンシの影響による性能検証しました。
検証項目は以下の通りです。

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

検証結果

ネットワークレイテンシ

非マルチクラウド構成として、AP/DBの両方をOCIに配置した場合と、マルチクラウド構成としてAPをAzure、DBをOCIに配置しました。マルチクラウド構成では、InterconnectとODSAの場合の2パターンとし、合計3パターンでAP-DB間のネットワークレイテンシ(往復の通信時間)を計測しました。計測にはpingコマンドを使用しました。

コマンド例
ping 192.168.xxx.xxx
結果

OCI内部のネットワークレイテンシが0.52msに対し、Interconnect、ODSAは10ms未満でした。インターネット通信の場合、ネットワークレイテンシは50ms以上が多いことに比べ、専用線を使用したことで非常に高速となっています。

OCI内部 Interconnect ODSA
平均値[ms] 0.52 2.44 8.72

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

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

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

オンライントランザクションはその特性上、それぞれのトランザクションを構成するSQLが比較的シンプルであり、かつ各トランザクションが並列で実行されます。このため、計測結果としてInterconnect、ODSAともに秒間の実行回数が1400回程度とOCI内部と遜色ない性能となりました。また、専用線を使用したことで、一定の通信速度を維持しており、安定した性能となっています。
ただし、単一のトランザクションの処理時間はネットワークレイテンシの影響により非マルチクラウド構成に比べ遅くなります。そのため、金融取引などのように、特にリアルタイム性が求められる処理では、性能要件を満たすか十分な検証が必要です。

OCI内部 Interconnect ODSA
実行回数/秒 1460.93 1381.38 1395.13

image.png

大量データ抽出検証

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

image.png

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

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

処理時間[秒] OCI内部 Interconnect ODSA
arraysize：15
(デフォルト)		 22.31 48.91 57.88
arraysize：5000
(最大)		 18.32 29.12 29.68
参考：arraysizeの変更方法
-- Oracle Clientで実行
SQL> SET STATEMENTCACHE 5000
SQL> show ARRAYSIZE
arraysize 5000

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

バッチ処理検証

期末の会計処理、日々の携帯電話の料金集計などのような、夜間バッチを想定したワークロードです。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万回
    　②1000行まとめてUPDATEし、COMMIT実行→AP-DB間の通信1600回
    　③一括でUPDATEし、COMMIT実行→AP-DB間の通信2回
コマンド例　(パターン①)
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間の通信回数が多くなる、かつ各処理がシリアルに実行されるため、処理時間がOCI内部に比べ長くなります。一方でAP-DB間の通信回数が少ない場合は、Interconnect、ODSAともにOCI内部と遜色ない性能となっています。この結果からAP-DB間の通信回数を抑えるようにAPを改修することで、Interconnect、ODSAの処理時間の短縮が期待できます。

処理時間[秒] OCI内部 Interconnect ODSA
1行UPDATEし、COMMIT
AP-DB間の通信160万回		 3614.60 6312.93 8478.76
1000行まとめてUPDATEし、COMMIT
AP-DB間の通信1600回		 11.95 16.08 19.32
一括でUPDATE、COMMIT
AP-DB間の通信2回		 7.62 8.99 8.28

総括

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

  • APをAzureに、DBをOCIに配置するマルチクラウド構成において、両クラウド間は専用線での接続が必須。
  • マルチクラウド構成では業務のワークロード特性によって業務処理時間に影響がありうる。
    • オンライントランザクション系の業務
      各トランザクションが並列に処理されるため、AP-DB間のネットワークレイテンシの影響が軽微となる傾向である。そのため、OCI単独と遜色ない性能を計測。ただし、金融取引などのように、特にリアルタイム性が求められる処理では、低いレイテンシが重要となるため、性能要件を満たすか十分な検証が必要。
    • バッチ、データ抽出系の業務
      各処理を構成するSQLがシリアルに処理されることで、AP-DB間のネットワークレイテンシが積みあがる傾向である。そのため、性能を改善するには、AP側でAP-DB間の通信回数を抑える処理へ改修、DB側でarraysizeを大きくするといったチューニングが必要。

上記より、業務のワークロードの種類や作りによってマルチクラウド構成を使用できるか否かが変わるため、本検証のような観点を考慮し、PoCを実施いただくことをお勧めします。

また、検証結果、および各相互接続サービスの特性を踏まえ、Interconnect、ODSAのユースケースは以下のように考えられます。対象システムの要件を考慮して、構成を選択いただくことをお勧めします。

  1. Interconnect
    • ネットワークの影響を受けにくいシステムの場合は、基幹システムで利用できる
    • ネットワークプロバイダとの契約なしでシームレスにネットワークを構成でき、DB、Compute、VMなどのAzure、OCIのリソースは柔軟な設計構築が可能
  2. ODSA
    • ネットワーク性能、および構成の柔軟性がInterconnectより比較的低く、基幹システムで求められる高性能処理は不向き
    • ネットワークやDBをシームレスに構築できるため、アジャイルに利用したいデータ分析、BI用途や開発検証環境向き

あとがき

今回はInterconnectとODSAでの検証でしたが、Oracle Database Service@Azureについても国内でリリースされ次第検証予定です。お楽しみに。

参考

・ 日立製作所からのお知らせ

・ オラクル社ブログ

・ マニュアル

商標

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

12
7
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
12
7