GitLab サイト信頼性エンジニアリング for AWS

Gitaly SREの考察

GitalyはGitリポジトリ・ストレージのための組み込みサービスです。GitalyとGitalyクラスターは、GitLabのサービス側で使用しなければならないオープンソースのGitバイナリの水平スケーリングに関する基本的な課題を克服するために、GitLabによって設計されました。このトピックに関する詳細なテクニカルリーディングはこちらです：

Gitalyが作られた理由

なぜGitLabがGitalyを作るために投資しなければならなかったのか、その根本的な根拠を理解したい方は、以下の最小限のトピックのリストをお読みください：

GitalyとPraefectの選挙

Gitalyクラスタの一貫性の一環として、Praefectノードは時折、どのデータコピーが最も正確かを投票しなければなりません。このため、膠着状態を避けるために、Praefectノードの数が不均等である必要があります。つまり、HAでは、GitalyとPraefectは最低3つのノードを必要とします。

Gitalyパフォーマンス監視

ディスクIO、ネットワークIO、メモリなどのボトルネックを特定するために、Gitalyインスタンスの完全なパフォーマンス・メトリクスを収集する必要があります。

Gitalyパフォーマンスガイドライン

GitalyはGitLabの主要なGitリポジトリストレージとして機能します。しかし、ストリーミングファイルサーバーではありません。また、Gitパックファイルの準備やキャッシュなど、多くの負荷のかかる計算も行います。

note
すべての推奨は、パフォーマンステストを含む本番環境での設定です。トレーニングや機能テストのようなテスト設定には、より安価なオプションを使うことができます。ただし、パフォーマンスにイシューがある場合は、調整や再構築を行う必要があります。

全体的な推奨事項

CPUとメモリの推奨値

  • 一般的なGitLab GitalyノードのCPUとメモリの推奨値は、リポジトリ間で比較的均等な負荷を想定しています。GitLabパフォーマンスツール(GPT) 、特徴的でないリポジトリのテスト、および/またはGitalyメトリクスのSREモニタリングは、一般的な推奨値よりも高いメモリおよび/またはCPUを選択するタイミングを知らせるかもしれません。

対応するために

  • Git PackのファイルオペレーションはメモリとCPUを消費します。
  • リポジトリーのコミットトラフィックが密集していたり、大きかったり、頻度が高かったりすると、負荷に対応するためにより多くの CPU とメモリが必要になります。バイナリの保存やビジー、大きなモノレポなどのパターンは、高負荷を引き起こす可能性がある例です。

ディスク I/O に関する推奨事項

  • SSDストレージと、耐久性と速度の要件に適したElastic Block Store(EBS) ストレージのクラスのみを使用してください。
  • プロビジョニングされたEBS IOを使用しない場合、EBSボリュームのサイズがI/Oレベルを決定するため、必要以上に大きなボリュームをプロビジョニングすることが、EBS IOを向上させる最も安価な方法となります。
  • Gitalyパフォーマンス・モニタリングがディスク・ストレスの兆候を示した場合、プロビジョニングされたIOPSレベルのいずれかを選択することができます。EBS の IOPS レベルは耐久性も強化されているため、パフォーマンスを考慮しない実装もあります。

対応するために

  • Gitalyのストレージはローカルであることが想定されています（EFSを含むあらゆるタイプのNFSではありません）。
  • Gitalyサーバーはまた、Gitパックファイルを構築しキャッシュするためのディスク領域を必要とします。これは、Gitリポジトリの永続的なストレージ以上のものです。
  • Git PackファイルはGitalyにキャッシュされます。一時ディスクでのパックファイルの作成は高速なディスクの恩恵を受け、パックファイルのディスクキャッシュは十分なディスク容量の恩恵を受けます。

ネットワークI/Oの推奨

  • インスタンス・レベルのネットワークI/Oボトルネックが原因でクラスターのレプリケーション・レイテンシが発生しないように、Elastic Network Adapter(ENA) アドバンスト・ネットワーキングをサポートするインスタンス・タイプのみを使用します。
  • 10Gbpsを超えるサイズのインスタンスを選択してください。ただし、必要な場合に限り、モニタリングやストレステストによってノードレベルのネットワークボトルネックが証明された場合に限ります。

対応するために

  • Gitalyノードは、（開発者のエンドポイントを追加したり、CI/CDに）プッシュとプルのオペレーションのためのリポジトリのストリーミングの主な作業を行います。
  • Gitalyサーバーは、クラスターが運用とデータの整合性を維持するために、クラスターノード間およびPreefectサービスとの間で合理的な低レイテンシーを必要とします。
  • Gitalyノードは、ネットワークのボトルネック回避を第一に考慮して選択する必要があります。
  • Gitalyノードは、ネットワークの飽和を監視する必要があります。
  • すべてのネットワークのイシューが、ノードレベルのネットワークの最適化で解決できるわけではありません：
    • クラスターのノードレプリケーションは、ノード間のすべてのネットワークに依存します。
    • エンドポイントをプルしたりプッシュしたりするGitalyネットワーキングのパフォーマンスは、その間のすべてのネットワーキングに依存します。

AWSのGitalyバックアップ

Gitalyディスク情報のレプリケーションメタデータをPraefectが追跡する性質上、最適なバックアップ方法は、公式のバックアップと復元Rakeタスクです。

AWSのGitalyリカバリ

Gitalyクラスタはスナップショットバックアップをサポートしていません。スナップショットバックアップは、Praefectデータベースがディスクストレージと同期しなくなるイシューを引き起こす可能性があるためです。Praefectはリストア中にGitalyディスク情報のレプリケーションメタデータを再構築する性質上、最適なリカバリ方法は公式のバックアップとリストアRakeタスクです。

EKSのGitaly HAクイックスタート

AWS GitLab Cloud Native Hybrid on EKS Quick Startfor GitLab Cloud Nativeは、Gitalyをマルチゾーンの自己修復インフラとして実装しています。AZ障害を含むGitalyノードに障害が発生した場合に、Gitalyノードを再確立するための特定のコードを備えています。

Gitalyの長期管理

Gitalyノードのディスクサイズは、Gitリポジトリの成長とGitalyのテンポラリ・ストレージとキャッシュ・ストレージの必要性に応じて、監視し、増加させる必要があります。すべてのノードのストレージ設定は同一に保つ必要があります。