staging.gitlab.com 上の Geo
概要
Geo は GitLab.com のステージング環境で完全に動作しています。これはチームが新しい機能をスケールでテストおよび検証し、バグを発見し、パフォーマンスの問題を特定できるようにする重要なドッグフーディングの取り組みです。これは、Geo の改善に対する信頼を高めるため、お客様にとって重要です。
以下の項目では、ステージング環境で Geo を有効にする際に対処したいくつかの特定の設定や方法について説明します:
アーキテクチャ
staging.gitlab.com のために 1 つの Geo セカンダリノードが稼働しており、すべてのコンポーネントが 1 つの単一ノードに配置されたオールインワンボックスとして設定されています。現在のところ、Geo HA デプロイは実行していません。
PostgreSQL レプリケーション
ステージング環境の Geo プライマリデータベースからデータをレプリケートするためにアーカイブリカバリを使用することにしました。設定方法の完全な説明は、単一ノードのインストールを参照するこのランブックの上部セクションにあります。
PostgreSQL Foreign Data Wrappers（FDW）- クエリのタイムアウト
GitLab Geo は、セカンダリレプリカとトラッキングデータベース間でいくつかのクロスデータベースクエリを実行するために PostgreSQL Foreign Data Wrappers（FDW）を使用します。このアプローチの技術的な優雅さにもかかわらず、これらのクエリは Geo にいくつかの問題を引き起こしました。
当初、ステージング環境はまだ PostgreSQL 9.6 を実行しており、Geo は PostgreSQL 10 以降でのみ利用可能な join push-down や aggregate push-down などの FDW の改善の恩恵を受けます。これにより、バックフィルフェーズ中に一部の FDW クエリがタイムアウトしました。この問題が PostgreSQL 10 以降の Geo では問題ではなくなることを知っているため、ステージングでのステートメントタイムアウトを 20 分に増やすことでバックフィルを続行するのに十分でした。
13.2 リリース以降、バックフィル操作を簡素化することで Geo のスケーラビリティを改善し、これらのクロスデータベースクエリを排除して FDW 要件を削除しました。
PostgreSQL バージョン
ステージングは現在 PostgreSQL バージョン 11.7 を使用しています。2020 年 5 月に、SRE データストアチームと協力して Geo ノードを Postgres 11 を使用するように更新しました。
Gitaly シャード
Geo セカンダリノードの前提条件として、同じ論理 Gitaly シャードセットで設定されることが必要です。つまり、git_data_dirs 設定の名前が Geo プライマリノードのものと一致する必要があります。
ステージングでは、ほとんどのプライマリ Git ストレージシャードはほぼ空であり、ZFS ストレージや Praefect などの未完成の機能の実験的なアーティファクトがあります。このため、現時点では 1 つの物理シャードのみを使用し、すべての論理シャードをその上に格納しています。これを実現するために、Geo セカンダリノードの git_data_dirs で定義された各論理 Gitaly シャードが同じパスと gitaly_address を共有します。
シークレット
ステージングシークレットを使用している間に、ステージング上の Geo セカンダリノードで問題が発生しました。Geo セカンダリノードは独自の GKMS シークレットストアを使用する必要があり、これにより競合する設定を削除し、本番環境とは異なるこのノードのシークレットを設定することができました。
デプロイ
Geo セカンダリノードへのデプロイは間接的に行われます。staging.gitlab.com へのデプロイの最終ステップの 1 つは、実行するべき GitLab のバージョンで Chef の属性を更新し、その特定のパッケージのインストールを有効にするフラグを設定することです。Chef は Geo セカンダリノードでほぼ 30 分ごとに実行されます。staging.gitlab.com への正常なデプロイ後に、このノードで Chef が次回実行されるとき、Geo ノードはアップグレードを開始します。最悪の場合、Geo セカンダリノードはアップグレードプロセスを開始するまでに 30 分かかります。
既知の問題
ステージング環境には、データベース内のすべてのプロジェクトのファイルシステム上のデータ（リポジトリ、LFS オブジェクト、アップロードなど）がありません。失敗したレジストリの再同期を何度も試みることによる多くの偽陽性エラーとリソースの無駄を避けるために、グループレベルで選択的同期を有効にすることにしました。現在は gitlab-org グループをレプリケートしています。
ステージングには既存のレプリケーション/検証の問題がある場合があります。それらすべてを Geo ステージングメンテナンス Epic で追跡することを目指しています。
監視
Geo エンジニアの責任とサポートローテーション
全員が自分の MR の QA テストに責任を持ちます（該当する場合）。重要なものは確実に対処し、それ以下のものは追跡してください。ステージング上の Geo で問題に気づいたら、ローテーションエンジニアに DRI として ping/割り当てを行ってください。
毎月、Geo バックエンドエンジニアがステージング上の Geo を監視し、問題を作成/エスカレートする DRI となります。これはオンコールシフトではなく、DRI は問題を自分自身で修正することは必須ではありません。
ローテーションの最後の週に、退任者は着任者とのミーティングを設定して次のことを確認する必要があります:
- ステージング環境への SSH アクセスがある
- ステージング上の Geo 管理 UI を表示できる
- Sentry の geo-staging-gitlabcom プロジェクトの通知を有効にしている
- ステージング Geo の現在進行中の Issue を把握している
このローテーションの主な目標:
- ステージング上の Geo が機能することを確認する。
- ステージング上の Geo を機能させる責任を分散する。
- カスタマー sysadmin の経験をよりよく理解する。
DRI の日次タスク
- https://staging.gitlab.com/admin/geo/nodes を確認する。何か異常に見えるものがあれば、
#geo-for-gitlab-dot-comで質問する。必要に応じて#g_geoにクロスポストする。重要なものは確実に対処する。 - Sentry を確認する。現在はノイズが多いですが、エッジケースを特定したり、内部で何かが問題かどうかを特定するのに役立ちます。
- トリガーされたアラートを確認する。見つかった場合は、対応のためのドキュメントに従う。
ステージング上の Geo が機能していない場合
- 診断を進める方法:
- Sentry、Kibana、Grafana などで調査し、SSH でサーバーにアクセスする。
- Issue を開く
- 他の人に助けを求める
- エンジニアリングマネージャー、プロダクトマネージャー、インフラのカウンターパートと一緒に Issue の優先順位付けを支援する。
ローテーションスケジュール
| 月 | 担当者 |
|---|---|
| 2023 | |
| 12 月 | @jtapiab |
| 11 月 | @aakriti.gupta |
| 10 月 | @brodock |
| 9 月 | @dbalexandre |
| 8 月 | @vsizov |
| 7 月 | @mkozono |
| 6 月 | @ibaum |
| 2022 | |
| 7 月 | @dbalexandre |
| 6 月 | @mkozono |
| 5 月 | @cat |
| 4 月 | @mkozono |
| 3 月 | @dbalexandre |
| 2 月 | @cat |
| 1 月 | @vsizov |
