NREに向けた取り組みとさくらのサービス別通信状況（β）について
この記事は、2024年1月17日(水)に行われた「さくらの夕べ in 福岡」における発表を編集部にて記事化したものです。
目次
はじめに
さくらインターネットの米田と申します。「NREに向けた取り組みとさくらのサービス別通信状況(β)について」ということで今回お話しさせていただきます。
内容を最初にさらっとお話しさせていただきますと、まずリアルタイムの通信状況を確認できるステータスページを、2023年9月27日から「さくらのサービス別通信状況(β)」ということで提供開始しました。図の右側の部分がそれですね。こういったものをβ版ですが提供を開始いたしました。このシステムの中身や、この取り組みの背景といったところが発表内容になります。
自己紹介
続いて自己紹介です。大阪出身で、今も住んでいます。さくらインターネット株式会社のクラウド事業本部 プラットフォーム部 ネットワークユニットっていう、ちょっと長い部署名のところに所属しています。この業界には地味に長くいさせていただいてるんですけども、さくらインターネットには2022年度の新卒ということで入りまして、現在2年目になります。
それに加えて一般社団法人HomeNOC Operators’ Groupの代表理事をやっていたり、一般社団法人techfeeloという名前になっていますが、doornocという団体の運営もやっています。趣味としてはインフラ歩きをしつつ旅行を楽しんだりとか、大阪の人はみんな使うと思うんですけど「しらんけど」っていう言葉をモットーに生きています。
これまでのネットワーク品質測定
ということでここからが本題で、最初にお話しさせていただいた内容をメインに話していきます。
まずこれまでどういったことをやっていたかというと、SNMPなどをベースに測定情報の取得や検出をしていました。どこの会社さんでも、SNMPだけだけじゃなくてICMPでpingを飛ばしたりとか、OSSの測定ツールでZabbixとか、他にもいろいろ良いツールがあると思うんですけど、そういうツールを使っていると思います。うちの社内にも昔から歴史的な理由で使われ続けているシステムがいろいろとあります。
この方法の長所としては、OSSを使うことで比較的簡単に構築できるという点があるかなと思っています。その一方で短所としては、いろんなツールがあると障害箇所を調べるのに時間がかかりますよね。特に測定箇所が限られるというか、測定用のサーバを設置するとしても、そもそもその拠点にサーバが設置できるかとか、そのあたりから問題があります。他にも、ここをもうちょっとこうしたいなっていうときに、自分でプログラムを書ける人は書いたらいいですが書くのが難しい場合もありますし、バイナリで提供されているプログラムもあるので、なかなかかゆいところに手が届かないといったところもあるかなと思います。
そこでどういった問題が起こるかと言いますと、障害が発生したことはすぐにわかっても影響範囲がどこまで及ぶかがわからなかったたり、ここが悪いかなと思っても調べてみるとやっぱり違ってたとか、そういったことがありました。
障害をすぐに検出可能なシステムの開発
そこで今回のツールを作ったことで何が変わってきたかっていう話です。測定箇所を増やして障害をすぐに検出できるシステムを作ろうということで、その一環としてネットワーク品質可視化システムを今回開発しました。
これの長所としては、障害が発生したときの影響範囲を調べる材料が増えます。他にも、回線品質やサービスのネットワーク障害を検知できます。その一方で短所としては、現時点では障害の判断材料としてしか使えておらず、判断は人力に頼ることになります。人力で頑張って調べるのは、特に障害などで急いでいるときには結構しんどいのでそこはまだ課題として残っているのですが、とりあえず現時点では判断材料が増えましたという状態です。
システムの仕組み
では、このシステムの仕組みを説明します。
まず、「さくらのサービス別通信状況」というものをβ版で出させていただいてるんですけれども、これはサービスからインターネットに抜けるまでの当社ネットワークの健康性を表示したりとか、バックボーン区間のRTT、例えばpingを打って何msecとかって出てくると思うんですけど、そういった往復遅延の値を測定していて、それを表示しているものになります。
このシステムの構成を上図に示します。ウェブアクセラレータという当社のCDNサービスがあるんですけど、これの大阪リージョンにエージェント(測定ノード)を設置しまして、東京リージョンにも同じように測定ノードを設置しまして、その測定ノード同士で通信したりとか、それからインターネットに出る直前のルーター付近にもエージェントを設置して疎通を取り合っています。それで、もし10分間連続して断があるとウェブページの表示がNGになります。バックボーンネットワークの遅延は数値で表示していますが、断があるともちろん測定に失敗するので、数値が表示されずにNGの表示になります。
エージェントの中身
続いてエージェントの中身を紹介します。機器としてはRaspberry Piを使用しています。スライドの右側がRaspberry Pi 4で、左側はRaspberry Piの10Gbps対応版です。最近のルータは10Gしかついていないものがあったり、イーサネットがついていないルータも多いんで、そういったニーズにも対応できるように、こういった機器を使ってエージェントを作って設置しました。これ以外にも実は普通の1Uのサーバを使ったりもしています。
今後の展望
それで、こういった仕組みを作ったのはいいんですけど、これからはこれをもっと多用して、他のシステムとも連携して障害箇所を自動的に判別できるようなシステムを作れればと思っています。先ほどお話ししたように、現状ではまだ判断材料にはなるけどすぐに障害かどうかまでは判別できないという短所があるので、それを解決するためのソリューションをこれから作っていきたいと思っています。マイクロサービス的なものを作って、マイクロサービス同士で通信して、そこからシステムの方で自動的に判別して、ネットワーク障害が起きたときにここがダメですよとかここは正常ですよとか、そういったものをこれから作っていければというところで現在進行しているところです。
NREに向けた取り組みについて
最後に、当社におけるNRE(Network Reliability Engineering)に向けた取り組みについて説明します。
私達の会社にも一応従来から開発体制があり、自動化っていうのをやってはきたんですけど、チームとしてちゃんとまとまってやっていたわけじゃないんで、もっとプロジェクトとしてそれを加速できるような仕組み作りを今やっています。その中に今回お話ししたネットワーク品質可視化プロジェクトがありまして、その他にもネットワーク自動化のプロジェクトとか技術交流とか、そういったものがあります。先ほど「今後の展望」のところでお話しした部分がネットワーク自動化プロジェクトと絡んでいますので、そういったことを今後引き続き進めていけたらなと思っているところです。
JANOG53の展示ブースについて
2024年1月17日(水)〜19日(金)に開催されたJANOG53において、当社のブースにて本プロジェクトの展示を行いました。上の写真が展示ブースで、左側が本プロジェクトの展示になっています。拠点に置いているエージェントと同じものを展示ブースにも設置し(写真左下に見える黒い小さい箱)、当社の拠点との間の通信状況をご覧いただきました。エージェントは有線LANで接続しているので、ケーブルを抜くともちろん通信断になります。そういったところもご覧いただきました。
発表を終えて
このプロジェクトは長く開発を進めてきましたが、ようやくβ版としてみなさんに提供が出来るものとなりました。今回の発表で実際に大切なフィードバックもたくさんいただきましたので、本システムにも反映させていければと思います。また、NREでは同様に弊社でしか出来ないような新しい物の開発などを今後もより一層進めていきますのでよろしくお願いします。