BBSakura Networks Advent Calendar 2024 の10日目の投稿です。

記事をご覧頂きありがとうございます！

BBSakura Networks株式会社（以降BBSakura）にてOCXサービスのクラウド直接接続まわりを担当してる丸野です。

概略

BBSakuraでは、BBIXがサービス提供を行っているOpen Connectivity eXchange(以下、OCX)のソフトウェア開発を行っています。その中でもクラウド事業者と直接接続する機能をOCXでは"Cloud Connection"と呼んでおります。

今年の2024/02/09にOCX利用者向けに、

「Cloud Connectionにおいて、接続先ロケーションの表現を変更しました。また、一部の相互接続情報からPrimary/Secondaryの表現を廃止しました。」

というアップデートを実施しました。これは、その後新たに展開する”大阪ロケーション経由でのクラウド接続”を利用いただくための１つの準備ではありましたが、使い勝手の向上を狙った大きな変更でした。

変更箇所は複数あるのですが、今回は「Cloud NNI PoP名というパラメータに表記変更をしたこと」について深堀りしたいと思います。

概略
深堀り箇所のビフォーアフター
- リソース作成画面
- リソース一覧画面
大きく変更した背景
実装その1、リソース作成画面の項目名について
- リソース作成画面にて項目名を、「Cloud NNI名」から「Cloud NNI PoP名」という名前に変更
実装その2、パラメータについて
実装その3、リソース一覧画面の表示について
- 表示する項目はCloudNNI名としていたものを、Cloud名＋相互接続先、という項目に変更
まとめ

深堀り箇所のビフォーアフター

Cloud NNI PoP名ってなんのこっちゃ？となると思うので、OCXポータルの画像を用いてビフォーアフターを載せておこうと思います。

リソース作成画面

before

after

"新たなCloud Connection リソース作成画面、項目名や選択肢が大きく変わってる" — 新たなCloud Connection リソース作成画面、項目名や選択肢が大きく変わってる

リソース一覧画面

before

after

"新たなCloud Connection リソース一覧画面、かなり大きな変更が見て取れる" — 新たなCloud Connection リソース一覧画面、かなり大きな変更が見て取れる

このパラメータは、OCXのCloud Connectionを作成する際に、各パブリッククラウドにおいてどのロケーションから直接接続するかを決めるパラメータとなっており、Cloud Connectionにおいて最も重要なパラメータになります。もともとは Cloud NNI名 という項目名だったものをパラメータ内のデータ含めて変更しており、お客様の利用においては表記が変わっただけになりますが、実装する立場としては「使い勝手が悪くなることなく、新たな概念を加える」という想いで取り組みました。

※裏側の話をすると、実は内部のデータ構造を大きく見直ししており、かなり大規模な変更をしております。

大きく変更した背景

以前の CloudNNI名 という項目は、リソース作成画面上はある程度詳細な情報を表記していましたが、基本的にはドキュメントサイト上の組み合わせ表を見ながら運用するのが前提の仕組みになっており、使い勝手の悪いものとなっておりました。

以下を見ていただくと、ひと目では詳細なロケーション情報がわらない状態になってます。

旧リソース一覧画面

"ぱっと見ではロケーションがわからない状態" — ぱっと見ではロケーションがわからない状態

変更前当時のロケーション情報の組み合わせ表 (AWSの例)

CloudNNI名	CloudNNIロケーション	クラウド接続先リージョン
AWS Hosted Tokyo#1 Primary	Equinix TY4	ap-northeast-1
AWS Hosted Tokyo#1 Secondary	アット東京 CC1	ap-northeast-1

実際にお客様からの問い合わせもいくつか発生しており、ご迷惑をおかけした経緯がございます。そんな中で抜本的な見直しを行い、改善を進めた形になってます。

ここからは、実装時に考えてたことを書いていきます。

実装その1、リソース作成画面の項目名について

リソース作成時に選択するパラメータそのものの項目名について、以下のような改善を実施しました。

リソース作成画面にて項目名を、「Cloud NNI名」から「Cloud NNI PoP名」という名前に変更

PoP（Point Of Presence）という言葉を追加した背景としては、以下のとおりです。

クラウドとの直接接続に関連するインターネット上の情報において、高い頻度で使用されている言葉であること
- Cloud NNI という言葉だけだとあまり聞き馴染みがないため、高い頻度で使用されている言葉と組み合わせてより分かりやすくしたかった
  略称をPOPにするか、PoP にするかも、インターネット上の使用頻度などを調べて、どっちを使うか社内でちゃんと決めたりしてます！
選択するパラメータそのものにも手を加える（下部で詳細は説明します）ため、新たな抽象度の概念を取り入れたかった
- ※ここについては、内部的なデータ構造見直しの影響も関係している

この部分については、PoP以外に ロケーション という言葉も案としては考えていました（Cloud NNI ロケーション）。ですが、ロケーションという言葉はクラウドインフラにおいてあまりに使用頻度が高く、抽象度も曖昧になる（Cloud NNI ロケーションとした場合、それがBBIXプロバイダ・ロケーションなのか、パブリッククラウド・ローションなのか、若干曖昧さが発生してしまう）と思ったため、使うのを避けました。

<<ちょっと脱線>>

項目名などの"命名"にこだわることは非常に重要だと思ってます。例を挙げると、攻殻機動隊 S.A.C. というアニメにおいて、通称 "笑い男事件" という名称が生まれたり、様々な事件で起きている現象そのものを STAND ALONE COMPLEX と命名することで会話をする際の焦点を明確にすることができています。

実装その2、パラメータについて

リソース作成時に選択するパラメータに対しては、以下のような改善を実施しました。ひとつずつ説明します。

"変更により、様々な情報がひと目で分かるようになっている" — 変更により、様々な情報がひと目で分かるようになっている

別資料を見てもらったりすることなく、直感的に情報を取得してもらえるような表示に変更

我々が独自に命名していた形（"AWS Hosted Tokyo#1" のような書き方）を廃止することにしました。とにかく必要な情報のみを少ない操作で取得してほしいので、なるだけ読み替えが必要な要素は排除しました。

BBIXプロバイダ・ロケーション、パブリッククラウド・ロケーション、それぞれがひと目でわかるように変更

今回の実装から実は、BBIXプロバイダ・ロケーション（BBIX側のクラウド直接接続収容設備のロケーション）の情報が詳細にわかるようになっています。ネットワークサービスにおける自社設備の情報はブラックボックスとなることがほとんどですが、直接接続を収容する部分までは公開するように変更しました。

"1つ目のデータを見ると、BBIXプロバイダ側はEquinix TY4、AWS側はEquinix TY2、というのがわかる" — 1つ目のデータを見ると、BBIXプロバイダ側はEquinix TY4、AWS側はEquinix TY2、というのがわかる

理由については、サービスを展開する性質上それぞれのBBIXプロバイダ・ロケーション、パブリッククラウド・ロケーション、が異なる場合があるためです。（画像をよく見ると、BBIXプロバイダ側はEquinix TY4、AWS側はEquinix TY2、となっている）

これにより、障害を想定する際に、ある程度細かいところまでお客様自身でも確認が可能となっております。

見せ方も意識する

また、パラメータ内のデータ表示方法も少しこだわりました。

■Cloud NNI PoP名のフォーマット
・BBIX ("BBIXプロバイダ・ロケーション情報") <====> "パブリッククラウドを示す表記" ("パブリッククラウド・ロケーション情報")

このようなフォーマットにすることにより、1つのパラメータ操作の中で「"Cloud NNI PoP" という単位の中に、クラウド直接接続設備における"BBIXプロバイダ・ロケーション"と"パブリッククラウド・ロケーション"情報があり、それぞれが繋がっている」みたいな集合的ニュアンスが表現できるようになり、かつ「それらの情報がプルダウン内の1データごとに収まってる」形になったのでは、と思います。

これにより「ロケーションに関わる設定をこの1つのパラメータ操作だけで完結する」というシンプルなものになったと思ってます。

また() ※カッコの中のロケーション情報についても、いちいち並びを気にすることなく、標準的なソートによって見やすい並びになるような工夫をしてたりします。

可能な限りバックエンドAPI側で完結した形で実装

見せ方を意識することにも一部関係することとして、フロントエンド側で扱うデータの渡し方も意識して実装してます。

例えば今回の場合、パブリッククラウド・ロケーションだけを選択し、その後選んだデータに合わせたBBIXプロバイダ・ロケーションを表示する実装方法もありました。しかし、この方法はフロントエンド側で条件分岐がどうしても発生してしまうと思います。

フロントエンドでの実装に依存しすぎると予期せぬ挙動が発生することもあるため、命名規則をしっかり決めたうえで可能な限りバックエンドでデータをひとまとめにして渡し、フロントエンド側がシンプルな実装になるように意識しました。利用者にはなかなか伝わらない部分ではありますが、こういったことも実装には不可欠な検討事項になります。