IPv6, 勉強会, 雑感

1年ほど前、イケてないIPv6とどう付き合うか、という社内勉強会で、

  • レイヤを交換するとプログラムの挙動が変わるのはイケてない
  • IPv6は難しすぎてイケてない
  • 今すぐ対応する必要はないけど必要になったときのために勉強しときましょう

というような話をしたのですが、状況が変わってきたので、またIPv6の社内勉強会をやりました。

最近の状況をざっくり言うと以下のような感じでしょうか。

  • AppleがNAT64/DNS64環境でアプリを動作させることを要求してきた。
  • Google、Facebook、Apple等のハイパージャイアントがIPv6を強力に推進してきている。
  • IPv6を使ったインターネットの方向性についても共通見解が見えてきた。

IPv6は沢山の人の思い、時間、お金を費して、どんどんカオスになっていた感があるのですが、ハイパージャイアントという潤沢な資金力によって整理されようとしている、という現状はなんだか面白いなあ、とは思います。

コンテンツ事業者としては、その流れを見極めつつ、進む方向を考えなければいけないと思っています。

参考資料

スライド中のURLを書き出しておきます↓

DMM.comラボからの発信

ツチノコブログ イケてないIPv6とどう付き合うか
http://tsuchinoko.dmmlabs.com/?p=1662
IPv6について喋って、と無茶振りされた社内勉強会の資料とブログ。
エンジン形式、ジャニーズ、将棋棋士等の教養要素も加味。
レイヤを交換するだけでプログラムの挙動が変わるのは仕様がイケてないよと言ってみた。

JANOG35 Meeting – なぜ、IPv6 対応したくないのか
https://www.janog.gr.jp/meeting/janog35/program/ipv6/
上のブログを馬渡さんに補足されてJANOG35で喋った時の資料。
IPv6に関わった人々の前で、やりたくない、って言うのはかなりドキドキした。

Appleの動向

iOS Developer Library
Supporting IPv6 DNS64/NAT64 Networks
https://developer.apple.com/library/prerelease/ios/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html
Appleによる iOS の IPv6 DNS64/NAT64 に関する説明資料。
環境の簡単な作り方についての説明もある。

海外の状況

諸外国におけるIPv6対応の状況
http://www.soumu.go.jp/main_content/000368565.pdf
総務省の資料。
これを見ると徐々にIPv6対応が進んでいるのがわかる。
原状はまだ比率としては多くないが、今後も増えていくのは見えてきた。
Google、Facebook、等のハイパージャイアントが積極的にIPv6対応を進めている。

GoogleによるIPv6の統計情報
https://www.google.com/intl/ja/ipv6/statistics.html
これを見ても原状はまだ比率としては多くないが、今後も増えていくのは見えてきた感じ。

AkamaiによるIPv6の統計情報
https://www.stateoftheinternet.com/trends-visualizations-ipv6-adoption-ipv4-exhaustion-global-heat-map-network-country-growth-data.html#countries
すごく対応している国もあれば、まったく対応してない国もあるのがわかる。

総務省からの勧告関連

IPv6によるインターネット利用高度化に関する研究会第29会会合議事概要(案) 2015/9/28
http://www.soumu.go.jp/main_content/000385661.pdf
IPv6を推進したい立場の人と、コストやセキュリティのことを考慮して推進に消極的な事業者とのやりとりが厳しくせつなくて泣けてきます。
みんなそれぞれ立場があって真摯にやってるのはとてもわかる。。。。

「全スマホでIPv6接続を」 総務省が携帯3社にアドレス新企画への対応要請 2015/11/10
http://www.sankei.com/economy/news/151111/ecn1511110004-n1.html
上記の会合が決裂のような状況になったので総務省が強行手段に出た?

IETFでの標準化の動き

IETF93報告会 IPv6関連WG
https://www.isoc.jp/wiki.cgi?action=ATTACH&file=20150827_IETF93_update_05_nishizuka.pdf&page=IETF93Update
IETF94 IPv6関連ホットトピック
https://www.isoc.jp/wiki.cgi?page=PreIETF94&action=ATTACH&file=ietf94study_03_hottopic_nishizuka.pdf
西塚さんによるまとめ資料。
IETFでの標準化が混乱しつつ、まとまりつつある様子が良くわかる。
「IPv4 as a Service」が提案された。

宅内端末状況

IPv6移行の現状 – 宅内端末から見たIPv6とIPv4 –
http://www.slideshare.net/akiranakagawa3/2015-summer-seminar
JPNEの中川さんによる資料。2015年夏時点の状況がまとまっている。

CEDEC-Net 2015 での IPv6 環境の話

CEDEC-Net 2015 で IPv6 の会場ネットワークを提供してきました
http://yuyarin.hatenablog.com/entry/2015/08/31/011205

CEDEC-Net 2015 テクニカルレビュー
http://www.slideshare.net/yuyarin/cedecnet-2015
「動作しないアプリ → 艦これ」と名指しされてしまったよ。

DMMについての情報、その他

[イベント]「やまもといちろう、あの『ウワサ』のDMM会長・亀山敬司に直撃!」というイベントに参加してきた
http://itevangelist.net/blog/yamamotoichirou-dmm-kameyamakeishi-event/
DMMがどんな会社かが良くわかる面白イベント記事。
中の人が読んでも面白かった。

【堀江×亀山】ファーストペンギンは血まみれになる
https://newspicks.com/news/1256434?ref=user_9250
有料記事だけどわりと面白かった記事。
スライド中のファーストペンギンという単語はこの記事から引用。

【DMM亀山敬司講演@船井総研】第1回:「衰退業界での生き残りかたとは?」
http://dailynewsonline.jp/article/1045440/
DMMの事業に対する考え方が汲み取れる記事。
言いすぎて、会場をどん引きさせちゃったらしい。
そのうちアフリカ出張とかもありそうだよなあ。アフリカは何が美味いんだろ。

たかがレシピサイトに何故こんなに技術力が必要なのか?
http://techlife.cookpad.com/entry/2015/11/27/194316
「技術がなければ価値なんか届けられない」という、良い言葉が書いてある。

ツール, 運用管理

最近ギックリ腰(筋膜炎)で腰の大切さ、ありがたさを実感したトウマツです。こんにちは。
今回は、便利ツールを見つけましたので、みなさまに紹介したいと思います。

DMM.comラボは、DMM.comのサービスを快適にご利用いただくために、毎日のようにサーバを増設しています。

このサーバ増設には、サーバに対してIPアドレス等の初期設定をする為に、キーボード、ディスプレイ、マウスの3点セットが必要となる場合があります。
しかし、これらは大きく、重く、そしてかさばるので持ち運びに適さず、ギックリ腰の僕には苦行です。また、ディスプレイは電源を必要とするため200V供給のみのラックでは電源の確保も一苦労なのです。

というわけで、そんな悩みを解決してくれそうなツールを探してみたところ、良さげなツールを発見したので実際にどんな使い方が出来るのかを試してみました。

ノートパソコン接続KVMコンソール
http://www.startech.com/jp/Server-Management/KVM-Switches/USB-Crash-Cart-Adapter~NOTECONS02

CrashCartAdapter単体

 

実際にMacBook Pro‎とノートパソコン接続KVMコンソールを接続し、サーバをセットアップしてみるの図

CrashCartAdapter全体

 

このノートパソコン接続KVMコンソールをノートパソコンに接続して専用アプリケーションを起動すると、ノートパソコンのキーボードとマウスの入力信号をサーバにそのまま転送し、サーバから出力されるビデオ出力をノートパソコンの画面上に表示します。
つまり、従来サーバの初期設定に必要であったキーボード、ディスプレイ、マウスは不要となり、ノートパソコン1台とこのノートパソコン接続KVMコンソールのみ持っていけば済むのです。

ノートパソコン接続KVMコンソールの専用アプリケーションは、Mac OS XやWindowsにはもちろん、Linuxにも対応しています。また操作画面の録画機能を搭載していたり、USB CD-ROMに見せかけてISOイメージを読み込ませたりできるなど、「現場」で必要な機能が詰まっており、DMM.comラボのサーバデータセンタチームでも評判のツールの一つです。

というわけで、今後も面白そう、便利そうなツールをどんどん紹介していきますのでよろしくお願いします。

 

※こちらから購入しました@2015/12/02時点 $323.99
KVM Console to USB 2.0 Portable Laptop Crash Cart Adapter
(もちろんアフェリエイトではありません)

wifi, ネットワーク, 勉強会, 運用管理

11/17〜19に行われた Internet Week 2015 にて「失敗から学ぶWi-Fi構築」というテーマで講演させていただきました。Wi-Fi で陥りがちなアンチパターンと、それがなぜ失敗してしまうのか、どうしたら改善できるのかというテーマのプログラムでした。

無線LANに限らず、トラブルシューティングでは「なんか変だぞ?」という直感が、理屈よりも先に働くことがあるかと思います。これは経験や、どういう仕組みで動いているかを知ることによって、なんとなく変だなという直感として意識に上がってくるようになるのではないかと思っています。

電波は見えないし聞こえないけど、それがどういったものかをなんとなく知ることで、無線独特の特性、電波の飛び方や干渉の起こり方をなんとなくでも想像できるようになればと思い、このプログラムでお話しました。資料はのちほど Internet Week 2015 のページに掲載される予定です。

オフィス街と郊外を測定しながら走ってみた動画

プログラムの最後に紹介しました車載動画です。都内繁華街で電波が非常に混み合っているエリアから、電波がクリーンなお台場まで、簡易測定器を積んだ車で移動しながら撮影してみました。

測定器には metageek Wi-Spy を利用しました。この測定器は つながらない無線LAN!?(2/3) 調査編 で紹介したものです。

waterfall_wifi
この画面(Chanalyzer4)は、左右が周波数 (無線LANのチャネル表示)です。上下に分かれていますが、上は現在の電波強度、下はその履歴です(記録したものがだんだん下に動いていくのでウォーターフォールグラフなどとも呼びます)。

このケースでは 1, 6, 11 ch でいわゆる Wi-Fi が利用されているように見えます。それぞれのチャネルの真ん中が凹んでいますが、これが IEEE802.11a/g の特徴です。

Wi-Fi で利用されている変調方式 OFDM は、ひとつの通信を複数のサブキャリアと呼ばれる電波に分割して伝送します。802.11g (20MHz幅) であれば52本のサブキャリアに分割し、ひとつの通信となっています。この真ん中の部分は実装上の都合で通信に利用するのが難しいため、使われていません。このため、中心に凹みが観察されます。

秋葉原から出発し、お台場の暁埠頭まで移動しました。これは2.4GHz帯を観測しています。

  • 無線LANではないと思われる電波がかなり多い(意外)
  • 無線LANだけを拾うアプリ(inSSIDer, WiFi Analyzer等のアプリ)だけでは状況を正しく判断できそうにない
  • 繁華街ではほんの少し移動しただけで状況が大きく変わり、この辺はこういう状況である、等といったことは言いにくい

waterfall2

移動した約50分間のウォーターフォールを一枚に圧縮してみました。繁華街を離れ、海に近づくに従って電波の密度が下がっていき、バンド全体がクリーンになっていくのがわかると思います。

とはいえ、海の倉庫街(特に税関のある辺り)から広域にわたって何だかわからない電波が出ていたりもしましたので、やはり実際に測定してみないとわからない、かつ、この瞬間ではこういう電波状況だったが今後どうなるかもわかりません。突然トラブったりすることもあり得ます。

今度、電波がクリーンそうな熊野に行ってきたいと思います(フレッツが来ていない限界集落)。測定したら面白そうな場所があったらぜひ教えてください! 

iDC, ネットワーク

こんにちわ。また大分があいてしまったぜという感じの酔っ払い系ツチノコです。

 

今回は JANOG US Regional Meeting というところでお話をしてきました。JANOG は JApan Network Operators’ Group っていうくらいで基本的に日本でやってるんですが、今回は NTT America さんのオフィスをお借りして、San Jose です。人数も会議室でやってたくらいでいつもの JANOG と違って目線が同じでプレゼンの最中にも質問が飛び交って議論がいつも以上に盛り上がる感じ。こういうのもいいですねー。

私がしゃべった資料はこちら。

 

コンテンツ屋として考える現在のデータセンタインフラ、ネットワークとこれからはこんな感じにしたいなー、っていうお話でした。Chaos Monkey 動かしても大丈夫なアプリ+インフラってやりたいとおもってもなかなか越えなくちゃいけないハードルは高いんですけどね。でもやりたい。

 

私の発表以外の当日のプログラムと資料はこちらから辿れます。

https://www.janog.gr.jp/meeting/regional-us-1/

 

尚、当日の動画は youtube で公開されています。動画は2015年11月末迄の公開だそうなので、まだ見てない方々はお早めに。最初の住本さんの海底ケーブル話は特にオススメ。資料無しストリーミング有りですし。

Erlang, 小ネタ

はじめに

 初めまして。新人ツチノコの大山裕泰です。私もツチノコの一人ですが、比較的容易に発見できる部類のツチノコだと思います。勉強会等で見つけてくださった際には、是非お声掛けください。
 最近 Erlang を触り始め、ちょうど良いネタが見つかったので書いてみました。

 余談ですが、最近の Erlang の人気の高まりは Riak などが注目されているためだと思いますが、Erlang エンジニアの人口が少ない ためか、Erlang について扱った記事やブログなどはあまり多くありません。
 とかく今回取り上げる prim_inet モジュールは、Erlang の標準ライブラリに組み込まれていながら、本稿執筆時点での ユーザガイド にも リファレンスマニュアル にも載っていない隠し機能としか言いようがないにも関わらず、RabbitMQ とかではフツーに使われていたりします。
 そんなわけで今回は prim_inet モジュールの一部機能の使い方について、簡単なサンプルと共に紹介したいと思います。Erlang を知らない人でも何となく理解してもらえるように頑張ってみました。

Erlang ってどんな言語?

 Erlang は超並列なシステムをプログラムするのに適しており、全てのプロセス間において共有メモリを無くすことで安全な並列性を実現しています。また、言語システム自体に分散システムをサポートする機能を提供しており、システム全体で数千から数十万単位のプロセスによる超並列・分散システムを構築する用途で広く利用されています。
 そして Erlang の最も象徴的な特徴は、OTP (Open Telecom Platform) と呼ばれるプロセスの汎用的な挙動を規定したテンプレートにあります。

 他の言語の例で言い換えると、Erlang 言語自体が Ruby で、OTP が Rails といった感じです。ただ OTP のスキームは Rails よりも遥かに厳格です。Erlang と OTP のようなプロセスの挙動をガチガチに規定した仕組みを用いる事で、ある意味簡単に超並列で堅牢な分散システムを構築できるようになります。

本題

 prim_inet は ERTS (Erlang Run-Time System Application) に組み込まれているライブラリの一つで、TCP, UDP, SCTP プロトコル通信に関する様々な機能を提供しています。ERTS とは Erlang のランタイムシステムの実行において必須機能を提供する Kernel アプリケーション と、OTP 機能をはじめとする 標準ライブラリ から構成されるアプリケーション群です。
 
 今回は、簡単な Echo Server の実装を通して prim_inet モジュールによるノンブロッキング通信システムの実装方法について見て行きます。Echo Server とは RFC862 で規定されており、クライアントからの接続後に送られたデータを、そのクライアントに対して送るサーバになります。
 今回実装するサーバのプロセスモデルを以下に示します。サーバ側では一つの “Server” プロセスを生成し、ユーザ側からの TCP 接続毎に Echo Serverの実装である “Worker” プロセスを生成し、以降のデータ通信は “Worker” で行います。

 prim_inet での実装について見る前に、一般的に TCP 通信を行う際に利用する gen_tcp モジュール を利用した場合の実装について見て行きます。
 gen_tcp, prim_inet それぞれを利用して実装した Echo Serverを以下に用意しました。

 https://github.com/userlocalhost2000/echo-server

 まずは gen_tcp 側の実装 “generic_server” を見て行きます。ビルド方法、及び使い方はリポジトリの README を参照してください。
 generic_server では、OTP によるクライアント・サーバモデルのプロセスを一つ起動させる。プロセスの起動後、以下に示す init 関数が呼ばれます。

 ここではクライアントからの TCP の接続を待ち受ける wait_connect/2 関数を呼び出します。この短い関数内に Erlang の幾つかの特徴的な処理が詰め込まれています。
 まず関数の評価に対して、パターンマッチ と呼ばれる仕組みが利用されます。この仕組みでは、関数の呼び出しに対して、呼び出し時に指定された実引数と、定義された関数の仮引数の数、及び各仮引数の型・値の比較を行い、これにマッチした関数の評価を行います。なので、同名の関数でも引数の数が異なる別関数が存在することがあるため、関数名の表記には仮引数の数を表す数字を末尾につけ wait_connect/2 のように表現します。
 パターンマッチは関数評価以外にもあらゆる場面で利用されるとても強力な仕組みです(wait_connect の一行目でもこれを利用し、返礼値のチェックとエラーハンドリングを同時に行っています)。言語機能としてパターンマッチをサポートしている言語に Scala などがあります。
 wait_connect 関数では、クライアントからの接続が来た場合に、Echo Serverのワーカプロセスを生成し、再びユーザからの接続要求を待ち受ける処理に戻ります。C や PHP などの手続き型言語で言うところの無限ループです。しかし Erlang では Haskell などと同様に、変数は単一代入 (値を持っている変数に別の値を持たせられない) の原則があるためループ処理が言語として実装できません。そのため、ループ相当の処理を再帰などを用いて行います。wait_connect では末尾再帰を用いて無限ループを実装しています。

 ここで wait_connect 関数内部の処理について見て行きます。内部では、一行目でユーザからの接続を待ち受け、接続が来た場合にはワーカプロセス (Echo Server) を生成し、以降のクライアントとの通信処理をワーカプロセス側で行わせるように設定し、自分自信 (wait_connect/2) を呼び出して再びユーザからの接続を待ちます。
 wait_connect の一行目で実行している gen_tcp:accept/1 が generic_server の特徴になります。これによりユーザからの接続が来るまで処理をブロック(他の処理を行わないで、ひたすた接続が来るまで待っている状態になる)してしまいます。

 では prim_inet を利用して、ユーザからの接続を待ち受ける処理をノンブロッキングで行うようにします。nonblocking_server では wait_connect の代わりに prim_inet:async_accept/2 を呼び出します。この関数呼び出しはノンブロッキングで、呼び出し元に処理が返ってきます。
 ユーザからの TCP 接続が来た場合には、handle_info/2 関数でハンドリングします。内部では、generic_server と同じように、prim_inet:assync_accept を呼び出して再びユーザからの接続を待ち受ける処理と、ワーカプロセスの起動処理を行っています。一点、接続してきたクライアントのソケットとサーバ側のソケットのソケットオプションを合わせる設定をするための関数 (set_sockopt/2) 呼び出しだけ追加されています。

 最後にワーカプロセス (Echo Server) の実装を以下に示します。ワーカプロセスは generic_server, nonblocking_server それぞれにおいて同じになります。基本的にユーザから送られたデータを返し、”quit” というメッセージが来た場合にだけはコネクションを閉じる処理を行います。

おわりに

 OTP についてはごくごく一部しか触れられませんでしたが、OTP とその背後にあるプロセスの監視機能について理解できれば、おおよその Erlang のコードが読めるようになると思います。
 今回の内容が Erlang についての興味や理解の助けになれたなら幸いです。最後まで読んでくださり、ありがとうございました。

PAGE TOP