JAWS-UG首都圏勉強会レポート 第10回

AWSとネットワークをディープに語る勉強会開催

キャリアを超えてネットワークを語り合うNW-JAWSが始動！

2016年10月28日、ソラコムに走った激震とその対応が語られる

　読者の中にはそろそろ忘れそうになっている人がいるかもしれないので、この辺りで喚起しておきたいが、これから4人目の発表を紹介するのはあくまでLT。それぞれ5分程度の持ち時間で語られた内容だ。しかしそろそろ読み疲れてきたのではないだろうか。Wordの文字カウンタには5200文字という数字が見える。それだけ、濃かったのだ。

　4人目のLTバッターは、ソラコムの松井 基勝さん。松井さんは、2016年10月28日に発生した.ioドメインの名前解決問題について、その経緯と対処について語った。いわゆる、トラブルシュート事例だ。

「10月28日、突然サービスが正常に動かなくなりました。それに気づいた社員たちがslackで騒ぎ始め、手を尽くして原因を探ったところ、.ioドメインのネームサーバが正常に動作していないことがわかりました」（松井さん）

ソラコム 松井 基勝さん

　TLDのネームサーバーは冗長化されているので、本来なら1台や2台がダウンしたところで名前解決に支障が出ることはないはずだ。しかしこのとき起きていたのは、さらに良くない事態だった。7台あるネームサーバーのうち2台が沈黙、別の1台は誤ったレスポンスを返す状態になっていたのだ。

A1、A2、Y1が沈黙、さらにA4に異常発生（問題発生時のイメージ映像）

「内部の名前解決にも外部DNSを使っていたので、サービス同士がうまくつながらない状況に陥っていました。それを回避するために急遽内部にDNSを用意し、.soracom.ioドメインについては内部のRoute53に問い合わせるよう設定を変更しました」（松井さん）

　しかし外部からのアクセスにはこの手法では対応できない。しかたがないのでsoracom.jpにsoracom.ioをミラーリングするようにして、顧客にはこちらのURLを案内した。その後、誤ったレスポンスを返していたDNSが沈黙したことで、いくつかの課題と教訓を残して事態は収拾。

「内部DNS用にパブリックホステッドゾーンを使用していたのは、設計上よくなかったと反省しました。しかし、一方でTLDサーバーが間違ったレスポンスを返すことに対応するのはどうやっても不可能なので、.ioよりももっと安定したドメインの方が安心感があるのかもしれないとも思いました。もうこのドメインでサービスを始めてしまったので変えられませんけど」（松井さん）

NGN網でIPv6の閉域接続ができるか実験中のテコラス岩淵さん

　5番バッターは、NHNテコラスの岩淵 昇さん。普段閉域接続やIP-VPN、広域イーサネットや専用線環境の構築を担当しており、閉域網には飽きてきているとのこと。そう言いつつ、LTの内容はNGN網で閉域接続ができるかどうか実験してみたというお話。

　「フレッツ・光ネクストはIPv6オプションが有効な状態で提供されているので、NGN網だけで折り返し通信ができちゃうんです。これができてしまうと既存の閉域網サービスは存続の危機なんですが、プレフィックスが変わる場合もありそのまま使える訳ではないことがわかりました」（岩淵さん）

NHNテコラス 岩淵 昇さん

　しかしほっとしたのもつかの間、SoftEther社から「OPEN IPv6 ダイナミックDNS for フレッツ・光ネクスト」が発表された。Dynamic DNSを使って対向拠点のプレフィックスを自動設定することでNGN網での直接通信が可能になったのだ。

　さらに、クラウドゲートウェイパッケージを使ってフレッツ網とAWSのダイレクトコネクトが可能になり、DNSの権限委譲もできるようになったため、SoftEther社のサービスと同様のことをRoute53を使ってできないかと実験することに。

「使ったのは、みんな大好きなヤマハのRTX1210です。Dynamic DNS的な機能を実装しているのでなんとかなるのではと思って色々がんばってみたのですが……LTまでには何の！成果も得られませんでしたああぁぁ！」（岩淵さん）

　この実験は今後も継続していくとのことなので、第2回以降の勉強会で進展が発表されることに期待したい。

スカイアーチの福島さんは「ネットワーク構成図もうやめよう」

　いよいよ最後となるLTに登壇したのは、スカイアーチネットワークスの福島 厚さん。スカイアーチネットワークスは事業内容を語るよりも、「サバ缶の会社」と言った方が読者には通りがいいだろう。この日もサバ缶を大量に持って来ており、筆者もひとついただいた。福島さんの悩みはサバ缶の味でも缶のデザインでもなく、AWSを使ってサービス設計しているときにネットワーク図が描けないということ。

「そもそもサービス同士が物理的にどうつながっているかを意識しないで済むのがクラウドのメリットのひとつ。仮想環境なので物理的なトポロジーとか物理的な接続とか関係ないと説明するのですが、古いシステム屋さんには通じません。『で、ネットワーク図は？』と問い詰められるので、しかたなくネットワーク図を描くことになります」（福島さん）

スカイアーチネットワークス 福島 厚さん

　ネットワーク図を描きづらい原因は大きく3つ。まず、物理トポロジーという概念がない。ルータやスイッチもない。さらに、IPアドレスが固定されていない。しかたがないので福島さんは構成図からトポロジーを妄想し、接続部にあるであろうスイッチを創造し、IPアドレスの代わりにサーバー名のエイリアスを書き込んでネットワーク図を描くのだそうだ。

「そもそも、もうネットワーク図で構成管理するのやめましょうよ」（福島さん）