CNTOM2022で発表したモバイルコア運用引き継ぎのお話

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

こんにちは。BBSakura Networks 株式会社開発本部の佐藤です。 気が付いたら 23 日でした。12 月もそろそろ終わりですね。

今年の 11 月に開催された CNTOM2022 にスポンサー枠で登壇しましたので、発表準備の過程で考えていたこと・発表後に改めて思い返したことを書きます。発表時の資料はこちらになります。

発表時に伝えたかったこと

クラウド基盤×自作EPCによるフルMVNOの運用とその実態

当日は「クラウド基盤×自作EPCによるフルMVNOの運用とその実態」というタイトルで発表しました。

タイトル中の「その実態」がポイントで自作 EPC システムの開発初期を支えたメンバーが徐々に離脱するなか、知識・経験が不足している自分が何に悩み、どんな道筋を立てて運用を引き継いだかを伝えたいと思いました。以下ではその中身を述べていきます。

運用参加初期に思ったこと

親会社であるさくらインターネットから BBSakura Networks に出向してすぐに「さくらのセキュアモバイルコネクト」のモバイルコア部分の運用開発メンバーに加わりました。 そして参加して間もない頃に発生した通信障害の対応を通してモバイルシステム特有の運用の難しさを実感しました。

  • 何らかのトラブルにより通信断が継続した場合にはシグナリングストームが発生すること
  • 外的要因(基地局〜モバイルコア間のネットワークのどこかで発生する通信断など)が解消された後でもシグナリングストームによる大量の通信要求を処理しきれないケースがあること

また、フルスクラッチで内製されたシステムであるため運用担当者には以下の認識が必要と感じました。

  • 自力で解決するしかないこと(トラブル発生時に保守業者にお任せといった対応はできない・エスカレーション先は無い)
  • そのため、通信障害を速やかに収束させるにはシステムに対する深い理解(システム全体を俯瞰して障害原因を特定・各コンポーネントソースコード把握)が要求される

出向前に在籍していたさくらインターネットの DC 業務および前職のシステム管理業務では、不具合発生時には予め定められた作業手順書に従って対応すること、復旧が困難な場合にはサポート先へエスカレーションすることが原則だったため、自分がこの水準を満たすには相応の時間が必要と判断しました。

そして何ヶ月か経過した後、開発初期からこのシステムを担当しているメンバーが社内異動等により徐々にチームから離れていくことが決定していきました。

自分が主担当として運用していくために何をすべきか

初期メンバーがチームを離脱するまでにある程度の期間が設けられていたため気持ちの準備はできていたものの、各メンバーが通常の業務に追われる日々が続いたため引き継ぎのための時間を十分に確保することは困難な状況でした。 そのため、開発初期メンバーと同等の知識経験が無い自分がこれまで実現されていた運用水準を維持向上してくためにはある程度の方針・計画を立てて進めていく必要があると感じました。それをふまえて実践したことが以下になります。

障害発生時の原因絞り込み & 認識の共有ができるための準備

システムを構成するサーバ・ルータの詳細なネットワーク図を作成しました。 意識した点として障害箇所とその影響箇所がひと目でわかるよう、すべての構成要素が一枚の図に納まるようにしました。加えて要素間での疎通確認・リモートアクセスが即座にできるよう各要素には IP アドレスの明記を必須としました。

ミドルウェアの統合化 & さらなる整理

開発初期のメンバーといっしょに進めてきたミドルウェアの統合化作業をメンバー離脱後も継続しました。 多少の修正を加えれば必要が無くなるミドルウェアは基本外す方向で積極的に置き換えていき、システム全体の構成をシンプルにすることに努め、障害発生時に疑うべき点を減らしていきました。

自動デプロイの導入はあえて採用しなかった

自動デプロイの導入が当初より検討されていましたが、理解が必要な技術が増えること、中途半端な状態で導入した場合の運用リスク(障害発生時、デプロイツールの動作に問題が無かったかを検討する時間が発生するなど)を懸念し、枯れた手段であるコマンドが列挙された手順書によるメンテナンス作業をあえて採用するようにしました。

サービス提供主体側との密な連携

サービス提供主体であるさくらインターネット側のメンバーと役割分担を推進して通信障害が発生した際に原因究明に注力できる体制を設けました。また、障害対応後の振り返りができるよう各役割の連携フローをまとめ、実際に障害が発生した際に用意したフローに従ってお互いが連携できるよう合同の運用訓練を定期開催するようにしました。

取り組んだ結果

稼働率(通信断の状態だった時間の合計割合)が前年度比で改善できたことは素直に嬉しかったです。 これまでのメンバーと行ってきた運用のあり方を変えていくことには正直不安がありました。もし開発初期メンバーが継続して運用する体制が維持されていれば、より良い体制になっていたのではないか?と常に感じていたためです。 今回の経験を通して自分が主担当として運用するシステムは自信を持って運用できる体制に思い切って切り替えていくことは、システムを引き継ぐ上での有効な手段であると強く感じました。

現在の取り組み

初期の頃を不安を乗り越えてたくさんの知識と経験を得ることができました。ソースコードの修正も抵抗なく行えるようになりました。現在はこれまで採用を見送っていた CD 環境の構築に挑戦しています。システムの更なる安定化と改善頻度の向上が両立できるよう精進していきたいと思います。

VPPにSRv6 MUP Plugin APIを追加している話

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

こんにちは。BBSakura Networksのエンジニアをしている( @takemioIO )です。

普段はモバイルコアを開発しているチームでソフトウェア開発しています。1日目の記事を書いたり、このアドベントカレンダーの主宰をしています。

背景

SRv6 MUP の OSS について何か行う際には DPlane を選択する必要がありますが、世の中での実装は大変少なく ebikenさんのP4, 拙作のXDP, VPP での実装が世の中に存在しています。

この中でソフトウェア実装としてエコシステムも含めると一番成熟しているのは VPP の実装で、以前JANOGでArcOSでSRv6MUPに関する実装の発表をされていた村上さんが SRv6 MUP Plugin のメンテナーですので、大変しっかりとした実装になっています。

ですが高度な操作を行うには CPlane を経由して経路を注入することが必要で、現状では VPP の CLI 経由でのみでしか行えず残念ながらプログラマビリティが足りてない状態にあります。 VPP は本来 API を提供していて、それを使って C や Go などから操作することが可能になっていることから、コントローラーを開発しやすくする工夫がされています。

本記事ではその VPP に実装されてる SRv6 MUP Plugin に対して の API を実装して便利にしようという記事です。

注意: ここでの引用するコードや解説のリンクは タグ stable/2210 を対象としています。

調査

既存APIの調査

本体に入っている SRv6 を見るとこちらは API が実装されてて/src/vnet/srv6/sr.apiを見ると API 定義が書かれています。 例えば以下のようなフォーマットがあって、SRv6 policy を追加するAPIスキーマがあります。

autoreply define sr_policy_add
{
  u32 client_index;
  u32 context;
  vl_api_ip6_address_t bsid_addr;
  u32 weight;
  bool is_encap;
  bool is_spray;
  u32 fib_table;
  vl_api_srv6_sid_list_t sids;
};
...

このAPIスキーマは VPP が独自実装&定義しているもので、これをベースに C のヘッダー定義等のAPIのスケルトンが出力されます。このスケルトンに合わせて実装を書いていく感じです。詳しくは周辺コードを読んだりしていくとよくわかります。 もし API を実装するならばここの機能を拡張するか、別途定義することになりそうですね。

SRv6 MUP のプラグイン周りの実装調査

/src/plugins/srv6-mobile に MUP 関連のソースファイルが置かれています。 ここのコードを読むコツを End.M.GTP6.D を例にして出すと localsidpolicyの機能を追加するレジスター関数を中心に読むと良いです。

cf. /src/plugins/srv6-mobile/gtp6_d.c#L236-L249

  rc = sr_localsid_register_function (vm, fn_name, keyword_str, def_str, param_str, 128, //prefix len
                      &dpo_type,
                      clb_format_srv6_end_m_gtp6_d,
                      clb_unformat_srv6_end_m_gtp6_d,
                      clb_creation_srv6_end_m_gtp6_d,
                      clb_removal_srv6_end_m_gtp6_d);
  if (rc < 0)
    clib_error_return (0, "SRv6 Endpoint GTP6.D LocalSID function"
               "couldn't be registered");
  rc = sr_policy_register_function (
    vm, fn_name, keyword_str, def_str, param_str, 128, // prefix len
    &dpo_type, clb_format_srv6_end_m_gtp6_d, clb_unformat_srv6_end_m_gtp6_d,
    clb_creation_srv6_end_m_gtp6_d_2, clb_removal_srv6_end_m_gtp6_d_2);

これらはざっくりいうと以下のこの4つに機能に必要なものを載せています。

  • format: 実際にこの機能をコールしてトレースした時のフォーマットを出力します。
  • unformat: CLI で入力したときに実際にパースを行います。
  • creation: コンストラクタ、初期化を行うときはここで行います。 MUP では使ってませんがAD-flow などでは使ってます。
  • removal: デストラクタ、CLI でパースした後に保存したパラメーターを保存するメモリーを解放等をします。

今回はここの unformat でどんなパラメーターを受け取っているのかを確認し、それをAPIでどのように表現するか考える必要がありそうです。

方針

前述の通り、今回の場合では VPP CLI に対応した機能を追加する必要がありました。 実際に VPP にあるSRv6 MUPのドキュメントのCLIの例を見ると policy localsid のどちらも利用して実装されてることから2種類の API の注入機能を実装することになります。

# 以下、t.m.gtp4.d、end.m.gtp6.dの例
sr policy add bsid SID behavior t.m.gtp4.d DST-PREFIX v6src_prefix SRC-PREFIX [nhtype {ipv4|ipv6|non-ip}]
sr localsid prefix SID-PREFIX behavior end.m.gtp6.d DST-PREFIX [nhtype {ipv4|ipv6|non-ip}]

方法としては実際には2つの方法があり、「本体にあるSRv6機能を拡張することで実現する」、または「別途専用にAPIを定義する」という選択肢がありますが、今回は Plugin としてせっかく実装されているので後者を選択し API もちゃんと分割することにしました。(ただし削除などの機能は本来の localsidpolicyのAPIより削除することとします)

また同時に unformat で利用されてるパース部分を切り出し、API側の実装と共通化を図ります。

開発方法とパッチを出すときの Tips

ここでは開発の時の Tips とパッチを出すときに知ってたら便利だったことを書きます。

開発で使えるTips

buildしてinstall までの基本形

make install-dep
make install-ext-deps
make build-release
make pkg-deb
sudo dpkg -i build-root/*.deb
# 開発中にビルドして即実行する時(イテレーション)
make build
make run

特定のテストを実行する

# https://github.com/FDio/vpp/blob/stable/2210/test/test_srv6_mobile.py#L10 のテストだけ実行させる例
# V=2 で詳しくログを出す, TEST_JOBS=auto タスクランナーの並列数を自動化
V=2 TEST_JOBS=auto TEST="test_srv6_mobile.TestSRv6EndMGTP4E" make test

VPP 本体に関する操作

# vpp の interfaceがおかしい場合は以下のコマンドでバス情報を取得して動作させる
sudo lshw -class network -businfo
# vpp に着信してきたパケットを見るとき
# cf. https://fd.io/docs/vpp/v2101/gettingstarted/progressivevpp/traces.html
trace add dpdk-input 10
show trace
clear trace
# vppのfib, arpのテーブルを見る
show ip fib
show ip neighbors
show ip6 fib

Goライブラリから API で叩けるようにする時

govpp ライブラリが提供されており、そこからも API が実行できます。その際に新しく追加した API を動かしたい場合は自分でスキーマからビルドしてあげる必要があります。以下はその例です。binapi というディレクトリに一式出力されます。

go install go.fd.io/govpp/cmd/binapi-generator@master
binapi-generator --input-dir=$VPP_PATH/build-root/install-vpp-native/vpp/share/vpp/api --output-dir=binapi

パッチを出す時のTips

基本的にhttps://s3-docs.fd.io/vpp/22.10/contributing/gitreview.htmlを見ると色々書いてるのでこれ通りに進めればオッケー

注意点は commit message に Type を書いてあげる必要があって機能追加ならばType: feature、バグフィックスならばType: fix などがあるのでちゃんと記述する必要があります。

また以下のようにして commit 時に Signoff-By をしてあげる必要があります。

git commit -s

これでコミットを作成した後は以下のコマンドでコードや Git のコミットメッセージの体裁を確認します。

make checkstyle-all

あとはパッチ提出時に git review command を使うので結構慣れてない自分は戸惑いながら使っています。Gerrit 使い方 とか調べて利用するのも良いでしょう。

後は CI が動作するので無事通ることを祈るばかりです。 この開発で自分が引いた問題の一つに CI 環境でのコンパイラが GCC-11 起因で通らなかったケースがありましたのでそういう場合は ci-management という CIに関するリポジトリを見て察することができます。

この場合のケース対策として export CC=gcc-11 とすることで手元でも無事デバッグできます。

で、その実装とそのパッチは結局どうなってるの?

実装はこちらで、https://gerrit.fd.io/r/c/vpp/+/37628 で今パッチ出して作業中です。

状態としてはメンテナーの村上さんからは Approve は出ましたがマージ権限を持つメンテナから Approve が出ていないのでテストを追加等を鋭意作業中です...🥺

(2023/12/21 追記) https://gerrit.fd.io/r/c/vpp/+/40104 で無事マージされました! レビュワーの村上さんに大変な感謝を表明します。

最後に

今回は、VPP の SRv6 MUP Plugin を弄れる API 機能を追加してみる話でした。いやーブログまでにマージまで持っていきたかったがなかなかうまくいかないものですね...

初めて VPP のコードを触ったんですが実際にはどうするといいか結構悩みました。例えば Plugin 機能で分けてはいるが同じ CLI コマンドを拡張するような実装にしたゆえの抽象化の漏れみたいになっている点をどうしたら綺麗に出来るかなどは考えることがあったなーと思いました。結局素直に実装することにしましたが・・・

BBSakura Networks ではこのように IETF で標準化中の新しい技術を使った業務を普段から行っており、BGP や SRv6 等のネットワーク技術に明るく、3GPP の仕様が読めて、プログラミングもできる仲間を募集しています。 気になった方は 採用情報 からご連絡ください。

よろしくお願いいたします。

ASを復活させてみた話

アイキャッチ画像は CC2.5で提供されているインターネットの画像です​

こんにちは。BBSakura Networks社長の佐々木です。 この記事はBBSakura Networkのアドベントカレンダー 20日目として投稿致します。 以前、Peeringの世界とインターネットというタイトルでインターネットのバックボーン接続の世界について投稿をさせていただきました。本日は「ASを復活させてみた話」を投稿させていただきます。 ​ ​

ASNとはなんぞや?

インターネットはネットワークのネットワークとして、各独立したネットワークの集合体として成り立ってます。 この各ネットワークを識別するものがASN、AS番号と呼ばれる物になります。AS番号は2byteのものと4byteのものがあり、0〜4294967295まで使えるようです。膨大な数ですね! これらのAS番号同士で世界中につながったネットワークが「インターネット」となっております。 ​

歴史を作ったISP

インターネットが勃興した年といえばなんといっても1995年、Windows95の発売が契機だったと思います。 中学生だった私は、翌年96年にパソコンを手に入れ、モデムを買い、受験生だというのに毎日インターネット接続に勤しんでました。 当時、インプレスさんのインターネットマガジンという雑誌があり、山口県の片田舎から如何に快適に接続するか、プロバイダー接続マップを眺めながら最適なISPを探した物でした。

JustNet、Mesh、InfoSphere、いろんな2次プロバイダを使った後、アーバンインターネットという地元の3次プロバイダに落ち着きましたが、いつも上位に君臨してたAT&T JENSやKDDIに憧れ、いつかISPで働きたいなと思っていたのもこの頃でした。Impressさんの商用ネットワークサービスプロバイダー接続マップ(1996年10月号)(https://i.impressrd.jp/files/images/ispmap/ispmap199610.pdf) を見てみると、当時栄光を極めていた大半のプロバイダーはすでにこの世から無くなり、まさに盛者必衰の理をあらわしております。 ​

OCXとASN移転の準備

弊社では、OCX Open Connectivity eXchange というプラットフォームのシステムを開発しております。 OCXではデータセンターやクラウド、インターネットなど、ありとあらゆるネットワーク間を誰でも簡単に接続出来る基盤を目指してサービスを開発しております。 OCXの事業を企画し、検討を進める中で、せっかくサービスを作るなら、歴史を作ったASN達を復活させたいと思いました。 ​ 歴史的経緯でソフトバンクグループの中にあり、レジェンドなAS番号をリストアップしてみました。

AS運用事業者 AS番号
東京インターネット AS2521
PSINet Japan AS2554
AT&T Jens(SpinNet) AS2915
ITJIT AS4682

日本初の商用インターネット提供事業者であるJensのASNを移転しようと思いました。 AS4682は私の師匠が、自分が立ち上げたASをどうしても手元に戻したいと言うことで、一緒に手続きしました。 ​ 長い時間を掛けて色々な調整を行い、JPNICに移転申請を掛け、無事に10月に移転を完了することが出来ました。

  移転元組織:
    - ソフトバンク株式会社(資源管理者略称:ODN)
​
  移転先組織:
    - BBIX株式会社(資源管理者略称:BBIX-AS)
​
  対象AS番号:
    - 2915
      4682

​ 日本初の商用インターネット事業者AT&T Jensで使われていたAS2915ですが、NTTComさんのAS2914ともお隣さんです。 OCXをVerioの次ぐらいに同じぐらい大きなネットワークにしたいという想いを込めて使っていきたいと思います・・・。

中国ニューライフスタイルについて話②

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

まえおき

皆さんこんにちは、BBSakura Networks なつ(夏)と言います。

アドベントカレンダーBlog書くのは2回目です。前回のBlogは中国のニューライフスタイルについて話しました。Blogの最後に「年末にはまた中国に帰りますが、次の進化、楽しみしています」と書いてますが、結局、コロナ禍で帰れなかったです(苦笑)

コロナは既に三年間経ちましたが、中国ではまたどの技術が進化していますか?ライフスタイルはどのように変わってますか?今回またこれについて話したいと思います。

顔認証について

顔認証技術の運用は日本で馴染みがあり、オフィスの入退室管理で顔認証システムを導入する会社は近年どんどん増えていると思います。 中国では、オフィス以外、生徒の登校状況管理のために、学校で顔認証システムが普及されてます。近年、さらにさまざまな分野で活用されています。

地下鉄改札通過に活用

近年、各都市で5G、ビッグデータ、AIなどを活用したスマートシティの建設が進む中、地下鉄の改札通過にも顔認証技術を活用されています。 市民は事前に決済アプリで顔のデータと支払い先の情報を登録すれば、交通ICカードスマートフォンをつかわずに、顔を改札横に設置されたタブレットにむけるだけで、改札を通過できます。改札出た時、アプリから自動決済されます。もちろん、コロナ対策の為にマスクつけたままの顔認証と乗客の体温検査も対応できています。

一方、地下鉄で顔認証技術の活用について下記のようにいくつの課題があると考えています。 - 法的問題点:情報漏えい、プライバシーや肖像権の侵害のリスクはゼロではない、法整備の必要があります。 - 顔認証の精度:オフィスや学校の利用者数より、地下鉄の利用者数は圧倒的に膨大です。その裏側のビッグデータ処理技術はかなり厳しく要求されています。また環境(照明変化など)によりうまく認証できない場合があります。ちなみに、中国の在住の友達から「何度も顔認証できず、結局QRコードで決済してしまった」と言いました。 - 既存の支払い方法と混在、APPのUI・UX問題:乗車する時、顔認証とQR支払いはどっちか有効にする必要があります。両方有効すると、ダブルチャージしてしまう可能性があります。

ゴミ分類に活用

ご存知の通り、環境保護のために、2019年から上海を始め、全国でゴミ分類処理制度が普及しています。 ただし、不法投棄は次々発生してしましました。それを防ぐために、顔認証ゴミ箱の導入が進んでいるらしいです。

事前に顔のデータを登録すれば、利用者がゴミ箱の前に立つと、カメラで顔をスキャンし、認証が終わると、ゴミ箱の蓋が開きます。 また顔認証以外に、ゴミの重さのはかり機能もついています。ゴミの量に応じポイントが付与され、ポイントがたまると日用品と交換できるらしいです。ゴミ重さのデータはゴミ回収作業時間の分析にも活用しています。 新技術で、国民の環境保護意識の高めとスマートシティ化の進めの一方、「やりすぎ、市民のプラバーシーや肖像権の侵害」の声もあります。

新技術を新しい分野に普及する時、当然さまざまな問題が存在していると思います。これからの国民立場から考えながら、法整備と技術の進化を期待しています。

ネット通販からライブ通販へ

中国の独身セールはよく耳にすると思います。 (由来:11月11日、中国では独身の日と言われます。独身の皆さんがお買い物して自分にご褒美の理由で、2009年からECサイトは毎年の11月11日に独身セールをやっています)

前回のBlogにも独身セールについて書きました。2019年の独身セールでアリババの取引額はわずか1分間で1000億円達成しました。自分も毎年独身セールを狙って、お得な商品を購入しています。 毎年かなり盛り上がってますが、今年の独身セールは、例年よりかなり静かになってます。メディアの宣伝もあまりなかったし、アリババの取引額も初非公開だし、でした。コロナ禍で経済低迷・節約志向、政権の統制影響などさまざまな理由がありますが、個人的にはユーザのショッピングスタイルが変わってるのは一つ大きな理由だと思います。

近年TickTokの流行に伴い(特に2019年から)、生中継で商品を売る「ライブコマース」が主流になっています。 - コロナ禍で、ショップで買い物する機会は少なくなります。 - 独身セールのような年一回しかやってないセールより、ライブコマースはクーポン配布や共同購入による大幅な値下げできます。 - 利用者はコメント欄やチャット通じ、質問を投げ、その場で回答されます。それでその場で購入する方が多いです。

2025年ライブコマースの市場規模は100兆円に達すると見られています。

最後に

今年はコロナの3年目です。中国のライフスタイルは大きく変わってますと思います。(いいところもあるし、悪いところもあります。。)。もしこのシリーズにご興味があれば、また3回目のBlogを書きます。

今年の12月から中国のコロナ対策は緩和のため、来年帰るように頑張って調整しますw。

お宝発掘くんを作って埋もれてるナレッジの再発掘を試みた話

はじめに

本記事はBBSakura Networksアドベントカレンダー2022、14日目の記事です。遅刻しました。

こんにちは。BBSakura Networks株式会社@voice726です。 突然ですが、皆さん社内ナレッジの管理はどうしてますか?

社内ナレッジの管理運用は様々な課題があり、各企業でいろいろな取り組みがなされていると思います。その課題の一つとして挙げられるのが「資料が埋もれてしまう」問題。つまり、せっかくナレッジとして記録してもアクセスされにくくなってしまうという課題があると思います。今回の記事では、この「埋もれてしまう問題」に対して、「お宝発掘くんbot」というアプリを作成することでサルベージできないかと試みたので、その話を紹介します。

作ろうと思ったきっかけ

弊社でも業務にあたり様々なサービスを導入していますが、ナレッジ管理目的としては主にKibelaを利用しています。 各業務に紐づくドキュメント類から、個人が業務で使用した技術のメモ等、様々な記事が投稿されています。

ただ、ナレッジは蓄積されてはいるものの、参照する側としては参照しづらさを感じることもしばしば。特に感じていた課題は以下の2つです。

新しく入ってきた人たちが、過去のナレッジにアクセスしづらい

これは私が入社したばかりのときによく感じていたことですが、なにかの課題に取り組んでいるときに知りたかった情報についての記事の存在に後から気づいて、「こんな記事あったんだ!」と思うことがしばしばありました。 一旦入社してしまえばKibelaの投稿をSlack通知してはいるので、こんな記事が書かれてるんだなーと拾うことはできるのですが、入社前は投稿通知をリアルタイムに見ることができないので(遡るかというとそうでもないし)、過去の記事を目にする機会が極端に少なくなるという課題がありました。

プロジェクトに紐付かない記事(個人での技術メモ)等は浮上しにくい

プロジェクト等に紐付いている記事では各プロジェクトにおける関連ドキュメントとして目次やドキュメント一覧を整理する等してリンクしやすいとは思うのですが、特定プロジェクトに紐付かない、いわゆる「やってみた系」の記事は存在すら認知されないのではと思うこともあります。

そこで思いついたのが、既存の記事をランダムにSlack投稿するbotを作れば良いのではというところでした。この発想は、よくSlack botの入門としておみくじとかそういうネタをよく見かけるのが出発点で、単におみくじ作っても面白くないのでなにか役に立つおみくじは作れないのかと考えていたところ、ちょうど前述のような課題感もあってKibelaの記事をおみくじ的に垂れ流したら面白いんじゃないかなと思ったのがきっかけでした。

ちなみに上記以外の目的としては、KibelaAPIでGraphQLを採用しており、あまり触ったことがなかったのでその練習をしたいなと思っていたのと、過去の記事を掘り起こすことで社内でのコミュニケーションフックになったらいいなあという妄想もありました。

技術的なはなし

技術選定

ということで、早速実装検討を開始。まず言語は社内でよく使われており、自身も書き慣れていたGo言語を採用。 前述の通り、KibelaAPIにGraphQLを採用しているので、GoのGraphQLライブラリとして https://github.com/hasura/go-graphql-client を採用しました。

「採用しました」といってもGoでGraphQLをするのは初なので、ググってGitHubのStar数が多そうなものという理由で選定しています。 この辺の選定は雑に済ませてしまったので、もっと便利なライブラリがあるよ!というのがあればぜひ教えていただけると嬉しいです。

このライブラリではクエリを構造体で記述することができます。詳しくは公式READMEを参照していただきたいのですが、簡単なクエリを書くなら以下のように構造体を作ってあげてから

var q struct {
    Human struct {
        Name   string
        Height float64 `graphql:"height(unit: METER)"`
    } `graphql:"human(id: \"1000\")"`
}

以下のようにQuery関数の引数として渡してあげるだけで問い合わせができます。

err := client.Query(context.Background(), &q, nil)
if err != nil {
    // Handle error.
}

結果の参照も

q.Human.Name

のようにstructでできるので便利ですね(いずれの例も公式READMEより引用)。

ロジックとしてはシンプルで、記事URL内のIDとなる数字を乱数で生成し、その記事IDで取得してきた記事をSlackのチャンネルに投稿するという形になっています。もう少し詳細に書くと

  1. 最新の記事のURLを取得
  2. ${HOST_NAME}/notes/${\d+}というフォーマットのURLが取得できるので、${\d+}を最大値とした乱数を生成
  3. 2.で生成した数値をURLに戻して、記事取得を試みる
  4. 記事が取得できるまでループさせる(記事削除等でID欠けが発生するので)
  5. 記事が取得できたらSlackに投稿する

という形になっています。URLを取得しているのは、Kibelaが持っている記事IDは数値ではないので乱数との相性が悪く、URLを利用しています。

さて、アプリを作ったらこれをどこかにデプロイしないといけません。当時弊社ではちょうどGCP導入の機運が高まっており、Cloud runやCloud functionsに社内ツールを移す話も出ていました。 GCPはまったくもって触ったことがなかったので、これも練習にちょうどいいやとGCPのCloud functionsにデプロイすることにしました。 Cloud functionsへのデプロイに関しては公式ドキュメントを参考に、色々試しながらデプロイしました。 また、バッチの定時キックに関しては、DevelopersIOの記事を参考にPub/Subで行いました。

ということで、デプロイしてPub/Subのスケジュールを調整。 そして完成したのがこちら。

完成したお宝発掘くんのスクリーンショット

今は1日2回、朝とおやつどきに投稿するようにしています。

ハマったところ

ロジックを書くところまでは各種READMEを読みつつ問題なく進んだのですが、GCPのCloud functionsで色々ハマりました。

  • ビルドして単体のバイナリで動かす感じでmain packageを切ってmain関数に書いていたらエラーが出た
  • packageをmainではないものにした上で、unexportedの関数名で関数を切ったらunexportedは読み込めないというエラーが出た

これはCloud functionsの仕様なのですが、どうやらクラウド上でmain.goが動いていて、そこから呼ばれる関数という形で動くみたいなので、exportしておかないとmain.goが動かしたい関数を読み込めなくて落ちるようです。 後でマニュアルをよく読んでみたら、この辺のことは公式のCloud Functions の関数を作成するに書いてありました。

  • Pub/Subをトリガーにして定時キックさせる際は、関数のシグネチャfunc Hoge(ctx context.Context, m PubSubMessage) errorにする必要がある

これも公式のイベント ドリブン関数を作成するに書いてありました。 ドキュメントをよく読みましょうということなんですが、GCPのドキュメントは難しいですね……

作ってみての感想

まず技術的な面でいうと、手軽なCloud functions/GraphQLの練習としては丁度いい規模感でした。 ロジックもGraphQLも複雑ではないし、シンプルに定時実行すればよいので、メインの仕事の合間に勉強として作るには丁度いい規模です。 GCPはとにかく触ってみないとわからないことも多いと思うので、触れる機会が作れたのは良かったなと思っています。

機能面というかお宝発掘くんを実際稼働させてみての感想としては、やはり「こんなドキュメントが社内に埋まってたのか」という発見があるのが楽しいですね。 また、他のメンバーからは昔の記事がサルベージされて「懐かしい」スタンプがついたりと好評(?)なようです。

それ以外での感想としては、何故か社内の出来事と連動して関係のある記事が上がってきて、これ中の人がいるのでは……という気持ちになったり、ランダム性がある投稿が定期的にされるようになったので、なんだか生き物を飼ってそれを観察しているような不思議な気持ちになったりと、思わぬ副次効果もありました。

おわりに

ということで、今回はGo + GraphQL + GCP Cloud functionsでKibelaAPIを叩いてお宝記事を発掘するbotの紹介でした!

今後としては、今はランダムで拾ってきた記事をそのままフィルタかけずに投稿しているのですが、どうしても記事数が多くなる議事録等は確率を少し下げてみたりの調整機能の追加などを検討しています(会議議事録は投稿しなくていいのではみたいな意見もありましたが、昔の議事録を読むのは懐かしいからいいんじゃない?というコメントもあり、とりあえず確率は下げとこうかなという話に落ち着いています)。また、毎回記事だけを垂れ流しても面白くないので、時々サボってみたりとか、時々ランダムで弊社のShared valuesを投稿してみたりとかなどの遊び心を追加しても楽しいかなと思っています。

O'Reilly Learning Platformが導入された話

こんにちは。BBSakura Networks株式会社の金井(@masu_mi)です。 遅れてしまいましたがBBSakura Networksアドベントカレンダーの9日目の記事です。

気づいたら学習環境が良くなっていたという話です。また弊社の学習支援の一部についても触れてみます。 はじめに断りますが網羅的な紹介というわけではありません。

弊社ではCisco Modeling Labsの個人ライセンスなどを経費精算できます。 ほかにもUdemyや資格の報奨金などあるようです。 また学習(書籍購入・購読・サブスク加入等)支援制度のまとめページにはこんな一言が書かれています。

誰もダメとは言っていないので、欲しい人が承認を得て精算すれば良い

必要に応じてACM会員LWNの購読が経費精算できるのは当たり前かも知れませんが心強い一文ですね。

続きを読む

オフラインWEEK オンライン前提の働き方をより良くしていく仕組みについて

BBSオフラインWEEKについて

こんにちは、BBSakura Networksの山口です。 現在は会社の方針を決め、舵取りをする役割の一部をやらせていただいています。 今日のアドベントカレンダーでは、BBSの現在の働き方とその中でいろいろ試行錯誤してるなかで、最近始めたオフラインWEEKについてご紹介させていただきます。

そもそもの働き方?

BBSakura Networks は、ソフトバンクの100%子会社 BBIXさくらインターネット のジョイントベンチャーで、有線/無線を問わずネットワークをソフトウェアでより便利にしていくために、ネットワーク自体をコントロールする仕組みサービスとして提供させていただいています。

実は2019年に設立した当初から、チームメンバーが全国各地に点在していたこともあり、オンラインを前提にした働き方はなくてはならないものでした。

そんな状況ですので、当初から社員がそんなに集まれないことを前提とした、リモートワークのための仕組み、フロー情報のためのSlackとか、ストック情報のためのGoogle Workspaceとか、Kibelaとか、モニタなどの機材の貸し出しとか、細かいところだと経費精算の仕組みとか、電子契約の仕組みとかもわりとリモートよりに充実していたかと思います。

また、オンラインだけの課題というのも割と早くから経験していたこともあり、その辺りの課題感の共有のために、四半期に1度くらいはみんなで集まって、会社の方針を共有したり、特定のテーマに基づいて議論やワークをして、コミュニケーションを活性化させる場としての全社集会(四半期会議)は比較的早くから整備されていきました。

オンとオフの良いところを混ぜてみる

四半期に1度の全体会議を開催していても、コミュニケーションの質というよりも、種類というべきものが足りないなという実感はありました。オフライン前提で会社に集まって働く働き方しかできなかったときには、当たり前にやっていた、「お互い何の用も無いのだけれども、なんとなく場や空気感・課題感を共有する」ようなすぐには効果が見えないようなコミュニケーションです。新しい発想とか、中長期のズレを補正するとか、アイディアを深めるとかというのは、こういうコミュニケーションから出てくるのかもしれないなというのが私のイメージです。

オンラインだけだと、人的・時間的コストが高くなってしまって、「めんどうくさい」が勝ってしまって、そのうちやらなくなってしまうか進めてくれる人にめちゃくちゃ負荷がかかる、これはなんとかしないといけないと思いました。

 BBSでは、今年度からオフラインWEEKという、特定の期間だけ特定の場所に集まって、そこで日々リモートでやっていた業務を、やってみるというイベントをはじめました。 オフラインが当たり前だったころには考えられないことをイベントにしてみたんです。

会社としては、場所とお菓子とドリンクを用意しておく、2回目からはLTの時間が設定されて、お昼ごはんを提供する、グループ会社の人(さくらインターネットの人)も呼んで一緒に働いてもらうというようなことをしました。

おやつコーナーに駄菓子が並べられている

 おやつコーナーで、なんとなくおやつ食べている人がいて、その周りでいろいろな話が自然に生まれて、何らかの関係性ができていく、仕事上のつながりがない人と関係性を作って行くことが、その先の先の事業や、会社のらしさがつくられていくというような面白い場所にできている気がしておりまして、今後も継続していきたいと思っています。

LTのタイムテーブルを書き込む社員

LTで発表する社員

写真に写り込むさくらインターネット社員

※さくらのメンバー!

これからの働き方と課題

当社はこれからも、リモートを前提とした働き方を推進していきたいと考えています。

もちろんオンとオフそれぞれにメリット・デメリットはあるかと思いますが、リモートを前提することによって、少なくとも居場所を移動できない・したくない人の採用ができ、移動したい人が継続的にチームメンバーでい続けてくれます。通勤時間もなくなるしね。

合わせて、出社したい人は自らの意思で出社できるようにしていくことも合わせて重要だと思っています。オフラインでなければならない業務に従事しているメンバーがいる場合には、特に個別の配慮も必要なケースもあります。 例えばIT大手の富士通では2020年に交通費補助を廃止という ニュース がありました。逆に交通費手当を廃止しない企業、または交通費そのものが給与に含まれているような企業の場合には、出社したい時にすればよいひとと出社しなければならない人で、相対的に不公平感がでちゃうなんてこともあります。非常に細かいことなんですが、当社としてもいずれは考えていかないといけないといけないのかなと思いました。(現在のところ、JVの当社では課題にはあがってきていませんが。)

個人的な感覚では、オフィスはすでに、仕事「だけ」をする場所ではなくなってきていると思います。作業だけならコワーキングスペースや、自宅で集中してするのが当たり前に、オフィスでは、ゆるくつながっているメンバーがいるから、そこでしかできないことを考えて集中的にやる、そのような感じに、当社のオフィスの役割は変化していくのかもしれないな。

⁠最後に

月並みですが、メンバーを募集しています!

BBSakuraでは、

シェアードバリューに

 世界を変える、Geeks’PlayGround

行動指針

 Move Quick,ChangeFast
 Respect and be Respected
 Beyond the Border

を掲げており、規範を持って動ける、世界を変えていくようなGeekたちの遊び場にしていきたいと思っています。

ビジネスが継続できるのが大前提ではありますが、新しい仕組みを技術的にも、ビジネスの仕組み的にも作っていける方、これまでの常識に真正面から、時には裏口探して突破できるGeekな方々、ぜひ一緒に面白いネットワークの世界を作っていきませんか?

現時点(2022年12月12日)で採用は、ソフトバンクまたは、さくらインターネットからの出向になっています。ご興味のある方は こちら からご連絡くださいませ!

筆者の DM でもいいですよ!