YAPC::Asia 2014に行ってきた＆しゃべってきた
みなさんご存知のYAPC::Asiaに出したtalk提案が採択されたので、スピーカーとして参加してきた。スケジュールを見たら2日目の一番最後の枠(LTの直前)で、なんと初めてのホールでのtalk。
1日目午後は会社でお仕事上の用事があったので参加できず、2日目朝は前日夜に死ぬほど飲んでいたので動けず、2日目午後は自分のtalk前で気もそぞろ……という感じで聞く側としてはアレだったけど、いろんな人が会場にいていろいろ話したし、面白かった。
しゃべってきた
"Handling not so big data." というタイトルで、今現在における分散データ処理プラットフォームの世界はどうなっておるのか、ということをざっと概観しつつ、そういう仕事に踏み込むときには何が重要なのかについて少し話した。
分散データ処理についての話だけど、上でどんなロジックを動かしているか、データ実体の中身はどのようなものかを言わなくても語れる重要なことは山ほどあって、自分が最近あちこちで話をしているのはそれがものすごく大きいと思うんだけど、自分に限らず他の人ももっとそのメリットを活かしましょう、というのが最後のページの話でした。ちょっと時間足りなすぎて焦ってて、わかりにくい表現になってたかもしれないと後で思った。
スライド作ってみたら明らかに20分に収まらない感じでどうしようかと。だけど削れるような場所も無く、やべーどうしようと思った結果、図を増やして少しわかりやすくしつつ20分間耐久LTを行うという暴挙に出た。他のカンファレンスだったら顰蹙モノだけどYAPC::AsiaならLTで鍛えられているし大丈夫なはず！
で、やってみたところ、そこまで文句もなかったのかなということで、良かった良かった。
というか、ベストトーク賞2位をいただきました。びびった。ものすごく嬉しかったです。ありがとうございました！
で
喉がぶっこわれて声が出なくなりました。
さて
次は9月13日に台湾のHadoopConでがっつりとHadoopやNorikraやその他の話をしてきます。2週間先と思ってたけど、そうか、来週末か。英語……。
あとgcp ja night 28でBigQueryとFluentdをネタに適当な話をビール飲みながらやりますが、こちら、申し込みが定員をはるかにぶっちぎっておりますね。すごい。台湾の直後なんでいつ準備しようというのが目下の悩みどころです。
更にその直後にRubyKaigiがありますね。行く予定です。
更にその翌週にISUCON予選がありますね。どうするんだこれ。
YAPC::Asia 2014で分散データ処理技術についてしゃべります
もう今夜が前夜祭ですね。YAPC::Asiaの季節になりました。
で、どうしようかなーと思ったんですが、Webサービスの中の人も多いYAPC::Asiaだからきっと需要があるだろうということで、話には聞くがあまりキャッチアップできていなさそうな最近の分散データ処理技術の概要とか現状について、ざっくりと話します。
そんなにビッグでもないデータ処理手法の話 - YAPC::Asia Tokyo 2014
どういう問題意識があってそのためにこういうパラダイムやミドルウェアが最近はあって、ということを簡単に総覧していくような初心者向けのものです。あまり個々の技術の詳細には踏み込みませんが、全体的なトレンドがどうなっているかは分かるかな、後で必要なときに調べるとっかかりになるかな、という内容にはできると思います。
最近ビッグデータとか聞くけどどうなの、とか、なんかデータ解析やろうかなと思うんだけど何を使えばええんや、とか、そういう人に超オススメです。お楽しみに。
YAPC::Asia 2014でぼくとあくしゅ！！！
Reverse Proxyがなぜ必要か、勝手に補遺
「全体のリソース効率を上げましょう」というためのものである。
Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー
これは完璧に正しくて、ただ「リソース効率」という概念はあまり具体的な想像が追い付かない人がいそうだなと思ったので、ちょっとだけ補足しようと思った。
Reverse Proxyを入れることでリソース効率の向上を狙うんだけど、それは以下のような複数の場面におけるそれぞれのリソース効率向上を複合的に狙うものだ。
- 通常時のトラフィック配信におけるCPU・メモリ使用率を最適化する
- バースト時(過負荷時)のトラフィックをより細かく制御可能とする
- 障害時におけるダウンタイムおよび総合的な計算・配信能力の低下を極小化する
- 多数のサーバによる構成全体を増強・入れ替え・移動あるいは削減する際の自由度の向上を狙う
簡単にコンピュータの性能だけで言うと最初の項目だけをリソース効率の向上ととらえてしまいがちだ。
が、Webサービスが大規模になるとその裏側のサーバクラスタにおいては常に構成変更・障害・局所的過負荷などが起きており、そういった事態への対処というものを折り込んで全体のリソース使用状況を最適化する必要がある。
こういった状況において制御可能なポイントを増やしておく*1と、何かあったときの対処が非常にやりやすい。密結合のハイパフォーマンスサーバソフトウェアひとつよりも、疎結合のそこそこパフォーマンスサーバソフトウェアいくつもの組合せの方が、最終的に高稼働率・高スループット・低コストな環境を作りやすいのだ。
ということで、Webサービス*2が大規模化することを念頭に置くと、こういったことを考える必要がある。
逆に、用途や状況が限定されたケースであれば、こういったセオリーを無視した手が打てるケースもある。銀の弾丸は無いので、自分がいる状況、払えるコスト、世の中にある選択肢*3、そういったものを勘案して最適な手を選択したいものだ。
ということで
みんなもISUCONに出てそういうことを学ぶといいね！ お前らの挑戦を待っているぜ！！！ かかってこいや！
HadoopCon2014 in 台湾で発表しますのお知らせ
CFPが出ていたのでえいやと応募してみたところ、キーノートおよび一般セッションの両方で話すことになりました。50分ずつです。英語。しぬ。
今回もLINE株式会社に旅費等出してもらえそうなので、とりあえず行って頑張ってしゃべってまいります。
ひとつ目はバッチ処理とストリーム処理およびその組合せとしてのLambda architectureについて、この前のHadoop Conference Japan 2014でもしゃべった内容をもうちょっと丁寧にやることになるかなと思います。
ふたつ目はたぶんNorikraの宣伝をがっつり。とはいえ(日本語で出ている内容に較べては)新しい内容はないかもしれませんが、この前 LINE Developer blog に出た内容なんかはちょっとしゃべるかもしれません。
他のスピーカーを見るとAcerとかTrend Microとかあるのが台湾っぽくて素敵ですねえ。
みなさんも興味があれば参加するといいと思います！*1 台湾近いし！ 台湾でぼくとあくしゅ！
*1:まだ参加応募フォームなさそうなのが気になる……。
uuidtools gemの新版がリリースされました
https://rubygems.org/gems/uuidtools
uuidtoolsという便利なgemがありましてその名の通りuuidの生成に使えるものでしたが、その機能のうちMACアドレスからuuidを生成するという部分がifconfig外部コマンドに依存していました。
で、みなさんご存知の通りRHEL/CentOS 7ではこのifconfigコマンドが標準でインストールされなくなり、正常に動作しなくなりました。これに伴った修正がuuidtools gemでも行われましたが、長くリリースされない状況でした。
https://github.com/sporkmonger/uuidtools/issues/24
が、先日無事リリースされたため、みなさんアップデートしましょう、自分で作っているgemがuuidtools依存しているなら 2.1.5 以降に依存するよう変更しましょう、ということです。
みんな大好きFluentd関連で言いますと拙作 fluent-mixin-config-placeholders が uuidtools に依存しています。先程このgemを uuidtools 2.1.5 以降に依存するよう修正した 0.3.0 をリリースしました。
Fluentd pluginを作っており fluent-mixin-config-placeholders という名前に聞き覚えのあるみなさんは是非依存関係の更新にひと手間割いていただければと思います。
こちらからは以上です。(絶賛アップデート祭なう……。)
NATやファイアウォールの向こうへデータをお届けする fluent-plugin-pull_forward を書いた
Fluentdにおけるネットワークごしデータ転送プラグインといえば forward が組み込みであるし、通信路を暗号化したければ secure-forward がある。
しかしこれらFluentdのネットワーク転送プラグインは基本的に全て送信元から送信先に対してプッシュする形になっており、ネットワーク接続も送信元から送信先に対して行うことになっている。このため送信先のFluentdがNAT下にある場合やファイアウォールで保護された場所にある場合、もしくはダイヤルアップ接続……は、まあ今は無いだろうけど、例えば移動するデバイス上にある場合など、こういったときにはうまくデータの転送を行う構成がとれない。
なぜこういう状況、つまりプッシュ型で転送を行うプラグインばかりなのかというと、FluentdのBuffer pluginの仕組みによる。細かく設計上の話をあれこれしてもアレだし面倒くさいので省くが。
という状況なのはわかっていたんだけどまあ自分に用途ないしいいか、と思って放置していたのだが、色々あって自宅(NAT下)でFluentd立ててそこに向けてデータ送りたいなー、という用途が発生してしまった。
fluent-plugin-pull_forward および fluent-plugin-buffer-pullpool つくった
用途が発生してしまったからにはしょうがないので、趣味プロダクトの一環ということで作った。まだ自宅で使いはじめてないんだけど、動く……はず。
コードはこちら。
https://github.com/tagomoris/fluent-plugin-pull_forward
https://github.com/tagomoris/fluent-plugin-buffer-pullpool
ということで、これを使えばオフィス内のマシンとかけっこう電源落としたりする自宅サーバにもFluentdごしにデータを転送できる！ やった！ 便利！
しかもプロトコルは HTTPS + Basic認証 + JSON なので、実は受け取り側はFluentdである必要すらなく、HTTPSのリクエストを発行できるあらゆるクライアントはFluentdからイベントデータをJSONで好きなタイミングにフェッチできる。なんて便利なんだ！
このためにデータのflush(の実質的な処理)をpull型でできるようにするためのハックを加えたbuffer pluginも作った。対応したAPIをもったBufferedOutput pluginからのみ使用できる*1。
注意点としては、フェッチされる前のデータは当然だがFluentdが起動しているノードにファイルとして残り続ける。なので buffer_chunk_limit および buffer_queue_limit の設定および空きディスク容量には注意が必要。あんまり高スループットな環境で使うものではないです。
ということで
実は割と刺さる人がいるのではないかと思います。みなさまぜひご利用ください。
DISられないUIを作るために最低限守るべき5つの鉄則
ぼくらが迂闊にUIを作ると、そこにはユーザの正直な目線があり、非常に様々な、そして真っ当な反応がある。
曰く「わからん」「まさかそこをクリックするとは」「不思議な動作」「独自宇宙」「モリスUI」。
反応がもらえるのは非常に良いことだが、何度も何度も繰り返しているとつらくなってくるので、できれば避けたい。分かっている(いた)ことは最初から対応しておきたいものだ。*1
ということで、ここではブラウザで操作する管理画面等のWebUIを作るとき、真っ先に心得ておくべき5つの鉄則を紹介したい。これを守っていてもDISられなくなるというわけではないが、これを守らないと間違いなくDISられるので注意しよう。
なおこの記事ではオリジナリティというものについては考慮しない。オリジナリティとか犬に食わせろ。
クリックできる場所はcursor:pointerを指定しろ
これを忘れるとこの世のものとは思えないくらい壮絶にDISられるので注意しよう。例えば以下の箇所はクリックできるか否か。
できる。できてしまうんだ。本当にすまんかった。今では反省している。
普通の人はマウスカーソルが変わらないとその場所はクリックできるとは認識しない。もう何はともあれこうしておこう。超大事。
これで全ての問題が解決するわけではないが、それはそれ、これはこれ。
トグルスイッチの状態をボタン色のみで表すな
あなたの前にこのボタンがひとつだけある、としよう。果たしてこのクエリは現在、実行される状態だろうか、停止されている状態だろうか。押すとどうなるだろう？
ということで、わからん、と言われないために、とりあえずこうしてみる。
これなら青が押されてるっぽいし、赤を押せそうだ。んで一応、赤を押したときには更に説明をダメ押ししておく。
ここまでやれば、まあ分からない人がいたとしても、きっと努力は認めてもらえるはずだ。有効/無効であれば、無効アイテムの背景をグレーアウトするのもたぶん効果がある。
使えるならこういうのがいい。いろいろライブラリとかあるはず。アニメーションはどうかと思うが、世間の常識に乗っておくのは大事。
クリックしたら何か反応を出せ
画面のどこかをクリックしたとき、裏側で何かの状態が変わっており、そのアイテムが選択されている、みたいなやつ。ダメゼッタイ。わからん。
ダイアログを出すでも画面のどこかでアイテムがぷるぷる震えるでもいいので、反応を出そう。画面に出ないで何かやるのはダメだ。
いやぷるぷる震えるのは多分ダメだ。考え直せ。
コピペは全選択でやれ
前のにかぶるが。ボタンをクリックすると情報がクリップボードにコピーされるというやつ、あれは超ムズい。ZeroClipboardみたいなのを使ってうまくやる方法をつい考えたくなるが、あれも本当にクリップボードに入ったかどうかを確認する手段がユーザにない。
あとFlashがフォーカスを奪う。GitHubのリポジトリURLのコピペボタン、あれのことだ。あれをクリックするとその後なぜかキーボード操作がうまく働かないという経験があなたにもあるはずだ。
コピペはもう面倒だからTextareaをポップアップさせ、その中身にコピペしたいテキストを放り込んで全選択状態にしとけ。そしたらユーザが勝手に Ctrl-C する。そのくらいのリテラシーはユーザに期待しよう。わかりやすいし。どのブラウザでも動くし。
最後に: 暗い背景にしとけ！
正確には、管理画面系なら白背景にしとけ。グレーアウトでdisabledとかが示しやすくなるから。
モニタリング系なら暗い背景にしとけ。つまりこういうやつだ。Kibana3は格好よさが全てだ。
同じKibana3でも白背景だとこうなる。これはいかん。いやいいと言う人はいるだろうが、というか自分は実はモニタリング系でも白背景のほうが好きだが、世の中の人は暗い背景というだけで(以下省略
いいか、モニタリング系の画面を作りたいなら悪いことは言わないから暗い背景にしておけ。
最後に
お前の作ったアレはいまだに上記の鉄則が守られてないじゃねえか！ というあなた。
そういうことも世の中にはある。
*1:もちろんそれができないから何度もDISられてるんだけど……。
