社内勉強会の前回の記事からだいぶ日が経ちましたが、勉強会は休むことなく週一のペースでコツコツやっておりました。

タイトルにありますように今回の勉強会のテーマは週一の勉強会を5回費やして行われるほど、長くて多岐に渡る内容でした。それを今回まとめて紹介します。

今回の資料は『Webエンジニアのためのデータベース技術[実践]入門』(技術評論社)を使用しました。

執筆者はかつてDeNAに所属し、現在Facebookに在籍されており、そしてMySQLに大変精通している松信嘉範さんです。

データベースの現場に近いノウハウが満載です。進行は大きく分けて、データベースの選定基準、テーブル設計、高速化(&性能改善)テクニックでした。

本勉強会は、参加した社員が交代でキリのいいところまで音読し、質問をする者、それに答えられる者がホワイトボードの前に立ち説明を始めるという感じのスタイルで進みました。どんなに不慣れな質問をしてもよいという雰囲気があって、新人＆本テーマに関する知識の浅い私にはなによりありがたかったです。

重要なポイントはユーザーからの膨大なアクセス数にどう対応するか。いかに信頼性を高めるか。データ変更の頻度の違いに注目したテーブル設計の指針。（ディスクアクセスを発生させずに）メモリ上で処理を完結させる工夫。レプリケーション遅延対策。サーバー間にまたがるサーバー同士によるデッドロックという古いようで比較的新しいトラブルなどなど。

一通り終えてみて、データベースの基本から飽くなき探究心でMySQLの裏側まで把握した応用まで含まれており、データベースの知識だけでなくプログラマとしての高い志まで感じ取ることができ、大変勉強になりました。

有意義な勉強会でした。みなさんおつかれさまです。

『Webエンジニアのためのデータベース技術［実践］入門』松信嘉範　著

今回は上の書籍を使用しましたが、ちょっと古い雑誌ですが、その中で同じ著者が執筆したよく似た内容のコーナー「特集3:ビッグデータ時代のDB設計入門」がありますので併せて紹介します。

2011年10月22日発売

技術評論社『WEB+DB PRESS Vol.65』

最後にお知らせです。インフィニットループではデータベースに詳しいエンジニアを募集しています。データベースに興味のある方は求人ページで詳細をご覧ください。　→　インフィニット求人ページ

イベントの詳細はこちらです。

→　パソナテック　エンジニアカフェ×Aiming Lord of Knights の裏側見せます！
　
　
前半のクライアント側の発表をAimingの細田さんが、後半のサーバサイドの発表を私（松井）が担当させていただきました。

細田さんの資料は先行して公開されていますので、まずそちらを先に読んでから、私の資料を読まれると良いと思います。
　
今回は「ホントに裏側まで見せていいよ」とのお言葉をいただきましたので、普段の発表ではなかなか言えない部分まで、がっつりと記載しております。

口頭での補足ベースの資料になっておりますので、わかりづらいところもあるかもしれませんが、どうぞご覧下さい。

　
Aiming細田さんのクライアント側の発表資料はこちら

　
　
インフィニットループが担当させていただいたサーバ側の発表資料はこちら

あのVim検定が遂に、Android版になってマーケットに登場しました！

iPhone版と同様に問題のアップデート配信も予定していますので、
Androidユーザーの皆さんもぜひ挑戦してみてください！よろしくお願いします。

アプリの詳細についてはこちらのVim検定公式サイトをご参照下さい。
※収益の一部はウガンダの恵まれない子供たちの援助に使用させていただきます。

今回の勉強会では実際に仕事で活用している便利ツールの紹介ということで、
プロジェクターを使って実際にツールの使用感を披露したり、

プログラミングにおすすめのフォントがスライドショーで紹介されたり、

その他にもSkypeに関するテクニックや、作業時間の管理術、Vimの活用術などが紹介されました。

普段とは一風変わった形式の勉強会でしたが、有用な情報が多く共有された勉強会だったと思います。

インフィニットループでは様々なツールを活用しているエンジニアを募集しています。
詳細は求人ページをご覧ください。　→　インフィニットループ求人ページ

「Vim検定」ではレベル別の問題で己のVim力を確認し、鍛えることができます。
また、今後のアップデートで熟練のVimmerによる厳選された問題が追加される予定です。
皆さんの挑戦を待っています！よろしくお願いします。

アプリの詳細についてはこちらのVim検定公式サイトをご参照下さい。
※収益の一部はウガンダの恵まれない子供たちの援助に使用させていただきます。

なお、近日中にAndroid版のリリースも予定しております。
Android使いの方はお楽しみに！

サーバー監視ツールで MySQL を監視しているのにデータが多すぎて活用していない。という方はいませんか？その豊富なデータをパフォーマンス・チューニングに活用しない手はありません。今回はサーバー監視ツールのグラフを読み解いた実戦経験を元に、「これだけ見れば大丈夫」というツボをまとめてみました。

これだけ見れば大丈夫！　クエリ編　３つのつぼと５つのグラフ

• （その１）監視ツールが何を見ているのか知る
• （その２）監視のキモ、グラフ３点セット (Questions, Lock Waits と Transaction Handler)
• （その３）グラフでチェックする SQL チューニング ( Select Type と Handler)

シンプルでお勧め、サーバー監視グラフ化ツール Cacti

運用しているサーバーには、単純なネットワークの死活監視から始まってシステム全体の性能を監視するまで、様々なサーバー監視のインフラが必要となります。有名どころでは Nagios, Zabbix, Hinemos などがありますが、今回使っているのは Cacti　http://www.cacti.net/ というサーバーパフォーマンスグラフ化ツールです。監視項目のグラフ表示の他、しきい値を超えるとメール通知する基本機能も備えています。またテンプレートを自作し好みの項目をグラフにすることも出来ますし、自作テンプレートはネットからも入手出来ます。機能がシンプルですので、インフラ・エンジニアの別の仕事（運用の自動化とか）に浮気することなく、MySQL のパフォーマンスに集中出来るのもよい所です。

私が MySQL のための Cacti テンプレートとして使ったのは better-cacti-templates です。導入については　ググれカス http://ggrks.org/の記事 cactiの導入とApacheとかMySQLとかのtemplateの導入 などを参考にしてください。

（その１）監視ツールが何を見ているのか知る

グラフのデータを活用するには、データの意味、つまりデータをどうやって採集しているのか 知る事が重要です。better-cacti-templates が採集している MySQL データは、SHOW STATUS コマンドで表示される MySQL の統計情報の項目と、SHOW ENGINE INNODB STATUS コマンドで表示される文章を元にしたオリジナルな項目、の２本だてで構成されています。Cacti のグラフの意味を知るのは

1. SHOW STATUS の項目に同じ名前の項目があるか、あれば MySQL リファレンスマニュアルで意味を調べる
2. SHOW STATUS に無い場合は、それはテンプレートの独自項目なので、テンプレートのスクリプトを解読する

という手順になります。better-cacti-templates の場合はテンプレートのソースの scripts/ss_get_mysql_stats.php を見ると独自項目の内容の詳細がわかります。今回の記事で取り上げなかった Cacti のデータ項目が気になった方は、ぜひソースの解読に挑戦してみて下さい。

（その２）監視のキモ、グラフ３点セット (Questions, Lock Waits と Transaction Handler)

まず最初はパフォーマンス監視のキモであるグラフの３点セットです。チューニングというより監視が目的の場合の重要なグラフがこの３つです。まずは Questions から見ていきます。

SQL の種類のグラフ MySQL Command Counters

このグラフはどういう種類の SQL 文が実行されたかまとめたものです。単位はインターバル（デフォルト５分）毎の回数ですが  m はミリ、つまり1/1000 回です。例えば 100 m  というのはその５分間で発生した回数が 0.1 回ということで、50分で１回発生した、という事を示しています。

Com は Command の略で Com Select / Delete / Insert / Update / Replace はその名前のとおりの SQL の実行回数です。 Com xxx Multi と付いているのは複数テーブルを一括して Update するMySQL 独特の構文です。ここで注目すべきは Questions です。MySQLリファレンスマニュアルには簡素に「MySQL への問い合わせ回数」と記述されています。なんでもカウントしますが、ここだけに計上されるのは SET などの補助的なコマンドと、エラー応答です。SET が急に増えることはありませんので、上のグラフの点線部のように増加した場合は、何かエラーが増加しています。

エラー内容の調査にはアプリケーション側での調査が必要ですが、 とりあえず Questions だけが増加して来たら、何かの悪い兆候と思ってください。

ロック待ち時間を見るのに最適 InnoDB Current Lock Waits

監視３点セットの２点目はこのグラフです。データの項目は Innodb Lock Wait Secs ですが、この値は SHOW ENGINE INNODB STATUS で表示されるトランザクション情報のうち、”TRX HAS BEEN WAITING n SEC FOR THIS LOCK TO BE GRANTED” の n をシステムのトランザクション全部で合計したものです。ここでいうロックは行ロックやテーブルロックの区別はありませんが、パフォーマンスからみればロック待ちの時間はゼロが良く、この値が増加しているのも悪い兆候です。

上のグラフでは、ちょうど Questions と同じ時間帯で Lock Waits も上昇しています。表示中の  k はキロ、1000 です。２つ合わせるとエラーが増加してロックの待ち時間も増えている、となります。MySQL だと真っ先に疑われるのはデッドロックですが、この例では INNODB STATUS を見ても記録されていませんでした。さてどうしたものか？そこで生きてくるのが次の３点目のグラフです。

トランザクション状況を一瞥する MySQL Transaction Handler

このグラフは項目の名前どおりにコミット数とロールバック数をグラフにしたものです。グラフ点線部にそれまで無かったロールバックが記録されていたことがわかります。

デッドロックではなくても何かのエラーでトランザクションが アボートされるとロールバックが発生します。「元のクエリのロック時間」＋「更新を巻き戻す時間」＋「再実行時間」、、、、という具合に無駄に処理が増え、ロックの競合確率やロック待ちも増加し、レスポンスが悪くなります。

というように以上３点のグラフを見ればクエリで異常が発生していないかどうか監視できます。

（その３）グラフでチェックする SQL チューニング ( Select Type と Handler)

MySQL ではスローログを活用してプロファイリングするのが有効です。ところがデータ量が少ないシステム開発中にはクエリは高速に動いてしまい、スローログには記録されません。そこでさらに log_queries_not_using_indexes をセットして、インデックスを使っていないクエリ、インデックスを使っていても全件検索しているクエリを全て記録し、そこをチューニングします。ところが、小さいテーブルを SELECT * FROM Table しているものとか、全件コピーするために INSERT INTO .. SELECT … をやっているものとか、わかってて全件検索しているクエリも記録されるので件数がかなり多く負荷になります。そのため log_queries_not_using_indexes は本番稼働時には外されることも多いです。

さて、開発も最終段階でスローログの設定も本番と同じにしたとします。データが少ない今はスローログには何もひっかかりませんが、もしインデックス張り忘れなどのチューニング忘れのクエリが残っていれば、データの増加後に速度が低下して初めて気がつくことになります。クエリ全部に EXPLAIN を実行して検査するというのも現実的ではありません。問題が発生してからではなく、発生する前に未然に対応することは出来ないでしょうか？　そんなときに活躍するのがサーバー監視のグラフです。

SELECT の使い方を知る My SQL Select Types

クエリのチューニングはほぼイコール SELECT のタイプ、ということに尽きます。個別のクエリに対して EXPLAIN をすることでどのような実行計画を使っているのか知る事が出来ますが、このグラフを見ることでシステム単位でどういうタイプのものが実行されているのか、その全体像を知ることが出来ます。

Select Scan はテーブル（またはインデックスでも）の先頭行から全件検索（スキャン）をした回数です。Select Range は WHERE などの指定によって範囲が限定された探索を行った回数です。SQL のチューニングとして、「 SELECT にはインデックスを使用して探索行数や行ロックの範囲を少なくしよう」というのが一般的ですが、意図的に全件取り出す必要性もありますから、スキャンはゼロにはなりません。それでも Select Range  >>>  Select Scan というのがが望ましい状態です。上のグラフ例では反対に Select Scan が多くなっています。インデックスを使う余地のあるクエリが相当数あることがわかります。

もう一つのチューニングとして「JOIN はインデックスで行う」というものがあります。これがちゃんと守られているかどうかはインデックスのないカラムで JOIN すると記録される Select Full Join と範囲指定の効果はあるがやはりインデックスは使わず JOIN した時の Select Full Range Join （青の点線部）をみるとわかります。上のグラフでは 139 ミリ回という小さい値ですが、ここはゼロであることを目指しているので、見えた瞬間お！誰だ！という具合に気がづくことが出来ます。

クエリの I/O 動作を知ることが出来るグラフ  MySQL Handlers

Handler というのは MySQL のストレージエンジンのインターフェースで、その種類を見ることで InnoDB がファイル I/O 、ディスク I/O に近いローレベルでどういう仕事をしているのか見ることが出来ます。

Write, Update, Delete は名前のとおりの動作なので割愛して、ポイントとなるのは以下の Read 系の操作です。

• Handler Read First テーブルやインデックスの全件検索（スキャン）の際には、まず最初に先頭レコードの取得を行います。その回数が Read First です。
• Handler Read Key インデックスを使ってさらに範囲指定の効果が効いている場合、キー値に基づいてジャンプして行を読み取る操作を行います。その回数です。
• Handler Read Next キー値に基づいて行を特定した後、後続の行を読んだ回数です。
• Handler Read Prev 内容としては Next  と同様で、キー値でポイントを決めた後、その前の行を取得する操作です。
• Handler Read Rnd スキャンを行う場合のアルゴリズムとして MySQL ではランダム探索が使われます。Handler Read Rnd の Rnd は Random のことです。全件検索のためにランダムにジャンプした回数がこの値です。
• Handler Read Rnd Next ランダム探索によってポイントを決めた後、引き続き後続行を読み取った回数になります。

Handlerr Read First は全件検索あたり１回しか計上されないので読み取り回数と比べると小さくてグラフでは見えませんが、数字を見ることで全件検索の回数の傾向がつかめます。同様に Handler Read Rnd と Handler Read Rnd Next を見ることで、全件検索によって読み込んだ行数がわかります。

上の２つのグラフを総合すると「全件検索する Select の割合が多いが読み込んだ行数の割合は少なかった」ということがわかります。このことから、チューニングされていないクエリがかなりあるものの、この段階ではあまり影響が出ておらず、今後データ量が増加すると影響が出るかもしれない、ということまで知ることが出来ます。

最後に

以上３つのツボ５つのグラフを見るだけで、実行されている SQL の挙動をつかみパフォーマンスチューニングへと活かすことが出来ますので、みなさんも是非ご活用ください！

次回後編は　これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（システム編） を予定しています。ご期待ください！

ーーーー

インフィニットループではプログラミングやインフラが好き、というエンジニアを募集しています。詳しくは募集ページ　http://www.infiniteloop.co.jp/recruitment/ まで

わなの狩猟免許を持っているので社内でそう呼ばれています。

今日は週に一度の勉強会の日でした。

われわれと同じようにソーシャルゲームを開発しているドリコムさんの、サーバー負荷対策のスライドをみんなで熟読するのがテーマです。

勉強会の時間になると。。。。

人がぞろぞろと入ってきます。

今、まさにソーシャルゲームの案件に関わっている人たちです。

途中、専門的な内容は社長の松井さんから説明。

わたしたちインフィニットループもソーシャルゲームの開発をしているので、スライドの内容を見たメンバーから
「あるある～笑」
との声があがることもしばしば。

松井さんは
「ドリコムさんみたいにうちももっと、新しい技術とかを取り入れていかないとなー」
とかつぶやいていました。

ソーシャルゲームは安定運用がとても大切なので、会社としては新しい技術をすぐに取り入れるのが難しかったりするんです。
そこはメンバーが各自が空き時間を見つけていろいろ試していくべきなんですね。
僕もがんばらないと。

インフィニットループでは、新しい技術やサービスに興味関心の強いエンジニア／アルバイトを募集してます。

一緒に最先端の技術を学び合う仲間の応募、待っています！

くわしくはこちら　→　インフィニットループ求人ページ

弊社、インフィニットループでは毎週金曜日に社内勉強会を行っています。
今回は弊社スタッフのmichi氏を講師として、「最低限シェル＆シェルスクリプト」のテーマで勉強会を行いました。

使用された講義資料：
http://www.ep.sci.hokudai.ac.jp/~inex/y2011/schedule.html
http://www.ep.sci.hokudai.ac.jp/~inex/y2011/0513/lecture/pub/

資料から発展し、実際の業務内容にも触れた補足説明も大変興味深く感じました。
プライベートでは中々触れる機会がありませんでしたが、大規模な開発プロジェクト内で円滑かつ迅速な作業を行うには、必要不可欠な技術であることがよく理解できる内容の講義でした。

インフィニットループでは、業務用私用問わず開発作業にシェルスクリプトを活用されているエンジニア／アルバイトを募集しております。
詳しくはこちらをご覧ください　→　インフィニットループ求人ページ

弊社、インフィニットループでは毎週金曜日に社内勉強会を行っています。
今回の勉強会では、弊社開発プロジェクトを実例としたインフラに関わる負荷試験のおはなしを、
松井社長が直々に講師として解説されました。

社外秘となるため、使用されたスライド資料は本記事には掲載されることが叶いませんでした…残念です。

尊敬すべき先輩の貴重な一枚

負荷対策へコストを最大限に掛けるわけにもいかず、かと言って蔑ろにも出来ず、
葛藤しながらも現実を見定めていくことが必須であるということが、よく理解できる内容でした。

インフィニットループでは、SNSなどの高負荷対策といったインフラ周りに長じているエンジニア／アルバイトを募集しております。
詳しくはこちらをご覧ください　→　インフィニットループ求人ページ

弊社、インフィニットループでは毎週金曜日に社内勉強会を行っています。
今回は社内のTDDに対する理解を深めるために、スライド「TDDを実践してわかった TDDつまづくあるあると自分なりの乗り越え方まとめ」を読む会が行われました。

本資料は、@remore氏がTDDBC in Tokyo 1.5 でLTに使用したものです。

スライド資料を読み終えた後は、Jenkins, Selenium,といったテストツールについても紹介がありました。

TDDは魅力的なメリットも多くテストコードの積極的な導入が望ましいですが、現実と理想の壁も高そうで、上手に付き合っていくことが大切だと感じました。

インフィニットループでは、テスト駆動開発に詳しく、レガシーコードを駆逐する意欲に溢れたエンジニア／アルバイトを募集しております。
詳しくはこちらをご覧ください　→　インフィニットループ求人ページ