YAPC::Asia 2015に行ってきた ~2日目~

  • 1
    いいね
  • 0
    コメント
この記事は最終更新日から1年以上が経過しています。

もちろん2日チケットを買ったので、2日目もいってきました。
ちゃんと起きて10:00〜のセッションに間に合いましたよ。

Google Cloud Platformの謎テクノロジーを掘り下げる (Kazunori Sato)

https://speakerdeck.com/googlecloudjapan/deep-dive-into-google-cloud-technology

メモ

googleはサーバベンダーでもある。自社で開発している。
GCPのラックは普通にgoogleのサービスのものと同様。
app-engineの大きい顧客であるsnap chatは100万リクエスト/秒

BigQuery超早い

400GBに対してNo INDEXで正規表現ありでも10秒ぐらい
Hiveでやると遅い
10億行と10億行の JOIN に30秒かからない

VM

各クラウドサービスはVMつかってない。コンテナにしてる
クラウドサービスでVM使うのはオーバヘット
GoogleはCell単位
GoogleのDCのCPU使用率高い

GCE Load Balancer

public DNS
8.8.8.8
日本から見ると台湾 アメリカだとアメリカ
リージョンごとに違う経路情報やってる
TCP anycastを安定的に実装してる.
そのため、global IP 1つでバランシングできる

Google cloudでおきてること

deep lering

教師無し学習で猫だとわかった
Androidの音声認識とかもdeep learning
Vision API for Google play Services
顔認識ができる
笑っているのかとかだせる。
これが第一弾

質疑応答

Q. app-engineのインスタンス アメリカにしかないけどレイテンシ気になるよね
A.がんばってます。いい感じのがいい感じのときにサービスリリースされる。

 我々はどのようにして冗長化に失敗したのか (Kenji Naito)

Webサービスの前提

ずっと動いてほしい
必ず壊れる
これを両立してほしい

冗長化

冗長化しても障害発生時に切り替わらないこと多いよね。

式年遷宮インフラストラクチャ

→ スタンバイとアクティブをころころ入れ替える

Master slaveをどういれかえるか

Redis
→Redis centinel

どうアプリに通知するか

Consul使う
Consulはいい感じにDNSレコードを返すもの

MySQL5.6GTID とMySQLfailover

遷移実行前と遷移実行後に任意のコマンドに実行できる

MySQLで2億件のシリアルデータと格闘したチューニングの話 (さいけん)

前提

商品購入のシステムでシリアルを入力して紐付けたい。
シリアルマスタと商品の紐付けしたい。
シリアルマスタ 2億件
出来上がったもの(商品シリアルヒモ付け) 1億件

サーバスペック

2コア メモリ8G/HDD 560G /tmp2G

負荷テスト

count に84秒 CPU 80-85%

ORDER BY や alterしたときに /tmpが枯竭

tmp_dirを物理ディスクに変更したけど50GBぐらい →運用で回避した
商品シリアルヒモ付けデータが28GB

insertが意外と早い

LOCAL DATA で3億件登録が70分ぐらい
と思ったら実データで2億件登録しようとしたら75時間かかった

負荷テストのときより遅くなった原因

負荷テストのときは連番だけど実データはランダム
→insertのときにindexの再生成

8000万件くらいから遅くなった原因

innodb_buffer_poolが枯竭
innodb_buffer_pool_izeを1/10にした
250MBで実行した場合340万
500MBで実行した場合700万ぐらいから遅延
データ量が増加してinnodb_buffer_poolが固結するとinsertが大幅に遅延
→メモリを増やすことで対応

updateではまった話

負荷テストのときは100万件74秒
max:100万件 1万件ごとにコミット
シリアルマスタからステータスが未使用のものを取得
updateが遅い理由
→indexの再構築
ステータス管理をやめて管理テーブルを作成してupdate自体を不要に

まとめ

インデックスの再構築怖い
今後 差分バックアップしたい
パーティショニングとか使いたい
innodb_buffer_pool_sizeは大きい方がいい
主キーはシーケンスにした方が早い
負荷テスト大事
実際に近いデータでやった方がいい

データ分析基盤を支える技術(Masahiro Nakagawa)

セッションをまとめると

いまビックデータとか流行ってるけど、それを構成する各要素の話。
自社で分析基盤を持つと運用つらいからそういうのは外部のサービスをうまく使っていきましょう。

データ分析のコンポーネントの話

・人間の感は割とあたるけど可視化したほうがいい
探索的にデータを解析する。
・今後どういうのが効果あるかわからないからいろんな角度から可視化
・仮説を立てるために可視化する

データを分析する(貯める)プラットフォーム

RDBMSに貯める

・使うのが簡単で、分散処理のはまりどころはない。
・時系列に増えていくものに強くない
→並列分散したRDBMSを使う

Parallel RDBMS

OLAPモデルを踏襲してネットワーク間のロスをなくしている
欠点として1行更新がや
→そんなうまくはいかない
ユーザのノウハウ必要
どのキーをもとに分散するか
どのキーでソートするかを決めた上で、
クエリを決定するひつようある。
カラム変更とかきつい

Data Lake

Hadoopみたいなやつでのスキーマのマネジメント生データをいれる。
Data Lakeが変換する。
HDFSをDataLakeとして使っている

Apache Hadoop

Hadoopはもう概念化してる。
Hadoopには単一障害点がない。
Hadoopはソースからビルドできない→おれら(TD)やってるし・・
Hadoopを自社で持ちたい場合はなるべくディストリビューションを使ったほうがいい。
ただし最新のものを使いたいとかならばコミュニティバージョンを使う
TD はpatch投げていて、masterまであがるのはおそいからコミュニティバージョン使うのも視野にいれている。

Apache Tez

Map-Reduceを効率のよい実行フローを勝手に生成して実行してくれる

データを収集するツール

build loadするツール

Embulkというツール。TDがリリース
Spoop Hadoop界隈でよく使われている。

Straming loadするツール

Fluentd この発表の人(中川さん)がメンテナーしてる。
そういえば、fluentdのステッカーいただきました。ありがとうございました。

Flume

Apacheのプロジェクト
ためたデータに直接投げたい
すばやく返したい

MPP query engine for data stores.

バックエンドはなんでもいいからクエリ投げたい

presto

バックエンドはhadoopに限らない
サマリーとかはHive
DashboardはPresto
Presto使えばその場で見れる
速報値をほしい

APache Storm

でてきたデータをStorm上で解析してどっかにだす
1Recodごとにクエリが走る
fluentdと同様のmicrobatch方式も

Norikra

SQLにそってデータを処理してくれる
ただし、分散しない
fluentdつかってればadonでいける

Apache kafka

分散キューシステム
pushしたデータをpullできる
なにがうれしいの
送り先のリソース側が都合にあわせてとってこれる

外部サービスの話

解析したいけど運用したくない時は以下のようなサービスを使えばいい

Amazon Redshift

Google BigQUery

きまったモデルのもと運用されている
決まったモデルにしたがえば簡単にできる
なんかブラックボックスの技術使ってる

TD

オープンソースをフルにつかってData Lakeを提供しているような感じ
様々なかたちでクエリ投げられる

まとめ

データ分析基盤を作るのはやめましょう。
運用負荷がかかるので。
cloudのサービスを使った方が便利
エッジが聞いている場合はつくったほうがいい
SQLはちゃんと使う。

サンタクロースを支えるIT技術(masayuki ishikawa)

まとめると

ボランティアとかでも趣味エンジニアリングができて貢献できる。
好きなツール、好きな技術を好きに使わせてもらえるので、モチベーションにはなる。
今時のレンタルサーバは無理やりgitいれられる

perlがメインじゃない現場でもperlを使う(AdTech現場編) Masaru Hoshino

まとめると

ソースが規約にあってないものがあった

一回既存ファイルを修正してphp-cs-fixerが使えるようにした。
perlの時はブラックリストにいれて分別して、新しいものはガイドラインに従うようにした。
これで、目グレップでコーディング規約にあってるかわかるようになった。

cron-tabのリリースうっかりミスやるよね

cront.txtっぽいファイルで設定してリリース。
cronのテストを期待値をつかってテストしている。
cronexeption phpライブラリを使い、コメントを期待値としてテストした。

LT

MySQL5.7の罠があなたを狙っている(yoku0825)

http://www.slideshare.net/yoku0825/mysql-57-51945745

default_password_lifetime =360

360日で突然の死

16桁ハッシュの古いパスワード廃止

新しいパスワード使おう

YAPC全体のまとめ

・非perlエンジニアでも楽しめた。
というよりオープニングセッション以外は全部perlそんな関係ないやつだし
・会場のWifiが超快適だった。
CONBUさんすげぇ。 http://conbu.net/
・会場キャパ問題はどのカンファレンスでも発生しちゃうな。
自分は運良くほとんど聞きたいセッションは聞けたけど、(聞けなかったのは2日目15:30~のHTTP2時代のWebだけ)
人気セッションだと入場制限もかかちゃって、せっかくチケット買ったのになーって人が多かった気がした。
とはいえ、これはカンファレンスやる上でどこでも起きうる問題だし、しょうがないなーって気はする。
・懇親会のローストビーフが美味しかった。
懇親会は人酔いした+コミ症なんで^^;ってのもあって、ちょっと早めに切り上げたけど何人かとは話はできた。
あの懇親会スタイル人の声が聞きづらい+自分の声がどこまでだせばいいかわからないのもあって苦手なんだよね・・・
・モチベーションは回復した。
やっぱり会社内で仕事していると、この仕事意味あるのかなとかネガティブになりがちなんだけど、外に目を向けることによって(会社はまあそこそこにして)OSS活動したり、変な技術つかって楽しんでみたりしてもいいんだなーというのに気付いたのがよかったかな。
・以外と発表者がやっていることは自分もやっていることだったりする。
さすがにES6とかHTTP2には手を出してないけど、クエリのチューニングとかマイクロサービスの考え方とかは、まったくできてないというわけではないし、うまくまとめて発表してみたいな感はあった。
・エンジニアとして、情報のINPUT/OUTPUTの重要性
やっぱり、エンジニアとしては、情報のINPUTはそうだしOUTPUTも必要だと。それはカンファレンス聞きながらtwitterするでもいいし、メモ書きをあとからまとめるでもいいし、何かしらアクションを起こすということは大事だと思う。あと、(qiitaでこんなこと書くのはなんだけど)、ただのTIPSだけの情報はそれはそれで重要だけど、どうしてそう考えたかというプロセス部分こそが重要なんじゃないかなと。また、OUTPUTするのもいいけどそれは自発的にやるべきだしやらないことによってデメリットがあるからやるってわけじゃないよね。と思う