日時: 2014-12:12 19:00~22:20
場所: FreakOut
イベントURL: http://gcpja.connpass.com/event/9647/
togetter: http://togetter.com/li/756806
スライドは見つけ次第、追記予定

トレタのBigQuery / Google Apps Script活用術

Apps Script

最も簡単に動かせる Server Side Javascript
無料
DB, bq にもアクセスできる

たかはしさん

slack ボット、勤怠管理、おはよう・お疲れさまとつぶやくだけ
Google Spreadsheet に記録
Google Apps Script で記述
公開されてる、https://github.com/masuidrive/miyamoto

BigQuery の利用状況（前職）

MySQL の内容をバッチで 1 回 / 1 日全コピー
マーケの人が SQL を書けたので

bq の利用状況（いま）

MySQL の内容をバッチで 1 回 / 1 日全コピー
個人情報はコピーしないので、いろんな人に使ってもらってる
非正規化を行う、あとで join しなくて済むように
ログは fluentd 経由で
どうやって可視化する（アクセス手段の確保も）が課題
みんな SQL たたけない
Google Apps Script -> Slack で実現してる

bq の可視化

BigQuery ボットがサマリ情報を毎日つぶやく
また、Spreadsheet で 1 ページにグラフ化させている
SQL も Spreadsheet に書くようにすれば、仕様の更新も比較的簡単にできる

作りたい（作ってる）もの

mysql2bq
mysql のデータを bq にコピーする
BigQuery Cheats
bq の結果から単純なグラフを生成

Kubernetesの機能とデモ、開発体制について

Kubernetes とは

docker container をデプロイしてスケジュールするもの
全体をどう統合するのかという課題に対応するプロダクトが Kubernetes
docker は単独のコンポーネントをデプロイするのは簡単になった
だが、docker コンポーネント同士を連携するのは難しい
簡単に何をしているかというと
マスターノードがコマンドを受け付けたら、スレーブに docker のコンテナーイメージを適当に配置してくれる
略称、Kube

3 つの概念

Service
個々のコンポーネントを抽象化したもの
抽象的なので実装が必要、Replication Controller と Pod が行う
Replication Controller
サービスを実装する
Pod のレプリケーション
Pod
コンポーネントを配置する際の最小単位、この概念があると色々便利というのは Google の経験則が生かされた結果だろう
これを Replication Controller がコピーする（必要なら）

大まかな仕組み

Kube はマイクロサービスをデプロイするためのもの
設計上の前提
ひとつひとつのコンポーネントはマイクロサービスである
それぞれは特定の機能にフォーカスして、他のサービスと通信して依存しあう
それでいて全体でシステムを構成する
そのうちのいくつかは外部に公開されている
このマイクロサービスが、上記概念の Service である
サービス内では、サービスを実装するコンポーネントが複数並んでいて、それらはロードバランスされている
その配備されている一個一個のコンポーネントがPodである
ひとつのマシーンにて、複数の Pod を走らせることもある
1 つの Pod は 1 つ以上の docker コンテナーを持っている

guestbook アプリというサンプルを例に

3 つのサービスによって、ひとつのウェブサイトが出来上がっている
Redis master サービスがある
Redis slave サービスがある
guestbook app サービスがある
まずは、Kube のクラスターを立ち上げる
次に、Redis master サービスに対応する Pod をつくる
master node は replication しなくていい（複数要らない）ので直接 Pod をつくるだけになる
Kube クラスターに Pod の作成を依頼すると、Kube クラスターの管理下に redis master サービスを実装する Pod （master ノード）が配置される
今度は、redis slave の Replication Controller をつくるところからはじめる
json で定義ファイルを用意している
定義ファイルでは、1) いくつつくるか、2) その Pod インスタンスはどうつくるべきか、3) Pod 内の個々のコンテナはどう走るべきか（いわゆるシェルコマンド）を書く
クラスターに依頼したら、Replication Controller で指定した数だけの Pod ができていることが確認できる
次に、その複数の Pod をロードバランスするサービスをつくることになる
ロードバランスサービスでは、どの Pod が自分に属するのかを定義すれば、それにマッチする Pod に自動でロードバランスするようになる。
最後に、redis を使うウェブアプリの Replication Controller をつくる
クラスターに作成を依頼すると、適当なノードに割り振られる
redis slave と同様に、その複数のノードをロードバランスする Service もつくらないといけない

もう少し細かい仕組み

Kube の中心は etcd
zookeeperみたいなもの。ロックをとったり、 kvs があったり。高可用性 KVS。
すべての設定は etcd に書かれる
API サーバー（= Master components）はコールを受け取ったら、最後に etcd に書く（= 直接他のデーモンとやり取りしない）
いろんなデーモンが etcd を watch していて、必要に応じて fetch している
Pod 作成のコールが来て etcd に書かれた場合、それを kubelet というデーモンが watch していて、Pod をつくる（Minion = Slave components にて）
kubelet は完了したら、その対応した情報を etcd に書き込む
ネットワーク周りは Pod にプロキシがあって、それを通じて行われる
Pod は他のサービスにつなぎたければ、このプロキシに接続して、そのプロキシが他のノードにつなぎにいってくれる
さっきの guestbook でのウェブアプリサービスは redis がどこにあるかわからないけど、localhost のプロキシにつなぎにいけば、redis Pod につなぎにいくことが出来た
これは、GCE LB を経由して外部につながることが出来る。

印象

まだ若いプロジェクトで、デファクトがない状況
重要なのは将来性
特別なテクノロジーは使われていないが、当たり前のことを積み重ねてはいる
そして、Google の 2 billion containers / week で培った経験が積み重ね方に現れてる
issue の解決がめちゃくちゃ早い
kibana の dashboard がある、ログの収集機能は fluentd を使ってる。こういう機能を自分たちでつくるのではなく調べた上で他のオープンソースを選択できる開発体制は信頼が出来ると思う。

類似

Fleet
小さいものを配置するのには良い
ただし、ネットワークをどうするかはあまり練りこまれていない
また、Kube on Kube で同じように使うことが出来る
Paas w/Docker（Managed VMs, Elastic Beanstalk）
比較的大きなマイクロサービスをここに載せるのは大変
とはいえ、Kube の Replication Controller を使わないような場合には Kube は無用に複雑なのでこれらのほうがいい
Mesos
Kube はネットワークは良く作りこまれているけれど、CPU / memory / プロセスを盛り込みたい場合にはスケジューラーが作りこまれていないので、難しい
メモリ 2GB 空いているので突っ込むとかしたいなら、Mesos の方が良い

質疑応答

GCE LB は差し替え可能？
差し替え可能。プラットフォームごとに変えられる

ログだけじゃない！BigQuery使おうぜ！とGCEも使えるよ。

紹介

セブン & アイ NetMedia
妖怪メダルはけっこうあるからおすすめ
運用チーム、データマイニングとか監視やってる

bq との出会い

Google 本社でまだ使ってない bq を社長が使ってると言ったから

bq の使い方

アクセスログ、在庫、商品、顧客属性、注文明細、カテゴリのデータを非正規化して、bq に入れたのが最初
GAS -> bq -> GAS で現場に提供している

7 カフェキャンペーンページの検証に使ってみた

キャンペーンの結果、より詳細にリンク先の売上がどう影響したのかを調査した
直リンクのもの（マンガ）、PV は伸びたけど、売上には効果がなかったり
バナー先で紹介されているもの（料理本）、PV も売上も伸びた
商品カテゴリが影響したのか、バナーが良かったのか等の仮説が出てきた

bq の pro, con

[con?] Oracle にあるマスターデータを入れているが、bq は UPDATE が出来ない
更新日を持たせてインポートして、View で取っている
[con] タイムスタンプが UTC, よくわからない EACH 句
JOIN でデータが多すぎるときには EACH 句使わないといけない
[pro] テーブルワイルドカード
table_date_range は指定した期間のテーブルが UNION されて使える
[con] いつもなら数十秒なのが数分たっても返ってこないことがたまにある

JOIN も早い

リコメンドメールの開封率やコンバージョン解析で、5 億 x 1 億の JOIN が 5 分。1 回 7 円。

質疑応答

Oracle では実現できない？
exadata 入れてるけど、たぶん無理
同時に回せるのがすごくいい
朝一番に 200 人みんなが SQL 発行している
出版社別受注実績で、日次期間・月次期間・出版社を Google スプレッドシートで指定したら、商品マスターと注文データを JOIN している（現場では神ツールと呼ばれている）
今後は購入者のデータと JOIN しようと思ってる
データの見せ方は？
Google スプレッドシートの可視化の方法もスプレッドシートに書いている（前述のトレタと同じような方法）ので、現場と話しながら可視化を検討できるのが、bq だけしかできないこと

GCP最新動向まとめ

gcp live の話がメイン

GCE（過去 6 ヶ月のリリース）

16 コアの VM が登場
ローカル SSD を使う場合には、CPU がボトルネックになるほど早いのでこれを使わないといけない
Transparent maintenance（ライブマイグレーション）
メンテナンスでリスタート騒ぎを起こさない
vmotion をより早くやってるようなイメージ
200ms でメンテナンス出来ているのでは

GCE （Local SSD）

いままでは、全部ディスクはネットワークディスク（ドライブ）だった
NFS のようなイメージ
書き込もうとすると、3 台以上のサーバーのディスクに書き込まれるので可用性はとても高い
Local SSD は直付けされているのでとても早いが、冗長化はされていない
FusionIO と同じようなパフォーマンスをクラウドで出来るようになったのが新しい、そして安い
インスタンスタイプと結びついていないのも良い
それでいて、GCE のライブマイグレーションにも対応予定。
冗長化やスナップショットがないという欠点はまだある
CPU がボトルネックになるので、4 SSD をつけるときには 4 x 4 の 16 コア必要
また、IRQ がボトルネックになったりもする
ベータ版

Compute Engine Autoscaler

ベータ版
CPU 使用率、LB の負荷率、Google Cloud Monitoring のカスタムメトリックスをトリガーのしきい値にできる

Container Engine（GKE）

kubernetes の商用エンジンという位置づけ
フルマネージドのコンテナエンジン
Alpha 版
ゾーン、クラスタ、VM 数、VM のインスタンスタイプを指定すると Kube のクラスターが出来る

fluentd との取り組み

Kube に採用
Google Cloud Logging に採用

Firebase

買収したサービス
GCP との統合はこれから
NoSQL, JSON database
milisec で変更が各クライアントにプッシュされる

Google Cloud Networking

大きくは次の 2 つがサポートされる
1. Google Cloud Interconnect
1-1) Direct Peering -- POP（Point of Presence）に専用線を直接ピアリングすることが可能、大手向き
1-2) Carrier Interconnect -- キャリアの専用線経由で Google Network に接続できる、順当な感じの選択肢
1. Google Compute Engine VPN -- 通常の VPN、以前から出来たは出来たけれど、ちゃんとしたサービスとして出てきた

Monitoring Kubernetes

Kubernetes

Docker をクラスタ管理するにはツールが必要というところから出てきたプロダクト
色々な環境で動かせるのが良い
マネージドではなくてオンプレとかで動かしたい
リソース管理をどうするか
Mackerel でやってみるとか試してる

Monitoring に関連する要素

kubelet
cAdvisor
heapster

kubelet

各ノード（minion）に常駐、動作しているデーモンプロセス
kubernetes master と協調動作して、コンテナを配置したりしている
minion をコントロールするプロセス

cAdvisor

Docker の統計情報を取得する
ホスト全体、コンテナ全体、それぞれにある
kubelet とは別のレポジトリにある

heapster

リソース情報収集ツール
kubernetes 専用
influxDB と連携している

標準モニタリング

heapster + cAdvisor -> InfluxDB + Grafana
クラスタ内にあるのでクラスタが落ちると消える -- これにプロダクション依存は出来ないだろう
各コンテナの CPU 使用率とかメモリ使用量とかが可視化される

Minion の統計情報取得

kubelet の API があるので、http で取得できる

モニタリング手法

クラスタ上で動いているものを把握するためのコマンドがある
Minion 上のコンテナ状態取得するためのコマンドがある

pods の動的なサイズ変更

レプリカを動的に指定すれば、オートスケールとかも出来る

GCPUG

Google Cloud Platform User Group を立ち上げました