1.この記事で達成したいこと
- 以下の本を読んだので感想や学びを書き残す
- また、そのような感想を抱くことになった自分の担当業務内容や役割も書いたほうが改めて本書を手に取る際にて助けになるだろうと思い、書いていく
2.本書を読んだ当時の担当業務や役割
- 主な担当業務はtoBのWebサービスの運用兼開発と問い合わせ対応
- そのなかで「xxx機能がうまくできないんだけど〜」というお問い合わせを受けてログを追うことがある
ここで肝となるのが、問い合わせの背後に見え隠れする「見るべきログのアタリ」をどれだけ早く見つけることが出来るか？また、そこから何を読み取り、次の一手を決めるか？（回答する？さらなる調査をする？機能改修？etc…）- ※ いわゆる「パフォーマンスチューニング」はやっていないが、興味はある（技術検証の一環で見様見真似でパフォーマンス測定なるものはやったことはあるけど。。）
- アルゴリズムやネットワーク、データベースといった大学の学部レベルでのコンピュータ・サイエンスを勉強する社会人学生でもある
- 本書はいわゆるパフォーマンス測定でご飯を食べるインフラエンジニアだけではなく、僕のような学生やWebアプリケーション開発エンジニアも学びがある一冊だと思う
- 名著とされる「詳解 システム・パフォーマンス | Brendan Gregg, 西脇 靖紘, 長尾 高弘」は読み進めることが難しく感じた
- 一方で、本書は文字どおり多くの図やイラストを用いて、システムパフォーマンスについて解説されていると感じた。
3.感想や学び
- 本書は、
「情報科学を学ぶことの大事さ」というコラムを設けて情報科学を学ぶことの重要性について説いており、大学での勉強をがんばろうと思えた パフォーマンス測定の基本について、"はさみうち"という言葉で表現していたことが印象的- そもそも"はさみうち"とは
- パフォーマンス測定について端的に表していると感じたが、大学の極限の授業で"はさみうち"について学んでいたという点も印象に残った理由かなと
e.g. サーバーAのログの該当箇所のタイムスタンプとサーバーBの該当箇所のタイムスタンプだけずいぶん開きがあるようにみえるな、、、。
<クライアントPC> <--> <サーバーA> <- ??? -> <サーバーB> <--> <サーバーC>
- パフォーマンスを取得するコマンドが出力する情報にはいくつか種類がある
- サマリ形式
- 一定期間の情報を合計もしくは平均で表示
- 「調査の最初に概況を押さえたい」ときに効果的
- e.g. sarやvmstat
- イベント形式
- 個々のイベントを表示
- 「いつ、どこで何が起きたか？詳細に知りたい」ときに効果的
- e.g. パケットキャプチャやシステムコール
- ※ データが莫大になり、負荷も大きいため、本番環境で常に取得するようなツールではない。サマリ形式のコマンドでアタリを付けた後、使うのがよさそう。
- スナップショット形式
- その瞬間瞬間の状況を記録する。
- e.g. psやtop
- サマリ形式
4.本書で何度も読み返したいところ
「2.3 パフォーマンス分析で重要な理論」と「2.4OSのコマンド」
- vmstat, ps, netstat, iostat, topなどパフォーマンス情報を確認するコマンドの解説
「3.3ストレージのパフォーマンス分析の考え方」
- レスポンスタイム, IOPSなどストレージ周りの用語の解説やI/Oとキャッシュが絡んだパフォーマンス劣化の考え
「3.5原因調査」
- 問題の真因にどうやって気がつくか
- 平時と異常時、時間軸で比較
- CPU過負荷となっていないか？低レイヤーにも気を配る
- アプリが遅くなったからI/Oが遅い？I/Oが遅くなったからアプリが遅い？
5.宿題
5-1.イベント形式とスナップショットの違い
本書では、以下のとおり説明されている。
イベント形式を映画（すべて記録）だとすると、こちらは写真のようなものです。写真は1枚だけだとそれほど役に立ちませんが、定期的に連写することで、パフォーマンストラブルの際に役立ちます。街中の監視カメラの画像で、ある瞬間に被害者と不審な人物が写っていて、その次の瞬間に被害者が倒れていたとすれば、その不審な人物を疑うことができます。そういう使い方をします。
ここで疑問にあがってくるのは、psコマンドやtopコマンドなどスナップショット形式のコマンドの実行頻度だが、、？
5-2.本書の目玉でもある「パフォーマンスチューニングの定石」まで到達
用語の解説から実業務で使われるテクニック論まで幅広く扱っている。次章の「パフォーマンステスト」も気になるところ。。