えいのうにっき

a-knowの日記です

gcp ja night #28 に参加してきたので色々まとめるよ #gcpja

勉強会 GCP GAE BigQuery

gcp ja night #28 に参加してきたので、色々まとめるよー。スライド資料を見ればわかるようなことは書かない方向で。

懇親会の場で、Googler の佐藤さんに、前から気になってたことをいくつか質問できたので、その内容もこのエントリの最後にメモっとく。

イベントページ

gcp ja night #28 - connpass

各種まとめ

2014.09.16 gcp ja night #28 #gcpja - Togetter

gcp ja night #28 - 資料一覧 - connpass

Managed VMのDocker対応とKubernetes最新動向

  • @briandorsey by Brian Dorsey, Developer Advocate, Google Inc.
  • 僕の観測範囲では、スライド資料の公開はなし
  • GAE などのような PaaS を使いつつ、IaaS 的なものを使いたくなったこと、あるよね。というお話
    • PaaS には制約が付き物。例えばファイルの出力が行えなかったりとか
    • 1 request を返すまでのタイムリミットがあったりだとか
    • 特定のライブラリを使えなかったりとか。今日はこの問題の解消をデモでやってくれた
      • ある数独の問題をイメージで与え、イメージの解析を MVMs 上でライブラリを使って実施する
  • それを叶えてくれるのが、Management VMs（MVMs）
    • GAE のインスタンスを、GCE 上で動かしてくれる
    • GAE と GCE との橋渡しには、（今日紹介された例だと）Task Queue を使う
      • GAE が Task ã‚’ push / GCE が Task ã‚’ pull...ってことなのかな？
  • GAE には Module / Version という考え方があるけど
  • フロントはオートスケールする GAE で、ライブラリ処理の必要なバックエンドは GCE で
    • バックエンドの方も、LA をもとに、MVMs 側も調節してくれる、らしい
  • MVMs はまだ Limited preview

Containerizing the Cloud

  • Docker とかコンテナとかのお話し
    • 個人的にここらへん弱い部分なので、メモも自信ない(´・ω・｀)
  • なぜコンテナは嬉しいか？
    • 静的な環境を用意できる
    • ポータビリティ
    • 疎結合になる
  • Google ではほぼすべてがコンテナ化されてる
    • コードのリポジトリはどれもほとんど同じ（！）
    • 依存性がひとつのバイナリに入ってる
  • Kubernetes
    • 発音、くばねてぃーず って聞こえたから多分そう
  • 例えば同一ホスト上で動作する2つのコンテナを、常にセットで起動したいとき...
    • Kubertes に丸投げできる、多くのコンテナ群を Kubernetes で管理できる
    • role ã‚„ staging / production などを設定できる
    • コンテナの組み合わせを Pod と呼んでる
    • 4 Pods 欲しいときは、「4 replicas」
    • templates に、あらかじめ決めておいたコンテナの組み合わせ定義を指定する

Google BigQueryの概観とユースケース

  • by @naoya_ito
  • 今日使用されたスライドそのものは見つからなかったのだけど、先日の YAPC とほとんど同じ内容だとのこと 公開されましたので差し替えました（2014/09/17 17:33）。こちら -> Google BigQuery の話 #gcpja - Speaker Deck
  • 6ページ目：BigQuery のブレイクスルーの一つには、Streaming Insert API が使えるようになったことが挙げられる。
  • 12ページ目：価格が異常に安いのも特色の一つ。
    • さらに、スキャンサイズ 1TB/month は無料。
  • 16ページ目：ColumnIO のおかげで、ランダムリードにならずシーケンシャルリードとなり、嬉しい。

KAIZEN でのつかいどころ

  • 34ページ目：正規化はあまりしないのがセオリー。
  • 35ページ目：外部ツールとの接続
    • BigQuery Connector for Excel by google
    • DOMO(BI)
    • （ここでは触れられていないが（Beer Talk にて、@hakobera さんが発表）、GAS での使用も nice）
    • 分析したい軸となるマスターテーブル（次元テーブル）を用意。JOIN するのに使う
  • 38ページ目：標準SQLではない。ので、注意はもちろん必要だが、便利な関数とかも多いのでぜひ調べてみては。（2014/09/17 17:33 ページ数修正）
  • 38ページ目：どうせフルスキャンしてるし、という前提に立つと、見えてくるものがある（2014/09/17 17:33 ページ数修正）
  • 39ページ目：不必要なカラムには null をセットすることで、容量食わなくさせることができる（2014/09/17 17:33 追加）
  • 40ページ目：四方山話（2014/09/17 17:33 ページ数修正）
    • 「でかいデータのインポート、Google Data Store に置いてからインポートすると、同じ GCP ということで高速」
      • Google Cloud Storage（S3みたいなもん）のこと、かな？
    • Table Decorators の検索可能範囲は、直近 7æ—¥ まで

GAE/GoとManaged VM

  • by @ymotongpoo
  • スライド資料 -> https://preso.ymotongpoo.com/gcpjanight28.slide
  • Runtime の開発はシドニーでやってる
  • GAE/Go は、 GAE/PHP よりもユーザーが少ない...
  • ８ページ目：フレームワークの話。ロックインされるとかって話を GAE/J とかでよく聞いたけど、 GAE/Go でも同じなの？
    • 全然そんなことないよ、というのが、9〜16ページの間で書かれている
    • User とか Task Queue とかの appengine 特有のパッケージがあったり、main関数は必要なかったり、DB に Datastore を使う場合は多少ロックインしちゃうけど、その程度
  • メリット
    • spin upがはやい＝スパイクに強い
    • 手元で動かしているアプリケーションからの改修を小さいままに移植可能
  • 結論 ＝ GAE/Go は最強！

BigQueryと俺とFluentd

  • by @tagomoris:
  • スライド資料 -> BigQuery, Fluentd and tagomoris #gcpja
  • 8ページ目：table sharding inserts
    • テーブルあたりのクオータが厳しいので、sharding に対応した
    • データをいくつものテーブルに分散して入れる
      • こんなことをしても、 from 句に table を複数書けるので問題にならない :)
  • 17ページ目：パフォーマンスについて
    • 大量にデータを書き出す場合は table sharding 使いましょう
    • 書き込み部分だけをスレッド化する機能が fluentd にある。それを活用している
      • I/O待ち部分を並列化できる
  • 18ページ目：特徴
    • 認証について
      • auth_method compute_engine が便利らしい。秘密鍵うんぬんいらない
      • GCE 上でしか動かないけどね :-p 同じ GCP ファミリーだからこその成せる業。
    • スキーマについて
      • scheme_path
        • ファイルにスキーマ情報をjsonで書いて、 schema_path で指定
      • fetch_schema
        • 再起動したタイミングで自動で読み込んでくれる？
  • 19ページ目：API Quota
    • けっこう厳しい。
    • fluentd の既存のAPIでは検出できない部分での制限が多い
  • 20ページ目：クラウドをおもちゃにして遊ぶのは、環境を準備する必要がないので良い :)
    • 変な制約があることが多くて燃えるｗ

terraform + GCE

  • by @voluntas
  • スライド資料 -> Terraform 0.2.2 で GCE + Ansible を試してみた
  • Cloud Formation ã‚’ GCE で使うようにできるもの？
  • とはいえ、「GCE 周りを最低限サポートした」程度、という印象。最初はバグも
  • plan で dry-run 的な
  • apply で適用
  • インスタンスを管理できるのは魅力。provisioning もできる
  • local-exec、 インスタンスを生成する まえ に、何かをさせることができる
    • remote-exec は起動後。 chef との組み合わせがよさそう
  • provider、全然足りてない。これからに期待

BigQueryで大規模投票サイトを作った話

  • by @a2c
  • スライド資料、観測範囲では発見できなかった
  • 理想の投票は選挙のシステム。チートは無理
    • このレベルである必要はない。けど、目指す。
  • 色々対策などを考えた結果、とりあえず、「後先かんがえず全部のリクエストを全部 BigQuery に食わせる」ことに。
    • BQ なら、 DB やストレージとかのことを考えなくて良い！
  • 機械的なのも、ある程度は絞りたい
    • ある程度のリクエストパラメータを必須にすることで、 F5 だけ防ぐ
    • 保存先はcookie よりも ローカルストレージのほうが消しにくい
    • 合計時にIP重複除去
    • GA を投票ありがとうページに仕込んでおいて、コンバージョン数を取る
  • GASでグラフ化してリアルタイムでモニタリング
  • 大量に書き込みつつ、そこに全量カウントを同時並行で実行とかも平気でできる。それがBigQuery。
  • GAの値、びっくりするくらい正確。トータルの値は誤差未満、0.3%未満とか。

はじめてのBQ GAS

  • by @hakobera
  • スライド資料 -> はじめての BQ GAS - Speaker Deck
  • 14ページ目：GASにはcron的に使えるトリガがある！
    • 「1時〜2時の間」、とかっていう、ざっくりした感じ
    • このレベルで全然問題ないし、負荷的な頃合いを見計らったりとか、こっちで考える必要もない！
  • 21ページ目：日時レポート定義シートを作成。
    • このシートを参照してクエリ実行 -> 通知、という仕組みにしておけば、エンジニア対応なしにレポートの追加ができる！

Googler に質問したこと

BigQuery での「スキャンサイズ」の見積り方について

Q． フルスキャンだから、投入サイズ＝スキャンサイズ、と見て良いか。

A． 良いよ！

UDFについて

Q． ぶっちゃけ、UDF っていつくらいでしょうか？

A． 年内には出るんじゃないでしょうか。内部的にはもう普通に使っているので！

BigQuery における、 Temporary Table の専有するサイズについて

Q． BigQuery に対して投げるすべてのクエリの結果は、destination table を指定しない場合は 24時間で消える temporary table に出力されるということですが（参考）、この temporary table の専有するサイズも、使用料の対象になりますか？

A． Good Question ですね！ぜひ、15,000円の有料サポートに入って、そこで問い合わせて下さい！ :)

質問おわり。 Googler はとっても商売上手だった...。(｀；ω；´)

（ 2014/09/17 追記：この件について、別エントリに起こしました。BigQuery へのクエリの投げすぎに注意しよう（2014/09/18 追記しました） #gcpja - えいのうにっき ）

（まとめの内容は随時追記するかもしれません。）