さくらのバックボーンネットワーク動向2024

公開日

この記事は、2024年1月17日(水)に行われた「さくらの夕べ in 福岡」における発表を編集部にて記事化したものです。

はじめに

小椋と申します。半年前に入社したので、さくらの夕べで話すのは初めてになります。プラットフォーム部のネットワークユニットに所属してまして、バックボーンネットワークなどの管理をしています。これからやっていきたいというものも含めて、バックボーンの設計や構築、それから自動化やSSoTなどをやっていければいいなと思っています。

今日は何を話そうかと考えていたんですが、まずトラフィックの傾向が最近どんな感じだったのかっていうのを調べてみたので共有させていただきたいなと思います。それに伴ってDDoSがどんな感じで来てるのっていうのが個人的に気になったので、そこも調べてみたのでこの場で話してみたいと思います。

さくらのバックボーンネットワークについて

本題に入る前段として、いったんバックボーンの話を簡単にさせていただこうかなと思います。

ご覧になったことがある方もいるかと思うんですけど、基本的に拠点が3つあって、北海道・大阪・東京という形になっております。トランジットが水色の部分ですね。大阪と東京からそれぞれ足を出している形になっていて、IXやPNI(プライベートピアリング)も同じように東京と大阪から出てるっていう感じですね。北海道からは外に出る線がないので、東京か大阪に1回飛んでから外に抜けていくっていう感じのバックボーンの構成になっています。

このバックボーンの中をもう少し詳しく紐解いてみるとこんな感じになっています。上の部分が先ほどの図のPNIとかトランジットの方ですね。トランジットがいくつかあって、あとIXとPNIがあって、ボーダールータっていうものがまずいったんBGPを受け取るという形ですね。その下にスーパーコアルータというルータがあって、これが経路を集約しています。その下にそれぞれのデータセンターのコアルータと呼ばれるルータがいて、その下にエッジルータがぶら下がるっていう、こんな感じの構成になっています。

トラフィックの傾向

今日の発表テーマを思いついた背景として、2023年はさくらインターネットがいろいろと話題に上がる機会が多かったので、そういう外部要因から何か変化が生まれることがあったのかを調べてみたかったというモチベーションがありました。

ガバメントクラウドに関するニュースリリース

例えば6月16日には生成AI向けクラウドサービス開始のニュースリリースが出ました。これもちょっと話題になったような気がします。次が11月28日、ガバメントクラウドの件が発表になったので、ここも話題になったなと思ってます。

実際、その通りでして、まず株価の推移を出してみたんですけど、プレスリリースが出たタイミングでわかりやすくポンポンと上がってるのが見て取れると思います。

では検索はどんな感じで推移するのかなっていうことで、Googleトレンドで「さくらインターネット」がどれぐらい調べられてるのかを見てみたんですけど、これも結構似た感じになってて、プレスリリースが出たタイミングで、そもそもこの会社は何やってんのみたいな感じで検索してもらったようで、ちょっと件数が跳ね上がってる感じです。

そうなってくると、ではトラフィックの傾向にはどんな変化があったのかなっていうのが気になってきます。

これがトラフィックの推移です。上がOutgoingのトラフィックで、下がIncomingのトラフィックになります。赤枠で囲んだ部分が2か所ありますが、これが先ほどの6月18日とか11月28日のあたりになります。これを見ると、形状に変化があったかっていうとあんまりそんなでもないかなと思いますね。全体的にはちょっと右肩上がりと言っていいのかわかりませんが若干増加傾向にあるものの、外部要因によるトラフィックへの影響が大きく顕著に見られるかっていうと、なんかそんなに見られなかったなというのが感想でした。

トラフィック傾向についてまとめると、トラフィック自体は緩やかに伸びていますが、バックボーンネットワークの帯域は十分に余白を持った運用をしてるので、急激に伸びてもそんなに問題ない運用にはなっています。

ただ、どうしてこんなことを調べてきたかっていうと、会社が目立つというか表に出る機会が多くなると、攻撃される回数の推移がちょっと気になるなと思って、それに伴ってトラフィックが動いたかなっていうのを見てみた結果、そんなに多くなかったって感じでした。

DDoSの傾向

こちらが2023年度のDDoS発生件数を月ごとに算出して折れ線グラフでまとめたものです。先ほどと同じように赤枠の部分が6月18日とか11月28日にあたるところです。なんとなく6月はスパイクというかちょっと件数が増えているのが形になって見えるなと思います。11月の方はちょっと前半に来てるような感もありますが、そんなに変化が見られなさそうな感じはありますね。

ただ、この6月っていうのが、外的要因でさくらのインフラ向けの攻撃が増えたのかというと、実はそんなこともなくてですね。6月の件数がポンと上がっていましたが、日付ごとに見てみると攻撃は割と上旬に固まっていました。プレスリリースが出た6月18日以降については特に変化がなかったようです。なので、結果的にちょっとスパイクっぽく見えてましたが、実際にはあまり影響がなかったなと思ってます。

先ほど紹介したDDoSの対象はさくらインターネットのインフラだけじゃなくて、クラウドやVPSなどいろいろなサービスのユーザ向けのDDoSも件数に入っています。で、その中で社内インフラに対する攻撃がどれくらいの割合だったのかっていうのが上記スライド下部の円グラフです。左側が2023年度の統計で、2か所飛び出しているのが社内インフラに対する攻撃です。これを見ると、社内インフラ向けの攻撃の割合は、2%が2か所あるので合計4%ぐらいですね。右側の6月だけのグラフでは13%と3%の部分が社内インフラ向け通信への攻撃です。こちらを合計しても16%ぐらいなので、まあそんなもんだよねっていう感じです。

さくらのDDoS対策

DDoSの話をしたので、その対策としてどんなことをやってるかっていうのも、過去に別の人間が話したこともありますが、改めてお話ししてみたいなと思います。

弊社ではハードウェアのアプライアンスでMitigation(攻撃の遮断や回避)するようなことをやってなくて、自分たちで作ったシステムを運用してるっていう形になってます。選択肢としてはアプライアンスもあったんですが採用しなかったということですね。スクラビングのサービスみたいなものもありますが、これも結果的には採用していません。

これが現状のDDoS対策システムの概要です。ポイントをいくつか説明します。

DDoSの検知は、ルータから取得するsFlowの情報を使って検知します。検知をなるべく早く実施したいという目的から、VoltDBを使って高速に検知する形になっています。検知した後、トラフィックをルータからOpenFlowスイッチに転送します。ここは後ほどもうちょっと詳しくお話ししますが、OpenFlowスイッチでMitigationするっていう感じですね。そこでスクラビング(正常なトラフィックのみ通す)してトラフィックを軽減して戻すっていう形です。ざっくりとした概要としてはこんな感じの流れになっています。

先ほどの説明を図にしたものがこちらです。最初に説明したバックボーンネットワークの上半分ぐらいを持ってきたものになります。通常のトラフィックは赤色のルートで抜けていきますが、それをコレクターに送信しているMitigationシステムっていうのがあります。

Mitigationシステムでは、入ってきたトラフィックを高速に解析してます。それから、特定の宛先に閾値以上の異常なトラフィックが流入してないか、大量のショートパケットトラフィックが流入してないかっていう2つのポイントをチェックしています。

そして、DDoSを検知したらオペレータにプッシュで通知します。スライドの右下に小さくシステムの画面が載っていますが、これがオペレータが見ている画面です。

こちらはどんな感じでMitigationしているかという流れの話ですね。オペレータは先ほどの通知によってDDoS検知の情報を知るので、その後、状況を先ほど小さく掲載した画面で確認し、OpenFlowスイッチに対してトラフィックの送信を指示します。この指示はオペレーターがシステムUI経由で出します。そうすると、その対象ネットワークに対してBGPで経路を吐き出すので、それを引っ張ってくるっていう感じですね。こうしてOpenFlowスイッチの方にトラフィックを持ってきます。

で、トラフィックを引っ張って来れたら、そこでスクラビングしてドロップする場合もあれば、きれいにしてまた戻すっていう場合もあるんですけど、そんな感じでまた元に戻して、宛先まで届けるっていう流れになってます。

もう少し細かい話をします。ここでは宛先のIPアドレスを書き換えるというやり方を採っている話をします。

引っ張ってきたのは上図のDST:Aと書いてある赤色のところで、こちらが実際に飛んできたフローのトラフィックですね。これを先ほどのBGPのアドバタイズでOpenFlowスイッチに引っ張ってきました。その後、そのままDST:Aの赤色のIPアドレスで返すと、ボーダールータのルーティングテーブルはOpenFlowスイッチ側に向いてるんで、トラフィックがまた戻ってきちゃうっていうのがあります。なので、いったんここで、宛先のIPアドレスをDST:A'っていう別のIPアドレスに付け替えてます。これはDDoSのMitigationシステム用にアドレスプールされてる中からIPアドレスをアサインして付与するっていう感じですね。そのDST:A'という、図では黄色くなってるトラフィックが乗っかってきて、ルーターの下側にもう1つOpenFlowスイッチがありますが、こちらで元のIPアドレスに戻してあげて、ネットワークの中にまた返してあげるっていう、こんな感じになっております。

それでも防げないというか、想定以上のトラフィック流入があった場合はどうするのっていう話ですが、その場合はもう上流側の方でRTBH(Remotely Triggered Black Hole Filtering)してもらうようになります。これもMitigationシステムの方で経路広報する設定を入れるっていう感じですね。

まとめと参考情報

なんか自分が作ったかのように話しましたが、私は何も作ってなくて、さくらに入社したらこんなものがあったって感じです。

バックボーンネットワークの運用については、詳しく書かれている事例みたいなものもありますので、興味のある方はご覧ください。さくらのナレッジには「ふたひねり効かせたOpenFlowの利用事例」という記事があります。ふたひねりと言ってるのは、先ほどのトラフィックの戻し方の説明にあった、アドレスを1回ひねってまたもう1回ひねっているからふたひねりっていうことらしいです。また、VoltDBの方でも事例として載っているみたいなので、そちらも見ていただければうれしいです。

ということで、バックボーン動向と言いつつ、後半はDDoSの話になってしまって恐縮ですが、以上で発表を終わらせていただきたいと思います。ありがとうございました。

質疑応答

質問者A：DDoSを検出したらオペレータが判断してから実際に曲げるってなってましたけど、単に検出したら曲げるのではなくオペレータを介在している理由と、あとそれで実際に何かうれしかったというか、やっぱりオペレータがいてよかったということがあったら教えてください。

小椋：例えば、大量のトラフィックが入ってきても判断の余地がない場合ですね。上の方でRTBHしてしまう場合。あれはもうオペレータを介在せずにやってもらっちゃいます。

もう一方というか、判断が必要な方っていうのは、サービスによって閾値みたいなものが各々決まってるんですけど、その判断材料をDBの中でちゃんと持ててないというか、そこをきれいにすれば判断材料をDBの中で持てるので、フローのデータから「これはこのサービスだからこうだよね」っていうのができるんですけど、それが現状うまく整えられてないがゆえにいったん人の判断が入ってしまってるっていうことだと思います。

質問者A：ありがとうございます。熟練の目利きがいるわけですね。

小椋：そうですね。結局そういう部分ポイントがあったりします。

質問者B：VoltDBを使っている理由を知りたいです。

小椋：まず高速であることが必要という話を聞いてます。他にもあったと思うのですが、私と同じユニットで仕事している中西さんに回答をお願いしたいと思います。

中西：VoltDBを採用した理由については僕も詳しくは聞いてないですけど、まずDDoS判定をするためのカウンターまわりを高速で見るためにはInMemoryデータベースが必要だったらしいです。その中でもデータベースの設計思想が、そういった集計により適したものがVoltDBだったということを、このシステムの開発者から聞いています。

発表を終えて

JANOG day1の後にも関わらず、ご参加いただきありがとうございました！ 非常に緊張しましたが素敵な時間を過ごさせていただきました。席の外からも意見や感想が飛び交う場だったので、このような場も貴重だなと再認識することができました！