パフォーマンスチューニングの学び
みなさんこんにちは、ポッドキャスト配信者のKeithこのくわはらです。
Keithの声日記、2024年10月29日の声日記をお届けします。
今日は久しぶりに外部の勉強会に参加しました。
ハッシュタグでいろいろ騒がれていた、騒がれていたって言うと聞こえ悪いな、投稿されていたっていうのもあると思うんですけど
水地さんと藤原さんと総代さんの3名がご登壇されていた勉強会ですね。
パフォーマンスチューニングに関するものです。
すごい勉強になりましたね。
現地開催とオンライン開催2つあって、僕はちょっといろいろな理由でオンラインで参加をしたんですけど
かなり面白い勉強会でしたね。とても学びも本当に大きく
この勉強会っていうかパフォーマンスチューニングの話って何度聞いても面白いので、ぜひ
もっとたくさんやっていただけるとすごく嬉しいなと思いますね。
勉強会のタイトルは私自治場最高のチューニング ハックアットデルタということで、デルタ社の会場
厳密に言うとセブンリッチグループオフィスというところだそうですね。
主催はデルタの方でしたけど
最初の何だかんだ総代さんの話が一番個人的には刺さったかなというところです。
水口さんの話は何度も聞いたことあったり、彼のブログとか
Xの投稿も追ってはいるので聞いたことあるなという話だったりするので
今回はなんか珍しくそれほど新しいことはなかったなと言った感じですね。
ただ
知見の方向と言うと
あれですけど、今までご経験と本当経験値と
一個一個に関してはやっぱり理解度の深さがすごく高いので、言うて何だかんだ学びにはなるんですよね水口さんの話は。
はい 今日は総代さんのほうが多角的な視点からの話ですごく面白かったなと思いますけど
最終的に総代さんが何度もおっしゃっているのは 本当のパフォーマンスチューニングをするんだったらそもそも仕様を変えれば
変えればいいっていうか変えるべきじゃないのっていうぐらいの温度感で言ってましたね。 仕様を変えればいいっていうのはどういう意味かというと
それ必要ですかっていうのをちゃんと問い直しをしてくださいっていうのがその本質で
例えば バッジ表示の数字
数字で出す意味ありますかとかユーザーが本当に知りたいのは新しい通知があるかどうかだけですよねっていう話ですね
実際そのバッジの数字自体 気にしているかどうかって意外と気にしない人が多いんじゃないかなと思ってますね
アソラックのチャンネルとかでも 最近は通知バッジというか
通知 違う更新があった場合は太字になってそれ以外は普通の
文字のサイズだったり太さだったりするんですけど バッジでアプリもそうですね
スマホアプリとかでもバッジあった場合そのバッジで数字のところに出ているかっていうと
出ているんですけどそれを見ているかあんま見ない気がしてて
その数字が大きすぎた場合とかもう2桁じゃなくて3桁とか言ったらもう
見なくてもとにかく更新あるし逆に言うと数字がでかすぎると
もう なんですかね
多すぎるせいか逆に見なくなるっていうところがあるので通知の意味がなくなってきている
気がするであれば むしろ数字は出さない方がいいんじゃないかと思ったりします
少なくともバッジの通知に関してはですね
まあこれが一例だったりとかあとページャーですね ページング
ウェブアプリ作ったことある人は一度は通る道でしょうっていうページャーですね
あれのてんてんてんとやった後の最後のページですね あれも必要ありますかっていう話ですね
が結構僕も中には刺さって確かに思ったんですね 一番後ろに行きたければ小順後順の相当変えればいいじゃん
で結局はまあ遷移するかどうかとか話ではなるので それでこと足りるよねってなって
一番後ろのところをわざわざ表示するために データベースでわざわざデータを取ってきたりとか
1回全量を取っていかなきゃいけないみたいなところとか はいあるので
まさもっぱいないよねって話ですね 冒頭でそのグーグルが以前やっていたいろんなものグーグルって検索
サイトなんですけど 説明し必要ないか
検索した時に検索結果がバーと一覧出てくるじゃないですか 冒頭ですね検索結果の画面の上の方に何件検索しました
ヒットしましたっていうのが昔は出てたんですよね グーグルが出してたせいでいろんなサイトもグーグルがやってるなっていう
それを参考に学って 実装して
やってたんですけどその実装する時にデータベース上でカウントをやってもいいですけど てかそこでやるべきなんですよね
データ量が多い場合は アプリ側の方で全量を取ってきてさらにそれをカウントするのがおらしい
データベース上でカウントしてそれをレスポンスの中に組み込むというのが普通です けど
まあ インデックスが効かなかったりとか貼ってたとしても
副問い合わせとかの方で 結局カウント計算をするとインデックス関係なくなったりするので
結果パフォーマンス悪くなったり処理自体が重くなったりするって話が出て それもそうだよなっていうのででもそういうことって結構多々にしてあると思います
商品一覧とかでもそうですよね 検索の1回一覧画面全部出すときは全量取ってきたりするとかありますけど
タグで検索したりとかカテゴリー検索して絞り込んだとしても件数多かった場合とか 件数は1回全部何件って検索結果に表示される
ウェブアプリってまだまだたくさんあって でもそれは必要あるんですかっていうのが件数知りたいかっていうところですね
物によるっちゃ物によりますけど そんなにないんじゃないかなって僕はあの
お話聞いた後から自分の中でちょっと考えてみたんですけど いやないんじゃないってすごく思いましたね
その数字を得ることがユーザーが本来欲しかったデータではないよねって 思います
それだったら 質の仕様を削るとか他の見せ方をするとか
そもそもユーザーの体験を見直しを図るとかやる方が良いと 結局は作らないのが一番パフォーマンスが高いと
これは作っているシステムとかアプリケーションもそうですし 開発のパフォーマンス チームのパフォーマンス ベロシティとかの観点でも作るものが少ない方が
そりゃ早いよね 早いというか作らないんで
と思うので本当にハイパフォーマンスというのは何もしないが一番良いっていうのは パフォーマンスっていうだけで言えばそうなんですよね
とはいえそれだと結局ノート何も解決しなかったり価値を作れないと思うので
作っていく中でどうパフォーマンスを上げていくかっていうところですね その話は結構面白かったなと思います
で2つ目の最高のチューニングをしないためにすることっていうところ まあその最高の定義から入ってますけど
チューニングを 必要がない
サイトとかシステムの方が 結果的にはハイパフォーマンスだよねっていうのはある気がしてて
ちょっとこれはトークと違う話ですけど 必要があるからチューニングをするってわけですよね
つまり思いが遅いサイトになってくるわけで それは設計次第とかもしくはそのデータが溜まってきて
その蓄積されたデータの結果重くなってしまったり パフォーマンスに負荷がかかっているようなサイトになってしまったりっていうのはあると思います
今はいろんなものが整備されたりサービスがいろんなものが出てきているので お金で殴れば解決するものももちろんあるんでしょうけど
今回の勉強会の中でも藤原さんがおっしゃってましたけど 頭打ちは来ると
金で殴って殴ってもサービス自体に頭打ちが来る その後の時に思いくエリーでスロークエリーを見て
ボトルネック探すとかそういう変なSQLないかとか 実行契約叩くとかもそうですけど
やったりすると
お金で殴らなくてもできるパフォーマンスチューニングってのがあるはずだよねっていう話もあって すごく面白かったなと思います
一番刺さったというか そうだなって思ったのは
お金で殴るっていうのはもちろん手段としてあるんですけど お金で殴る
何のために殴るのか 根本解決をするための時間稼ぎのために殴ると
根本解決のためにいろいろやった結果最終的にはスケールアップをするとか スケールアウトでサーバーの数を増やすとか
っていうやり方ももちろんありますけども スタートがそこからではなくていろんなものをやったけど最終的に言えばインフラにお金をかければ
解決するってところまでたどり着いたのであればお金を使う ってところですね
最初からお金を使う場合は根本的解決のために時間稼ぎをして 一旦お金で殴れる環境であれば
少なくのパフォーマンス問題は一旦解決というか起きなくなるんで その瞬間にやるっていう話ですね
これは確かにいいと思って
あとこの理由だと割とリンギも通しやすい気もしますね
はいっていうので とても
気づきというかハッとさせられるお話を結構藤原さんがしていて
学びが多かったなって感じですね 今回はやっぱりパフォーマンスチューニングの勉強会3人ともとても素晴らしいお話だったので
スライドもツイッターで公開されてたので また改めて読んでみたいなとも思いましたね
システムとかアプリケーションを作っているので技術の話ではあるんですけど 技術以外での解決策とか解決の糸口っていうのはあるなっていうのを
改めて 自分の頭の片隅に入れてとか選択肢として常に持ち続けていくっていうのを今後も意識したい
なと思わされるような勉強会でした その上でちゃんとシステムのボトルネックと向き合うときに
イスコンボーンとかを読んでみるとか いろんな外部のサービスを使ってそもそも計測をしてみるとか
ですね あとはまあ指標とかどういう数字を目指せばいいかって分からないなったら一旦
Googleが出しているCore Web Vitalsの数字を追うとか いろんな後はそういう指標があると思いますので
そこに頼るっていう感じですかね はい
ちょっとまとまらないですけどパフォーマンスシューティングの勉強会すごく面白かったので システム作っている限り永遠の課題なのでこれは
エンジニアとしてここはずっと追い続けたいなと思いました はい
子どもの成長
続いて 子供のうつ伏せですね
最近うちの子がツイッターで言いましたけどうつ伏せできるようになったんですけども 奥さんから言われたのは
かなり首っていうか顔が上がれるようになったよ もはやもう首座ったと言っていいんじゃないかと
言ってて実際にちょっとうつ伏せさせてみたんですけど 結構長時間しかも今までよりも全然高い
高さまで首を持ち上げられる顔を持ち上げられるようになってて本当びっくりしましたね いつの間にそんな首の筋肉ついたんやってぐらいです
一回こう振って上に上がれるぐらいじゃなくてもう上げたもずっとその高さを維持できて いたんですよね
ようびっくりしました この成長ってほんと早いですね一気に成長していく
逆に言うと 気づかないうちにうつ伏せにもなってしまえる
体の筋肉が育ってきたっていうところでもあるので 今までと本当に
監視をもっとレベル高くしなきゃいけないというので どうやって監視するかを仕組みで解決することもできますけど
ちょっと考えなきゃなって感じですね
3ヶ月も経ったのでそりゃそうだよなっていうところはありますけど
スクスクと大きくなってくれて嬉しいなって感じです
ラストですね 今日は
仕事業務でもいろんなことを今日は考えなきゃいけなくて また新しい観点とか視点
勉強しなきゃいけないものっていうのがたくさん出てきたので 今日はなんか
幅広い頭の使い方しなきゃいけなかったんですけど 一番でも
なんでしょうね 今日の業務の中で
印象が残っているのはシナリオテストですね
所属するチームでのテストケースは いわゆる自動テストですね ソフトウェアテストも書いてはいるんですけど
そうではなくて最終的にリリースする前とか 受け入れの話で
やるテストですね もちろんアードホックなテストとかモンキーテストっていうのもありますけども
いわゆるちゃんとシナリオを書いて このケースでのテストをして
想定通り動きますかっていう正常系と 想定通りエラーが出ますねっていう異常系のテストを
スプレッドシートで久しぶりにテストケースとかと書いてますね
基準とかテストどこまでの流度でやるかとか テストのためのコースをどこまで取るかっていうのが
やっぱりまだまだタイトな環境とか状況ではあるので そこまでテストケースを書いてはないんですけど
僕は受託上がりで なおかつ一番最初に入った会社
テスターという肩書き テスターとしてるんですよね コードを書かせてもらえなかった
とにかくリリース前にエンジニアが作ったものを バンバン叩いていただいて
バグを出していくっていう感じですね っていうのをやってたので
久しぶりにテストケース 今 書いてるんですけど かなりケース数が少なくてですね
すでにリリースしているサービスの開発 追加が早い 追加 追加 追加か
新しい機能開発今してるんですけど
それまでのテストケースと比較すると かなりテストケース少なくて これでいいんだと思いましたね
もちろん まだまだ機能の数が少なかったり
僕が今まで作ったのは Web アプリケーションといっても EC サイトを作ることがほとんどだったので
圧倒的に観点とか テストケースの数が違うのは そりゃそうなんですけど
そこをずっと渡り歩いてきてた身としては
テストケース こんなに少なくていいんだっていうね ちょっと逆に違和感を感じている
別に ちゃんと叩けていて バグだったりとか 想定するものが
動いているのであればいいんですけど
やっぱそれでもね 数があると その分いろんな
しかも数があるって言って ただやみくもり数を増やしているわけじゃなくて
流度をどこまで細かくするか もう縦膜の隅をつつくみたいなぐらいの流度で
昔はやってたんですよね 今までの僕が所属した会社でやるテストでは
1つのシステムのテストケースなんて 大体1000以上いくのがザラだったんですよ
700以下とかあんま見なかったですもんね
いわゆる中 今のチームの開発だと そんなに数いかないので
それよりも早く出して 早くお客様からフィーダバックを得て
どんどんブラッシュアップとか エンハンスをしていくってところが
今はまだフェーズとして 重要度が高いと
品質が低いもの 品質ってのは今回のやると ちゃんと動作するかっていう意味での品質ですけど
低いものを出し続けるのは それはもちろんカミナ社としてのブランドを下げるので
品質は担保はしたい なのでテストもちろんするし リリース前にバグバッシュとかもやるんですけど
とはいえ ちゃんとシナリオを書いて シナリオ通り動くかっていうのを確認するのも
もちろん大事だと思っているんで まあ流度とかは
適宜は自分が時間が空いた時に またテストケースをどんどん追加していったり
自分の中でまた これってどうなんだろうって AdHocにテストしていって
見つかった不甲斐はどんどんチケットを 起こしていくっていうのをやっていくとは思いますけど
やはりこちらとしては 作ってる側の目線でやっぱりテストをするので
本当にエンドユーザーのお客様が どんなふうに使っているかっていう
自分が想像しえないような使い方を されていることも絶対あると思うので
なるべくはそういうのを見つけたいとは 思いますけど
テストに関するお話は いくらでも喋れるので また別で
喋ろうかな 日記ではなくてですけど 今 久しぶりにコードシナリオケースを
バーッと書いてます でも面白いのは 今まではずっと画面単位でテストを
書いてたんですよね この画面でできることって何ですかっていうのと
それを画面遷移した後にどうなるかっていう 接続の部分のテストを書いてたんですけど
今の会社でのテストケースの書き方って言ったら やっぱりユーザーストーリーごとに
書いているという感じです なので ちょっと今まで勝手が違って
書き方とかも テストケースのフォーマットも違うので
そこに対する違和感というか 自分の中ではギャップが大きくて
そこがこれでいいのかって 思ったりはしてますけど
それがあってリュードが 少し僕の中では荒いと言いますか
大きいリュードでやるだなっていう 印象がありますね
とはいえ 別に細かくしていいはず なので 自分の中ではもうちょっと
細かくしてやりたいと思いますね 強化値テストぐらいはもちろん
やりますし 値をどこまで細かく するかっていうのもありますけど
フォームが例えば3つあって フォーム1でちゃんとバリデーション
が出ますよね フォーム2でバリデーション 出ますよねとか その組み合わせの
数をやろうとしたら もちろんフォーム3つだったら
組み合わせの数は6個なので テストケースは6個できるんですけど
これを全部やっていくと フォーム の数が増えれば増えるほど指数
カスタム的にテストケースは増 えていくし フォームだけじゃなくて
画面全体の中でそれでどういう 挙動をするのかと他のエラーと
組み合わせると一気に増えていく ので そこまで細かくやるのはあん
ま意味ないと思ってるんでね 組み合わせテストって基本的には
2つか3つぐらいをやれば大体 全エラーの8割か9割ぐらいカバー
するみたいなのをどっかで本で 読んだ気がするんで そんなふう
なやり方はやろうかなと思ってます ほい じゃあダラダラ喋りました
けど20分過ぎたので今日はここで 終わっていきたいと思います
はい10月もあと2日ですね 頑張っていけたらなと思いました
子どものうつ伏せとパフォーマンスチューニング
では終わりたいと思います 今日も一日お疲れさまでした
バイバイ
