IGFが日本にやってくる!

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

先日のInternet week 2022でのIP Meetingにて

少し前までは「本当に怖い怖いIP Meeting」と思っていたのですが、自分も年を取り気がついたらオーディエンスの方が若い人が多くなっている昨今、自分がしっかり伝える立場になったのだなと改めて思った次第です。
ここに「IGF2023を睨み、情報社会のいろんなことを語ろう」というタイトルで私もパネリストとして出演しました。メンバーは

江崎 浩さん(JPNIC理事長)
小林 茉莉子さん(株式会社メルカリ mercari R4D リサーチャー)
西潟 暢央さん(総務省総合通信基盤局電気通信事業部データ通信課長)
加藤 幹之さん(IGF2023に向けた国内IGF活動活発化チーム チェア)
前村 昌紀さん(一般社団法人日本ネットワークインフォメーションセンター 政策主幹)
福智 道一(BBIX専務取締役)

とても豪華なメンバーで「何で福智さんここにおるんや?」とおもった人も多かったと思います。
自分でも何でだろう??と思ったぐらいですので。
呼ばれた理由を推測しますと、最近ウクライナ事情などでインターネット周りでいろんなことが起こったことやスプリンターネットなどの話題が盛り上がってる中、IX事業者としての視野角でインターネットがどう見えるのか何か話してほしいという感じかと思います。

そもそもインターネット・ガバナンスって何やねん

https://www.nic.ad.jp/ja/governance/about.html
このJPNICの解説に詳しくのっていますが、要は

  1. 「ガバナンス」と聞くと企業統治とかを思い出すけど
  2. インターネットはマルチステークホルダーによって構成されているし
  3. 単一の管理機構がなく中央集権的にルールを決めていない
  4. それゆえインターネットが健全に運営されるためには、 通信プロトコルの標準化、 統一された識別子の管理分配方法をはじめとした、 インターネット全体で共有されるルール策定が重要

ということなんですよね。

インガバを語る上で私が大好きな言葉と絵

We reject kings, presidents and voting.
We believe in rough consensus and running code.
(Internet Engineering Task Forceより)
この言葉と

この絵 (https://www.icann.org/en/system/files/files/ecosystem-06feb13-en.pdf)

本当、これに尽きるよねー

んで、IGF(Internet Governance Forum)ってなに?

ここは、IW2022でのあおちゃんのプレゼンをそのまま貼り付けますね。

総務省のある方に言わせるとIGFは、
「もちろん格式高い議論もありますが、いろんな人がいろんなテーマで話をしているのでもっと気軽に参加してもいいと思うよ」だそうです。

本当に日本で開催されます!!

https://www.soumu.go.jp/menu_news/s-news/01tsushin06_02000261.html
総務省の報道資料にもあります通り
令和5年10月8日(日)から12日(木)の5日間
場所は京都市にあります国立京都国際会館にて

せっかく日本で開催されるのだから

日本初開催となるIGF2023ですが、正直盛り上がりも準備もイマイチな感じがします。
IW2022のパネルディスカッションでもどうやって様々な人々を巻き込むかが課題だと。
特に若者の関心を集めることが次世代につながるので重要かと。
私が提案したのは日本最大のインターネットコミュニティであるJANOG
若者を交えて議論する場を用意すればいいのではないか?ということです。

2023年1月25日からJANOG 51が富士吉田で開催されます。
どなたか野良BoFで議論してみませんか?
少なくともJANOG若者支援プログラムに参加している学生さんには
必ず参加してもらいたいものです。

ご参考までに同じく先日行われた
『Day 2 特別セッション「IGF2023日本開催へ向けて」@日本インターネットガバナンスフォーラム2022 ~ IGF2023日本開催を見据えて』の録画を貼り付けておきますね。
時間のある方は参考までにご覧ください。


www.youtube.com

あとがき

すみません、投稿が超ギリギリになってしまいました。
もう来年は書かないかも
もし、書いてほしい!ということであればライターさんを募集します。
お礼は。。。晩ご飯、奢ります!^^

BBSakura Networksの今後について

BBSakura Networksの佐々木です。この記事はBBSakura Networkのアドベントカレンダー 最終日として投稿致します。 2019年に BBSakura Networksについて ということで、Blog投稿をさせていただきました。 当時は会社設立したばかりで、開発が完了しているサービスが何もございませんでしたが、今はいろんなソフトウェアを開発しております。本日はそれらのうちいくつかの紹介と、今後やりたいことについて少し紹介をさせて頂きます。

BBSで開発している物

BBSではさくらインターネット、BBIXを通じて開発しているソフトウェアを出しております。 特にBBIXでソフトウェアを使って実現しているサービス、システムはほとんど全てBBSのメンバーで開発されています。

BBSで開発しているシステムをいくつか紹介させていただきます。

さくらのクラウドのショートメッセージサービス

さくらのクラウドのショートメッセージサービス のバックエンドシステムはBBSにて開発しております。さくらインターネットとBBIXで一緒にBBSを作りましたので、両社のシナジーも込めて最初に商品化しました。

さくらのセキュアモバイルコネクト

さくらのセキュアモバイルコネクト は私がBBSを作りたいと思ったきっかけとなるプロダクトでしたが、今はBBSのメンバーでソフトウェアの保守・改良を行っています。 通信事業者で長らく働いていた私には、かなりエポックメイキングな商品だと思ってます。

BBIXのシステム

BBIX ウェブサイト もデザインは一部外に出しておりますが、BBSのメンバーで作成されてます!

BBIXお客様向けポータル

BBIXのお客様向けポータルではユーザーの情報などとともに、xflowを使ったトラフィックの可視化などを行ってます。 先日、advent calendarに投稿 してくれた蟹江もこちらの開発に従事しております。 トラフィックが目に見えるようになるのはネットワークエンジニアにとって楽しいですよね!

OCX (Open Connectivity eXchange)

OCX はBBSメンバーが主導となり開発したサービスとなります。 元々はCloudIX研究会でInter-Cloudというコンセプトを議論していたのですが、そのときにクラウド間のみならずマルチに簡単に接続出来るPlatformについて妄想を膨らませており、そのときのコンセプトをプロダクトにしました。蛇足ですが、 CloudIX研究会 は業界の様々なエンジニアが集まり、インターネット業界に入ったばかりの私にとっては大変刺激的な会でした。 あの出会いが無ければ今のOCXは無かったと思います。

OCXで実現したいこと

現在、ネットワークは当たり前ですが人間が使ってます。Webを見たり、動画を見たり、検索をしたり。なのでインターネットのサーバーとユーザー間の通信をeyeballトラフィックと呼んだりしておりました。 しかし、昨今、サーバー間・コンピューター同士の通信が増えており、通信の利用者の割合が「人間」から「ソフトウェア」へ、わかりやすく言えばAIへ急速に置き換わっていっていると感じてます。 現在の通信ネットワークは人間が利用するのを前提として設計がされてます。「人間」が申込みをしなければ使えませんし、「人間」が設定を入れなければつながりません。これから通信の利用者の中心がコンピューターとなるため、コンピューターに適したネットワークを用意しなければいけないのです。つまり、ネットワークをプログラマブルにし、ソフトウェアから扱いやすいものにしていきたいと思ってます。 これからデジタルツインと呼ばれる世界を作る中で、プログラマブルなネットワークは必須になってくると信じており、これを実現していきたいと考えております。世の中の様々なデータとサーバー基盤を連携させるための通信基盤。これを実現することで、デジタルツインを実現出来ると思っております。

理想と現実

一方で世の中が人間中心である中、いきなりコンピューターのみをターゲットにしたサービスは事業として成立しないなと思います。そこで、まずは人間にとって便利なネットワークを目指してOCXのサービスを開始しております。 今現在、OCXで出来ることは、データセンター間接続、マルチクラウド接続、ルーター機能となっておりますが、次々に「出来ること」を増やしていきたいと考えてます。このとき、いろいろなソリューションを簡単に組み合わせできるようなプラットフォームにしていきたいと考えており、Openに外部のソリューションを取り込めるような仕組みも取り込んで行きたいと思っております。 また、全国規模のアクセスポイントや様々なアクセス種別のインフラを地域地域のみなさんと一緒に構築し、ひとつの大きなネットワークプラットフォームを作ることで、ネットワーク効果を作って行きたいと考えております。

BBSakura Networksの今後

BBSakura Networksではソフトウェアをベースに世界に羽ばたくプラットフォームを作りたいと考えておりました。 まずは直近の2-3年で、国内の企業向けのネットワークサービスとして、ほとんどの方が「OCX」について認知を出来ているという状態まで広げていきたいと思ってます。並行して、海外にもサービスを展開していきたいと考えてます。OCXでは様々な技術が使われることになりますので、都度必要なソリューションをBBSとして拡充していきたいと思っております。 全ての「モノ」がつながる社会を支えるテクノロジーカンパニーを目指して、いろいろな種類の回線、クラウドサービスと接続し、こんなところにまでBBSがという状態に出来ればと思ってます!

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を投稿してみたりとかなどの遊び心を追加しても楽しいかなと思っています。