コラム, プログラミング, 趣味

はじめまして!バーテンツチノコ(仮) の近藤です。六本木のBARで、カクテル作れないバーテンダーをやる傍らで、夜な夜なプログラミングをしています。

人狼をみんなで集まってやる時、人間GM(ゲームマスター)の代わりに司会者をやってくれるLINE BOTを作りました。その名もとろろ人狼BOTです。

今日はそのBOTの紹介をしたいと思います。

 

 

 

使用イメージはこんな感じ

 

とろろ人狼BOTを友達登録し、代表者1名(以後、便宜上「GM」と表記)が「村」を準備し、参加者が集まったら開始合図を行います。

開始後は、会話をしつつ、各々がBOTとやりとりをしながらゲームを進行していきます。

 

ゲームの流れを順を追ってご紹介します。

1.友達登録すると、名前を聞かれるので答えます

2.左上の、「村を作成」をタップすると「村」を作成できるので、友達にQRコードを教えて参加してもらいます

※参加する側(うさぎさん)のLINE(先ほどとは別人物のLINEです)

3.人数を確認。こんな感じに5人集まりました

4.村を開始するとこんな感じ

村人3人、人狼1匹、占い師1人がいるそうです。自分(とろろ) は占い師でした。このメッセージは全員宛にアナウンスされます

 

~~ここから、実際には話し合いが始まります~~

うさぎ『ねこさんが人狼かな?』

ねこ『いや、ねずみさんじゃないかな』

ひつじ『そうかなあ』

ねずみ『うさぎは人間だと思うな』

~~~~~~~~~~~~~~~~~~~~~

(※話し合いは一例です。実際にはもっと殺伐とする可能性があります)

5. といった話し合いの結果、自分が人狼だと疑わしいと思ったうさぎさんに投票することにしましょう

6.皆の投票が済んだら、GMは「時間を進める」コマンドを使います。この時、未投票の人がいると警告が表示されます

うさぎさんが処刑されてしまいました。(※うさぎさんは、実は村人でした)

7.夜が来ます。夜の間は誰とも会話禁止で、各々が淡々と自分の能力を使います
自分(とろろ) は占い師なので、占い先をセットしましょう
ひつじさんを占いたいと思います

8.全員が能力をセットしたら、翌朝に時間を進めます

ねずみさんが人狼に殺されてしまいました。
占いの結果、ひつじさんは人狼だったので、他のメンバーにそれを伝え、ひつじさんへ票を入れてもらうように説得します。

9.投票を行い、時間を進める

10.決着

13393054_1144158248940477_1216561269_n

 

いかがでしたでしょうか。キャプチャを淡々と貼り付けただけの紹介でしたが、ゲームの流れは以上です。

★LINEがインストールさえされていればアプリインストール・ユーザ登録不要

★それぞれがBOTを通じてコマンド入力を行うので、自分の挙動を隠したりする必要がなく進行がスムーズ

★GMが不要になるので、全員で同じ情報量・立場でゲームに参加出来る

何度かテストプレイをしていますが、上記の点でたいへんご好評をいただいております!

 

とろろ人狼Bot(@tororo_jinro) というTwitterアカウントを作っております。

公開出来ると判断でき次第、LINE QRコードを公開しますので、良かったらフォローしてください(๑´ㅂ`๑)

 

ではでは

 

 

補足:GM用 チートシート

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

■ はじめまして

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実行委員会より寄稿させていただいたものになり、文責はすべて実行委員会にあります。

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 多重化によって、どのリソースがどのように消費されるかについて見てきました。
 ここでの内容によって、効果的にリソースを消費するサーバ実装の手助けになれば幸いです。

PAGE TOP