GitLab におけるオブザーバビリティベースのパフォーマンステスト

概要

オブザーバビリティベースのパフォーマンステストは、包括的なインストルメンテーションとリアルタイムデータ収集を通じてシステムパフォーマンスを理解するためのプロアクティブなアプローチです。特定のテストシナリオに依存する従来のパフォーマンステストとは異なり、オブザーバビリティテストは実際の使用条件下でのアプリケーションの動作を深く可視化します。

アプローチ

オブザーバビリティテストは、オブザーバビリティツールを積極的に活用して、パフォーマンスの問題に発展するトレンドを検出します。一般的なアプローチをいくつか挙げます：

  • 開発チームがコンポーネントのダッシュボードを監視し、パフォーマンスの懸念事項をプロアクティブに把握する
  • オブザーバビリティデータに対する探索的テストをサポートするダッシュボード / ツールを構築して、明らかではないリンケージを探す（システム A がシステム B を遅くするなど）
    • パフォーマンスバー のようなツールを使うと、パフォーマンスの異常に気づき、根本原因の調査を開始できる
  • 既存のオブザーバビリティツールを開発 / テスト環境に拡張する
    • これにより、開発プロセスの早い段階でパフォーマンスメトリクスを取得できる
    • ツールに対するチームの親しみを高め、採用 / 使用を容易にする

主要コンポーネント

  • インストルメンテーション: アプリケーションスタック全体にトレース、メトリクス、構造化ログを組み込む。
  • リアルタイムデータ収集: 実際の使用中にパフォーマンスデータを継続的に収集する。
  • ホリスティック分析: システム全体を調査してボトルネックとパターンを特定する。

目標

  • パフォーマンス可視性の向上: チームが自分たちの作業のパフォーマンスへの影響を認識できるようにする。
  • プロアクティブな問題検出: 顧客への影響が発生する前に潜在的な問題を特定する。
  • チームのエンパワーメント: 専門知識を必要としないアクセスしやすいパフォーマンス分析ツールを提供する。

非目標

  • 負荷テストの置き換え: オブザーバビリティベースのテストは、GPT のような適切に設計された負荷テストを補完しますが、置き換えるものではありません。

実装アプローチ

フェーズ 1: 基盤整備

  1. 教育とドキュメント化
    • このプロセスが何であるかについてのドキュメントを追加して、チームが理解できるようにする
    • チームが理解して採用するためのトレーニングを作成する
    • チームがパフォーマンスダッシュボードを構築 / 使用できるようにするガイドを作成する
  2. ベースライン評価とインフラ
    • 既存のダッシュボードが多数あるため、必要なものをすでにカバーしている既存のものを特定する
    • ギャップを特定して補完する計画を策定する

フェーズ 2: 初期実装

  1. チーム選択
    • ペアリングする単一チームを選択する
    • チームのダッシュボードを特定 / 構築するために協力する
    • チームのワークフローに統合する
  2. フィードバックループとドキュメント化
    • 学んだ教訓を他のチームのためのドキュメントにフィードバックする

フェーズ 3: 実践と文化の構築

  1. アーリーアダプターへの拡大
  2. プロセス統合
    • GitLab Dev ワークフローでの使用方法をドキュメント化する

フェーズ 4: 展開と成熟

  1. 全面展開
  2. 継続的改善
  3. 高度な機能
    • 機械学習の統合: オブザーバビリティデータパターンに基づいてパフォーマンスの問題を予測する ML アルゴリズムを実装する。
    • 強化された開発者ツール: コード作成中にリアルタイムのパフォーマンスインサイトを提供する IDE プラグインを作成する。

ケーススタディ

ケーススタディ 1: オブザーバビリティベースのパフォーマンステストを使用したスクラムチーム

背景

チームは重要なパフォーマンス要件を持つ ETL（抽出、変換、読み込み）プロジェクトを構築していました。数時間のシステム遅延は ETL プロセスで越えられないバックログを生み出し、ビジネス運営にとってパフォーマンス監視が不可欠でした。チームは小規模（開発者 9 名、QA 2 名、Ops 1 名）で、2 週間おきに本番環境へデプロイしており、重量級のプロセスを追加することは大きな負担になったでしょう。そのため、既存のオブザーバビリティスタックを使用して実装しました。

オブザーバビリティの実装

3 層の監視アプローチを実装しました：

  1. ユーザーエクスペリエンス監視
    • 本番環境とテスト環境の両方で既存の Apdex ベースのダッシュボードを使用
    • ページ読み込み時間や API レスポンス時間などのエンドユーザーパフォーマンスメトリクスを追跡
    • 許容可能なパフォーマンスレベルの明確な閾値を設定
  2. サービスレベル監視
    • 主要サービスの詳細なダッシュボードを作成して以下を表示：
      • リソース使用率（CPU、メモリ、I/O）
      • サービスの依存関係とそのパフォーマンス
      • キューの長さと処理レート
    • 重要な ETL 操作の KPI 追跡を確立
  3. エラー追跡
    • 包括的なエラーロギングを実装
    • エラーパターン認識ダッシュボードを作成
    • エラーレートの閾値に対するアラートを設定

日常のワークフロー

  1. ダッシュボードレビュー（毎日のスタンドアップで 5 分）
    • チームが 3 つのダッシュボード層をすべてレビュー
    • 即座の問題解決よりもパターンの特定に集中
    • 構造化されたアプローチを使用：
      • ユーザーエクスペリエンスメトリクスをレビュー
      • サービスヘルス指標を確認
      • エラーパターンを調査
  2. Issue 管理
    • 懸念されるパターンの Issue を作成
    • 機能作業と並行してパフォーマンス Issue を優先付け
    • スプリント計画で専用の調査時間を割り当て

実装の課題

  • 小さなチームサイズと高速なリリースサイクルが提供できるものの制約となった
  • パフォーマンス調査の優先度と新機能開発のバランスを取ることが難しかった
    • パフォーマンスの改善が機能のデッドラインと競合することが多かった
    • 即時修正と長期的なソリューションの間でトレードオフを行わなければならないことがあった
  • チームに適したメトリクス / ダッシュボード設定を特定するために試行錯誤が必要だった
    • 監視すべき適切なメトリクスと考えていたものが正しくないと判明した
    • インフラが段階的に進化したため、ダッシュボードも同期を保ちながら進化させる必要があった

成果

  • パフォーマンス KPI を継続的に達成
  • 10 倍の成長期間中に 99.999% の稼働時間を維持
    • パフォーマンス関連のインシデントなし
    • 緊急の負荷テスト不要
    • オブザーバビリティデータに基づいてプロアクティブにスケール
  • 学んだ教訓：
    • オブザーバビリティによる早期警告が主要なインシデントを防いだ
    • 毎日のレビュー習慣がパフォーマンスを常に意識させた
    • 小さく定期的な改善は、大きなリアクティブな変更よりも優れている

ツールとテクノロジー

  • Prometheus
  • Grafana
  • [GitLab で使用されているその他の関連ツールを追加]

今後の方向性

[TBD]

リソース

最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License