JANOG45 Meeting in Sapporo に参加してきた（前編）
JANOGとは
JANOGとは、JApan Network Operators' Groupを意味し、インターネットに於ける技術的事項、および、それにまつわるオペレーションに関する事項を議論、検討、紹介することにより日本のインターネット技術者、および、利用者に貢献することを目的としたグループ。
JANOG設立構想は、1997年2月にSan Francisco で開催された NANOG9(ナノグ,North America Network Operators' Group)の最終日、会場でもあった Grand Hyatt Hotelの最上階のバーで、参加していた日本の運用者を中心に「日本語でネットワークの運用技術を議論できるミーティングをやろう！」という意思の基に結成された。JANOGのこれまでは、"wiki風JANOG史"としてドキュメントに公開されている。
JANOG45 Meeting in Sapporo
今回は札幌開催。真冬の時期の札幌なので、大雪になったりしないだろうかと心配していたけど記録的な暖冬ということで困るようなこともなく無事に開催された。3日間開催されるけど、私は仕事の都合で2日目の昼から3日目の昼までの参加。数日前に降って、ようやく雪が積もったそうだ。会場の周辺は以下の写真のような様子。日中は溶けているけど、朝晩は凍ってすべりやすい。でも、気をつければ大丈夫なレベルだった。
地元のお店の人の話によると、この時期にここまで雪が少ないのは40年ぶりぐらい、とのこと。街の人は喜んでいる人も多いかもしれないけど、農業にも影響があるかもしれないし、雪まつりで雪を集めるのも多額な費用がかかっているし、除雪に関連する仕事をしている人は収入が下がってしまうかもしれないし、やっぱり冬の北海道は雪が降ったほうがいい、と話をされていた。
JANOGerとクラウドのワクワクする関係
テーマも内容もとてもよかった。このセッションを自分なりに要約すると、以下。
・ネットワーク図をこう変えた
エクイニクス・ジャパンの丸野さんは、以前はオンプレの仕事をしていて、今はパブリッククラウドの仕事をされている。
パブリッククラウド（AWS）＋物理基盤の仕事が多いが、ネットワーク図がわかりづらい、という話。
オンプレ時代とのギャップが激しすぎて、対ネットワークエンジニアでも説明がつらい。お客様への説明は尚更難しい。なので、やったことは以下の3つ。
(1) route-table：
ひと目でわかりやすいようなアイコンを追加し、到達性に合わせて線をつなげるルールに変更。また、経路が把握できればいいのでルーターアイコンは削除。
(2) Subnet：
オンプレで用いられる論理構成の書き方になるだけ近づけるべく横線に変更。
(3) Subnetから伸びる矢印：
instanceのoutbound通信は、そのinstanceのsubnetが紐づくroute-tableに流れる（AWSの仕様）。その意味を表現するために矢印を追加。逆に下りはどのroute tableからでも到達できるので要素として書かない、片方向矢印にしてるのもそのため。
その結果、公式ドキュメントの表現でもネットワーク図が読みやすくなったそうだ。
・クラウドによってネットワークエンジニアはいらなくなるのか
ネットワークエンジニアはいらなくなる？という話はけっこう出てくる。正直最初は「これからの知識なんかなくてもインフラが作れるような時代になるのか」と思っていたそうだ。全然そんなことなかった。思っていたよりネットワークの知識がいる。
本質はあまり変わらなくて、よく見てみると「抽象化はされているが、使っている技術は変わらない」「抽象化されることにより本質の理解が必要」よりよい対応をするためにはパケットの気持ちになることは必要。クラウドになっても引き続きネットワークエンジニアは必要。
ただ、クラウドはまったく新しい価値観の世界で、今までと比べて半分以上の業務は変わった。コード化は必要になるので、新しいスキルを獲得しないといけない。
＜ディスカッションでの話＞
ネットワーク屋とアプリ屋が近づくといいよね、という話だと思うが、物理のところまでやっている人もいて、そこまでいける人はいない。どこまでオーバーラップできるといいのか。
低レイヤーについて詳しいネットワークエンジニアも少ない。上のレイヤーをしている人が、下のレイヤーまで出来る人も少ない。生粋のネットワークエンジニアはクラウドに抵抗がある人も多い。
できる人と一緒に手を動かしてみるといいと思う。開発言語の資格をとってみるのも、いいと思う。
・信頼性について考える
“Everything fails, all the time”
- Werner Vogels (CTO, Amazon.com)
すべてのものはいつでも壊れうる。
アメリカ：工事中の事故で光ファイバー切断
ブラジル：ゴミ捨て場火災で光ファイバー切断
実際にこんなことが起こったが、AWSではインパクトがないようなシステムになっていた。
・Design For Failure
絶対に落ちないシステムはないので、がむしゃらに網の信頼性を上げるよりは、システム全体の信頼性をあげてみる。アーキテクチャ試行の回数を増やすために自動化を取り入れるのがよい。
詳しくはホワイトペーパー「AWSを用いた耐障害性の高いアプリケーションの構築 」に書いてある。
・クラウドを使った自動化と信頼性
Netflixの事例。8分間のマルチリージョンフェイルオーバー。
カオスエンジニアリングによる意図的なリージョン障害を発生させている。本番系で絶えず起こしているのがNetflix。
カオスエンジニアリングはクックパッドも「Chaos Engineering やっていく宣言」をしている。クックパッドについてはセッション内で詳しく触れられたわけではないが、以下のログミーの記事『クックパッドが「カオスエンジニアリング」を始めた理由』がわかりやすい。
弊社もブースに出展しました
ネットワークの運用自動化・トレーニングサービスと、日本リージョン初のCPSP認定を取得したエーピーコミュニケーションズの強みの一つである”ネットワークセキュリティSI”に関するプロダクトを出展。
展示したプロダクトとサービスはこちら。
ご興味がありましたら、上記のページよりお問い合わせください！
この記事が気に入ったらサポートをしてみませんか？