拠点を接続する、最近の話

この記事は、2022年1月28日(金)に行われたJANOG49における発表を編集部にて記事化したものです。

自己紹介

小岩と申します。ビットスターという札幌の会社で働いています。ビットスターは一言で説明するはなかなか難しいんですけど、「ITで、こまったを、よかったに。」をスローガンにいろいろやっている会社です。あと、一般社団法人LOCALっていう、北海道を中心にITコミュニティの活動を支援する団体の理事をやっています。それから、札幌で「88NITE」っていう、ゲーム音楽のパーティーをクラブでやったりするイベントでDJをやってます。好きな焼酎は三岳です。まとめると「妻とLesMillsとHardstyleとfunkotとホッピーとバーボンとレモンサワーを愛するどこにでもいるサラリーマン」です。

何の話か

今日は何の話をするかというと、日本の国内に支店とか拠点がいくつかあるような、よくある企業内部ネットワークの最近の話をしたいなと思っています。

広域な内部ネットワークに対する変化

はじめに、最近こういった広域な内部ネットワークに対する変化がいろいろあって、例えばクラウドやSaaSをみんな使うようになったりとか、コロナウイルスの影響で業務とかビジネスの流れが変わったりとか、あとは今まで境界型のセキュリティを使っていたのがゼロトラストを使ったりとかっていう感じでいろいろと変化があります。

もう一つ、オフィス需要の変化もあって、ビットスターも今はフルリモート勤務なんですが、今まで大きい事務所を構えていたのが事務所がなくてもいいんじゃないかとか小さくてもいいんじゃないかとか、さらにその事務所のネットワークに対しての需要の変化もあって、ただインターネットにつながればいい、インターネットにつながってSaaSとかクラウドのサービスを使えばいい、っていう変化もあると思います。

そういう変化が難しい業種もある

ただその一方で、そういう変化に対応することができないとか難しい業種ってのもやっぱりあって、例えば僕らのようなIT系の業種だと割と対応しやすいんですけども、実店舗を持つ小売業とか製造業とか、それから運送業、あとは酪農・農業・漁業といった第1次産業の業種に関しては、こういう変化に対する対応は難しいんじゃないかなと思います。そういった方々、つまり従来型のネットワークが必要な業種の方々に対しても、クラウドとかSaaSへの対応とか、あとは組織内部の通信の増大もある中で、やっぱりネットワーク設計のアップデートが必要なんじゃないかなと思っています。

そこで今回は、そういうネットワーク設計のアップデートに関するデザインパターンみたいな話をいくつかさせていただければと思っています。

拠点を繋ぐ話

はじめに拠点を繋ぐ話をしたいと思います。

NGN折返を使う方法

まずNGNの折り返しを使って拠点を繋ぐといいことがあるよねという話があります。これは僕が去年、ちょうど1年前ですが、福岡のJANOGで「NGN折返し通信を用いた広域ネットワークと、その他いろいろ」という発表をしました。NGNの折り返しを使ってネットワークを組むと広帯域で低遅延のネットワークが作れるという話です。

上図のような感じで、NGNの折り返し網の中でIPsecを張ってOSPFでルーティングを回せばいいというネットワークが作れます。こうすることによって高速で低遅延なネットワークを安価に構築することができます。

この方法を従来のインターネットVPNや広域イーサーを使った方法と比べるとどうかっていうと、インターネットVPNと比べると高速で低遅延なネットワークを構築できますし、広域イーサーのサービスを利用する方法よりも安価にネットワークを構築することができます。

モバイルの活用

もう1つの方法はモバイルの活用ですね。今は高速のモバイル通信がいろいろ出てきてますので、それを使うことによって拠点を接続することもできるかなと思います。例えば拠点側の冗長性の確保として、メインの回線はフレッツ光を使ってNGNの折り返しをやります。そして、バックアップの回線をモバイルで用意し、インターネットVPNで接続することによって、例えばフレッツ光の故障やルータの故障に対する冗長性を拠点側で確保することができます。

ただ北海道は…これ北海道固有の話題なのか他の地域もそうなのかはわからないんですけど、光回線がない場所ってのが結構あって、ちょっと都市部から離れたりとか、街のちょっと離れた場所になると光回線が引けませんと言われる場所も多くて、そういうところではどうしてもモバイルが主回線になってしまいます。ただ小さい拠点であまり人数がいない事務所とかだと、モバイルでも割と帯域幅が大きいので意外と使えるというのが最近の所感です。

しかし、モバイルの回線は天候に左右されるケースが多くて、実際にあった話なんですけど、雨が強くて、ネットが不通になるのはそのせいだと思ってたと。昼夜に関係なく雨が降るとネットが切れることがあって、たぶん雨が降ると防風林が濡れてそれで影響が出てるんじゃないかみたいなレポートが上がってくることがあります。こういうところで天候に左右されてモバイルのリンクが切れちゃったりってことがたびたびあって、こういうのって5Gになると改善されたりするのかどうかはちょっと聞いてみたい、議論をしたいポイントです。

クラウドと接続する

一方、拠点側からクラウドにどう繋ぎ込むんだっていう話もあります。例えば各クラウド事業者、AWSとかAzureとかさくらのクラウドとかGCPとかいろいろあるんですけど、それらに対して既存のネットワークからどうやってクラウドに接続するんだっていうのも、いくつかデザインパターンがあるんじゃないかなと思っています。

既設ネットワークの活用

1つの方法は、既存のネットワーク、例えば広域イーサーのサービスを活用してネットワークを引いてますよっていう場合ですね。こういうところに対してどういったアプローチをしていくかというと、1つのアプローチとしてはこういうのがあるかなと思っています。

これはさくらインターネットの場合なんですけども、さくらインターネットのハウジングラックに実際に回線を引き込んで、そこからさくらのクラウドにハイブリッド接続で繋ぎ込みに行くという方法も使えるかなと思います。

これの利点としては、オンプレミスで動いているサーバーをクラウド化したい、IaaSのサービスに持っていきたい場合や、あるいはレガシーな課題、例えばサーバのIPアドレスを同番で移行したいとか、あとは多拠点のケース、例えば小売業などで全国に拠点があって、各拠点の設定変更やネットワークの変更をするのはすごいコストがかかってとても対応ができないので、拠点側の設定変更をしないでそのままクラウドに接続したい、というような場合にはこの手が使えるかなと思っています。これは実際に僕の方で対応させていただいて、さくらインターネットの事例紹介のサイトで紹介されていますので、興味のある方はそちらをご覧ください。

NGN折返の活用

同じような感じで、NGNの折り返しも活用できるよねっていうパターンがあります。これもまたさくらインターネットの話になってしまうんですけども、北海道の各拠点からNGNの折り返し網経由でさくらインターネットの石狩データセンターのハウジングラックに引き込んで、そこからハイブリッド接続でさくらのクラウドに繋ぎにいきます。

これは何がおいしいかというと、NGNの折り返しを使っているので通信が北海道内で完結し、非常に安価で高速で低遅延なネットワークを構築することができます。北海道からクラウドを使うっていう話になると、例えばAWSでもAzureでもGCPでも東京に1回行ってそこからまた戻ってくることになるので、単純にインターネットVPNとか張ると50ms〜70msといった遅延がどうしても発生してしまうんですけども、通信を北海道内で完結することによって2ms〜4msぐらいの低遅延のネットワークを構築することができます。こうすると、エンドユーザから見るとほぼ社内にサーバがあるような感覚でネットワークを使えるので、非常に業務の改善であったり効率化が図れると思います。

いっそ直接つなげてしまう

さらに、いっそ直接繋げちゃおうという話もあって、これはうちの会社で計画をしているんですが事務所の移転とかもあってまだできていないんですけども、ビットスターの本社からダークファイバーでさくらインターネットの石狩のハウジングラックに繋げちゃって、そこからクラウドに繋いでいくっていう方法もあります。これはダークファイバーで直接接続するので、経路長によってリンクするかどうかの博打が若干あるなと思っているのと、あとはダークファイバーが切れちゃうと終わりなので、それの回避手段をどこかで用意しないといけない、例えばインターネットVPNを併用するとか、そういったことが必要になるのかなと思っています。

あとこれはもう完全に北海道特有の問題なんですけども、2月とかの寒い時期で気温が-20度ぐらいになると光ファイバーの特性が変わって軋轢が起きたりとか通信速度が落ちたりとかリンクが落ちたりすることもあるので、その点をちょっと気をつけないといけないなと思っています。

AWSとの接続

ここまでがさくらインターネットを中心とした接続の話なんですけども、たぶん皆さんもっとお使いになってるのはAWSだと思うので、そことどう繋ぎ込むかっていう話をしたいと思います。

インターネットVPNを使うか閉域接続を使うか

AWSにEC2のサーバを置いたりRDSを使いたいという場合に、当然ながら各拠点からどうやって接続するんだって話になると思います。今日の話はあくまでも複数拠点がある企業の内部ネットワークの話なので、そこからどうやって接続するかという話になるんですけども、いくつか方法があって、インターネットVPNを使いましょうって話と、あとは何らかの閉域接続のサービスを使いましょうという話です。後者については、例えばフレッツVPNワイドからクラウドゲートウェイ クロスコネクトを通してAWSのDirect Connectに接続しましょう、みたいな方法が取れると思います。

ただ、これをやると、各拠点から接続をしに行くのでコストが高いっていうのと、あと社内で動いてるサーバやサービスが全部AWSに上げられればいいんですけどそうもうまくいかなくて、オンプレミスの機械との兼ね合いとかもあったりします。あとはインターネットの接続を1か所でUTMとかで管理をしている場合に、そこをどうするんだみたいな話もあってなかなか難しいと思っています。

AWSへの接続を集約する

そこで結局どうなるかっていうと、たぶんAWSへの接続は集約をする形になるんじゃないかなと思ってます。どこか1か所で各拠点間の接続を受けて、そこからAWSに接続をしに行くような形ですね。こうするとコストも抑えられますし、運用管理の変更があまりダイナミックな変更にならず小さい変更で済むので、運用管理をする方も楽かなと思います。

おそらくネットワーク図としては上図のような感じになります。拠点側のネットワークは左側にあって、そこからインターネットの出口に接続し、そこからフレッツVPNワイドからAWS Direct Connectに流れていくような感じになるのかなと思います。

一点障害を回避する

ここでこの構成を作った場合に問題があって、図のフレッツVPNワイドより右側の部分が一点障害になります。ここで障害があるとAWS側の設備(サービスやサーバ)につながらなくなるので、業務がストップしたりとか遅延したりっていうことが発生します。ここはどれぐらい落ちるんだみたいな話も若干あるんですけども、やっぱり障害はあって、Direct Connect全落ちっていうこともあったので、ここをどうにか回避する必要性があるんじゃないかなと思ってます。

ここで障害となりうる要因としてはいくつかあって、例えばNTT東日本から貸し出されるCPEのハードウェア障害(CPEが壊れちゃってフレッツ光につながらなくなっちゃうとか)、フレッツ光自体の障害、あとは先ほど紹介したようなAWSのDirect Connectの障害など、いくつかの障害要因があります。よって、これらの障害が起きたときにもAWS側に接続ができるようなネットワーク構成にしなきゃいけなくて、例えば下図のような感じでインターネットVPNを張りましょうかってのが一般的な解決方法になるのかなと思います。通常は下の正系のネットワークで広帯域のネットワークを使ってて、もしそれに障害が起きて落ちちゃった場合は上の副系のインターネットVPNにフェイルオーバーしてそっち側で通信を行うような形です。

このようにAWSの接続を冗長化した場合にどうなるかというと、正系はフレッツVPNワイドからクラウドゲートウェイ クロスコネクト経由でAWSのDirect Connectを通ってVPCのバーチャルゲートウェイ(VGW)に入っていきます。副系はインターネットVPNを通して直接VPCのVGWに入っていくような形になります。

障害をどう検知するか

このときに一つ問題があって、正系の障害をどうやって検知するんだっていう話が出てきます。AWSにおいてはネットワークの障害検知とか障害回避は基本的にBGPのルーティングでやっているらしく、BGPのパケットの到達性で検知をしています。VPCのVGWにおける正系/副系の切り替えに関しては完全にBGPのルーティングを使っていて、正系の方でBGPが回ってこなかったときはインターネットVPNの方に切り替えますみたいな感じの動きになってます。

上図に構成を示しますが、AWS VPCのVGWは、BGPのルーティング交換することで到達性を見ているので、正系の方はVGWとフレッツVPNワイドのCPE、副系の方はVGWとインターネットのVPNルータで見ています。よって、BGPパケットの到達性に関して言うと、副系のインターネットVPNに関しては終端のルータ、つまり僕らが管理しているルータまでBGPが届くので、これが来なくなったら副系が切れてるなっていう判断がつきます。問題は正系のネットワークで、こちらのBGPのパケットって、その前段のサービス事業者のルータで終わっちゃうので、僕らのネットワークには到達しないんですね。つまり、ネットワークの障害検知に関して言うとちょっと変なことになっていて、副系はBGPで検知が可能、つまり僕らが管理してるインターネットVPNルータでBGPを受けてるのでBGPで検知可能なんですけど、正系のネットワークに関してはBGPのパケットが僕らが管理してるネットワークまで到達してこないので、何らかの手段でそれを検知する必要があります。

正系の障害検知はEC2にpingを打つしかない

で、どうしたかっていうと、基本的にはこうしました。

もともと僕らが見てるネットワークっていうのは、内部のルーティングはOSPFで制御してます。なので、AWS向けのルートに関しては正系と副系がそれぞれOSPFで広告をしていて、正系のルータのOSPFを優先するようにmetric値を設定しました。正系のルータのOSPFの広告が止まると、副系のOSPFのルートのみが残るので、自動的に副系に切り替わるよねっていうネットワークの構成になっています。

で、この正系ルータのOSPF広告をどうやって止めるのかっていうと、AWSのVPCのネットワークにpingを打つしかなかったです。しかもVGWはICMPに応答しなかったので、中で動いているEC2のインスタンスに対してpingを打ち続けていて、このping応答がなくなったら正系のネットワークに障害が発生したと判断をして正系ルータのOSPF広告を止めて副系に切り替える、っていう構成にしました。

たぶん世の中にはこんなことをやってる人たちがいっぱいいると思うんですけど、なんか検索してもスマートな方法が出てこなかったんですよ。なので、これ皆さんどうされてるんですかねっていう話をちょっとお聞きしたいとか議論したいなと思ってます。

発表のまとめ

ここらで今日の話をいったんまとめます。

• まずは拠点を繋ぐ話として、去年も発表したNGN折返の話をご紹介させていただきました。
• その次に、最近モバイルも広帯域で使えるよねって話をしたんですけど、一方で天気に左右されたりとか不安定な部分もあるよねっていう話をしました。
• その次にクラウドとかSaaSとどうやってうまく接続するんだっていう話題をさせていただいて、そこで1つの方法としては既設の広域イーサーやIP VPNサービスを使ったりとか、あとは既存の拠点がいっぱいあるので設定変更のコストがかかるようなお客さんの場合はこうしたらいいんじゃないですかねって話をさせていただきました。
• それからNGNの折り返しを使ってクラウドに接続をすると、特に北海道内とかだと有利とかいいことがあるよねって話をしました。
• さらにいっそ直接つなごうってことでダークファイバーを使った接続の話をさせていただきました。
• 最後にAWSとの接続の話をだいぶ細かくさせていただきました。

というわけで、ちょっといろいろと議論をしたいなと思っております。ということでいったん僕の発表はこれで終わります。どうも皆さんありがとうございます。

質疑応答

発表後、会場やオンラインで参加されている方々と質疑応答をしました。

質問者A：これ正系のフレッツVPNワイドのところがOSPFルータまでBGPで経路をもらっていて、副系のところもBGPでやってるって形なんですよね。間のところが接続されていないのでこういう構成になっているっていうことですかね？

小岩：この図でいくとですね、フレッツVPNワイドのCPEまではBGPでルーティングが来ています。その下に僕らの管理してるルータがいるんですけど、ここのルーティングは僕らの管理してるルータの方でスタティックルートを書く設定になってるんです。なので、NTT東日本のルータ(CPE)と僕らの管理してるルータの間はスタティックルートでルーティングを掛け合っていて、動的なルーティングプロトコルを一切使っていないので検知ができないんですよ。

質問者B：今回のJANOGで地域IXに関するセッションをやったんですけど、地域IXで目指してることってまさしくこういう世界かなと。すなわちローカルな折り返しをすることでいろんなクラウドになるべく遅延が少なく接続できるようにすると。それを一企業でここまでやっているっていうのはすごいなっていうのが正直な感想です。一方、ちょっと質問なんですけど、いろいろ調べてもなかなか情報が出てこないという話だったんですけど、例えばこういうのを横展開というか、他の企業に提供するようなことは考えられてますでしょうか。
(編集部注：地域IXに関するセッションは3つありました。「地方の拠点IXからの脱却 ～日本の西側にあるIXの魅力とは！～」「地域IX？それとも拠点IX？～地域ISPからみた福岡IXへの期待～」「続・IXの現状と新たなる展開　ー地域IXの展開と果たすべき役割ー」)

小岩：そうですね。ビットスターの立場でいくと、ビットスターはさくらインターネットグループではあるんですけれども、一方でAWSの導入とかAzureの導入とかいろいろやらせていただいてます。僕らはうちの会社をSIerだとは思ってないんですけど、一方でSIer的な動きもしているので、そういったお客様の困りごと、例えばクラウドへの接続が遅いんだよねとか何とかで困った場合に、こういったソリューションを僕らは提供できるので、そうすると低遅延で接続できますよみたいなビジネスはいっぱいやっていきたいなと思ってます。

質問者C：私も今、全国50拠点でフレッツVPNワイドと、もう1つ別のVPNも繋いで両系統に出すみたいなことをやらせていただいてます。非常になんかデジャヴ感というか、似たようなことを考える人もいるんだなと思いながら話を聞いてました。ただ、うちの構成が参考にならないのは、うちの場合は全国からUDPで送り付ける側なんですよね。完全2系統で送るんですけど、終点は完全にネットワークが分かれていてもいいっていうような感じなので、ちょっとうちのは参考にならないなと思いました。
ところでこの図面について質問なんですけど、この運用が面倒くさいんだったら、そのフレッツVPNワイド側を別のインターネット回線経由のインターネットVPNルータにしちゃえば運用楽になるんじゃね？と思ったんですけど、それって何か違うなっていう感じですか？

小岩：インターネットVPNを2本張るようなイメージですか？

質問者C：そうですそうです。

小岩：あー、それはですね、やっぱりDirect Connectを使って閉域網接続をして、ある程度帯域を稼ぎたかったっていうのがあるんですよ。なので、この構成はこれありきの話だったんですよ。これを受けて、ここが落ちることがあるからインターネットVPNを副系でやりましょうねというときに、ここの切り替えや障害の検知をどうするんだっていうのがすごい悩んだというか、試行錯誤をしたみたいな感じですね。

質問者C：なるほど。そうなると、正系をすぐにとっかえるって感じでもないですね。

小岩：そうですね。結局インターネットVPNを2本引いても、冗長性をどうするんだみたいな話がちょっと難しいっていう感じですね。あとですね、北海道、それもちょっと遠くの田舎になっちゃうとですね、回線の選択肢がないっていう状況もあるんですよ。

質問者C：ケーブルテレビも引けない感じですか？

小岩：はい。ケーブルテレビもなくて、下手するとNTT東日本一択みたいな感じの状況になってしまうんです。そうすると、ちょっと変な話をすると、副系のインターネットVPNも下手するとフレッツ光に乗っちゃうので、フレッツが落ちると全部落ちちゃうみたいなパターンもありえます。東京とかだと選択肢がいっぱいあるんだと思いますが、これは北海道特有の問題なのかわかんないんですけどだいぶ選択肢が限られてきちゃうので、結構四苦八苦しながらできるだけ落ちないように頑張ってるっていう感じですね。

質問者D：Direct Connectで帯域と費用を抑えたいって話であれば、例えばどこかの既存のデータセンターにDirect Connectで引いて、そのあとNGN折返で各拠点に持っていけば、フレッツVPNワイドと同等のことができるんじゃないかなと思うのですがどうでしょう？

小岩：ちょっと図が悪いんですけど、ほぼそれと同じことをやってます。ただここはどうしてもNTT東日本のサービスを使う必要性があってこれを引かなきゃいけないので、こういう感じになってるっていうことです。

質問者D：なるほど。それを使うことがもう決まっていて、他の逃げ道がなかったっていうことですね。

小岩：はいそうです。

発表を終えて

と、こんな感じで最近のネットワーク設計のデザインパターンみたいな話をさせていただきました。
オフィス需要やクラウドへの対応などでネットワーク設計も変化していますが、一方できちんと接続して耐障害性をあげるとなると、なかなかスマートには行かず地道で泥臭い作業が必要となります。
また、久しぶりのリアル登壇でした。オンラインとは違う良さがやっぱりあって、オンラインの良さも取り入れつつ早く良い議論ができる状況になるといいなと感じました。