今年出たもののまとめ
前半
後半
- https://github.com/myfinder/aws-casual-3/blob/master/slide.md
- https://github.com/myfinder/aws-casual-3/blob/master/lt.md
- https://github.com/myfinder/yokohamapm-12/blob/master/slide.md
- https://github.com/myfinder/aws-advanced-users-meetup-2/blob/master/slide.md
- https://github.com/myfinder/marketing-tech-20141216
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>
更にカジュアルに使うために
オフィシャルサイトに案内がある通り、インストールには 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 はまだまだ執筆者を募集しておりますので、ふるってご参加ください。
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::MySQL は Perl で書かれたモジュールですが、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 にインポートします。
- 対象テーブルのスキーマ情報を取得し、BigQuery の型に変換した json ファイルを一時ファイルとして作成する
- 一時データ置き場として Google Cloud Storage(GCS) に bucket を作成
- 対象テーブルのデータを dump して bucket にアップロード
- BigQuery の対象テーブルがあれば削除して新たにテーブルを作り、GCS から dump したデータをロード
- dump データと bucket を削除してクリンナップ
このような手法で問題解決できそうだという方は、是非お使いください。
おわりに
App::BigQuery::Importer::MySQL はお手軽に MySQL から BigQuery へテーブルを同期できるツールです。
ログ系テーブルに対する集計にマスタデータを JOIN したいという方にお勧めです。
お使いいただく中で不具合を見つけられたり、機能要望などがありましたら github リポジトリのほうまで issue / pull reuqest をいただければと思います。
さくらインターネット #石狩DC 体験記(2回目)
謝辞
応募者181名、参加枠30の狭き門な状況で2度めの貴重な機会をいただきまして、さくらインターネット並びにはてなの担当者さま方に感謝申し上げます。
前回からのアップデート差分を振り返り、ツアーを締めくくりたいと思います。
(公開していい情報かどうか未確認な話題や写真は、確認が取れ次第更新します)
前回見たフロアの差分
- サーバの埋まり具合
- 1号棟はほとんど埋まったとのこと
- 実際HVDC対応のNECサーバが1ラック70ノード(Xeon 1CPU)びっしり埋まっているラックが増えていた
- 1ラック70のCPUが詰められるのはかなりの密度
- HVDC化したことで電源の故障が導入以降全く発生していないという点は特筆すべき点
直流・交流の変換ロスを減らすHVDC:Expressテクノロジ読本 | NEC
-
- 残念ながらそちらは見る&撮影することは出来ず。
石狩丼の変遷
- こちらが昨年の石狩丼
- こちらが今年の石狩丼
- 高密度化が進んでいますね
音声レシーバ
- 今回の見学で最も良かった改善点はこのレシーバ
- 前年はメガホンだったけれどもこちらのほうが全員均等に声が届くので、聞き逃すことがなくなった
鷲北さんのさくらのクラウド裏話
- さくらのクラウドがサービスリリースまでにどういった経緯だったかというトーク
- かなり短期間で実装〜公開された話や、石狩開所に合わせたリリースに向けた構築の話は特に関心高かった
- “Demo or die.” というフレーズはいただきです
田中x田中対談
- 2014年の振り返りから今後の展望について、というのがメイン
- やはりというか、Dockerの話題が盛り上がって、完全仮想化よりもDockerのようなコンテナのほうがより効率がいいという話だった
- その後で、さくらもDocker as a Serviceみたいなのやらないんですか?と聞いたら “ノーコメント” と言われたので、何か考えてそう感はあった
- その場では詳しく言及されていなかったが、エンジニアの待遇に関して田中社長はいろいろ考えているようで、東京の給料をもらいつつ石狩で生活基盤が作れるような流れにできれば〜といった主旨の話も出た
懇親会
- 個人的に注目している HP Moonshot の話を田中社長にしたら “さくらでも検証したけど、やはり汎用品の方が最終的には良い” という話だった
- 最終的なオペレーションやサーバのライフサイクルを考えたら、普及してる1Uサーバの方がメリットが大きいだろうなというのは想像にかたくない
- 先ほどの対談では詳しくできなかったエンジニアの働き方に関する話に関連して、石狩にも開発拠点を設けたいといった話を伺った
- 個人的には春先から夏の間北海道で花粉と湿気をやり過ごせたら最高だなと思う
石狩湾新港地域案内
- ガイド
- 昨年は田中社長がバスガイドをしてくれて、大変面白かったのですが今回はプロ中のプロ、石狩開発という石狩湾新港地域開発の担当会社によるガチ案内
- 地味に今回の資料で石狩湾新港地域の分譲価格(坪単価)とかを知れたのは興味深い点
- コンテナの荷揚げ所
- 通常は港湾テロ対策に一般の出入りが禁じられているところ、担当者の方がわざわざ休日にもかかわらず鍵を開けてくれてバスの中からではあるが見学することができた
- "ドッカーの働くコンテナ集積所” どっかで聞いたようなフレーズ
2号棟
- 完成しているBゾーン以外に、工事中のCゾーン、まだ手入れされていないコンクリート打ちっぱなしのDゾーン以降も見ることができた
- 完成したゾーンと壁や天井が仕上げられていないゾーンを行き来すると、実際壁や天井の裏がどうなっているか見えたり、空調機器を置く前の空気の通り道が見られたりしたのはとても良かったと思う
- このあたりは是非写真OKになってほしいところ
リフレッシュルーム
- 石狩DCのスタッフがランチしたり休憩したりする場所が出来ており、新しくきれいなスペースだった
- 座敷もあってゴロゴロできるのはとても良い
おわりに
毎年同じことを書くのもなんですが、スタッフの皆さんは些細な事でも丁寧に回答してくれるので、やはり普段サーバのことを余りやらない人ほど参加してどんどん質問すると実りが大きいのではないかと思います。
あと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両方に参加して、もっとAsiaでも盛り上がったほうがいいと思う点が幾つかありました。
特にトーク中でも質問が入ったり、トーク後にもスピーカーを捕まえて話したりする点などはAsiaでも積極的にやって良いのではと思います。
また、周りの人が積極的に話しかけてくれた点もすごく良かったなと。
なのでYAPC::Asiaでも参加者、スピーカーにとどまらず海外から来るゲストにはもっと積極的に話に行くことをお勧めしたいです。
一対一なら多少ブロークンな英語でも聞こうとしてくれるし、なかなか表現がわからない時でも皆もってるスマホのGoogle翻訳アプリを使うと相手も合わせてくれたりします。
「せっかく来たけど話しかけても逃げられちゃうし全然交流できなかった」と思われるより「いやー日本人の英語全然わかんねぇけど活発に交流できたわ〜また来たいわ〜」って思ってもらったほうがポジティブでしょうし、自分自身もより多くのことをYAPC::Asiaで得られるようになるのではないでしょうか。