データベース: ディザスタリカバリ
Visibility: Audit
GitLab バックアップのディザスタリカバリポリシーに移動しました。
データベース
This is a Controlled Document
In line with GitLab’s regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged.Visibility: Audit
GitLab におけるデータベース信頼性
データベース信頼性エンジニア（DBRE）のグループは、GitLab.com を運用する Reliability Engineering チームに所属しています。私たちはインフラストラクチャと GitLab のプロダクトにおけるデータベース信頼性の側面を最も重視しています。
私たちは可能な限りデータ駆動の観点からデータベース信頼性にアプローチするよう努めています。そのため、以下でサービスレベル目標を定義することから始め、GitLab.com に対して現在維持することを目標としているサービスレベルをドキュメント化しています。
データベース SLO
私たちはサービスレベル目標（SLO）を使用して、データベースのパフォーマンスと信頼性の側面について検討します。SLO を「アーキテクトとオペレーターによるコミットメントであり、それらのコミットメントを満たすためのシステムの設計と運用を導くもの」1 と考えています。
バックアップとリカバリ
バックアップとリカバリには 2 つの SLO があります:
| SLO | 現在のレベル | 定義 |
|---|---|---|
DB-DR-TTR | 8 時間 | 災害時のフルデータベースバックアップからの最大回復時間 |
DB-DR-RETENTION | 14 日間 | GCS のマルチリージョンストレージクラスでリカバリ目的のバックアップを保持する日数 |
主要なバックアップ戦略は、すべてのデータベースクラスターの時間ごとの増分ディスクスナップショット（ブロックレベル）を取ることです（これらはマルチリージョン標準永続ディスクスナップショットです）。 また、データベースファイルの週次フルバックアップ（データベースレベル）と、別のマルチリージョン Google Cloud Storage バケットに保存される日次増分バックアップを含む二次バックアップ戦略も実装しています。さらに、すべての先行書き込み（トランザクション）ログデータを GCS に継続的にアーカイブし、いずれかのバックアップ戦略（ブロックレベルまたはデータベースレベル）を使用したポイントインタイムリカバリ（PITR）を可能にしています。ディザスタリカバリの詳細はこちら
回復時間には、ベースラインバックアップから PITR を実行する時間と、特定のポイントインタイム（災害の直前）までのトランザクションログアーカイブの回復時間が含まれます。
私たちは DB-DR-RETENTION 日以内の任意のポイントインタイムに回復できます。
高可用性
GitLab.com では 99.95% 以上の可用性を維持しています。PostgreSQL データベースについては、以下の SLO を定義しています:
| SLO | レベル | 定義 |
|---|---|---|
DB-HA-UPTIME | 99.9% | 一般的なデータベース可用性 |
DB-HA-PERF | p99 < 200ms | データベースクエリ実行時間の 99 パーセンタイルがこのレベル以下 |
DB-HA-LOSS | 60 秒 | プライマリ障害時に許容される最大データ損失 |
DB-HA-UPTIME が 99.9% であることで、月間約 45 分のダウンタイムが許容されます。アップタイムとは、他のデータベース SLO を維持しながら、データベースクラスターがアプリケーションからのクエリに応答できることを意味します。
計画的なダウンタイムに対して月間 45 分のダウンタイムバジェットを確保していますが、ダウンタイムをできるだけ低く抑えるよう努めています。ダウンタイムバジェットはシステムに変更を導入するために使用できます。バジェットが使い果たされた場合（計画的または非計画的に）、変更の導入を停止し、可用性に集中します（SRE のエラーバジェットに似ています）。
DB-HA-PERF については、クエリの 99% が 200ms 以内に完了するべきです。
DB-HA-LOSS では、レプリケーションラグの上限が必要です。プライマリへの書き込みは、セカンダリ（または PITR アーカイブ）にレプリケーションされるまでリスクがあると見なされます。
共通リンク
よく使われるリンクを以下に示します。
モニタリング & パフォーマンス関連ツール
データベーススペシャリストとして、以下のツールが非常に役立ちます:
- Postgres Checkup: PostgreSQL データベースの状態に関する詳細なレポート
- Private Grafana: アプリケーションとシステムレベルの両方のパフォーマンスデータ
- Performance Bar: GitLab で
pbと入力すると、ページ上部にパフォーマンスメトリクスのバーが表示されます。このツールは実行されたクエリとその実行時間を表示するのに特に便利です - Sherlock: Performance Bar に似たツールですが、開発環境向けです。Sherlock はバックトレースと実行されたクエリの
EXPLAIN ANALYZEの出力を表示できます。env ENABLE_SHERLOCK=1 bundle exec rails sで Rails を起動することで有効化できます - https://explain.depesz.com/ は
EXPLAIN ANALYZEの出力を視覚化するためのツールです
ダッシュボード
以下の（非公開の）Grafana ダッシュボードはデータベーススペシャリストにとって重要/有用です:
ドキュメント
基本的に https://docs.gitlab.com/development/database 以下のすべてが対象ですが、特に以下のガイドが重要です:
- ダウンタイムが必要なものは何ですか?
- データベースインデックスの追加
- デプロイ後マイグレーション
- バックグラウンドマイグレーション
- SQL マイグレーションスタイルガイド
- SQL クエリガイドライン
- インフラストラクチャのランブックとドキュメント
その他の開発関連ガイドについては https://docs.gitlab.com/ee/development/ を参照してください。
「Database Reliability Engineering」、O’Reilly Media、2017 年より ↩︎
