1日目も併せてご覧くださいませ。
2日目は午前からどっぷりセッション漬けでした。 色々な刺激を受けつつも非常にリフレッシュできました。
今回はこれを聴きに来ました。
実は第1回に参加してました。別段ドヤれる成績ではなかったですが。
元々iSUCONは旧ライブドアさんが「サーバ大量に仕入れたんでサービスイン前にこれ使ってイベントやろうぜ」的なものだった記憶があります。
ISUCONに勝つためのポイントは以下の通りです。
- 準備
- チーム編成:コミュニケーションコストを減らすため、できれば同じ業務のメンバー、あるいはお互いをよく知っているメンバーがよい。
- コミュニケーション:チームメイトとの会話を重視する。問題をいち早く相談して解決する(悩まない)。決まったことはメモ(手書き)して書き出す。後戻りを減らす。
- 時間配分:チームで認識を合わせる、最後の30分は再起動テストに残す
- 事前準備
- チューニングの進め方
- プロファイリング
- アクセスログ解析
- MySQL SlowLog解析
- クエリ実行回数と頻度の両方を見る、long_query_time=0にして実行→全てのクエリがslow queryの対象にする。
- アプリケーションのプロファイリング
- サーバの負荷を見る
- top,iftop,iotop,dstat
- ISUCONではあまりIO Boundにならない
- サーバ構成の把握
- チューニングの方向性を決める
- ISUCONではサーバのおかわりはないので与えられたリソースを効率よく使い切る
- 効率良いCPUの使い方を知る
- コンテキストスイッチングを避ける
- 何もしないアプリケーションに近づけていく
- 参照・通信・プロセスを減らす
- Webサーバの選択:Apache vs Nginx vs h2o
- Apacheはコンテキストスイッチが大量発生
- Nginx 1個のプロセスで効率よく通信を処理
- Nginx vs h2o = プロセス vs スレッド
- 限られた環境ではapacheは不利
- アプリケーションのチューニング
- 外部プロセスの起動
- HTMKテンプレート処理
- テキスト/画像変換処理
- RDBMS/Cacheとの接続
- N+1問題
- DBチューニング
- B+Treeの特性を知る(いつも心にB+Treeを)
- プライマリキーとプライマリキーじゃないインデックスのアクセスの違い(プライマリキーが速い)
- 捨てるデータの読み取りを最小限に
- 例:MySQLのOFFSET処理(使わない部分は捨てられる) * まずはidだけ取る(covering index)、offset limitに頼らないクエリ構成になるようにする、NoSQL
- B+Treeの特性を知る(いつも心にB+Treeを)
- 大事なこと
- 初期状態を記録し、いつでも戻せるように。
- 変更を都度記録し、壊れる前の状態に戻しやすくする
- 前日はよく寝ましょう。体調は重要。
- 諦めたらそこで終了。粘れば速くなるかもしれない。
Consulを使ったHA化の構築を行ったが、様々な問題があって結局Consulは使わずに本番運用を開始した、という話。
HAは仮想IPを用いて構築する方が一般的かと思いますが、Consulを使ってDNSベースのHAを構築していました。
個別の話はDNSベースならではの話、あるいはインフラ構築あるある話など様々な苦難を乗り越え(乗り越えてない?)たエピソードが満載。
得られたポイント(教訓)は
- どんなに炎上してても負荷試験はやろう
- 使うパッケージはきちんと理解・検証が重要
とのこと。
- CPU2コア
- メモリ8G
- ディスク450G のマシンで2億件のシリアルデータ(シリアルコードを含むレコード)を扱うという無理ゲーの話。(受託はつらいよ)
事前のテストではランダム性のないシーケンスを元に Insert/Updateしたら案外早かったので、実データを使ったら所要時間が全く違っていてお客さんの前で辛いことになったそうで。
オンライン処理じゃない大きなデータ投入の際はアーカイブログ切ったり、インデックスやFKの作成は後でやったりと別のアプローチが効果的なことが多いです。(個人的な経験則)
元々ハードウェア的にもきつい案件ですが、DBで頑張るよりアプリやスキーマレベルでどうにかすべき部分も多かったようです。
TLで流れていましたが、これが参考になりそうです。
MySQL 5.6における大量データロード時の考慮点 - SH2の日記
直前のセッションと全く同じ結論ですが、
- 負荷試験はやろう
勘に頼らない意思決定、障害検知(監視)、探索的な解析などデータ解析は重要なビジネスファクタになっています。
その中で最近はどのようなデータ分析基盤が作られているかをRDBから巨大データのリアルタイム処理まで順を追った解説がなされたセッションでした。
RDBMSを用いたデータ解析
- RDBMS単体(ETL + Query)
- Parallel RDBMS(Optimized for OLAP workload、カラムストアインデックスなのでinsertやupdateのオンライン処理は超苦手)
- 並列分散データベースはデータの配置にノウハウが必要
RDBMSから分散ファイルシステムを用いたデータ解析へ
基本用語
Apache Tez:タイムスライスではなく、DAGベースの処理で最適化されたクエリで処理
- Hadoopにはもう単一障害点はもう無い!!!
Hadoopを自社で持ちたい→やめたほうがいい。
- どうしても使いたい!→ディストリビューションを使ったほうがいい。
データの集め方
データを溜めて解析するやり方はデータ量が増えてきたらつらい
MPP(Map Parallel processing)クエリエンジン
- 独自のストレージを持たず既存のストレージからSchema on Readを行うクエリエンジン。prestoなど。
リアルタイム処理
キューシステム
- データ送信をプッシュ型からプル型にすることができ、送り先のリソース都合に合わせたデータ送信が可能。緩衝材的な。Apache Kafkaなど。 「解析したいけど運用したいわけじゃない(運用はつらい)」
外部サービスを使おう(データ解析基盤は作るな!運用はつらい!サービスにまかせよう!)
その他
QA
- 可視化のダッシュボードはどう作るか
- →自分で作るとつらい。サービスを使ったほうがいい。お金をかけるほどいいツールが使える・・・
2006年から始まったYAPC::Asia(ヤプシーエイジア)。 歴代のキーマンをゲストに10年間の歴史を振り返りながら数々のエピソードを語ってもらうというセッション。
前の方じゃないとゲストの方々の顔が見えなかったので、rebuild fmを聴いているような感覚でした。
中身を書いても面白さがイマイチ伝わらないので聴けなかった人は動画配信を待ちましょう!
(2015/8/28 配信来ました!)
圧倒的なスピード感、繰り返される爆笑、と「俺の知ってるLTじゃない!」と戦慄。
直前のセッションで「LT(Lightning Talk)はYAPC(ただしアメリカ)発祥」「高橋メソッドはLTから生まれた」というTipsを聞いて、なるほどこれが「YAPCか」という感じでした。
昨日のYet Another Perl Cooking - YAPC::Asia Tokyo 2015がイマイチなじめなかったのは自分のYAPC経験値が足りなかったからだったんだ、と分かりました。
個人的にはYAPCは昨年からの参加でしたが、今年で最後だと思うとYAPCを作り上げてきた人たちはこれからどこで活躍するのだろう、と気になり出してきました。
2000人級のカンファレンスイベントを支えた大勢のスタッフの皆様、本当にお疲れ様でした。