去年のアドベントカレンダー以降どうやって会社技術ブログの更新を続けているか

はじめに

この記事は BBSakura Networks Advent Calendar 2023 の 1 日目の記事です。

BBSakura Networks(以降 "BBSakura" と書きます)は、親会社が提供している Open Connectivity eXchange (OCX)さくらのセキュアモバイルコネクト などを開発・運用している、エンジニアの比率が高い会社です。

記事を書くのは みずき@n0mzk です。 ふだんはモバイル開発グループという組織でモバイルコアの開発・運用をしていますが、その傍ら技術広報活動もしています。

去年のアドベントカレンダー以降、この BBSakura Networks Blog をどうやって更新し続けてきたかをお伝えします。

継続までの歴史

BBSakura のブログは 2019 年にアドベントカレンダーをやるために作られました。しかしその後は更新されないままの状態が続き、昨年のアドベントカレンダーで更新再開しました。

せっかく再開したので継続しようとアドベントカレンダー終了ごろから取り組みはじめました。

~ 2023 年 1 月

ブログ継続の機運に乗って、ブログ執筆やイベント参加・登壇などの対外発信活動を支援する「技術広報チーム」を立ち上げました。アドベントカレンダーの参加呼びかけやレビューなどに積極的に関わっていたメンバーが集まったチームです。

2023 年 12 月現在、技術広報チームは 5 人体制で、リーダーの私も含め全員が本業はプロダクトを開発するエンジニアです。技術の話題を扱うので、エンジニアで構成するようにしています。

だれかから任命されるのではなく、会社にとって必要と感じることを自発的にやれるのが BBSakura の良いところなのです。

またちょうどこのころはてなブログ 企業技術ブログコミュニティの存在を知って、BBSakura ブログもはてなブログ for DevBlog に引っ越しました。

ブログ引越しについてはテックリードの日下部が記事を書いています。

この記事でも、

以前のブログは、 2019年にアドベントカレンダー をやるために立てたブログですが、その後、 2022年のアドベントカレンダー をやるまで、全く記事が書かれることがありませんでした。 今後はそのようなことがないように、また、外から見たら何をやっている会社かよくわからないと言われなくなるように、記事を書いていきたいと思っています。

はてなブログ for DevBlogに引っ越しました - BBSakura Networks Blog

と決意表明がされています。

~ 5 月

この時期は、公開社内勉強会の開催について、社外イベントに参加したことについての記事などが公開されています。

これらの記事は、私を含め、社外発信経験のある技術広報チームメンバーが頑張って書いていました。

6 月

しかし、技術広報チームメンバーだけが頑張るのではなく、もっと全社で取り組める持続可能な形にしたかったし、そのほうが BBSakura が扱っているさまざまな技術について有意義な記事を書けると感じはじめ、作戦会議を開きました。

また、BBSakura の注力プロダクトである OCX の開発に携わるメンバーが技術広報チームにいないことも課題に感じていたため、OCX の開発に携わっていて、かつ、対外発信活動を支援したい想いを持っていたメンバーを技術広報チームに誘って加入してもらいました。

この作戦会議とメンバー追加を経てそれ以降の執筆支援体制ができ上がってきました。

いまは月に 1 回技術広報チームの定例会を開き、その中でブログに書けそうなネタのリストアップと執筆の適任者探しをしています。適任と思うメンバーにそのネタについての執筆依頼を行い、書いてもらう、というサイクルです。

このやりかたでこの時期以降は月に 2 記事ぐらいずつ公開を続けられています。

うまく回りだすまでの試行錯誤を経ていま実践している工夫を、以下に紹介します。

継続のために工夫していること

書くハードルを下げる工夫

技術広報チームの活動を知ってもらう

会社として対外発信活動を推進しているんだということを社員みんなに知ってもらうことで、ブログ執筆の依頼もしやすくなるだろうと考えました。

週 1 回各プロジェクトからの進捗報告が行われる全社定例の時間で、技術広報チームも時間をもらって活動報告をするようにしました。

「こんな記事が公開されました」、「次はこういう内容の記事を依頼中です」など、毎週アップデートを全社にお伝えしています。依頼中の記事について「この人にお願いしています」と言うのはなんだか催促するように聞こえてしまうので、やめました。

毎週報告をしていることで、自発的に記事を書いてくれる人も出てくるし、執筆依頼したときのいきなり感も減っているのではないかと感じています。

書き方を周知する

ブログの書き方は、社内の情報蓄積ツール Kibela 上に記載して、毎週の報告のときに「ここを見て書いてください」と伝えています。

書きたくなったときに技術広報チームに書き方を問い合わせるところからスタートではハードルが上がってしまうので、情報をまとめて参照しやすい場所に置くようにしています。

依頼するときの工夫

ネタと適任者を探して依頼する

全体に対して「みんな書いてねー」と言って書いてくれる人はほんの一部の書き慣れている人だけでした。

この人に書いてほしいと思って名指しで「何か書いてよ」とお願いしても、依頼された人はネタを考えるところからのスタートになるため書くまでの道程が長くなってしまい、公開までなかなか至れませんでした。

そういううまくいかない依頼を経て、いまの、ネタを探してから適任者を探して依頼するスタイルにたどりつきました。

ネタを探すためには自分の携わっている業務だけでなく他部署の他プロダクトの動向にもアンテナを張っている必要があります。私は Slack のほぼ全てのチャンネルに参加して、機能リリース予定や技術トピックを追ってネタをストックしています。

いろんな人に依頼する

依頼する相手はなるべくいろんな人にしています。ただ記事数を増やすことだけを目的にしているのではなく、社内のエンジニアたちに対外発信経験を積んでほしい、そのメリットを感じてほしいという想いも持って活動しているので、新入社員や若手を中心に対外発信経験のすくないメンバーに積極的に声を掛けるようにしています。

それによって発信できる内容の幅が広がっているし、一度書いた人は今後も発信活動をしてくれて、その人の成長にも会社のアピールにもつながると思っています。

依頼しっぱなしにしない

依頼を引き受けてくれても、日々の業務が忙しいとブログ執筆のことは忘れられてしまいがちです。

引き受けてもらったあとは、ときどき状況確認をするようにしています。

ただ、急かされている・責められているというふうには捉えてもらいたくないので「急かしているわけじゃないんだけど、その後どうですか。今後の記事公開の計画の参考にしたいので状況教えてください。もし困ってることがあればいつでも声かけてください」というような聞き方をしています。

何度か声を掛けているとだんだんみんな「○日ごろまでに構成を作ります」、「今月中に第 1 稿書けます」などと自分で期日を切って進めてくれるようになってきます。

ときどきリマインドなしですぐに書き上げてくれる人もいて、依頼したこちらがびっくりすることもあります。

引き受けてもらえなくても落ち込まない

それぞれ業務があるなか別のことを依頼しているので、依頼を断られることも当然あります。落ち込んだりせず、「また今度タイミング合うときにお願いします!」で終わりです。

記事レビューの工夫

細かい指摘をしすぎない

未リリースの案件などの出してはいけない内容、利用する画像などの権利、大きな誤字脱字、意味が違って捉えられそうな箇所などは必ず指摘しますが、文体や接続詞の使い方などの細かいところ、記事の構成や内容の取捨選択などの根本的なところは執筆者の個性でもあるので、求められない限りはあまり指摘しない方針です。

細かいところまで指摘しすぎると、次回書く気が起きなくなってしまうからです。

また、公開完了後に執筆者にレビューの感想を聞いてチーム内で対応を見直すこともしています。

良かった点を伝える

せっかく書いてくれた文章に対して修正箇所の指摘だけを行うのはモチベーションが下がるかもしれないと思って、書いてくれた感謝・感想・良かったところをまず伝えるようにしています。

執筆者がどう感じているかはわかりませんが、ブログ記事を書くことがすこしでも良い体験だったと感じてもらえるといいなと思ってやっています。

連載企画

8 月から「#OCXを支える技術」という連載企画をやっています。

会社の注力プロダクトである OCX をアピールしてほしいという社長のコメントがあったこと、OCX 開発に関わるメンバーから「OCX で使われている技術についてシリーズ化するとよさそう」というコメントがあったことで連載がスタートしました。

連載を始めるにあたって開発メンバーに集まってもらってどういう視点で切り取れるか相談する会を開きました。技術広報メンバーだけではシリーズ化できるほど細かい切り口を見つけられなかったので、現場で開発しているメンバーに協力してもらえたのはとても助かりました。

情報を出せる時期、メンバーの手が空きそうな時期を見ながら、ある程度のペースで出せるように依頼していっています。

番外編: アクセシビリティの理解推進

工夫とはちょっと違うのですが私が企業公式ブログを運営するにあたって気にしていることのひとつにアクセシビリティがあります。

画像には代替テキストをつける、画像の色にコントラストをつけるなど、なるべく多くの人に情報を届けられる記事にするための意識をしています。

アクセシビリティについても Kibela ページに記載しているのですが執筆時点ではそれらを気にしていない人も多いので、レビューのときに修正をお願いしています。

アクセシビリティをみんなに意識してもらえるよう推進したいという想いがあるので、私が勝手に代替テキストをつけるのではなく、執筆者本人に、どういうテキストをつければ音声のみでも伝わるのか考えてもらうようにしています。

おわりに

技術ブログの更新を継続できるようになるまでの道のりと、継続のために行っている工夫についてお伝えしました。

技術広報チームはブログの運営だけでなく、登壇支援や公式 SNS アカウントの運営なども行っています。

これらの活動を通して私は会社のことをよりよく知れる 1 年だったなと感じています。

どのプロダクトで、いつ、どんな機能がリリースされるのか。どんなプレスリリースを出すのか。社内のエンジニアそれぞれが、どんなプロダクトのどの分野で、どんな機能を開発しているのか、運用しているのか。どういう考え、主義主張を持って仕事しているのか。各プロダクトではどんな技術が使われているのか、どんな挑戦があるのか。

自分の担当業務を行っているだけでは触れなかったであろう情報、キーワードがたくさん出てくるし、ふだん関わる機会のないメンバーとも会話できるきっかけになり、すごくワクワクする活動です。

自分が本業で担当している開発についても、会社全体の戦略の中でどこに位置していて他のなにと強く関係するのか、理解が深まったと感じています。

企業ブログの運営をしている人、技術広報担当者、社外への発信をしていきたい人たちに、なにか参考になったり、楽しそうと思ってもらえたりしたら嬉しいです。

明日からも毎日アドベントカレンダー記事が投稿される予定ですので、引き続き楽しみにお待ちください!

adventar.org

OCXハンズオン 〜マルチクラウドと閉域接続を取り入れた口コミ投稿サイトを作ろう!〜

はじめに

こんにちは!BBSakura NetworksでOCXのバックエンド開発をしている秋山です。
OCXとはBBSakura Networksが提供している、オンデマンドで閉域網を構築できるネットワークサービスです。
OCXの詳細や仕組みなどは以下の記事にて解説しています。

blog.bbsakura.net

OCXはより使いやすく、より多様なネットワークの構築ができるように日々アップデートを重ねており、先日新たなクラウドの接続先としてOracleの提供を開始しました。
本記事ではOCXの使い方の一例として、Amazon Web Services (AWS)と新たに追加されたOracle Cloud infrastructure(OCI)を閉域接続する手順について解説します。記事の終盤では各インスタンスを実際に動かし、クラウド間閉域接続を取り入れた簡単な口コミ投稿サイトの作り方についても解説します。

構成

本記事では最終的に以下のような構成を作ります。AWSのインスタンスとOCIのインスタンスを閉域網で疎通できるようにします。 今回の構成はあくまで一例であるため、環境によって適宜入力項目を書き換えて下さい。

AWS、OCI、OCX間のネットワーク構成。AWSのVPCにはInternetGatewayとVGWがあり、パブリックサブネット内にインスタンスが存在している。OCIのVCNにはDRGがあり、パブリックサブネット内にインスタンスが存在している。OCXにはCloudConnectionとOCXRouterがあり、AWSとOCIを繋いでいる。

目次

本記事は以下の順番で説明をします。
本記事ではAWS、OCI、OCXそれぞれのアカウント設定(IAMやコンパートメントなど)は完了していることを前提としています。

  • 0. 下準備(AWSとOCIの内部ネットワーク構築)
    • このセクションではAWSとOCIの内部ネットワークの構成手順について解説します。OCXとの接続は次のセクションで行うため、OCXとの接続方法だけを知りたい方、既に内部ネットワークを構築済みの方は読み飛ばして下さい。
  • 1. OCXの活用(CloudConnectionとOCXRouterを用いた閉域網構築)
    • このセクションではOCXポータルを用いてOCX内で閉域網を構築する手順や各クラウドとOCXを繋ぐ手順について解説します。
  • 2. webサーバ及びDBサーバの構築
    • 各クラウドに作ったインスタンスを実際にwebサーバ、DBサーバとして動かしてみます。OCXでの操作等はなく、できるものもおまけ程度なので読み飛ばしても大丈夫です。

0. 下準備(AWSとOCIの内部ネットワーク構築)

AWSの構築手順

AWSコンソールを操作し、以下のようなネットワークを作ることを目指します。

AWSの最終的に目指すべきネットワーク構成図。VPCにInternetGatewayとVGWがあり、VPC内のパブリックサブネット内にインスタンスがある。

VPCの作成

まずAWSコンソールからVPCを作成します。

AWSのVPC構成図。InternetGatewayがアタッチされたVPCを作成する。

  1. AWSコンソールで「VPC」と検索し、VPCの作成を押します。 AWSコンソールでVPCを作成を押す
  2. 以下の情報を参考に、VPCを作成します 。 VPCの詳細入力をする

      作成するリソース:VPCなど
      名前タグの自動生成:自動生成有効、ocx-techblog
      IPv4CIDRブロック:10.30.0.0/16
      IPv6CIDRブロック:IPv6 CIDR ブロックなし
      テナンシー:デフォルト
      アベイラビリティゾーン (AZ) の数 :1
      パブリックサブネットの数:1
      プライベートサブネットの数:0
      ap-northeast-1a のパブリックサブネット CIDR ブロック:10.30.0.0/24
      NAT ゲートウェイ:なし
      VPC エンドポイント:なし
      DNSオプション:両方有効
    

インスタンスの作成

先ほど作成したVPC内にインスタンスを作成します。

AWSのEC2構成図

  1. AWSコンソールで「EC2」と検索し、インスタンスを起動を押します。

    AWSコンソールでインスタンスを起動を押す

  2. 以下の情報を参考に、インスタンスを起動します。 インスタンスの詳細入力をする

     名前とタグ:ocx-techblog-webserver
     アプリケーションおよび OS イメージ (Amazon マシンイメージ):
     クイックスタート→Amazon Linux→Amazon Linux 2 AMI (HVM), Kernel 5.10 x86_64
     インスタンスタイプ:t2.micro
     キーペア:新しいキーペアの作成
     ネットワーク設定:編集ボタンを押す
       VPC :(ocx-techblog-vpc)を選択
       サブネット: ocx-techblog-subnet-public
       パブリック IP の自動割り当て:有効化
       ファイアウォール (セキュリティグループ):セキュリティグループを作成する
       セキュリティグループ名:ocx-teckblog-sg
     それ以下の項目:デフォルトのまま
    

    なお、インスタンスのキーペアは以下のように作成し、ダウンロードしておきます。 インスタンスのキーペアを作成する。名前はocx-techblog、キーペアのタイプはRSA、ファイル形式にpemを指定する。

  3. インスタンスを作成したら、インスタンスの詳細から「セキュリティ」→「セキュリティグループ」と移動します。 インスタンスのセキュリティグループにアクセスする

  4. セキュリティグループの詳細からインバウンドルールのインバウンドルールを編集を押し、全てのソースからのSSH、ICMP、HTTPアクセスを有効にします。 セキュリティグループのインバウンドルールを編集を押す インバウンドルールを設定

仮想プライベートゲートウェイの作成

VPC内にさらに仮想プライベートゲートウェイを作成します。

AWSのVGW構成図。作ったVPCにVGWをアタッチすることを目指す。

  1. AWSコンソールで「Direct Connect」と検索して「仮想プライベートゲートウェイを作成する」を押し、以下を参考に作成します。この時、リージョンが作りたい場所を指しているかに注意します。 AWSコンソールで仮想プライベートゲートウェイを作成を押す

     名前タグ:ocx-techblog-vgw
     自律システム番号 (ASN):Amazon デフォルト ASN
     タグ:デフォルトのまま
    
  2. 作成した仮想プライベートゲートウェイを選択し、「アクション」から「VPCへアタッチ」を選択します。アタッチ先には自分のVPCを指定します。
    作成後は仮想プライベートゲートウェイの詳細からASNを確認します。 仮想プライベートゲートウェイをVPCにアタッチ

OCIの構築手順

OCIコンソールを操作し、以下のようなネットワークを作ることを目指します。

OCIで作る予定のネットワーク構成図。VCNにInternetGatewayとDRGがアタッチされ、VCN内のパブリックサブネットにインスタンスが置かれている。

VCNの作成

まずOCIコンソールからVCNを作成します。

OCIのVCN構成図。InternetGatewayがアタッチされたVCNを作成する。

  1. OCIコンソールで「VCN」と検索し、「Start VCN Wizard」を押し、Create VCN with Internet Connectivityを選択します。 AWSコンソールでStart VCN Wizardを押す

  2. 以下の情報を参考に、VCNを作成します。

     名前タグ:ocx-techblog-vgw
     自律システム番号 (ASN):Amazon デフォルト ASN
     タグ:デフォルトのまま
    
  3. VCNの詳細からパブリックサブネットの詳細を選択します。 パブリックサブネットの詳細を見る

  4. セキュリティリストの詳細からイングレスルールの追加を押し、全てのソースからのSSH、ICMP、作成したAWSVPCのアドレスからのMySQLアクセスを有効にします。 セキュリティリストの詳細を見る イングレスルールの編集を押す

インスタンスの作成

先ほど作成したVCN内にインスタンスを作成します。

OCIのVM構成図。作成したVCNのパブリックサブネット内にインスタンスを設置する。

  1. OCIコンソールで「インスタンス」と検索し、インスタンスの作成を押します。 OCIコンソールでインスタンスの作成を押す

  2. 以下の情報を参考に、インスタンスを起動します。 インスタンスの詳細入力をする

      Name: instance-20231005-ocx-techblog
      Create in compartment: 自分のCompartment
      Placement: AD1(Tokyo-1)
      Shielded instance: Disabled
      Image: Oracle Linux 8
      Shape: VM.Standard.E4.Flex(デフォルト)
      VNIC name: なし
      Primary network: Select existing virtual cloud network
      VCN in 自分の :ocx-techblog
      Subnet: Select existing subnet
      Subnet in 自分の: ocx-techblog-public
      Private IPv4 address: Automatically assign private IPv4 address
      Public IPv4 address: Automatically assign public IPv4 address
      Add SSH keys: Generate a key pair for me→Save private keyからダウンロード
      その他項目:デフォルトのまま
    

DRGの作成

VCN内にさらにDynamic Routing Gateway(DRG)を作成します。

OCIのDRG構成図

  1. OCIコンソールで「DRG」と検索して「ダイナミックルーティングゲートウェイの作成」を押し、作成します。 AWSコンソールでダイナミックルーティングゲートウェイを作成を押す
  2. 作成したDRGの詳細を選択し、作成したVCNへのアタッチメントの作成を行います。 AWSコンソールでVCNアタッチメントの作成をする

1. OCXの活用(CloudConnectionとOCXRouterを用いた閉域網構築)

AWSとOCI内にそれぞれ、以下のような基本的な構成を持っているとします。

これまでの手順で作成したAWS、OCIリソースの各種Gatewayとインスタンスがある。
それぞれのネットワークはインターネットへの疎通性があるため、サーバ間をインターネット経由で接続することが可能です。 しかし、ビジネスやシステムの要件が高まるにつれ、BGP経路ジャックやDDoS攻撃など、インターネット経由の接続がリスクを伴う可能性が増してきます。 このような背景を考慮して、OCXはインターネットを介さない閉域網をオンデマンドで構築・提供するサービスを提供しています。このセクションではOCXポータルから実際に閉域網を構築し、その閉域網とクラウド間を接続する手順について説明します。

AWSとの接続

OCX及びAWSのコンソールを操作し、以下のようなネットワークを構築することを目指します。

AWS接続後のOCXネットワーク。AWSで作成した環境をOCXネットワーク内に引き込む。DirectConnectで物理的につながっているので、CloudConnectionを用いて論理的に制御する。

Cloud Connectionの作成

OCXポータルからCloud Connectionを作成し、AWSとの接続を行います。

OCXのCloud Connection作成

  1. OCXポータルのメニューから「Cloud Connection」→「Create」→「AWS」を選択します。 OCXのCloud ConnectionからAWSを選択

  2. ロケーション、名前、速度を入力して次へを押します。 AWS Cloud Connectionの詳細入力をする

  3. AWS Account IDを入力します。 AWS Cloud ConnectionにAWS Account IDを入力する

  4. 各項目を確認したら作成します。 AWS Cloud Connection作成前に各項目を確認

  5. AWSコンソールからDirect Connectの「接続」を確認し、先ほど作成したCloud Connectionと同じdxconのIDを持つ回線の詳細へ移動します。 AWSコンソールからAWS Direct Connectの接続回線を承認する

  6. 接続を承認します。 Direct Connectで接続の承認を行う

  7. 承認完了後、その回線の仮想インターフェース(VIF)を作成します。 AWSの回線にVIFを作成する

  8. 以下を参考にVIFの各項目を入力します。

     仮想インターフェイスのタイプ:プライベート
     仮想インターフェイス名: ocx-techblog-vif
     接続:デフォルト(CC指定のsiteと一致しているか確認)
     仮想インターフェイスの所有者:自分の AWS アカウント
     ゲートウェイタイプ:仮想プライベートゲートウェイ
     仮想プライベートゲートウェイ:ocx-techblog-vgw
     Virtual Local Area Network (VLAN):2
     BGP ASN:65000
     追加設定
     アドレスファミリー:IPv4
     ルーターのピア IP:10.128.30.1/24
     Amazon ルーターのピア IP:10.128.30.2/24
     BGP 認証キー:helloocx
     その他項目:デフォルトのまま
    
  9. ピアリング設定が作られていることを確認します。 AWSVIFのピアリング設定を確認する

OCX Routerの作成

OCX内にOCX Routerを作成し、BGPセッションの準備をします。

OCX Router構成図。OCX内にOCX Routerを作成する。この時、OCX RouterはRouterインスタンスなので、別途CLoudConnectionとの疎通は行わなくてはならない。
1. OCXポータルのメニューから「OCX Router(v1)」→ +マークを選択し、以下を参考にOCX Routerのインスタンスを作成します。 OCXポータルからOCX Routerを作成する 2. 各項目を確認して作成します。 OCX Routerの入力項目を確認して作成する 3. OCX Routerのインスタンスを選択し、「Create Interface」を選択し、Local IPv4 Addressに10.128.30.1/24を指定してOCX RouterのInterfaceを作成します。 OCX RouterのInterfaceを作成する 4. 各項目を確認して作成します。 OCX Router Interfaceの各項目を確認して作成する 5. 作成したOCX RouterのInterfaceを選択し、「BGP Parametersタブ」からBGP Parameterの作成をします。 OCX RouterのBGP Parameterを作成する 6. 以下を参考にOCX RouterのBGP Parameterを作成します。 OCX Router BGP Parameterの各項目を確認して作成する

Virtual Circuit(VC)の作成

OCX内に作ったOCX RouterとCloud Connection間をVCを使って接続し、BGPセッションを確立します。

OCX、AWS間のBGPセッション構成図。OCXRouterとCloudConnectionを繋ぎ、OCXRouter-AWSVGW間の疎通を作る。
1. OCXポータルのメニューから「Virtual Circuits(VCs)」→「Create」を選択し、名前を入力し作成します。 OCXポータルでVCを作成する 2. 作成したVCのアタッチアイコンを選択します。 VCのアタッチアイコンを選択する 3. VCのアタッチ先としてCloud Connectionを選択します。 VCのアタッチ先にCloud Connectionを選択する 4. 表示されるCloud Connection一覧から先ほど作ったAWSのCloud Connectionを選択し、VCにアタッチします。 Cloud Connection一覧から先ほど作ったAWSのCloud Connectionを選択 5. 同じようにして「VCのアタッチアイコン」→「OCX Router(v1)」→「先ほど作ったOCX RouterのInterface」を選択し、OCX Router InterfaceをVCにアタッチします。 VCのアタッチ先にOCX RouterのInterfaceを指定 6. しばらく待ってから。AWSコンソールからDirect Connectの「仮想インターフェース」を確認し、ピアリングのステータスがupになっていることを確認します。 AWSのピアリングステータスを確認する

OCIとの接続

OCX及びOCIのコンソールを操作し、以下のようなネットワークを構築することを目指します。
AWSとの接続は先にOCXでCloud Connectionを作り、AWSコンソールでそれを承認し、VIFを作る方式でした。
OCIとの接続は先にOCIコンソールでFastConnectを作り、Cloud Connectionを作った際に接続するという方式になります。 OCXとクラウドとの接続方法はクラウド事業者によって方式が変わるため、注意が必要です。

AWS、OCI、OCX間のネットワーク構成。OCIからOCXまでも疎通させ、最終的なOCXを通じてAWSとOCIがつながっている構成を作る。

FastConnectの作成

OCIコンソールからFastConnectを作成し、OCXネットワークとの接続準備を行います。

OCX、OCI間のFast Connect構成図。FastConnectを作成し、OCI側に接続口を作成する。

  1. OCIコンソールから「FastConnect」と検索し、作成を押します。 OCIコンソールでFast Connectの作成を押す

  2. ConnectionタイプにFastConnectPartner、PartnerにBBIX Multi-Cloud Serviceを選択して、次へを押します。 FastConnect作成画面でパートナーを指定する

  3. 以下を参考に情報を入力し、FastConnectを作成します。 FastConnectの詳細入力をする

      Name: ocx-techblog
      Compartment: 自分の
      Virtual circuit type: Private virtual circuit
      Traffic: All traffic
      Dynamic routing gateway in 自分の: ocx-techblog-drg
      Provisioned bandwidth: 1Gbps
      Customer BGP IPv4 address: 10.128.40.1/30
      Oracle BGP IPv4 address: 10.128.40.2/30
      Customer BGP ASN: 65000
      Use a BGP MD5 authentication key: 有効
      BGP MD5 authentication key: worldocx
      その他項目: デフォルトのまま
    
  4. 作成したFastConnectの詳細から、OCIDとASNを確認します。 FastConnect詳細からOCIDとASNを確認する

Cloud Connectionの作成

OCXポータルからCloud Connectionを作成し、OCIとの接続を行います。 OCX、OCI間のCloudConnection構成図。OCX内にCloudConnectionを作成し、OCXとOCIを論理的に繋げる。

  1. OCXポータルのメニューから「Cloud Connection」→「Create」→「Oracle」を選択します。 OCXのCloud ConnectionからOracleを選択
  2. ロケーション、名前、速度を入力して次へを押します。 Oracle Cloud Connectionの詳細入力をする

  3. 先ほど作成したFastConnectのOCIDを入力し、各項目を確認したら作成します。 OCIDを入力する

  4. OCIコンソールに移動し、作成したFastConnectのStatusが「Provisioning」もしくは「Provisioned」になっていることを確認します。

OCX RouterのInterfaceを作成し、BGPセッションを確立

AWSとの接続に用いたOCX Routerのインスタンスに、新たに作成したInterfaceとVCと組み合わせることでBGPセッションを確立します。

AWS、OCI、OCX間のネットワーク構成。AWSのVPCにはInternetGatewayとVGWがあり、パブリックサブネット内にインスタンスが存在している。OCIのVCNにはDRGがあり、パブリックサブネット内にインスタンスが存在している。OCXにはCloudConnectionとOCXRouterがあり、AWSとOCIを繋いでいる。

  1. AWSと接続するのに利用したOCX Routerのインスタンスの「+マーク」→「Primary Interface作成」を選択し、以下の情報を参考にOCX Router Interfaceを作成します。 OCI接続用のOCX Router Interfaceを作成する。Nameは任意、LocalIPv4Addressは10.128.40.1/30を指定する。
  2. 作ったOCX Router Interfaceから「BGP Parametersタブ」→「BGP Parameter作成」を選択し、以下の情報を参考にBGP Parameterを作成します。 OCX RouterのBGP Parameterを作成する。Local Addressは10.128.40.1、Remote Addressは10.128.40.2、Remote ASNは31898、MD5 Auth Keyはworldocx、その他項目はデフォルトのままで入力
  3. OCIとの接続に使うVCはAWSとの接続に使ったVCとは違う回線に当たるため、VCを新たに作成します。OCXポータルのメニューから「Virtual Circuits(VCs)」→「Create」を選択し、名前を入力し作成します。 OCXポータルでVCを作成する
  4. VCに先ほど作成したOracle Cloud ConnectionとOCX Router Interfaceをアタッチします。 VCにOracle Cloud Connectionをアタッチ VCにOracle用OCX Router Interfaceをアタッチ
  5. しばらく待ってからOCIコンソールに移動し、接続したFastConnectのピアリングステータスがupになっていることを確認します。 FastConnectのピアリングステータスを確認する

ルートテーブルの編集と疎通確認

ここまででOCXを用いてAWSとOCIを閉域網で接続する方法を確認しました。最後に特定の通信が構築した閉域網を通るようにルートテーブルを編集し、疎通確認をします。

AWSでの設定

  1. AWSコンソールに移動し、作成したAWSインスタンスの詳細からパブリック、プライベートIPを確認します。 AWSインスタンスのパブリック、プライベートIPを確認する

  2. 同じくAWSコンソールから作成したVPCの詳細へ移動し、パブリックサブネットに紐づいているルートテーブルを選択します。 AWSVPCのルートテーブルを選択

  3. ルートの編集を選択し、OCI向けの通信はVGWを通るようにルートを追加します。 VGWへのルートを追加する

OCIでの設定

  1. OCIコンソールに移動し、作成したOCIインスタンスの詳細からパブリック、プライベートIPを確認します。 OCIインスタンスのパブリック、プライベートIPを確認する

  2. 同じくOCIコンソールから作成したVCNの詳細へ移動し、ルートテーブルを選択します。 OCIVCNのルートテーブルを選択

  3. ルートの編集を選択し、AWS向けの通信はDRGを通るようにルートを追加します。 DRGへのルートを追加する

ログインと疎通確認

  1. AWSとOCIのインスタンスを作った際にダウンロードした秘密鍵を~/.sshへコピーします。ターミナルを開き、以下のコマンドを順番に入力します。yyyy-mm-ddは鍵の名称に合わせて入力して下さい。

     cd Downloads/
     cp ocx-techblog.pem ~/.ssh
     cp ssh-key-yyyy-mm-dd.key ~/.ssh
     cd ~/.ssh
    
  2. 以下のコマンドを入力し、AWSインスタンスにログインして疎通確認を行います。各IPアドレスは各自で前セクションで確認したものを使用します。

     sudo ssh ec2-user@X.X.X.X -i ocx-techblog.pem
     sudo su
     yum update –y
     ping 10.40.0.185
    

    以下の画像のように疎通していることが確認できると思います。

    AWSからOCIへの疎通確認

  3. OCIのインスタンスでも同様に行います。

まとめ

今回はOCXを用いて2つのクラウドサービス間をつなぐ閉域網の構築を行いました。OCXは物理的な工事の手配や発注からのリードタイムが短いことが特徴として挙げられており、ここまでの実際の作業も1時間以内に終わらせることができます。
Cloud Connection、OCX Router、VCを始めとした様々なリソースを組み合わせて自由に構築を行えることも特徴で、本例ではOCX Routerを1インスタンスしか使っていませんが、2インスタンス使った冗長構成を作ることも可能なので是非お試しください。

2. webサーバ及びDBサーバの構築

ここでは、実際に口コミサイトを作るという体でAWSのインスタンスをwebサーバ、OCIのインスタンスをDBサーバとして利用します。
インターネットを通じたユーザからのhttpアクセスに対しwebページを表示し、webページに入力された口コミはOCXで構築した閉域網を通じてDBへ登録されるという仕組みになります。このようにアプリケーションレイヤとデータベースレイヤを分け、その間にインターネット経由でないプライベートな接続を用意してあげることで、セキュリティリスクの軽減や帯域確保による動作の向上が期待できます。 AWS、OCI、OCX間のネットワーク構成。AWSのVPCにはInternetGatewayとVGWがあり、パブリックサブネット内にインスタンス(webサーバ)が存在している。OCIのVCNにはDRGがあり、パブリックサブネット内にインスタンス(DBサーバ)が存在している。OCXにはCloudConnectionとOCXRouterがあり、AWSとOCIを繋いでいる。

OCIインスタンスでの設定

まず最初にOCIインスタンスをMySQLサーバとして利用できるように設定を行います。

MySQLのインストールと設定

  1. 以下のコマンドを実行してMySQLのインストールを行います。sudo suのsuperuser権限はこれ以降の手順でも適用します。

     sudo su
     yum module install mysql:8.0/server –y
    
  2. 以下のコマンドを実行してMySQLのコンフィグファイルを開きます。

     cd /etc/my.cnf.d
     nano mysql-server.cnf
    
  3. [mysqld]の項目に以下を追加して保存します。

     character-set-server=utf8
     collation-server=utf8_unicode_ci
     bind-address = 0.0.0.0
    
  4. ファイアウォールの設定をします。

     firewall-cmd --add-port=3306/tcp –permanent
     firewall-cmd --reload
    
  5. MySQLを実行し、ログインします。

     systemctl start mysqld
     systemctl enable mysqld
     mysql -u root
    
  6. 以下のSQLコマンドを実行し、データベースとユーザの設定をします。awsuserとAwsuser00$$はユーザとパスワードに当たるので、好きなものを設定して下さい。

     create database sampledb;
     use sampledb;
     CREATE TABLE userdata (
          id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
          username VARCHAR(50),
          message TEXT
     );
     CREATE USER 'awsuser'@'10.30.0.66' IDENTIFIED BY 'Awsuser00$$';
     GRANT ALL PRIVILEGES ON sampledb.* TO 'awsuser'@'10.30.0.66’;
     FLUSH PRIVILEGES;
    
  7. OCI側の設定は完了したため、ルートテーブルを以下のように設定し、インターネットとの疎通性をなくします。こうすることで、MySQLサーバを擬似的にプライベートサブネット内に置きます。 OCIのルートテーブルを編集してインターネット疎通性をなくす

AWSインスタンスでの設定

次にAWSインスタンスをwebサーバとして利用できるように設定を行います。

MySQLのインストールと疎通確認

  1. 以下のコマンドを実行してMySQLのインストールを行います。sudo suのsuperuser権限はこれ以降の手順でも使います。

     sudo su
     yum localinstall https://dev.mysql.com/get/mysql80-community-release-el7-5.noarch.rpm -y
     yum install mysql-community-server –y
    
  2. 以下のコマンドを実行して、OCXで構築した閉域網を通じて、OCI側のMySQLサーバにアクセスできるか確認します。パスワードを聞かれるので、設定したものを入力します。MySQLにログインできることを確認したらquitコマンドから切断します。

     mysql -u awsuser -h 10.40.0.185 –p
    
  3. 以下のコマンドを実行してapacheのインストールを行います。

     yum install httpd –y
     yum install php php-mysql -y
    
  4. 以下のコマンドからapacheを実行します。

     systemctl start httpd
     systemctl enable httpd
    
  5. AWSインスタンスから確認できるパブリックIPにhttpでアクセスします。http://X.X.X.Xにアクセスしてapacheの初期画面が表示されたら成功です。httpsではアクセスできないので注意して下さい。 AWSインスタンスのパブリックIPを確認

  6. 以下のコマンドを実行し、index.phpを作成、編集します。

     cd /var/www/html
     nano index.php
    
  7. index.phpに以下をペーストして保存します。$host, $user, $passにはそれぞれOCIインスタンスのプライベートIP、設定したユーザとパスワードを入力します。

     <?php
     $host = '10.40.0.185';
     $db   = 'sampledb';
     $user = 'awsuser';
     $pass = 'Awsuser00$$';
     $charset = 'utf8mb4';
    
     $dsn = "mysql:host=$host;dbname=$db;charset=$charset";
     $options = [
         PDO::ATTR_ERRMODE            => PDO::ERRMODE_EXCEPTION,
         PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
         PDO::ATTR_EMULATE_PREPARES   => false,
     ];
    
     if ($_SERVER["REQUEST_METHOD"] == "POST") {
         $username = $_POST["username"];
         $message = $_POST["message"];
    
         try {
             $pdo = new PDO($dsn, $user, $pass, $options);
             $stmt = $pdo->prepare("INSERT INTO userdata (username, message) VALUES (?, ?)");
             $stmt->execute([$username, $message]);
             echo "Data saved successfully!";
         } catch (\PDOException $e) {
             throw new \PDOException($e->getMessage(), (int)$e->getCode());
         }
     }
     ?>
    
     <form action="index.php" method="post">
         Username: <input type="text" name="username"><br>
         Message: <textarea name="message"></textarea><br>
         <input type="submit" value="Submit">
     </form>
    
  8. 以下のコマンドを実行して、apacheを更新します。

     systemctl restart httpd
    
  9. AWSインスタンスから確認できるパブリックIPにhttpでアクセスします。http://X.X.X.Xにアクセスして以下の画面が出てきたら成功です。 apacheで設定したwebページ

  10. usernameとmessageを入力してsubmitボタンを押すと、以下のようにデータベースに情報が登録されることを確認します。 DBに口コミが投稿されていることを確認する

OCXを支える技術 #3 OCX - Cloud Connectionの技術説明、クラウド接続プロバイダは何をやってる?

記事をご覧頂きありがとうございます!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%を超える通信量が必要

こういった考慮点が 「各クラウド毎に異なる形で存在」します。そのため、情報の整理は非常に重要ですし、日々のリソース状況を監視する必要もあります。

また、ガチガチに設計してしまうと、クラウド側の仕様変更時に動けなくなります。 この辺の塩梅も日々苦労しております。

お客様論理回線の接続仕様を把握

現在のクラウド直接接続の多くは IEEE802.1Q(通称:VLAN または dot1qなど)での接続がほとんどです。 ですので、VLANを用いたL2通信に関わったことのある方はイメージしやすいと思います。クラウドとの接続としてやっていることは意外とシンプルです。

この部分について、もう少し深掘りしたいと思います。 説明のために、"Cloud Connection"にてクラウド接続を行い、その通信をお客様設備(CPE)までL2通信する際の簡単な図を書いてみました。

※以降の通信まわりの技術名称は、筆者が呼び慣れてる通称の呼び方で説明します。

dot1qの対応

dot1q の設定の流れを示した図
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"まわりについては、ユースケースを用いたリソース解説として弊社メンバーがまとめてくれています。よかったら是非見てください!

blog.bbsakura.net

Azure QinQへの対応

なお現状1クラウドだけ唯一他クラウドと違う仕様があり、AzureのみIEEE802.1Qトンネリング(通称:ダブルタグVLAN または QinQなど)での接続仕様となっています。これによりAzureは上記図とは異なる通信になります。

"Cloud Connection"ではここの違いをシンプルにすべく、Azureとの接続については シングルタグ化オプション を実装しました。

www.bbsakura.net

この実装については、以前社外勉強会を行った際に詳しく説明してますので、よかったら是非見てください!

speakerdeck.com

クラウド側リソースとの連携

お客様論理回線の接続仕様について大まかに説明をしましたが、対応が必要なのはOCX側設備だけではありません。クラウド側のリソースの作成や削除もOCXシステムから連携し対応する必要があります。

クラウド側リソースへの連携を理解するには、以下の2つの違いについて明確に理解する必要があります。

  • クライアントが所有するクラウドアカウントを経由したAPI/SDK実行
  • プロバイダが所有するクラウドアカウントを経由したAPI/SDK実行

クラウド側リソースへの連携の考え方

1つ例を交えて説明します。 あなたは自分のクラウドアカウントに対して外部環境から自動化を検討する際、以下のようなことを検討すると思います。

  • 自動化しようと思っているコンポーネントにて用意されているクラウド側API/SDKの選定と仕様の把握
  • 選定したAPI/SDKに対して外部環境から操作できるようにするために、アクセス権限の把握&付与
  • アクセス権限を利用するためのアクセストークンの発行方法を調べ、それに従い外部環境からアクセストークン発行のプログラムを構築

こういったことを検討し、準備することで外部環境からクラウド側API/SDKを操作する仕組みを作ることができます。 図にしてみるとこのような感じ。

クラウドAPI連携の例1
クラウドAPI連携の例1

では似たようなことをプロバイダの立場で、不特定多数のクライアントに対して行う場合を考えてみましょう。

この場合、困難なのはアクセス権限の付与、およびアクセストークンの発行になります。

クライアントのクラウドアカウント上に、プロバイダが操作できるようアクセス権限付与&アクセストークンの発行してもらうのもありかもしれませんが、管理や作業の手間を考えるとクライアントにもプロバイダにも負荷が高く現実的ではありません。 図にしてみるとこのような感じ。

クラウドAPI連携の例2
クラウドAPI連携の例2

そういった問題を解決するために、各クラウドには「プロバイダのクラウドアカウント上で直接接続をある程度制御できる、プロバイダ向けAPI/SDK」を用意してくれてます。 プロバイダ向けAPI/SDKに、お客様リソースを判断できるパラメータ(AWSアカウントID, サービスキー, ペアリングキー etc...)を渡すことで、プロバイダ環境から一元的に各お客様に対して制御ができるようになります。 図にしてみるとこのような感じ。

クラウドAPI連携の例3
クラウドAPI連携の例3

プロバイダとクライアント間の承認の仕組み

ここで1つの疑問が出てきます。それは「プロバイダであればクライアントに対して問答無用にリソース作成や削除ができてしまうのか」ということです。 結論を先にいうと「No」になります。 この辺はちゃんとできていて、以下2つのどちらかの仕組みにて問題を解決しています。

  • 事前にお客様にて必要作業を行った際にランダムな文字列で発行されるキー(サービスキー, ペアリングキー)を用いて、その文字列を知っているプロバイダであれば特定の操作ができる
    • キーの情報共有そのものを承認行為とするイメージ
  • プロバイダがクライアントのクラウドアカウントに対して操作を行った際、クライアント側で承認プロセスを実行してもらう
    • 承認プロセスがクラウド上の仕組みとして存在するイメージ

このような仕組みにより、プロバイダ、クライアント、それぞれの立場で安全に連携することが可能となるわけです。

なお、クラウド側リソースとの連携についても当然、各クラウド毎に仕様が大きく異なります。 プロバイダ専用のクラウドアカウントの管理も必要になりますので、各クラウドに関する広い知識が必要になってきます。

まとめ

総じて重要なことは、 「お客様が使いたいときに使えるよう色んなことを先回りをして、難しいことをシンプルな形で提供する」ということに尽きる思います。 そのためには、ネットワークの基礎+上記で説明したような内容を各クラウド毎に理解する必要があります。

またサービスとして提供するためには、これらの理解だけでは足りません。その先のクラウド側ネットワーク(VPC/VNetなど)やオンプレミス側ネットワークを理解し、提供するサービスがどんな使われ方をするのかを把握しておく必要があります。

サービスを作っている立場として、OCXの"Cloud Connection"は以下のような機能としてシンプルで使いやすいものにしたいと思ってます。

  • クラウドへの直接接続が、ほしいときに、簡単に使えるサービスへ
    • イメージしやすい(非冗長なら"Cloud Connection"が1つ、冗長なら"Cloud Connection"が2つ)
    • 計算しやすい (OCXはトラフィック課金がない、初期費/月額費が固定で計算しやすい、日割り計算も適応)
    • 作成しやすい、削除しやすい

やらなければいけないことは沢山ありますが、日々できる限りのことを続けていき、より良い改善をしていきたいと思っています!

本記事について、いざ書き出すと内容がどんどん膨れ上がってしまい、長文になってしまいました、、、、 最後まで読んでいただきありがとうございました!

ユースケースで見る OCX リソース解説 「拠点からクラウドサービスへの接続」編

はじめに

こんにちは! BBSakura で基盤となるネットワークを開発している酒井です。

このブログ記事では、前回の 「拠点間接続」ユースケースの記事 に引き続いて、 OCX のもう 1 つの代表的なユースケースである「拠点からクラウドサービスへの接続」を通して OCX リソースについて解説します。

「拠点からクラウドサービスへの接続」ユースケースではお客さまのオンプレミス環境とパブリッククラウドを OCX のネットワークを介して接続します。このパブリッククラウドへの接続に必要な OCX リソースである Cloud Connection を詳しく解説していきます。

この記事の想定読者ですが、下記の技術について理解していることを前提としています。

  • パブリッククラウド

また、この記事では下記の内容で話を進めていきます。

  1. 前回のおさらい

    • 前回の記事で解説した、もっとも基本となる OCX リソースについておさらいします。
  2. パブリッククラウドへの接続

    • 本ユースケースが必要になる状況とその方法について簡単に説明します。
    • OCX を用いた接続の概要について説明します。
  3. Cloud Connection

    • OCX リソース Cloud Connection について概要と使い方について説明します。
  4. 冗長構成

    • 本ユースケースでお客さまに設計いただく OCX ネットワークの冗長構成について説明します。

1. 前回のおさらい

前回の 「拠点間接続」ユースケースの記事 では、「拠点間接続」ユースケースを通して Virtual CircuitPhysical PortVirtual Circuit Interface の OCX リソースについて解説しました。もし OCX を知ろうとされていて前回の記事をまだ読んでいない方は、先に前回の記事を読んでいただければと思います。

おさらいとして、前回解説したリソースについて簡単に説明します。

  • Virtual Circuit (VC) 1 つの L2 ネットワーク(ブロードキャストドメイン)に対応します。 OCX では VC へのアタッチ操作がその VC に対応した L2 ネットワークへの接続を意味し、さまざまな OCX リソースを VC へアタッチ可能です。
  • Physical Port (PP) OCX への接続口であり、お客さま側ネットワーク機器が接続する OCX の物理インタフェースになります。
  • Virtual Circuit Interface (VCI) 1 つの PP に紐づき、その PP に VLAN を設定します。また、 VC にアタッチ可能なリソースです。

これらの VC ・ PP ・ VCI を組み合わせることにより、下の図のように複数の OCX 拠点を結ぶ L2 ネットワークを自由に作成できることを前回の記事で説明しました。

前回の記事の内容をおさらいするための図。OCXを挟んで拠点1・2・3が存在しており、各拠点内にはルータがある。各拠点のルータからOCXへは線が延びており、OCX側では各拠点のPPでその線を終端している。OCX内では各PPにVCIが引っ付いており、VCIからは2つあるVCのどちらか片方に接続の線が延びている。片方のVCは拠点1のVCIと拠点3のVCIが接続されている。もう片方のVCには拠点1のVCIと拠点2のVCIが接続されている。
「拠点間接続」ユースケースの例

今回のユースケース「拠点からクラウドサービスへの接続」においても、これらのリソースは使用することになりますので、ここまでの内容をしっかり理解しておくことが重要です。

2. パブリッククラウドへの接続

パブリッククラウドへの通信方法

まず、「拠点からクラウドサービスへの接続」ユースケースがどのような時に必要となるのか説明します。併せて、その実現方法についても説明します。

企業や自宅のオンプレミス環境からパブリッククラウドへの通信はインターネットを経由して行なうことが一般的です。しかし、インターネットは通信帯域や通信経路の保証がないこと、加えて、さまざまな攻撃に晒されるリスクがあることから、一部のシステムの要件にはインターネットとの通信が禁止されている場合があることはご存じかと思います。 こういったインターネット通信禁止の要件をクリアするパブリッククラウドへの通信方法として「専用ネットワークを経由する方法」を多くのパブリッククラウド事業者が提供しています。 この方法では、オンプレミス環境から専用ネットワークのみを経由することで、低遅延・広帯域・安全にパブリッククラウドとの通信が可能になります。

「専用ネットワークを経由する方法」では、パブリッククラウド事業者のネットワーク機器にお客さま側ネットワーク機器を物理的に接続する必要があります1。このパブリッククラウド事業者ネットワーク機器とお客さま側ネットワーク機器間の接続方法をもとに「専用ネットワークを経由する方法」をさらに細かく下記の 2 種類の方法に分けることができます。

  • 「専用接続」
  • 「パートナー接続」

「専用接続」では、パブリッククラウド事業者のネットワーク機器への接続をすべてお客さまにて調達する必要があります。具体的には、パブリッククラウド事業者ネットワーク機器が設置されているデータセンターまでの回線や当該データセンター内の構内配線などを一から用意する必要があります。調達した接続についてはお客さまが専有できますが、コストやリードタイムの観点では負担が大きくなりがちです。

その一方で、 「パートナー接続」ではパブリッククラウド事業者の認定接続パートナーがパブリッククラウド事業者ネットワーク機器への接続部分を肩代わりしてくれます。 先行してパブリッククラウド事業者ネットワーク機器とパートナーのネットワーク間で接続を行なっているため、お客さまはパートナーのネットワークに接続するだけで OK です。

「専用接続」と「パートナー接続」のお客さまの調達区間を比較するための図。図の上側に「専用接続」の場合、下側に「パートナー」接続の場合を描いている。「専用接続」の場合だと、左からお客さまNW機器、回線、パブリッククラウドNW機器設置データセンターの構内配線、パブリッククラウドNW機器、パブリッククラウドが順に線で接続されている。お客さま調達区間は回線・構内配線を含んだお客さま側ルータからパブリッククラウドNW機器の範囲であることが示されている。「パートナー接続」の場合は、左からお客さまNW機器、パートナーネットワーク、パブリッククラウドNW機器、パブリッククラウドが順に線で接続されている。お客さま調達区間はお客さま側ルータからパートナーネットワークの間のみであることが示されている。
「専用接続」「パートナー接続」の調達区間比較

「専用接続」「パートナー接続」でそれぞれの場合のお客さまにて調達が必要になる区間を上の図で表しました。なお、図ではパブリッククラウド事業者のネットワーク機器が設置されているデータセンターとは別の場所にお客さま側ネットワーク機器が設置されていることを想定しています。

OCX を用いたパブリッククラウドへの接続

OCX は前述の「パートナー接続」を提供しています。 OCX の「パートナー接続」のメリットとしては以下のようなものがあります。

  • マルチクラウドに対応
    • OCX では複数のパブリッククラウド事業者とのパートナー接続をサポートしています。現在サポートしている事業者は こちら に記載されております。
    • OCX 拠点への 1 つの物理接続(1 つの Physical Port)から複数のパブリッククラウドへ同時に接続が可能です。
  • 短いリードタイム
    • お客さまに用意いただく物理的なものは OCX 拠点(Phyisical Port)への接続のみとなります。
    • 一度 OCX 拠点へ接続いただいた後は、お客さまにて OCX マネジメントポータルを直接操作いただくことで、リアルタイムにパブリッククラウドへの接続を作成できます。
  • 安価で明確な料金
    • 「専用接続」で必要となるパブリッククラウド事業者ネットワーク機器までの高価な専用回線に比べて、 OCX は安価な価格設定になっています。
    • OCX の料金はリソースごとに初期費用と月額から構成される簡潔明瞭な価格設定となっています。

各パブリッククラウドへの「パートナー接続」に対応する OCX リソースがこの後に説明する Cloud Connection となります。

3. Cloud Connection

Cloud Connection (CC) はパブリッククラウドへの 1 つの接続に対応する OCX リソースです。例えば、 AWS への接続を 2 つ用意する場合は 2 つの CC を作成する必要があります。

CC を使用したもっともミニマムな「拠点からクラウドサービスへの接続」ユースケースの構成を図示します。

Cloud Connectionを用いたミニマムな構成を示した図。左からそれぞれ1つのお客さまNW機器、PP、VCI、VC、CC、パブリッククラウドが線で接続されている。このうちPPとCCまでの範囲はOCXの枠で囲まれている。
Cloud Connectionを使用した最小構成図

この図では VCI と CC が 1 つの VC にアタッチされています。そのため、図の左にあるお客さま側ネットワーク機器(通常はルータとなります)と右にあるパブリッククラウド事業者のネットワーク機器(パブリッククラウドゲートウェイ)までが L2 ネットワークで接続されていることになります。このお客さま側ネットワーク機器とパブリッククラウドゲートウェイ間で BGP を用いてお互いのネットワーク経路を交換することで、お客さまオンプレミスネットワークと「パブリッククラウド上のネットワーク」の間で通信が可能となります。

なお、ここの「パブリッククラウド上のネットワーク」が指すネットワークは 2 つあります。 1 つ目はお客さまがそのパブリッククラウド上で作成したプライベートネットワークです。 2 つ目はパブリッククラウドがインターネットに公開している SaaS などのパブリックサービスに到達するためのネットワークです。 1 つ目のネットワークについてはすべてのパブリッククラウドで「専用ネットワークを経由する方法」で提供されていますが、 2 つ目のネットワークについては提供されていない場合があります。詳細は各パブリッククラウドの公式ドキュメントを確認してください。

接続に BGP を用いるのはパブリッククラウド側のサービス要件となります。そのため、 OCX に限らず他パートナーによる「パートナー接続」や「専用接続」でも基本的に同様であるため、接続に用いるお客さま側ネットワーク機器が BGP をサポートしている必要があります。もし、 お客さま側ネットワーク機器が BGP をサポートしていない場合は、 OCX では OCX-Router(v1) という BGP をサポートしたオンデマンドのルータを提供していますのでご利用をご検討いただければと思います。

CC の作成手順は、接続先となるパブリッククラウドによって微妙に異なります。各パブリッククラウドに対応した詳しい手順は OCX ドキュメントサイト で説明されていますのでご参照ください。

CC の作成(「パートナー接続」の作成)から実際に通信が可能となるまでの大まかな手順は、どのパブリッククラウドでも基本的に下記の手順となります。

  1. パブリッククラウドで「パートナー接続」を作成

    • 手順[2]の操作で必要となるパラメータが提供されます。
    • この手順が不要なパブリッククラウドもあります。
  2. OCX マネジメントポータルで CC を作成

    • 対象となるパブリッククラウドに合わせて必要なパラメータを入力します。
  3. パブリッククラウドで追加操作

    • パブリッククラウド側で必要な追加の操作を行ないます。
  4. 作成した CC を VC にアタッチ

    • VC にアタッチすることでその VC に対応する L2 ネットワークへ CC (≒パブリッククラウドゲートウェイへのネットワーク)を接続します。
    • 当該 VC にはオンプレミスのお客さま側ネットワーク機器へと続く VCI がすでにアタッチされていることとします。
  5. BGP の設定

    • お客さま側ネットワーク機器で BGP を設定し、パブリッククラウドゲートウェイとネットワーク経路の交換を行ないます。

ここまでの内容で、「拠点からクラウドサービスへの接続」ユースケースでは VCPPVCI に加えて CC を用いて構成することがわかったかと思います。

4. 冗長構成

最後に、少し進んだ内容になりますが「拠点からクラウドサービスへの接続」ユースケースでの冗長構成について説明します。

このユースケースでは、障害が発生したとしてもオンプレミス環境とパブリッククラウド間の通信が途絶えないようにすることが重要です。そのためにも、 SPOF (Single Point Of Failure)が存在しないように OCX ネットワークを構成する必要があります。以降では、例となる図を用いて段階的に SPOF を取り除いていきながら解説します。なお、今回の例ではオンプレミス環境から 1 つのパブリッククラウドへ OCX を介して接続しているものとします。

まずは下の図のように、もっともミニマムな構成からスタートです。

CCがSPOFとなる図。左からそれぞれ1つのお客さまNW機器、PP、VCI、VC、CC、パブリッククラウドが線で接続されている。このうちPPとCCまでの範囲はOCXの枠で囲まれている。また、お客さまNW接続機器からVCIまでは拠点1と書かれた破線で囲まれている。CCで障害が発生したことを示すマークがある。
Cloud ConnectionがSPOF

上の図の CC に注目します。 CC は OCX とパブリッククラウドとの接続部分となるため、当該 CC 箇所の OCX 側ネットワーク機器の物理インタフェースとパブリッククラウドゲートウェイの物理インタフェースの障害による影響を受けます。そのため、 CC を 2 つ用意して冗長化します。 OCX では CC を冗長化できるように OCX とパブリッククラウドの接続ポイントである NNI (Network-Network Interface)を各パブリッククラウドごとに 2 つ以上提供しています。 NNI が異なるということは、 OCX とパブリッククラウド間が違う箇所で接続されているということを意味します。 CC の作成時に NNI を選択できますので、 CC を冗長化する場合は NNI を重複させずに CC を 2 つ作成していただければと思います。

CC を冗長化した構成が下の図となります。

PPがSPOFとなる図。1つ前の図からCCのSPOFを取り除いた図でもある。左から1つのお客さまNW機器、1つのPP、2つのVCI、2つのVC、2つのCC、1つのパブリッククラウドが線で接続されている。VCIからCCまでは2つの線に別れており、それぞれの線で1つずつVCIからCCまで接続されている。パブリッククラウドでそれらの線が合流している。PPで障害が発生したことを示すマークがある。
Physical PortがSPOF

上の図では PP に注目します。 PP はお客さま側ネットワーク機器が接続する OCX への接続口となるため、お客さまネットワーク機器の物理インタフェースと OCX 側ネットワーク機器の物理インタフェースの障害による影響を受けます。この影響を回避するために、 PP を 2 つ用意して冗長化します。

この際、単に PP を 2 つ用意するだけではなく、より一歩踏み込んで、ネットワーク機器筐体の障害への対策を取ることを推奨します。この対策により、当該 PP を収容している OCX 側・お客さま側ネットワーク機器の突発的な再起動や電源断による筐体全体に影響がある障害も回避が可能です。具体的には、 PP の 「ポートの冗長」 オプションを有効化することで、 OCX 側ネットワーク機器筐体障害の対策を行なえます。この「ポートの冗長」オプションを有効化することで、 PP 作成時に同じ OCX 接続拠点の既存 PP を指定でき、その指定した既存 PP を収容している OSW 側ネットワーク機器筐体とは別の機器筐体に PP を作成できます。これにより、機器筐体をまたいで冗長化された PP のペアを構成できます。また、この PP の冗長ペアに接続するお客さま側ネットワーク機器も冗長化することで、お客さま側ネットワーク機器筐体の障害にも耐えうる設計となります。

ネットワーク機器筐体の障害対策を含めて、 PP を冗長化した構成が下の図となります。

拠点がSPOFとなる図。1つ前の図からPPのSPOFを取り除いた図でもある。左から2つのお客さまNW機器、2つのPP、2つのVCI、2つのVC、2つのCC、1つのパブリッククラウドが線で接続されている。お客さまネットワーク機器からCCまでは2つの線が平行しており、それぞれの線で1つずつお客さまNW機器からCCまで接続されている。パブリッククラウドでそれらの線が合流している。お客さまNW機器からVCIまでは拠点1と書かれた破線で囲まれており、その破線内に拠点1で障害が発生したことを示すマークがある。
OCX拠点がSPOF

さて、最後に 1 つの OCX 拠点がまるごとダウンすることを考えます。あまり考えたくはないですが、広域災害や電源に関わる事故によってデータセンター全体に影響のある障害が存在します。上の図のように 1 つの OCX 拠点にしか接続していない場合に、当該データセンターでそういったデータセンター全体に影響のある障害が発生すると、その障害が復旧するまで影響を受け続けることになってしまいます。この影響を回避するには、下の図のように異なる OCX 拠点へ接続し、拠点冗長をとる必要があります。

SPOFがすべて取り除かれた図。1つ前の図のお客さまNW機器、PP、VCIが拠点1と拠点2にそれぞれ1つずつ配置されている。
SPOFがない構成

上の図が、オンプレミス環境から 1 つのパブリッククラウドへ OCX を介して接続する場合の SPOF が無い構成と言ってよいでしょう。これ以上にシステム全体として障害に強い構成とするには、「OCX 以外のオンプレミスとパブリッククラウド間の通信手段も用意しておく」「パブリッククラウドの障害に備えてマルチクラウドで構成する」といったことが考えられます。リスクとコストを天秤にかけて、お客さまにとってベストな構成を検討いただければと思います。

おわりに

今回の記事では、「拠点からクラウドサービスへの接続」ユースケースを通して、 Cloud Connection のリソースについて解説しました。また、 Cloud Connection を用いた構成での冗長構成についても説明しました。前回の記事とあわせて、これで OCX のもっとも基本となるユースケースについて理解いただけたかと思います。

紹介したもの以外にも、まだまだ OCX には他の機能サービスやそのサービスを構成するリソースが存在し、今後も追加されていく予定です。それらの解説も別の機会にできればと考えています。

OCX のご利用に興味をもたれたり、 OCX を使用した構成の設計についてご質問やご相談ごとがあれば、お気軽に弊社までお問い合わせください!


  1. より正確にはパブリッククラウド事業者が発行した LOA のパッチパネルポートまで接続する必要があります。そのためには、 LOA をデータセンターに提出してクロスコネクトを調達する必要があります。

新卒による、リモートワークでのオンボーディングの振り返り

こんにちは、BBSakura Networks株式会社 の清水です。 私は新卒として、2023年7月よりBBSakura Networksに入社し、普段はモバイルコア*1に関する開発を担当しております。

弊社はコロナ禍より以前からリモートワークを採用しており、私も入社してから現在に至るまで自宅を主な勤務地として活動しています。

本記事では、フルリモートで働く新卒社会人が、7月から現在に至るまで、どのようなオンボーディングを経てグループに馴染んでいったのかについて、私の目線からご紹介させていただきたいと思います。

自己紹介

2023年4月から働き始めた新卒です。6月までは親会社であるBBIX(及びその親会社であるソフトバンク)にて研修を受けておりました。 大学時代はコンピューターサイエンスを専攻していたものの、ネットワークに関する知識は少し勉強しただけ、ましてやモバイルネットワークに関しては何も分からないという状態でした。

配属が決まった直後に、グループの皆さんとオンライン会議でお話しし、その際にモバイルネットワークに関する説明を受けたのですが、聞き慣れない用語のオンパレードで、

「知っているプロトコルが1つもないです。」
「そもそも、3GPP*2ってなんですか?」

と思わずコメントしてしまったことを覚えています。

オンボーディング

入社直後

業務で使用するツールなどの登録手続き・エンジニアとして身につけるべき知識の勉強を中心に行いました。 この際、社内Wikiに、新しく入社したメンバーがやるべきこと・学ぶべきことがまとめられており、 社内手続き・社内ルール・制度などはそこを読めばスムーズに理解できます。 勉強するべきことについても、何について、どのホームページ・書籍で勉強を行えばいいか、まで丁寧に記載されています。 弊社ではUdemyと、オライリー学習プラットフォームに加入しており、動画学習・テキストによる学習のいずれについても手厚くサポートされています。 自分は開発で使用されているGo言語に触れたことがなかったため、このタイミングで基本的な内容を学習しました。

また、CCNAの研修も1週間受講しました。 一緒に講義を受講した同期は早々にCCNAに合格しています。すごい (自分はまだ受験すらしていない…)

また、社長から経営理念・組織・事業内容に関してお話しいただきました。 お話の中で出てきた、”世界を変える Geeks' Playground” というシェアードバリューや、自社開発にこだわる姿勢は、自分もとても気に入っています。

この時期に歓迎会も開催していただきました。 歓迎会はフルリモートの会社らしくオンラインでの開催でしたが、ボードゲームをやって盛り上がったりしていました。

グループメンバーとの顔合わせ

さて、先程お話した通り、弊社は基本的にフルリモートで勤務しています。 ですが、仕事を進めるにあたり、一度はグループのメンバーとオフラインで顔合わせをしたほうが円滑にコミュニケーションを取りやすいです。 しかし、グループのメンバーは北海道から関西まで様々な場所に住んでおり、一同に会するのは簡単なことではありませんでした。 それなら私が皆さんに会いに行けばいいのではないか、ということで入社1ヶ月目にして早速出張を経験することになりました。

顔合わせは、東京・北海道・関西の3ヶ所で行い、以下のようなことを行いました。

  • 業務内容について分からないことや使用するツールの使い方を教えてもらう
  • 簡単なタスクを振っていただいて、プルリクエスト作成などを通して業務の流れに慣れる
  • 食事会
  • 施設の見学

直接顔を合わせて交流することで、グループのメンバーの人となりを知ることができ、安心感が増しました。

余談ですが、顔合わせの際にいくつかの施設を見学させて頂いたので、ここで紹介させていただきます。

  • さくらインターネットの石狩データセンター(北海道)

せっかくなので、さくらインターネットの石狩データセンターを見学させていただきました。 現在、石狩データセンターには3号棟まで施設が存在しているのですが、初期に建てられた1号棟での知見が、その後に続く2号棟以降に反映されており、内部の仕組みが変わっていたりするのがとても興味深かったです。 なお、石狩データセンターには社内のプロジェクトとして動いている石狩ラボ構築プロジェクトの拠点にもなっています(自分もメンバーとして参加しています!)。

  • 理化学研究所 計算科学研究センター (兵庫)

現在運用中のスーパーコンピューター「富岳」に関する展示や、スーパーコンピュータに関する研究成果の展示などを見学しました。 スケジュールの都合上、富岳自体の見学はできませんでしたが、とても興味深かったです。

「富岳」の1ラック模型
「富岳」の1ラック模型

  • 電電宮 (京都)

電電宮は、電気・電波の祖神として信仰されている神社であり、電気事業者のみならず、通信事業者やコンピュータ事業者からも信仰を集めています。 お守りもSDカードやシールだったりと馴染み深いものが多くて面白かったです。

電電宮
電電宮

なお、護持会の会員には、関連する業界の有名企業のお名前がずらりと並んでいます。

護持会会員御芳名 弊社の名前もここに入っています
護持会会員御芳名 弊社の名前もここに入っています

初仕事スタート

顔合わせを一通り終えたあと、初仕事として、モバイルコアのコードの書き換え、具体的には、HSS*3へのリクエストを処理するためのコードの書き換えを行いました。 初仕事として振られたこのタスクは、タスク管理ツールにおいて”難易度: Hard”と記載されており、はじめのうちは自分にできるのか不安でした。

ですが私は、「モバイルネットワーク?アタッチ?HSS?なんですかそれ?」という状態 + Go言語未経験ということでほぼ0からのスタートだったため、始めはかなり基本的な内容から教えていただきました。 その後上司とペアプロを通して、コードの書き方を教わりながら実装をはじめていきました。 もちろん、ペアプロもオンラインで行っています(VSCodeのLive Share、便利ですよね)。

未経験者である私に根気よく説明してくださった諸先輩方には本当に感謝しています。

リモートワークにおけるコミュニケーション

ここからは仕事を進めていく中で、自分にとって助かっている社内のコミュニーケーションの方法や取り組みについて紹介させていただきます。

朝会

毎朝実施しています。 基本的には、私が前日にやった作業を報告し、疑問点などがあればその場で確認しています。 このパラメータはどうすればいいのかという開発業務の相談から、社内手続きなどのちょっとした不明点まで、色々な疑問を気軽に聞くことができたので、この朝会の存在は個人的にはとても助かりました。

また、雑談で盛り上がることもしばしばあり、グループの皆さんと仲良くなるきっかけにもなったと思います。

Times

弊社ではSlackを利用してコミュニケーションを行っているのですが、社員の中には、自分用のチャンネルを作成し、times(分報)として利用されている方もいます。 自分の所属するグループでは全員がtimesを持っていたので、自分も配属初週に何となく作っていました。

当初は活用方法がよく分かっていなかったので、自身がその日やったことを日報としてまとめ、翌朝の朝会ではその内容を元にお話する、みたいな使い方をしていました。 現在では、日報に加え、自分の取り組んでいる内容をほぼリアルタイムで発信する、という使い方が多くなっています。 〇〇を始める(完了した)、みたいな報告の他にも「開発を進めているコードなどでエラーが発生した」や、「この部分についてどのように対応するか悩んでいる」みたいな感じで自身が躓いている点・考えを整理している過程なども書いていくようになりました。

このような発信をしていると、親切な先輩方がアドバイスをくれるようになり、自分1人で考えるよりもスムーズに仕事が進むようになりました。 (みなさん、いつもありがとうございます)

このように、気軽にアドバイスを貰える場としてtimesの存在もとても助かっています。 (この記事を書いている際にも、自分のオンボーディングの過程を思い出すためのツールとして大活躍してくれました。)

このブログを書く過程で知ったのですが、Working Out Loudという方法論が存在しており、上記のような自分の取り組みはWorking Out Loudに似ているのかもしれないなと思いました。

blog.studysapuri.jp

余談ですが、皆さんのTimesを見ると、有意義な情報が共有されていたり、その方の人となりを知ることができるのでとても楽しいです(ただし、ずっと見ているとあっという間に時間が過ぎていくので程々にしていますw)

会社全体としての取り組み

フルリモートの環境でも円滑なコミュニケーションを取るために、弊社ではいくつかの取り組みが行われています。

全社定例

これは文字通り全社員がオンラインで毎週行っている会議で、基本的には各グループの経過報告の場です。 しかし、それ以外にも経営陣の方がお話をしてくださったり、会議後半の時間で持ち回りの司会が雑談のネタを提供したりと、課外のメンバーの人となりを知る機会としても機能しています。

四半期会議

四半期に1回、会社のメンバーがオフラインで集まり、課題感の共有や、特定のテーマに関して議論するグループワークを行う機会があります。 普段仕事での関わりが少ない方とも交流ができるとてもいい機会です。 私は、配属が決まる前に四半期会議に参加させていただく機会があったのですが、とても雰囲気が良くて、楽しそうな環境だなと感じていました。

まとめ

以上のようなオンボーディングプロセスを経て、私は無事に初仕事を終えることができました。 初仕事を通して自分が書いた1000行以上にわたるコードを見てとても自信が湧きました(もちろん、行数が全てではありませんが)。

現在は上で述べたようなモバイルコアのソフトウェアの開発に加えて、SIMカードのプロファイルの検証や検証に用いる機器の環境構築などのハードウェアに関する業務も行っています。 ソフトウェアからハードウェアまで幅広い業務に携われるのもこの仕事の魅力だと感じています。 特に、配属前にソフトウェアもハードウェアも両方触れる環境で働きたい、と考えていた自分にとってはまさに願ったり叶ったりな環境であり、毎日楽しく仕事をさせてもらっています。

オンボーディングを通して、リモートワークの良さは、目的に合わせて柔軟に働く場所を選べることにあるのだと感じました。 入社前の自分はリモートワーク = 常に自宅で働き続けること、みたいな固定観念があったのですが、実際にはそんな事はなく、私の場合でも物理的な作業が必要な場合は現地に赴いたり、それこそ今回のように顔合わせの際には直接会うために出張したりと、状況に合わせて柔軟に働く場所を選んでいます。

自分もいち早く戦力として活躍できるように、引き続き頑張りたいと思います。

なお、弊社のリモートワークにおける働き方については、当ブログの他の記事でも紹介されています。 気になった方は是非みていってください。

最後に、宣伝になりますが、11月28日に開催されるCNTOM2023にて、モバイル未経験の新卒がどのようにして業務を進めていったのか、というテーマでお話しさせて頂く予定です。 上で紹介させていただいた、これまで自分が取り組んできた仕事についても具体的に触れていくつもりです。

  • 日程: 11月28日(火) 17:10 - 17:30
  • 登壇者: BBIX株式会社 清水 雄斗 (今回は親会社のBBIXがスポンサーをしているので、BBIX社員として登壇させていただきます)
  • 登壇テーマ: 「モバイル未経験から新卒配属5か月でモバイルコアとSIMの開発運用で活躍してる話」

CNTOMの詳細や申し込み方法につきましては以下のリンクをご覧ください。

cntom.jp

ここまでお読みいただきありがとうございました。

*1:携帯電話の通信網において、基地局より先にある、認証基盤や交換機といったネットワークの中核的な要素のこと。

*2:3GPP: モバイル通信に関する標準化を行っている団体、もしくはその団体が公開している技術仕様書のこと。仕様書は、扱っている技術カテゴリについて細分化されており、更にそれら1つ1つの仕様書についても数百ページに及ぶ。

*3:Home Subscriber Server。モバイル通信の認証認可を行うサーバーのこと。

ネットワーク業務未経験エンジニアがラボでSONiCの設定したり、勉強した話

はじめに

こんにちは、BBSakura NetworksでOCXのバックエンド開発を行っている渡邉です。
今回の記事はOCX開発について…ではなく、
これまでネットワークに関する業務をやっていない人間が石狩ラボに導入したSONiCの設定を行い、ネットワークの勉強をしたことについての記事になります。

簡単に自己紹介をします。

  • エンジニア歴:11年ほど
  • 開発経験:Web系サービスのフロントエンドやバックエンドの開発がキャリアのほとんど。
  • ネットワークに関する知識:学生時代に勉強したぐらい。業務は未経験。

1. 石狩ラボプロジェクトとは

弊社では石狩ラボプロジェクトというプロジェクトがあり、ネットワークに詳しくない人間がネットワークについて学んだり、色々な機器などを試したり、現地のデータセンターで作業したりというプロジェクトです。
もちろん普段の業務でネットワーク関連の業務に従事しているメンバーもいます。
詳しくは以下の記事を参照ください。私もこの記事読んで気軽に参加してみるかと参加しました。
blog.bbsakura.net

プロジェクトに参加したきっかけ

自分は2023年2月に中途入社しました。
それまでの業務に関してはtoC、toBのWebサービスが主流でありネットワーク業務とは無縁でした。
入社して石狩ラボプロジェクトの存在と前述の記事を知り「ネットワーク業務初心者でもこれだけ勉強できる機会があるんだ」と参加したいと思いました。
2023年度の石狩ラボプロジェクト参加募集メンバーの呼びかけに最初ちょっと及び腰でしたが、上長からも「気軽に勉強してください!」と後押ししてもらい今年度からメンバーとして参加することとなりました。

実際に参加して

とはいえ、本業である開発業務もあるため石狩ラボプロジェクトには兼任での参加となります。
今回のプロジェクトでの自分の担当業務は

  1. ラボ機器のログ保存の期間や、保存場所などログに関することを考える。
  2. ラボに新たに導入するスイッチのNOSであるSONiCの本番configの設定を用意する。

の2つでした。1に関しては絶賛現在も対応中です。
本業側の優先度がどうしても高く多忙な時期は打ち合わせに参加できなかったり、割り振られたタスクが消化できず、といった状況になりました。
そんな中メンバーの一人が「1週間に1日2時間ほど、石狩のことだけ黙々とやる日を作りましょう」と枠を設けてくれて、自分も積極的にできる限り参加しラボの業務もこなせていきました。

前置きがとても長くなりましたが、今回はタイトルの通り2について記事にできればと思います。

2. 実際に行った作業

さて、何度もお伝えしている通りネットワークのことは本当に何も知りません。
設計の話を聞いていて「VLAN」というワードが出てきて「VLANってなんですか?」
ネットワーク機器のメーカーにヤマハがあるという話を聞いて「ヤマハって楽器とバイク以外も作ってるんですか…?」
「SONiC(ソニック)」ってあの人気キャラのことですか・・・?
CUIの操作も久々だったため、「そもそもネットワーク機器の設定はどこに入れれば良いんだ」というレベルです。

ここからはそんな私が現地で作業するまでに行った作業と、現地で行った作業についてお話できればと思います。

現地に行くまでに実施した作業

  • CML2上で事前検証

    • まずSONiCの設定を設計するにあたりCML2を利用し、想定される設定の事前検証を行います。
      ネットワークに詳しいメンバーに基礎的なことから教えてもらい、設計を元に設定作業を進めます。
      設定を進めつつ、実機に合わせて想定と異なっていた箇所は合わせて修正していきます。
  • スイッチにSSH接続するためのkeyの投入準備

    • 次にスイッチに対してSSH接続を行えるように、各メンバーのKeyを設定するscriptの準備を行います。
      これは必須ではないのですが、メンバーが増えていけば自ずとKeyの設定作業が負荷となっていくため、 早い段階でこういったscriptを用意して、今後の運用コストを少しでも減らします。

この段階までにネットワークにおける基本的な用語(一部)やCML2というツールの使い方、ネットワーク機器の設定周りについて学びました。

ここで、私が石狩に行くにあたりどういった作業をするのか石狩ラボのトポロジをお見せします。

2台のRTX1300とCiscoCatalyst3560-CGが接続されている。CiscoCatalyst3560-CGと4台のDell R450が接続されている。CiscoCatalyst3560-CGがリプレイス対象
リプレイス前
2台のRTX1300とDell S5248F-ONが接続されている。Dell S5248F-ONと4台のDell R450、2台のDell R650が接続されている。CiscoCatalyst3560-CGをDell S5248F-ON(SONiC)にリプレイスした
リプレイス後
※厳密にはもう少し複雑な構成となっています。
今回の目的は昨年の初期構築で設置する予定だったDellのスイッチを設置する対応となります。

現地で実施した作業

  • 既存スイッチの取り外し&新スイッチの設置
    • まず取替対象の既存スイッチをラックから取り外します。
    • 新しくラックに入れるスイッチの中身を開けNICの差し替えを行います。
      • 部品が固かったり、ちょっと力を入れると壊れてしまうのでは?という怖さを感じつつ、差し替え作業とラックにスイッチを戻す作業を行います。
  • スイッチにLANケーブルを挿す
    • 次に各ポートに対して、事前の設計通りLANケーブルを挿していきます。本数がそこそこあるため間違えないように目印を見ながら挿していきます。
  • 準備したconfigの投入
    • ここまでで物理作業が概ね終わっているのでここから事前作業で用意したconfigを投入していきます。
    • 投入作業自体は他のメンバーが進めていくので、自分はそれを後ろから見守ります。
  • configのdump取得と復旧手順の用意
    • ここまで順調に設定を行ってますが、何かしらの原因でconfigが消失した場合に備えてdumpの取得と復旧手順を確立させる必要があります。
    • この作業が自分としては一番自らできた箇所かなと思っています。
// SONiCのconfigのバックアップを取得するコマンドを実行する。
~$ cd /host/
/host$ sudo config-setup backup

// 実機の設定のバックアップが取れる
/host$ ls | grep old_config
old_config

// バックアップが取れていることを確認
/host$ cd old_config
/host/old_config$ ls
asic_config_checksum             config-migration-post-hooks.d  core_analyzer.rc.json    hw_resources        sonic-config.tar
ccd_mgmt_sock                    config-migration-pre-hooks.d   docker_limits.json       init_cfg.json       sonic-environment
cert                             constants.yml                  frr                      licenses            sonic_version.yml
config_db.json                   copp_config.json               generated_services.conf  snmp.yml            updategraph.conf
config_db_version_registry.json  copp_feat_trap.json            hamd                     sonic_branding.yml
/host/old_config$ cd frr
/host/old_config/frr$ cat ospfd.conf
~設定なのでここでは省略。投入した設定になっていることを確認~

// old_configをローカルにコピー
# root
scp -r /host/old_config {user}@N.N.N.N:/home/{user}/tmp
# Local
scp -r {user}@N.N.N.N:/home/{user}/tmp/old_config /Users/{user_name}/{bk_dir}
# GitPush
~手順は省略しますが取得したバックアップをGit上で保存~

// old_configの取り込みを行い、正しくバックアップできているか確認
~$ sudo config-setup boot
  • SSH接続用のkeyの投入、疎通確認
    • 本来の予定では事前に作成したscriptでKey設定する予定だったのですが、script内のKey設定部分抜き出し直接設定。
    • 設定したことをメンバーに連絡し、SSH接続できることを確認しました。
  • 想定外のトラブル
    • 機器側のポート番号や用意したケーブルタグを目印にしてLANケーブルを挿していたと思ったらPortの番号を見間違えてケーブルを挿し間違える
    • NICを差し替えて、LANケーブルを設計通り挿したら疎通が通らない事象が発生
      原因はNICの挿す向きでPortの上下が入れ替わり、左から見ると2,1になっていた。
      よく見るとうっすらと上下逆さまに「2」と「1」の刻印が…(画像で見せたいのですが、DCは撮影NGにつきご容赦ください)
    • 一方で「1」と書かれた穴にLANケーブルを挿してPort1に挿したな、ヨシ!と思ったらPort1じゃないということもありました。

その他にもいくつかトラブルがあったのですがそれは別の機会があれば記事にできればと思います。

現地作業でデータセンターの雰囲気や実際のラックがどうなっているか、機器の構成などネットワークの物理的な内容について学ぶことができました。

終わりに

今回私が学んだことを列挙して、終わりたいと思います。

  • tag vlanとは一つのポートで複数のポートを仮想的に持たせる技術である。
  • port vlanとは一群のポートを仮想的に分割し、複数ドメイン持たせる技術である。
  • ヤマハはネットワーク機器も作ってる。
  • SONiCはネットワーク機器におけるOS(NOS)。
  • シミュレーションと実機の設定では必ず違いが出る。
  • ケーブル挿すときは刻印をよく確認する。けど刻印が正しいとは限らない。

ネットワークの知識レベルが1だったのが、今回の石狩ラボプロジェクトで5ぐらいにはレベルアップできたような気がします。

ユースケースで見る OCX リソース解説 「拠点間接続」編

はじめに

こんにちは! BBSakura で基盤となるネットワークを開発している酒井です。

このブログ記事では、 OCX の代表的なユースケースを通して、 OCX 内でお客さまに作成いただく各 OCX リソースについて解説します。

OCX の代表的なユースケースとしては、「拠点間接続」と「拠点からクラウドサービスへの接続」があります。「拠点間接続」ユースケースは、一般的な用語として Data Center Interconnect (DCI) と呼ばれることもあります。今回の記事では「拠点間接続」のユースケースを通して、 Physical Port (PP)Virtual Circuit Interface (VCI)Virtual Circuit (VC) の OCX リソースについて解説します。「拠点からクラウドサービスへの接続」ユースケースを通しての他 OCX リソースの解説記事も予定しておりますので、楽しみにお待ちください。

この記事の想定読者ですが、下記の技術について理解していることを前提としています。

  • L2 スイッチ
  • VLAN

また、この記事では下記の流れで解説を行ないます。

  1. OCX 概要
    • OCX が提供するネットワークについて簡単に説明します。
  2. Virtual Circuit (VC)
    • OCX でもっとも基本となるリソースである VC について説明します。
  3. ユースケース「拠点間接続」について
    • 「拠点間接続」のネットワーク構成について簡単に説明します。
    • 「拠点間接続」に必要な OCX リソースである Physical Port (PP) と Virtual Circuit Interface (VCI)について説明します。
  4. お客さま接続ルータの設定
    • OCX に接続するお客さまルータの設定について簡単に説明します。

1. OCX 概要

OCX は BBSakura が開発を行なっているネットワークのサービスです。 OCX ではマネジメントポータルをお客さまに直接操作いただくことで、簡単に OCX 拠点を結ぶプライベートネットワークを構築できます。 将来的には API による操作も提供予定です。これらの操作は後述する OCX リソースの作成・変更・削除にあたります。

なお、具体的な OCX の操作方法については OCX ドキュメントサイト にすべて記載されておりますので、適宜ご参照ください。

OCX を用いて構築できるプライベートネットワークは基本的には L2 のネットワークになります。似たような L2 ネットワークのサービスとしては、通信キャリアが提供している 広域イーサネット があります。 OCX では、一般的な 広域イーサネット のサービスに無い特徴としてオンデマンドに直接お客さまが操作可能であること、また、単純な L2 ネットワーク以外のよりリッチな機能を提供していることが挙げられます。 OCX で提供しているリッチな機能については、別の機会に説明いたします。今すぐ知りたいという方は、弊社にお気軽にお問い合わせください。

OCX は OCX 拠点間で L2 ネットワークをお客さまに提供します。そのため、お客さま視点では OCX は巨大な L2 スイッチと考えていただくことが可能です。

OCXを端的な概念として表した図。左から拠点X・OCX・拠点Yが、並んでおり、拠点Xと拠点Yの中はルータとルータ配下のネットワークが描かれている。OCXは大きなスイッチで表されている。拠点Xと拠点Yから間のOCXへ接続を表す線が延びている。
OCXイメージ図

この記事で解説する「拠点間接続」ユースケースは、単純な L2 ネットワークのみで構成できます。そのため、 OCX の理解を始めるには「拠点間接続」ユースケースはうってつけです。

2. Virtual Circuit (VC)

OCX で構築できるネットワークは L2 のネットワークだと話しました。この L2 のネットワークに一対一で対応する OCX リソースが VC になります。そのため、 VC は OCX でもっとも基本的なリソースだと言えます。

リソース VC について詳細に解説します。まず、この OCX ドキュメント では VC は下記のように説明されています。

Virtual Circuit(VC)は1つの大きなブロードキャストドメインとして振る舞い、VCIやCloud Connection、Router Connection、Internet Connectionなどのレイヤ2の論理回線を相互に接続することができます。

ブロードキャストドメインとは、ブロードキャストアドレス宛の L2 イーサネットフレームが届く範囲のことを指します。ブロードキャストアドレス宛の L2 イーサネットフレームとは、具体的には宛先 MAC アドレスが FF-FF-FF-FF-FF-FF のイーサネットフレームになります。イーサネットでブロードキャストアドレスを宛先として使用するプロトコルの 1 つに ARP があります。この ARP は通信先の IP アドレスから MAC アドレスを解決するプロトコルであり、 1 つの L2 ネットワークに接続したルータやホスト間でネクストホップへの通信のために実行されることはご存じかと思います。

通常の L2 スイッチだと、このブロードキャストドメインは VLAN に対応します。具体的には、 L2 スイッチではイーサネットフレーム内の VLAN ID タグによってブロードキャストドメインを識別します。 OCX が単純な L2 スイッチと異なる点として、OCX でブロードキャストドメインに対応するリソース VC 自体には固有の VLAN ID は紐づきません

では、どのようにして OCX では VC 、つまり、ブロードキャストドメインを識別しているのでしょうか。 VC には後述するその他の OCX リソースを アタッチ するという操作が可能です。この VC へとアタッチされたリソースは、その VC のブロードキャストドメインに参加したと OCX では判断します。そのため、同一 VC にアタッチされた OCX リソース間で発生する通信は、その VC に対応したブロードキャストドメイン内で発生した通信として OCX では取り扱われます。

リソースVCを説明するための図。OCX内に2つのVCがあり、それぞれ複数のOCXリソースと重複がないように繋がっている。それらのOCXリソースからVCへのアタッチの関係を矢印で表している。また、各VCに接続されたOCXリソースの1つからブロードキャストフレームがVCに向けて送信され、そのVCにアタッチされている他のOCXリソースにそのブロードキャストフレームが転送されている。
VC説明図

お客さまが OCX で L2 ネットワークを作成する時は、まずブロードキャストドメインにあたる VC を作成し、そのブロードキャストドメインに接続させたい OCX リソースを当該 VC にアタッチする、ということが OCX における基本的な操作となります。逆に、ある OCX リソースのブロードキャストドメインへの接続を解除したい場合は、当該 VC からその OCX リソースを デタッチ すれば OK です。

3. ユースケース「拠点間接続」について

「拠点間接続」とは

ユースケース「拠点間接続」では、複数の OCX 拠点にお客さまネットワークを接続し、その OCX 拠点間で L2 ネットワークを構成することで、地理的に離れたお客さまネットワークをセキュアかつ低遅延で接続します。

下の図のように、お客さまが接続した OCX 拠点の間であれば、 VC を用いて自由に L2 ネットワークを構成できます。

拠点間接続を説明する図。拠点X・Y・Zがあり、拠点内にはルータとお客さまネットワークが存在する。これらの拠点がOCXを通して線で結ばれており、それらの線はそれぞれL2ネットワークを表している。図では、拠点Xと拠点Z間の線・拠点Xと拠点Y間の・全ての拠点と接続された線があり、OCXを通して自由にL2接続できることを説明している。
拠点間接続のイメージ

OCX 拠点は順次展開中ですが、47 都道府県すべてに展開することを BBSakura としては 1 つの目標としています。お客さまの「拠点間接続」の選択肢が増えるように、今後も頑張って OCX 拠点の展開を進めます!

さて、「拠点間接続」のためにはお客さまに物理的にいずれかの OCX 拠点に接続していただく必要があります。先に述べたように OCX は巨大な L2 スイッチと考えることができます。そのため、お客さまのオペレーションミス等でお客さまネットワーク内に L2 ループを構成してしまい、接続しているブロードキャストドメインでブロードキャストストームを発生させないようにするためにも、一般にはルータなどの L3 ネットワーク機器で OCX 拠点に接続していただくことを推奨しております。その点を気にしなければ、もちろん L2 スイッチなどの L2 ネットワーク機器での OCX 拠点への接続も可能です。

この物理的な OCX 拠点への接続に必要な OCX リソースが以降で説明する Physical PortVirtual Circuit Interface になります。

Physical Port (PP), Virtual Circuit Interface (VCI)

PP は物理的な OCX 拠点への接続口となる OCX リソースです。具体的には、 PP は OCX 側ネットワーク機器の物理インタフェースと考えていただければと思います。お客さまが接続したい OCX 拠点を選択して PP リソースを作成することで、当該 PP に対応する LOA が OCX マネジメントポータル上で発行されます。この LOA を当該 OCX 拠点のデータセンター事業者に提出することで、 PP へのクロスコネクト(ラック間接続)がデータセンター事業者によって敷設されます。クロスコネクトについてイメージがつかない方は、データセンター事業者にお問い合わせください。

なお、この記事を執筆時点では PP としてサポートしているインタフェース規格は 1000BASE-LX10GBASE-LR になります。そのため、 OCX の PP と接続するにはお客さま側ネットワーク機器がどちらかの接続規格に対応している必要がありますのでご注意ください。

無事にクロスコネクトが敷設され、お客さま側ネットワーク機器と OCX の PP 間でリンクアップすると、 VCI の出番となります。 VCI は 1 つの PP に紐づく OCX リソースです1。 VCI には主に 2 つの役割があります。

VCI の 1 つ目の役割が、 PP に VLAN を設定することになります。 OCX では 1 つの PP、つまり、 1 つの物理接続で複数のブロードキャストドメインへ接続できます。 PP とお客さま側ネットワーク機器間で送受信されるフレームがどのブロードキャストドメインと紐づくのかを識別するためには、 PP とお客さま側ネットワーク機器間で共通の VLAN を設定する必要があります。リソース VCI の設定項目には VLAN ID があり、この設定した VLAN ID が当該 VCI が紐づいている PP に追加されます。前述したように PP は OCX 側ネットワーク機器のインタフェースにあたりますので、 VCI を通して、 OCX 側ネットワーク機器インタフェースに VLAN ID を設定するイメージをしていただければと思います。

VCI の 2 つ目の役割は、ブロードキャストドメインへの接続となります。 VCI は VC へアタッチ可能な OCX リソースです。 VCI を VC へとアタッチすることで、その VC に対応するブロードキャストドメインへ当該 VCI を接続します。

この VCI の 2 つの役割によって、お客さまネットワーク機器とブロードキャストドメイン間で通信可能な状態となります。

例として、 1 つの PP に 2 つのブロードキャストドメインを重畳している構成を図示します。

PPとVCIリソースを説明するための図。OCXを挟んで拠点1・2・3が存在しており、各拠点内にはルータがある。各拠点のルータからOCXへは線が延びており、OCX側では各拠点のPPでその線を終端している。OCX内では各PPにVCIが引っ付いており、VCIからは2つあるVCのどちらか片方に接続の線が延びている。VC Xには拠点1のVCI A(VLAN10)と拠点3のVCI D(VLAN10)が接続されている。もう片方のVC Yには拠点1のVCI B(VALN20)と拠点2のVCI C(VLAN30)が接続されている。
PPとVCIを使用した接続図

この図では、拠点 1 には PP が 1 つ存在し、その PP には VCI AVCI B が紐づいています。 VCI A には VLAN 10 、 VCI B には VLAN 20 が設定されています。また、 VCI AVC XVCI BVC Y にそれぞれアタッチされています。さらに VC XVC Y にはそれぞれ別拠点の PP に紐づいた VCI がアタッチされていることがわかります。これらにより、下記の 2 つの L2 ネットワークが構成されたことになります。

  • 拠点 1 と拠点 2 間
   [拠点1 お客さま接続ルータ]---(VLAN10)---[VCI A]---(VC Y)---[VCI C]---(VLAN 30)---[拠点2 お客さま接続ルータ]
  • 拠点 1 と拠点 3 間
   [拠点1 お客さま接続ルータ]---(VLAN20)---[VCI B]---(VC X)---[VCI D]---(VLAN 10)---[拠点3 お客さま接続ルータ] 

このように、複数の VCI を用いて、拠点 1 では 1 つの PP で 2 つのブロードキャストドメイン( L2 ネットワーク)への接続を重畳できました。ここで、 VC Y にアタッチされた拠点 A の VCI B と拠点 2 の VCI C では VLAN ID が異なっていることに気づかれた方もいるかと思います。 OCX では VC への OCX リソースのアタッチでブロードキャストドメインを識別すると先に説明しました。そのため、同一の VC にアタッチする VCI 間で VLAN ID を揃える必要はありません。これにより、同一の L2 ネットワーク(ブロードキャストドメイン)に接続していたとしても、お客さまネットワーク機器の接続 OCX 拠点(正確には接続 PP)ごとに異なる VLAN ID を自由に使い分けることが可能です。

4. お客さま接続ルータの設定

ここまでの説明で、「拠点間接続」には VC ・ PP ・ VCI が必要であることがわかったかと思います。また、 1 つの PP で複数のブロードキャストドメインに接続できることも説明しました。

最後にお客さま側ネットワーク機器の設定例を確認しておきましょう。と言っても、単純に接続ルータ間で通信を行なうだけであれば、当該ルータの OCX 接続インタフェースに VLAN を設定すればよいだけです。例として、先ほどの図に IP アドレスを追記した図を用意しました。

設定例のもととなる図。先ほどの「PPとVCIリソースを説明するための図。」にIPアドレスが追記されている。VC Xは192.168.10.0/24、VC Yには192.168.20.0/24が対応していることが書かれている。また、拠点1では「.1」・拠点2では「.2」・拠点3では「.3」とルータの横に追記されており、各ルータのIPアドレスの第4オクテットを表している。
設定例のためのネットワーク図

この図に記載の VLAN や IP アドレスに合わせて設定すると下記のようになります。なお、この設定例では各ルータとして Cisco IOS ルータを使用し、 GigabitEthernet1 で PP に接続しているものとします。

  • 拠点 1 接続ルータ
   interface GigabitEthernet1.10
    encapsulation dot1Q 10
    ip address 192.168.10.1 255.255.255.0
   !
   interface GigabitEthernet1.20
    encapsulation dot1Q 20
    ip address 192.168.20.1 255.255.255.0
   !
  • 拠点 2 接続ルータ
   interface GigabitEthernet1.30
    encapsulation dot1Q 30
    ip address 192.168.20.2 255.255.255.0
   !
  • 拠点 3 接続ルータ
   interface GigabitEthernet1.10
    encapsulation dot1Q 10
    ip address 192.168.10.3 255.255.255.0
   ! 

Cisco IOS ルータであれば、上記のように sub-interface を作成し、その sub-interface に VLAN ID と IP アドレスを設定すれば OK です。この設定によって、各拠点接続ルータと PP の間で VLAN タグ付きフレームのやり取りができるようになり、結果としてルータ間で Ping が通るようになるはずです。実際には、各拠点接続ルータの先にお客さまネットワークがあり、それらのお客さまネットワーク間で通信ができるようにルーティングの設定する必要があるかと思いますが、今回の記事では割愛します。

おわりに

今回の記事では、「拠点間接続」ユースケースを通して、 Physical Port (PP)Virtual Circuit Interface (VCI)Virtual Circuit (VC) の OCX リソースについて解説しました。今回の内容が理解できましたら、 OCX の基本的な使い方は理解できたと言って良いと思います。

次回はもう片方の主なユースケースである「拠点からクラウドサービスへの接続」を通して、その他の OCX リソースについても解説できればと考えています。

もし、今回の記事を通して OCX のご利用に興味を持たれましたら、ぜひ弊社までお問い合わせください!


  1. より正確には PP もしくは LAG Port に紐づく OCX リソースとなります。 OCX の LAG Port についてはまた別の機会に解説できればと思います。