エントリー済み

その修正で本当に速くなったのか?k6とOpenTelemetryで確かめる性能改善

中級者 Operation / Monitoring / Logging

開発側では「速くなった」と報告した修正が、運用側の試験では「まだ遅い」と評価されたら、何を確かめればよいでしょうか。

本セッションでは、k6で負荷をかけ、OpenTelemetryで遅い処理を調べ、修正の効果を再試験で確かめる一連の手順を解説します。同時に処理できる件数を制限したHTTP APIを題材に、開発と運用で試験条件と観測データをそろえます。

応答を待ってから次のリクエストを送る試験では、処理が遅くなると送信頻度も下がります。修正の前後で負荷が変わってしまうと、応答時間の差を修正の効果とは判断できません。そこで一定の頻度で送る試験と比較し、想定した負荷を実際にかけられたかを確認します。

次に、アプリ内の待機時間と呼び出し先の処理時間から修正箇所を絞ります。制限を緩めた後は、呼び出し先に要求が集中して別の待ち時間やエラーを生んでいないかも調べます。同じ条件で再試験し、応答時間とエラーの割合から変更を評価します。

最後に、改善しなかった結果も含めて試験条件と調査記録を共有し、開発と運用が同じデータから性能変更を判断する手順を示します。

Speaker

Yoshi Yamaguchi

Grafana Labs

Staff Developer Advocate

グラファナラボジャパン合同会社スタッフデベロッパーアドボケイト。Grafana CloudとGrafanaスタックの普及と技術支援を担当し、特にオブザーバビリティ、SRE、DevOpsといった領域を担当。OpenTelemetryやGoのコミュニティの支援も活発に行っている。「OpenTelemetryではじめるテレメトリーサンプリング」執筆、「入門OpenTelemetry」「SREをはじめよう」「効率的なGo」「SLO サービスレベル目標」「オブザーバビリティ・エンジニアリング」翻訳、「SREの探求」監訳をはじめ、技術書の執筆・翻訳に多数関わる。