アルパカログ

Webエンジニア兼マネージャーがプログラミングやマネジメント、読んだ本のまとめを中心に書いてます。

YAPC::Asia 2015 参加レポート

f:id:otoyo0122:20200909131449p:plain:w300

YAPC::Asia に参加したのは2013年以来2度目で、今年の会場は東京ビッグサイト会議棟でした。

今回1番勉強になったトークは @kazeburo 氏の http://yapcasia.org/2015/talk/show/86ebd212-fab3-11e4-8f5a-8ab37d574c3a で、内容は主に ISUCON で重要となるアプリケーションや MySQL のチューニングについてでした。
ISUCON だけでなく普段の業務にも活用できる非常に有益な情報だったので、学んだことを記憶の範囲でまとめます。

ログのプロファイリング

いきなりアプリケーションのソースコードを読んで勘を頼りに・・・ではなく、まずはログをプロファイリングしてどこがボトルネックになっているか調べるのが大切だそうです。

アクセスログ

Apache アクセスログにリクエストの処理にかかった時間を出すには %D をつけます。Apache の再起動をお忘れなく。

Slow Query

すべてのクエリを Slow Query に出して解析します。

set global slow_query_log=1;
set global long_query_time=0;

元に戻すには MySQL を再起動するだけで良いので簡単とのことです。

統計ツール

ちょっと記憶に自信がないですが、トークで紹介されていた統計ツールは下記だったと思います。

プロセスが何をしているか

strace コマンドが使えるそうです。

リソース監視

top コマンド以外にも iftop (トラフィック), tcpdump, iotop (Disk IO), dstat (いろいろ) コマンドが使えるそうです。

MySQL のチューニング

MySQL のチューニングでは常にB+木をイメージするのが重要とのことです。

innoDB では Primary Key がクラスタインデックスになっており、リーフノードにデータへのポインタが格納されています。一方、セカンダリインデックスではリーフノードに PK が格納されているため、セカンダリインデックスを用いた検索では少なくとも2度検索が走ってしまいます。

また、ページングに OFFSET 句を使ってしまうと後ろのページに行くにしたがって捨てられるデータが多くなってしまいもったいないです。

解決策の1つとしては、2度のクエリに分け、まずセカンダリインデックスから id (PK) だけを、次に id を元に必要なページのレコードを取得するようにすれば、1番目のクエリが Covering Index となるので高速だそうです。

最後に

質疑応答で、私も気になっていた「アプリケーションだけや DB だけにとらわれない幅広い知識を得るにはどうしたら良いか?」という質問に対して氏が「大規模サービスの運用に携わってみること」と回答されていたのが印象的でした。

今回学んだことを業務に活用し、いつかは私も氏のように高度な技術力を持ったエンジニアになれたらと思います。