IoT, イベント, インフォメーション, お知らせ

バズワードウォッチ、楽しんでますかー?
実体が曖昧なのに、なぜか盛り上がってる分野で、良く使われるキーワードがいわゆるバズワードです。
バズワードを追いかけると、ビジネス的な大当たりを引くこともあり、ITに関わる経営者は大体バズワードに踊らされています。
踊るのも楽しいですしね。

とはいえ、もちろん踊るだけでなく、確実にバズワードをビジネスに役立てている企業もちゃんとあります。
たとえば「クラウド」というキーワードで儲けてる企業もいくつかありまして、そのうちのいくつかの企業が、情報交換する場の一つとして活用しているのが、「日本インターネットプロバイダー協会クラウド部会」(略称:JAIPA Cloud部会)です。
そのクラウド部会では、2013年から毎年1回「JAIPA Cloud Conference」というイベントを開催しています。
2016年のイベントも明日開催されます。

 

JAIPA Cloud Conference 2016 (略称: クラコン 2016)

 

プログラムの中身を見るとびっくりするのですが「クラウド」で踊っていたはずの企業が、みんな揃って別のバズワードである「IoT」で踊っています。
おそらく IoT ビジネスになりそうなんでしょうねえ。
とはいえ IoT でのビジネスははクラウド以上に知恵と勇気が試される世界のような気がします。
知人がこう言ってました。

「IoT。無邪気な大人の本気総合格闘技」

明日のイベントも無邪気な格闘が見られると思いますので、時間がある方は出掛けてみてはいかがでしょうか?
私も朝から会場入りする予定です。

以上、メディアスポンサーとしてのツチノコブログがお送りしました。

hardware, コラム, 失敗談, 歴史, 雑談

注意: 読んでも時間の無駄、思い出話です。35歳未満の方はそっと閉じていただければ幸いです。

15年前 「まぁまぁ」定番のNIC

 10年、いや15年以上前の Linux。コンピュータ屋さん以外にもやっと Linux というものが認知されはじめ、流行のディストリビューションは Slackware から Red Hat Linux へ。「どうやら最近の Linux は結構ちゃんと動くらしいね」という巷での噂 …そんな頃を思い出すモノが会社の廃棄物置き場で発見され、思わず救出しました。

dec21140
DEC 21140

 もしかしてこれは DMM が東京進出した際にはじめて導入されたサーバに入っていたNICかも…?

 これは DEC の 21140 というチップが載った 100BASE-TX の NIC です。tulip というコード名のほうが通りがよいでしょうか。当時 Linux での NIC といえば、カニ(Realtek RTL8139シリーズ), 3com 3c905シリーズ、Intel PRO/100(8255x), そしてこの DEC の 2114x 系列 (tulip/de4x5) がポピュラーでした。他にもあることにはありましたが、Linux においての選択肢は多くありませんでした。

  1. Intel eepro100, 3com 3c905: 高級、ちゃんと動く
  2. DEC 21140: そんなに高価じゃない(6,000円程度と記憶) まあまあちゃんと動く
  3. RTL8139C or lator: 安価(2,000円?), やたらCPUを食う、運が悪いとNICが止まってOS再起動、カーネル刺さる
  4. それ以外: 安価、動くかわからない、カーネル刺さる

 この中で “まぁまぁ” の NIC は DEC 21140, これが定番でした。

安いNICはよくカーネルがpanicした

 安いNICはろくなことがありませんでした。CPUを食う、kernel panic で死ぬのは高負荷時とも限らず再現性が謎、速度が超遅くなる、NICの存在ごと沈黙、たまたま動いていてもカーネルをアップデートするとおかしくなるなどなど。珍しいパターンでは ネットワークに何かしら流れていないとCPUが食われてしまう(トラフィックのグラフと CPU使用率のグラフが対称っぽい形を描く)、などなど、さまざまな珍現象に見舞われました。

 FreeBSDの rl, RTL8139 ドライバのソースに「史上最低のひどいチップだ」のようなコメントが書かれていたことも話題になりました。

dec21140_2
DEC 21140 裏 (ぷらっとホーム)

 なんと、ぷらっとホームのシールが貼られています。DMM が東京進出した際のサーバがぷらっとホームの3Uのものだと聞き及んでおりますので、それに入っていた NIC でしょうか。

 tulip 互換をうたうチップはいくつか存在し(NETGEAR, ADMtek, なんかがあったような), ドライバのソースは互換チップのバグ ワークアラウンドで肥大化していた記憶があります。でも互換チップもちゃんと動かなかったような…

 この頃の PC-UNIX はメジャーな製品(≒ブランド品)しか動かず、貧乏学生のお財布には厳しかったものです。今日 2016 年 では Linux でもだいたいドライバはあるし、カーネルを巻き込んで死ぬようなものはとても少なくなりました。仮想化もあるし。何かハードウェアを買おうとする前に、Linux で動くのかどうか調べまくる人も減ったでしょう。


 ――なんて話を同年代の方々にしたら「チューリップ? そんなのあったなー」「俺は BSD だったし 21140 に特に思いdeはない」など しょっぱい反応……。そんな方々にも以下のカードはお気に召していただけたようです。

adaptec AHA-2940U2W
adaptec AHA-2940U2W

写真を撮ったあとそっと廃棄物置き場へ戻しました…。Interop 2016 でインターネットの未来を見たあと、ちょっと昔の思い出に耽っていました。
「歴史って、人類や生命全体の “おもいで” に違いないのよ」

IPv6, ネットワーク

インターネットは、IPパケットを利用した通信です。IPパケットの宛先や、そのIPパケットの送信元はIPアドレスという固定長の識別子によって示されています。しかし、IPアドレスだけだと人間がわかりにくいので、www.example.comのような「名前」が利用されます。

名前のままでは通信ができないので、名前に対応するIPアドレスを調べる「名前解決」が行なわれます。この名前解決を行うためにDNSが使われる場合、ユーザはDNSサーバに対してIPv4アドレスやIPv6アドレスを問い合わせます。

DNSへの問い合わせは1回に1つだけ

DNSプロトコルの基本は、1987年に発行されたRFC 1034RFC 1035が基本となり、その後各種変更が別途RFCとして発行されています。

RFC 1034には、基本的なDNSの仕組みとして、UDPデータグラムかTCPコネクションを通じた問い合わせに対して、回答するか、エラーを通知するか、他のネームサーバを参照するといった返答が行なわれるとあります。

このときやりとりされるDNSメッセージは、RFC 1035に以下のように記載されています。DNSメッセージは、Header、Question、Answer、Authority、Additionalの5つのセクションに分かれています。

DNS message format

Questionセクションは、問い合わせの内容を記述するために使われます。Questionセクションに含まれる”question”は、以下のようになっています。

Question Section

この”question”は問い合わせを行う文字列が含まれます。RFC 1035に記載されている仕様上は同時に複数の”question”をQuestionセクションに含むことが可能と読めますが、現在は事実上単一のレコードに対してしか問い合わせは行えません。

そのため、IPv4とIPv6の両方のIPアドレスをDNSサーバに問い合わせる場合には、DNSサーバに対する問い合わせは、Aレコード(IPv4アドレス)の問い合わせと、AAAAレコード(IPv6アドレス)の問い合わせが別々にそれぞれ1回ずつ、合計2回発生します。

DNSサーバへの問い合わせとトランスポート

さて、さらに話がややこしくなるのですが、DNSサーバに対する問い合わせのトランスポートと、問い合わせの内容は全く独立です。

たとえば、上記図のようにDNSサーバへのトランスポートはIPv4 UDPで行い、IPv6を示すAAAAレコードを問い合わせることが可能です。逆に、IPv6 UDPをトランスポートとして利用し、IPv4を示すAレコードを問い合わせることも可能です。

組み合わせとしては、以下の4パターンが可能です。

  • IPv4トランスポート、Aレコードを問い合わせ
  • IPv4トランスポート、AAAAレコードを問い合わせ
  • IPv6トランスポート、Aレコードを問い合わせ
  • IPv6トランスポート、AAAAレコードを問い合わせ

このように、IPv4でもIPv6の名前解決が行えるようにすることで、IPv6が整備されていない環境においても、IPv6に関連する名前解決が可能とするためという意味合いもあります。もし、IPv6でのみAAAAの検索可能という仕様であれば、特定の名前解決を行う際に関係する全てのDNSサーバがIPv6対応している必要が生じます。

13系統あるDNSルートサーバのうちの6系統にIPv6アドレスが設定され、IPv6トランスポートによるDNSルートサーバへの問い合わせが可能になったのが2008年2月4日です。もし、IPv6トランスポートでしかAAAAレコードの問い合わせができない仕様であったのであれば、2008年2月以前はAAAAの名前解決が全て不可能であったと予想できます。

RFC 3901(DNS IPv6 Transport Operational Guidelines)には、すべてのDNSゾーンはIPv4のみか、IPv4とIPv6のデュアルスタックで運用されるべきであると書かれています。IPv6のみでDNSゾーンを運用すべきではないとあるのです。

このように、IPv4とIPv6は直接的な互換性がない別々のプロトコルでありながら、名前空間は共有しているのです。

次回はCDNとの相性の話です

次回は、DNSサーバに対するトランスポートとしてIPv4とIPv6のどちらを使うのかと、CDNとの相性に関して紹介します。

イベント

こちらでもお知らせしていましたJANOG38に参加してきました。

結論を先に書くと、JANOG38はとっても楽しく有意義でした!

本会議・運営スタッフともに初参加してきた私の目線で色々書いてみます。

スタッフ業務について

まず、運営スタッフについてお話しします。

JANOG Meetingのスタッフは有志で構成されたチームで運営しています。
チーム構成は、ORG(企画編成委員)、PC(プログラム委員)、各チームを統括する実行委員長、それらを統括するSC(実行委員長)で成り立っています。

今回の運営スタッフ一覧は下記ページからご確認いただけます。
https://www.janog.gr.jp/meeting/janog38/stafflist

スタッフの募集は3月に開始され、4月の1週目には1回目のスタッフミーティングが開催されます。
募集からスタートまでがとってもスピーディー!
(スタッフ募集の告知は、JANOGのホームページやツイッター、Facebook、メーリングリストで行われるのでご興味のある方は要チェック!)

さて、私が所属していたのはORGチームなので、ORGチームについての情報を展開していきます!

ORGの仕事は大きく分けて「広報」・「会場設営」・「ものづくり」になります。

・広報の仕事…Webによる広報・SNS広報・ML(attendees等)・写真を撮る・ニュースレターを書く
・会場設営の仕事…会場ファシリティ、懇親会開催、動線アテンド、音響・照明、空調、ストリーミング配信
・ものづくりの仕事…アンケート、ランチ企画、グッズ制作、サイネージ

いずれの仕事も手を挙げればすべて関わることが可能ですし、本職との兼ね合いをみてやれるところだけ対応することもできました。
本会議当日以外は、各々の仕事の合間を見つけて作業を進めていくので、リモートでの調整が必須です。
そのため、Slack、Confluenceが大活躍!

私が主に関わったのは、Webによる広報、SNS広報、ストリーミング配信、会場設営、ランチ企画、グッズ制作あたりです。

広報では、準備期間中からTwitterやFacebookを使って、開催前の情報をUPしていきました。
事前ミーティングの様子を報告したり、今回からアンケートの方法が変わったのでそのアナウンスなどを中心に情報展開を行いました。

本会議中は、会場の様子や注意アナウンスだけでなく、おやつはここにありますよ!などなど現地にいる方、また、ストリーミングでご覧になっている方向けに情報発信を行いました。

グッズ制作では、Tシャツとアロハを作りました。
こちらは、スタッフや司会者が本会議中に着るユニフォームになります。

image (1)image (3)

絵が描けず、デザイン応募に参加できなかったのが無念でした。
次にチャンスがあればやってみたいヾ(*´∀`*)ノ

本会議中のメインタスクは会場設営!
たくさんある協賛ブースの荷物仕分けから始まり、サイネージの設置、張り紙を貼ったり、目まぐるしく動き回っていた気がします…ドタバタし過ぎてあまり覚えていなかったり><

DAY1では会場諸注意を担当しました。
たくさんの人の前で壇上に立ち、会場諸注意をするのはとっても緊張しましたが、いい経験になりました。

IMG_1147
↑懸命に会場諸注意をする私の図

ランチ企画はDAY2に参加しました。
本会議に参加しているエンジニアさん、営業さん、若者支援で参加した学生さんなど様々な人と一緒にランチをしつつ交流しました。

本会場の近くに会場を借り、想定以上の人入りで盛況でした!

IMG_8248IMG_8251

ツチノコブログを見てます!と言ってくださった方もいて、ほっこりしました。

スタッフ仕事をして感じたこと

・「これいいかも!」と提案したらすぐさまGOを出してくれる動きやすい環境!
・たくさんの企業の方々とお仕事ができ、いろんな考えややり方を学べたたのが有意義!
・Facebookの友達がべらぼうに増えた!!

少しだけプログラムのはなし

多品種少量サービス運用について その2

 

ネットワークサービス開始時やユーザ数が多いサービスはオペレータの対応回数が多く、ナレッジを貯めやすくその後も運用がスムーズにいくことが多い。一方、サービスの円熟期でもユーザが少ないままのサービスは、オペレータ対応回数が少なく以下の問題を抱えがちとなる。

1.ナレッジが無いため、一度起こると対応に多くの稼働が使われる
2.サービス開始後に新たに着任した人の習熟が難しく、人事異動が難しい
3.多品種少量サービスだけを纏められ、守備範囲が広くなる

ネットワーク運用部門はこの悩みを抱えていることが多いと思われる。この悩みについてどのように運用対応しているか、JANOGの各オペレータに意見交換、知恵だしを行い、少しでも解消できるようにしていきたい。

ORGスタッフとして上記BoFのお手伝いをしつつ、お話を聞いたのでちょこっとだけですが書きます。

・多品種少量サービスの運用はドキュメントが貯まりにくい
・そもそもドキュメントを書くのが大変
・俗人化してしまう

あるあるな内容で終始うんうんうなずいてしまいました。
みんなで解決していこうよ!という趣旨だったので一緒にまざりたかったのですが、後ろから眺めるだけで終わりました。どこかで続きが聞けると思うので個人的に追いかける所存です!

協賛ブースについて

DMM.comラボとして協賛しブース出展をしました。

IMG_1218IMG_1222

私自身は長い時間ブースに立つことができませんでしたが、それでも少しの時間ブースに立ち寄ってくれた方とお話しすることができました。

若者支援を利用してJANOGに参加されていた学生さんから「刀剣乱舞」で遊んでいます!とキラキラした目で声をかけていただき、こちらもにこにこしてしまいました。
弊社のステッカーを貼って「刀剣乱舞」で遊びます!と話してくださり、DAY3ではステッカーを貼ったスマートフォンを見せに来てくれました。

また、アフリカ事業に興味を示された方も多かった印象です。

持て余してしまうかな?と、心配していたノベルティのひえひえも沖縄で焼いた肌をクールダウンするのに活用していただけたようで、無事に配り終えました。
ブースに来てくださった皆様、ありがとうございました!

最後に

スタッフとして参加したのでなかなかセッションをゆっくり聞くことができませんでしたが、スタッフとして働いたことで学べたこともあり有意義でした。
これから就活をはじめる学生さんから「やりたいことは特別にないし、お金もそこまで稼ぎたいわけじゃない、でも楽しく働きたい場合、どういう会社を選べばいいんだろう?」と、質問されていた運営スタッフの横で話を聞いていたのですが、「JANOGに限らず、こういうイベントに業務として参加させてくれる会社は少なからず働きやすい会社だと思うよ」と回答されていたのが印象に残りました。
直接利益につながるわけではないですが、業務としてスタッフ参加させてくれた会社に感謝します。

業務としてスタッフに参加するチャンスが巡ってきた方はぜひ参加してみると新しい発見があるかもしれませんよ!

次回のJANOG39はDMM.comラボがホストとして、JANOGに関わります。
今回の経験を活かし皆様にとって有意義な会になるように尽力いたします!

イベント

JANOG38 Meeting 2日目が終わりました。

2日目はIPv6やゼロレーティングを支える技術、九州地震などの災害時のインターネットについてや沖縄県のIT戦略などなど、沖縄という土地ならではの講演もありました。

2日目のプログラム終了後には懇親会が催され、発表者を始め、色々な業種の方と交流することができました。

IMG_3487

 

ミス沖縄と泡盛の女王も応援に駆けつけて、沖縄らしい華やかな懇親会でした。

IMG_3495 IMG_3489

IMG_3493 IMG_3491

残すところは最終日。JANOG38 3日目はDMM.comラボのメンバーが4つのセッションに登壇します!

PAGE TOP