まいんだーのはてなブログ

はてブなのはてブロなのどっちなの

ソフトウェアエンジニアだけでサービス運用できる環境を作って失業した話

はじめに

このエントリは非常にポジティブで技術的なチャレンジに関するまとめであり求人エントリでもあります。

まとめ

昨年後半から、急成長するサービスを支えるため “どオンプレ” な環境で作ったサービスをクラウドに持っていく仕事をしていました。

クラウドのオイシイところを押さえられるよう作り変えをした結果として “Infrastructure as Code” を実践することになり、結果としてソフトウェアエンジニアだけですべてがコントロール出来る状態になり、インフラおじさん業が不要になりました。

そういった環境で働きたい "腕の立つITエンジニア(特にスマホとサーバサイド)" を募集しています。

発表資料&箇条書きで振り返る最近の動き

AWS Casual Talks #3

  • https://github.com/myfinder/aws-casual-3/blob/master/slide.md
  • クラウドに移すことを決めて、opsリポジトリを作って色々まとめ始めた頃
  • この頃はまだAutoScalingとかやってなかった
  • 毎度インスタンスを差し替えるのではなく、Ansibleで継続的にconfigを更新するやり方をしていた
  • ログ集計をオンプレのHiveから、Redshift or BigQueryどっちでやるかを検討していた時期
  • セットアップが面倒なものをDockerで運用したら楽になるんじゃと思って使い始めたのもこの頃
  • 実際Docker使うと楽になった

AWS Advanced Users Meetup vol.2

  • https://github.com/myfinder/aws-advanced-users-meetup-2/blob/master/slide.md
  • このタイミングから、Ansibleを継続適用するのをやめ、イミュータブル方向に一気にかじを切った
  • デプロイを種サーバからでなくS3から行うようにしたのもこの頃
  • AutoScaling対応をして、弾力的なアプリサーバの運用ができるようになった
  • 結果として、いわゆる “Infrastructure as Code” を実践することになった
  • Mackerelの威力を思い知った
  • この時注意していたのは “必要以上にクラウド側特有の機能に頼らない(学習を必要としないようにする)” ということ、これが後々、別のソフトウェアエンジニアへの情報共有で重要なポイントになった

Mackerel Meetup #3 と Monitoring Casual Talks #7

  • https://github.com/myfinder/mackerel-meetup-3/blob/master/slide.md
  • ここでこれまでの総まとめ的な発表をした
  • モニカジ7では “インフラエンジニアが死んだ” というタイトルで失業した話をした
  • この頃には今までやらなくてはいけなかった仕事の大半がなくなった
  • この後は細かいチューニングやら、ちょっとイケてない部分や余計な手順を省く仕事をしていた

直近の改善

  • Dockerコンテナでデプロイしていた諸々をすべてPacker->AMIという形に変え、Dockerを使うのをやめた
  • この方がすべてのコンポーネントをソフトウェアエンジニアが把握しやすいというのが理由
  • DockerコンテナもPackerから作ることができるので、最初からDockerでやるよりも汎用的だし未来の可能性を狭めない
  • packer build時にServerspecを使って、セットアップ状況をチェックできるようにした
  • ピークとそうでない時のトラフィック差が大きいサーバは Spot Instance 使うようにしてコストを大幅に引き下げた
  • AutoScalingが走っている時にdeployすると、タイミングによっては古いコードのままサービス投入されてしまう問題があったのでデプロイロック機構を入れる
  • 更に増えていく機能やデータをうまいこと扱うため、DynamoDBとその周辺ツールセットの検証と引き継ぎ

結果

  • “どオンプレ” だった環境が下記のような技術要素に置き換わり、スケーラブルで、かつソフトウェアエンジニアだけでコントロール可能で柔軟さと機動力をあわせ持ったシステムに生まれ変わった
  • サービス監視/インスタンス管理をMackerelで
  • インスタンスのセットアップやAMI作成をPackerで
  • セットアップ状況の保証をServerspecで
  • トラフィックが上下する部分はAutoScalingで
  • 量の多いログ集計はBigQueryで
  • ほとんどコードで管理できるようになり、新しい取り組みにソフトウェアエンジニアがチャレンジしやすい環境ができた
  • かくしてインフラおじさんとしてやっていた仕事をおよそ無くすことができ、更に運用コストも大幅に減らすことができ、私は堂々失業することになったのだった

とても大事なお知らせ

このエントリにある取り組みをしたエム・ティー・バーン社のAppDavisというサービスはいま絶賛成長中であり、機能開発がとても活発です。

↑に書いたようなチャレンジにも大いに理解のあるチームで開発をしたい ”腕の立つITエンジニア(特にスマホとサーバサイド)” を募集しています。

ご興味、ご関心を持っていただけた方は気軽に 社長 に声をかけるか、 こちらのフォーム から "エム・ティー・バーンの話を聞かせろ" と送ると良いでしょう。

www.fout.co.jp

おわりに

丸2年エントリでも書いたことですが、自分がこれまで取り組んできたことで重要な点は “開発/運用の品質/スループットを上げつつコストや納期を勘案して、サービス展開の可能性を最大化する” ということだったように思います。

今回のチャレンジでは、振り返ってみると意識していた原則が2つあって "何か新しいものを1つ入れるときは既存の何かを2つ以上減らせること” "ボトルネック以外触らない" というもので、それが結果として自分の仕事を無くすことにつながっていったわけです。

そういうわけで、今後はもっと違うことにチャレンジしていこうと思っております。今後とも何卒よろしくお願い致します。

今年出たもののまとめ

まとめ

  • 前半は "どオンプレ、ちょっとだけクラウド" をずっとやっていたが、後半はその自分で作ってきた "どオンプレ" からクラウドに移す仕事をしておりました。
  • 来年はもっと違うことにチャレンジしていきたいと思っております。
  • とはいえ、今年やったことは1月のMackerel Meetupで話をします。

Fluentd と Norikra をもっとカジュアルに使おう

Norikra とは

Norikra とはリアルタイムイベントストリームに対して SQL ライクな言語で処理できる cool なプロダクトです。

例えば、Nginx のアクセスログを Norikra に流し込み、n分あたりのアクセス数やレスポンスタイムをリアルタイムに集計するといった事が可能です。
もちろん Nginx だけではなく、ご自身が書かれたアプリが出力するログも流し込んで集計できます。

更に Fluentd を組み合わせると GrowthForecast や Mackerel といったツールに集計結果を渡して可視化するなどといったことも容易なので、速報値集計やシステム運用状況の可視化に持ってこいです。

Fluentd と Norikra を活用して可視化する例

fluent-plugin-norikra と可視化ツール(GrowthForecast等)を組み合わせるとすぐに可視化できます。

fluent-plugin-norikra では in/out 両方とも実装されており、"Norikra へデータを入れる" "Norikra で実行されたクエリの結果を取り出す" 事が簡単にできます。
例えば広告配信などで毎分の配信結果やクリック、コンバージョンの速報値を可視化したいといった向きにマッチします。

今回の例では、仮に下記のような体裁のログを log.ad として forward することを想定します

{ "time": 1417886121, "ad_id": 100, "spot_id": 1234, "publisher_id": 4321, "charge_price": 100, "payment_price": 50 }

Norikra は事前にスキーマ定義を設定しておく必要はなく、データを送れば自動的にテーブルを作ってくれます。
データ型を明示的に指定したいときは auto_field 設定を false にし、登録する内容を明記することもできます。
このログの場合すべて整数なので、integer として扱われます。

Norikra へログを送信する場合、fluentd の設定ファイルには

<match log.*>
  type    norikra
  norikra norikra-server:26571

  remove_tag_prefix log
  target_map_tag    true
</match>

と書いておくだけで、Norikra 側には自動的に ad テーブルが作られます。

Norikra にデータが送られたら event(SQLライクなやつ) を登録しましょう、例で指定したタイムウィンドウ毎にクエリ結果がためられていきます。
event にはグループ名とターゲット名を指定する必要があり、このグループ名やターゲット名を使って、処理した結果を受け取ることになります。
今回は ad_request_count_1min としておきましょう。

select count(*) as count from ad.win:time_batch(1 min)

そのクエリ結果を取り出すには、fluentd 側で下記のような設定をしましょう。

<source>
  type    norikra
  norikra norikra-server:26571
  <fetch>
    method   event
    target   ad_request_count_1min
    tag      string ad_request_count_1min.all
    interval 60s
  </fetch>
</source>

ここまでで取り出した結果を別の plugin (例えば fluent-plugin-growthforecast) に渡してグラフを作れば、簡単に可視化することができます。
この程度の可視化であれば、fluent-plugin-datacounter を使っても同じことができますが、複数のログストリームを JOIN したり、項目で(例えばホストごと) GROUP BY などする際には fluent-plugin で頑張るよりも手軽です。
また、fluent-plugin では集計対象を登録、削除する際に再起動が必要ですが、Norikra は再起動無しに追加削除が可能なので、運用上も手間が少ないという利点があります。

筆者はこういったログから配信状況の推移や売上/支払の速報値について、Mackerel のサービスメトリックを用いて可視化しています。

<match request_count_1min.all>
  type mackerel
  api_key api_key_string
  service ServiceName
  metrics_name request_count_1min.${out_key}
  out_keys ad_request_count_1min,appimp_request_count_1min,imp_request_count_1min,click_request_count_1min,conversion_request_count_1min
</match>

f:id:myfinder:20141207024717p:plain

更にカジュアルに使うために

オフィシャルサイトに案内がある通り、インストールには jruby が必要です。
Norikra だけを動かすサーバが用意できるなら、jruby をインストールしてほげほげするのも容易ですが、

"ちょっと試そっかなー、でもあのサーバだと他に ruby が必要なコンポーネントとバッティングするしな〜"

というふうな状況に二の足を踏んでいる方もいらっしゃるのではないでしょうか。
そんな二の足を踏んでいる皆様がもっとカジュアルに Norikra を使えるよう、Docker Hub に Dockerfile を用意しました。


myfinder/docker-norikra Repository | Docker Hub Registry - Repositories of Docker Images

Docker がインストールされ、稼働している環境であれば下記コマンド一発で Norikra が動き始めます。

docker run -d -p 26578:26578 -p 26571:26571 -v /var/tmp/norikra:/var/tmp/norikra:rw -t myfinder/docker-norikra norikra start --stats /var/tmp/norikra/stats.json -l /var/tmp/norikra

これで人類は Norikra のインストールをどうするかという悩みから開放され、どこでも気軽に動かすことができるようになりました。
(Norikra 自体の詳しい使い方はオフィシャルサイトをご覧ください)

今後もこの Dockerfile は upstream に追随して更新していく予定ですが、自分で管理したいという方はどんどん fork するといいのではないかと思います。
あるいはいずれオフィシャルに Docker Image が提供されるようになるかもしれません。その時はオフィシャルの方を喜んで使いましょう。

MySQL のテーブルを BigQuery にインポートするための App::BigQuery::Importer::MySQL

このエントリは MySQL Casual Advent Calendar 2014 の1日目として書かれた記事であり、同時に Google Cloud Platform Advent Calendar 2014 の17日目として書かれた記事でもあります。
このエントリは MySQL と BigQuery を組み合わせて使う際に誰しも思うであろうことをどう解決するかという一手について書いたものです。

MySQL について

もはや説明不要の RDBMS ですね。これを読まれている方の中でも多くの人が使っているのではないでしょうか。
MySQL Casual Advent Calendar 2014 はまだまだ執筆者を募集しておりますので、ふるってご参加ください。


MySQL Casual Advent Calendar 2014 - Qiita

BigQuery について

こちらも説明は要らないかと思いますが、BigQuery は小さいデータ(メガバイト程度)から超巨大なデータ(ペタバイト級)まで、SQL ライクなクエリを用いて短時間で解析できる SaaS 型データストアサービスです。
fluent-plugin-bigquery を用いれば、発生したデータを逐次 BigQuery にインポートし、すぐにクエリで解析をかけることもできます。
データを入れておくだけなら S3 よりも安いので、用途によっては BigQuery をプライマリデータストアにしてしまうのもアリではと思います。


Google BigQuery - Fully Managed Big Data Analytics Service — Google Cloud Platform

BigQuery の用途と課題

BigQuery は追記のみ対応で、DELETE や UPDATE をすることができません。
ログをずっと貯めこむだけならそれで全く問題ないのですが、サービスの運用ではログテーブルとマスタ系テーブルを JOIN したいという要求が往々にして存在します。
なので、単純に追記することしかできない BigQuery ではマスタ系テーブルに対する操作を単に流し続けるということができません。
これに対してひとつの手として、定期的にマスタテーブルを BigQuery にインポートする方法が考えられます。
が、それを各所で個別に実装するのはなんか手間もかかるし、ちょっと面倒かなと思います。

そこで App::BigQuery::Importer::MySQL というツールを作りました。

App::BigQuery::Importer::MySQL

App::BigQuery::Importer::MySQLPerl で書かれたモジュールですが、CLI を同梱しているのでどなたでもカジュアルにご利用いただけます。
既に CPAN で公開していますので gcloud と MySQL のクライアントライブラリがインストールされており、必要な設定が済んでいれば

cpan App::BigQuery::Importer::MySQL

もしくは

cpanm App::BigQuery::Importer::MySQL


というコマンドで導入でき、インストールが完了すると "mysqlbq" という cli が利用可能になります。

使い方はとても簡単で、下記コマンドを叩くのみです。

mysqlbq --db_host=mysql-host.localdomain --src=mysql_table --dst=bigquery_table

--dryrun オプションをつければ、GCSやBigQueryに対する操作は行われないようになっています。

動作確認は gsutil 4.6 と MySQL 5.6.19 で行っていますが、特殊なことはやっていないので他のバージョンでも動作するかと思います。

このツールは下記のような動作で MySQL のテーブルを BigQuery にインポートします。

  1. 対象テーブルのスキーマ情報を取得し、BigQuery の型に変換した json ファイルを一時ファイルとして作成する
  2. 一時データ置き場として Google Cloud Storage(GCS) に bucket を作成
  3. 対象テーブルのデータを dump して bucket にアップロード
  4. BigQuery の対象テーブルがあれば削除して新たにテーブルを作り、GCS から dump したデータをロード
  5. dump データと bucket を削除してクリンナップ

このような手法で問題解決できそうだという方は、是非お使いください。


myfinder/app-bigquery-importer-mysql · GitHub

おわりに

App::BigQuery::Importer::MySQL はお手軽に MySQL から BigQuery へテーブルを同期できるツールです。
ログ系テーブルに対する集計にマスタデータを JOIN したいという方にお勧めです。

お使いいただく中で不具合を見つけられたり、機能要望などがありましたら github リポジトリのほうまで issue / pull reuqest をいただければと思います。

さくらインターネット #石狩DC 体験記(2回目)

謝辞

f:id:myfinder:20141201151755j:plain

応募者181名、参加枠30の狭き門な状況で2度めの貴重な機会をいただきまして、さくらインターネット並びにはてなの担当者さま方に感謝申し上げます。
前回からのアップデート差分を振り返り、ツアーを締めくくりたいと思います。
(公開していい情報かどうか未確認な話題や写真は、確認が取れ次第更新します)

データセンターの基盤的な話

  • 基盤については昨年のエントリにくわし〜く書きましたのでそちらを参照ください


さくらインターネット #石狩DC 体験記 - まいんだーのはてなブログ

前回見たフロアの差分

  • サーバの埋まり具合
    • 1号棟はほとんど埋まったとのこと
    • 実際HVDC対応のNECサーバが1ラック70ノード(Xeon 1CPU)びっしり埋まっているラックが増えていた
    • 1ラック70のCPUが詰められるのはかなりの密度
    • HVDC化したことで電源の故障が導入以降全く発生していないという点は特筆すべき点


直流・交流の変換ロスを減らすHVDC:Expressテクノロジ読本 | NEC

  • 高温超電導直流送電施設ができてた
    • 昨年書いた近所に建てた太陽光発電所からDC400Vでそのまま送電するという研究のための施設建屋が新たに出来ていた

f:id:myfinder:20141201151636j:plain

    • 残念ながらそちらは見る&撮影することは出来ず。

沿岸バスのラッピングバス

f:id:myfinder:20141129113545j:plain f:id:myfinder:20141201202420p:plain

さけ太郎&さけ子

  • 石狩DCに着いたらエントランスから石狩市のキャラクター ”さけ太郎&さけ子” が出てきて歓迎してくれた

f:id:myfinder:20141129131055j:plain

  • 今年はキャラ色が強い

石狩丼の変遷

  • こちらが昨年の石狩丼

f:id:myfinder:20131123133928j:plain

  • こちらが今年の石狩丼

f:id:myfinder:20141129132302j:plain

  • 高密度化が進んでいますね

音声レシーバ

  • 今回の見学で最も良かった改善点はこのレシーバ

f:id:myfinder:20141129132103j:plain

  • 前年はメガホンだったけれどもこちらのほうが全員均等に声が届くので、聞き逃すことがなくなった

鷲北さんのさくらのクラウド裏話

  • さくらのクラウドがサービスリリースまでにどういった経緯だったかというトーク
  • かなり短期間で実装〜公開された話や、石狩開所に合わせたリリースに向けた構築の話は特に関心高かった
  • “Demo or die.” というフレーズはいただきです

田中x田中対談

  • 2014年の振り返りから今後の展望について、というのがメイン
  • やはりというか、Dockerの話題が盛り上がって、完全仮想化よりもDockerのようなコンテナのほうがより効率がいいという話だった
    • その後で、さくらもDocker as a Serviceみたいなのやらないんですか?と聞いたら “ノーコメント” と言われたので、何か考えてそう感はあった
  • その場では詳しく言及されていなかったが、エンジニアの待遇に関して田中社長はいろいろ考えているようで、東京の給料をもらいつつ石狩で生活基盤が作れるような流れにできれば〜といった主旨の話も出た

懇親会

  • 個人的に注目している HP Moonshot の話を田中社長にしたら “さくらでも検証したけど、やはり汎用品の方が最終的には良い” という話だった
    • 最終的なオペレーションやサーバのライフサイクルを考えたら、普及してる1Uサーバの方がメリットが大きいだろうなというのは想像にかたくない


HP Moonshot System | 日本HP

  • 先ほどの対談では詳しくできなかったエンジニアの働き方に関する話に関連して、石狩にも開発拠点を設けたいといった話を伺った
    • 個人的には春先から夏の間北海道で花粉と湿気をやり過ごせたら最高だなと思う

f:id:myfinder:20141129221414j:plain f:id:myfinder:20141129222342j:plain

石狩湾新港地域案内

  • ガイド
    • 昨年は田中社長がバスガイドをしてくれて、大変面白かったのですが今回はプロ中のプロ、石狩開発という石狩湾新港地域開発の担当会社によるガチ案内
    • 地味に今回の資料で石狩湾新港地域の分譲価格(坪単価)とかを知れたのは興味深い点

f:id:myfinder:20141201160428j:plain

  • コンテナの荷揚げ所
    • 通常は港湾テロ対策に一般の出入りが禁じられているところ、担当者の方がわざわざ休日にもかかわらず鍵を開けてくれてバスの中からではあるが見学することができた
    • "ドッカーの働くコンテナ集積所” どっかで聞いたようなフレーズ

f:id:myfinder:20141130093239j:plain

  • LNG基地/火力発電所建設予定地
    • 大きいLNGタンクが2つに増えており、更に小さいタンクも増やしているとのこと
    • これは後述の火力発電所新設に向けた動きだそう
    • 北海道の泊原発が止まっているため、北海道全体では電気不足になっており、これを解決するために石狩湾新港に新火力発電所建設が進んでいるという話
    • エネルギー生産の中心で冷涼で海底ケーブル引き上げ所もあるっていう "データセンター作ってください" と言わんばかりの立地になってきている

f:id:myfinder:20141201160503j:plain

2号棟

  • 完成しているBゾーン以外に、工事中のCゾーン、まだ手入れされていないコンクリート打ちっぱなしのDゾーン以降も見ることができた
    • 完成したゾーンと壁や天井が仕上げられていないゾーンを行き来すると、実際壁や天井の裏がどうなっているか見えたり、空調機器を置く前の空気の通り道が見られたりしたのはとても良かったと思う
    • このあたりは是非写真OKになってほしいところ

リフレッシュルーム

  • 石狩DCのスタッフがランチしたり休憩したりする場所が出来ており、新しくきれいなスペースだった
  • 座敷もあってゴロゴロできるのはとても良い

f:id:myfinder:20141130120020j:plain

おわりに

毎年同じことを書くのもなんですが、スタッフの皆さんは些細な事でも丁寧に回答してくれるので、やはり普段サーバのことを余りやらない人ほど参加してどんどん質問すると実りが大きいのではないかと思います。
あとLTは臆せずやったほうがさくらのシャツがもらえるのでお得です。

重ねて、企画いただきましたさくらインターネット及びはてなの皆様に感謝を申し上げます。
ありがとうございました。

ISUCON4 本戦に出場

自分はサーバ側でみんなの開発ベースを整えつつ、今回の問題をどう対応していくかという作戦について取りまとめておりました。
当然3台使い切るための構成を考え

1. redisは1ノードに集約
2. uploadされた動画は各サーバの足元に置いてredisに動画置き場の情報を書く
3. アプリは x-reproxy-url ヘッダを返して動画を持ってるサーバから取得する

という方針で全部のサーバでベンチを受けられるようにしまして、これ自体は15時〜16時くらいまでに完了。
ただ、その先のチューニングからはスコアも伸びず、ベンチマーカー側の帯域がいっぱいになるし "さて果たしてこれから何をしたものか" となって終了時間を迎えた次第でした。

"帯域が太ければ" みたいな話が終了後の懇親会で出ましたが、たとえ10Gのネットワークが提供されていたとしてもスコアはせいぜい10倍にしかならず、トップの60万点には当然届かないわけで、今回問われたのはそういう所の戦いではなかったということです。

今回は5位まで賞があるということもあって、みんな堅実な戦い方をしたせいかわかりませんがfailが少なく最後まで戦えていたのでそこはとても良かったと思います。
ただ、8000点前後で大きく差がつかず団子状態になって手詰まって抜けられるチームが少なかったのは予選同様で、実力で差が出る部分まで全体的に行き着きづらい問題設計になってしまっていたのかなと感じました、さじ加減がとても難しそうですが。。

講評でCache-Controlの話が出た時は"ウーム、UAごとのキャッシュだと何度来るかわからんからそれだけで劇的に変わっちゃうのもどうなのよ、あと現実に即して考えるならnginxがLast-Modified返してるんだからベンチマーカー側も考慮したほうがいいのでは"とは思いましたが...

この辺はあとでロージリーさんに伺ったところ、Cache-Controlを付与するとベンチマーカーは一度キャッシュすると全体で使いまわしてくれる仕様だったようです。
更にベンチマーカーはスループットが出れば出るほど多くリクエストを出す仕様になっており、キャッシュさせてしまえば後はずっとレスポンスを返し続けるだけの簡単なお仕事をぶん回すのみになります。
そうなると、途中で得点レギュレーション変更された imp得点(0.001)x5 -> 表示回数(1)x5 によって1位の60万点のようなスコアが出るのもうなずける話です。
とはいえ現実の配信でCDNを向けさせるにしてもCache-Controlとかオリジン側で入れるのはごくごく当然やることなのでそういうのをやれてない/気づけてない時点でやられてしまっていたというのが現場からのレポートです。


さいごに、出題の皆様、運営の皆様、テコラス様、ありがとうございました。

YAPC::Europe 2014 と YAPC::Asia 2014 に行ってきました

YAPC::Asia 2014が開催されました & 参加してきました。
昨年のベストトーク副賞でJPAさまから渡航滞在費用を提供いただけたので、今年はAsiaだけでなくYAPC::Europe 2014にも参加してきました。

YAPC::EuropeとYAPC::Asiaでのトーク内容

YAPC::Europeの模様は↓のスライドをご覧ください。

あとYAPC::Europeで発表した内容は↓のスライドをご覧ください。

所感

今回、YAPC::EuropeとYAPC::Asia両方に参加して、もっとAsiaでも盛り上がったほうがいいと思う点が幾つかありました。
特にトーク中でも質問が入ったり、トーク後にもスピーカーを捕まえて話したりする点などはAsiaでも積極的にやって良いのではと思います。
また、周りの人が積極的に話しかけてくれた点もすごく良かったなと。

なのでYAPC::Asiaでも参加者、スピーカーにとどまらず海外から来るゲストにはもっと積極的に話に行くことをお勧めしたいです。
一対一なら多少ブロークンな英語でも聞こうとしてくれるし、なかなか表現がわからない時でも皆もってるスマホGoogle翻訳アプリを使うと相手も合わせてくれたりします。

「せっかく来たけど話しかけても逃げられちゃうし全然交流できなかった」と思われるより「いやー日本人の英語全然わかんねぇけど活発に交流できたわ〜また来たいわ〜」って思ってもらったほうがポジティブでしょうし、自分自身もより多くのことをYAPC::Asiaで得られるようになるのではないでしょうか。

おわりに

ベストトーク1位のうずらさん、おめでとうございます。
是非YAPC::Europe 2015@グラナダへ行ってきてください。

主催のyusukebeさんはじめスタッフの皆様、とても良いイベントだったと思います。ありがとうございました。