ICTSC, イベント

お久しぶりです。 2年間の学生延長オプションを申請したツチノコ、@whywaitaです。

1年ぶりにツチノコブログにお邪魔させて頂きますが、今回もICTトラブルシューティングコンテスト(以下、トラコン)のお話をさせて頂きたいと思います。 トラコンそのものにつきましては、過去に何名かが記事を投稿しておりますので、そちらも確認頂ければと思います。

第4回、第5回と運営側として参加してきた私ですが、今回は”運営OB枠”、チーム「traITors」として、参加者側で大会に加わりました。 今回は先日行われた”NTT西日本杯 第6回 ICTトラブルシューティングコンテスト”の 参加 レポートとなります。

到着まで

前日(8/26)の朝、私とメンバーの1人は東京を発ちました。学生にはお金はありませんが体力があります。 ここまで言えば分かる方には分かるかもしれません。青春18きっぷを使った12時間の旅が始まったのです。 我々が通ったルートを地図に書き出してみるとこのようになります。

12時間旅行

道中は浜松で鰻を食べました。特急を乗らずに浮いたお金で美味しい鰻を食べるライフハックとなります。

そんな楽しい(厳しい)旅を乗り越え、我々は大阪に到着し、トラコンに参加しました。

訪れた危機

大会の1日目(8/27)の朝に、チームメンバーが集まりました。チームメンバーが大阪と東京に居た関係で顔を合わせるのは前回大会ぶりでした。運営委員も疲れているだろうという事で、翼を授けるドリンクを差し入れ用に購入しました。

Redbull15本

会場に到着すると慌ただしく最後の詰めの作業をしている運営委員や、昨日遅くまで作業していたのかゆっくりと体を休めながら会場に到着する運営委員が居ました。前々回や前回の我々はあのように見えていたのか、という話をチームメイトとしていると、開場時間になったので我々も会場入り。そんな我々に用意されたテーブルには、他のチームのテーブルには置いてあるLANケーブルが無く、あったのはLANケーブルを作る為の工具類でした。

工具

するとにやけた顔の運営委員がやってきて、「皆さんはL1からお願いしますww」と言って去って行きました。ちくしょう。

まあ仕方が無いとメンバーでLANケーブルを作成します。こういう時に限って大人達は楽しそう写真を撮りにくるのです。ちくしょう。

さて、ようやくLANケーブルが出来上がってルータやスイッチに結線したら、ようやく競技を開始出来ます。

まず、スコアサーバにユーザ登録します。前回まで問題の出題や質問の窓口としてRedmineを用いていたのですが、今回は運営陣が開発したスコアサーバを用いて行いました。

kyontan/ictsc-score-server

個人アカウントの登録には「自分の名前」「自分で決めたパスワード」「運営から渡された登録コード」を用いるようです。登録コードは8文字程とのこと。 じゃあユーザー登録、を…

登録コード

運営委員によると128文字あるとのことでした。

な…何を言っているのかわからねーと思うが、俺も何をされたのかわからなかった…
ジャン=ピエール・ポルナレフ


運営委員からの愛のプレゼント(単に嫌がらせとも呼びます)は問題にも現れます。

各チームにはそれぞれIP Phoneを渡されていました。 Cisco社から提供されたモデルはPoEによって運用されており、LANケーブル1本で電力とデータを供給出来ます。 しかし我々のチームのIP Phoneはそもそも色々な情報が来ていないようでした。 色々試してみたのですが問題が解決出来ず、ふと使われていた(これは運営陣が用意したLANケーブルです)ものを見てみると…

データ線無しLANケーブル

上が正常なLANケーブル、下がIP Phoneに刺さっていたLANケーブルです。 少し見づらいですが、下のLANケーブルには中の線が少し足りない事にお気づきでしょうか?

なんと運営委員は、PoEの中で電源給電部のみを残したLANケーブルを専用で作成していたのです。 ここまで手の込んだ悪戯をする為には、少なくない労力が必要でしょう。我々は逆に少し感心してしまいました。

さて、結果は…?

多くの運営委員からの嫌がらせ愛を感じながら、競技は終了しました。

結果としては2位相当(我々は招聘チームのため、表彰対象外となっています)で、あと8点足りず1位にはなれなかったようです。 うーん、残念。

前回のDMM.com Laboさんの言葉をお借りして、

『まあ結果はいいじゃないか』

という事で。


大会の翌日(8/29)、我々チームメンバーは会場に再度訪れていました。

大会は2日間で終わりですが、最後に会場からの撤収作業が必要となります。 お借りしたルータ、スイッチ、サーバ、ラックを1つ1つ梱包しながら片付けていきます。 勿論会場もお借りした時の状態に戻します。大会で利用したホワイトボードや机なども元の形に戻します。

東京へ送る荷物全ての発送が終われば、現地での作業は終了です。

まとめ

4日間の参加レポートをお届けしました。

参加者側からの視点で見るトラコンはまた運営側から見る物とは別の物です。 今までもそれは若干感じていたのですが、実際に運営側と参加者側両方を経験してみると、また色々な物が見えて興味深い感想を持ちました。 どういうような感想を抱いたのかなどは、今回の運営委員にフィードバックしていき、よりよい大会運営に役立てていきたいと考えています。

一緒に大会に参加してくださった参加者の皆様、この大会の為に尽力してくださった社会人の皆様、 そしてなにより、今回のトラコン開催にこぎつけた運営委員に感謝申し上げます。

次回大会をお楽しみに。

どのような形で関わるかは、この記事を読んでくださった貴方次第です。

イベント, 勉強会

過去の関連記事:今週末(8/23)はお台場(LL Diver)に行こう

Lightweight Language of Things
http://ll.jus.or.jp/2016/

8月27日(土)に日本電子専門学校で行われた、真夏のプログラミング言語イベントこと、LLイベントのお手伝いに行ってきました。入り口で受付のお手伝いをしたのですが Peatix とっても便利ですね。イベント参加者として使用したことはあったのですが、イベント運営側で使用するのが初めてだったのでちょっとテンションが上がりました。QRコードをかざすだけで、さくっとイベント申込者を確認できる仕様、便利でしたー!

LLイベントとは

Lightweight Language (軽量プログラミング言語)をテーマとして1年に1回開催しているイベントです。
今年は、Lightweight Language of Thingsというタイトルに掲げ、LLらしい言語、LLらしいプログラミングとは何かを議論するカンファレンスでした。

これまでのイベントについてはこちらをご覧ください。
http://ll.jus.or.jp/2016/history

個人的に面白かったセッション

IMG_8729

LL言語の話でないところをフォーカスして大変恐縮ですが、キーボードにこだわろうについて書きます。

今回のセッションでは、Happy Hacking Keyboard、Realforceのメーカの方、ErgoDox、Kinesis愛用者さんが登壇して、キーボードについて熱い議論が繰り広げられていました。
私は、ThinkPad X1 CarbonのノートPCのキーボードを利用している所謂「キーボード0円勢」ですが、会場アンケートで2万円以上のキーボードを使用している方が多くてびっくりしました。

印象に残っている話をざっくりと

・Happy Hacking Keyboardを当時、秋葉原の小売店で販売したら32000円であっという間に売れた、無刻印キーボードはエンジニアの自尊心をくすぐった。当初、イベント販売だった物が定番商品になった。
・ErgoDoxは、ろくろを回す姿勢は疲れないので、近いポーズでキーボードが打てるように作った。
・東プレの静電容量無接点キーボードは接点がないので摩耗せず、壊れにくい。
・アームレストにはバナナの高さがちょうどよい。バナナが悪くなる前に食べて次のバナナに交換するオペレーションが必要。

展示ブースにて

展示会場では、各キーボードが展示してあり、個人的には東プレの静電容量無接点キーボードがすごくしっくりきて欲しい!となりました。Happy Hacking Keyboardは総漆塗りの試作機から、実際に発売された50万円のキーボードも!漆塗りでもキーの打ち具合はHappy Hacking Keyboardそのものでした。大変お高いのですが、漆塗りは耐久性が高くコーディングがはげることもないとのことでしっかりしたお品でした…!触れて感動!(現在、購入することはできません!)
IMG_8732

本当にすこしだけ言語の話

Dynamic Typing再考を聞いて、印象的だった発言を少しだけ。ちなみに、最高と再考をかけているそうです…。

・6月は毎年来る!クリスマスとは違う!(毎年6月にES20xxとしてリリース)
・型がなくても動くのに型をかくのは冗長
・本当はテストも書きたくない

”型がなくても動くのに型をかくのは冗長”というお話を、まつもとゆきひろさんが何度もお話しされていたのがとても印象的でした。これを心から理解できるように言語の勉強を少し始めようと思います。

 

最後に

JTF2016の懇親会にてひょんなことから、今回お手伝いに行くことになりました。いつもとは異なる界隈の話が聞けて有意義でした。個人的なこととしては3Fの控室兼展示ブースで、前田さんに見せていただいたTコード芸(芸ではないですね、失礼しました。)が素晴らしすぎました。変換なしですらすらと漢字を入力する様を見せつけられました。常人にはまねができない。

ご興味のある方はこちらをお読みください。
Tコードについて

MQ, OpenStack, Python

 こんにちは、インフラ本部の大山裕泰です。
 今日は OpenStack の共通ライブラリ群 oslo に含まれる olso.messaging を使って RPC over MQ 処理を実装してみます。なぜ RPC を MQ を介して行うと良いかについては 過去のエントリ で書きましたので、興味があれば読んでみてください。

oslo って何?

 oslo は OpenStack の各コンポーネント (OpenStack の最も大きなソフトウェアモジュールの単位) で共通で利用するライブラリを集めたプロジェクトになります。
 その昔の OpenStack では設定ファイルやコマンドライン引数の解析、メッセージパッシング、ロギングなどといった処理が各コンポーネント毎に個別に存在しており、開発・メンテナンスコストが掛かる問題がありました。
 そして Grizzly サイクルで共通ライブラリ群を提供する olso プロジェクトが発足し、Havana で設定ファイルとコマンドライン引数の解析を行なう oslo.config と、通知や RPC の仕組みを提供する oslo.messaging がリリースされました。現在では、国際化や並行処理など様々な機能が加わり、本稿執筆時点では 34 のライブラリ が存在します。

 oslo 自体は OpenStack のプロジェクトですが、用途は OpenStack に限定されません。例えば oslo.config は、設定ファイルとコマンドライン引数の解析を行なうライブラリとして広く知られており、NTT Communication などが中心となって開発している SDN Framework Ryu などで採用されています。
 今回紹介する oslo.messaging では、RabbitMQZeroMQ などの MQ システムを介した通知や RPC の仕組みを提供します。

なぜ oslo.messaging なのか?

 oslo.messaging の使い方について見て行く前に、oslo.messaging についての理解を深めるために、なぜこの仕組みを使うのかについて考えてみたいと思います。
 MQ を利用した通知や RPC の仕組みは、もちろん oslo.messaging が登場する以前から存在していました。RabbitMQ を使う場合には Pika という AMQP ライブラリを用いてそれらの処理を行なうことができます。また ZeroMQ を使う場合には、PyZMQ ライブラリを用い、Kafka にも 同様の Python ライブラリ が存在します。

 しかしこれらを用いることによって、ミドルウェアないはプロトコル依存の実装になってしまいます。
 oslo.messaging では、ミドルウェア・プロトコル非依存の通知、RPC の仕組みを提供しており、これによってユーザは様々な MQ システムを選択することができるようになりました。

oslo.messaging の使い方

 以降では oslo.messaging を使って、汎用的な RPC over MQ 処理を行なう方法を紹介します。サンプルとして以下のコードを利用します。

https://github.com/userlocalhost2000/oslo-messaging-examples

 コードの中身を見る前に、システムのアウトラインについて簡単に把握したいと思います。以下は oslo.messaging と他のシステムとの関連、及び内部アーキテクチャについて表した図になります。

 処理のおおまかな流れとしては、左上の “User Application” が “RPCClient” で定義されたインターフェイスを叩き、”Transport” オブジェクトで抽象化された MQ システム (RabbitMQ など) を経由して “Server” に登録された “Endpoint(s)” の処理を実行し結果を取得します。ここでは、oslo.messaging レイヤにおけるクライアント、サーバ側の内部の仕組みについて簡単に解説します。

 クライアント側では RPCClient オブジェクトがユーザアプリケーションに対して、RPC 処理の仕組みを提供します。また Transport オブジェクトが、RabbitMQ や Kafka , ZeroMQ などの各種 MOM を抽象化し、ユーザは RPCClient が提供するインターフェイスを通して MOM 非依存な RPC リクエストをサーバに送ることができます。
 サーバ側では、ユーザからの RPC 要求を処理する Server オブジェクトを生成します。その際、ユーザ側で各 PRC 要求に対応する処理 (Endpoint) を一つ以上実装してやり、それらを Server オブジェクト生成時に指定します。
 また Server 及び Endpoint(s) に対して RPC API の名前空間と互換 version について設定することができます。これらの設定を保持したものが Target オブジェクトになり Server 及び Endpoint にひも付きます。
 Endpoint オブジェクトにおいて Target を省略した場合には、グローバルな名前空間と version1.0 が暗黙的に設定されます。ただし Server オブジェクトにおいては Target オブジェクトを topic 及び server パラメータ付きで指定しなければなりません。
 Target オブジェクトの topic パラメータは、サーバが提供する API を識別するための項目で amqp ドライバにおいては名前付きキューの名前に対応します。クライアントはこの値だけを知っていれば、サーバの場所を意識せずにサーバに対して RPC 要求を送ることができます。
 また Target オブジェクトの server パラメータは、文字通り API を提供するサーバを指定する項目ですが、実際に存在するサーバのホスト名ないしは IP アドレスを指定しなければならないわけではく、サーバを指定する任意の文字列になります。これはクライアントが topic パラメータで指定した API を持つサーバ群のうち、特定のサーバに対してメッセージを送りたい場合に利用されるパラメータになり amqp ドライバにおいては、topic 名で指定した名前付きキューに加えて、”${topic}.${server}” の名前付きキューを生成します (${topic} と ${server} にはそれぞれパラメータの設定値が入ります)。

動かしてみる

 各データ構造の役割と関連がわかったところで、サンプルコードを見ながら実際に動かしてみます。
 まずサンプルコードを動かすために oslo.messaging をインストールします。またここでは Python 2.7.6 を使用しています、尚本稿執筆時点で OpenStack がサポートしている Python のバージョンは 2.7.x と 3.4.x になります [*1](https://wiki.openstack.org/wiki/Python3)。

 続いて次のサンプルコードを GitHub から取得します。

 サーバ側のコード src/server.py について簡単に解説します。以下がその抜粋になります。

 22 行目の get_rpc_server メソッドの呼び出しで Server オブジェクトを生成します。RPCClient からの RPC 要求に対して endpoints パラメータで指定したオブジェクトにマッチするメソッドを呼び出します。その際、エンドポイントオブジェクトに target メンバが設定されている場合には、namespace と version ネゴシエーションの確認を行います。target メンバが指定されていない場合には、デフォルトの namespace (=None) と version (=1.0) が内部的に設定されます。
 コールバックメソッド hoge() のパラメータはそれぞれ、ctx がユーザ定義のオブジェクト (ディレクトリ型) を表し、arg がユーザ定義の引数を表します。

 次にクライアント側のコード src/client.py についても簡単に見て行きます。以下がその抜粋になります。

 20 行目でユーザ定義の RPCClient ラッパーの hoge を呼び出し、内部的に 15 行目でサーバに対して hoge メソッドの呼び出しを行っています。その際 14 行目の prepare() メソッドの呼び出しで RPCClient オブジェクトが内部で持つ Target オブジェクトの namespace と version パラメータを上書きします。
 version パラメータがサーバ側のエンドポイント hoge() で指定した値と一致していないことに気づいたかもしれません。Server 側のバージョンネゴシエーション処理では、クライアントからの要求 version のメジャーバージョン (上の位) が一致しており、かつマイナーバージョン (下の位) がサーバで設定した値以下であれば、互換性がある要求として当該メソッドを実行し結果を返します。

 それでは、実際にこれらを実行してみます。次のようにターミナルからサーバスクリプト src/server.py を実行し、次の別のターミナルを開いてクライアントスクリプト src/client.py を実行してみてください。


(左:サーバ、右:クライアント)

 クライアント側からの呼び出しでサーバ側で定義したエンドポイント hoge() が呼び出され、クライアント側で実行結果が受け取られていることが確認できました。

hardware, linux, 小ネタ

おはようございます。ライトノベル好きのツチノコです。ヒマワリの季節が近づいてきましたね。

さて、タイトルの通り、ONIEをbuildしました(というか何回かしている)ので日本語で手順をまとめておきます。
公式のドキュメントは https://github.com/opencomputeproject/onie/wiki/Building-ONIE です。

5月のJapan ComCamp meets de:codeでLTした、例のブンチンカッコカリからのリカバリの時にも利用しました(スライド中ではONIE関連は省略)。

前の記事はここです。間があいてしまってもうしわけないです(夏休みの宿題はためるタイプでした)

環境はDockerで作ってしまうことにします。Dockerfileは https://gist.github.com/wataken44/e5e6c7f94b257c15196d50bab9a9a2de にあります。

まずはimageをbuildします。

Dockerfileの中身は以下のようになってます。

コンテナを走らせてbuildします。

<vendor>,<model>のところにはお手元の機種名を入れます。DellのS6000-ONだとそれぞれdell, s6000_s1220になります。一覧は ~/onie/machine 以下にあります。

1時間くらいでbuildが終わり、isoイメージやpxe用のイメージができます。

あとはUSBメモリに焼くなりなんなりしてセットアップすればONIEのインストールができるようになります。
ご活用ください。

BIOS
上はDell S6000-ONのBIOS画面です。AMIのBIOSが動いていて、8GBのメモリが乗っていることがわかります。
シリアル経由ですがツチノコブログの読者には見慣れた画面ではないでしょうか。

S6000のBIOS
Boot orderを変更できる画面です。

ネットワークスイッチのBIOS画面が見れて、そこらへんのPCと同じようにOSをインストールしたりできるようになりました。すごい時代ですね。

p.s. このテンプレ展開のせいで、おれのラブコメが鬼畜難易度がすごい

CDN, IPv6, ネットワーク

前回、DNSサーバを利用した名前解決と利用するIPバージョンの組み合わせに関して紹介しました。今回は、IPv4とIPv6を別々のISPで接続しているような場合、DNSを利用するCDNとの相性が問題になる可能性について紹介します。

問題が発生するのは、以下の図のようにIPv4とIPv6で別々のISPを利用しつつ、キャッシュDNSサーバはどちらか片方のISPを利用しているような環境です。たとえば、フレッツでIPv4とIPv6を別々のISPにするような設定をしていたり、IPv4しか提供されていない環境で、Hurricane Electricなどが提供しているようなIPv6 over IPv4トンネルを使っているようなときに発生する可能性があります。

この図では、家庭に対してIPv4はISP Aによって提供され、IPv6はISP Bによって提供されます。ユーザが利用しているPCに設定されているキャッシュDNSサーバは、IPv4を利用しているISP Aのものを利用しています。

このような環境で、CDNによって負荷分散が行われているコンテンツをユーザが取得するときの流れをみます。

まず、最初にユーザがISP AにあるキャッシュDNSサーバを利用して名前解決を行います(1)。このとき、ユーザはIPv4とIPv6の接続性を両方持っているので、AAAAレコードの問い合わせを先に行っているものとします。また、AAAAレコードの問い合わせに使われるキャッシュDNSサーバまでのトランスポートはIPv4とします。

ISP AにあるキャッシュDNSサーバは、権威DNSサーバにAAAAレコードの問い合わせ行い、回答を得ます。ISP AとISP Bは、双方ともにIPv4とIPv6両方で運用されており、IPv6で運用されたCDNキャッシュが両方のISP内にあるものとします。

このような環境下では、権威DNSサーバは問い合わせを行ったキャッシュDNSサーバの最寄りコンテンツキャッシュであるCDNキャッシュAを、キャッシュDNSサーバへと返答します(2)。

キャッシュDNSサーバからの名前解決結果を受け取ったユーザは、CDNキャッシュAからコンテンツを取得します。このとき、コンテンツ取得に利用されるトランスポートはIPv6となるため、ユーザはISP Bを経由してCDNキャッシュAにあるコンテンツを取得します。

しかし、ISP BにもCDNキャッシュBというコンテンツキャッシュがある場合、ユーザは遠回りをしてコンテンツを取得していることになってしまいます。このような遠回りが発生するのは、CDNによる負荷分散機能の一部である権威DNSサーバが「ユーザはISP Aにいる」と認識しているために発生しています。

ISP BのキャッシュDNSサーバを利用すれば、ユーザはCDNキャッシュBからIPv6トランスポートを利用してコンテンツを取得できるようになりますが、今度は逆にIPv4でのCDNキャッシュコンテンツ取得が遠回りになってしまいます。

DNSのリソースレコードごとに、利用するキャッシュDNSサーバを設定できれば、このような問題は軽減できると推測されます。たとえば、IPv4のAレコードを取得するときと、IPv6のAAAAレコードを取得するときに利用するキャッシュDNSサーバをそれぞれ設定することによって、キャッシュDNSサーバとのトランスポートとリソースレコードをマッチさせることができれば回避可能です。しかし、現時点では、そういった使い分けが行われることは稀であるため、このような問題が発生していると思われます。

ただし、このような状況に陥ったとしても、単に遅くなるだけでユーザが気がついていない可能性も考えられます。そもそも、CDNとの相性を追求するような設定をユーザ側が行うことが正しいのかどうかという問題もあります。

この話は多少マニアックではありますが、IPv4とIPv6のデュアルスタック環境において発生する課題発見や運用ノウハウの蓄積は、まだまだこれからかも知れません。

PAGE TOP