この番組はエンジニアの成長は楽しい学びからをもとに昨日より少し成長できる学びを届けるエンタメ系テックラジオです新しくなりましたね新しくしてみましたこれが果たして定着するか一旦これで走ってみましょうと来週に忘れてそうで怖いわいやもう毎週忘れますよ本日なんですけど久々にですねちょっと読んだ本の

紹介というか紹介紹介というか紹介をちょっとさせていただこうかなと読むの自体久しぶり久しぶりさみたいなんですかいや読んでるの自体はねちょいちょい読んでるんですよ最近はドメイン駆動設計を始めようっていう本を休日に子供と外出して子供がしめしめ寝たぞっていうタイミングでちょいちょい読んでたんですけど今日はちょっとその本じゃなくてですねなんかちょっと思い立って思わずポチってしまって今日

パパパーッと読んでおもろいやん系の一部分だけ紹介する話なんですが本日紹介するのが紹介パフォーマンスチューニングという出たオライリーのクソ熱い本じゃないですかそれオライリーのクソ熱い本です1000ページぐらいあるんですけどだいたいまさか全部読んだわけじゃなくて本当に一部分1000もないわごめんなさい780でしたはい

クソ分厚いんですけどだいぶ分厚いイメージあるよそれでねパフォーマンスチューニングですよパフォーマンスチューニングしたことありますかいや興味はあるけどねあんまないな1回だけやったのはアプリケーションレイヤーのところのチューニングでPHPのさ

独自の仕様みたいなのがいろいろあって例えばイコールイコールで比較するときとイコールイコールイコールで比較するときはイコールイコールイコールで比較する方が早いみたいなそういう細かいやつを積み重ねてサーバー側での処理早くしたみたいなことが一回だけあるねうん

それも確かに一つのパフォーマンスチューニングですね今日お話をするのはアプリケーションレイヤーよりもさらに広げて全部ですね一つのサービスがあってそのサービスの性能試験と言われるまあ

インターフェースエンドポイントから負荷をかけてみてそのレスポンスが返ってくるまでの秒数とかあとはさばけるリクエスト数とかっていう流度でパフォーマンスをチューニングしていく本なんですけどちょっとこのパフォーマンスチューニングという分野は非常に面白くてですね普通のソフトウェアエンジニアリングの多くの領域だと

何か問題が起きましたそれの解決をするために観測して客観的に出てきた情報を判断してアクションを講じていくみたいなそういう客観的なプロセスを踏んでいくようなものなんですけどことパフォーマンスチューニングにおいてはめっちゃ主観的に進んでいくんですよそうなの?そうなの?

まずパフォーマンスに問題があるか否かこれめっちゃ主観です基準とかないんですか例えばですけどSEOとかってさこのページが描画されるまでに何秒以内に描画されないといけないみたいな目安あるじゃないですかそこを目標としてて超えたら頑張るとかそういう感じじゃないんだ

それは合ってます合ってるんですけどそこで問題とするかどうかって分かりやすい基準はそこなんですけどそこはそうかもしれないですけど全体として基準を下回ってたとしてもディスクIoに100msかかってますこれを早いとするか遅いとするかみたいなところって主観なんですよっていう僕も性能試験とかやってて

実際の現場私が経験してきた多くの現場だと納期があるんで性能要件があってその性能要件を達するように頑張って締め切りギリギリまで頑張ってクリアできるところと妥協するところがあるみたいな感じでただそれってアプリケーションの機能という単位ではありえないと思ってるんですよできてない機能があったらリリースしないんですよ

そういうことねなるほどっていうのでなんかパフォーマンスの分野ってすごいふわふわしてるというかなんて言うんだろうな必要ではないというか必要ではないっていうのもちょっと語弊があるんですけどさじ加減もあるけどねページ開くのに5分かかるんだよねとかさすがに必要だけどね1秒以内でないとダメだっていう基準があった時にじゃあ1100ミリセックの時にどう判断するのか確かに

体感いいかみたいになりそうだしいやいやダメだっていう人もいるかもしれないしお金をかけてまでそれを解決しろよっていう判断をするかまあいっかってなるか1100はいいだろうってなったとしてもじゃあ1600はどうだとかねそこは確かに主観だなめっちゃというか非常に水物というかっていう分野でよりなおかつ体系的に学ぶ資格とかないしとはいえ

結構ぶつかると苦労するような部分なので学びたいなというところでちょっと本を読んでみておりますいいですねこの本面白いのがパフォーマンスチューニングの本ってどんな内容を書いていると想像しますかまずはボトルネックを突き止めようって書くポイントでどうやって計測するのかみたいなとこから始まって第何章では

どこどこの部分のパフォーマンス改善をやりますみたいなうんうんうんそんなんでしょいやーもう本当にありがとうございますありがとうございます本当にまあ実際あるというかまあその実際にパフォーマンス改善してみようみたいなそういうハンズオンはないんですけどうんうん

コマンドの紹介とかもちろんありますこうやったらこれが見れますよとかあとはパフォーマンスチューニングというかデバッグ調査か調査する際の考え方とかあるんですけどあとは普通にCPUの仕組みとかなぜなら何か起きてる時に仮説を立てなきゃいけないスケスケ力を高めるための情報大事だよねこれいかにスケてるかがマジで

肝だと思うわいや本当にそうなんですよ本当にそうそこの流度が荒いとさなんか原因を見つけるのにも苦労しそう本当にそうなんかケーススタディ的なというかまあ別に答えもない話なんですけど性能試験ガトリングでやったりとかすると例えばじゃあ1秒間に1000リクエストゲットやらポストやらプットやらをまあいろいろ混ざってじゃあ20分間負荷をかけますとうん

でやってみると性能要件クリアしませんでしたとじゃあなんかどっかにボトルネックありそうだなってなるじゃないですかメトリックスを見てみますとCPUもメモリも全然いっぱいいっぱいになってないぞってなった時の絶望感あー確かにもう玉がねーつってこれがねやっぱスケスケになってる人は何か仮説立てれるのかもしれないですけどスケスケになってないと

どうしようもないじゃないですか確かにかなりね事前知識がすごい必要かつあんまりAIに投げても上手いことやってくれない分野なのかなと今ちょっと勝手に思ってるんでどうなんだろうあんまやったことないけど

仮説コンテキストを投げるの難そう 確かにでも仮説ここ調べたらいいんじゃないですかみたいなところのなんか世の中の人の一通りのことを言ってくれそうだけどね そうですねそれもあるかもしれないですけどそれが果たして本当に合ってるかっていうところがね難しいんでまあというのでちょっとちょっとそろそろ本題入っていこうかなと思うんですけど 今日はあのこの本めっちゃ長いんですけど2章の

メソトロジーというパフォーマンスチューニングする際の考え方みたいな章からいくつかというか本当に超一部だけ紹介しようかなとやっぱね本は最初の2部が一番エピソードにしやすいって噂ですからね一部です一部一部か一部です一部が一番全体のこと書いてるんでねでもやっぱメソトロジーの話をちょっとしようかなと思いますがはい

メソトロジーの話に入る前にもう少し基礎のところなんですけどまずパフォーマンス分析って2種類あんねんとさっき言ったようにエンドポイントから負荷かけてみてレスポンスが返ってくるかっていうところでその結果を分析する切り口が2つありますと1つがリソース分析

これはCPUやメモリとかあとはネットワークとかディスクIoとかそういうリソースの分析はい

を指しますで主に見られる指標としては今言ったのって割と使用率が頭に浮かぶと思うんですけど使用率の他にスループットこれは通信量とかあとIoPSこれは1秒あたりどのくらいIoが書き込まれたりしてるかインプットアウトプットパーセカンドこれは使用率とはまた別ですねうん

使用率はあくまで時間あたりのCPUだったら時間あたりにプロセスが利用している数かもしれないしストレージだったら時間あたりというよりはリソースの許容量あたりの割合を指しますね

この今まで3つ言ったIoPSスループット使用率の他にあとフォワードというものがありますフォワードこれ僕もあんまり聞き慣れなかったんですけどフォワードというのは処理しきれなくて溢れてる量ですねなのでプロセスだったりすると1CPUが2つ1CPUがハイパースレッティングっていう1つのCPUコアで複数のプロセスを処理できるっていう仕組みを使って2つのプロセス処理できるとして

1CPUで2つ処理できるとしてそこに3つ目のプロセスが入ってきたらその3つ目ってマチになっちゃうじゃないですかそれは飽和度0より大きいですなるほどね0より大きいんだ100を超えるわけじゃないんだ1っていうか50っていうのか分かんないですけど飽和度は飽和してなかったら0です飽和してなかったら0で溢れてきたやつらが数値としてカウントされると違ったらすみません確かそうだったと思います

限界ギリギリまで溶かし込んだ食塩水にさらに塩を入れるとそのまま塩の結晶が残るみたいなあれだそうそうそうそうで温度を下げていくとね塩の結晶ができるやつですよねそうそうあれだよね塩は温度であんま変わらないから砂糖でやったような気もするけどそうなんだそこまで覚えてないな

そんなこと置いといて一つがリソース分析もう一つがワークロード分析ですワークロード分析これはアプリケーションのパフォーマンスを調べるものですなのでアプリケーション

の処理したもののスループット処理できるリクエストなのかデータ量なのかあとは処理のレイテンシーですね遅延がどのくらいあるかみたいなところを調べるというこの2つリソースを見るところとワークロードの処理の状態を見るというその2つの分析の視点がありますそれは言わばあれですかねインフラとアプリケーション見てるみたいなそういうところにつながっていくのかな

ちょっと近いですね一方でそういうことなのかな確かにインクラとその上に載ってるプログラムアプリケーションレイヤーを見ているそうかもしれないですねただミイシーに見てるというよりは被ってるんでどっちかから観測できるといいなみたいな確かにワークロードもだって要はインフラ関係あるもんなアプリケーションも

全体としての異常は多分ワークロード分析から観測してその上で詳細というか切り分けをする材料としてリソース分析をしていくような流れのように見えましたまず僕はこのパフォーマンスチューニングにおいて本能的というかなんとなくやってたんですよリソース分析とワークロード分析やってたんですけどまず言葉にして

するとこの2種類あるんだなというのがまず気づきとしてありましたとでこの2つの分析がある中でノリさんに質問なんですけどこの分析ってパフォーマンスに問題がありますってなった後にどうなったら分析って終えていいかどうなったら分析って終えていいかはい例えばなんか問題分析性能に問題がありますってなった後にじゃあそれ問題を調査しようってなるじゃないですか問題を調査しましたうん

本当はじゃあ1秒早くしたいけど500ミリセック早くなりましたってなった時に分析を続けるか否かみたいなマジでむずいなさっきの主観的なところに戻っちゃうけどそれがビジネスの文脈だとどれくらいクリティカルなのかによる気がするんだよなうんうんうんでそのクリティカルはどういう数字に出るかっていうともしかしたら

最初のコンテンツをロードする前に離脱するユーザーがいるかもしれないみたいなっていうような別の指標で現れるんじゃないかなと思っていてだからその半分じゃあ改善しましたとその上でやめるかどうかはまたその別のビジネス的な指標を見た上でOKだったら追わなくていいんじゃないか

いやーさすがですねいやまあCTOすからね素晴らしすぎますね考え方3つあります最初の2つはのりさんが言った通りです1つは解決したとしてもROIが低いときROIはリターンオンインベストメント投資利益率なんで費用対効果というか時間のコスパざっくりとコスパが

悪い時頑張ってもコスパが悪い時はもうやめていいと2つ目はこれをやるよりも別のことやった方がコスパいい時ROIが高い時別のことやった方が高い時はやめた方がいい最後の3つ目が遅延の要因の大半を説明できた時例えば1秒遅延してますってなった後に800msとか900msの要因はこれでしたって言えたら

これもまたね残り100がROIの話になるんですけどでもパレートの法則で残り1割2割を突き詰めるのって結構大変なんでこれまでの以上のコストがかかるとはいっていうのでそれでそういう大半説明できた時とあとは解決したとしてもコスパが悪い時他に持ってやるべきことがある時は分析やめていいという風にこの本に書かれてましたうん

本当に言語化してくれてありがとうっていう感じなんですけどそこを超えてチューニングしなきゃいけないのイスコンぐらいだよそうですね0.0ミリセックイスを競ってるでしょうからねそうそうそうそう

っていうのがまずパフォーマンスチューニングのベースのベースなんですけどちょっとここからメソトロジーのところをちょいちょいと紹介させていただければなと思いますこの本メソトロジーって言ってるのが分析をどのように始めてどうやって進めていくかっていうHowのTipsというか考え方のパターンというかっていうのがいっぱい書かれてるんですけどなるほどね

この本全部で16章あるんですけど2章だけで30弱ぐらいメソトロジーがあって2章だけで2章だけで30弱ぐらいメソトロジーがあって全部いったら8倍?ただメソトロジーの章は2章だけなんですけどそういうことねだけって言っても2章以外で紹介されてるのを含めると本全体で40何個あるんですよすげーな

もう多すぎるんで 今日はまあ気になった数個を紹介しますなるほどねうわてかそんだけスケスケになる必要あるんだねそのパフォーマンスチューニングをガチでやるってなったらいやー見たいですよってかねでもそんな気しますよなんか例えばですよめっちゃシンプルなアプリ考えたとしてAWSで構築しているじゃあアンプ

アプリファイというかS3クラウドフロントクラウドフロントバックエンドはどうしようかなAPIゲート選むだデータベースにRDSってなった時にこれどこが遅いって当たりつけるために今言ったサービスの性質全部理解してて当たりをつけられないといけないですからねこの単純なやつでもそうなのにじゃあもっとでかくなったらとかうんうんうん

あとはマルチクラウドになったらとかとんでもないことになりますよね確かになガチでやったらそうなるんだろうけどめっちゃ雑なこと言うけど超絶大規模サービスじゃない限りさだいたいクエリじゃねって思っちゃうんだ超絶大規模サービスじゃない限りねでもいつか来ますよいつか来る

いつか来るかそれまでに備えとかないといけないなそうなんですよということでいくつか相談していきます1つ目アンチパターンからいきますアンチパターン街灯のアンチメソッドっていうアンチパターンなんですけど街灯の街灯はどの街灯ですか街の明かりです街の明かりなんだ一番違うだろうなと思ってたやつが来た街の明かりですはい

これ気をつけてねっていうアンチメソッドなんですけどこれ何かというと自分が欲している自分が使いたいとか思ってるツールとかあとはインターネットで拾ってきたツールみたいなところを使ってなんか明らかな問題が現れるかどうかっていうのを適当にって言ったらあれですけど希望的観測的なそうです

照らされているところを中心に見るっていうパフォーマンス分析のやり方ですあーなるほどねこれだから街灯って言ってるんですけどもともとその街灯効果っていう観察結果バイアスっていうのがあるみたいで街灯効果何かというとこれちょっと例え話というか逸話なんですけどある晩警察官は街灯の下で探し物をしている酔っ払いを見て何を探しているのかというのを尋ねましたうん

酔っ払いは鍵をなくしちゃったんだって言ってますとで警察官も見つけられなくて鍵をで酔っ払いに尋ねました街灯のこの下でなくしたっていうのは確かなことなんですか酔っ払いは答えましたいいやでもここの明かりが一番具合がいいからねって酔っ払いはここが明るいから探してるといやーなんか海外の話だなーって感じすると

海外の話だなこれ実際やりうると思うんですよねこれはね元々使ってるツールで見ちゃうとか元々用意してたメトリクスのダッシュボードとかで見るのでそこを中心にちょっと原因を探そうとしちゃうそれはね楽な方に流れちゃうよそうなんですよこれ非常に気をつけなきゃいけないなとこれ良くないのが

見つかることあるんですよね根本原因はいはいはい偽妖精的な偽妖精でもないのかなたまたま見つかることあってここからは想像なんですけど人間ってたまに見つかるものに対してめっちゃ執着するんですよ下下のガチャとかああいうたまに出るやつすっごい執着するっていう性質あると思うんでこれは本当に気を付けなきゃいけないんですよだからうーん

ゴールデンハンマーだと思ってしまってそうだよな一方確率でも低くないんじゃないかなと思う自分もいてそこに落ちてる可能性高いから照らされていった説はあるなっていう気もしてるんだよな本当は体系的な知識を持って適切なアプローチを取れるのが一番いいんですよね間違いないねそれで見つけれたのとたまたまそこをよく見るから見つけたのだと

なんか精度が安定感なのかな安定感が全然違いますよねはいいろんなケースに対応できるんですねはいというのでこの中こういうアンチパターンを気をつけていきたいなというところでちょっと紹介させていただきましたありがとうございますはいで続いてまあまともなパターンですまともなパターンアンチじゃないパターンということですねアンチじゃないパターンですはい

一つ目は科学的メソッドというのが言われるものでこれはアプリケーションのプログラミングでも重要な考え方なんですけど要するに仮説を立てて検証することを通じて未知の事象について検討していくというやり方ですなので一般的な性能試験においては性能試験回してみます結果が出ます何か問題がありますねその問題なんだろうねを

調べるんですけど調べる際に仮説を立てますと今起きている結果の中でこういう仮説があるなと元々取っているメトリクスの中にそれが現れていればいいんですけど現れていない場合は例えばデータベースなのかバックエンドのアプリなのかところでまた新たに性能不可をかけてみてそこで何かしらのコマンドを叩いて

やっぱりここに影響が現れてるか現れてるな現れてないなっていう仮説検証をしてでそのサイクルを回していくというやり方これはエンジニアにおいて非常に大事な基本的な考え方ですねで

これを前座に置いておいて前座に置いておいて前座に置いておいて次がUSEメソッドと呼ばれるものを紹介しますUSEはいこれはUtilizationSaturationSaturationErrors使用率フォワード使用率フォワードエラーの3つの

パフォーマンス調査をやるものになってますなので全てのリソースのさっき言ったUSE3つの指標をチェックするというようなやり方ですなので全体のフローとしてはまず最初に対象のリソースをリストアップしてで、付加かけてみて

でそのそれぞれのリソースに対してさっきのエラーがあるか法話があるか使用率が高いかっていうのを一個一個チェックして一個一個チェックして問題があれば問題あるしなければないみたいななるほどねさっきの科学メソドロジーだっけ科学的メソッド科学的メソッドとなんかもうセットだよね仮説立ててここじゃないかつってそこでその3つを調べていくみたいなイメージあーえーと

そうですねどっちかというとUSAメソッドは見るメトリックスを制限してますねエラーとフォアと使用率に原因が現れることが多いのでそこを見るって明確に定義しているのが差かなと思います科学的メソッドはもっと広いですねもっとふわっとしているそういうことかここの

最初のリソースをリストアップするっていうフェーズにすごい特徴あるなと思っててこれ面白いのがリソースのリストアップの中で何のリソースがどこと関わってるかっていうのを図に起こすって言ってるんですよへー例えばDRAMはCPUから呼び出されてるよねとかCPUから

Ioブリッジを経由してIoのコントローラーを経由してディスクに書き込み読み込みをしてるよねとかなるほどねPCの中にある一個一個のパーツとその経路まで図にしちゃうってこと?図にしてでメトリクス見て何か異常あったらここのこれがこうなってるのねみたいなマジでって思ったんですけどそこまで来たらマジで本当にコンピューターサイエンスの知識がないと立ち打ちできないね

立ち打ちできないしでも実際僕性能試験やってるんですけどそれを感じていますそうなんだその必要性に駆られて買ったんですかその本そうですよいいチョイスですねいいチョイスそうじゃないと読まなかったのはなでもいいだからいいきっかけをもらってますねこの図にしようっていうのがすごいなと思ってうん

図にしないまでも頭の中にないとダメだなって思いますねそうね問題起きた時に手札が本当にいやーでもさすがにOSで隠されてる部分まで見ねえわイメージできねえわなのでちょっとスケーさせようとしてます今さっき言った使用率フォワードエラーですねこれそれぞれどういう風に見ていくかというと使用率に関しては

コマンドでも見れますねトップトップ甘すぎる?トップもいいですアイオースタッドとかVMスタッドじゃなかったっけありそうだよなどなどですねあと各種グラファナとかジェンキンスとかニューレディックとかいいので見れますねいろんなログとかはい

であとはまあ法話度はいこれあんまり気になれないかもしれないですけど法話度の計測わかんないかもはい

フォワードも実はVMスタッドで見れるらしいんですよへーVMスタッドってCPU使用率やらいろんな情報がバーって表形式で出てくるんですけどその中のR列っていう列の数字がCPUのコア数を超えてるときにこれってCPU使いたいのに待たされてるプロセスが存在するってことだからこれってフォワードが0超えてるよねっていう判断になるみたいですへー

メモリとかもフォワードがあるっていう状態はメモリのスワッピングとかあとはアウトオブメモリが発生してる状態これもVMstatのオプション1だったりあとはDMESGコマンドでも見れたりするみたいですDMESGディスクメッセージディスクメッセージかな確かにディスクメッセージっぽいなコマンドは見たことあるわエラーはねログインでますと

いうところで使用率フォーワードエラーっていうのを計測しながらあとは各リソースの関係値というかをイメージしながらデバッグしていくというか調査していくっていうのがこのUSAメソッドというものみたいですちなみにこれは補足的なところなんですけどNetflixあそこシステムとんでもないんですけどそのイメージありますやばいですよね多分ね

ああいうところだとこのUSCメソッドではないんですけどそれに似たREDメソッドっていうので要求率エラー処理時間っていうリクエストエラーリクエストレイトエラー処理時間デュレーションっていうのを全サービスマイクロサービスアーキテクチャなんですけどそれをそれぞれ

見てパフォーマンスチューニングしてるみたいですへーなんでやっぱその一個一個のCPUシリーズとかリソース見るのもやっぱ大変なんでそういうなんかちょっと抽象した形で見てる見るもんなんだなっていう感じみたいですねうんうんうん

はいっていうのでちょっと今日お話できるのがここまでなんですけどはいちょっとこの本読み進めてねCPUの超コアな話とかできると良いなと思いながらちょっと読んでみようと思うのでこれ難易度どんな感じですかちなみにめっちゃ高いと思いますよですよねめっちゃ高いと思いますいやなんかこれでいてこれサクサクいけるんですよってなったらさそこを軸にそのコアな部分を知ることもできるのかってなってたけど

逆だな多分全然逆だと思います全然逆だねはいこれをねポップにちょっとお届けしておければ思うので我々が我々が我々ではい難易度高いですけどねはいで多分最終的に読み終わったらあの暇寿司なのかな暇寿司のオペレーション改善をねこの紹介パフォーマンスチューニングのその

ティップスというかエソトロジーを駆使してやっていくというエピソードが取れるかもしれないそうねあれだってねなんだっけウェブサーバーの話したときのやつだっけはい

そこに向けてね一個一個蓄積していこうかなと思いますわかりましたありがとうございますということで締めますねハッシュタグひまじんプログラマーでSNSのXFeedback募集してますので本日のエピソードの感想とかありましたら何でも良いのでお気軽にポストお願いいたします皆さんのパフォチューンエピソードもぜひ聞かせてくださいめっちゃ気になるあとはポッドキャストの説明欄からGoogleフォームで番組の要望・感想・質問何でもお待ちしてます感想だけでもいいのでぜひお願いしますお願いします

あとはチャンネルの説明欄からスラックオンラインコミュニティひまぷろ談話室の参加申し込みフォームがありますので他のエンジニアと友達になりたい刺激を受けたい何かしらの仲間を見つけたいという方いらっしゃいましたらぜひお気軽にご参加お願いいたしますおすすめです最後に各種ポッドキャストプラットフォームのフォロー高評価もお願いしますそれではまた次回バイバイ日本のエンジニアは使うアプリが多すぎる

事実、ヒマプロの使用アプリ平均数38.6個。レイキャストならアプリの即起動。過去のコピー履歴を引き出せる。ウィンドウのリサイズなど、これ一つで作業効率アップ。しかも料金無料。今すぐレイキャストで検索。