📖

[WIP]「達人が教えるWebパフォーマンスチューニング〜ISUCONから学ぶ高速化の実践」読書メモ

2022/06/28に公開約4,600字

達人が教えるWebパフォーマンスチューニング〜ISUCONから学ぶ高速化の実践」の読書メモを書くためのエントリー。読み進め次第随時更新していく。

メモ

Chapter 1: チューニングの基礎知識

1-1

ウェブサイトの高速化についての書籍ということで、冒頭からGoogleの報告やCore Web Vitalsを参照しながら客観的に高速化の重要性を説くとともに、最後に「かっこいいと思いませんか」と主観に訴えてくるのがにくい。

1-2

まず「高速なウェブサービス」の定義を「ユーザー視点で低レイテンシー(低RTT)なサービス」としている。これは自分の理解とも合致する。次にその中でCore Web VitalsのLCPの基準(2.5秒)を引き合いに出し、ブラウザ側の処理を考慮してレスポンスの返却が1秒以内に完了することを目指したいという大まかな目安を提示している。

レイテンシーだけでなく、スループットについても考慮することを補足している。ノートでスループットについて考慮する場合に計測のウインドウも考慮することが書いてある。

高速化に際し、システムアーキテクチャの理解をマクロ的なものから徐々に掘り下げて各コンポーネントを理解するという手順を推奨している。自分もSLOの設計手順で同様のアプローチを推奨しているので納得感が高い。特にシステムを「入力・計算・出力」の各動作まで単純化させたところから理解させようとするアプローチは伝わりやすいと感じる。

1-3

リソースとキャパシティの関係を端的に説明していて分かりやすい。またノートで触れている大規模サービスはキャパシティの大小だけでなく、地理的な観点で見た場合にユーザー視点で考えると分散環境が必要になることなど、新しい視点について言及しているのは面白い。

1-4

キャパシティ=個々の性能×数という定義を紹介し、その上で垂直スケーリングと水平スケーリングの説明をしている。

キャパシティのコストパフォーマンスを調整する方法として、需要側と供給側の調整について整理しているのは分かりやすいと感じた。特に需要側の技術的な手法以外の調整方法にも言及しているのは、視点を広くさせる意味で素晴らしい解説だと感じた。
供給側の調整方法に関して、クラウド時代における「エラスティック」と「オンデマンド」という観点を説明するとともに、オートスケーリングの課題も整理していてよかった。

キャパシティプランに際して、負荷試験の必要性を説いて、本書の後半に続く解説になっていた。

1-5

パフォーマンスチューニングに際し「推測せず計測をせよ」という鉄則にまず触れているのは同意するばかり。また負荷試験に際して、与負荷側の律速を計測することも触れているのが素晴らしいと感じた。

計測に際し、変更は一度に1つにすることを強調しているのもやはり素晴らしいと感じた。また計測誤差要因についての考慮事項も触れているので、計測をする前の心構えとしてなれるまではこの節を毎回読んでもいいくらいだと感じた。

1-6

「パフォーマンスチューニングはボトルネックの解消である」と強調した上で、コンビニエンスストアでの例を出して、非常に理解しやすくなっている。

ここで再び、1-2で解説したようにボトルネックの特定はまずマクロ的な構造から把握することを解説している。その上でミクロのアプローチとして、ボトルネックの対処は「解決」「回避」「緩和」の3つであるとしている。そこまで触れた上で、最後に「個々の要素の高速化でなく一連の処理の全体最適化」に意味があるということを強調しているのは良かった。

1-7

負荷試験の実行プロセスの概要を簡潔に説明してくれているので分かりやすい。本書後半にある負荷試験の章でもう少し詳細がわかるのかな?という期待を持った。

1-8

章全体のまとめは簡潔だけども理解の整理が出来る書き方になっている。

Chapter 2: モニタリング

2-1

モニタリングとはなにか、について導入の説明。アラートに関しての説明が「定常状態でなくなった場合に人間に対して通知する」となっているが、これはアンチパターンの解説になっているように読める。

レイテンシのグラフの例があるが、簡略化したイメージの説明のためのものであることを明記しないと誤解を受ける図になりそう。レイテンシはばらつきがある値になるので、中央値やP90といった値を表示する場合には図1のようになる。

2-2

「返答」と書いたり「レスポンス」と書いたりしていて、言葉の定義が揺らいでいる気がする。「応答」はどちらに相当するのか?

モニタリングの目的は組織の状況に応じて変化するというのは完全に同意。SLOの振り返りというのはまさにこのような目的で行われる。

2-3

モニタリングの種類の分け方が「外形監視」と「内部監視」の2つになっているが、自分が分けるならよりニュートラルな意味合いになるように「ブラックボックス監視」か「ホワイトボックス監視」とする。

外形監視=Synthetic Monitoringというのは自分としては微妙だと思っていて、単純なHealth Checkも外形監視と言えるけれども、これはSynthetic Monitoringなのかと言ったら違うと思う。

2-4

サーバーにssh出来る前提で各種Linuxコマンドを紹介しているけれども、そういう構成は2022年だとだいぶクラシックだと思うので、最初にこの章の出だしを見たときに面食らった。

またCPU使用率に関して top の解説をしているけれども、あれはstalledの時間も入るので、あくまでざっくりとした参考程度にしかならないし、 perf について触れておいたほうが良いのではないかと思った。

2-5

モニタリングツールの紹介と、具体例としてのPrometheus(および node_exporter)の紹介。

2-6

プル型とプッシュ型のアーキテクチャの違いとそれぞれの利点を大まかに紹介。Prometheusにフォーカスして、プル型の欠点を補うエコシステムツールが存在することも言及。プル型とプッシュ型の違いは検討事項の違いであり、どちらが優れているというわけではないという結論。自分もそう思う。

node_exporterが出力する node_cpu_seconds_totaltop コマンドを用いた際の表示される値と同じ、という記述があるけども、本当にそうなんだっけ?と思って調査。top が使っているソースは /proc/stat を見ている。

一方でnode_exporterの実装も /proc/stat を見ているので同じだった。

終始Prometheusのnode_exporterが具体例として説明されていた上で、モニタリングは「何を対象として」行うかを考えるのが重要でツールは関係ない、と結んでいる。その事自体は同意するところである一方、アプリケーションのチューニングをするのにアプリケーション側のメトリクスの話がここまで一切でていないのが気になる。

2-7

Prometheusを例にしてCPU使用率の上昇がグラフで可視化される様子を説明している。しかし、一体これがなんの値(last valueなのかmeanなのか)がまったくわからない。この時点でまだ計測項目に対してどういった値をどのように統計処理をしてどのように可視化するか、といった話が出てきていないのが不安。

2-8

グラフで可視化した際の軸の値域に注意しないと実際の変化より見た目が大きくなることに注意すべき主旨の内容で、これは可視化に関しては同意する。またグラフの比較に関しての注意も説明している。

観測者効果についても、その用語は出していないが解説している。特に難しい用語でもないので名前を出しても良いように思うのだけれども。また、負荷試験に関して与負荷システムは観測対象と異なる系にする話が書いてあるけど、ここは負荷試験の章に回してもよいのでは。

メトリクスのサンプリングウィンドウに関して、もう少し踏み込んだ説明があったほうが丁寧に思う。断続的に来るリクエストのレイテンシーを1秒以内にする場合の話が来ているけれども、2-7と同様、そこから先に何を目的としてサンプリングするのかについての解説がほしい。

コラム。ラインプロファイラというのは一般用語ではない気がするのだけれども、どこで使われているのだろうか。Pythonのプロファイラに line_profiler という line-by-line profiler はあるけれども、これは固有名詞でしか無いという認識。line-by-line profilerなら聞く。たとえばGoに標準搭載されているプロファイラ(pprof)とかも line-by-line profiler になっている。

「Flame Graphs」は「Flame Graph」です。

オブザーバビリティの説明が「ログ、トレース、メトリクスを主要素としたモニタリングの考え方」と書いてあって、ここは完全に同意できない。オブザーバビリティというのはシステムの内部状態が外部から観測可能な状態になっているかどうかというシステムの性質でしかなく、そのために有効なテレメトリーとして「ログ、トレース、メトリクス」の3つが主要なものとして挙げられているということであって、因果が逆。

2-9

ログベースメトリクスに関する説明。自分もより多くの人に使ってもらいたいと思う。

ところで最後にエラーログ1件で対応って書いてあるけれども、どれくらいの頻度でエラーログが発生する想定なのだろう。

2-10

全体としてモニタリングについてかなり概略だけ説明したという感じだったけれども、もう少し取得するメトリクスの決め方やその可視化に関する具体的な解説がほしいと思った。

Discussion

ログインするとコメントできます