イベント, クラウド, プログラミング, 勉強会

■ はじめまして

CROSS2016で実行委員長をさせていただいているRYOSUKEです。
Dmm.comラボさんのご厚意により、お邪魔させていただきました!!

僕らがやっているCROSSについて、ちょとだけお話をさせてください!

■CROSSって?

CROSSは、2012年から開催している、WEB/ITテクノロジーに関わる全ての人のためのイベントです。
特定の企業の特定の方だけにお話をしていただくのではなく、1つのテーマにそって複数の企業や技術、
世代などを交わらせ、パネルディスカッションをして頂くことによって、異なる価値観、その差分から
垣間見える技術や考え方の本質を皆さんに感じてもらえればと思っています!

もちろん、難しいこと考えなくても、普通に楽しめます!
CROSSっていろいろ特徴があるんで、説明させて。

IMG_5620

■CROSSの各セッション会場について

CROSSに来られたことがある方はご存知かと思いますが、CROSSの会場は大きなホールを区切って、
ある程度周りの音が聞こえるように設計しているんです。
これは、会場全体をお祭りの縁日をイメージして作られているからなんです。
縁日って、人が多い方、盛り上がっている方を目指してみんな移動して、いろんなものを見ていきますよね?
他のイベント/カンファレンスよりも、ザワザワ感が常に感じられ、より多くの盛り上がりがある方に行って、
新しい発見を是非して欲しくて、そうしています。
※ その昔、僕がセッションをやっていたら隣のセッションが大きく盛り上がって、僕のセッションから
人がさっといなくなったも良い思い出です ><

■今年のプログラムについて

今年のプログラムは、HadoopやSparkといった分散テクノロジーや機械学習、IaaSクラウドの内情やIotといった
比較的新しいテクノロジーとされるものを始めとして、首都近郊の地方や海外と日本での働き方、そして運用の話、登壇されるのはいずれも、一線級の方々ばかりです。
普段使っているOSSのコミッターや、システムの開発者、その企業のCEOなどが集まってくださっていますので、非常に濃いエッセンスが得られると思います!

http://2016.cross-party.com/program

まずは、ご自身の興味のあるところを中心にしつつ、ちょっと外れたところもぜひ見に行ってください。

 

■なぜ横浜にした!?

横浜、普段都内で開催されるイベントに参加されている方からしたら、遠いですよね?
実は、CROSSは第3回まで新宿でやっていました。でも当日見ていて、「目当ての一つのセッションだけ見て帰ってしまう人がいる。」
「電話で呼び出されて、事務所に戻ってしまう人がいる」これって、とてももったいないなと思ったんです。

なまじっか近いから、そういうことになるのかと思って、思い切って横浜での開催にしてみたのです。
昨年の様子を見る限りでは、かなりの方が一日いて下さったのかなと思っています。
実は渋谷からは40分くらいでいけますが、プチ出張気分の横浜でガッツリ一日過ごしてください!

 

■今年の出し物

・ヒートマップ

CROSSみたいなカンファレンスやイベントで実際の人の動きって見えたら、面白いと思いません?
デザインを語るセッションに実際にいるのは、WEB系の人だったのかな?デザイナーなのか?職種は?どのくらいいたんだろう?こういったものをリアルタイムに知ることができれば、セッションを開催する側も参加している人もより良い活動ができると思うんです!※一般の方に見えるのは、どの会場にどの程度の人がいたかになり、公開はされません。
ちなみに今回のシステム(ヒートマップシステム)はさくらインターネットさんと、DMM.make AKIBAさんが
共同で構築してくださっています。こういったアイディアやモノが出てきて、試せるのも、面白いですよね!

heatmap_sequence

・最高の発想力と最低の技術力の共演

また、昨年は大変盛り上がった、ニフティDPZの言語対抗綱引きですが、今年は何か素敵なDATAが入っているかもしれない古(いにしえ)のメディアを落とす射的大会と、技術力が低い人向けのロボット対決(ヘボコン)が開催されます。射的は随時参加可能な予定ですが、ヘボコンは参加が8名までとなっていますので、早めに来てエントリーしてください!!
審査員には、技術力の粋を集めたあの方が参加されると伺っています!!

 

 

■実現したいこと

CROSSは自分の興味の外側に触れることで、自分の境界を明らかにし、その外側を知る機会を提供しています。自分のやっていることと、やれるかもしれないところ、わからないものを発見し、やりたいと思ったら、アンカンファレンスで表現することができます。
ぜひ、自分のやりたいこと(仕事の運用改善でも、新しいビジネスでも、疑問でも何でも良いです。)を認識し
楽しめるかどうか、ちょっと考えてみるきっかけにしてみてください!

また、CROSSでは、こういったカンファレンスや勉強会には会社の業務として参加して良いという文化を作りたいと思っています。今年からそういった趣旨に賛同いただける企業様を募集しリストしていこうと思っています。

ぜひ、こちらからお伝え頂けると嬉しいです。

IMG_5629

■ 最後に

だらだらと書いてしまいましたが、CROSS2016は参加者が主体となって駆動させるとてもおもしろいイベントです。ぜひ参加していただき、何かを持ってかえって頂けると嬉しいです。(※今年は実験的に無償です!)
それと、来年CROSS2017をやれることになったら、ぜひ実行委員会に参加してみませんか?
業務では絶対に無いであろうおもしろ体験が沢山出来ます!!

最後になりますが、DMM.comラボさんには、ネットワーク構築と機材提供のお手伝いをしていただきました!
また、このような駄文掲載の機会も頂けて大変うれしいです!!
また来年もよろしくね!

IMG_5639

※本文はCROSS実行委員会より寄稿させていただいたものになり、文責はすべて実行委員会にあります。

イベント, インフォメーション, デザインパターン, ネットワーク

明日からJANOG37 Meetingが名古屋で開催されます。
DMMもスポンサーになっているので興味がある方はスポンサーブースまでいらっしゃってください。
ただ、冬なので残念ながらカキ氷はありません。ごめんなさい。

JANOG37 Meeting
http://www.janog.gr.jp/meeting/janog37/

今回もプログラムは盛り沢山ですが、全体的にわかりやすいプログラムが多いな、という印象です。
そんな中、2日目の夕方、パターンを題材にBoFをやることになりました。
わかりにくいプログラムが1つぐらいあっても良いよね。

Pattern BoF 2 – Pattern Oriented Network Architecture
http://www.janog.gr.jp/meeting/janog37/program/pattern

 

登壇者はかなりスペシャルです。

1人目はソフトバンクが誇るアーキテクトの松嶋さん。
松嶋さんは数々の実稼動している巨大サービスネットワーク基盤を設計してきているのですが、そのデザインを良く見ると、うはー、と思うポイントがいくつかあるんですよね。

たとえば、高速切り変えのため、ルートリフレクターをSDNコントローラとして使う、というようなアイディアをサービス網に実際に導入したりしています。
その説明資料が以下なのですが、なんと2007年の発表なんですよ。
このシステムは今も動いているらしいですが、時代を先取りしすぎている感はあります。

JANOG 20 〜 高速な障害復旧に必要な思いやり 〜
http://www.janog.gr.jp/meeting/janog20/pg-kousoku.html

ソフトバンクのIPv6対応は、ステートレスなプロトコルを用いて進められているのですが、この裏にも松嶋さんの思いが詰まっています。
以下のセッションの松嶋さんの資料を眺めてもらえるとわかるかと。

JANOG 25 〜 既存ユーザへのIPv6 提供と実装を考えてみる 〜
http://www.janog.gr.jp/meeting/janog25/program/v6deploy.html

JANOG 26 〜 IPv6時代のIPv4を考える 〜
http://www.janog.gr.jp/meeting/janog26/program/dslite.html

JANOG30 〜 これでいいのか4rd -標準化と実装と運用のはざまの奮闘記- 〜
http://www.janog.gr.jp/meeting/janog30/program/map.html

最近ではIPv6の中にVIDを埋めこむことでオーバレイネットワークが作れるというようなアイディアなんかも喋っています。

MPLS Japan 2015
http://www.mpls.jp/

EVPN/Overlayとネットワークアーキテクチャ
http://www.mpls.jp/presentations/MPLS-JAPAN2015_matsushima_post.pdf

他にも松嶋さんのアート(?)はあるのですが、常人では思いつかない発想がどんどん出てくるというのは、ぶっちゃけ天才であり変態ではないかと。

 

2人目の登壇者はシスコの河野さん。

河野さんは普通の人より先のことが見えてるんですよね。
話をすると、謎なことを言ってるなあ、と思うこともあるんですよ。
でもそれが1年後ぐらいにふと、なるほど、あのとき言ってたのはこういうことだったのか、と気付いたりします。

技術的な予言は深い知見の組立てで行なわれるわけで、そもそも河野さんが言うことをちゃんと理解するには、それ相応の勉強が要求されます。
たとえば昨年11月でのMPLS Japanでの発表資料を見てもらいたいのですが、

Networkプログラマビリティとステート性・トランザクション性
http://www.mpls.jp/presentations/MK_state-in-programming_01.pdf

この発表では

– ネットワークに関するある程度の知識
– SDNについてのここ数年の動き
– 宣言型プログラミングについての知識
– 分散システムについての知識
– コンピュータサイエンス
– ネットワーク技術の歴史
– トップエンジニアが持っている哲学的なもの

などが詰まっている感じでしょうか。
そのへんの前提知識があった上で未来を理路整然と組み立てているように感じます。

河野さんはシスコのブログも書いています。
これも中身がとても濃くてタメになります。

Cisco Japan Blog >> Miya Kohno
http://gblogs.cisco.com/jp/author/miyakohno/

 

今回のBoFにあたっては、松嶋さん、河野さんとDMMの酔っ払いさんの3人から、ネットワークシステムをデザインするときの考慮点を聞いて、デザインパターンとして抽出をしてみました。
そのパターンをネタとしてあれこれ話ができれば良いかな、と思っています。
パターンを使えば、アーティストや予言者が考えていることがうまく説明できるかもしれません。
というか、できるといいなあ。

 


 

過去の関連エントリ

JANOG34 Meetingで話をしてきました

JANOG35 Meetingで登壇してきます

JANOG US Regional Meeting 2015-10-23

JTF2015でスキルパターンを作った話をしてきました

 

Ruby, プログラミング

はじめに

 こんにちは、インフラ統括本部の大山裕泰です。今回は、EventMachine によってイベント駆動型なサーバを記述した場合と、従来のフロー駆動型なサーバとで、高負荷環境にいおいてどれだけリソースの使い方に違いがあるのかを調べてみたという話になります。
 すっごい今更な内容ですが、この辺りの内容をキチンと押さえておくと、サーバサイドアプリケーションを記述する際、どのようにサーバを記述すれば(高負荷になった際に)どのマシンリソースが、どのように使われるかがわかるようになって嬉しいと思います。

EventMachine って何?

 I/O 多重化によるイベント駆動 I/O (Event Driven I/O) を実現するためのミドルウェアで Rails などで利用されています。RabbitMQ クライアントの一部 でも使われています。

イベント駆動 I/O って何?

 イベント駆動型プログラミング (Event Driven Programming) と呼ばれるプログラミングパラダイムを用いて I/O 処理を実現したものになります。 イベント駆動型プログラミングは、決められた手続きに沿って順に処理を行うフロー駆動型プログラミングの対抗概念になり、GUI プログラミングのようにユーザからのキー入力やマウス操作を “イベント” という形に抽象化し、これらを処理するコールバックルーチン “イベントハンドラ” をそれぞれ記述してゆきます。
 フロー駆動型プログラムにおける I/O 処理では、ソケットファイルディスクリプタを通してバッファからデータを取り出し、何か処理して、またデータを取り出し… というような感じで、データストリームに対して処理を行ってきました。例によって Echo サーバをフロー駆動な感じで記述すると以下のようになります。

 コネクションの確立、データストリーミング処理、切断処理といった一連の処理が一つの手続きによって記述されているのがわかります。
 これに対して、イベント駆動型プログラムにおける I/O 処理では、こうしたデータストリームをイベントという形に変換してやり、これをユーザが定義したイベントハンドラに処理をさせます。
 EventMachine によって Echo サーバをイベント駆動な感じで記述すると以下のようになります。

 コネクションの確立、データの取得、切断処理がそれぞれイベントハンドラで記述できています。

何が嬉しいの?

 イベント駆動 I/O についてグダグダと書いてきましたが、EventMachine によって得られるもう一つの恩恵 (というか今回はこっちがメイン) として I/O を多重化してくれます。I/O 多重化 (I/O Multiplexing) とは、複数の I/O ストリーム (ファイルディスクリプタ) を一元的に操作する手法で、select / poll / ppoll 等のシステムコールによって実現されます。つまり、一つのプロセス (あるいはスレッド) から複数のファイルディスクリプタを同時に取り扱うことができるようになります。これに対して、先ほどのフロー駆動 I/O による Echo サーバの例では、コネクションの度にスレッドを生成し、ソケットファイルディスクリプタはそれぞれのスレッドが独立して持っています。

 では何故 I/O 多重化なのでしょうか? それは C10K 問題 (C10K Problem) を解消する手法として期待されたためです (C10K 問題については、丁寧に解説してくれているサイトがいくつもあるので、併せて参照してください) 。
 ざっくりと説明すると、凄まじい数のコネクションを受け付けるサーバにおいて、フロー駆動 I/O の例で示したような実装をするとリソースを大量消費してしまい、処理が捌けなくなるよーという内容です。
 どういうことかというと、コネクション毎にプロセス (ないしはスレッド) を生成して、ビジネスロジックを走らせ、レスポンスを返すやり方だと、プロセスを生成する場合、プロセス毎にデータセグメントがコピーされるので大量にメモリが消費され、また大量に発生するコンテキストスイッチによる大量の TLB フラッシュによって大量の CPU 時間をにカーネルに持って行かれてしまいます。スレッドを生成する場合でも、プロセスのスタック領域のコピーや thread_info などカーネル内部に確保されるスレッド用のデータによって線形にメモリが消費され、またプロセスの場合ほどではないにしろ大量にコンテキストスイッチが発生するためコネクションが増えるに従って CPU 時間をロスします。
 多重 I/O では、単一スレッドのプロセスにおいて、複数のファイルディスクリプタを扱うことができるため、上記の問題が回避できます。
 尚、I/O 多重化をイベント駆動プログラミングと絡めて話していますが、イベント駆動 I/O を実現する上で I/O を多重化すると嬉しいことがあるので、たまたま同時に語られることが多いですが、これらはそれぞれ独立した概念で、I/O 多重化はイベント駆動でなければならないということではないです。

検証

 ここで、先ほど紹介しましたフロー駆動で実装した Echo サーバ (normal-echo) と、イベント駆動で実装した Echo サーバに (event-echo) 対してベンチマークを実施し、それぞれのリソースの使い方について確認します。尚、ベンチマークツールには methane さんの echoserver の client を用いました。測定したサーバ環境は以下のとおりです。

* CPU : Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz
* RAM : 4GB
* OS : Ubuntu 14.04
* Ruby : 2.0.0p384

 以下のように “同時実行数” と “スレッド当たりのコネクション数” をそれぞれ 100 から 400 までの条件で実行し、サーバのメモリ消費量を計測しました。

 実行結果は以下のとおりです。緑の棒グラフで示したものが normal-echo におけるメモリ消費量を表し、青色が event-echo におけるメモリ消費量を表しています。

 normal-echo の方はコネクション数が増えるに従ってメモリ消費量が増えているのに対して、EventMachine で実装した方はほぼ一定値で推移しています。
 また、スループット (処理したリクエスト数の秒平均値) を以下に示します。例によって、normal-echo の結果を緑、event-echo の結果を青で示しています。


 
 今回はまたま全ての結果が EventMachine で実装した方が優れていますが、あらゆるケースにおいて EventMachine が優れているわけではありません。
 normal-echo における各 CPU コアの利用率を表したものを以下に示します。

 全てのコアがまんべんなく利用できているのがわかります。これに対して event-echo における各 CPU コアの利用率を表したものが以下になります。


 
 特定のコアに処理が集中しているのがわかります。というのも、I/O 多重化によって一つのスレッドで全ての処理を捌いているので、マルチコアの恩恵が受けられていないためにこのようになっています。
 なので、先ほど示したスループットの結果は実行環境やワークロードによって変わってきます。今回利用したベンチマークツールでは、1 コネクション当り、6 byte のショートメッセージ “hello\n” をデフォルトで 100 回送るというもので、サーバも Echo サーバなのでコンテキストスイッチの CPU コストよりも Echo サーバのロジックが軽量だったため、上記のようになったと思われます。

終わりに

 今回は、イベント駆動プログラミング、I/O 多重化、そして I/O 多重化によって、どのリソースがどのように消費されるかについて見てきました。
 ここでの内容によって、効果的にリソースを消費するサーバ実装の手助けになれば幸いです。

huawei, コラム

前回からの続き。

ショールーム見学の後はランチタイム。
まずは社員食堂にお邪魔しました。

IMG_0991IMG_0993IMG_0994IMG_0996IMG_0997IMG_1003IMG_1004

4万6000人が働くキャンパスだけあって食堂も広い!!
人もすごく沢山。
メニューも沢山。
しかもおいしそう。
社員の年齢層は低めで活気にあふれてました。
写真をクリックすると大きくなるので開いてもらうと様子がわかるかと思います。

食堂の横にはセブンイレブンもありました。
今の為替レートだと、1元=20円、ぐらいなので日本との価格差はほとんどありません。

IMG_1008IMG_1013IMG_1015IMG_1016

パン屋さんもありました。
こちらもおいしそう。
やっぱり値段は日本と変わりません。

IMG_1009IMG_1017IMG_1019

でも我々はここでは食べずに食堂の2階に移動。

エスカレータを上がると美女3名の生演奏でお出迎え。

IMG_1023

Huaweiには接待部という部署があり彼女達はそこの所属なんだとか。

我々が2階で食べたランチも接待部所属の一流シェフの手によるもので、大変美味しゅうございました。

IMG_1033IMG_1037IMG_1041

ちなみに「接待部」は接待だけをしているわけではなく、

  • ショールームでの説明
  • コールセンターでの一次対応
  • 取引先とのアテンド対応

等の業務も行なっていて、どんな新人でも必ず接待部に一度は配属されるそうです。
新人はそこでHuaweiの製品知識やカスタマー対応なんかを学ぶとのこと。

おいしいものを食べた後は会議室でエンジニアとディスカッション。
次回に続きます。

雑談

明けましておめでとうございます。

ツチノコの親分です。
本年もどうぞよろしくお願いいたします。

昨年はあまり出番のなかった親分ですが、
今年はネタ専門で時々参加しようかなと思ってます。

さて、このブログですが、
社内においては、いかにバズるか?をモチベーションにありとあらゆる記事にチャレンジしていますが、
社外の方にもこのブログのアカウントを提供しております。

いろんなサイトからいろんな情報を頂いての今がありますので、
実は有用な情報で恩返しすることも重要なミッションだと思っています。
我々だけではなく皆さんの恩返しもお手伝いができれば、より良い場所になっていくと考えてますので、
そんな思いの方がいらっしゃいましたら、ぜひアカウントをリクエストしていただければと思います。

学生の方も大歓迎ですし、軽いネタでも大歓迎です。

そんな親分の昨年のオススメ軽ネタは

本当にあった怖い話 〜 Load Average編 〜

です。

ちなみに昨年の記事での親分のお気に入りは

技術書、それも売れるやつを書きたい人へ、編集者からのアドバイス

スタートアップのデータ処理・分析基盤、作るか、使うか

つながらない無線LAN!?(2/3) 調査編

でした。
※社外ツチノコさんの記事が二つですよ。

 

ということで、今年も宜しくお願い致します。

PAGE TOP