はじめに
Google CloudとOCIはクロスクラウド接続を行う事が可能です。
実際に接続を行った検証結果は次のリンクを確認ください。
さてここで、Google Cloudの東京リージョンは3つのゾーンから構成されるのに対し、OCIの東京リージョンは1つのAD(いわゆるゾーン)のみを持ちます。OCIとクロスクラウド接続した際にどのゾーンからクエリを実行するかによって、レイテンシに変化があるのでは？と考えて確認してみました。
ちなみにGoogle Cloudのゾーン間のレイテンシは パフォーマンスダッシュボード で確認することが可能で、次図のような状態でした。
確認環境と結果
次図のような環境において、それぞれの仮想サーバからpingでの簡易確認を実施しています。
①Google Cloud ZoneA 上の仮想サーバ(e2-medium, 2vCPU, 4GB mem)
②Google Cloud ZoneB 上の仮想サーバ(e2-medium, 2vCPU, 4GB mem)
③Google Cloud ZoneC 上の仮想サーバ(e2-medium, 2vCPU, 4GB mem)
④OCI 同一AD 上の仮想サーバ(VM.Standard.E2.1.Micro, 2vCPU, 1GB mem)
結果は次表のような形になりました(それぞれ20分程度実施)。
| min(ms) | avg(ms) | max(ms) | |
|---|---|---|---|
| ①GCP ZoneA | 1.204 | 1.307 | 2.970 |
| ②GCP ZoneB | 1.613 | 1.724 | 4.296 |
| ③GCP ZoneC | 1.151 | 1.234 | 3.896 |
| ④OCI 同一AD | 0.241 | 0.342 | 1.089 |
Google Cloud内ではZoneCにおけるレイテンシが1番短く、ZoneBが1番長い、という結果になりました。
前述のパフォーマンスダッシュボードの結果とあわせると、クロスクラウド接続はZoneCから接続されている？と推察できますね(実際にはもう少し複雑かと思われます)。
まとめ
Google CloudのZoneのID（a,b,c）は仮想的なIDとなるため、物理的なIDとは別になりますが、ゾーンによってレイテンシが変わることを確認できました。東京リージョンではレイテンシに大きく変化はないため、どのゾーンでも気にする必要はないかもしれませんが、性能テストなどを行うときは考慮しておいた方が良いかもしれません。
さて、先日GAされた Oracle Database@Google Cloudでは、Google Cloudのそれぞれのゾーンに対応したADが割り当てられるようになると想定されます(次図はOracle Database@Azureの例)。こちらは仮想サーバとデータベースがより近接で動作させることができると想定されますが、複数ゾーンを利用する場合にはいろいろと考慮が必要になりそうです。
また、OCIのADが一つしかない東京では1つのゾーンでのみ利用できるのか、それとも、全てのゾーンで利用できるように実装されるのか、リリースが待たれますね。
（引用：First principles(第1原則): Oracle Database@Azureでミッション・クリティカルなアプリケーションを強化）