そろそろ自作サーバ同窓会についてひとこと言っておくか

だいじなこと

同窓会にはそんな人は居なかったのですが "自作サーバ" という手段を目的化してしまうのはNGですね。

兵站の件

自作サーバの是非を話すときには、そのサービスを成立させる価値の流れにマッチしておりサービスにどういうアドバンテージをもたらすのかという点をズラしてしまうと趣味トークにしかならないのでもったいないなと。
また、トークの中でも言いましたが、単にサーバを組み立てるだけの話ではなく、それらを計画して実行して運用して廃棄してまた新しいのに入れ替えて、という一連のシステムライフサイクルを回せるようにすることのほうが重要で、そこまでやりきることを要求されることは忘れないでいたいものですね。

最近はクラウドサービスの隆盛がめざましく、x86サーバも年々出荷台数が減りIBMがレノボへ事業売却というような件に象徴されるように、既に価値創造における直接的な差別化要因ではなくなりつつあるわけです。

というわけで本来の意味での "Logistics" を下敷きにしないで "自作サーバは楽しいです勉強になりますやったほうがいいです" という話をしてもサービスになんの付加価値ももたらさないわけで、そういうのはぜひ自身のおうちで、おこづかいの範囲でやってください。

え？ぼく個人的にどうかって？自作インフラたのしいです(^p^)

おわりに

id:stanaka さんならびに登壇者の皆様ありがとうございました。
各社各様で、様々な思いを聞くことができた良い機会であったと思います。

ただ、各社各様といいつつ "某100Sなんとか" で卒業するケースが多かったのは興味深い話でございました。

私からは以上です。

フリークアウトに転職して丸2年が経った

前職は3年弱で辞めたので、前職生活の2/3以上をすでにフリークアウトで過ごしたことになる。

最初から何でもやるつもりでjoinして、まずは下回りからサーバサイドのことをやってたんだけど、その時はサービスに対する危機意識が低かったと思う。大きいサービスを運用するのはやってきていたけどネット広告は初のことで、いざ入ってみるとソーシャルメディアとは全然違う。単にシステム規模ではなく、運用のシビアさとか、直接的に金銭に関わってくる度合いとか、そういうビジネス的な要求が高い。サービスとして緊張感をより高く持つ必要があると思った。

サービスの成長を支えてリードすべくガンガンインフラ業務を進めていくといろんな問題が起こることに気づいた。
例えば調達戦略。何を、どこから、いくらで、いつまでに調達して使えるようにするか。自前で基盤を作っていると、既に基盤部門のあった会社では見えていなかった問題がたくさん見えてくる。
サービス基盤は空気みたいなもので、問題がないときは意識されないけどひとたび問題が起こると、サービスの将来に深刻な問題を残す可能性も多分にある。
この辺りの基盤づくりについて誤ると中長期的にみればサービスの成長可能性を大きく下げてしまう。

自分はサービスの成長をサービス基盤要因で止めることがないように努めた。サービス基盤を成長にあわせて問題なく構築運用できるプロとして仕事をすることだ。
取り組んだ大きなトピックはふたつで、ひとつはサービス基盤の再構築、もうひとつはエンジニアが増えてもリリース速度と品質を落とさないための施策だ。

サービス基盤の再構築は2つのフェーズに別れる。まず最初は既存の自作サーバを中心としたサービス基盤の改善だ。
いちからインターネット回線を引いて、ケーブルの一本からすべてを調達してシステムを構築する経験は乏しかったが、過去に経験した中古PCを数十台使ったインフラでの知見を活かしてネットワークを構築することができた。
以前はカスケードしまくりで拡張が難しかったネットワークを改善して3倍くらいの規模にはできるようにした。この再構築の時に得た知見は良いことも悪いこともたくさんあるが今も業務に活きている。

しかしながらこの対応も長くはもたず、様々な要因があって次の大きな改善をすることになった。新たな基盤構築である。
サービスのパフォーマンスを損ね、拡張性に乏しいサービス基盤は事業の成長に著しくブレーキをかけることになる、しかしサービス開発エンジニアは全員が必ずしも基盤技術に長けているとは限らないし、そういった作業に当てる時間を作るとサービス開発の速度が落ちてしまう。そこでもう一段階上のサービス基盤構築を模索し始めた。
幸いにも多くの外部事業者の方とお話をさせていただくことができ、多くのインプットを得ることができた。
システムの移行も大きな問題はなく実施できた、クラウド全盛の時代にこのような仕事はそうそう発生するものではないし、そのような機会を数多く経験出来たことは得難い財産になっている。

そんなことをしているうちに、いつの間にか開発エンジニアがえらい勢いで増えた。
この時点でサービス基盤は安定して運用/拡張できるようになっていたし、インフラを担う仲間も増えたがそれを上回るペースで開発者が増えていたのだ。
当然書かれるコードの量も増えていたし、リリース頻度も多くなっていた。必然的にテストの量も内容も様々に増え、テストを通す時間も右肩上がりになる。
ある時必要があってコードに手を入れ、手元の環境でmake testをした時に30分ほどかかった時にとてもイラッとして、開発している人はこんなことをずっと我慢していたのかと思って改善に取り組むことにした。
その内容はYAPC::Asia 2013のトークに詳しいのでそちらを見ていただくとして、この取り組みによって幸いにもBest Talk Awards 2位をいただくことができた。

自分は事業に比較的早いタイミングでjoinしたことで、他ではできなかったであろう多くのことを経験することができた。
これは元から狙っていたことでもあったが、思った以上にいろいろできたので幸運でもあったと思う。

mirakuiさんのエントリにもあるが、急速に成長するサービスを運営するときには開発だけでなく基盤側にも積極性/創造性が多分に要求される。
基盤チームであってもコードを書かないということはありえないし、必要なものは積極的に書いている。
多くのことに取り組んできて実感を持っているのだけど、バックエンドだろうがUIだろうがAPIだろうが基盤だろうが、そこに境界はないと考えている。

フリークアウトでの3年目を迎えたけど、会社もサービスもこれからもっと盛り上がって行くし、やるべきこと、やりたいことがまだまだ山のようにあり、日々戦いを続けていてこれからも楽しみですね。
あとこれだけは言っておきたいんだけど、 フリークアウトはエンジニアを募集しております ！！！！！！！

あわせて読みたい：クックパッドに転職して丸2年が経った

MySQL::Sandboxのこと、時々でいいから思い出してあげてください #mysqlcasual

はじめに

かじゅある！
この記事はMySQL Casual Advent Calendar 2013 2日目の記事です。

カジュアル詐欺とかガチュアルとかいわれのない誹謗中傷を受けることの多いMySQL Casualですが、私はカジュアルな記事を書きます。
みんなも Casual に記事を書けばええんやでヽ(´ー｀)ノ

石狩DC記事の方もよろしくお願いします。

MySQLはもはや説明不要のRDBMSかと思いますが、"使える"ようになるためには情報収集もさることながお試し環境をカジュアルに作れるようにすることが重要です。
ということで、まだMySQL Casual Advent Calendarではネタに上がってないMySQL::Sandboxをカジュアルに紹介します。

MySQL::Sandbox はその名の通り手元にきれいかつ閉じた MySQL の検証環境を作れます。
複数台構成も簡単にできて大変便利です。

MySQL::Sandboxを動かす環境を作る

Perlが必要なので、plenvとかで環境をこさえましょう

$ plenv install 5.18.1
$ plenv global 5.18.1
$ plenv install-cpanm

MySQL::Sandboxをインストールする

cpanm時代なので簡単にインストールできます

$ plenv exec cpanm MySQL::Sandbox

Sandbox環境を作る

以降はMySQL::SandboxのSYNOPSISに詳しいわけですが、各動作環境用のMySQLのtarボールがあれば起動可能です。
下記は単独のサーバの構築です。とても簡単です。

$ mkdir $HOME/opt/mysql
$ cd $HOME/opt/mysql
$ wget どこかのサーバから取ってきたMySQL-VERSION.tar.gz
$ make_sandbox VERSION

接続や停止は下記の通り

$ sandboxes/msb_x_x_xx/use
$ sandboxes/msb_x_x_xx/stop
$ sandboxes/msb_x_x_xx/start
$ sandboxes/msb_x_x_xx/restart
$ sandboxes/msb_x_x_xx/send_kill

とりあえずここまで試して、再度作り直したいときは

$ sandboxes/msb_x_x_xx/clear
$ sbtool -o delete -source_dir $HOME/sandboxes/msb_x_x_xx

という感じでなかったことにできます。

更に進んだ使い方

make_replication_sandboxコマンドを使うと、複数サーバを立ち上げてレプリを作ってくれたりします。
クラスタを作って実験したいときには持ってこいな感じです。
さらに環境変数 MASTER_OPTIONS, SLAVE_OPTIONS に my.cnf を指定しておけばその設定で立ち上げてくれて cool ですね。

$ export MASTER_OPTIONS="--my_file=/path/to/my.cnf"
$ export SLAVE_OPTIONS="--my_file=/path/to/my_other.cnf"
$ make_replication_sandbox x.x.xx

このくらいできるようになると、カジュアルに新しいバージョンのMySQLが試せるし気に入らなければ虚空の彼方へ消し去ることもできるのでカジュアルでよろしいかと思います。
他にもレシピを見るといろいろとオプションがありますので、複数台構成やらを試したい方はご確認をば。

明日

MySQL Casual常連の @kamipo さんが12/3を担当します！お楽しみに！！

さくらインターネット #石狩DC 体験記

はい、行ってまいりました。さくらのDC@石狩。
ブログを書くまでが #石狩DC ということで、記憶がフレッシュなうちにまとめます。

謝辞

はじめに今回貴重な機会をいただきまして、さくらインターネット並びにはてなの担当者さま方に感謝申し上げます。
単に新しい/珍しいだけじゃなく、多くのレイヤーでさくらスタッフの皆様が "考えて動いて" いることを実感できるとても良いツアーでした。
インフラに関心がある人もまだない人もコレを見ずしては死ねないと思いました。

私なりに今回得てきたものをとりまとめて、今回のツアーを締めくくりたいと思います。

巡ってきたところ

今回拝見した棟

図の通り、2年前に開所した1号棟に続き、まもなくオープンする2号棟にもおじゃましてきました。

空調設備

このデータセンター、各所で報じられている通り空調に外気を取り込む仕組みが採用されており、実際にその設備の中身津々浦々を余すところなく見学出来ました。

外気の吸気

一番外にある吸気口は目の粗いフェンスが設置されており、野生動物などの侵入を防ぐ感じになっていました。

フィルタ

右の綿のようなものが手前のフィルタで大きめのホコリやらを防ぐ層、左が除塩フィルタで、先ほどのフェンスを抜けてきた空気はここからミキシングチャンバーに取り込まれます。

ミキシングチャンバー

写真はミキシングチャンバーの床にある吸気口で、ここの開き具合で外気をどの程度取り込むか調整できるようになっています。
ミキシングチャンバーはその名の通りサーバから排気された熱を外気と混ぜて適切な気温/湿度を作り出す部分で、季節に応じて取り込み具合を調整してサーバルーム内部に取り込む空気を作りだしている部分です。
見落としがちなのが加湿で、乾燥し過ぎると静電気が発生して機器がやられたりする点は要注意。
温度も低ければいいというものではない、というのはだいぶ前にこちらのエントリで挙げられていたとおり、この辺はさくら独自の制御プログラムでまかなっている様子でした。ｺﾞｲｽｰ

その他

冬場は降雪対策としてサーバからでた余剰の熱でロードヒーティングしたり、更には床暖房にも利用しているとのことで、至る所で熱効率が考えられた構成になっていました。

サーバルーム

吸排気の部分もさることながらサーバルームも開所から2年の間の進化が見て取れ、時間も予算もかかる設備周りもどんどんチャレンジしている姿勢が伝わるものでした。

全体的な特徴

一般的なデータセンターでは床を上げて、その空間を利用して配線したり冷気を送るようにしているところ、石狩DCでは床を上げずに配線は天井を利用し、冷気は壁or天井吹き出し方式を採用している点は他と異なる特徴かなと思います。
"冷気は上から下に、熱気は下から上に" という一般的な原理原則に沿ったやり方になっているなという印象です。

各ラックのフロント、リア、上部には温度センサーが付けられていて、全ラックの温度状況を一覧できるような仕組みが実装されていたのも大きな特徴かと思います。
さすがにここまで細かく計測しているDCは多くないのではと思います。
この辺りまで細かく見ているからこそ、後述のようにエアフローを変えて実際に検証して効果を測れるのだろうと。

更に、建物自体が2階建てと高さを取らず、面積を広く取る設計になっているため、動荷重はそれほど問題にならずラックにものをビシッと詰めてもOKとのこと。
後述の電源状況とあわせても、都心のDCではできないような高密度な設計ができそうで夢が広がるポイントですね。

Aゾーン/Bゾーン

AゾーンとBゾーンではラック上部にファンとダクトが付けられており、フロア全体に冷気を行き渡らせ、ラック上部で吸気する形になっていました。
正直なところ、ラックごとにダクトを付けるやり方だとダクト部分とそこに搭載するファンが特注っぽくなってコスト高な上にラック上部のサーバに熱がたまるんじゃないかなという印象でした。

Cゾーン

一方Cゾーンでは各ラックにダクトを付けるのではなく、熱気を囲い込んで天井につけた大きなファンで排気する方式に変わっていました。
他のデータセンターでも最近のフロアではよく見るアイルキャッピングのような感じです。
10月の記事で触れられている通り、実際に方式を変えて試した結果この方式に落ち着いたようです。

これからサーバルームが作られる予定の2号棟もこの方式で作っていくということなので、空調効率はA/Bゾーンの方式よりもCの方式のほうがアドバンテージが大きいということが伺えます。

余談ですが新しいサーバルームの電源やらの検証のために、ラックにたくさんのドライヤーを吊るしていたのが印象的でした。
確かにサーバとドライヤーは近いものがある。。(多くの電気を食って熱を吐く的な意味で)

電源設備

見学したところの話

普段はコンセントバーやサーバの電源モジュールくらいしか馴染みがないので、高圧電気室や発電機室はいろいろと圧巻でした。
特に圧巻なのはズラリと並ぶディーゼル発電機。

機関車の車庫みたいな絵面。。
こういう大きなディーゼル発電機は都心のデータセンターでは騒音や重量の問題で利用されず、ガスタービン発電機が採用されることが一般的ですが、さすが広大な石狩の土地を活かした展開だなと。

ラックあたりの標準提供電源容量も大きく、8kVA(最大15kVA)と、都心のDC比で2倍～3倍も供給可能というふとっぱら。
この設計もSandyBridge時代の設計で、IvyBridgeに変えたら3割くらい消費電力が下がってくるケースもあるため、石狩DCは他ではあまり見られない "電気余り" な状況とのこと。
ここまで来るとラックあたりをもっと高密度にしたくなってくるわけですが、そこは先ほどのラック周りで述べたとおり、ラックも床面も十分な耐荷重なので思い切って詰めても大丈夫そう。

一部フロアでは直流送電の設備が置かれており、一般的な100Vではなく、230Vで送電していました。
230Vでの電源供給については自分も以前検討したことがあり、電源設備の都合上コスト高になる&ネットワーク機器が対応していないものが多いため断念した過去があります。
石狩DCでは "それ用" に設計されているところが自社ですべてやれる利点を活かせているなと感じます。

先の空調の話と合わせて、見学で回った際に見たPUEは1.08と、世界的にもトップクラスの電源効率をたたき出していました。

更に聞いた将来の話

石狩DCのパンフレットにも書いてあるのですが、近く石狩DCの近所に太陽光発電所を作る計画があるそうです。
そこから超電導直流送電技術を使って電圧変換を一切使わずにDC内の電源設備まで電気を供給するような実証試験を行うということで、更にエコな世界に行きそうな気配です。
広大な土地に多くの給電方法が合わさることで、通常ではできないようなラック構成ができたり、電力調達の効率が上がってサービスが良くなったりしていくことを期待しております。

ネットワーク

石狩 <-> 東京のレイテンシはだいたい10ms強で、50ms or die.的な観点からは結構大きいレイテンシですが、通常のWebサービスでは無視できる向きもあるのではと思います。
冗長構成については、実際現地で説明を聞いて、他の地方にはさほど引けをとらない良環境であることも改めて確認できました。

インターネット回線

さくらインターネットはバックボーンの接続状況を自社のサイトで公開しているので詳しい話はこのへんを見ていただくとして、このページにはない回線としてOCN北海道の回線が入っているとのこと。
また、今後更に接続キャリアを増やす予定もあるようなので、インターネット回線の対障害性は向上していく方向のよう。

個人的に気になったのは、現地の回線を使っても石狩DCへの通信が東京経由になるケースがあったりすること。
一見物理的に近いように見えても、実は遠回りしてしまうと思ったようなレイテンシが出ないので、このあたりは今後自分が選定する場合の注意点として覚えておきたいところです。

DC内部の回線

DC内部の回線が切れるようなことが発生すると復旧に時間もかかるため、うかつにクロスしていたりするところでファイバーカットが起こったりすると深刻な障害になり、サービスが受けるダメージたるや考えるとお腹痛くなってきます。。
石狩DCはMDF室が2つあり、それぞれ違う経路で地下埋設した回線を引き込み、構内ではそれぞれの回線がクロスすることがないように設置されている頼もしい構成でした。
自分で回線を引く設計をする際にはゆめゆめ気をつけたいポイントですね。。

サービス運用周り

サーバ本体へのオペレーションの効率/安全性の追求

自社サービスで、サーバの役割が把握出来ているならオペレータの判断で作業を進めてもいいかもしれませんが、顧客にサーバを提供している場合この作業には一層の注意が求められることは想像にかたくありません。
IPMI全盛の時代でも、最後の最後はサーバの目の前でないとできない作業が発生することはなくなりません。
声出しや指差しはよくある確認方法ですが、今回紹介されたオペレーションの中で興味をひかれたのは、テレカンのシステムを使った遠隔地でのダブルチェック体制でした。
現地のスタッフ以外でも対応可能なように範囲を広げれば、ダブルチェック体制を保ちやすいという良いインプットを得られました。

スタッフの意見で設備改善

搬入経路の非効率なところや、規模の拡大に伴ってスケールしにくいところは新たな棟で積極的に潰している点はフットワーク軽くとても良いと思った点です。
一気に全部の建物を作らずに、モジュール化を進めるやり方を採用している利点を最大限活かした作りになっていました。
残りの6棟がどこまで進化していくか、今後もウォッチし続けたいところです。

ほかにも

試される大地の試されるデータセンター

さくらインターネットの石狩DCは、固定化されたオペレーションを淡々とこなす場所ではなく、常にチャレンジングな取り組みを続けるエッジの効いたテクノロジーの塊でした。
帰りの道すがらでさくらのスタッフさんが「今後規模が大きくなるにしたがって、単に人を多くするだけでは回らなくなるのでここから先さらに技術開発が必要になる」といったことを言っていたので、まだまだ進化していく余地が沢山ありそうで残り6棟がどのように進化していくのかとても楽しみです。

田中社長の話

以前モリスさんが書いていたけども、すごい方でした。
技術的な話については↑のエントリに譲るとして、それ以外にも驚かされたことが幾つかあります。

1日目の懇親会で話した時は、商売的/営業的なことについて話をしてもそんじょそこらの営業よりよどみなく話していて、さすがと思っていた。
思っていたら2日目のオプショナルツアーであちこち回っていた時には石狩や周辺地域の歴史的な話や地元の産業、さらにはそれら地場産業と石狩DCの関係についても自身の言葉で誰かにフォローされることなく話をしており、真の意味で上から下まで深く理解している段違いの方であることがよく理解できました。

さくらインターネット伝説は伊達じゃない。

おわりに

石狩DCツアーは、普段データセンターに馴染みのある人はもちろん、ない人ほど得られるものが多い素晴らしいイベントになるだろうと感じてます。
次回がもしあるようであれば、普段ソフトウェア周りをやっている人、AWSのようなIaaSがメインだという方も臆せず応募することを薦めます。

エンジニアとして、見ずして過ごすのはもったいないのでこういう機会が広まるとよいなと願っております。

重ねて、田中社長はじめさくらインターネットの皆様、並びにはてなの担当者様に感謝申し上げて私の #石狩DC を締めさせていただきます。
ありがとうございました。

ISUCON3 本戦参加報告

引き続きチーム「50ms or die.」で本戦に参加してきました。

謝辞

はじめに運営の皆様、出題の @fujiwara さん、サーバ提供のデータホテルさまには予選含め、限られた時間でいろいろ絞り出して戦うという、とても得難い機会を頂けたことを感謝申し上げます。

結果

1800なんぼでfailという結果に終わりました。いわゆる「die.」です。
スコアレスでdieしてしまった前回よりはマシだけど、結果に結びつかなかった点は反省して次に繋げたい。

ただ、前回のような絶望感はなく、いかに時間内にやり切るかという挑戦ができたのでとても充実した時間になりました、この点は自身進歩したなと感じてます。

詳細はチームの @__kan さんや @bonnu も書いてくれると思いますが、私も覚えている限り何を思って取り組んだかといったあたりはまとめておきます。

やったことのまとめ

• プロファイリング

@bonnu さんに Devel::NYTProf を使ってどういうところが問題になりそうか調べてもらいました。
結果としてコード読んだらすぐわかるconvertまわり以外は特に何もなかったという結論に。。

• DB の slowlog チェック

コード読んだら join したりサブクエリ発行してたりする所があったのでこの辺怪しいかもと思って slowlog 出したり explain して確認したけど、まったくボトルネックではなかった。。

• 課題解決へのアプローチ

DBもアプリもボトルネックではないので、配信をスケールさせること、という認識は昼までのプロファイリングやslowlogを見てわかったので、まず1台で高速化し、その後スケールアウトさせるアプローチを考えました。

• 時間内に出来た実装

複数台でリクエストを受付、投稿された画像がどのサーバに入っているかをDBに入れておき、reploxyするという戦略で実装していきました。
が、最初の「1台で速くする」というアプローチを引きずり、初期データの収容先を1台に集中させてしまったため、そのサーバがサチる状況になっていたのは明らかにミスでした。
これを解消するために初期データを散らそうと対応を始めた所でタイムアップして終了でした。

当日までの流れ

以降は上記にまとめた内容がどんな流れで進んでいったかという記録です。

前日まで

予選の反省を踏まえて、できるだけ即手を入れていくのではなく、素の状態からボトルネックを列挙して優先度つけて潰していこう的な方針を確認しつつ、事前に「まずやること分担」を決めた。

• サーバのログイン環境/nginx化/nginxのログ/mysqldumpslowをdocrootにおいちゃう対応: myfinder
• 一発デプロイ/データクリーンアップ対応: kan
• NYTProf等のプロファイリング対応: bonnu

あとgithubにprivate repoを作ってwikiを使えるようにしたりなどはしておいた。

当日の昼まで

奥の会議室が確保でき、他のチームを気にせず喋れたのでチャットログはほとんど残っていないけど、プロファイリングを取ったりslowlogを確認したりをまず進めた。

結果的にプロファイル見てもslowlog見ても問題になりそうなのがsystem関数呼んで変換しているところが圧倒的すぎたし、DBのデータサイズも大したことがなかったのでこのへんは全くボトルネックにならないということはすぐにわかった。

なので、この時点で「帯域小さいからスケールアウトさせて、サーバ間での画像共有どうするか」に問題を絞って構成を皆で考えて進めればよかったのだが、1台で速くするという所をすぐ捨て去ることができなかった。

当日の昼以降

1台ではどう頑張ってもアレ以上行かないね〜となったタイミングで、複数台化に取りかかりはじめた。これが15時〜16時頃だった記憶。
複数台でリクエストを受付、投稿された画像がどのサーバに入っているかをDBに入れておき、reploxyするという戦略を取るつもりだった。
時間内にできた実装では、初期画像のリクエストがすべて1台に集中し、その1台が帯域を食いつぶしてスループットが上がらないという問題を抱えていた。
初期画像はすべてのサーバに置いていたので、すべてのサーバで初期画像の保持を分散させておけばよかったわけだが、この時点で残り30分だったため、あがいたけど結局間に合わなかった。

構成変更の判断が遅かったため、大きくスコアを伸ばすところに至らず時間切れという結果に。

おわりに

DB設計変更、アプリケーションの書き換えやMySQLのチューニングが今までの主戦場だった所から、今回は大幅に変わった点は脱帽で、 @fujiwara++ でした。
まさに総合力勝負だったと思います、引き続きこの戦いを生き抜けるよう研鑽に励みたいと思っております。

MySQL Casual Talks vol.5 開催報告

先日MySQL Casualやりまして、登壇者の皆様ありがとうございました。
今回も非常に和やかでカジュアルな雰囲気の中でイベントが平和裏に終わり大変良かったと思います。

さて、イベント中に参加者アンケートを取らせてもらったので、その報告をいたします。

参加者80-90名くらい？に対して有効回答25を頂きました。
2割超が回答してくれたのでまぁ回答率はそんなものだと思って以降の内容をご覧ください。

何度目の参加ですか？

1. 初参加: 9
2. 2回以上: 16 (うち2回目が10)

何気に初参加の方が多く、2回目という方も多かったようです。

開催方式の是非

1. 良い: 20
2. 開催方式とかどうでもいい: 5

"悪い"を選択した方はいらっしゃいませんでしたが、ご意見に"良し悪し"を追加して欲しいというものがありました、皆さん遠慮せずに悪いを選んで意見をいただいてもよかったのに。。。
まぁちゃんと来る人にとっては開催方式なんてどうでもいい話なので、これにワザワザ回答頂けるくらいきっちりした方には愚問だったかもしれません。
とはいえ、おおむね好評価のようでした。
最近Oracleさんが入館しやすくなり、方式との相性も良い感じだと思ったので、次があるなら変えずにやっていこうと思います。

次回登壇して欲しい人

1. @kazeburo さん: 2
2. @sh2nd さん: 1
3. @nippondanji さん: 1
4. @matsunobu さん: 1
5. @tagomoris さん: 1
6. @frsyuki‎ さん: 1

名前が上がった方は @frsyuki さん以外1回以上登壇いただいてる方ですが、ネタがあれば何度でもご登壇いただけると幸いです。
というか MySQL Casual で @frsyuki さんはだいぶ異色の取り合わせな気がしますね、そんな希望もありましたよということで報告させていただきます。

今後聞きたいテーマ

1. MariaDB: 5
2. MySQL vs MariaDB: 1
3. MySQLの運用: 1
4. MySQLのDev寄りのトーク: 1
5. Labsの詳しい所: 1
6. mroongaの実践: 1
7. MySQLを動かしているハードウェアまわり: 1
8. percona toolkit: 1
9. percona XtraDB Cluster: 1
10. パフォチュー: 1
11. オプティマイザやメモリアロケータ変更まわり: 1

みんな MariaDB 気になってるんですね〜
もう誰か MariaDB Casual Talks やればいいと思うよ。

おわりに

ということで前回今回と事前登録不要/先着順受付で開催してみたわけですが、人があぶれることもなく、時間通りに来た人はちゃんと入れたので、人の入りにお悩みの方はこのやり方でイベントやればいいんじゃないと改めて実感しております。
疑問質問などあれば @myfinder までいただければと。

それでは。

WEB+DB PRESS Vol.77 Perl Hackers Hub に寄稿しました

今月発売の WEB+DB PRESS でやっている Perl リレー連載に記事を書きました。

内容は YAPC::Asia 2013 でトークしたテスト関係の話題。
基本的なテストからCI、更には高速化についてまでをまとめていますので、読んでいただければと思います。

WEB+DB PRESS Vol.77

この記事を書いていて「そういえば Perl アプリケーションの基本的なテストについてまとまった記事ってなかったよな〜」とおもったので、これから本格的に Perl アプリケーションを書いていく方には前半の基本的なテスト部分が特におすすめです。

その他気になるトピックとして「スマートフォンテスト最前線」という特集があります。
スマートフォン広告におけるRTBもようやく本格化してきて、Web面だけでなくアプリ面が出てきたり、そのバリエーションも増えています。
今後、デバイスが増えてきてもリリースサイクルを早く、クオリティを高くしていくためにもこの辺りは引き続きアンテナをはっていきたいところです。

あわせて読みたい

Perl徹底攻略 (WEB+DB PRESS plus)