SaaS Connection を使用してみる

はじめに

こんにちは！

BBSakura Networks でネットワークエンジニアしています大野木です。

9 月 26 日に OCX のサービスとして SaaS Connection をリリースしました。

https://www.bbsakura.net/ja/information/press/ocx-2024-09-26-01

この SaaS Connection を使用すると、お客さまは OCX 網内からインターネットを経由せずに指定の SaaS に接続できます。

SaaS を使用したいが、社内のセキュリティポリシー上、インターネット接続を許容できないといったお客さまのニーズにお応えするべく、SaaS Connection は開発されました。

この記事では、SaaS Connection の使用方法についてご紹介します。

また、BBSakura Networks Advent Calendar 2024 の 13 日目の記事となります。

事前情報

SaaS Connection の接続構成例と実際の使用方法についてご紹介する前に、SaaS Connection の特徴、接続先、設定項目について事前情報の確認をします。

SaaS Connection の特徴

SaaS Connection は、次の特徴があります。

• 指定の SaaS 事業者への閉域接続を NAT 機能(SNAT)とともに提供している
• OCX リソースの VC とアタッチできる
• IPv4 のみ対応している
• SaaS への名前解決は別に用意する必要がある
• お客さま CPE や OCX Router (v1) とは eBGP を使用して接続する

SaaS Connection の接続先

SaaS Connection の接続先として、現在( 2024/12/13 時点)では以下になります。

• Cybozu
• Microsoft Azure Peering Service (以下 MAPS と略する) *1

今後もさらに SaaS Connection の接続先は追加されますので、 より便利にご利用頂けると考えています。

SaaS Connection の設定項目

SaaS Connection では、次の設定項目を入力し SaaS Connection リソースを作成します。

• 名前： OCX ポータル上で表示される SaaS Connection リソース名
• ロケーション： SaaS Connection が作成されるロケーション
• 接続先 SaaS ： 接続する SaaS 事業者名
• IPv4 ゲートウェイアドレス：お客さまのネットワークから SaaS へと接続するデフォルトゲートウェイの IP アドレス
• NAT IP アドレス：SaaS 接続時に SNAT するための変換用グローバル IP アドレス
• ローカル ASN ： SaaS Connection で動作させる AS 番号

SaaS Connection (Cybozu)の作成画面

SaaS Connection を作成後、お客さまの CPE や OCX-Router(v1)と接続するために、BGP Parameter を設定します。

• BGP Parameter：SaaS Connection で BGP 機能を使うための設定項目（ローカルアドレス、リモートアドレス、リモート ASN）

SaaS Connection の BGP Parameter の設定後の画面

「IPv4 ゲートウェイアドレス」と「NAT IP アドレス」の詳細については、Internet Gateway サービス解説 に詳細な記載がありますので、ぜひご覧ください。

SaaS Connection の使用方法

実際に SaaS Connection を使用する手順を説明します。使用する手順を項目で記載すると次のようになります。

1. OCX の他のリソース準備を行なう
   • Physical Port、VCI、VC 作成しアタッチする
2. SaaS Connection を使用する
   • SaaS Connection を使用する構成を検討する
   • SaaS Connection を作成する
     • SaaS Connection の BGP Parameter 作成
   • (オプション) OCX-Router(v1)を作成する
     • インタフェースを作成する
     • OCX-Router(v1 の BGP Parameter 作成
   • SaaS Connection を接続したい VC へアタッチする

1 については、OCX の他リソースの説明も含みますので、今回のご説明では省略します。適宜、 ドキュメントサイト をご覧ください。

2 については、次の章で構成例と BGP Prameters の例を示しながら、説明していきます。

SaaS Connection を使用した構成例

SaaS Connection を使用する際の構成例について説明します。

代表的な構成例として、

• ①お客さま用意の CPE と SaaS Connection が BGP 接続を行なう構成
• ② OCX-Router(v1) を使用した構成

の２種類が挙げられます。*2 *3

ポイントとしては、SaaS Connection の特徴でもご説明した通り、eBGP 接続を使ってお客さま CPE や OCX-Router(v1) と通信を行なうため、事前に BGP の設計を考えておくことが重要になります。

また、OCX-Router(v1) を BGP 接続の集約ポイントとしてご使用いただくことで、OCX の他のリソースである Cloud Connection とも接続が容易なため、おすすめです。

今回の説明では、②の構成で CPE と OCX-Router(v1)間を BGP 接続した構成を使用して、SaaS Connection の使用方法について説明していきます。

SaaS Connectionを使った構成例

次の章で、構成例②を実際に設定項目を記述しながら説明します。

BGP Parameter の設定例

BGP Parameter を次の項目のように決定し、SaaS Connection と OCX-Router(v1) を作成、BGP Parameter の設定をします。

例

1. SaaS Connection に関しての設定
   • SaaS Connection 作成時に設定入力
     • ローカル ASN: 65002
   • BGP Parameter 作成時に設定入力
     • リモート ASN: 65000
     • ローカルアドレス: 10.70.0.1
     • リモートアドレス: 10.70.0.2
2. OCX-Router(v1) に関しての設定
   • OCX-Router(v1)作成時に設定入力
     • ローカル ASN: 65000
   • (CPE 向け)インタフェース作成時に設定入力
     • ローカル IPv4 アドレス: 10.70.0.1
   • (SaaS Connection 向け)インタフェース作成時に設定入力
     • ローカル IPv4 アドレス: 10.90.0.2
   • (CPE 向け) BGP Parameter 作成時に設定入力
     • リモート ASN: 65001
     • ローカルアドレス: 10.70.0.1
     • リモートアドレス: 10.70.0.2
   • (SaaS Connection 向け) BGP Parameter 作成時に設定入力
     • リモート ASN: 65002
     • ローカルアドレス: 10.90.0.2
     • リモートアドレス: 10.90.0.1
3. CPE に関しての設定
   • CPE 側の仕様にあわせて設定
     • ローカル ASN: 65001
     • リモート ASN: 65000
     • ローカルアドレス: 10.70.0.2
     • リモートアドレス: 10.70.0.1

BGP Parameter を設定した構成例

SaaS Connection と OCX-Router(v1) を作成後、画像の構成例に従って SaaS Connection 等を VC にアタッチします。

アタッチが終了すれば、SaaS Connection を使用する準備は整いました。

SaaS Connection の動作確認

最後に、これまで紹介した構成例に Ubuntu Desktop を接続して、どのような動作になるか確認していきます。

次の図のように、Ubuntu Desktop を CPE に接続します。

また、SaaS Connection では、名前解決は別に用意する必要があります。今回は、CPE 側で Ubuntu Desktop 用の 名前解決用に Google Public DNS (8.8.8.8) 向けへの疎通性を別に用意しました。

Ubuntu Desktop をCPEに接続するイメージ図

今回は、SaaS Connection (Cybozu) を使用しているので、試しに store.cybozu.com にブラウザからのアクセスできるかを試します。

store.cybozu.comにアクセスが成功している図

無事に、store.cybozu.com にアクセスできました。

また、コンソールより traceroute の結果を見ても、本日紹介した構成例に従って、ルートを通っていることがわかります。

bbix@bbix-virtual-machine:-$ tracepath -n store.cybozu.com
1?: [LOCALHOST]    pmtu 1500
1: 192.168.112.1    0.976ms
1: 192.168.112.1    0.862ms
2: 10.70.0.1        1.329ms
3: 10.90.0.1        1.075ms asymm 4
4: 10.249.77.0      1.547ms
5: 10.249.76.80     2.144ms
6: 101.203.88.167   3.416ms
7: 103.79.12.54     2.851ms
8: no reply
9: no reply

また、違うサイトに閲覧できないことも確認します。例として、Wikipedia のメインページにアクセスします。

Wikipedia にアクセスができない図

問題なくアクセスできないことが確認できました。

おわりに

この記事では OCX の新サービスである SaaS Connection の使用方法について解説しました。

SaaS Connection は今後も機能強化していく予定ですので、楽しみにお待ちください。

もし、今回の記事を通して OCX のご利用に興味を持たれましたら、弊社までお問い合わせください！また、不明点などもありましたら遠慮なくお知らせくださいませ。

*1:MAPSとは、Microsoft が提供する「Microsoft Cloud」（「Microsoft Teams」「Microsoft 365」「Dynamics 365」「Azure」などのクラウドサービスの総称）へ直接接続を行なうことで、品質を強化するネットワークサービスです。

*2:今回の構成例では、説明簡略化のため冗長構成を省略して記述しております。

*3:②の構成の注意点として、CPE と OCX-Router(v1)間を Static Route で経路設定をした場合、OCX-Router(v1)の「Connected と Static Routes の経路再配布」機能を使用することを忘れないようにしてください。

転生したらホームページがWordPressだった件

＃異世界転生と、忘れ去られたWordPress

・・・おや・・？

私の名前は、Maki。 ある日、私は仕事中に突然の睡魔に襲われ、あっという間にこの世を去ってしまった。 そして、気がつくと私は、見知らぬ草原にいた。 私は、自分が異世界に転生したことを悟った。そう、ここは、フロント・エンドと言う世界ーーーー。

異世界で目を覚ました私は、そこで見慣れたロゴが表示されているパソコンを眼の前に見た。それは、私がかつて使っていた、あのWordPressのロゴだ。

「WordPress！？」

私は思わず声を出してしまった。 そうだ。前世の私は、BBSakuraというエンジニア集団の会社でモバイルコアのバックエンドエンジニアとして働いており、自社のホームページをWordPressで構築した経験があった。しかし、その記憶はなぜか断片的で、詳細を思い出せない。

＃WordPressの課題感

・・WordPress・・そうだ！

私は前世の記憶を一つ思い出した。それは、WordPressの運用がとても大変だったこと。

「しばらくさわってないし、まずはこのWordPressをメンテしよう！」

そう思った私は、さっそくパソコンの前に座る。しかし、WordPressの操作方法はほとんど覚えていない。

WordPressでホームページを本格運用した場合、以下のような問題が発生したはずだ。

• ステージングと本番を分けるのが大変
• 開発ブランチを作りたい（開発自体をGitでやりたい）
• 投稿記事のフォーマットが記事によってズレてしまったりする
• 動作がもっさり
• プラグインのバージョンメンテが大変
• 子テーマを作らないといけない問題
• プラグインのバージョンメンテナンス、脆弱性の問題

そこで、最新の技術を使って、もっと簡単にホームページを作成できないかと考えた。

最近話題のRemixというフレームワークを使えば、Reactのコンポーネントをサーバーサイドでレンダリングできると聞いたことがある。これなら、動的なホームページを簡単に作成できるはずだ。

＃モジュールの壁にぶつかる

そこで、私は、初めてのフロントエンドフレームワークであるRemixを使って、自社ホームページを構築することにした。 Remixは、最新のWeb開発のトレンドを取り入れた、とても便利なフレームワークらしい。フロントエンドやWebの知識がまったくないところからのスタートだけど、便利で最新って書いてある。

バックエンドもやってたし、Remixもなんとかなるはず！簡単だ！（フラグ）

私は、Remixでプロジェクトを作成し、さっそく記事を作成するためのモジュールを探し始めた。しかし、なかなか良いものが見つからない。記事を誰でも簡単に書けるように、Markdown形式で入力できるようにしたい。 ようやく見つけたモジュールは、機能的には申し分なかったが、なんとRemixに対応していなかったのだ。

＃フロントの基礎を学ぶ

Remixの壁にぶつかり、私は改めてWeb開発の基礎を学び直すことにした。JavaScript、TypeScript、Reactといったフロントエンドの技術を、一から勉強し直す。

JavaScriptは、Webの基本となる言語だ。TypeScriptは、JavaScriptの静的型付け言語だ。Reactは、Facebookが開発した、Webアプリケーションの開発によく使われるフレームワークだ。 まずは会社で契約しているUdemyを使ってJavaScriptの勉強をスタートしてみた。

JavaScriptとTypeScriptの学習は、それほど苦労しなかった。しかし、Reactの学習は、とても難しかった。Reactの考え方は、今までのGoでのプログラミングの経験とはまったく異なるものだった。

• React
  • フロントエンド開発に特化したJavaScriptのライブラリ
  • ブラウザ（クライアント）で実行されるコードと、サーバーで実行されるコードを、シームレスに書くことができる。
  • UIの部品（コンポーネント）を作成し、作成したコンポーネントを組み合わせることで画面を構築する。
  • 非同期処理が中心（沼）。ユーザー入力やバックエンドとのAPI通信のために最適化されている。
  • DOM（ウェブページの設計図）を直接更新せず、仮想DOM（DOMのレプリカのようなもの）を使って間接的にレンダリングを行うことで、DOMを直接更新するより高速に動作する。
  • コンポーネントごとに状態管理を行い、状態が変わるとコンポーネントを再レンダリングする。
• Go
  • 汎用プログラミング言語。
  • Goroutineによる並行処理がシンプルに記述でき、高負荷なバックエンドの処理を効率化できる。

また、Reactと同じくフロントエンド開発の2大巨塔のひとつとしてVueも存在するが、この検討段階では選択肢に入らなかった。なぜなら、BBSakuraが開発しているプロダクトのひとつであるネットワーキングポータル「OCX」はReactで書かれているからだ。できるだけ同じライブラリで作った方が、メンテナンスもしやすく、また、「OCX」で実現したいことの実験場としてホームページを使うこともできるかもしれない。

それでも、私は諦めずにReactの学習を続けた。そして、ようやくReactの基本的な部分を理解することができた。

Reactとそのおともだちの依存関係

＃Next.jsで再挑戦

しばらくの間、基礎を固めた後、再びホームページの開発に取り掛かる。今回は、Next.jsというReactフレームワークを使うことにした。Next.jsは、静的サイト生成とサーバーサイドレンダリングの両方に対応している。また、静的サイト生成により高速に動作するため、SEOにも強いという点が魅力だ。

ホームページの開発にNext.jsなどのフレームワークを使うのは、少々オーバーキルかもしれない。しかし、フロントの基礎を学んでいるときに感じたように、「OCX」はNext.jsを使って開発されており、「OCX」で実現したいことの実験場としてホームページを使うには、Next.jsという選択が一番良いと考えた。

Markdown形式で記事を作成するためのモジュールも、Next.jsに対応しており、スムーズに開発を進めることができた。

Webアーキテクチャを整理し、さまざまなフレームワークの中からNext.jsを選択した

＃社内リソースの確保と開発の大義名分の建てつけ

この世界、フロント・エンドに降り立ってからというもの、私の使命は「OCX」を開発することだった。しかし、いきなり未経験の状態から既存のプロダクトに手を付けるにはいささか手腕がたりない。それならば、この忘れ去られたホームページをプロジェクト化し、人を募っていろいろな知見のアウトプットの場にしよう。部署横断でわちゃわちゃして、Geeks' Playground を実現しよう。ないのなら作る。そう、自らの手で。それが私であり、BBSakuraだ。

少しずつ感覚を取り戻してきた。

この案件をプロジェクト化するには、まずは以下のことが必要だ。

• 直接お金を生まないという性質上、この案件を実行する大義名分が必要（体力）
• ホームページという性質上、デザイン実装が得意なメンバーと事業が得意なメンバーが必要（パーティメンバー）
• 納期を自ら設定し、最後までやりきる根気（SAN値）

私は、事業メンバーをつかまえ、「Geeks' Playground を実現したい」「後進の育成に使いたい」「部署横断のコミュニケーションの場をつくりたい」「BBSakuraのプロモーションに力を入れるための第一歩を踏みたい」という大義名分を伝えたところ、快く同意していただいた。また、デザイン実装が得意なメンバーも集めてくれるというのだ。とても助かった。

ここからみんなで力を合わせて、ホームページを作っていこう。

＃力を入れたはじめてのフルスクラッチ自社ホームページ

私がこの業界で仕事をするにあたって、とても大切にしている心がある。それは、「技術を人に意識させない」こと。せっかくフルスクラッチで少数精鋭で取り組んできたプロジェクトだ。ここに、自分の思いを思い切りぶつけたい。その思いを体現するために重視したのは、以下の1つのシンプルなポイントだ。

• ユーザーの「自然体」をじゃましないデザインにする

このポイントは奥が深い。自然体をじゃましないためには、色調やデザインもシンプルにしたい。また、目の導線を遮らないボタンやテキストの配置にも工夫した。また、上に書いたように、記事を誰でも簡単に書けるように、Markdown形式 にすることも、メンテナーの自然体にできるだけ近づけるための努力だ。

執筆時点でのBBSakuraのホームページ（WordPress脱却のすがた）

＃新たな壁、そして決断

ホームページの開発が完了し、Vercelでデプロイできた喜びも束の間、新たな問題が浮上した。グループ会社の方針により、特定の認証局が発行したSSL証明書を使用する必要が生じたのだ。Vercelでは、この要件を満たすことが困難だった。

Vercelは、GitHubのリポジトリと連携するだけで簡単にWebサイトのデプロイ〜ホスティングまでを実現できる便利なツールだ。しかし、持ち込み証明書を利用できるEnterpriseプランに切り替えるには多額の費用がかかる。弊社で利用するアカウントの数を考慮すると、会社を倒産させる規模の価格の試算がでてしまった。（執筆時点の情報）

これらの問題を解決するため、私は別のプラットフォームへの移行を決意した。

＃Google Cloudへの移行

いくつかのクラウドホスティングサービスの中から、私はGoogle Cloudを使うことを決意した。比較対象は以下の3つ。

• Cloudflare Pages
• さくらのクラウド
• Google Firebase Hosting

この中から、以下の条件を満たすものを絞り込んだ結果、Google Cloudを選ぶこととなった。

• 低コスト: 費用をできるだけ安く抑える。
• シンプル構成: 組み合わせるサービスを最小限にする。
• 簡易機能: 複数サービスを組み合わせる場合、シンプルな機能のものを選ぶ。
• サーバーレス: 運用の負担を軽減するため、サーバーレス構成にする。
• 環境分離: ステージング環境と本番環境を分離する。
• 限定公開: ステージング環境を社内のみに公開することでセキュリティを強化する。

Google Cloudへの移行を決意した私は、よりスケーラブルで効率的な環境を目指し、Compute Engineではなく、Cloud BuildとCloud Run、そしてCloud Load Balancingという組み合わせを選択した。 まず、Cloud Buildを使って、Dockerイメージを作成する。Next.jsのアプリケーションをDockerfileで定義し、Cloud Buildトリガーを設定することで、コードの変更を検知し、自動的に新しいイメージをビルドするようにした。

次に、Cloud Runにコンテナをデプロイする。Cloud Runは、サーバーレスコンテナプラットフォームであり、リクエストに応じてコンテナを起動・停止するため、非常にコスト効率が良いのが特徴だ。また、自動スケーリング機能も備わっており、トラフィックの変動に柔軟に対応できる。 最後に、Cloud Load Balancingを使って、複数のCloud Runインスタンスにトラフィックを分散させる。これにより、高い可用性と耐障害性を確保することができる。

BBSakuraホームページのデプロイ図

＃新たな章へ、そして未来へ

Cloud Build、Cloud Run、Cloud Load Balancingという組み合わせは、私にとって新たな挑戦だった。しかし、これらのツールを組み合わせることで、非常に効率的でスケーラブルなWebアプリケーションを構築することができた。

現在は、Cloud RunのログをCloud Loggingで集計し、Cloud Monitoringで監視することで、アプリケーションの状況を常に把握している。 異世界に転生し、WordPressから始まり、Next.js、そしてGoogle Cloudのサーバーレス環境へと、私のWeb開発の旅はますます加速している。一生懸命制作したホームページだが、まだまだ改善点はもりだくさん。もっといいUI、もっといいデザインを求め、もっといいUXを探求しよう。この異世界で、私はこれからもWeb開発のスキルを磨き、より革新的なWebアプリケーションを作り続けていきたい。

＃最後に

この記事は BBSakura Networks アドベントカレンダー 12 日目の記事です。

大きくなりつつある会社のオンボーディングを整える

はじめに

この記事は BBSakura Networks アドベントカレンダー 2024 の 11 日目の記事です。

adventar.org

こんにちは。開発本部 モバイル開発グループの みずき @n0mzk です。

モバイルコアの開発・運用がメインの業務ですが、今年の 8 月から兼務で人事をやっています。人事といっても労務管理などは行わず（もともと担当してくれている方がいるので）、人材開発といわれるような分野を担当しています。今日は、人事をやることにした背景と、最初の取り組みとして行っているオンボーディングについて書きます。

BBSakura で人事を始めた

BBSakura は今年の 8 月で設立から丸 5 年が経ちました。設立時には 20 名程度だった社員数もいまは 100 人を越え*1、当初エンジニア中心だった職種も、企画・営業・経理など、多様化しています。

人数が増えたことで、OCX（Open Connectivity eXchange）のような大きなプロダクトを作れるようになった反面、組織課題も大きくなってきていると感じていました。具体的な課題意識については後に記載しますが、それらの課題について対策を打ちたく、人事業務をやらせてほしいと上司に訴え、兼務でやらせてもらうことになりました。

設立から 5 年経った BBSakura の組織課題

以下のような課題を感じていました。

• テキスト・非同期コミュニケーションメインとする、リモートワーク前提の働き方が崩れつつある
• 越境しづらくなっている

テキスト・非同期コミュニケーションメインとする、リモートワーク前提の働き方が崩れつつある

BBSakura は設立時（コロナ禍前）からフルリモートで働く前提の会社でした。そのためテキスト・非同期コミュニケーションを重視しています。オフィスに全員で集まって議論しながら開発することがなかなかできないため、全員に議論の背景と結論を伝えるにはテキストが残っている必要があるのです。

ですが、東京在住で東京の拠点に出社する頻度の高いメンバーが増えてきたためにオフィスでの口頭コミュニケーションで意思決定がなされ、テキストが残らないことが増えてきました。そうするとその場にいなかったメンバーには断片的な決定事項のみが伝えられ、背景を理解できないまま開発することになります。後から質問しながら・当時の議論を思い出しながら認識を合わせる必要があったり、開発が進んでから手戻りが発生したりして、開発スピードが下がります。

今ではプロダクトの規模も大きくなっていて、その場にいた人だけが手を動かせば作れるというものでもなくなっているのも、この問題が発生する背景です。

越境しづらくなっている

BBSakura の行動指針のひとつに "Beyond the border" というものがあります（参考: 会社紹介 | BBSakuraについて | BBSakura Networks株式会社）。

自分の担当範囲・自部署の責任範囲の業務だけやればよいという意識でいるのではなく、部署を越えて互いに興味を持ち、口も手も出し、自律協調してみんなで良いものを作ろうということだと理解しています。

ですが会社が大きくなり互いの部署のことを知る機会が減っていること、また事業の規模が大きくなってそれぞれ自分の仕事で忙しくなっていることから、越境（Beyond the border）しづらくなっていると感じています。忙しいのは仕方ないにしても、部署を越えて業務内容や人となりを知れる状態を維持することで、互いに興味を持ち越境しやすい組織にしたいのです。

まずはオンボーディングから

これらの課題への対策として、まずは BBSakura に入ってきてくれる方たちに、BBSakura がどんな会社なのか、なにを大事にし、なにを目指しているのかを伝えられるようにしようとしています。

これまで入社者へのオンボーディングは配属先の部署任せになっていました。ですが会社として大事にしていること・やろうとしていることは全員に同じように伝える必要があるので、入社初日に人事として時間をもらって会社としてのオンボーディングを行うようにしました。

組織や事業の紹介ももちろん行いますが、下記のようなことを伝えるのに時間を割いています。

• フルリモート前提の働き方をする会社であること
• そのため、テキスト・非同期コミュニケーションを重視していること
• フロー情報・ストック情報を意識してツールを使い分けていること
• スムーズなコミュニケーション・円滑な業務遂行のために、リモートでも互いの様子や人となりを知ることも大事にしていること

以下はオンボーディングで利用している資料の 1 ページです。Slack を中心とした社内コミュニケーションについて説明しています。

オンボーディング資料の一部

いつも下記の記事を紹介させていただきながら、Working Out Loud を推奨しています。

blog.studysapuri.jp

Working Out Loud を実践するのは、助けてもらいやすい状況を作るためだけでなく、それぞれが自分のことを発信することで互いに興味を持てるようにするためでもあり、またチームを越えてノウハウの共有が行われる可能性を生むものでもあります。

入社オンボーディングはオフラインで顔を合わせて行うのがいいかなという迷いもありつつ、リモートワーク前提の働き方を伝えるために今のところはあえてオンラインで行っています。入社してくれた方の意見を聞きながら、毎月、試行錯誤しています。

今後やりたいこと

オンボーディングに対して「社内のやりとりの雰囲気がわかった」、「溶け込みやすかった」という感想をもらい、やってよかったなあと思っているし、今年入社した鐘ヶ江さんがアドベントカレンダー 8 日目の記事で「オンラインでもオフラインでも、メンバー一人一人が自分らしく参加できる文化が根付いているため、私のような中途組も自然と馴染めている気がします！」と書いてくれているのはとても嬉しい感想でした。

BBSのコミュニケーション文化の魅力 - BBSakura Networks Blog

ですが、まだまだやれていないこと・やりたいこともあります。今後は以下のようなことも取り入れたいと思っています。

社内の人間関係構築支援

配属先以外の部署について各部署から説明してもらうとか、直属以外の上司と 1on1 してもらうというのを最近入社した方には行っています。他部署の業務を理解することに加え、ふだんあまり関わらない人とのコミュニケーションのきっかけにもなるとよいと思っています。なにか困ったときに配属先部署の外に相談できる相手がいる状態であることが、主に中途で入った方にとっては安心材料になると考えているからです。

上司部下の関係にならない上位レイヤーの人や、業務上少し関わりがある人への紹介・1on1 設定など、まだ人間関係を構築するための支援できることはあるので、今後増やしたいと考えています。

入社後の継続的なサポート

いまのところ人事として行っているのは入社初日のオンボーディングのみです。ですが、会社に馴染んで活躍してもらうためには入社後 1 か月・3 か月などのタイミングで様子を聞いたり、困っていることを聞いてサポートしたりという継続的なサポートも必要だと思っています。これも今後取り組みたいことのひとつです。

おわりに

大きくなりつつある組織で新しいメンバーに活躍してもらえる組織を作るための取り組みについて紹介しました。

本業である開発業務と並行してこれらを行う負担の大きさや、組織として立ち上がっていない状態で人事をやるやりづらさはありますが、やりたいことを自分から提案すれば実現させてもらえるところは、設立時から変わらない、BBSakura の良いところです。新しく入ったメンバーにも、やりたいことを持ってそれを主張できる状態まで馴染んでもらえるよう、初期からいるメンバーとしてサポートしたいなと思っています。

*1:親会社と兼務のメンバーも多くいます

Cloud Connection のパラメータ表記を大きく変更した話

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名 というパラメータに表記変更をしたこと」について深堀りしたいと思います。

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

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

リソース作成画面

• before

旧Cloud Connection リソース作成画面

• after

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

リソース一覧画面

• before

旧Cloud Connection リソース一覧画面

• after

新たな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、パラメータについて

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

旧Cloud Connection リソース作成画面

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

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

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

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

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

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プロバイダ・ロケーションを表示する実装方法もありました。しかし、この方法はフロントエンド側で条件分岐がどうしても発生してしまうと思います。

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

実装その3、リソース一覧画面の表示について

CloudConnectionリソース作成後に表示するリソース一覧画面についても、変更してます。

Cloud名＋相互接続先の項目に変更

表示する項目はCloudNNI名としていたものを、Cloud名＋相互接続先、という項目に変更

リソース作成画面で選択するCloud NNI PoP名の表記をそのまま表示することも考えましたが、情報が横に長くなるため、リソース一覧上は"Cloud名"と"パブリッククラウド側ロケーション情報（項目名としては"相互接続先"）、という最低限必要な情報の表示にとどめています。

なお作成時に選択したCloud NNI PoP名の形で再度見たい場合は、Infomationアイコンを押してもらうと、確認できるようにしてます。

詳細から確認することも可能

まとめ

今回は 表記の変更 に絞って記事を書いてみました。

表記をどう変更するか、だけでも正直それなりに悩みました、、、 ありとあらゆる案を考え、技術メンバー以外のレビューも多方面にしっかり行いながら、たくさんボツにした中で最もいい形を採用したつもりです。

「UIの使い勝手を大きく変えることなく改善するために、何をどこまで表現するかを考えつつ、齟齬が発生しない＆関連する外部サービスと見比べて違和感のない形でフォーマットや言葉を考える」というのは、すごく難しいなと痛感しました。

しっかり検討したおかげで、分かりやすくシンプルな使い勝手になっているのでは！と思ってます。おわり。

BBSのコミュニケーション文化の魅力

はじめに

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

BBSakura Networks の鐘ヶ江です。
BBSには今年の夏頃から中途入社して、普段は親会社のBBIX側に関わるお客様向けシステムの開発を担当しています。
今回はリモートワーク中心の組織だからこそのBBSのコミュニケーション文化を紹介します。

BBSのコミュニケーション文化の魅力3選

Slackでの会議実況

BBSで隔週開かれるリモート会議では議事に関してのコメントや雑談タイムのツッコミを自由にSlackで発信しています。
参加者が多いオンライン会議では一方向の発信になりがちですが、Slackでコメントを投げられることで、会議の雰囲気も和やかに感じます。
ただの傍観者から会議の空気を作る一員へと、自然な形で関われるのがいいなと感じています。
発言しない人がメモってくれるので勝手に議事録ができているのもイイ。
↓自分が司会担当のとき様子。雑談ネタで自己紹介しました。色々コメントくださって温かい☺️

定例会議の実況の様子（一部モザイクしています）

timesチャンネル

私のtimesチャンネルの様子

Slack上には個人専用のチャンネル（通称：times）があり、X（旧Twitter）のように自由に発信できる場となっています。
特に決まったルールはなく、業務の進捗から日常のつぶやきまで、それぞれが自分らしい投稿スタイルで運用しています。
自分は主に開発でハマったことのメモや進捗共有の場として活用していますが、他のメンバーのチャンネルも覗いてみると、技術的な気づきから何気ない日常の出来事まで、多彩な投稿が見られます。
普段は直接関わりのない部署の方の業務内容を知ることができたり、ふとした息抜きにチャンネルを巡回するのも楽しみの一つです。
時折もらえる共感のスタンプや相槌のコメントが嬉しかったり。

四半期会議（今は半期会議）

今は半期に一度となっていますが、BBSのメンバーが一同に集まる懇親イベントがあります。
普段の業務はリモートメイン、オンラインの会議もカメラオフの文化なので「実は入社以来、初めて顔を合わせます！」という声もちらほら。
弊社のOCXに関連したアイデアソンも開催され、チームを越境したグループで意見を交わしたりと、普段のオンライン会議とは一味違う活発な議論が展開されてました。
普段は別々のプロジェクトで働くメンバー同士が一つのテーマについて語り合うことで、新鮮な発見や気づきも多く生まれた気がします。
普段対面で接する機会が少ないためこうしたイベントはとても貴重な時間に感じられました！最後の懇親会含め楽しいイベントでした。

まとめ

BBSはリモートワークを中心とした組織でありながら、チャットでの気軽な会話、会議での自由な意見交換、そして定期的な対面での交流など、多様なコミュニケーションの形を大切にしています。
オンラインでもオフラインでも、メンバー一人一人が自分らしく参加できる文化が根付いているため、私のような中途組も自然と馴染めている気がします！

400ZRをレガシーなWDMにエイリアン入光してみた話

はじめに

 この記事では、光信号「400G-ZR」を既存のWDMシステムに「エイリアン入光」させて伝送する実験について紹介します。本記事は、光通信の専門家ではないものの「400ZR」という用語を耳にしたことがあるネットワークエンジニアを主な読者と想定しています。

 本記事は、BBSakura Networks Advent Calendar 2024 の 9日目の記事となります。

自己紹介

 こんにちはこんにちは！BBSakura Networks 開発本部のMatsu(立松 裕將)です。今年の9月からBBSakura Networksに兼務していますが、普段はBBIXで機材の購入稟議や、光ケーブルとたわむれていることが多いです。最近は、JANOGのスタッフや発表などの活動をすることも多いです。一部では「ネットワークシェル芸人」と認知？されているかアレなんですが、ネットワークインフラ専業の構築エンジニアで、ソフト寄りの話題よりかはインフラ寄りの話題が無難かなと思い、レイヤー1の話をしたいなーと思っています。

 え？BBSakuraとレイヤー1、そんなに関係なくね？と思ったあなた。
 実は、BBSakuraのアイコンは、インターネットと回線ケーブルをモチーフにした桜の花のシンボルが元になっているんですね。

bbs-logo

 カラフルなラインは、回線ケーブルの色と世界の文化や業種の多様さがまざり、とけこみあっている様子を表しています。 ふたつの異なるフォントは、世界の「これから」と「これまで」の両方を表しています。 テクノロジーは、世界中で、大きく、複雑怪奇に発展してきました。 これからは、テクノロジーのために悩んだり犠牲を払う必要はないようにしたい。 テクノロジーは、人々の幸せのためにあるべきだから。

出典：会社紹介 | BBSakuraについて | BBSakura Networks株式会社

 なので、レイヤー1の話をするのはおかしくないんです！

 といったことで今日は、光通信の基礎である「レイヤー1」について解説し、「これまで」のWDMシステムから「これから」の400ZRの導入に関する実験結果を共有したいと思います。

 レイヤー1ってそもそもなんぞ？というところから、噛み砕いて説明していきます。それではよろしくどうぞ！

Go で RADIUS をしゃべる

この記事は BBSakura Networks Advent Calendar 2024 の 12/7（土）の記事です。

こんにちは。BBSakura Networks CTO の日下部（@higebu）です。

RADIUS（Remote Authentication Dial In User Service）は RFC2865 で定義されている AAA（Authentication, Authorization, and Accounting）のためのプロトコルです。 1997 年に RFC となった古いプロトコルですが、モバイルネットワーク等では現在も現役で使われています。

今回は Go で書いているモバイルコアなどで RADIUS をしゃべらないといけなくなった方向けに便利なパッケージの紹介と、FreeRADIUS との通信方法、3GPP 独自のアトリビュートの追加方法を説明します。

layeh.com/radius の簡単な紹介

layeh/radius は RADIUS のクライアント・サーバの両方に対応したパッケージです。

アトリビュートのパーサ、シリアライザのコードは radius-dict-gen というツールで、自動生成されています。このリポジトリにないアトリビュートを追加したいときは、 RADIUS のディクショナリファイルがあれば、簡単に追加することが可能です。

Go で RADIUS クライアントを実装してみる

適当なディレクトリを作って、 go mod init しておきます。

また、 layeh/radius の README に書いてある通り、作ったディレクトリで go get -u layeh.com/radius を実行しておきます。

Access-Request を投げて CHAP 認証する main.go は下記のようになります。

package main

import (
        "context"
        "crypto/md5"
        "crypto/rand"
        "flag"
        "fmt"
        "io"

        "layeh.com/radius"
        "layeh.com/radius/rfc2865"
)

var (
        secret   string
        addr     string
        user     string
        password string
)

func init() {
        flag.StringVar(&secret, "secret", "secret", "RADIUS secret")
        flag.StringVar(&addr, "addr", "localhost:1812", "RADIUS server address")
        flag.StringVar(&user, "user", "user", "RADIUS user")
        flag.StringVar(&password, "password", "password", "RADIUS password")
}

func main() {
        flag.Parse()

        // Calculate the CHAP response from the password and challenge
        challenge := make([]byte, 16)
        rand.Read(challenge)
        h := md5.New()
        h.Write([]byte{0})
        io.WriteString(h, password)
        h.Write(challenge)
        response := h.Sum(nil)

        // Create and send Access-Request packet
        packet := radius.New(radius.CodeAccessRequest, []byte(secret))
        rfc2865.UserName_SetString(packet, user)
        rfc2865.CHAPPassword_Set(packet, append([]byte{0}, response...))
        rfc2865.CHAPChallenge_Set(packet, challenge)
        resp, err := radius.Exchange(context.Background(), packet, addr)
        if err != nil {
                panic(err)
        }
        fmt.Println(resp.Code)
}

README に PAP 認証の場合のサンプルコードがあるので、 CHAP 認証にしてみました。 コマンド実行時に RADIUS サーバのシークレット、認証したいユーザのユーザ名、パスワードを入力したいので、フラグを用意しています。

このコードで実際に認証を行えるかどうかを試すには FreeRADIUS を立てるのが簡単なので、 Docker を使って立てましょう。

今いるディレクトリの下に下記のファイルを用意しておきます。

• freeradius/raddb/clients.conf

client localhost {
        ipaddr = 127.0.0.1
        secret = secret
}
client dockernet {
        ipaddr = 172.17.0.0/16
        secret = secret
}

• freeradius/raddb/mods-config/files/authorize

bob        Cleartext-Password := "hello"
           Service-Type = Framed-User

FreeRADIUS を Docker で動かすコマンドは下記の通りです。

docker run --rm -d \
    --name freeradius \
    -v ./freeradius/raddb/clients.conf:/etc/raddb/clients.conf \
    -v ./freeradius/raddb/mods-config/files/authorize:/etc/raddb/mods-config/files/authorize \
    -p 1812-1813:1812-1813/udp \
    freeradius/freeradius-server

コンテナを起動できたら、先ほど作成したコードを実行してみましょう。

$ go run main.go -secret secret -user bob -password hello
Access-Accept

このように、 Access-Accept と表示されれば成功です。

パケットの中身を見てみると、きちんと CHAP-Password と CHAP-Response が入っていることがわかります。

Access-Request

Go で RADIUS サーバを実装してみる

Disconnect-Request を受信したら Disconnect-ACK を返すだけのコードは下記のようになります。

package main

import (
        "log"

        "layeh.com/radius"
        "layeh.com/radius/rfc2865"
)

func main() {
        handler := func(w radius.ResponseWriter, r *radius.Request) {
                if r.Code == radius.CodeDisconnectRequest {
                        username := rfc2865.UserName_GetString(r.Packet)
                        log.Printf("Disconnect %s", username)
                        code := radius.CodeDisconnectACK
                        log.Printf("Writing %v to %v", code, r.RemoteAddr)
                        w.Write(r.Response(code))
                }
        }

        server := radius.PacketServer{
                Handler:      radius.HandlerFunc(handler),
                SecretSource: radius.StaticSecretSource([]byte(`secret`)),
        }

        log.Printf("Starting server on :1812")
        if err := server.ListenAndServe(); err != nil {
                log.Fatal(err)
        }
}

go build して実行するか、 go run main.go でサーバが起動できます。

上記の通り、ハンドラ内で RADIUS の Code に応じて処理を分岐する必要があります。

ハンドラの登録時に、 RADIUS の Code を指定できるともっと便利になりそうなので、ハンドラパターンでよくある、 ServeMux を こちら で開発中です。

これを使うと下記のようになります。

        handler := func(w radius.ResponseWriter, r *radius.Request) {
                username := rfc2865.UserName_GetString(r.Packet)
                code := radius.CodeDisconnectACK
                log.Printf("Disconnect %s", username)
                log.Printf("Writing %v to %v", code, r.RemoteAddr)
                w.Write(r.Response(code))
        }

        radius.HandleFunc(radius.CodeDisconnectRequest, handler)

        server := radius.PacketServer{
                SecretSource: radius.StaticSecretSource([]byte(`secret`)),
        }

アトリビュートを追加してみる

今回は 3GPP TS 29.061 で定義されているアトリビュートを追加しようと思います。

まず、今回作っているリポジトリのトップに ts29061 という名前のディレクトリを作り、そこにディクショナリファイル dictionary.3gpp を置きます。 今回はわかりやすさのために IMSI のみ追加する内容にしています。

VENDOR          3GPP                            10415
BEGIN-VENDOR    3GPP

ATTRIBUTE       IMSI                                    1       string

END-VENDOR      3GPP

ディクショナリについて、詳しくは FreeRADIUS のサイト に説明があります。

コードを生成するには下記のコマンドを実行します。

go run layeh.com/radius/cmd/radius-dict-gen@master -package ts29061 -output generated.go dictionary.3gpp

成功すると、 generated.go というファイルができているはずです。これを使うと下記のように、 3GPP TS 29.061 に定義されているアトリビュートを使えるようになります。

ts29061.ThreeGPPIMSI_Add(packet, []byte(imsi))

最後に

今回は Go で RADIUS のクライアント・サーバの実装をしたいときに使える、 layeh/radius を紹介しました。

BBSakura Networks では fiorix/go-diameter のように OSS として公開されているプロトコル実装を使っていることもありますが、社内で独自に実装しているものもあり、プロトコル実装に興味がある方も募集しております。