ガバクラ推奨構成出てきたのでOCI編を見てみたのと疑問点を整理してみた。
台頭するOCIの対応
ガバメントクラウドとしてOCIを採択する団体も増えてきており、AWSとの違いやOCIへの興味を持つ方も増えてきているのではと思います。とはいえまだまだOCIを採択する自治体はAWSに比べると少なく、ガバメントクラウドとしてのOCIに関する情報も少ないのが実情。先日共闘PF内でOCIに関する議論がなされたため、せっかくなのでここに内容をまとめようと思います。
本記事は「こういう理解だ」「こうあるべき」という押しつけがましいものではなく、簡単なまとめです。OCI採用ベンダも増えてきて、今後あるいは将来的にOCI側もマルチベンダになる可能性が十分あると思います。現時点で考慮しておきたいことや、OCIに興味を持った方、OCIを扱う方にとって少しでも参考になる情報となれば幸いです。
なお、国・デジタル庁やCSPからお墨付きをもらっているものではないため、あくまで参考情報としていただければと思います。また、疑問点を中心に、パブリックコメントのように有識者の皆様のご意見もいただけたらと思います。
１．OCIの基礎・概念
神記事がありました。感謝！！
最低限押さえておきたいこと①：用語の整理
まずはAWSの用語とOCIの用語の違いを確認しましょう。
最低限押さえておきたいこと②：OCI独自の概念「コンパートメント」
こちらの記事が分かりやすかったです。
２．ガバクラ推奨構成で示された「OCI推奨構成」
①推奨構成の公開
デジタル庁のHPに公開されました。（2024年5月22日）基本的な部分をさらっと見ていきたいと思います。
②推奨構成の概要を確認
資料「ガバメントクラウド推奨構成（OCI）」（以下「推奨構成」）のP13「本資料が推奨とするシステム構成の概要」を踏まえ、２つの点を別途考慮する必要があると考えました。
LGCS利用前提であること：回線を独自調達する場合は別途考慮が必要。
アプリケーション分離前提であること：異なる分離方法の場合は別途考慮が必要。
③共同利用方式における団体間の分離方法
資料「ガバメントクラウド推奨構成（OCI）」P47「共同利用方法における団体間の分離方法」を踏まえ、以下の点を留意する必要があります。また旧版と、今回公開された新版で異なる用語があるので、留意する必要があります。
AWSでいうアカウント分離相当が「コンパートメント分離」：推奨構成ではテナンシは1つのみの払い出しが前提となっている。
３．マルチベンダの場合はどのような形が望ましいのか
①ガバメントクラウド運用管理補助者兼ASPの場合
推奨構成では以下に示されています。
ポイントは以下の２点あります。
NW管理用のテナンシが別途払い出されている。
分離方法に合わせてNW管理をどこで行うかは検討すべきとされている。
②ガバメントクラウド運用管理補助者及びASPの場合
推奨構成では以下に示されており、ポイントは運用管理補助者テナンシ内にNW管理機能も持たせている点です。
③マルチCSPの場合はどのような形が望ましいのか（推奨構成）
推奨構成では以下に示されています。
ポイントは以下の２点あります。
閉域NW内の「相互接続ルーター」で折り返す通信となっている。
(*2)としてガバクラ内部でのCSP間通信NWは令和6年度に提供開始予定とある。
４．推奨構成を踏まえたマルチCSP構成案
共闘PFでの議論を整理しました。推奨構成はアプリケーション分離が前提となっていますが、実際はコンパートメント分離が主流だと思いますので、以降の資料はコンパートメント分離前提の図となっています。AWSとOCIのマルチクラウドとして例示します。
パターン１：NW管理テナンシを個別調達するケース・NW運用管理補助者を個別調達する場合（NWを単独管理する場合）
NW運用管理補助者とASPが異なる場合は、NW管理を行うテナンシを最前線に配置します。ASPテナンシ内にNW管理コンパートメントを払い出してもらってもよいのですが、管理と責任分界点の観点から、テナンシ自体で分離させた方が無難だと思います。
ベンダのデータセンターに回線を集約してガバクラ接続回線を共同利用するような場合では、NW管理テナンシも共同利用方式（NW運用管理補助者の管理）となります。
コンパートメント分離はAWSでいうアカウント分離に相当するものであり、コンパートメント単位での請求額の把握や自治体への請求が可能と思われます。
パターン２：ASPがNW管理を兼ねるケース
NW管理テナンシは不要となり、NW管理するASPテナンシ内にFastConnectが接続します。
NW運用管理補助者とASPが同一である場合、そのASPテナンシ内にNW管理コンパートメントを作成することでNW管理を切り離して管理できます。FastConnectを受けるDRGは例図だとC社のDRGが受け、D社テナンシにはDRG間の接続を行います。地場ベンダがNW管理とASPを兼ねる場合など、このような構成が一例として考えられます。
パターン３：FastConnectをテナンシ単位で契約するケース
OCI共同利用方式を採択するいずれのASPもNW運用管理補助者を担務できない場合は、各テナンシにFastConnectを引き込むこともできます。
ただし、コストが高額になるため、基本的にはパターン１か２のどちらかになると思います。NW運用管理補助者を調達できない場合は、パターン１のように自治体が単独利用方式で管理を行うのが一般的かと思います。
この場合は、庁舎内と各ASPガバクラ内のCIDR設計・調整をだれが行うかなどの課題も発生します。
各パターンに対する注意点
一般的にコンパートメント単位で請求額の把握はできます。ガバクラにおいてもコンパートメント分離方式が最上位の分離方式となっているため、コンパートメント単位での請求は可能の認識ですが、詳細はデジタル庁様へご確認ください。
Local Peering GatewayではなくDRGにてピアリング接続することもできます。但しその場合は、VCNにアタッチできるDRGは1つのみのため、事業者拠点接続用のFastConnectの接続先は検討が必要です。
５．ガバクラにおけるOCIの疑問あれこれ
共闘PFで話題になったものなどをいくつか紹介します。一意見、参考情報があれば、ぜひご意見をいただければ幸いです
疑問①：OCI内がマルチベンダの場合のベストプラクティスは？（DRGの使い方など）
まずNW管理をASPが兼ねるかどうかで、NW管理テナンシが必要かどうかを判断します。
NW管理テナンシが必要な場合は、FastConnectはそこにあるDRGに接続する。各ASPテナンシへの接続は、ASPテナンシ内のDRGに対して接続します。（例示のパターン１）
NW管理テナンシが不要な場合（ASPがNW管理を兼ねる場合）は、そのASP内にNW管理用コンパートメントを作成し、そこのDRGに対してFastConnectを接続する。他社ASPへの接続は、ASPテナンシ内のDRGに対して接続します。（例示のパターン２）
また、複数テナンシ間の接続時に各テナンシにDRGを用意する必要があるかどうかについては、基本的には各テナンシにDRGを用意したほうが良いとされています。これは「VCNには2つ以上のDRGをアタッチ出来ない」というOCI上の制約が一因です。例えば、NW管理テナンシXのみにDRGを作成し、ASPテナンシY上のVCNaへクロステナンシVCN接続を行った場合、VCN aはX上にあるDRGと接続されている状態となります。もしY上の別のVCN bと接続を行いたい場合、すでにVCN aにはX上のDRGが接続されているため、VCN bへの接続を担うDRGを追加できません。このような状況を起こさないため、各テナンシ内にDRGを持つ構成を推奨されています。
疑問②：共同利用方式における団体間の分離方式をどのように実現するか
推奨構成ではコンパートメントによる分離が最上位の分離方式として定義されています。これはAWSでいうアカウント分離に相当します。一方で前述の通りにマルチベンダになった際など、同一テナントに同居しない方がよいとされるケースもあります。実際に推奨構成でもマルチベンダの項目で、ベンダごとにテナンシを払い出している図が示されています。よって、状況に応じて「コンパートメントレベルでの分離」か「テナンシレベルでの分離」かを判断することになると思われます。
疑問③：AWSのようにNWアカウントは必要なのか
状況によると考えます。OCIはコンパートメントという概念とDRGの機能によって、AWSのようにNWアカウントを切り出すことなくNW管理を実現できます。コンパートメントで論理的に区切ることで仮想アカウント分離のように環境を分離できます。DRGは、AWSのDXGWとTGWを合わせたような機能であり、FastConnectの接続と各VCNの接続を集約でき、さらにルータとして経路の振り分けも行えます。このような理由でいわゆるNWアカウントは不要となるが、NW運用管理をASPが行うのかどうかなどによって検討する必要があります。
なお推奨構成では、以下のとおり自団体向けのNW管理コンパートメントをASP内に作成することも示されています。
まとめ
今回は、先日公開されたガバクラ推奨構成（OCI編）をもとに、共闘PFで話題になった部分をまとめてみました。
推奨構成にも記載されていますが、推奨構成自体が「必ずしも全ての地方公共団体に適した構成とは限らない（P12）」ものであり、結局は個別具体の状況に応じて適切なアーキテクチャを検討・判断していくことが重要と思います。冒頭にも書きましたが、この記事の内容が絶対的に正しいものではありません。気になる点やご助言などありましたらぜひご指摘ください。
このプロジェクトを戦う戦友として、一緒に乗り越えていきましょう。
この記事が気に入ったらサポートをしてみませんか？