IETF 116 Hackathon に参加して SRv6 の開発をしてきました

こんにちは。テックリードでモバイルコアを開発しているチームのリーダーの日下部 (@higebu) とチームメンバーの早坂 (@takemioIO) です。

IETF 116 Hackathon にて、以下の二つのHackathonに参加してきましたので何をしてきたのかなどをご報告したいと思います。

  • BGP-MUP SAFI Implementation and Interop (日下部、早坂)
  • SRv6 Data-Plane Visibility (早坂)

IETF 116 Hackathon について

IETF 116 Hackathonについて知らない方もいると思いますので、簡単に紹介すると、無料で参加できる IETF 116 の中のイベントの1つで、RFC、ドラフトの著者などと開発者や運用をしている人などが集まって、実装してみたり、相互接続テストをしてみたりして、仕様に対する理解を深めたり、議論したりするための場です。

今回は 3/25(土)(9時30分~20時)と3/26(日)(9時30分~13時, 14時から結果報告)の2日間開催され、会場はパシフィコ横浜ノースでした。

飲み物、昼食、夕食(ビール付き)も無料で供給され、ずっと会場でハッカソンしていられるようになっており、スポンサー企業やスタッフの皆様にはとても感謝しております。

スケジュールやスポンサー企業について、詳しくは IETF 116 Hackathon Wiki を見てください。

IETF 116 Hackathon Project Map

BGP-MUP SAFI Implementation and Interop について

BGP-MUP SAFI Implementation and Interop

標準化中の BGP-MUP SAFIのインターネットドラフト を参考に実装した製品やOSSを持ち寄って相互接続テストを行ったり、詳細な仕様を確認したり、バグを直したりする会です。

詳しくは IETF 116 Hackathon WikiのBGP-MUP SAFI Implementation and Interop を参照してください。

BBSakuraから参加した二人は下記の3つのOSS実装で参加しました。以下に参加開始時点での実装状況と実装者を示します。

  • ExaBGP (@takemioIO)
    • CLIで設定した4つのルートタイプの送受信ができる状態
  • GoBGP (@higebu)
    • CLIで設定した4つのルートタイプの送受信ができる状態
  • FRR (@higebu)
    • 4つのルートタイプのencode/decodeができそうでできない状態 😇

GoBGPでの実装については下記の記事もご参照ください。

blog.bbsakura.net

他に、Arrcusさん、Ciscoさん、Furukawaさんの開発版の製品がエントリーされていました。

BGP-MUP SAFI Implementation and Interopハッカソンの様子

1日目

Breakfast

簡単な挨拶と、各チームの紹介の後、相互接続テストの結果を書くスプレッドシートと、テスト環境として使う CML2 (Cisco Modeling Labs) へのアクセス方法が共有されました。

相互接続テストをすぐに始められるようにするため、日下部と早坂は事前にCML2でGoBGPやExaBGPを動かすための cloud-initYAML ファイルを作っていました。

(補足:CML2で使えるUbuntuイメージは cloud-init によってネットワークの設定やパッケージのインストールなどが行えるようになっています。)

しかし、今回利用したのが3/3にリリースされたばかりの CML 2.5 で、普段使っていたのが CML 2.4 だったためか、 GoBGP, ExaBGPを動かすためのcloud-init がうまく動かず、何とか動かないかと格闘しているうちに、午前中が終了しました。。。

結局、 cloud-init では default_user cisco の設定と、ネットワークの設定のみに絞ってVMを起動し、コンソールから GoBGP などをインストールする方式に変更しました。

最終的な cloud-init のYAMLやGoBGP, ExaBGPのコンフィグやアンチョコは下記のgistに記載しています。

FRRについては前述の通り動作がまだ不完全だったため、Hackathonらしく現地で開発をしていました。 そのために並行して、SoftBankの藤田さんに開発に参加してもらい、FRRのデバッグを進めていただくため、開発環境を整えていただいていました。

いろいろやっているうちに、昼ご飯のカレーがなくなっていたことが悲しかったのを覚えています。

午後にとある実装と接続テストを行ったところ、Attribute Length Errorが返されてしまいました。

そこで、いろいろと切り分けをしていった結果、Next hopをIPv6アドレスにするとType 2、3、4(Direct Segment Discovery Route、Type 1 & 2 Session Transformed Route)は受け取ってもらえることがわかりました。

さらに Type 1(Interwork Segment Discovery Route) では Prefix が IPv4 の場合は /32IPv6 の場合は /128 のみ受け取ることができるということがわかりました。

この仕様の認識の違いは翌日には修正されていました。スピード感が早くHackathonらしいなと非常に驚きました。

FRRの状況はさらにSoftBankの堀場さんがCML2上で開発に途中参戦し、夜までには Type 3、4(Type 1 & 2 Session Transformed Route)の受信ができるようになっていました。

そのときのコミットが こちら です。

2日目

前日に問題があった実装との相互接続テストを実施し、問題が解消されていることを確認していきました。

当日はType 4(Type 2 Session Transformed Route)に含まれるTEIDの処理に問題があった実装もあり、仕様に関する認識の違いもありましたが最終的には相互接続を達成しました。

Arrcusさんでは ルートリフレクタとしても動作するMUP-CとMUP-GW、MUP-PEを用意し、MUP-C経由でMUP-GWやMUP-PEにRoute Targetを使って、Type 3、4(Type 1 & 2 Session Transformed Route)の経路情報がimportされるように設定されていて、さすがだなと思いました。

また、FRRの開発では、慶応SFCの澤田さんも参加し、主に Prefix Length の扱いについてソースを追って、正しい実装はどうなるかを考えていました。

最終的にFRRを除いた他の実装については全ての Route Type の相互接続テストをパスできました。

FRRについては、Type 3、4(Type 1 & 2 Session Transformed Route)を10個ずつ受けても1個しか表示されないという状態からスタートでしたが、SoftBankの堀場さん、藤田さん、慶応SFCの澤田さんのお力で全て表示されるところまで進みました。ありがとうございました 🙇

FRRのBGP-MUP SAFI対応は完成までまだまだやることがたくさんある状態なので、引き続き協力してくれた方々と一緒に実装していきたいと思っています。

BGP-MUP SAFI Implementation and Interop の結果

前述の通りFRR以外の全ての実装が相互接続を完了することができました!

Project results presentations については松嶋さんの発表資料を貼っておきますので、こちらをご参照ください。

このハッカソンからBGP-MUP開発者が勘違いや失敗しやすい注意点の洞察も得れました。 以下にその知見を共有したいと思います。

RFC 8950 Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop

RFC 8950 Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next HopRFC 5549 が更新されたものです。

今回のテスト環境ではBGPのトランスポートプロトコルIPv6です。

しかし広報する経路情報に含まれるプレフィックスIPv4(つまりAFIがIPv4)の場合があります。その場合にNLRIに含まれるNext hopにIPv6のみを受け入れる実装とそうでない(IPv4も受け入れる)実装がありました。

GoBGPでは最初はコマンドでIPv4のNext hopを入れてしまっていたため、エラーを返されていました。

経路を広報する際に何らかの方法で Next hop を決める実装をしている場合は、 AFI が IPv4 でもトランスポートプロトコルIPv6 の場合は IPv6 の Next hop を入れるようにしましょう。

RFC 8950 には SAFI = 128,129 のときにRDを付けるということが書いてあり、 SAFI = 85 のときはどうする?という話もありましたが、その場ではなしで全実装が動いたので、一旦なしで良いと思っています。

Type 1: Interwork Segment Discovery Route (ISD) の Prefix
         +-----------------------------------+
         |           RD  (8 octets)          |
         +-----------------------------------+
         |       Prefix Length (1 octet)     |
         +-----------------------------------+
         |        Prefix (variable)          |
         +-----------------------------------+

ISD の Prefix は明確に Prefix Length (1 octet)Prefix (variable) と書いてあるのですが、 3GPP 5G の場合は gNodeB の N3 インターフェースのアドレスになるということからか、 /32 固定で実装してしまうことがあります。

書いてある通り、BGPで一般的に使われている Prefix として実装しましょう。

Type 4: Type 2 Session Transformed Route (ST2) の TEID
      +-----------------------------------+
      |           RD  (8 octets)          |
      +-----------------------------------+
      |      Endpoint Length (1 octet)    |
      +-----------------------------------+
      |      Endpoint Address (variable)  |
      +-----------------------------------+
      | Architecture specific Endpoint    |
      |         Identifier (variable)     |
      +-----------------------------------+

Endpoint Length が BGP でよくある Prefix Length と同等に見えますが、これには Architecture specific Endpoint Identifier (variable) のビット長も含んでいます。

また、 Architecture Type が 3GPP 5G の場合の TEID は下記の通りですが、これも Prefix のように1ビット単位の可変長になっています。

      +-----------------------------------+
      |          TEID (0-4 octets)        |
      +-----------------------------------+

こちらは複数の実装で、仕様通りに実装できておらず、ExaBGPGoBGPでもハッカソンの数日前に修正しました。

モバイルネットワークをやっていると TEID も Prefix のように扱って集約できるようにするという発想にならない感じがしますが、経路として扱えば集約できるので、そのように実装しましょう。

SRv6 Data-Plane Visibility

このHackathonは標準化中の SRv6のIPFIXに関するインターネットドラフト を参考に実装を行う会です。

詳しくは IETF 116 Hackathon WikiのSRv6 Data-Plane Visibility を参照してください。

ここでは他社のチームと一緒に行なっており NTTCom の三島さんからのお誘いでBGP-MUP SAFI Implementation and Interopと並行して早坂(@takemioIO)が参加しました。

SRv6 Data-Plane Visibility の結果

成果物がこちらです https://github.com/watal/ietf116_srv6_data-plane_visibility

このプロジェクトの中では、XDPでSRv6パケットのSRHを受け取りそれをIPFIXに詰める仕組みを実装しようとしました。

XDPの採用理由としてはそもそもこのHackathonはVPPを利用した実装を行うチームがあり、それなら同じパケット高速化の仕組みを持つXDPでも使えるようにしたいな!ということで僕らはXDPの採用に至りました。

チームなので分担して開発を行なっており、自分はこの中でもXDPを利用したSRv6のパケットを受け取ってパースしてユーザーランドに渡す部分の実装を行い実装を完了させました。

ですが最終的な結果としては残念ながら IPFIXのテンプレートの中にSRHの情報を入れて渡す統合の部分が終わらずデモは出来ませんでした。 しかし時間があればできるものだったと思いますので今後も実装を続けていこうと思います!

最後に

BGP-MUP SAFI Team の皆様、相互接続テストを実施していただき大変お世話になりました。 GoBGP、ExaBGPでは相互接続テストを通過させることができ、仕様理解も深まりました。

BGP-MUP SAFI Implementation and Interop の Champion でドラフトの著者の松嶋さんには、 ハッカソンに誘っていただきました。また期間中何度も仕様を確認させていただきました。ありがとうございます。

古河の林さんには、GoBGP、ExaBGPの実装について多くのご指摘をいただきました。 林さんのおかげで期間中に相互接続テストが完了できたと思います。大変感謝しております。

また、NTT Comの三島さん、深川さんには、SRv6 Data-Plane Visibility に誘っていただきました。ありがとうございました。

皆様のおかげで大変良い経験になりました。

SRv6 MUP や SRv6 Data-Plane Visibility 関連の活動は続けていくつもりですので、引き続きよろしくお願いいたします :bow:

Wrap up

#ふりかえりカンファレンス 2023で、ラボ構築についてお話ししました

  • 登壇しました
  • 登壇の経緯
  • お話しした内容
  • 登壇内容についてのふりかえり
    • インフラ構築にふりかえりを導入できた要素はなんだったのか
    • 失敗を共有したチームは活性化されるのか
  • 楽しかった!
  • 石狩ラボ構築プロジェクトのその後 - 発表内容後半の内容ご紹介
    • 初回構築後、ふりかえりを終えて
    • ふりかえりのその後、プロジェクトをさらに進めてみて
    • 石狩ラボと、ラボ構築プロジェクトの今後

登壇しました

retrospective.connpass.com

以前このブログにも書いた「石狩ラボ構築プロジェクト」についてお話ししてきました。

発表資料はこちら。

speakerdeck.com

今回のふりかえりカンファレンスのテーマは「ふりかえりに味変を」でした。

2021年でホップ、2022年でステップ、ときて、2023年でジャンプ、といった具合でしょうか。 守破離でいうと破のフェーズのテーマになります。

ふりかえりカンファレンスのふりかえりと、2023年度開催のお知らせ - ふりかえり実践会

ソフトウェア開発の文脈で語られることの多い「ふりかえり」をインフラ構築プロジェクトに適用してみた事例として、味変というよりは、白米をいつものお茶碗と違う器に盛ってみた、みたいなおはなしができたのかなと思います。

登壇の経緯

RSGT2023 に参加して、「もっと行動し、発信していきたい」と思った勢いで、プロポーザル受付中だったこのカンファレンスにプロポーザルを出しました。

ちょうど石狩ラボプロジェクトにふりかえりを導入してチームが良くなってきていた頃だったので、ふりかえりカンファレンスにぴったりな話ができるはずと思って書きました。

プロポーザル採択の連絡をいただいたのが3月頭。

プロジェクトとしては、最初の構築作業でうまくいかず、年度内のリカバリを目指して頑張っている時期でした。

4月頭に登壇することになったので、登壇時にカッコつけたい気持もあり、3月中のリカバリ成功への思いが強くなりました。

自分に(メンバーにも?)プレッシャーをかけながら準備して、結果3月末のリカバリを成功させることができました。

発表の中でこの話をしたところ、「そこでプレッシャーかけてもちゃんと成功するだけの土台ができてたのか。すごい」とコメントいただけて嬉しかったです。

登壇では無事に「リカバリ成功しました」というおはなしができたので、構築作業自体の成功と合わせて二度おいしい経験となりました。

登壇駆動でのプロジェクト推進、みなさんにもオススメです!

お話しした内容

石狩ラボ構築プロジェクトについては以前このブログに記事を書いたことがあります。

これらは、去年12月、初回の構築作業に失敗し、初めてふりかえりを行った直後に書かれました。

今回の発表では初回構築とふりかえりまでの経緯と、ふりかえりの後チームがどう変わっていったのかをお話ししました。

発表資料に沿った内容の紹介は長くなるので記事の最後、「続きを読む」以降に書きました。詳細はそちらをご覧ください。

すごくざっくり書くと、以下のような内容でした。

  • ふりかえりをやったおかげで初回構築失敗のリカバリに向けてやることが明確になったし、チームの雰囲気もよくなり、プロジェクトの進みがよくなった
  • 結果、3月末に構築のリカバリに成功した!
  • インフラ構築にもふりかえりは有効だとわかった
  • チームビルディングが大事、ふりかえりが大事、というあたりまえのことが大事だとわかった
  • 知識や技術をつけるにも、プロジェクト推進のスキルを上達させるにも、失敗の経験が大事
  • 失敗からリカバリさせようというモチベーションのためには、チームで悔しいという感情を共有することも大事

登壇内容についてのふりかえり

インフラ構築にふりかえりを導入できた要素はなんだったのか

カンファレンスのふりかえり*1の中でフーリーから「インフラ系ってふりかえりの文化が浸透していないように感じる、そこにふりかえりを導入できたのはなんでだろう」というコメントがありました。

これには以下のような要素があるかなと思います。

  • 私が「ふりかえりはどんなプロジェクトでもやるものだ」と思っていたこと
  • 構築作業という、わかりやすい区切りがあったこと
  • チームメンバーが失敗の経験と、悔しい気持を共有していたこと

上の2点によってふりかえりが提案され、下の1点によって、それがチームに受け入れられたのかなと思います。

また、その後ふりかえりの効果をチームが感じられたことによって、毎週の習慣・文化として浸透していったと感じています。

失敗を共有したチームは活性化されるのか

発表の中で「失敗の経験を共有していることが大事だ」という話をしました。

社内でレビューしてもらったときにチームメイトが「チームが停滞している気配を感じたときはあえて成功率の低いイベントを設けて失敗を共有するのもいいのかもしれない」と言っていました。

これを見て、ただ失敗するだけではチームは活性化されなさそうだなあ、他の要素が必要そうだけど、なんだろう、と考えていました。

失敗したあとに「悔しい」「挽回するぞ」という感情?「次はやれるはず」という自信?「会社のお金と時間を使って失敗したままにはできない」という意識?などと考え、議論してみたけど、答えが出ないまま発表に臨みました。

カンファレンスでは、内海さん@utsumit が「チームの状態を「即興性」の視点からふりかえってみよう~素早く学習できるチームになるために~」という発表をされていました。

インプロバイザー(人やチームの「即興性」を引き出す人)として活躍されている内海さんが、即興性の3要素を「自発性」「利他性」「挑戦性」として、挑戦性を高めるには失敗が大事だとお話しされていました。

失敗ならなんでもいいというわけではなく、大事なのは安全に失敗できる領域をつくること、実際にチャレンジすること、そして失敗を素早くオープンにすることだそうです。

これを聞いて、チームの活性化に必要な失敗以外の要素は、その失敗がコントロールされたものであることなのかも、と、納得しました。

もちろん仕事をしていく上ではコントロールできない失敗もたくさんありますが、チームを活性化させるためには、コントロールされた失敗を利用するのがよさそうです。

そして、この石狩ラボはコントロールされた失敗をするための場として作っているのだったな、と、思い出させてもらいました。

内海さんの発表の中で挑戦性のお話はほんの一部でした。全体はぜひこちらを見てみてください。

チームの状態を「即興性」の視点からふりかえってみよう - Speaker Deck

楽しかった!

まる一日ふりかえりについて語りつづける、とっても楽しいカンファレンスでした。

ソフトウェアを作っているエンジニアや PdM, PjM などが多かったであろうカンファレンスに、BBSakura が取り組んでいるインフラ構築の話、ネットワークの話を持ち込めたのも、ふりかえりってソフトウェア開発のためだけのものではないという意味で、良かったなと思います。

そして、今後も「コントロールされた失敗をできる場」であるラボを拡張し活用していきたいとあらためて思いました。

ふりかえりカンファレンス、参加者向けにアーカイブ動画か公開される予定だそうです。

参加者と一緒なら他の方も視聴してよいそうなので、参加者を見つけて、公開されたら一緒に見せてと誘ってみてください。

*1:ふりかえりカンファレンスの最後にはカンファレンス自体のふりかえりがあります。カンファレンスのキャラクター(?)「フーリー」と「カエリー」が各セッションの内容をふりかえる時間です。

続きを読む

BBSakura公開社内勉強会のタイムテーブルが決まりました #bbsakura_open_study

BBSakura公開社内勉強会概要

来週、2月16日の14時から、BBSakura Networksの社内勉強会拡大版を社外のみなさまに公開して開催します。

bbsakura.connpass.com

connpassからご参加登録受付中です!

開催までの経緯、想いは以下のブログ記事をご覧ください。

blog.bbsakura.net

タイムテーブルが決まりました!

前回のブログでは準備中としていたセッションの内容とタイムテーブルが決まりましたのでお知らせします!

発表順 時間 内容 話す人
-- 14:00 - 14:10 オープニング 日下部水規(@n0mzk
1 14:10 - 14:30 新卒でもできることはある!OCX自動化奮闘記 秋山正道
2 14:30 - 14:50 OCXのAzure シングルタグ機能解説とデモ 丸野達矢
3 14:55 - 15:15 さくらのセキュアモバイルコネクトの運用に CD の仕組みを導入する話 佐藤哲也
4 15:15 - 15:35 簡易 DRA の自作を振り返る 金井真澄
-- 15:35 - 15:50 休憩
5 15:50 - 16:10 英語の勉強について 夏玲鳳
6 16:10 - 16:30 サーバー3台で120万IFのトラフィックを収集する話 江野高広
7 16:35 - 16:55 Playgroundを作ろう!ーネットワーク初心者によるラボ構築PJとその効能ー 伊藤彰規
8 16:55 - 17:15 BBSakuraでのSRv6 MUP関連まとめ 日下部雄也(@higebu)/早坂彪流 (@takemioIO
-- 17:15 - 17:30 クロージング 代表取締役CEO 佐々木秀幸

やむを得ない理由で変更があった場合はご容赦ください。

主催チーム、登壇者、みんなで良いものをお届けできるよう鋭意準備しております。

ぜひconnpassから参加登録していただき、当日を楽しみにお待ちください!

BBSakura 公開社内勉強会を開催します! #bbsakura_open_study

公開社内勉強会を開催します

2月16日(木)、BBSakura Networksの「四半期会議」で行う拡大版社内勉強会を社外のみなさまにも公開します!

bbsakura.connpass.com

この記事を書いているのは公開社内勉強会発起人のid:n0mzkです。

公開社内勉強会をやりたい想いを書きます。

公開社内勉強会概要

まずは会の概要からお伝えします。

  • 2023年2月16日(木)14:00~17:30
  • 場所: オンライン(YouTube Liveの予定)
  • 参加方法: 上記connpassからお申し込みください。
    • 感想や質問は、ハッシュタグ #bbsakura_open_study をつけてツイートしてください!

開催までの背景

BBSakuraでは四半期に一度全社会議を開催しています。

設立当初から全国各地でリモート勤務するのが前提の会社ですが、だからこそ四半期に一度ぐらいは顔を合わせて、部署を越えて会話して、業務をブーストしよう、というイベントです。四半期会議のときは(感染症などの状況が許せば)オフライン会場にも社員が集まります。

午前中は全社方針の説明や、各部署からの報告があります。午後は、日々の業務からは離れて全員でひとつの課題に取り組むような企画が、社員からの持ち込みで行われます。前回は「良いウェブサイト/サービスってなんだろう?」を考えるワークショップが行われました。

この四半期会議、最近まではCMOの山口が毎回企画をしてくれていましたが、前回からはグループ(≒ チーム)ごとの持ち回りで企画を担当することになりました。

今回は私が所属するモバイル開発グループの担当です。

午後の時間の企画も考えてよいということで、ぜひやりたい!と思ったのが、公開社内勉強会でした。

やりたい想い

知識やノウハウを社内で共有したい

BBSakuraでは週に1時間、自由参加の社内勉強会の時間があります。

時間枠はあるのですが、実際に開催されるのはそれほど高頻度ではありません。時期によりますが、数か月開催されないことも……。

会社設立当初に「それぞれの持っている知識を社内に共有したい」「アウトプットすることで自身の知識を整理する機会として利用してほしい」という意図で始まった会ですが、3年半経ち、それぞれの業務もだんだんと忙しくなってきて、勉強会に話すネタを考える余裕がなくなってきているのかもしれません。

社内勉強会の頻度が下がるのにつられて、知識が部署内・チーム内に閉じがちになってきていると感じていました。エンジニアも非エンジニアもそれぞれ貴重な知識を持っていたり、いろんな技術を使っていたり、おもしろいことを考えていたりするのに、もったいない状態です。

あらためてそれらの知識などを社内で共有する機会を作りたいというのが、いちばんの企画理由でした。

アウトプットしてほしい

上の項に書いた社内勉強会の意図のもうひとつ、「アウトプットすることで自身の知識を整理する機会として利用してほしい」も、企画理由としてありました。

知識の整理にもなるし、アウトプットすればフィードバックをもらえます。アウトプットするところに情報が集まってきます。そうして新たなインプットにもつながります。仕事にも還元されていきます。

社外に出てほしい

せっかくやっていることを整理して話をするなら、社外にも届いたほうがいいじゃん!というのが、「公開」の勉強会とした理由です。

聞いてくれる人が多いほど、いろんな視点からフィードバックをもらえます。

なにより、社外で仕事の話をするのって、楽しいですよね。

解決したい問題に向かう仲間が見つかるきっかけになるかもしれません。

自分を世の中にアピールできる機会にもなります。

BBSakuraを知ってもらいたい

BBSakuraという会社、最近はOCXをリリースしたり、OSSにコントリビュートしたり、アドベントカレンダーをやったりして、すこしずつ知っていただけてきているでしょうか。

でも、まだまだ知名度のない会社だと思います。

もっと知ってほしいです。

作っているもの・使っている技術・取り組んでいる課題を積極的に発信して、メンバーが楽しく働いている様子を知ってもらいたい。あわよくば一緒にBBSakuraで働きたいと思ってもらえたらいいな、という下心もありました。

こんな話ができそう

そんな想いで開催する公開社内勉強会、以下のような話題についてお話しする予定で準備を進めています。

※ 内容が変更になる可能性もあります。ご了承くださいませ。

BBSakuraのメンバーがどのような技術を扱い、なにに興味を持って、どんな雰囲気で働いているのかを感じていただけたら嬉しいです。 ぜひご参加ください!

はてなブログ for DevBlogに引っ越しました

こんにちは。BBSakura Networksでテックリードをしている日下部(@higebu)です。

先ほど、「はてなブログ for DevBlog」への引っ越しが完了したため、なぜ引っ越しをしたのか、引っ越し作業はどうだったかとこのブログの今後について書きたいと思います。

なぜ引っ越しをしたのか

昨年の12/20に 企業技術ブログ: エンジニアの技術ブログコミュニティ のリリースを知り、大変良い取り組みなので、ここに弊社のブログも載せたいと思いました。

また、恥ずかしながら、それまで「はてなブログ for DevBlog」を知らなかったのですが、「はてなブログ for DevBlog」についても調べたところ、これでいいじゃんとなったため、引っ越しすることにしました。

それだけではよくわからないと思いますので、簡単に背景を説明したいと思います。

以前のブログはGitHubで記事を管理し、Cloudflare Pagesで公開していたのですが、エンジニアしかGitHubアカウントを持っておらず、アカウントを持っていてもGitに慣れていない人もいるという課題がありました。

普通の技術ブログではGitHubに慣れたエンジニアだけが書いていけば良いかもしれませんが、BBSakura Networksでは社長を始め、普段GitHubを触ることがないメンバーにも記事を書いていって欲しいと思っています。

そのため、GitHubでの管理ではなく普通にWebブラウザで記事を書けるブログプラットフォームで、良い感じのサービスを探していました。

はてなブログ for DevBlog」は複数アカウントで記事を管理でき、非常に安いことと、利用するだけで 企業技術ブログ: エンジニアの技術ブログコミュニティ への掲載も完了することから、引っ越しを決めました。

(簡単に決めたように見えますが、実際には内部で相談したり稟議したりしています。)

企業技術ブログ: エンジニアの技術ブログコミュニティ については下記の公式の記事を読むと良さがよくわかると思います。

developer.hatenastaff.com

引っ越し作業はどうだったか

基本的には記事を移してドメインの設定などを行うだけで完了でした。

ただ、以前のブログが Hugo ベースだったため、 はてなブログのインポート機能 が使えず、手動で記事を移行することになり、少し手間がかかりました。

特に画像が多い記事はアップロードの回数も多く大変でした。。。

また、以前のブログのパスがはてなブログ標準の /entry ではなく /posts だったため、 記事を配信するディレクトリを変更 をやりたかったのですが、上記のインポート機能を使わないとディレクトリ変更ができない点に苦労しました。

これは、空のMovableType形式のデータをインポートすることでディレクトリ変更を行うことができ、解決しました。

このブログの今後について

以前のブログは、 2019年にアドベントカレンダー をやるために立てたブログですが、その後、 2022年のアドベントカレンダー をやるまで、全く記事が書かれることがありませんでした。

今後はそのようなことがないように、また、外から見たら何をやっている会社かよくわからないと言われなくなるように、記事を書いていきたいと思っています。

すばやく体験しフィードバックループを回す大切さを身をもって実感した

こんにちは。モバイルコア開発チームでエンジニアをしている日下部(み)です。

12/27の記事「ネットワークなにもわからないマンが何もわからないままラボ構築プロジェクトのリーダーになった話」で紹介されているラボ構築プロジェクトに私も参加しています。このプロジェクトについて、@voice726さんとは別の視点でふりかえり記事を書いてみます。

ラボ構築プロジェクトを通して、高速にフィードバックループを回すことの大切さを実感した体験記です。

デスクに置かれたRTX1300の写真
検証中のRTX1300

ラボ構築ふりかえり会

voice726さんが書いているとおり、ラボの初回構築では目標としていた状態にたどりつけませんでした。構築後、メンバー内でふりかえり会を行いました。

このプロジェクトの目的は物理機器で実験できるラボ環境を作ることですが、教育的な目的もありました。つまり、ネットワーク初心者や物理作業の経験が少ないメンバーが構築を行うことで知識・経験を得るという目的です。

これについては、初期構築未完成ではありますが機器選定・調達・設計・構築と一通り経験したことによってメンバーそれぞれ構築というものに対する解像度が上がり、ふりかえり会では、次回作業に向けた具体的な改善策を話し合うことができました。このことから、一定の成果は得られていると感じています。

技術的・知識的な観点でのコメントとおなじくらい、プロジェクトの進め方についても反省点が挙がりました。このことから、構築経験を積むという目的よりひとつ抽象度を上げて、プロジェクトを推進するということも、体験として得られたことがわかりました。 以下、構築の観点、プロジェクト推進の観点それぞれの反省点について考察しながら紹介します。

構築の観点

  • 最初は最小限の構成(ルータ、スイッチ、サーバ各1台など)で構築し、動くことを確認してから拡張していけばよかった
    • 小さい単位に区切って完成させ、意図通りに動くかどうか確認したり、利用者からの声を聞いたりというフィードバックを得ることを行えばよかったというコメントです。実際には「あれもこれもやってみたい」とルータを2台冗長化しOSPFでルーティングしたり、LAGを組んだりと、最小限ではない作り込みをしようとし、結果として成功せず、ラボとしての機能を社内に提供できないという状態になってしまいました。
  • 検証機の相談など早めに機材に触れられないか働きかければよかった
    • 早く機材に触れられればその分早く手を動かして検証することができました。実際にはスケジュールの見積の甘さもあり、機材が手元に届いてから構築まで時間がなく、充分に検証できないまま構築作業を行うことになってしまいました。
  • 仮想環境で同様の構成を作って試せばよかった
    • 物理機器がなくても構築より前に手を動かし検証する方法を取ることはできました。一部CML2を利用して検証できたこともありましたが、構築しようとしているものと同様の構成を試すことはしていませんでした。同様の構成で試すことをしていれば、構築の日に起きた問題にもう少し早く気付けていたはずです。
  • 構築当日の作業手順に、段階ごとの検証項目を充実させておけばよかった
    • 細かい段階に区切って意図通りの状態になっているかどうか確認するべきでした。ルータ・スイッチ・サーバ・RaspberryPiすべての機器にconfigを入れてパケットを流そうとしてみてからデバッグを始めたので、疑うべき箇所が多くなっていました。

プロジェクト推進の観点

  • チームビルディングの場を初期から作ればよかった
    • 構築を終えてからふりかえり会を実施しましたが、プロジェクト開始からそのときまで約半年、互いの困りごとや良かったと感じていることを話し合う場を設けていませんでした。もっと早い段階でそのような場を設けていれば、チームとして強みを補強し合い弱みをカバーし合いながら進むことができたはずです。
  • メンバーそれぞれの得意分野を知って互いに相談できる状態にしてよけばよかった
    • それぞれの得意分野を互いに知っていればその分野についてその人に相談したり、質問したりすることができました。チームとして補強し合う状態になるために必要なことでした。
  • わからないことが多いタスクを2, 3人で組んで早めに相談できる状態を作りたかった
    • 1つのタスクは1人で担当することがほとんどで、わからないことにも担当者1人で手探りで調べながら取り組んでいました。複数人で担当していれば、相談し、知識やアイディアを提供し合い、コミュニケーションの中からより高速に解決策にたどりつくことができていたかもしれません。
  • 構築の観点の反省点も見方を変えればプロジェクト推進の問題だった
    • 最小構成から背伸び構成までのスコープ・ステップを整理すること、適切なリスク判断をすること、各ステップで早期に検証することは、構築に限らず他のプロジェクトにも適用できる反省でした。

得たこと

構築、プロジェクト運営、どちらの経験からも共通して得られたのは「短い期間・小さい単位で手を動かしてみてフィードバックを得ること、そのフィードバックを次の行動に活かすことが大事」という教訓でした。
こう書いてみると、あたりまえのことです。 ですが、実際に自分たちが行動し経験したことで、このあたりまえのことが実感を伴って理解できるようになりました。失敗経験を通して実感することで、ラボ構築以外のプロジェクトでも、これまでよりもより自信を持って「すばやく体験しフィードバックループを回す」やりかたを推進できると感じています。

ネットワークなにもわからないマンが何もわからないままラボ構築プロジェクトのリーダーになった話

本記事はBBSakura Networksアドベントカレンダー2022、22日目の記事です。

こんにちは。@voice726 です。またもや遅刻しました……今回は「ネットワークなにもわからないマンが何もわからないままラボ構築プロジェクトのリーダーになった話」と題しまして、私がリーダーをしていたラボ構築のプロジェクト(通称石狩ラボプロジェクト)のお話をしたいと思います。

石狩ラボプロジェクトが始まるまで

このプロジェクトの話はある日突然降ってきました。そうそれは6月のできごと。 テックリードからSlackにこんな投稿が。

"ラボ構築募集のSlack投稿のスクリーンショット"

上の概要で語られていたことを大雑把にまとめると

  • 雑に触ることができる物理環境によって、さくらのクラウドのようなサービスが生まれたり、その後新機能が追加されたりしている
  • BBSakuraではBBIXの物理インフラをうまく使い、ソフトウェア技術によってOCXのような新しいサービスを作っていくことが求められているため、物理インフラがわかっていないことは新しいサービスを作っていくときに足かせになる
  • 最近では動画学習などもあるけど、実際の経験に勝るものはない
  • 要は社内で下のスライドのようなことをやりたい(PDF注意)

ということが語られていました。

それに対しての弊社CEO佐々木からの返答がこちら。

"CEO佐々木からの返答:「けしからんことをするのは良いことだと思います!」"

(補足しておくと、「けしからん」とは上記の登氏のスライドの中に頻繁に登場する用語です。氏は技術者が自由に触って試せるラボ環境の重要性を説いており、そのような環境を構築することを「けしからんこと」と表現しています。詳しくは上記の氏のスライドをご一読ください。)

ということで、一瞬で始まりました。チャンネルが作成され、早速初期構築にむけてメンバーとリーダーの募集が始まりました。

リーダーに関しては当初「自分はネットワーク何もわからないマンだし、少しでもわかる人のほうが良いのかな?」と思って様子を見ていたのですが、 テックリード曰く「教育を兼ねているので、若者か未経験者にリーダーをしていただきたい」とのことだったので、 若者かどうかは別として未経験だったので手をあげてみました。

突然ですがここで簡単に私の自己紹介をしてみようと思います。

  • エンジニア歴4年目
    • かなりのアプリ寄り。前半2年のキャリアはほぼアプリケーションエンジニアとしての業務中心
    • BBSakuraに入ってきたタイミングでネットワーク機器も触り始める、DCでの構築作業はお手伝いでついていったことが数回あり
    • プロジェクトリーダー的なポジションもアプリ開発系の業務では任されたことが数回あったので、なんとなく回し方はわかっているものの、リーダーとしての経験が豊富とかリーダーとしての技術まわり(ファシリテーションとか、組織論とか)の勉強をめっちゃやってるわけではないので、まだまだひよっこ

こんな感じで、ネットワークエンジニアとしてもリーダーとしても超初心者な状態。 それでも思い切って立候補してみた理由としては、失敗していい環境でリーダーをやるという経験ができるチャンスってなかなかないのでは?と思ったからです。 自分の中での課題として、失敗に対する耐性がないなと思っていて、失敗を恐れながらディフェンシブに動くことが多いなと思っていました。 そんな中で、未経験の人に是非やってほしいというのはかなり後押しになりました。 かくしてネットワークやマネジメントに関しては全くの初心者だった私が、石狩ラボプロジェクトのリーダーとして動くことになりました。

"「未経験の人がやんちゃしてOKなのがラボだと思ってます!!」という社長の発言のスクリーンショット"

メンバーもそれぞれ立候補式で参加。 チーム横断で全社から様々なバックグラウンドのメンバーが集まりました。 例えば入社2年目の若手メンバーからモバイルコア開発チームの歴10年以上ベテランなエンジニア、DCでの運用経験のあるメンバーまで、総勢10名ほど集まってスタートしました。

その他数名の有識者がアドバイザーとしてつくことになりましたが、基本的には「見守る」というスタンスで、基本的に構築に関してはメンバーだけで進め、疑問点や相談したいことがあったらアドバイザーに相談という形で進めることになりました。

プロジェクト、始動

さて、こうしてプロジェクトが無事に始動したわけですが、プロジェクト開始時点ではっきり決まっていたことは

  • 年内くらいに初回構築できればうれしい
  • 構成はサーバ4、スイッチ1、ルータ1くらい

というくらいで、最終的にどういう構成でいつまでにやるかもメンバー内で検討して良いとのこと。 前述のDC勤務経験のあるメンバーに全体の工程の叩きを作ってもらって大まかなフェーズ分けはしたものの、それ以外は全員はっきりとした知識がない状態でのスタートでした。 なのでみんなで手分けして調査をしながら、悩みながらも徐々に話が進んでいきました。

具体的にやったことをリストすると

  • 構成の検討
  • 機器の選定・調達
    • 調達窓口の選定・やりとり・価格交渉
  • 小物周りの選定・調達
  • 予算管理・稟議
  • ハウジング契約
    • 電源・ハウジング回線スペックの検討
  • ネットワーク設計(論理・物理)
  • config検証

という感じで、内容としてはDCでの構築作業の標準的な内容かと思いますが、それぞれを実際に体験したことがないメンバーがほとんどで、解像度も低かったため、 道中は課題だらけ・わからないことだらけ。挙げるときりがないので、具体例をいくつか抜粋します。

何を選んだら良いかがわからない

「サーバ4、スイッチ1、ルータ1」と一口にいっても、スペックはかなり幅広いと思います。 サーバ1台選ぶだけでも、CPU・メモリ・NIC・OS・保守・諸々のライセンスなどなど、様々なオプションがあり選択に苦労しました。 特に大きかったのは、ラボでやりたいことがメンバー内できちんと定まっておらず、必要スペックが割り出せなかったという点かなと思っていますが、それについては後述します。

他にも調達に関連してのハマりごととしては、値段の相場観がわからないので、予算をレビューしてもらうときに、これはちょっと高いのでは?というツッコミを受けたりもしました。

ラボでなにがしたい?の具体例が出てこない

上で「ラボでやりたいことがきちんと定まっていない」という話をしましたが、じゃあ「ラボでやりたいことを考えよう!」となったときに、 そもそもネットワーク機器やラボで何ができるのかがわからない・イメージがつかない、という状態が発生しました。 結局選定としてはそれぞれ別業務で使ったことがあるからなんとなくスペックがわかる・汎用性がありそう、といった消極的選択に近い物が多く、そういった意味でラボとしての面白みには少し欠ける選択が多かったかなと思っています。 今回は初期構築ということで初心者メンバー中心での構築でしたが、今後ネットワークに詳しいメンバーがどういった点に面白みを感じてどういう機器を入れていくのかを楽しみにしたいと思っています。

他の優先度が高い業務に時間を取られてしまう

このプロジェクトのメンバーは様々なチームから横断でメンバーが集ったと上で述べましたが、基本的にメンバー全員それぞれ自チームでそれぞれのプロダクトに関する業務を持っています。 会社の事業と強く紐付いているプロダクトに関連するタスクと比較して、ラボ構築のような教育的側面の強いプロジェクトのタスクはどうしても優先度が低くなってしまうもの。 特にプロダクト側のタスクが忙しくなってくると、なかなかラボ構築プロジェクト側にはコミットできず、タスクが消化されなかったりというような状態も発生していました。

リーダーとして何をしていいかがわからない

これはリーダーとしての課題です。 まずリーダーとして手を上げてみたものの、実際リーダーって何したらいいんだっけ……?となりました。 一応気をつけていたこととしては

  • プロジェクト全体に気を配ること
    • 全体の進捗からマイルストーンに対して現在地がどれくらいなのかを把握し、スケジュール的に問題なさそうかを判断
    • それぞれの課題(予算・発注・技術的なところなど)の状態を説明できるようにしておきたい

などがありますが、そもそも構築自体に対しての解像度も低い状態だったので、何にどれくらいかかるかが読めなかったり、 実際にどういう状態になったら構築に行っても大丈夫かという状態の判断が甘くなってしまったりと、進捗管理するだけでもかなりお腹いっぱいの状態でした。

いざ現地へ

そんなこんなでなんとか話を前に進めて、やっと現地での初回構築にまで到達。 プロジェクトがスタートしたのが6月で、実際に構築は12月中旬で行ったので、ここまで来るのに半年間かかりました。 しかし構築も一筋縄ではもちろん行かなかったのです。

当初は「ハウジング回線に接続したルーター経由でリモートからサーバ等に入れるようにして、現地に行かなくても機器の設定を触れるようにしよう」という点を目標の一つとしていました。 しかし、現地で実際に作業してみると、想定より時間がかかったり、検証ではOKでも実際はうまく動かないということがありました。 特にスイッチはCML2を使って検証を行っていたのですが、 ルータ周りの設定はスケジュール等の見積もりの甘さもあってあまり検証の時間が取れず、現地で検証しながら構築しているという感じになってしまいました。 現地でのリカバリがうまく行った部分もあったのですが、間に合わない部分も多く、最終的にはルーター経由ではリモートからサーバに入れないまま終了という結果になりました。

一応バックアップ策は機能していて、「RaspberryPiとモバイル回線(さくらのセキュアモバイルコネクト)」を使って遠隔ログインはできるようにはなっていたのですが、 やはりハウジング回線 → ルーターを経由してのリモートログインまでは達成したかったなー……

朝10時集合で、終わってみるともう22時を超えており、みんな疲労困憊。 タイムマネジメントや、焦っても休憩を入れることの大切さを身をもって味わいました。

おわってみて

「失敗していい」といいつつ、やっぱり凹みますね。 悔しい!って思いました。 振り返ってみると課題も山積で、ああしたらよかった、こうしたらよかったばかりで整理しきれていません。 実際いまこの記事を書いている間も反省会が進行中で、いろいろな意見が出ている中から次のアクションアイテムに落とす作業が進行しています。

"反省会の様子"

でもこうして課題がいっぱい出てくるということは、それだけ構築に関する解像度が高くなったと前向きに捉えています。

他にもやってよかったなと思ったことは多くありました。 なんでもそうですが、やっぱり知識はインプットしたあとに実際に使うことが大切で、今回ネットワークの勉強をしながら実際に機器を触ることで、理解が更に深まったメンバーも多かったようです。 また、業務に還元できているといった手応えを早速感じているメンバーもいて、やはり手を動かすことは大切なんだなと感じています。

"弊社Slackの「手を動かそう」「足を動かそう」スタンプスクリーンショット"

それ以外にも、わからないなりに社内有識者からのアドバイスは借りながら、でも手を動かすのはほぼ自分たちの力だけで構築までを一度通したことも良かった点だと思っています。 反省の中ではもっとアドバイザー方に積極的にレビュー等をお願いしたらスムーズに行ったのではないかというコメントもあったのですが、その一方であまりそれをせずにやろうとしたことのメリットも感じています。 経験者が見たら当然気づきそうな地雷なのかもしれないですが、それを実際に自分たちで踏み抜いていったことに価値があったのかなと感じています。

あとは大変なことも多かったけど、やっぱり「楽しかった!」の一言に尽きます。 初めてサーバをラックに乗せられて楽しかったという声や、pingが通ったときの「おお〜!」という歓声を聞くと、頑張った甲斐があったんだなーと思うと同時に、 もっと勉強していろいろなことができるようになったら、もっと楽しいんだろうな!と感じています。

初心者リーダーとしてこのプロジェクトに携わった視点で言うと、まず当該フィールド(=DCにおける構築)の知識が乏しい状態でもなんとか前に進めて、(内容はどうあれ)構築までこぎつけたという点は少し自信になったなという気がしています。 一方で、前述の通り、リーダーとしてもネットワーク技術者としても解像度が低かったゆえの課題は多くありました。 進捗管理だけではなくチームビルディングなどもっと気を配ったほうがよかったなと思うことも多く、今回リーダーの立場として経験したことを踏まえて,更に知識面でもインプットを増やせて行けたらと思っています。

今回プロジェクトを進めていく中で様々な迷いがありました。それはリーダーとしての経験・知識の少なさと技術的な知識・経験の少なさの両方から来るものでした。 プロジェクトを進めていく中では様々な判断をする箇所が出てくると思いますが、いろいろな自信のなさから判断に迷ったり、メンバーにお願いをしたりというところがうまくできなかったのが大きかったなと思っています。 それ以外にも、リーダーというポジションとして何をすべきか、どういう目線から関わるべきなのか、やってみないとわからないことって多いなーと思いました。

まとめ

今回の初回構築は当初立てた目標という観点から見ると決して成功とは言えず、そこまでに至る過程も経験者から見たらボロボロだったかもしれません。 でも今回失敗することで得られたものは大きかったし、貴重な経験ができました。 今後の業務でも今回得た学びを活かしてさらにいろいろな楽しいことができるようになっていけたらと思っています。リベンジしたい!!

最後にテックリードからラボ構築メンバーへのひとことを紹介したいと思います。

石狩ラボも初期構築のリベンジに留まらず、もっともっと発展していく予定です。 AS取得してみたいね!とか、オレオレISP運用したいね!とか、100G環境つくりたいね!とか、いろいろな夢が広がっています。 このようにBBSakuraはチャレンジできる環境が整っています。「私もラボで色々けしからんことをしたい!」と思った方は、 ぜひこちらのカジュアル面談からお話ができたら嬉しいです!