勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

詳解システム・パフォーマンス 第2版の16章ケーススタディと動画

要件定義などの調べものをずっとやっていた反動(?)で、ずっと読みたいと思っていた「詳解 システム・パフォーマンス 第2版」を読んでいる。ちなみに第1版も(事情により)かなり読み込んでいる。第2版はいろいろとアップデートされているので楽しみな本ではあるが、今回は刷新された「第16章 ケーススタディ」について面白かったので取り上げておく。自分のメモを兼ねている。

「詳解システム・パフォーマンス 第2版」の雑な紹介

Linux上で稼働するアプリケーションのパフォーマンス分析と対応について、極めてディープに説明する本である。だいぶお値段が張るので、まずオライリー日本語サイトで目次をチェックしておくことをお勧めする。
www.oreilly.co.jp

16章 ケーススタディ について

いきなり16章のケーススタディを紹介するのには理由があって、著者が先に読むことをお勧めしているのだ。

16章は、ほかの章とは異なり、ストーリーテリングの方法を使ってパフォーマンスエンジニアの仕事を大きな視野で捉えようとしている。あなたがパフォーマンス分析の初心者なら、さまざまなツールを使ったパフォーマンス分析の具体例としてこの部分を最初に読み、ほかの章を読んだあとでもう1度戻ってくるとよい。

そしてこの16章のケーススタディは、著者のBrendan Greggが2019年のイベントで講演した内容がベースとなっているので見てみると面白い(面白かった)。以下の動画の冒頭10分程である。
www.youtube.com

ざっくりいうと、このような内容になっている。

  • 新しいコンテナベースのプラットフォームであるマイクロサービスをテストしたところ、パフォーマンスが3倍になってしまった
  • 予想外だったし、話がうますぎる。本当?
  • というわけでその原因を調査した(結果は動画を見るか、書籍で確認していただきたい)

実際の調査がどの程度大変だったのか、試行錯誤はあったのかはわからないのだけれども、極めてエレガントに分析していると感じる。

おまけ:第1版のケーススタディとの違い

では「詳解 システム・パフォーマンス」ではどうだったのかも簡単に紹介しておく。

  • 「13.1 ケーススタディ:赤いクジラ」
    • 営業から顧客のサーバを見てくれという、フワッとした連絡が来る。
    • 既存のサポートチケットを見ながら仮説を立てて、状況を分析する。開始時点では状況はよくわからないというのがポイントか。
    • 最終的にはRedisの定期的なディスクに対するフラッシュ処理が原因であることを突き止める(ただし、Redisが何なのかを把握していない状態で)

何が問題であるかも明確でない状態から、本書で紹介されるUSEメソッドなどを用いて診断を進め、最終的に問題のアプリケーションに到達するというストーリーが興味深い。

さて、著者のおすすめのとおり16章を読んだので、いまは冒頭から順次この分厚い本を読んでいるところである。読み終わるのは来年かなー