Geo検証テスト
Geoチームは、GitLabのマイナーバージョンとPostgreSQLデータベースのメジャーバージョンの間でアップグレードする際にGeoが動作することを確認するために、一般的なデプロイ設定に対して手動テストと検証を行っています。
このセクションには、検証テストのジャーナルと関連するイシューへのリンクが含まれています。
GitLabのアップグレード
以下は、私たちが行った GitLab アップグレードの検証テストです。
2020年7月
- 説明マルチノード設定で GitLab 12.10.12 から 13.0.10 パッケージへのアップグレードをテストしました。マルチノードの Geo デプロイでダウンタイムなしのアップグレードプロセス/手順を修正するイシューの一部として、ループするパイプライン、HAProxy 統計ダッシュボード、両方のノードの準備状況をログに記録するスクリプトを使ってダウンタイムを監視しました。
- 結果：プライマリサイトとセカンダリサイトのアップグレード中にダウンタイムを観測したため、部分的に成功。
- フォローアップのイシュー/アクション：
Geo プライマリサイトの repmgr から Patroni への切り替え：
- 説明マルチノードのGeoプライマリサイトでrepmgrからPatroniへの切り替えをテストしました。オーケストレータツールを使用して、repmgrによって管理される3つのデータベースノードを持つGeoインストールをデプロイしました。このアプローチにより、PatroniとPostgreSQL 11を使用したGeoインストールの検証に関する関連イシューにも対応することができました。
- 結果：部分的に成功しました。プライマリサイトでPatroniを有効にし、セカンダリサイトでデータベースのレプリケーションを設定しました。しかしながら、Patroniが再起動するたびにセカンダリサイトのレプリケーションスロットを削除してしまうことがわかりました。もう1つのイシューは、Patroniがクラスター内で新しいリーダーを選出した際に、セカンダリサイトが自動的に新しいリーダーに従わないことです。これらのイシューが解決されるまで、Geoインストール用のPatroniを公式にサポート、推奨することはできません。
- フォローアップのイシュー/アクション：
2020年6月
- 説明マルチノード設定で GitLab 12.9.10 から 12.10.12 パッケージへのアップグレードをテスト。ループするパイプラインと HAProxy 統計ダッシュボードを使ってダウンタイムを監視。
- 結果：プライマリサイトとセカンダリサイトのアップグレード中にダウンタイムを観測したため、部分的に成功。
- フォローアップのイシュー/アクション：
- 説明マルチノード設定で GitLab 12.8.1 から 12.9.10 パッケージへのアップグレードをテストしました。
- 結果ゼロダウンタイムを検証するためのループパイプラインをデモ中に実行しなかったため、部分的に成功。
- フォローアップのイシュー：
2020年2月
- 説明マルチノード設定でGitLab 12.7.5から最新のGitLab 12.8パッケージへのアップグレードをテストしました。
- 結果ダウンタイムを監視するためのループパイプラインをデモ中に実行しなかったため、部分的に成功。
2020年1月
- 説明マルチノード設定でGitLab 12.6.xから最新のGitLab 12.7パッケージへのアップグレードをテストしました。
- 結果アップグレードテストは成功。
- フォローアップのイシュー：
- 説明マルチノード設定でGitLab 12.5.7からGitLab 12.6.6へのアップグレードをテストしました。
- 結果アップグレードテストは成功。
- フォローアップのイシュー：ダウンタイムなしのアップグレードに関するドキュメントを更新し、デプロイするノードが使用中でないことを確認します。
- 説明マルチノード設定でGitLab 12.4.xから最新のGitLab 12.5パッケージへのアップグレードをテストしました。
- 結果アップグレードテストは成功。
- フォローアップのイシュー：
2019年10月
- 説明マルチノード設定で GitLab 12.3.5 から GitLab 12.4.1 へのアップグレードをテストしました。
- 結果アップグレードテストは成功。
- 説明GitLab 12.2.8 から GitLab 12.3.5 へのアップグレードをテストしました。
- 結果アップグレードテストは成功。
- 説明GitLab 12.1.9 から GitLab 12.2.8 へのアップグレードをテストしました。
- 結果設定ミスの可能性があるため、部分的に成功。
PostgreSQLのアップグレード
PostgreSQLのアップグレード検証テストを以下に示します。
2021年9月
PostgreSQL 13 で Geo インストールを検証：
- 説明PostgreSQL 13がGitLab 14.1のopt-inバージョンとして利用できるようになったので、Geoを使ったGitLabの新規インストールでPostgreSQL 13が有効になっているかテストしてみました。
- 結果GitLab Environment Toolkitを使ってGeoとPostgreSQL 13の環境構築に成功し、その環境に対してGeoのQAテストを失敗することなく実施しました。
2020年9月
Geo インストールの PostgreSQL 12 アップグレードの検証：
- 説明GitLab 13.3でPostgreSQL 12がopt-inバージョンとして利用可能になったため、既存のGeoインストールをPostgreSQL 11から12にアップグレードするテストを行いました。また、PostgreSQL 12をサポートするための修正が行われた後、Geoを使ったGitLabの新規インストールも再テストしました。これらのテストはGitLab 13.4のナイトリービルドを使って行われました。
- 結果プライマリとセカンダリに単一のデータベースノードを使用した Geo デプロイのテストは成功しました。Geoのプライマリ上でrepmgrとPatroniが管理するPostgreSQLクラスタで既知の問題が発生しました。このイシューが解決されるまで、プライマリ上のデータベースクラスタで PostgreSQL 12 を使用することは推奨されません。
- PostgreSQL クラスタの既知のイシュー：
2020年8月
- 説明PostgreSQL 12 が GitLab 13.3 のオプトイン・バージョンとして利用可能になる前に、PostgreSQL 12 を有効にして Geo をインストールした GitLab 13.3 の新規インストールをテストしました。
- 結果PostgreSQL 12では
recovery.confファイルがサポートされなくなったため、Geoセカンダリのセットアップには手動操作が必要でした。Linux パッケージに適切な変更が加えられて検証されるまで、Geo を PostgreSQL 12 でデプロイすることはお勧めしません。 - フォローアップのイシュー：
2020年4月
Geo インストールの PostgreSQL 11 アップグレード手順：
- 説明GitLab 12.10 で PostgreSQL 11 をデフォルトバージョンにする前に、Geo デプロイで PostgreSQL 11 へのアップグレードを GitLab 12.9 でテストしました。
- 結果：部分的に成功。別個のトラッキングデータベースを持つ複数ノードの設定でイシューが発見され、Geo が有効な場合に自動アップグレードを許可することについての懸念が提起されました。
- フォローアップのイシュー：
PostgreSQL 11 での Geo インストールを確認してください：
- 説明GitLab 12.10でPostgreSQL 11をデフォルトのバージョンにする前に、GeoをPostgreSQL 11でインストールしたGitLab 12.9の新規インストールをテストしました。
- 結果インストールテストは成功しました。
2019年9月
Geo の PostgreSQL 10.0 アップグレードのテストと検証：
- 説明12.0のリリースに伴い、GitLabはPostgreSQL 10.0へのアップグレードが必要になりました。GitLab 12.1.8までの様々なアップグレードシナリオをテストしました。
- 結果アップグレード時に複数のイシューが見つかりました。
- フォローアップのイシュー：
オブジェクトストレージのレプリケーションテスト
以下は、追加で実施した検証テストです。
2022年4月
AWSベースのオブジェクトストレージを使用したオブジェクトストレージレプリケーションの検証：
- 説明AWSベースのオブジェクトストレージレプリケーションとGitLabベースのオブジェクトストレージレプリケーションを使用した場合に、プライマリのオブジェクトストレージからセカンダリに単一のイメージをレプリケートするのにかかる平均時間をテストしました。このテストは、プライマリサイトのプロジェクトに毎秒1MBのイメージを60秒間アップロードすることで行いました。そして、セカンダリサイトでイメージが利用可能になるまでの時間を計測しました。これにはRubyスクリプトを使用しました。
- 結果AWSマネージドレプリケーションを使用した場合、サイト間でイメージがレプリケートされるまでの平均時間は約49秒でした。同じリージョンでGeoマネージドレプリケーションを使用した場合、レプリケーションにかかる平均時間はわずか5秒でしたが、リージョンをまたいでレプリケーションを行った場合、平均時間は33秒に増加しました。
GCPベースのオブジェクトストレージを使用して、オブジェクトストレージのレプリケーションを検証します：
- 説明GCPベースのオブジェクトストレージレプリケーションとGitLabベースのオブジェクトストレージレプリケーションを使用した場合に、1つのイメージがプライマリのオブジェクトストレージからセカンダリにレプリケートされるまでの平均時間をテストしました。このテストは、プライマリサイトのプロジェクトに1MBのイメージを1秒ごとに60秒間アップロードすることで行いました。そして、セカンダリサイトでイメージが利用可能になるまでの時間を計測しました。これにはRubyスクリプトを使用しました。
- 結果GCPは他のクラウドプロバイダーとは異なるレプリケーションを扱います。GCPでは、マルチリージョン、デュアルリージョン、シングルリージョンのいずれかのバケットを作成します。これは、選択されたオプションに基づいて、バケットが自動的にリージョンにレプリカを保存することを意味します。マルチリージョンを使用した場合でも、アメリカ、ヨーロッパ、アジアといった単一の大陸にのみレプリケートされます。現在のところ、GCPベースのレプリケーションを使用して大陸間でオブジェクトをレプリケートする方法はないようです。Geoマネージドレプリケーションの場合、同じリージョン内でレプリケートする場合の平均時間は6秒で、リージョンをまたいでレプリケートする場合はわずか9秒でした。
2022年1月
Azureベースのオブジェクトストレージを使用したオブジェクトストレージレプリケーションの検証：
- 説明AzureベースのオブジェクトストレージレプリケーションとGitLabベースのオブジェクトストレージレプリケーションを使用した場合に、1つのイメージがプライマリのオブジェクトストレージからセカンダリにレプリケートされるまでの平均時間をテストしました。これは、プライマリサイトのプロジェクトに1MBのイメージを1秒ごとに60秒間アップロードしてテストしました。そして、セカンダリサイトでイメージが利用可能になるまでの時間を計測しました。これにはRubyスクリプトを使用しました。
- 結果Azureベースのレプリケーションを使用した場合、プライマリオブジェクトストレージからセカンダリへのイメージのレプリケーションにかかる平均時間は40秒、レプリケーションにかかる最長時間は70秒、最短時間は11秒でした。GitLabベースのレプリケーションを使用した場合、レプリケーションが完了するまでの平均時間は5秒、最長のレプリケーション時間は10秒、最速は3秒でした。
- 続いてのイシューです：
2021年5月
オブジェクトストレージレプリケーションを有効にしてフェイルオーバーをテストします：
- 説明テスト当時、Geo のオブジェクトストレージレプリケーション機能はベータ版でした。オブジェクトストレージレプリケーションが意図したとおりに動作し、フェイルオーバー後にデータが新しいプライマリに存在することをテストしました。
- 結果テストは成功しました。オブジェクトストレージのデータはレプリケートされ、フェイルオーバー後に存在しました。
- フォローアップのイシュー：
その他のテスト
2020年8月
- 説明プライマリおよびセカンダリ Geo サイトの両方で設定された Gitaly クラスターで Geo デプロイをテストしました。プライマリ Geo サイトで自動 Gitaly クラスター フェイルオーバーをトリガーし、エンドツーエンドの Geo テストを実行しました。その後、セカンダリ Geo サイトで Gitaly クラスターのフェイルオーバーをトリガーし、エンドツーエンドの Geo テストを再実行しました。
- 結果：プライマリサイトの Gitaly クラスターフェイルオーバーの前後、およびセカンダリサイトの Gitaly クラスターフェイルオーバーの前後で、エンドツーエンドのテストに成功。