記事をご覧頂きありがとうございます！BBSakura Networks株式会社（以降BBSakura）にてOCXサービスのクラウド直接接続まわりを担当してる丸野です。
この記事は、OCXを支える技術の連載記事です。連載記事一覧は、この記事についているタグ #OCXを支える技術 からご覧いただけます。
概略
BBSakuraでは、BBIXがサービス提供を行っているOpen Connectivity eXchange(以下、OCX)のソフトウェア開発を行っています。その中でもクラウド事業者と直接接続する機能をOCXでは"Cloud Connection"と呼んでおります。
今回の記事では、クラウド接続プロバイダとして"Cloud Connection"を提供するまでに、どんなことを考えていて、どんな技術を用いているかを見ていきたいと思います。
Cloud Connection
本編に入る前に少し"Cloud Connection"のことを説明します。
"Cloud Connection"は、各クラウドサービスへ接続するための仮想的な接続インターフェースとなります。 OCXマネージメントポータルの"Cloud Connection"を利用してOCXネットワークを経由した各クラウドへの接続設定を行うことができます。
"Cloud Connection"にて現在接続できるクラウド事業者とそれぞれの直接接続サービスは以下のとおりです。（2023年11月現在）
| クラウド事業者名 | 直接接続サービス名 |
|---|---|
| Amazon Web Service（AWS) | Direct Connect (Hosted Connection) |
| Microsoft Azure (Azure) | Express Route |
| Google Cloud | Inter Connect (Partner Interconnect) |
| さくらのクラウド | プライベートリンク |
| Oracle Cloud | Fast Connect |
目次
考える3要素
クラウドとの接続性を作り上げるには、主に3要素の考慮が必要になると思ってます。
- 物理回線の構築＆運用
- お客様論理回線の接続仕様を把握
- クラウド側リソースとの連携
それぞれ深掘りしていきたいと思います。
物理回線の構築＆運用
一言でいうと「お客様論理回線を収容するための物理線を用意する」だけなんですが、そのためには計画的な構築＆運用が不可欠になります。 なぜなら物理レイヤーは「ほしいと思ってもすぐに用意できるわけではない」ため、予め想定できる限りの考慮点を洗い出し、設計しておくに越したことはないからです。 ざっくり以下のようなことを考えながら物理回線の構築＆運用を行っています。
- 物理回線の調達、収容設計、増強計画
- 収容設計
- 物理回線上の帯域をどうするか
- 10G or 100Gの選択、共通基盤としてのLAGの有無
- 顧客論理回線の収容拡張性の余白をどこまで考えるか
- オーバーサブスクリプションの許容率
- 物理回線上の帯域をどうするか
- クラウド側直接接続仕様の考慮
- クラウド側POPの、各ロケーションに対してどうやって繋ぐか
- 同じデータセンターにそもそも設備を持ってる？ラック間構内配線で接続可能？など
- 相互接続の上限について
- ロケーション毎に相互接続できる物理回線に上限がある
- 一例：東京のとあるロケーションにおいて、該当クラウドと接続できる物理回線はxx本まで
- 上限緩和をするためには、特定の条件をクリアする必要がある
- 一例：該当クラウドについて、全体の物理帯域に対して月平均xx%を超える通信量が必要
- ロケーション毎に相互接続できる物理回線に上限がある
- クラウド側POPの、各ロケーションに対してどうやって繋ぐか
- 収容設計
こういった考慮点が 「各クラウド毎に異なる形で存在」します。そのため、情報の整理は非常に重要ですし、日々のリソース状況を監視する必要もあります。
また、ガチガチに設計してしまうと、クラウド側の仕様変更時に動けなくなります。 この辺の塩梅も日々苦労しております。
お客様論理回線の接続仕様を把握
現在のクラウド直接接続の多くは IEEE802.1Q（通称：VLAN または dot1qなど）での接続がほとんどです。 ですので、VLANを用いたL2通信に関わったことのある方はイメージしやすいと思います。クラウドとの接続としてやっていることは意外とシンプルです。
この部分について、もう少し深掘りしたいと思います。 説明のために、"Cloud Connection"にてクラウド接続を行い、その通信をお客様設備（CPE）までL2通信する際の簡単な図を書いてみました。
※以降の通信まわりの技術名称は、筆者が呼び慣れてる通称の呼び方で説明します。
dot1qの対応
"Cloud Connection"の作成を実施すると、指定されたクラウドと接続している拠点のNW設備にてdot1qの設定が行われます。これにより、クラウド設備と弊社設備の間でL2通信ができるようになります。 この際設定する対象となる物理回線は、事前調達し物理結線済みの回線に設定を行います。（ネットワークサービスを提供するために事前調達し準備してる回線のことを、NNI (Network to Network Interface) と呼んでおります。） 設定していることは主に以下のとおりです。
- dot1qのVLAN ID許可設定
- "Cloud Connection"購入時に指定した契約帯域に合わせた帯域制御設定
以上のようなことを裏で行うことで、クラウド側との通信到達性を構築します。 その後は、構築した通信路をOCXネットワークを通してお客様設備（CPE）まで送り届けるだけです。
<<ちょっと脱線！>>
ちなみに、OCXネットワーク内で扱う際のVLAN IDは、OCXシステム管理の別VLAN IDに変換をしております。これを行う事によって、各クラウドとのVLAN-ID選択方法に柔軟性を保たせつつ、"Cloud Connection"通信を論理的に分離＆管理する仕組みを実現してます。
送り届けるまでの概要は以下のとおりです。
- 拠点にて物理回線を提供する "Physical Port" を購入してもらい、構内配線を手配しお客様設備（CPE）と物理接続
- 接続した物理回線上で利用するインターフェースを決める"VCI"の作成
- 離れた拠点にあるL2ネットワーク同士を結ぶ"VC"の作成＆アタッチ
これにより、お客様設備（CPE）とクラウド設備がL2通信できるようになります。削除の際は、この逆の順序で動くようOCXシステムを作り上げる、というイメージです。
なお"Physical Port", "VCI", "VC"まわりについては、ユースケースを用いたリソース解説として弊社メンバーがまとめてくれています。よかったら是非見てください！
Azure QinQへの対応
なお現状1クラウドだけ唯一他クラウドと違う仕様があり、AzureのみIEEE802.1Qトンネリング（通称：ダブルタグVLAN または QinQなど）での接続仕様となっています。これによりAzureは上記図とは異なる通信になります。
"Cloud Connection"ではここの違いをシンプルにすべく、Azureとの接続については シングルタグ化オプション を実装しました。
この実装については、以前社外勉強会を行った際に詳しく説明してますので、よかったら是非見てください！
クラウド側リソースとの連携
お客様論理回線の接続仕様について大まかに説明をしましたが、対応が必要なのはOCX側設備だけではありません。クラウド側のリソースの作成や削除もOCXシステムから連携し対応する必要があります。
クラウド側リソースへの連携を理解するには、以下の2つの違いについて明確に理解する必要があります。
- クライアントが所有するクラウドアカウントを経由したAPI/SDK実行
- プロバイダが所有するクラウドアカウントを経由したAPI/SDK実行
クラウド側リソースへの連携の考え方
1つ例を交えて説明します。 あなたは自分のクラウドアカウントに対して外部環境から自動化を検討する際、以下のようなことを検討すると思います。
- 自動化しようと思っているコンポーネントにて用意されているクラウド側API/SDKの選定と仕様の把握
- 選定したAPI/SDKに対して外部環境から操作できるようにするために、アクセス権限の把握＆付与
- アクセス権限を利用するためのアクセストークンの発行方法を調べ、それに従い外部環境からアクセストークン発行のプログラムを構築
こういったことを検討し、準備することで外部環境からクラウド側API/SDKを操作する仕組みを作ることができます。 図にしてみるとこのような感じ。
では似たようなことをプロバイダの立場で、不特定多数のクライアントに対して行う場合を考えてみましょう。
この場合、困難なのはアクセス権限の付与、およびアクセストークンの発行になります。
クライアントのクラウドアカウント上に、プロバイダが操作できるようアクセス権限付与＆アクセストークンの発行してもらうのもありかもしれませんが、管理や作業の手間を考えるとクライアントにもプロバイダにも負荷が高く現実的ではありません。 図にしてみるとこのような感じ。
そういった問題を解決するために、各クラウドには「プロバイダのクラウドアカウント上で直接接続をある程度制御できる、プロバイダ向けAPI/SDK」を用意してくれてます。 プロバイダ向けAPI/SDKに、お客様リソースを判断できるパラメータ(AWSアカウントID, サービスキー, ペアリングキー etc...)を渡すことで、プロバイダ環境から一元的に各お客様に対して制御ができるようになります。 図にしてみるとこのような感じ。
プロバイダとクライアント間の承認の仕組み
ここで1つの疑問が出てきます。それは「プロバイダであればクライアントに対して問答無用にリソース作成や削除ができてしまうのか」ということです。 結論を先にいうと「No」になります。 この辺はちゃんとできていて、以下2つのどちらかの仕組みにて問題を解決しています。
- 事前にお客様にて必要作業を行った際にランダムな文字列で発行されるキー(サービスキー, ペアリングキー)を用いて、その文字列を知っているプロバイダであれば特定の操作ができる
- キーの情報共有そのものを承認行為とするイメージ
- プロバイダがクライアントのクラウドアカウントに対して操作を行った際、クライアント側で承認プロセスを実行してもらう
- 承認プロセスがクラウド上の仕組みとして存在するイメージ
このような仕組みにより、プロバイダ、クライアント、それぞれの立場で安全に連携することが可能となるわけです。
なお、クラウド側リソースとの連携についても当然、各クラウド毎に仕様が大きく異なります。 プロバイダ専用のクラウドアカウントの管理も必要になりますので、各クラウドに関する広い知識が必要になってきます。
まとめ
総じて重要なことは、 「お客様が使いたいときに使えるよう色んなことを先回りをして、難しいことをシンプルな形で提供する」ということに尽きる思います。 そのためには、ネットワークの基礎＋上記で説明したような内容を各クラウド毎に理解する必要があります。
またサービスとして提供するためには、これらの理解だけでは足りません。その先のクラウド側ネットワーク（VPC/VNetなど）やオンプレミス側ネットワークを理解し、提供するサービスがどんな使われ方をするのかを把握しておく必要があります。
サービスを作っている立場として、OCXの"Cloud Connection"は以下のような機能としてシンプルで使いやすいものにしたいと思ってます。
- クラウドへの直接接続が、ほしいときに、簡単に使えるサービスへ
- イメージしやすい（非冗長なら"Cloud Connection"が1つ、冗長なら"Cloud Connection"が2つ）
- 計算しやすい (OCXはトラフィック課金がない、初期費/月額費が固定で計算しやすい、日割り計算も適応)
- 作成しやすい、削除しやすい
やらなければいけないことは沢山ありますが、日々できる限りのことを続けていき、より良い改善をしていきたいと思っています！
本記事について、いざ書き出すと内容がどんどん膨れ上がってしまい、長文になってしまいました、、、、 最後まで読んでいただきありがとうございました！
