技術ブループリント
このドキュメントの目的は、Observability チームの目標とガイドラインを詳細に説明することです。焦点は私たちの原則と今後5年間の目標です。
チームの原則
GitLab のための Observability（SaaS プラットフォームだけでなく）
私たちは協力することで、より良くなれます。
主な使命は GitLab の SaaS プラットフォームをサポートすることですが、GitLab の他のチームや他のカスタマーと積極的に知識を共有し、あらゆる人に機能するツールとフレームワークを構築します。
セルフサービス、発見性、アクセシビリティ
私たちのスタックを使用する人々のために、仕事を自分でやる代わりに、繰り返し可能なセルフサービスの機会を提供することを優先します。これにより全員の効率が向上します。 これらの機会はユーザーにとって使いやすく、発見しやすいものです。 内部ユーザーはプラットフォームの可観測性を改善し、ダッシュボードやレポートなどの高レベルの手段、および基礎データへの低レベルの明確に定義されたインターフェイスを通じて、可観測性データに自由にアクセスできます。
可能な場合は作成するツールで製品を改善する
私たちが行うすべてが製品に属するわけではありませんが、一部はそうかもしれません！
ドッグフーディング哲学 に沿って、SaaS のコンテキストを超えて他の GitLab カスタマーにアップストリームで提供できるものを検討します。 同様に、要件を満たす場合は GitLab 自身の機能とツールを優先して使用します。
ツールの移植性
GitLab の SaaS インフラストラクチャは複雑です。
さまざまなプラットフォームで同様かつより一体的な体験を効率的に提供するために、移植可能またはツールに依存しない可観測性ソリューションの提供を目指します。
標準に基づいた実装
可観測性分野は成熟した競争の激しい業界であり、それぞれに利点と微妙な点を持つさまざまな（オープンソースの）ツールが多数あります。
私たちは移植性の原則を強化する業界標準の実装を選択します。
プラットフォームファーストアプローチ
ポイントソリューションではなく、再利用可能なコンポーネントを構築します。一貫したデータ構造とクエリインターフェイスにより、すべての可観測性データへのセルフサービスアクセスを提供する統合プラットフォームに可観測性を変革します。
私たちが構築する可観測性サービスとツールを、外部品質標準を持つ内部プロダクトとして扱います。これは以下を意味します。
- ドキュメント: ツールとサービスは外部から購入・使用するプロダクトと同様に徹底的にドキュメント化されています
- 信頼性: 内部ツールに対しても本番サービスに期待するのと同じ品質標準を維持します
- ユーザーエクスペリエンス: 直感的で、効果的に使用するために最小限の暗黙知を必要とするインターフェイスとワークフローを設計します
- サポート: 明確なサポートチャンネルを提供し、包括的なトラブルシューティングリソースを維持します
目標
これはプロジェクト計画とロードマップ作成のインスピレーションの源として使用されるべき、今後5年間で達成したいと考える目標の理想的なリストです。
テーマ1: GitLab の他のチームとの協力を改善する
私たちは一緒に取り組むことでより速くなれます。GitLab の他のチームとの協力を改善することで、彼らの仕事も私たちの仕事も容易になり、新しい問題や追加の問題に集中できます。
このテーマ内の目標
- 内部カスタマーが誰かを特定し、フィードバックを求めることでニーズを満たせているかを確認する
- 他の可観測性ツールとその使用者・所有者を特定する（Sentry、Tableau など）
- GitLab.com のために Monitor:Observability トレーシングツールをドッグフードする
- Dedicated と協力して Observability Units の作成と統合を支援する
- Cells および他の GitLab イニシアチブの可観測性コンポーネントをサポートする
- 他のチーム（SIRT、ビジネスアナリティクス、finops など）と協力してロギングとメトリクスの重複を排除し、何がどこに行くかのスコープを定義する
- ステージグループがツールの問題ではなくコードの問題に集中しやすくするためにエラーバジェットのカスタマーエクスペリエンスを改善する
- 追加チーム/環境（例: ステージング環境、Dedicated、インフラストラクチャチームを含む）へエラーバジェットを拡大する
- 追加チーム/環境（例: ops とステージング環境、Dedicated など）へキャパシティプランニングを拡大する
- 可観測性のシングルペインオブグラス（SPOG）を作成する
テーマ2: チームが可観測性スタックにオンボードしやすくする
現在、可観測性スタックに新しいサービスを追加することは複雑で、よく理解されていないプロセスです。ソース側に新しいメトリクスを追加することも部分的にしか理解されていません。すべてのカスタマーがシステムへのオンボーディングをセルフサービスできるよう、適切なツールと抽象化を作成するべきです。これによりシステムの保守も容易になります。
このテーマ内の目標
- チームが可観測性スタックにオンボードするためのリファレンスツール（helm チャート、cloud run の設定）を提供する
- GitLab 内の広範なシステムに使用でき、セルフサービスが容易な再利用可能な抽象化を作成する
- メトリクスのカーディナリティを改善し、正しいことをやりやすく誤ったことをやりにくくするベストプラクティスをチームに教育し、改善を繰り返すためのフィードバックループを作成する
- ソース側（LabKit など）でメトリクスを追加するための明確に理解されたパターンを作成する
テーマ3: 可観測性スタックを管理・維持しやすくする
効率的に作業するために、システムの状態についてデータに基づいた意思決定を行い、自分たちや他のチームの使いやすさを改善し、セルフサービスに集中します。
このテーマ内の目標
- 可観測性ツール（メトリクス、ロギング、キャパシティプランニングなど）の可用性と正確性に関する SLO を設定する
- メトリクスと可観測性デプロイのための変更が有効になるまでの平均時間に関する SLO を設定する
- キャパシティプランニングを使用して可観測性スタックのすべての側面の飽和を予測する
- 可観測性デプロイのデプロイツール（helm ファイル、デプロイツールなど）を改善する
- runbooks リポジトリをより小さな自己完結型のリポジトリに分割する
- コスト効果が高く管理しやすいロギングソリューションを作成する
- キャパシティプランニングをできるだけ左方向に推進する（使用方法のドキュメント、ライブ Grafana ビューなど）
- 誰も使用しないデータを削除するためにメトリクス、ログ、ダッシュボードを監査するシステムを作成する
テーマ4: 過去のよくある質問と将来の未知の質問に答える能力を改善する
可観測性の不足が時間、コスト、可用性の損失につながった状況が多々ありました。サービスを所有するチームに適切なツールとデータを提供することで、環境を観察する方法を継続的に改善する必要があります。
このテーマ内の目標
- Redis の使用方法をより深く理解するための Redis キー分析の強化
キーのサブセットが使用されておらず無駄なスペースとなっていたり、誰も気づかないうちに大幅に増加していたりと、複数のインシデントと問題が発生しています。どのチームがどのデータの所有者かについても殆ど把握できておらず、追加の分析がさらに困難になっています。共有データリソースの使用方法を理解し、改善する能力を向上させる必要があります。
- データベース分析と可観測性の改善
データベーススケールは私たちとエンジニアリングチームにとって核心的な問題であり、定期的な問題、さらにはあまり知られていない問題（私たちが実行するデータベースシステムの規模による）に対処しています。解決する必要のあるスケーリングのボトルネックに関するデータベース分析と洞察を得るために、通常期待されるものを超えたデータベース可観測性技術が必要です。
- 現在保有しているデータで未知の質問に答える能力を提供する
テーマ5: 外部カスタマーエクスペリエンスの改善
- 可用性がカスタマーエクスペリエンスを反映する
- セルフマネージドカスタマーが私たちの知識を活用できるツールセットを作成する
- セルフマネージドカスタマー向けのキャパシティプランニングツールを作成する
現状分析
課題点
- データの不整合: 500エラーがメトリクス、ログ、トレース間で異なる名前で呼ばれている
- 暗黙知への依存: 複数のツールをナビゲートするために深い専門知識が必要
- 発見性の低さ: 可観測性データへの統合エントリーポイントがない
- 設定の複雑さ: ステージグループが可観測性設定を容易に所有できない
- 相関の限界: スタック全体を通じて問題を追跡することが難しい
- カバレッジのギャップ: HAProxy、Cloudflare、クライアントサイドコンポーネントの可観測性が欠如
現在のアーキテクチャの限界
- 標準化されていない複数のクエリインターフェイス
- 一貫したデータ構造や命名規則がない
- 孤立したデータサイロ（Prometheus にメトリクス、Elasticsearch にログ、分散トレーシングなし）
- 異なる可観測性シグナル間の手動相関
プラットフォームビジョン
この技術アーキテクチャブループリントは、GitLab の可観測性インフラストラクチャをチームの原則と戦略的目標に沿った統合セルフサービスプラットフォームに変革するためのロードマップを提供します。提案されたアーキテクチャは現在の課題に対処しながら、すべてのデプロイメントモデル（SaaS、Dedicated、セルフマネージド）にわたる将来のスケールと複雑さの要件に GitLab が対応できるよう位置づけます。
成功は標準への強いコミットメント、データの一貫性への注意、そして実装プロセス全体にわたる開発者エクスペリエンスへの注力にかかっています。可観測性をプラットフォームとして構築することで、GitLab 全体のチームが速く動き、より効果的にデバッグし、カスタマーにより良い体験を提供できるようにします。
コアプラットフォームの定義
可観測性をツールの集合から以下を提供する統合プラットフォームへ変革します。
- すべての可観測性データへのセルフサービスアクセス
- 一貫したデータ構造とクエリインターフェイス
- すべての GitLab コンポーネントにわたるエンドツーエンドの可視性
- 構造化されたデータ収集を通じて未知の問題に答える能力
プラットフォームが必要な理由
- データの一貫性: すべての可観測性シグナル間で標準化された命名規則と構造
- 発見性: 統合検索と相関機能を持つシングルエントリーポイント
- セルフサービス: プラットフォームの深い知識なしにステージグループが可観測性を所有できるようにする
- 摩擦の軽減: 暗黙知の要件と複雑なツールナビゲーションを排除する
- 未知の問題: 探索的分析を可能にする構造化されたデータ収集
これが解放するもの
- すべての GitLab ユーザーに対して一貫したプロダクトとしての可観測性
- プラットフォーム全体でのインシデント、ソフトウェアバグ、その他のデバッグに対する検出までの時間と復旧までの時間の短縮
- よりシンプルな可観測性スタックの深い理解に基づいた開発チームによるより速い問題検出と解決と合わせて、問題が発生する前に防止するプロアクティブな可観測性による GitLab.com および他の SaaS プラットフォームのより高い可用性
- 暗黙知を持つ個人への依存の軽減とステージグループからのより多くの所有
- 可観測性コンポーネントのクエリを試みるすべての種類のユーザーの不満の軽減
- 未知の問題に答える能力と、簡単に見つけられるよう可観測性データを記録するための標準化された手法のセット
- カスタマーエクスペリエンスのより良い反映
ターゲットアーキテクチャ
高レベルアーキテクチャ
書き込みパス
読み込みパス
設定
コアコンポーネント
1. 発見とエントリーレイヤー
- サービスカタログ統合: 可観測性メタデータを持つ自動生成されたサービスマップ
- データ相関: クロスシグナル検索機能（関連するメトリクス、ログ、トレース、プロファイルを検索）
- ロールベースアクセス: Okta との統合
2. クエリフェデレーションエンジン
現在は単一のアプリケーションを使用して可観測性データを表示していますが、包括的な可観測性データレイクの基盤として機能する統合データアクセスレイヤーの構築を構想しています。
長期的な目標:
- クロスシグナル相関: メトリクス、ログ、トレース間の自動リンク
- クエリ変換: 高レベルのクエリをバックエンド固有のフォーマットに変換
- キャッシュレイヤー: 頻繁にアクセスされるデータのインテリジェントキャッシュ
このフェデレーションエンジンにより、組織全体のすべての種類の可観測性データへのビジュアライゼーションと直接的なプログラマティックアクセスの両方が可能になります。これは可観測性データをレイク形式のアクセスパターンを持つ戦略的資産として扱うための第一歩を表しています。
3. データ処理レイヤー
- スキーマ適用: すべてのシグナル間で一貫したデータ構造を確保
- エンリッチメントパイプライン: メタデータ、サービス情報、相関IDを追加
- サンプリングとフィルタリング: シグナル品質を維持しながらインテリジェントにデータを削減
- フォーマット標準化: すべてのデータを OpenTelemetry フォーマットに変換
4. データストレージアーキテクチャ
メトリクス
- 設定可能な保持期間を持つ長期ストレージ
- 複数クラスターにわたるフェデレーション
ログ
- スキーマを強制した構造化ロギング
- 分析クエリ向けに最適化
- トレースとメトリクスとの自動相関
分散トレーシング
- 完全なリクエストライフサイクル追跡
- プロファイリングデータとの統合
ワイドイベント
- 未知の問題のための構造化イベントデータ
- 探索的分析のための柔軟なスキーマ
- ビジネスメトリクスとの統合
継続的プロファイリング
- 本番プロセスからキャプチャされたプロファイル
- 複雑な飽和問題のデバッグを支援
5. 収集とインスツルメンテーション
信頼されていないアグリゲーター
- クライアントサイドメトリクスを収集するツール
- 複雑なセキュリティ議論が必要
- 潜在的なソリューションの調査が必要
アプリケーションサイドのインスツルメンテーション
- 可能な場合は標準コレクター（Otel）を使用
- 合理的なデフォルトを持つ GitLab 固有の SDK を作成
- Labkit を使用して定義されたカバードエクスペリエンス/ユーザージャーニー
サードパーティ監視**
- 所有していないもの（Cloudflare、LLM など）の監視を容易にする
- サードパーティサービスをカバードエクスペリエンスとユーザージャーニーを通じてカスタマーフィーチャーに相関させることを可能にする
Observability スタック**
- GitLab システムの可観測性を追加するための標準化された方法
- テナント（Cells、Dedicated）および単独のアプリケーションを含む
