トレースだけでは不十分?継続的プロファイリングでオブザーバビリティを高めよう川岡:私の発表では「トレースだけでは不十分?継続的プロファイリングでオブザーバビリティを高めよう」というタイトルでお話ししたいと思います。最近では、「継続的プロファイリングとは、o11y(Observability)における4本目の柱」と言われており、これは本番環境のプロファイルを収集するというのが重要であることを意味しています。Profilerについてお話しします。Profilerの機能紹介フレームグラフ下図のフレームグラフでは、どの処理にどれくらいCPU時間を使ったかが、わかるようになっています。グラフの縦はコールスタックで、呼び出し先の関数が上から順に表示されています。フレームグラフを見ただけで、ボトルネックが分かれば良いのですが、難しいのが現状です。そこで、同じプロファイルを、色んな軸で比較することで、パフォーマンスの変化を見て改善していくアプローチを取るのが一般的かなと思います。様々な比較軸があり、下図では時間によってプロファイルが変化しています。下図の「6」や「10」はCPUの時間だと考えてください。下図のように、リリース単位でプロファイルを比較することもできます。下図のように、ゾーンによる比較もできます。大事なポイントプロファイラーにおける大事なポイントとして、以下の2つがあります。Pyroscopeを推していますので、その理由を紹介いたします。Pyroscopeのハンズオンがお勧めですもし使ってみたい方がいましたら、ハンズオンがあるのでそちらをご利用いただくと良いかと思います。Profilerを使ったパフォーマンスについて話す前に、Communeのアーキテクチャーについてご説明します。Runでアプリケーションが動いていて、その配下にデータレイヤーがあります。Profilerを使っています。Runはサポートされていません。Profilerを導入していたので、動くことは動くんだなと思い、導入する勇気をもらいました。問題があればすぐに切り戻す予定でしたが問題なく動いてます(導入は自己責任で)。Profilerの導入はとても簡単です。エントリーポイントに以下を定義してあげれば良いです。以下はExpressの例です。弊社の場合、その他、以下を設定しました。プロファイラーで改善のヒントを見つける実際の改善事例として、34秒29かかる処理がありました。下にmakeRowsというメソッドがあり、それがかなりの時間を占めているとわかりました。ライブラリのところを見ると、CsvBulider.tsとあり、csvのダウンロード機能に関係がありそうだと思いました。Traceでcsvダウンロードのエンドポイントのトレースを見てみましたが、よくわかりませんでした。プロファイルをよく見てみるそこで、プロファイルをよく見てみるとformatDateというメソッドがあり、その下のf.tzが呼ばれ、21秒ほど時間が使われているのがわかりました。formatDateという名前なので、日時の変換系だろうな、というあたりをつけました。日時のフォーマットをやめてみるとその推測を確かめるために、日時のフォーマットをせず検証環境へデプロイしたところ、劇的な効果がありました。今回は、フォーマットに使うライブラリを変更したことで、時間が約1/3になりました。Profilerのおかげでパフォーマンス改善できたまとめプロファイラーの導入はメリットしかない!ログやトレースだけではわからないことがあるのでプロファイラーを導入してオブザーバビリティを高めましょう!最後に、以下のQRコードに会社情報が載っていますので気になる方は、アクセスしていただけると幸いです。川岡さんありがとうございました!続いてはQ&Aのコーナーです。Q&Aコーナー(Q)SREの必要性を経営者に説明する方法はありますか?酒井:純粋に顧客体験が悪くなるリスクがある状況で予算を要求するとしても、ROIを出せと言われたら結構難しいと思います。XはtoBとtoC両方あるので、法人側の業務効率低下やユーザーの機会損失を数値で出すことは可能ですが、それでROIが担保できるかは別問題ですね。個人的にはSREでこれまで見つからなかった課題を改善してプロダクト開発がやりやすくなったり、クレームが減ってビジネス案件の開発に集中できたりすることで、エンジニアの満足度や定着率向上、ひいては採用にもつながってくるといった中長期的な組織開発の側面を推すかもしれないです。川岡:聞く耳を持ってくれる経営者だと嬉しいですね!ローンチはSREがいなくても良いが、ユーザーが増えるにつれてユーザーが使いづらいものになっちゃうけどいいんですか?と訴えられると良いですね!なかなか成果証明が難しい役割ですが、会社やプロダクトが安定してスケールするために必要な役割だということを理解してもらうといいです!(Q)インフラエンジニアにおけるSREへのキャリアステップに必要なマインドセット、スキル、経験など教えてください。酒井:インフラエンジニアではないのですが、SREは顧客体験に紐づくものなのでビジネスに近い存在であるべきだと考えています。ビジネス思考があると良いと思いますし、ビジネスサイドの方と話ができることも必要です。山本:インフラエンジニアではないのですが、ソフトウェア開発のエンジニアリングスキルは必要だと思います。川岡:元々インフラエンジニアです。ソフトウェアを書くことが重要です。オンプレからのキャリアチェンジは苦労するかもしれませんが、本人がキャリアアップやステップを望んでいるかが重要です。現在進行形でしていることはありますか。酒井:「SREって何か」を概念レベルで知ってもらい、何が良いのかを理解してもらうことが重要です。誰に話すかによってアピールポイントは変わりますので、相手に合わせた説明が大切です。これは過去にやってきたことでもあり、現在も進行中の活動です。具体的には、私はスクラムチームのテックリードなのでスクラムイベントで枠をもらってSREの話をしたり、エンジニア向けにライトな勉強会を開いてアーカイブを共有したりしています。山本:地道な啓蒙活動に尽きます。して各地で広めたりしています。川岡:具体的な取り組みとして、朝会でSREがやっていることを全体向けに紹介したり、「月刊SRE」という発刊物を通じて活動を広める活動を行っていました。Profilerを見てみる」という開発者の方が結構いらっしゃったので、効果はあったと感じています。今後は、チーム単位でSREのプラクティスを根付かせるという活動になっていくと思います。ツールを導入することによって得られるメリットとコストのバランスを意識しています。常に有償のツールを導入するわけではなく、費用対効果を意識して導入しています。山本:費用と得られるメリットのバランスを都度考えています。どこまでやるかは毎回悩むところです。全てを実施するのではなく、徐々に入れていくのが基本的なスタンスです。川岡:明確な判断基準はないです。費用対効果が低すぎる場合を除いては、検討の段階に入ります。そのうえで、マネージャークラスで検討・判断しています。やっており、SRE専門のエンジニアはいないです。「SREのことがわかるエンジニア」はとても需要があります!その辺の基礎知識があれば、開発のエンジニアとしても需要があると思います。(Q)転職系ということで個人情報の扱いも多いかと思いますが、セキュリティ関連と掛け合わせたSRE話も何か注意点などあればお聞きしたいです酒井:転職サービスなので、一番重視すべきポイントです。個人情報保護のためのセキュリティテストはかなり頻繁に実施しています。本番リリースの直前には厳密なテストを行っています。SREとしては、インシデントが起きた際にアラートで検知する仕組みを運用しているので、個人情報に関するインシデントをいかに早く検知するかという課題に援用できるのではと考えています。(Q)エラーバジェットポリシーはどのように定着させましたか/させる予定ですか?酒井:これ以上SLOを悪くしたくないからリリースを控えるということは特にしていません。プロダクトの成長が著しいので、そのような判断は受け入れられません。ビジネス案件のリリースが主軸となっています。リリースを行ったときに、一気にエラーバジェットが消費されることがあるので、リリース直後はモニタリングを強化し、慎重に注視しています。普段の運用ではSLOステータスの状況を見てアラートを飛ばしており、SLO未達リスクが大きい場合は改善タスクを優先度高く取り組んでいます。実際に取り掛かる工数があるかどうかはチームによって異なります。(Q)SLOの対象となった指標について知りたいです。「ヘッドハンターの使い勝手〜」と言う話がありましたが、どのような指標を測定されているのでしょうか。酒井:SLIとしては、各ドメイン領域の重要機能(CUJ)で利用されるAPIの成功率とレイテンシーを計測しています。現状のSLOは、ある一定期間のSLIを計測し、それと比較して現状維持が継続していればOKという考え方で運用しています。(Q)さくらインターネットさん、クラウドベンダー・データセンター事業もされているような企業ならではのSRE意識、のようなものがあったらお聞きしてみたいです。山本:一緒に決めごとを作るのではなく、一緒に手を動かすことで信頼性を作っていくことです。期待値のズレをなくそうという意識で動いています。(Q)さくらさんのSRE部隊の構成・体制なんかにも興味あります山本:体制としては、一人ひとりが自立して動けるエンジニアが揃っており、それぞれが担当するものが異なります。SREとしてやりたいことを基盤に、それぞれが活動しています。(Q)SRE室というのはさくらさんの企業内全体での横串組織でしょうか?山本:クラウド事業本部の下にいます。横ぐしにはまだなっていません。(Q)SigNoz、恥ずかしながら初めて知りました。(1年目)こういったツール、アプリの情報収集や選定は専門部署で決められているのでしょうか?山本:SigNozについては、実験段階ということでSRE室、厳密にいうとオートスケールの開発室で選定しました。考えた上で、導入しなかった理由はあるでしょうか?(スモールスタートが理由かなと思いながらも他に理由があればと思った次第です。)山本:スモールスタートの部分が一番大きい理由でした。一台にまとまっていたので扱いやすいというのもあります。(Q)わたし、コミューンさんを使っているとあるコミュニティに入ってます!全然話は本筋じゃないですが、mが1つ減ったのはなぜですか?川岡:より多くの方に理解していただきやすくするため、コーポレートロゴおよびサービスロゴ・サービス名を「commmune」から「Commune」(3つのmを2つへ)と変更しています。(Q)コミューンさんのSRE部隊の体制なんかも参考に聞いてみたい、会社や全体でのSRE意識なんかも聞いてみたいです川岡:SREチームという単独の部隊があります。4人がプラットフォームも見るし、アラート対応もする、といったことをやっています。今後のこの関連の方向性、目指す姿なんかもお聞きしてみようかな。川岡:中途なのですが、最初はSREはなかったはずですが、かなり初期の段階でSREチームはあったと思います。当初は、インフラを面倒見ているのがSREチームみたいな感じでした。今後はSREチーム単独というよりかは、開発チームとの対話も必要になってくると思いますので、チームやメンバーとしての関わりは変化していくと思います。いかがでしたでしょうか、レポートの内容は以上です。StreetではIT・テクノロジーに関する様々なイベントや勉強会を開催しています!参加ご希望の方はフォームよりご登録をお願いいたします。引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。