Chonaso's Commentary

InternetやIT技術などについて知ったこと、試したこと、考えたことを書いていきます。

YAPC::Asia Tokyo 2015 2日目 #YAPCAsia

Perl 勉強会 監視 インフラ MySQL HTTP

1日目も併せてご覧くださいませ。

2日目は午前からどっぷりセッション漬けでした。 色々な刺激を受けつつも非常にリフレッシュできました。

今回はこれを聴きに来ました。

実は第1回に参加してました。別段ドヤれる成績ではなかったですが。

元々iSUCONは旧ライブドアさんが「サーバ大量に仕入れたんでサービスイン前にこれ使ってイベントやろうぜ」的なものだった記憶があります。

ISUCONに勝つためのポイントは以下の通りです。

  • 準備
    • チーム編成:コミュニケーションコストを減らすため、できれば同じ業務のメンバー、あるいはお互いをよく知っているメンバーがよい。
    • コミュニケーション:チームメイトとの会話を重視する。問題をいち早く相談して解決する（悩まない）。決まったことはメモ(手書き)して書き出す。後戻りを減らす。
    • 時間配分:チームで認識を合わせる、最後の30分は再起動テストに残す
  • 事前準備
    • Private Git Repository、メンバーのSSH公開鍵収集、Wiki、秘伝のタレ(技術ノウハウ集など)、Chat room,、技術選択についての簡単な打ち合わせ
    • 過去問を解く。EC2やGCPのクーポンを準備。過去問解いたらインスタンス落とそう。
  • チューニングの進め方
    • レギュレーションや当日の説明をよく読む。スコアの算出方法や失格条件は特に重要 　* 開始したらまずベンチマークを動かす(はずれインスタンスを引いていないか、など)
  • プロファイリング
    • Webアプリケーションで起きていることを知る 　　* アクセスログ解析、MySQLのSlowLog解析、アプリケーションのプロファイリング、サーバ負荷、これらのデータを読み取る練習。
  • アクセスログ解析
    • ベンチマークツールがアクセスしている先を知る、頻度とレスポンス時間をバランスよく見る
    • スコアに効いてくる重要な部分を見極める(無関係なところをチューニングしても仕方ない)
  • MySQL SlowLog解析
    • クエリ実行回数と頻度の両方を見る、long_query_time=0にして実行→全てのクエリがslow queryの対象にする。
  • アプリケーションのプロファイリング
  • サーバの負荷を見る
    • top,iftop,iotop,dstat
    • ISUCONではあまりIO Boundにならない
  • サーバ構成の把握
    • それぞれどのようなサーバ、ミドルウェアがどんな設定で動作しているか
    • 過去には設定のtypoや罠もあった！
  • チューニングの方向性を決める
    • ISUCONではサーバのおかわりはないので与えられたリソースを効率よく使い切る
    • 効率良いCPUの使い方を知る
    • コンテキストスイッチングを避ける
  • 何もしないアプリケーションに近づけていく
    • 参照・通信・プロセスを減らす
  • Webサーバの選択:Apache vs Nginx vs h2o
  • アプリケーションのチューニング
    • 外部プロセスの起動
    • HTMKテンプレート処理
    • テキスト/画像変換処理
    • RDBMS/Cacheとの接続
    • N+1問題
  • DBチューニング
    • B+Treeの特性を知る(いつも心にB+Treeを)
      • プライマリキーとプライマリキーじゃないインデックスのアクセスの違い(プライマリキーが速い)
    • 捨てるデータの読み取りを最小限に
      • 例：MySQLのOFFSET処理（使わない部分は捨てられる） 　　　* まずはidだけ取る(covering index)、offset limitに頼らないクエリ構成になるようにする、NoSQL
  • 大事なこと
    • 初期状態を記録し、いつでも戻せるように。
    • 変更を都度記録し、壊れる前の状態に戻しやすくする
    • 前日はよく寝ましょう。体調は重要。
    • 諦めたらそこで終了。粘れば速くなるかもしれない。

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から分散ファイルシステムを用いたデータ解析へ

  • 基本用語

    • Schema on Write:RDBMSはこれ。書き出す時にスキーマに合わせて書く。クエリ処理を速くするため。
    • Schema on Read:データを書く時はスキーマを考慮せずにシンプルに置く。読み込む時に最適な型に変換する。
    • Data Lake:一つの巨大なストレージにデータに置く。HDFSなど。ベンダーによってそれ以降の解決法が異なる。

  • Apache Tez:タイムスライスではなく、DAGベースの処理で最適化されたクエリで処理

  • Hadoopにはもう単一障害点はもう無い！！！

  • Hadoopを自社で持ちたい→やめたほうがいい。

  • データの集め方

データを溜めて解析するやり方はデータ量が増えてきたらつらい

  • MPP(Map Parallel processing)クエリエンジン

    • 独自のストレージを持たず既存のストレージからSchema on Readを行うクエリエンジン。prestoなど。

  • リアルタイム処理

    • Apache Storm:分散リアルタイム計算を実行するエンジン。twitterが使っていたことで有名。行単位の処理。コードのデプロイが必要。
    • Norikra:コードではなくSQLで処理。分散しない！

  • キューシステム

    • データ送信をプッシュ型からプル型にすることができ、送り先のリソース都合に合わせたデータ送信が可能。緩衝材的な。Apache Kafkaなど。 　 「解析したいけど運用したいわけじゃない(運用はつらい)」

  • 外部サービスを使おう(データ解析基盤は作るな！運用はつらい！サービスにまかせよう！)

    • Amazon Redshift(リソースを決めてその中で実行、急激なワークロードの耐性はない)
    • Google BigQuery(Googleは巨大なプラットフォームでみんなでシェア。パフォーマンスはコントロールできない)
    • TDはData Lakeを提供
    • Azureもできるって。

その他

  • SQLを使おう！
    • (当分は)ストリーム処理すらSQLになりそう。
    • SQLは覚えよう！

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人級のカンファレンスイベントを支えた大勢のスタッフの皆様、本当にお疲れ様でした。