クラウド閉域接続、簡単にできます（CloudConnectionの接続イメージ）

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

こんにちは！BBSakura Networks株式会社（以下、BBSakura）でクラウド接続を担当している赤羽です。今回は、BBIXのOpen Connectivity eXchange（以下、OCX）で提供しているCloud Connectionについて紹介します。クラウド閉域接続はハードルが高いと感じるかもしれませんが、OCXのCloud Connectionを活用することで、どれだけ簡単に接続できるかをお伝えします。クラウド接続方法の見直しを検討している方に、少しでも参考になれば幸いです。

1. OCXとは？

OCXとはBBIX株式会社が提供しているNaaS（Network as a Service）です。パブリッククラウドやインターネット、拠点間の接続など、クラウド上で管理・設定ができる仕組みになっています。Cloud Connectionはパブリッククラウドと閉域接続するためのコンポーネントのひとつです（パーツのようなものです）。専門知識がなくてもOCXポータルから数クリックで閉域接続できるようになっています。現在対応しているパブリッククラウドはAWS、Azure、Google Cloud、Oracle Cloud、IBM Cloud、さくらのクラウドの6つで、複数クラウドを同時に接続することも可能です。

CloudConnectionの詳細は過去のブログをご参照ください。

blog.bbsakura.net

blog.bbsakura.net

2. クラウドとの接続は3段階に分けて考える

オンプレミスとクラウド間の接続は複数の工程で構築しますが、大きく3つ、「①物理接続（L1接続）」「②VLAN設定（L2接続）」「③ルーティング設定（L3接続）」に分けて考えるとイメージしやすいかと思います。

※機器や構内配線をお客様にて用意する「専用接続」と、OCXでの提供方法の「パートナー接続」との比較となります

※オンプレミス設備とOCX（Physical Port）との接続は完了している前提でご説明します

Step1：物理接続（L1接続）

Step 1は「物理接続」です。これは、オンプレミス環境の自社設備とクラウド設備を物理的に接続する作業です。専用接続の場合、クラウド側の接続点の手配やデータセンター内の配線手配、接続テストを行います。データセンター側での調整や現地作業も必要となるため、最も手間がかかる部分です。

一方、OCXでは、この物理接続部分をCloud Connectionで簡単に構築することができます。後ほど構成イメージの比較についてご説明いたします。

Step2：VLAN設定（L2接続）

Step 2は「VLAN設定」です。VLAN番号の割り当てや仕様はクラウドごとに異なるため、事前に確認しておく必要があります。 VLAN番号が決まり、自前設備側とクラウド側と一致させることで、Step2のL2接続が完了します。

Step3： ルーティング設定（L3接続）

Step 3は「ルーティング設定」です。ここでは、IPアドレスやルーティング情報の設定を行います。多くのパブリッククラウドでは、BGPによるルーティング設定が推奨されています。クラウド側のインスタンスとオンプレミス側のルーター双方でBGP設定を行い、経路情報の交換を実施します。この作業が完了すると、オンプレミス環境とクラウド内のネットワークが通信できるようになります。今回は割愛いたしますが、OCXではこの部分を、OCX-Router（v1）で置き換えることができます。

3. Cloud ConnectionでStep1を簡単に接続

このように、クラウドと接続するには3段階の作業が必要で、専用接続を手配すると時間やコストがかかります。特に、時間がかかるStep 1の物理接続ですが、OCXのCloud Connectionではその部分が自動化されているため、現地作業も不要で、接続ロケーションや冗長構成もリストから選ぶだけで設定できます。

4. 各StepはOCXポータルで数分で完了

OCXでは、これらの作業をOCXポータルのWEB画面の操作だけで完結できます。ここでは、Step 1の作業をCloud Connectionで置き換えた場合の手順についてご説明します。 ＊今回はAWSを例にご紹介します。

BBIXのOCXポータルにログインし、Cloud Connectionメニュー右上の「作成」をクリック後、「AWS」を選びます。 下記画面が出てきたら項目を入れていきます。

1. 冗長有無を選択
2. 名前に任意のものを入力
3. 帯域を選択
4. Cloud NNI PoPを選択
5. アカウントIDを入力

入力が終わったら「作成」ボタンを押します。これでCloud Connectionが作成できました。設定はたったの1ページです！ あとはAWSのWEBコンソールで接続要求の確認と承認を行っていただければOKです＊クラウド側での処理に時間がかかる場合があります

まとめ

今回は、OCXのCloud Connectionを使って、どれだけ簡単にクラウドと閉域接続できるかについてお伝えしました。クラウドとの閉域接続では、物理接続がハードルとなることが多いですが、OCXを利用すれば各Stepを数分で完了でき、専門知識がなくても簡単に接続できます。Step 3のルーティング設定に不安がある場合でも、OCX-Router（v1）を使えば簡単に設定できるため、今後その点についてもご紹介していきたいと考えています。以上です。

異なるレイヤに飛び込んでみた話

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

はじめに

こんにちは。BBSakura Networksでソフトウェアエンジニアをしている桐山です。
今年の11月に入社しまして、モバイル開発グループの所属となりました。
まだ1ヶ月しか経っていないため、現在は環境や技術のキャッチアップを行っているところではありますが、これから本格的にモバイルコアの開発・運用に携わっていく予定です。

本記事ではBBSakura Networksに転職したきっかけや転職後の状況について語ります。

転職のきっかけ

前職では無線通信系の研究者向けのソフトウェア開発の仕事を約5年ほどしていました。 研究内容を理解して、意図通りの評価ができるように仕様を考えて、ソフトウェアを作り上げていくことはとても楽しくやりがいがありました。
一方で、通信業界で今後も面白い仕事をしていくために、以下のような理由で転職を考えるようになりました。

• 通信システム（特にモバイル網）をサービスとして提供する仕事をしてみたい
• RAN寄りの無線通信からレイヤを広げてコアネットワークやその先もできるようになりたい

BBSakura Networksとの出会い

前職でもBBSakura Networksの名前はJANOG等のイベントで見かけており、とても強者がいる会社というイメージで自分が入ることは全く考えていませんでした。
転職を考え始めていたある日、知り合いからBBSakura Networksの方を紹介していただき、その後、採用サイトを見たり開発をリードしている方の話を聞いたりして、自分のやりたいことが叶えられそうだと思って応募し入社に至りました。

ちょうど良いタイミングで魅力的な会社に出会えた経緯を思い返してみると、流れを作ったきっかけは初めて参加した2021年の通信系のアドベントカレンダーでした（今読み返すと恥ずかしいのでリンクは貼りません）。
無線通信系で仕事をしていて同年代と遭遇する機会があまりにも少なく（※）、SNSで勇気を出して発信してみたところ、一緒にモバイル等の話をできる方々と出会い、そのご縁がBBSakura Networksまで繋いでくれたのだと思っています。
※ JANOGのようなイベントは無線通信（特にRAN寄り）では展示会や学会くらいでした

採用について

BBSakura Networksの採用については、BBIX株式会社（ソフトバンク経由）またはさくらインターネット株式会社からの兼務または出向という形となります。
自分はさくらインターネットの方とお話したことと、応募要項に「要件があまり定まっていない状態からシステム構築の完遂をした経験」とあったことに惹かれて、さくらインターネット株式会社の経路から応募しましたが、どちらからでも問題ないかと思います。

ご興味のある方はぜひカジュアル面談もありますのでご活用ください。

www.bbsakura.net

転職してから

まだ入社1ヶ月のためわかっていないことが多いですが、現時点でのBBSakura Networksの印象は以下のような感じです。

• 当初の印象通り強者がたくさんいて技術的に深い話が交わされており成長できる環境である
• 勤務環境や学習環境が整っており、自分のやりたいことを尊重してもらえる風土がある
• 事業拡大を進めておりサービスを作り上げていくところから参加できる

同じ通信業界とはいえ異なるレイヤに転向したため、通信技術も開発もたくさん学ぶことがあります。
もちろん技術的に即戦力になれることは理想だと思いますが、異なるレイヤでも前職や個人的な活動でこれまで培った経験は活かせる部分はあると感じています。

ー	前職とのギャップ	経験が役立つ/役立ちそうなこと
開発	主な開発言語（Python→Go） ユーザ（特定少数→不特定多数） 用途（評価用→サービス提供用） 開発者（1~数人→10人）	複数の言語や環境を触ってきた経験 ：初めての技術が多くても抵抗なく取り組める 仕様調整〜開発〜試験まで一貫して実施した経験 ：規模感は違うが基本的な考え方は同じ
通信技術	モバイル（RAN寄り→コア） NW（小規模なLAN程度→より複雑で高度）	モバイルがどのようなものかの知識（興味） ：コアの詳細はわからなくても背景はわかるので入りやすい
環境	フル出社→フルリモート	自分から発信するスキル ：テキストベースのコミュニケーションでは重要度が高い

個人的には何よりも未知の領域の通信技術・開発への強い興味や好奇心がレイヤを乗り越えるために重要だと感じているので、今後も日々技術と向き合いながら楽しみつつ頑張っていきたいと思います。

NetFlowを分岐転送させて安定的なサービス提供と開発を共存する方法

目次

はじめに

こんにちは。BBSakura Networksの矢萩です。

この記事は BBSakura Networks Advent Calendar 2024 4 日目の記事」になります。

BBSakura Networksでは、親会社BBIXが手掛けているIX=Internet eXchange向けのユーザシステムの開発も行っています。BBIXではユーザポータルでのインタフェーストラフィック以外に、別サービスとしてNetFlowデータによるユーザトラフィックの詳細分析サービスを提供しています。 今回は、このシステムで使っているNetFlowデータを分岐転送させてサービス提供と開発を共存する方法を紹介したいと思います。

Internetトラフィックとフロー分析

フロー分析システムは、ネットワーク運用効率化のヒントを提供するシステムです。 IXユーザの課題となっている以下の情報を見える化します。

• どこのネットワークのトラフィックが多いか？
• トラフィックの多いネットワークはどの経路(Transit/IX)を主に使っているのか？

Internetはネットワーク(Asyncronous System＝AS)同士が相互接続することで全世界を包括するコンピュータネットワークを構成しています。IXにはASが集まり、それぞれが相互接続(Peering)することで、Internetでのトラフィック交換を効率的に行います。 ネットワーク接続の方法は

• (1) 相互接続：IXやPNI 相互接続 コスト安価
• (2) トランジット接続：Transit 上流接続 コスト高価

があり、(2)上流接続部分を(1)相互接続への比重を上げていくことことで、ネットワーク運用費用のコスト効率化することができます。私が担当しているフロー分析システムはNetFlowデータに含まれるAS番号情報から以下の詳細トラフィック分析結果を提供しています。

• 全体トラフィック分析(①AS全体、②トランジット経由、③IX経由、④PNI経由)
• ASごとの通信インタフェース分析
• インターフェース単位でのAS分析

これらの情報から、効率的なトラフィック交換を実現するためのルーティングポリシーを作っていくヒントを得ることができます。

◾️トランジット経由での分析の例

全体トラフィック分析：トランジット経由の例です。この場合、トランジットで一番多い通信はAS13335 とわかります。それではAS13335はどのインターフェースを使って通信しているのでしょうか。こちらはAS13335のOrigin AS分析でわかります。

◾️Origin AS分析の例

Origin AS分析では、AS13335をOriginとする通信がどのインタフェース経由で通信しているかを分析します。戻りトラフィックは ASBdr3_TO_IX1 ASBdr3_TO_IX2 ASBdr3_TO_Uplink3を使っており、 一番多いのはトランジットである ASBdr3_TO_Uplink3 になっています。このトラフィックをIX経由や直接Peer接続にすることができればネットワークのコスト効率を上げることができ、中継区間も減るので遅延改善も期待できます。フロー分析することでこのようなネットワーク品質向上のヒントが得られるわけです。

NetFlowでのトラフィック計測とは

NetFlowは、Ciscoが開発した統計手法を用いたトラフィック情報計測プロトコルです。UDPの上で実装されています。 ルーターやスイッチなどのネットワーク機器に実装されており、ネットワーク機器を経由する通信を一つのネットワークフローとして捉え、各通信フローをサンプリング取得することで、通信の中身を分析することができます。 NetFlowデータには以下のレコードが記録されています。

• 発信元IP(SrcAS)・送信先IP(DstAS)
• 発信元MAC・送信先MAC
• 発信元AS・送信先AS
• 通信フローの存在期間
• 通信フローの通信量
• 利用プロトコル(TCP/UDP/...)
• 利用ポート
• その他

大量のNetFlowデータを統計解析することで、SNMPインタフェーストラフィック計測ではわからなかった、あるOrign ASのトラフィックがどのインタフェースを経由して通信しているのかといった詳細分析を可能とします。

商用サービス化の課題：NetFlowの複製・分岐

フロー分析サービスは、BBIXユーザ向けのオプションサービスとして提供しています。商用サービスとして提供するためには、データ欠落を発生させない商用品質の確保が必須であり、開発当初、以下の機能実装が課題となっていました。

• バックアップサーバーのためのNetFlowコピー
• いろいろな分析用途プロセスにNetFlowコピー
• 負荷分散のためのNetFlowデータ分岐

NetFlowの分岐・転送可能にすることで、以下のメリットが受けられることが予想されていたためです。

• オンラインサーバーと全く同じデータで開発ができるため、サービスに影響なしで開発が可能
• オンラインサーバーと全く同じデータで開発ができるため、オンラインコードとの結果比較が容易になり、開発効率があがる
• バックアップサーバー・プロセスへの分岐が可能となり、複雑なフロー解析処理でのデータ欠落を防止できる
• ユーザ単位でのNetFlow振り分け転送機能により、オンラインサーバーのユーザ収容分散が可能となる

これを解決してくれたのがpaolo lucenteさん作の pmacct です。

出展：pmacct project www.pmacct.net

pmacctでできること

pmacctは以下の機能を実現できます。

• NetFlow(v5,v8,v9,IPFIX)/sFlow(v2,v4,v5)/pcap/NFLOGを収集し、
• いろんなフォーマットに保存(csv/text/RDBMS/noSQL/kafka/RabbitMQ/...)
• 一つの入力データを複数に分岐・転送可能

pmacctは取り扱う入力データごとに異なるdaemonが準備されており、今回はNetFlow用のnfacctdで分岐処理・コピー処理を行います。

• nfacctd (NetFlow Accouting deamon)
• sfacctd (sFlow Accouting daemon)
• pmacctd (packet capture base accouting daemon)

nfacctdはデフォルトでCSVなどのtext出力のほか分岐転送(tee)処理は標準機能として実装しているので、extentionの追加なしで使えます。

nfacctdによる分散処理構成例

フロー分析システムを構築にあたり、ルーターから直接NetFlowデータを受信して、処理サーバーに分配する１段目と、実際の分析処理を行う２段目の多段構成で組むこととしました。

• １段目 Server1：NetFlow teeサーバー
• ２段目 Server2：online分析サーバー
• ２段目 Server3：開発分析サーバー

１段目：サーバー間分岐転送用tee server

サーバー内の複数プロセスに同じNetFlowデータを分配するには、loopbackアドレスに各プロセス用のUDPポートを設定することで、プロセスへの分配転送が可能になります。

サーバー間分岐転送用tee server設定

設定を行うのはnfacctd用の設定と転送先設定になります。 nfacctdサーバー間転送設定は以下のように行います。ここでの肝はtee_receiversに設定される転送先設定になります。

server1:/etc/pmacct$ cat nfacctd_tee_server1.conf 
daemonize: false
debug: false
logfile: /var/log/pmacct/nfacctd_tee_server1.log
pidfile: /var/pmacct/pid/nfacctd_tee_server1.pid
nfacctd_ip: 10.0.1.20
nfacctd_port: 20001
plugins: tee[server1]
tee_receivers[server1]: /etc/pmacct/tee_server.lst
tee_transparent: true
plugin_pipe_size: 204800

! end of file
server1:/etc/pmacct$

サーバー間分岐転送用転送先設定

転送先設定は以下のように行います。 転送先については、Copyしたい数だけidを増やしていき、転送先のIPとポートを追加することで分岐先を増やすことが可能です。

server1:/etc/pmacct$ cat tee_server.lst
id=1 ip=172.16.1.100:20001
id=2 ip=172.16.1.200:20001
server1:/etc/pmacct$ 

サーバー間分岐転送 tee process起動

設定が完了したら、以下のように -D のdaemon指定で起動するとことで、NetFlowのサーバー分岐転送が開始します。

$ sudo pmacct -D -f /etc/pmacct/nfacctd_tee_server1.conf 

２段目：分析処理サーバーでのサーバー内NetFlow分岐

ルータから受信したNetFlowは前章の手順で、オンラインサーバーと開発サーバーに分配されました。サーバー内においても、用途別にプロセスを分散して同じNetflowデータにて並列処理を行うことで開発効率があがります。

例えば、

• AS分析プロセス
• トレンド分析プロセス
• デバッグプロセス用予備

という感じで、異なる観点での分析プロセスに分配するといった用途分岐です。 また、開発サーバーにおいては、

• AS分析プロセス：オンライン main branch
• AS分析プロセス：開発 development1 branch
• AS分析プロセス：開発 development2 branch

を並行稼働させて、ブランチ毎にロジックを変えて比較しながら開発できれば、正解(main branch)を見ながら開発ブランチごとの結果比較を行うことが可能となります。

サーバー内分岐転送用tee server設定

内部プロセス転送設定は以下のようになります。 設定を行うのはnfacctd用の設定と転送先設定になります。

Server2 online用tee設定

server2:/etc/pmacct$ cat nfacctd_tee_server.conf 
daemonize: false
debug: false
logfile: /var/log/pmacct/nfacctd_tee_server.log
pidfile: /var/pmacct/pid/nfacctd_tee_server.pid
nfacctd_ip: 172.16.1.100
nfacctd_port: 20001
plugins: tee[server]
tee_receivers[server]: /etc/pmacct/tee_server.lst
tee_transparent: true
plugin_pipe_size: 204800
server2:/etc/pmacct$

Server2/Server3 online用 サーバー内プロセス転送先設定

サーバー内の複数プロセスに同じNetFlowデータを分配するには、loopbackアドレスに各プロセス用のUDPポートを設定することで、プロセスへの分配転送が可能になります。

◾️サーバー構成例

• プロセス1用UDPポート： 127.0.0.1 :65001
• プロセス2用UDPポート： 127.0.0.1 :65002
• プロセス3用UDPポート： 127.0.0.1 :65003

このように複数のUDPポートに分岐転送設定しておくことで、必要なプロセスを開いているUDPポート指定で起動させれば同じNetFlowデータをもとに異なる用途のプロセスを並行して駆動することが可能となります。 内部プロセス用転送先設定は以下のように行います。転送先については、Copyしたい数だけidを増やしていき、転送先UDPポートを追加することで分岐先を増やすことが可能です。今回の例ではServer2/Server3ともに同じポートに転送することなっているので、共通になります。

server2:/etc/pmacct$ cat tee_server.lst
id=1 ip=127.0.0.1:65001
id=2 ip=127.0.0.1:65002
id=3 ip=127.0.0.1:65003
server2:/etc/pmacct$ 

Server3 開発サーバー用tee設定

こちらはServer2アドレスとServer3アドレスが変わっている以外は同じ設定になっています。

server3:/etc/pmacct$ cat nfacctd_tee_server.conf 
daemonize: false
debug: false
logfile: /var/log/pmacct/nfacctd_tee_server.log
pidfile: /var/pmacct/pid/nfacctd_tee_server.pid
nfacctd_ip: 172.16.1.200
nfacctd_port: 20001
plugins: tee[server]
tee_receivers[server]: /etc/pmacct/tee_server.lst
tee_transparent: true
plugin_pipe_size: 204800
server3:/etc/pmacct$

サーバー内分岐転送 tee process起動

設定が完了したら、以下のように -D のdaemon指定で起動するとことで、NetFlowのサーバー内分岐転送が開始します。

$ sudo pmacct -D -f /etc/pmacct/nfacctd_tee_server1.conf 

あとは必要な分析プロセスを開いているUDPポートにbindして立ち上げてあげることで、同じNetFlowデータでの並列処理を行うことができます。

まとめ

AS運用を深掘りしていくと、NetFlow/sFlowによる通信フロー分析が必須になってきます。AS/IX運用に携わった経験から自分が欲しいフロー分析サービスを独自開発してきたのですが、商用品質で安定提供していく上では、NetFlowオリジナルデータの分岐転送が大きな課題となっていました。紹介させていただいた方式は安定稼働実績が確認されている手法ですので、参考にしていただければ幸いです。

今回はNetFlowデータをリアルタイム並列駆動する方法でしたが、NetFlowデータをMessage Queueに保存して非リアルタイムに処理する手法もあります。リクエストがあれば紹介していきたいと思います。

ネットワークエンジニアを目指して

はじめに

こんにちは、新卒の松下です。

私はBBSakura Networks（以下、BBSakura）のクラウド接続グループに所属し、主にクラウド接続に関連する業務を担当しています。

突然ですが、新卒のエンジニアの皆さん、自分のことを「エンジニアだ！」と自信を持って言えますか？

正直、私はまだ「エンジニア」と胸を張って名乗るには力不足だなと感じています。そこで今回は、

1. どうしてそう思うのか
2. 技術力を高めるためにやっていること

この2つについてお話しします。同じように「自分はまだまだだな」と思う方の励みになったり、参考になったりすれば嬉しいです！

なぜ、技術力が足りないと思うのか？

私が技術力不足だと感じる理由は大きく2つあります。

1つ目は、単純に勉強が足りないこと。まだまだ知らないことばかりだなと日々痛感しています。

2つ目は、周りのエンジニアがすごすぎることです。

BBSakuraには、ネットワーク業界でも有名なエンジニアがたくさんいます。例えば、障害が発生したとき、瞬時に原因を見抜いて対応策を実施し、問題を解決する姿をすでに何度も見てきました。そのたびに「これがプロのエンジニアか…！」と感動しています。

同じ課の先輩方も本当に優秀で、自ら進んで動き、課に貢献し続けています。さらに、そういった姿勢によって培われた豊富な知識量には毎回驚かされます。

一方で私は、ちょっとした質問に対しても「これで合っているかな？」と資料を確認してしまい、情報を出すのに時間がかかってしまいます。もっとスピーディーに対応できるようになりたいと思う日々です。

それでも、こんな素晴らしい環境で働けているのは本当に恵まれているなと感じています。この環境を最大限活かして、少しでも早く追いつけるよう努力を続けています！

技術力を高めるために

私が技術力アップに一番役立っていると感じるのは、OCXの検証作業です。

毎週、先輩に時間を取っていただきながら、OCXの理解を深めたり、クラウド側の仕様を確認したりしています。例えば、以下のような構成を作り、BGPが正常に動作するか、pingが通るかを確認しています。

（AS番号、ipアドレス、vlanは実際の値から変えてます）

検証構成

この構成は、OCX-Router（v1）を利用し、Google Cloudへ接続する最も基本的な構成です。しかし、この基本的な構成を作るだけでも、BGPに関する知識が必要です。具体的には、BGPを設定する際にピア先が隣接ネットワークであることや、広報する経路を事前に準備しておく必要があるといった知識が求められます。

さらに、OCXとクラウド側では、GUIでの設定が自動的に適用される仕組みがありますが、CPE側のルータにBGPを設定する際は、直接ルータに手動で設定を入れる必要があります。

これらを進める中で、BGPの理解に加え、Google CloudやOCXの各コンポーネントに関する知識も必要であり、全てが正しく設定されて初めてpingが通るようになります。

その分、pingが通った瞬間や、BGPのステータスが「UP」になる時には、大きな達成感を感じられます。

また、一度検証を終えた後に、もう一度ゼロから構成を作り直すこともおすすめです。理解がさらに深まることを実感できます！

おわりに

こうした検証作業を通じて、自分が少しずつ成長していることを実感しています。最終的な目標は、どんなトラブルにも冷静に対応できるエンジニアになることです。

これからはネットワークの知識をさらに磨きながら、開発経験も積むことで、ソフトウェアにも精通したエンジニアを目指していきます。

この記事が、技術力に自信が持てず悩んでいる方の力になれば嬉しいです！最後まで読んでいただき、ありがとうございました！

ライブラリのアップデート運用を効率化した話（Dependabot の導入と成果）

目次

はじめに

OCX開発チームに所属しているアプリケーションエンジニアのokunoです。

多くの開発チームがライブラリのバージョン管理に頭を悩ませているのではないでしょうか。

私たちのチームも同様で、バージョンアップに気付く人が少数派だったり、実際に問題が発生したら対応したり、対応する頃には影響範囲が大きくなっていて確認が大変だったりと、 属人化やセキュリティリスクや非効率が課題となっていました。

これらの課題を解決するために、ライブラリのアップデート作業を自動化するアプローチを進めることにしました。
しかし、新たに浮かび上がったのが 自動化のリスクをどう管理するか という課題です。

というのも、以前はライブラリの自動アップデートのために Renovate というツールを使っていましたが、自動アップデートされたライブラリが原因でエラーが発生しました。
これをきっかけに、ツールと運用を全面的に見直すことにしました。

そこで現在は Dependabot を導入すると共に設定や運用プロセスを見直し、
セキュリティ向上と運用効率化を実現しました。

本記事では Dependabot 導入の背景や設定、得られた成果を紹介します。

背景

ここ数ヶ月、私のチームでは Renovate というツールでライブラリの自動アップデートを運用していました。

ところがある日、Staging環境で自社のサービス(OCX)を操作していたらエラーが発生。
調査の結果、Renovate がライブラリを自動アップデートした際、
適用されたバージョンはサービスと互換性がないことが判明しました。

Renovate は便利ですが、運用設計や制御設定が不十分だったので、
一時的な対策として自動アップデートを無効化しました。

しかし、
自動アップデートを有効化しなければ セキュリティを守れない
自動アップデートを有効化したままでは 障害リスクを避けられない

このジレンマを解消するため、ツールを含めてプロセス全体の見直しを行うことにしました。

前提

開発環境

• ソース管理: GitHub Enterprise
• 対象リポジトリ: 組織のプライベートリポジトリ
• リポジトリ構成: Monorepo
• マージ方法: Merge Queue
• アーキテクチャ: モジュラーモノリス（シングルモジュール）
• 対象ライブラリ: Go言語のライブラリ

リポジトリ構成

root
　├── .github
　├── dockerfiles
　├── go
　│   ├── services
　│   ├── batch
　│   ├── pkg
　│   └── go.mod

ツール選定

GitHubネイティブツールの Dependabot を選定しました。
理由は以下の要件を満たし、かつ GitHub Actions と連携しやすいと思ったからです。

1. メジャーバージョンはアップデートしないこと：GitHub Actions で対応
2. 指定したライブラリはアップデートしないこと：GitHub Actions で対応
3. 設定がシンプルで運用が楽なこと（最重要）

運用設計

全体フロー

1. Dependabot のアップデート検知とプルリク作成
   ・毎週月曜8時、Dependabot がライブラリのアップデートを検知し、プルリクを自動作成する。
2. GitHub Actions による自動マージ判定
   ・自動作成されたプルリクが条件を満たしていれば、mainブランチに自動マージする。

自動マージの条件

以下の条件を全て満たすプルリクのみ、mainブランチへ自動マージする。

1. マイナーバージョン以下のアップデート
   ・後方互換性が失われるリスクを避けるため、メジャーバージョンのアップデートは対象外とする。
2. 除外リストに該当しないライブラリ
   ・利用箇所のテストカバレッジが不十分で、影響範囲の大きいライブラリは、除外リストに定義して対象外とする。
3. コンフリクトなし＆CI成功
   ・プルリク内でコンフリクトが発生せず、自動テストなどのCIが成功した場合のみ対象とする。

手動対応フロー

1. 確認と手動マージ
   ・自動マージされなかったプルリクには担当者を割り当て、影響範囲を確認する。
   ・問題がなければmainブランチに手動マージする。
2. 継続的な改善
   ・初めての運用となるため、実際に進める中で新たな改善点が見つかったら状況に応じて柔軟に方法を見直す。

実装例

Dependabot の設定

以下は Dependabot が週1でライブラリのアップデートを検知し、プルリクを作成するための設定ファイルです。
Go のついでに GitHub Actions と Docker(ローカル開発用) も自動アップデートの対象としました。

# .github/dependabot.yml
version: 2

registries:
  github-private:
    type: git
    url: https://github.com
    username: x-access-token
    password: ${{secrets.DEPENDABOT_TOKEN}} # repo権限ありのPAT

updates:
  - package-ecosystem: "gomod"
    registries:
      - github-private
    directory: "/go"
    schedule:
      interval: "weekly"
      day: "monday"
      time: "08:00"
      timezone: "Asia/Tokyo"
    commit-message:
      prefix: "chore"
    open-pull-requests-limit: 20

  - package-ecosystem: "github-actions"
    registries:
      - github-private
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"
      time: "08:00"
      timezone: "Asia/Tokyo"
    commit-message:
      prefix: "chore"

  - package-ecosystem: "docker"
    registries:
      - github-private
    directory: "/dockerfiles"
    schedule:
      interval: "weekly"
      day: "monday"
      time: "08:00"
      timezone: "Asia/Tokyo"
    commit-message:
      prefix: "chore"

GitHub Actoins のソースコード

以下は Dependabot が作成したプルリクを、条件付きでmainブランチに自動マージするためのワークフローです。

# .github/workflows/dependabot-auto-merge.yml
name: Dependabot Auto-merge

# Dependabot に secrets を参照させるため pull_request_target を使用しています。
# ※ mainブランチのコンテキストで実行される
on: pull_request_target

defaults:
  run:
    shell: bash

concurrency:
  group: ${{ github.workflow }}-${{ github.event.pull_request.head.ref }}
  cancel-in-progress: true

jobs:
  auto-merge:
    # Dependabot が作成したプルリクエストのみ処理対象
    if: github.event.pull_request.user.login == 'dependabot[bot]'
    runs-on: ubuntu-latest
    timeout-minutes: 5
    steps:
      - name: Generate App token
        id: app-token
        uses: actions/create-github-app-token@v1
        with:
          app-id: ${{ secrets.APP_ID }}
          private-key: ${{ secrets.PRIVATE_KEY }}
          owner: ${{ github.repository_owner }}

      - name: Dependabot metadata
        id: dependabot-metadata
        uses: dependabot/fetch-metadata@v2
        with:
          github-token: ${{ steps.app-token.outputs.token }}

      # メジャーバージョンは自動マージしない
      - name: No major version updates
        run: |
          if [[ "${{ steps.dependabot-metadata.outputs.update-type }}" == "version-update:semver-major" ]]; then
            echo "Major version update found: ${{ steps.dependabot-metadata.outputs.dependency-names }}"
            exit 1
          fi

      # 特定のライブラリは自動マージしない（除外リスト）
      - name: Do not update the specified library
        run: |
          IGNORE_LIBRARIES=(
            "github.com/bbsakura"
            "gorm.io/gorm"
            "gorm.io/driver/postgres"
          )
          for LIB in "${IGNORE_LIBRARIES[@]}"; do
            if [[ "${{ steps.dependabot-metadata.outputs.dependency-names }}" == *"$LIB"* ]]; then
              echo "Ignored library found: $LIB"
              exit 1
            fi
          done

      # mainブランチに自動マージする
      - name: Enable Auto-merge
        run: |
          gh pr review --approve "$PR_URL"
          gh pr merge --auto --squash "$PR_URL"
        env:
          PR_URL: ${{ github.event.pull_request.html_url }}
          GH_TOKEN: ${{ steps.app-token.outputs.token }}

成果

直近の成果

項目	結果	ベネフィット
検知されたアップデート総数	80件	バージョンアップを早期把握
自動マージされた件数	71件(自動マージ率88%)	手動作業を削減、工数効率化
セキュリティ対応件数(CVE)	5件	脆弱性の対応漏れを防止
自動マージされなかった件数	9件	本番障害を未然に防止

自動マージされなかった9件については、互換性や自動テスト失敗の確認が必要なものです。
これによりサービスのセキュリティを向上させつつ、障害リスクをゼロに抑えました！

今後の改善点

1. 自動アップデート対象の拡大
   現在、特定のライブラリ利用箇所についてはテストカバレッジが不足しているため、自動アップデート対象から除外している。
   今後はテストコードを拡充することで、より多くのライブラリを自動アップデート対象に含められるようにしたい。
2. 全体最適化の推進
   現状、フロントエンド(JS/React)や他チームもライブラリのアップデート作業を実施する必要がある。
   これらのプロセスも自動化し、全社的な効率化と最適化を目指したい。

さいごに

この取り組みにより、セキュリティ向上や障害リスク軽減を実現しつつ、
ライブラリのアップデート検知から適用までのリードタイムを削減することにより、
サービス価値向上とチーム生産性向上に貢献できました。

私たちのOCX開発チームは サービス価値向上とチーム生産性向上 を常に目指し、
日々の開発だけでなく、こうした改善活動にも積極的に取り組んでいます。
例えば、オンプレからクラウドへの移行、システムアーキテクチャの改善、ER図やテーブル設計書の自動生成、AIを活用したコードレビューの自動化など、様々な施策を進めています。

これらの活動を支えているのは、
目的と方向性をすり合わせ、挑戦する人には無限の裁量が与えられる という文化です。

「良いサービスやチーム作りに挑戦したい！」 と思う方は、ぜひ私たちのチームに来てください！
→ 応募はこちらから

モバイルコアの開発ができるようになるまで

はじめに

こんにちは、BBSakura Networks のシステム開発部モバイル開発グループの平山です。

普段は主にモバイルコアの開発、運用などを担当しております。

今回は新卒でありモバイルの知識が全くなかった私がどのようにモバイルコアの開発、運用業務に参加していったかについてご紹介させていただきたいと思います。

自己紹介

私は、2024年4月から社会人になった新卒です。6月までは親会社で研修を受けており、7月よりBBSakura Networksに入社しました。

大学時代は情報系を専攻していたものの、研究活動でC言語のコードを書いていて多少プログラミングができるだけで、ネットワークの知識やモバイルの知識は全くありませんでした。

モバイル開発グループに入ったきっかけ

私は入社後、各部署を回り、各部署の説明をいただく機会がありました。その中でモバイル開発グループの方の自己紹介の中で「好きなエディターはVim」という紹介があり、私は「Vim使えるのかっこいい！」「本物のエンジニアっぽい！」と思いました。そこからモバイル開発に興味を持ちました。そして元々ソフトウェア開発をしたいと思っていたのでモバイル開発グループを希望し配属されました。

勉強方法

モバイルコアの開発に必要な知識は多岐に渡り、正直何から勉強していいかわからない状態でした。そんな中先輩が紹介してくださったチュートリアルや本を用いて勉強を始めました。ここでは私がモバイル開発に参加するまでに、勉強に利用したものをご紹介したいと思います。

• A Tour of Go
• Diameterプロトコルガイド
• 続・5G教科書

A Tour of Go に関しては学生時代C言語のコードを書いていたこともあり、構文がある程度似ていてさほど苦戦せずにチュートリアルを終えることができました。もちろんGo言語の全てを理解し習得しているとは思っていません。

Diameterプロトコルガイドと続・5G教科書は初めて聞く単語の連続で初めて読んだ時は全く理解できませんでした。読み始めても知らない単語が出てきて調べるの連続で読み進めるのに多くの時間を使ってしまいました。今も完全に理解しているとは言い難い状態です。

モバイルコア開発の苦労したところ

3GPP

3GPP（3rd Generation Partnership Project）とは、移動通信の標準化を目的とした国際的な組織です。1998年に設立され、携帯電話の技術規格を策定するために運営されています。特に以下の通信技術の標準化を主導しています。

• モバイル通信技術の標準化

  • 　3G (第三世代移動通信)
  • 　4G LTE (Long Term Evolution)
  • 　5G (第五世代移動通信)
  • 　今後の通信技術（6Gなど）

• 技術仕様と標準の策定

  • コアネットワーク（EPC, 5GC）
  • 無線アクセス技術（RAN: Radio Access Network）
  • IMS（IP Multimedia Subsystem）などの関連技術

• グローバル統一規格の提供
  各国や地域の通信事業者やメーカーが共通で利用できる規格を提供することで、世界中のモバイル通信の相互運用性を実現しています。

モバイルコアの開発をするためにはこの3GPPの仕様を読まなくてはなりません。日本語で書かれていても理解が難しい内容が英語で書かれているため自分の欲しい情報を探すのは苦労しました。

また3GPPの仕様を実装に落とし込むことにも苦労しました。仕様書を読んで実装するというのは初めてだったので、過去のコードを見ながら、自分が実装しようとしているところ同じ、似ているコードはないか探しながら実装しました。

Git

Gitの使い方にも大変苦労しました。チームで同じコードを共有しながら開発することも初めてだったので初めは戸惑いました。正直、Git の使い方を覚えるのが一番大変だったかもしれません。何度も先輩方に教えていただきながら、使い方を覚えていきました。

初めての開発

一通り勉強を終えたあと、初の仕事としてIDRの実装を行いました。IDRとはInsert Subscriber-Data Requestの略でDiameterプロトコルで使用されるメッセージの1つです。ネットワーク内で加入者データを更新または挿入する際に使用されるメッセージです。この仕事を聞いた時は、IDRという言葉を聞いたこともなく何のことなのかもわからず仕事を終えられるか不安でした。

まずは3GPPを読んでIDRとは何か調べる作業から始めました。上述したように3GPPを読んで理解するのは大変でした。完全に理解していない状態で、試行錯誤しながら実装を始めました。

実装を進める中で、次々と分からないことが出てきました。その度に先輩に助けていただきながら作業を進めました。何度も私の質問に丁寧に対応していただき、時間を割いてくださいました。ペアプロを行ったり、一緒に3GPPを読んだりと、多くのサポートをいただきました。先輩の助けがなければ、この仕事をやり遂げることはできなかったと思います。心から感謝しています。

まとめ

以上の経験を通してなんとかモバイルコアの開発や運用業務を行っています。まだまだ勉強していかなければいけないことはたくさんあると思っています。たくさん勉強して強いエンジニアになりたいと思っています！

この記事の大半は私の個人的な感想となっていますが、少しでもお役に立てれば幸いです。

最後に最後までお読みいただき、ありがとうございます。

入社から3ヶ月が経ちました

はじめに

こんにちは、新卒の外山です。

BBSakura Networks（以下BBS）のシステム開発部に所属し、主にソフトウェア開発を行っています。

BBIXでの新卒研修が終わった7月頭にBBSに入社してから3ヶ月が経ったので、やったことや感じたことを振り返ります！

Webアプリ研修

初日のオンボーディングでは、BBSの会社説明や社内制度の説明を受け、とがった技術者が多くいる環境にとてもワクワクしました。

その後、エンジニアとして配属された新卒メンバーは約1ヶ月間、Webアプリ研修に取り組みました。 内容はざっくり、以下の2つです。

1. Webブラウザにサイトが表示される流れを調査せよ

2. Protocol BuffersでAPIを実装し、フロントエンドを持つWebアプリを実装せよ

1. Webサイト表示の流れ

形式が指定されていなかったので、私は主に以下についてドキュメントに書き出しました。

• DNSサーバーへの問い合わせがどのような順で反復的に行われるのか

• HTTPリクエスト送信のL4,L3,L2ヘッダーの中身とそれを誰がどう読み書きしてサーバまで送られるのか

検索すると個別の情報として得られるものを、一連の流れに落とし込んで理解するのが難しいと感じました。

結局一次資料に目を通せていないのは反省点ですが、元々ゼロの知識だったインターネットに興味が湧いてきたので自分の中では満足感がありました！

一方で、全体の講評は思いの外厳しかったです。 ネットワークが好き・技術が好きなGeekのエンジニアの方々から見ると、新卒の発表は圧倒的に知識が浅く視野も狭いからだろうな、という気持ちです。

興味が湧き、勉強する意欲が高まったので、精進します！

2. Webアプリの実装

この研修で最終的に実装したのは、最低限のCRUD機能を持ったPetStore Appです。

私はこれまでにもアルバイトでのWeb開発経験がありましたが、見様見真似で機能を付け加えることばかりでした。

しかし今回はゼロから自力で動くものを作る必要があり、まず最初にDockerやGo、Protobufの勉強をしないといけない、というところで苦労しました。

以下、参考にした主なWebサイトです。

• Dockerの参考書

• Bufチュートリアル

同期と集まって相談しあったり、どうしても動かないところの解決には先輩方に半日くらい付き合っていただいたりして、UIの作り込みはさておきなんとか動くアプリを作ることができたので達成感でいっぱいです。

BBSのWebアプリ研修は今年が初めての試みらしくざっくりとした課題内容に最初は戸惑いましたが、好きに勉強させてもらえたこの機会にとても感謝しています！

PetStore Appの一画面

ちなみに、Postgresqlで個人的に一番つまったところの解決法を簡単に書いた記事はこちら。

業務開始

8月1日から、配属先の業務を開始しました。

本番環境での最終調整の段階に入っていて、ようやく2ヶ月間取り組んできたタスクが完了しそうな予感がしています！

netbox*1の登録情報が機器の設定と一致しているか（netboxに正しく入力がなされているか）を検証するバッチの実装を行いました。

ネットワークを無知な状態で始めたので、最初にタスクの説明をされた時はなにもわからない状態でしたが、

• MIBとは何か、何ができるのか
• VMを建てそこで開発する
• Linuxでのtimerやlog管理

など初めて知って、調べて、手を動かすうちになんとか最終段階まで辿り着きました。

他にも、CCNA研修やラボの使い方研修などに参加しました。思っていた以上に学ぶことが多く、1年目の今は新鮮な気持ちで働いています！

まとめ

• 知識はまだまだ浅いけれど、ネットワークに興味が湧いた
• ゼロから開発する経験でDocker、Protobufを勉強した
• 業務でも新しい知識と経験を得ている

以上、3ヶ月経った時点で楽しく業務に取り組んでいるという話でした。

最後まで読んでいただきありがとうございました！

*1:ネットワーク機器の接続やIPアドレスの割り当てなどを一元的に管理できるツール