もちろん2日チケットを買ったので、2日目もいってきました。
ちゃんと起きて10:00〜のセッションに間に合いましたよ。
Google Cloud Platformの謎テクノロジーを掘り下げる (Kazunori Sato)
メモ
googleはサーバベンダーでもある。自社で開発している。
GCPのラックは普通にgoogleのサービスのものと同様。
app-engineの大きい顧客であるsnap chatは１００万リクエスト/秒
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レコードを返すもの
MySQL５．６GTID と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)
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するのもいいけどそれは自発的にやるべきだしやらないことによってデメリットがあるからやるってわけじゃないよね。と思う