Aimingデータ解析チーム現場だより

# ホゲェ〜

なんか色々とまとめといた方が良さそうだ。
自分にとって数が多くて意味がわからんし。

まだ社内データは収集する環境を整えている状態だ。
整えているといってもできてるんだけど、
なんか色々と新しいツールが出てくるしそれに追っついて
書き換えちゃったりを繰り返している。

意味がわからなくなってきたのでまとめてみよう。
社内で共有するにはQiitaに上げたほうが良さそう。
あげちゃまずいものは書いてないつもりだ。
まずかったら消す。

データ解析チームが何やってるのかをまとめてみた。
各担当者の名前を出して問題なさそうなら出そうかなあ

# Aimingデータ解析チームについて

データ解析チームだとつまらんし愛情がわかないのでチーム名をつけている。
**Monolith**だ。モノリス。あのモノリス。

@shibacowさんが考えだした。トテモ良いチーム名だと思う。

## チームメンバー

は以下の3名

- @shibacow (解析スペシャリスト)
- @ckazu (Railsスペシャリスト)
- @futoase (腕力解決型エンジニア)

# 使っているサービス

## Treasure Data

http://www.treasuredata.com/

![treasure-data.png](https://qiita-image-store.s3.amazonaws.com/0/3985/c9e3671c-83bf-a7d8-8882-262921d9a636.png)

これは大きい。データ解析はデータがないと意味が無い。
入れ物がないと意味がとってもない。
自分たちでデータを格納するための、インハウスな環境を整えるのはだるすぎる。
落ちない環境を整えるためのチームを育てるにはどれくらいの時間とお金が...

ということでTreasure Dataを使っている。
ボコボコテストデータやらなんとかデータやら入れていってる。

Hive QLを書けば、MySQLでSQL Queryに親しんだ
化石と化した僕のようなおじさんでも気軽に溜め込んだデータから
面白い動向を見るための要求を出せる。

でまあ落ちないしデータはTreasure Dataにある！といえる
状態になってるのですごく安心して使ってる。

何か疑問が合ってもサポートの方にチャットで聞けば問題のない
状態になってるし便利。インターネットバンザイ。

## pivotal tracker

https://www.pivotaltracker.com/

![pivotal-2.png](https://qiita-image-store.s3.amazonaws.com/0/3985/d8d2e5e5-6499-b7ca-2396-317e5530f116.png)

ストーリーを起こして、ポイント付けて、ベロシティあれこれ...
という極めてアジャイルな使い方をしてる。
週1、金曜日に棚卸しをしたり月曜日には企画の人と一緒に
ストーリーを起こしたりしている。

## Trello 

https://trello.com/

![trello.png](https://qiita-image-store.s3.amazonaws.com/0/3985/83950a8a-8b58-505b-0af8-6252b8293bc1.png)

pivotal trackerはストーリーを立てて、という流れなのだけれど
細かいタスク、「xxの環境を構築するけど新しいことに挑戦するための調査」
みたいなものや、その場で発生した問題に対処するために
時間が取られちゃってるとかはpivotalで管理しづらい。
ベロシティが常に変化しちゃってよくわからなくなるし。

口頭で報告ということもやっているのだけれど、
Trelloを使ってみようと提案して使ってみている。

## idobata

https://idobata.io

![idobata.png](https://qiita-image-store.s3.amazonaws.com/0/3985/8db5ae8a-02e1-d007-cf91-0959ea9b26f7.png)

データ解析チームで試しに使ってる。
使い始めてから不満はない。
特定のエンドポイントに対しcurlでデータを送ってやると
チャットルーム内にメッセージを送れる。
つまるところpush専用のbotを作れる。

iOSアプリもリリースされているので出先から確認可能なのが助かる。

# 使っているソフトウェア

## fluentd

http://fluentd.org/

![fluentd.png](https://qiita-image-store.s3.amazonaws.com/0/3985/b009a1bf-265e-63e2-3441-7e0b50568d43.png)

fluentdを利用している。これがないとデータが集めらんない。
弊社の場合、利用しているサーバ(クラウド含め)は1社1様というわけには行かない。
fluentdというかtd-agentのセットアップについてデータ解析チームがサポートしている。

まだサポート対象の数が多くないからできることなのかなと思う。
出来そうなチームはチームに任せちゃって良いと思ってたりする。

今のところchef、capistranoを利用してデプロイしている。

## HRForecast

![hrforecast.png](https://qiita-image-store.s3.amazonaws.com/0/3985/26659f03-6409-3395-e14e-727b2cc02207.png)

https://github.com/kazeburo/HRForecast

Treasure Dataには **Sending Query Results to a Web Server** という
ウェッブの口に対してHive QLの結果を投げつける機能がある。

http://docs.treasuredata.com/articles/result-into-web

その機能を活かして、HRForecastに結果を投げつけるようにしている。
ただ、Treasure Dataが吐き出しているjsonの形式はHRForecastは食えないし、
そもそも食える状態じゃない。そのため、
Treasure Data が吐き出してるjsonをHRFが食えるPOST形式のリクエストに変更する
ブリッジするものを用意した。sinatraで書いてpumaで動かしてる。
先に入っていた先輩エンズィニアのヘルプ(ペアプロ)のもと書いた。

元々はHRForecastが描画していたグラフをそのまま利用していたけど
HighChartsを導入して以降、HRForecastはAPIのみ利用している

## GrowthForecast

![growthforecast.png](https://qiita-image-store.s3.amazonaws.com/0/3985/6b013a29-937e-7147-95c8-bf21740b9d2a.png)

https://github.com/kazeburo/GrowthForecast

これはリアルタイムなデータを流し込むのに利用してる。
さっき(1分前ぐらい)ログインしてきたユーザーとか。そんなの。

使い方はHRForecastみたく時系列にデータを評価したい、というのと対照的に
速報としてデータを貰いたいときに利用する

こちらもHRForecastと同じく、グラフ描画にはHighChartを利用する形になった。
APIサーバとして利用している。

## HighChart

http://www.highcharts.com/

![hinode.png](https://qiita-image-store.s3.amazonaws.com/0/3985/dea15a74-dc3c-15e4-0e53-f185cc7883fe.png)

きれいなグラフを出してくれるjsのライブラリ。
予算出してもらって買ってもらった。

HRF, GRFのAPI経由でもらったcsvをHighChartに食わせて描画している。

## chef

http://www.getchef.com/

![chef.png](https://qiita-image-store.s3.amazonaws.com/0/3985/df8d525d-f447-1ce7-75f1-f4dad5733fcf.png)

ミドルウェアのデプロイに利用している。
鉄板な感じがするのだけど、cookbookが増えてくるにしたがって
実行時間の長さが辛くなってきた。
またchefのバージョンアップに気づきづらい。
chef謹製のcookbookの構造が変わったりするので困っている部分も。

yum cookbookとか...

## capistrano

http://capistranorb.com/

![capistrano.png](https://qiita-image-store.s3.amazonaws.com/0/3985/d60f2010-f91a-e7db-6d43-f4caee9d9c51.png)

Railsアプリのデプロイに利用している。
v2, v3のものが混じってて整頓中。
v3からはgitのbranchを判別するようになってるので楽だ。
ただ、taskの書き方が若干変わってたりするが...

## ansible

http://www.ansible.com/

![ansible.png](https://qiita-image-store.s3.amazonaws.com/0/3985/3d3c8c45-5786-7aed-fd3c-315ba886799d.png)

chefから乗り換えよう他のものを探してて、まあこれかなって思ったので採用した。
ansibleについて今まで避けてきていたのだけど
使ってみたらかなりよかった。

デプロイ元でansibleをインストールしておけば良いだけで助かる。
ansibleそのものも巨大じゃないのと、
playbookに書き込むのは基本的にコマンドなので
他の開発者がレビューするときにも楽だ。
上から下に評価されて実行されるし。

## docker

https://www.docker.io/

![docker.png](https://qiita-image-store.s3.amazonaws.com/0/3985/c9a5b5ad-a2e7-e9aa-0227-d5e8d8a12669.png)

chefで毎度のごとくruby, perlのビルドをするのが辛くなってきた。
GRF, HRFのビルドもだるくなってきた。
楽しいんだけどだるい。どうにかしたい。
ということでdockerを使い始めてみることにした。
RHEL系のディストリに0.7から対応し始めたし。

ansibleとdockerを組み合わせることで
デプロイが楽になった。簡略化が進んだ！

docker indexというサービスがあるのだけれど、
そこに個人的に作成したGRF, HRF各imageを登録した。

- https://index.docker.io/u/futoase/docker-growthforecast/
- https://index.docker.io/u/futoase/docker-hrforecast/

どうにかこうにかstagingで立ち上げているが問題なく動いているようだ。
docker imageのビルドをdocker indexというサービスにに任せる(!)ことができ、
外部リソースを使ってビルドすることによりリソース省力化ができる。

...といってもdocker buildした後にprivate docker-registryに対して
pushすればよいのだけれど。

# これから使おうとしてるもの

## deploy

https://github.com/visionmedia/deploy

![deploy.png](https://qiita-image-store.s3.amazonaws.com/0/3985/158e5746-2791-b3b2-8cbb-d3f4f9b265ea.png)

capistranoの次として採用検討中(個人的に)

https://github.com/visionmedia/deploy

簡素な方が良いという考えから。
どんな塩梅で使えるのか確認するため個人的に確認してみた。

http://qiita.com/futoase/items/c2ac39cfe28813b79bc4

## dokku

https://github.com/progrium/dokku

![dokku.png](https://qiita-image-store.s3.amazonaws.com/0/3985/20ce0006-f3ba-440a-22e1-04452fff9d17.png)

localで確認できるよう導入してみたが、
ubuntuしか対応してないとのことでcentosもサポートしてもらえると助かる:)

個人的に以下のエントリがとても参考になった。
http://blog.coiney.com/2013/08/10/create-my-own-heroku/

# これからの展望

1. デプロイツールはdeployを使っていく(問題がでなければ...)
2. ミドルウェアインストール・マシン環境構築にはansibleを使っていく
3. アプリケーションイメージを常にdockerで持つようにする
4. docker exportでコンテナをバックアップ
5. 母艦が変わってもdockerが入れられるディストリであればdocker importで移行終了にする

とにかくインフラ、環境構築については簡素にする。
大切なのは何をやるか、だからだ。

まだ色々とある。試すことも沢山あるので逐次書いていく。