インタビュー
大地震が起きるとインターネットに何が起きるのか？「東京集中のインターネット」での災害対策を考える
ping 20ミリ秒以上なら、それは東京経由かも？
2021年3月10日 07:50
日本は、どうしても自然災害と向き合わざるを得ない地理的条件を持っている。
最近、被害が多く出ているのは台風だが、東日本大震災のような大地震や火山噴火なども懸念事項だろう。
その可能性が「万が一」だとしても、「“RAID全滅”があり得るように、“クラウドなら絶対安全”もない」のと同じように、可能性があるものは発生してしまうし、事業の中でのITの重要性が増している以上、単に「壊れました」で済まない状況になりつつある。
そうした自然災害に対する、ITとしての対策は、他地域へのバックアップやレプリケーション（複製）によるデータやシステムの冗長化だ。
災害に備えたDR（ディザスタリカバリ、災害復旧）やBCP（事業継続計画）のために、たとえば関東と関西でデータやシステムを冗長化しておくことは、しばしば行われている。
しかし、「データやシステムを冗長化したあとは、ネットワークも考えなくてはならない」と語るのは、テラクラウド株式会社の代表取締役CEO兼CTOの瀧康史氏。
災害時にネットワークや通信回線で何が起き、平時からどう対策しておくべきかについて、瀧氏と、同社の執行役員で広域ネットワークなどを担当する千代佑氏に聞いてみた。
大地震が起きるとインターネットに何が起きるか？
「関西だから東京の災害は無関係」ではない……かも？
対策は「道」レベルの冗長化、立地や建屋の詳細検討
「回線」「立地」「人材」「プラン」の総合力が重要
大地震が起きるとインターネットに何が起きるか？
――前回は「クラウドだから絶対に安全、というわけではない」というお話をお伺いしましたが、今回は、災害についての話を伺います。
[瀧氏]はい、日本は地震大国です。そこに住んでいるからには、DRやBCPについてまじめに考えるのが宿命だと思っています。
テラクラウドの本社は静岡にあります。
静岡の人間は、幼少のころから、明日にでも大地震が起きるかもしれないと言われて育ってきました。そのため、関東の大震災や富士山噴火について、机上の空論ではなくて、リアリティを持って考えないといけないと思っています。
――関東が災害にあった場合に、企業や公共組織などが直接打撃を受けますが、そのほかにどのような影響があるのでしょうか。
[瀧氏]さまざまな通信インフラが、関東に集まっています。日本のインターネットの東側の中心は大手町ですし、東京近郊にはデータセンターが多数あり、いろいろなISPが相互接続しています。そのため、関東に大きな災害がおきると、日本のインターネットはかなりダメージを受けます。
[千代氏]実のところ、東京でしか接続ポイントを持っていないネットワーク事業者もけっこうありますし、海外キャリアも「日本＝東京」ということで、東京にしか接続していないところもそれなりに多い。東京が災害になると、ISPやデータセンターを利用する企業のサービスにも、かなりのインパクトがあるでしょう。
――具体的には、どうなるのでしょうか？
[瀧氏]そうですね。条件を考えて思考実験してみるといいと思います。
まず、「事前対策」として、関東のほかに関西でもクラウドやデータセンターを契約して、データはすべて転送/同期されており、関東の情シスのスタッフも無事、という条件にしてみましょう。自社でできる事前対策は、ある程度しっかりやっている、というイメージですね。
まず、関東のスタッフですが、最初に生命と生活の確保ができたとして、そのあとで仕事に戻ることになるでしょう。昨今は「ITインフラ＝会社のインフラ」なので、情報システム担当はそれを復元することが重要になります。
そこで気になるのが、「関東のデータセンターがどうなっているか」でしょう。これは、データセンターによって状況が異なると思います。
新しいデータセンターは、免震構造ですので、地震の大きな揺れでも内部は緩やかに動き、機器に影響はほぼ出ませんが、古いデータセンターはオフィスビルを単に耐震補強しているだけのケースもあり、地震で大きく揺れると内部の揺れもかなり大きくなります。これは、私自身、10年前の地震の際、都内で実際に経験しています。
とはいえ、耐震だろうと免震だろうと、データセンターの建物や機器、データはかなり安全だと思います。問題が出るのは、そこへの接続だと思います。
――データセンターが耐えられてもネットワークが耐えられないということでしょうか。
[千代氏]はい。
「インターネット」と言っても、結局、最終的には光ファイバーなどの物理的な回線です。データセンターは強固でも、津々浦々までひかれている光ファイバーがすべて同じ災害対策基準で作られているわけではありません。
さらに言うと、光ファイバーが通るルートは意外と選択肢が少なかったりします。「2回線引いているので大丈夫」と思っていたら両者が同じ土管を通っていたということも、しばしばあります。その場合、物理的な意味では「回線は冗長」とは言いにくいでしょう。
もちろん、ISPもデータセンターもクラウド事業者も、みな災害対策は考えていますが、たとえば、山のようにある断層を跨がないわけにはいきませんし、断層が大きくズレてしまったら、どんな対策をしても、切れるものは切れてしまうと思います。
「点の災害」「線の災害」「面の災害」
[瀧氏]災害には、点の災害と、線の災害、面の災害があると私は考えています。
「点の災害」は、地震によって特定の1箇所が陥没したとか、工事で道を掘って間違って線を切ってしまったとかいった場合で、そこを通っている光ファイバーが切れてしまいます。この場合は、同じ土管を通らないように注意していれば、対策できると思います。
こうした「点の災害」であれば、日本の事業者は、がんばって直すと思います。実際、一箇所で切れた大量の光ファイバーをがんばって一晩で融着させる、みたいなことは時々聞きます。
しかし、地震のときには「線の災害」が起きます。つまり、断層です。
データセンターは断層の上に建てないと思いますが、後から断層が見つかったとか、さまざまな事情でそうなっている可能性もあります。また、断層は点ではなく線なので、回線が2経路あっても、両方とも切れてしまうことがあります。日本列島は、「東西を繋ごうとすると、かならず断層を横切る必要がある」といっても過言ではないですし、どこの断層が動くかはその時の地震の状況次第です。こうした「線の災害」は、問題の特定にも時間がかかりがちですし、おそらく長期の接続断になるだろうと思います。
最後が「面の災害」で、地域全体の災害です。
大地震が起きた場合には、そのエリアは通信設備や電源設備が使えなくなりますし、富士山が噴火した場合には、関東にそうとうな量の火山灰が降るといわれています。火山灰は導電性なので、メートル単位で降ってくるとなると、電源網が壊滅的なダメージを受けてしまいます。電源がだめになると、中継施設などもだめになるので、回線はまともに動かないことが考えられます。
こうした「線の災害」「面の災害」では、数週間から数ヶ月、そのエリアの通信網が切れてしまうということも覚悟する必要があります。
――起こりうる範囲として、どのくらいを想定しておいた方がいいでしょうか。
[瀧氏]東京で面の災害があった場合は、東京リージョンのデータセンターやクラウドは、ネットワーク的に孤立するとみたほうがいいでしょう。
すると、インターネットからデータを取りにいくことはできませんし、復旧するまでには、かなりの時間が掛かると考えた⽅が良いでしょう。
いかにデータがそこに残っていようと、ビジネスの現場においてデータにアクセスできない時間が2週間を過ぎると、無くなったものみなして、仕事のやり直しをしはじめる人がでてくると言われています。
いずれにしても、インターネットがつながるという前提に立たず、データセンターが残っても孤立するものと考えておく必要があります。
「関西だから東京の災害は無関係」ではない……かも？「関西to関西」の接続が東京経由になる理由
――なかなか大変な状況になりますね。利用側はどう考えておくのがいいでしょうか。
[瀧氏]データセンターの利用者としては、関西など別地域にデータを複製しておくことが、極めて重要です。そのうえで、複製したデータやシステムをどう生かすかが次のテーマになると思います。
まず必要なのが、関東側の情シスの人が、関⻄側の⼈に「⾃分が無事であること」と「関西側のシステムをアクティブにしてほしいこと」を伝えることでしょう。
災害直後、関東側のネットワークは、複数の回線を使っていてもつながらないでしょうから、携帯電話がいちばん頼りになるでしょう。とはいえ通話は厳しいでしょうから、SMSなどで連絡をとるのがよいかと思っています。ただ、それでも繋がるかどうかはなんとも言えませんが。
[千代氏]補足すると、携帯キャリアは、全国にアンテナをつなげる都合上、基幹回線が全国に散らばっていることが多いんですね。
それに対して一般的なISPの収容設備は、よくて県に1つ。東京と大阪で全国をカバーするという設計も見られます。そうなると災害時、接続がかなりきびしくなりますから、携帯キャリアのほうがまだ復旧が早いだろう………と想定しています。
――関西のシステムがアクティブになったら、次はサービスの利用者がそこにアクセスする番です。
[瀧氏]そうですね。その時は、サービス利用者のISPと関西のデータセンターとの間が、どう接続されているかが肝になります。
実は、関西のISPどうしが相互接続されている箇所は関東ほど多くはありません。具体的には、堂島とその近辺の数カ所ぐらいです。そのため、「関西どうしで接続するのにも、関東を経由している」ということがよくあります。
[千代氏]これは、日本のインターネットが東京を中心に構築されてきた影響でもあります。結果として、「関西からアクセスしても、東京でインターネットに接続する」というISPもけっこうあります。結果、「東京の回線が切れると、関西どうしでもアクセスできない」ということが発生します。これは、接続にかかわるコストの問題もあったりします。
ping 20ミリ秒以上なら、東京経由かも？
[瀧氏]また、インターネットの経路は、データを送る側のポリシーが優先されるので、「関西to関西」のルートがあって、データセンター側でそれを使う経路を指定していたとしても、ユーザー側のISPが関東を経由する経路になっていると、（ユーザー側のデータがデータセンターに届かず）有事の際にうまくつながらない、ということがあります。
ユーザーが平時から、関西どうしでつながっているかどうか調べるには、OSに入っているtraceroute（Windowsではtracert）やpingなどのネットワーク調査のコマンドを使うとよいでしょう。
関西と関東を往復すると、応答時間が10ミリ秒ぐらいかかります。だから、自宅から関西のサーバーにpingをかけときに、たとえば20ミリ秒ぐらいかかっているなら、関東をまわっているのではないかと推察できます。
[千代氏]とはいえ、ISPの設計はまちまちなので、ふだんは関東で接続していて、異常時にだけ関西で接続するという設定もありえます。ISPもビジネスなので、東京と大阪でまったく同じ規模の設備を構築するのは厳しいということで、コンテンツなどの量は東京が圧倒的に多いので東京をメインにしておいて、非常時に大阪でも接続できる設備を作っておく、というパターンですね。
[瀧氏]それは外から判別できないので、回線業者に聞くしかない。個人向け回線では教えてくれないと思いますが、ビジネス回線なら「どこどこのISP、データセンターと関西で折り返ししますか」と聞いたら教えてくれる場合もあると思います。
[千代氏]ちなみにISPによっては、「NetflixやYouTubeなどだけは、CDN経由で関西で折り返しているのだろう」と思われる接続もあります。その場合、関西で折り返すのはそうした巨大コンテンツだけという場合もあるので、必ず対象のデータセンターとの間でチェックしてみるのがよいでしょう。
[瀧氏]インターネットの経路制御は、近いほうに送るのではなく、安いほうに送ることが多いですから。これは全くの余談ですが、シンガポールのとあるホテルで日本に繋ごうとしたら、アメリカの西海岸を経由したことがありました。
もちろんものすごく遅くなるのですが、きっと現地のそのISPにとっては、日本に直接おくるよりも、アメリカの西海岸に送った方が安かったからでしょうね。そうしたことはユーザーにはわからないですからね。
[千代氏]オペレーションエンジニアの内輪話で共有されるぐらいですね。
対策は「道」のレベルでの回線冗長化、そして立地や建屋の詳細検討
――そうした問題について、プライベートクラウドやクラウドストレージのサービスを提供しているテラクラウドとしてはどう対策しているのでしょうか。
[瀧氏]INTERNET Watchの読者のみなさんは、コンシューマー向けに展開しているクラウドストレージのTeraCLOUDの印象が強いかも知れませんが、我々のサービスは実はビジネスユーザー向けのプライベートクラウドの方がトラフィック利用が多く、速度やレイテンシ(反応速度)を重視するお客様も多くいらっしゃいます。
ですから西のユーザーにはなるべく西で、東のユーザーにはなるべく東で接続しようとしているのですが、ISPどうしの接続は送り側が決めるので、「我々が西からデータを送っても、返事が東から返ってくる」ということもあります。
また、クラウドストレージのTeraCLOUDはISPからすれば少し変わったサービスで、データを配信するより受信する方が多いサービスです。CDNを使うのも向きませんし、利用者からテラクラウドのデータセンターへのデータ送信量が圧倒的に多くなります。利用者側ISPの経路設定でデータが送られてしまうので、ほとんど我々の方ではコントロールできないのです。
[千代氏]「もっと効率のいいルートがあるのに」と思うこともありますが、送る側の設定次第なので、個別にチューニングはしているものの、どうしても遠いほうから入ってきてしまう。
[瀧氏]我々としては、なるべく西側のものは西側でつなげたいと思っているので、ISPから希望があれば、西側の接続ポイントで相互接続をするようにしています。そうすることでコスト削減になりますし、お互いに災害にも強くなりますので。
――テラクラウドのデータセンターでの対策はいかがでしょうか。
[瀧氏]我々は、関東、中部、関西にリージョンを持っていて、これらは相互に接続されています。そして、このリージョン間のネットワークにも気を配っています。
私は大地震がずっと心配されてきた静岡の人間なので、いろいろな地方で地震が起きるたびに、それを注意深く見て学び、「我々の時」にそのノウハウを生かそうと毎回、対策を見直してきました。
そのひとつとして、中部、関東、関西の間で、「道路」のレベルでの冗長化を意識して回線を選んでいます。道路のレベルというのは、たとえば「東海道」と「中央道」といったレベルのことで、同じ道路は通らないような冗長化をしています。冗長線を持っていても、同じエリアですべて水没してしまうと終わりなので。
こういった回線を生かしたクラウドサービスも用意しています。
たとえばプライベートクラウドサービスでは、関東リージョンに置いたデータや仮想マシンインスタンスを、RPO（Recovery Point Objective、目標復旧時点）1時間ほどで、定期的に遅延同期で転送するDRの仕組みもサービスしています。時々、我々がRPO 1時間で同期するというのが驚異的と言われることがあるのですが、それは物理的な回線を選んできているからできることで、インターネット前提ではできないことです。これらのインフラを使うことで、比較的容易にDRをご用意できるため、お客様には好評を頂いております。
災害対策という視点でいうと、実は社内に「データセンター選定委員会」を設けていまして、独自の基準に適合しないところは、原則として利用しないことにしています。
たとえば、「海岸から5km以上離れていること」とか、「電源やサーバーの設備が海抜25mを超えていること」とか。クラウドストレージのTeraCLOUDではハードディスクをよく使うので、免震設計のデータセンターでしかサービスしない、などの基準もあります。もっともデータセンターは突き詰めると不動産で、「このエリアにはこういうデータセンターしかない」ということもあります。そうなると選択肢がないので、例外は出てきてしまいますが。
検討の際は、その地域の防災情報や、入手できる場合は建屋の設計情報なども考慮して選定していますので、ユーザー企業さんが個別に検討されるよりは精度の高い検討ができているのではないでしょうか。
大規模災害時は「回線」「立地」「人材」「プラン」の総合力が重要に
――では、クラウドやデータセンターの利用者は、どう備えたら良いでしょうか。
[千代氏]まず、今回のテーマである「回線」ですが、ISP同士がどのように接続しているかを意識しておくとよいと思います。個人向け回線では難しいでしょうが、ビジネス回線なら開示できる範囲で設備構成などを教えてくれるところもありますし、それをアピールポイントとして教えてくれるところもあります。
また、回線冗長をとるにしても、「キャリアが違うから大丈夫」という安易な考え方はやめたほうがいいと思います。
クラウドへの接続に関していえば、閉域網を使った接続サービスを利用するのもアリでしょう。インターネット経由のアクセスに比べると、自分で経路を把握できる部分もあり、不確定な要因をわりと排除できるので。そういうサービスを使ってクラウドへのアクセスを担保するというのも一つの手かと思います。
[瀧氏]オンプレミスでデータセンターを契約するときの選定については、データセンターそのもののスペックをちゃんと見ておくべきだと思います。「耐震」なのか「免震」なのかはもちろん、浸水しやすい場所かどうかとか。よく見ると氾濫しそうな河川が近くにあることもあります。
[千代氏]データセンターが河川や海の近くになってしまうのは、主に「そうした場所しかない地域だから」なのですが、最近は、そうした場所であっても、非常用発電機を2階以上に設置するデータセンターが増えてきました。
発電機は重量物ですし、燃料タンクも地下に置くことが多いので、これまでは一階や地下が多かったのですが、そういうところも見ておくとよいと思います。
[瀧氏]最後に、重要なのは人材ですね。
「大阪の人材だけでどれぐらいの対応ができるのか」について、事前に社内でコンセンサスをとっておくのも重要かと思います。
そして、人が実際にどう動いて業務を復帰させるかまで考え、リカバリプランを想定しておくとよいと思います。
――ありがとうございました。
（協力：テラクラウド）