フィーチャー開発のためのデータ保持ガイドライン
概要
データ保持は GitLab におけるフィーチャー開発の重要な側面です。フィーチャーを構築・保守するにあたって、収集・保存するデータのライフサイクルを考慮する必要があります。このドキュメントでは、フィーチャー開発の最初からデータ保持の考慮事項を組み込むためのガイドラインを概説します。
データ保持が重要な理由
- システムパフォーマンス: 時間ベースのデータ整理により、クエリの最適化とデータアクセスパターンの効率化が可能になり、応答時間の短縮とシステムスケーラビリティの向上につながります。
- インフラコスト: データライフサイクルポリシーによる戦略的なストレージ管理は、プライマリストレージ、バックアップ、ディザスタリカバリシステムのインフラコストを削減します。
- エンジニアリングの効率化: 最初からデータ保持を考慮してフィーチャーを設計することで、明確なデータライフサイクルを確立し、技術的負債を削減し、データ移行を迅速化することで、開発がより速くより信頼性の高いものになります。
フィーチャー開発のガイドライン
1. 早期計画
新しいフィーチャーを設計する際、初期計画フェーズでデータ保持要件を検討してください:
- 永続化されるデータの種類を文書化する。ユーザー向けデータか？処理を効率化するために内部で生成されるデータか？派生/キャッシュデータか？
- 各データタイプのビジネス目的と必要な保持期間を特定する。
- 古いデータの製品上の正当性と顧客利用パターンを定義する。新しいデータと比較して、古いデータとどのように関わるか？時間の経過とともに価値はどのように変化するか？
- データ保持に影響を与える可能性のある規制要件を考慮する（個人識別情報など）。
- データ削除またはアーカイブのメカニズムを計画する。
2. データライフサイクルを考慮した設計
フィーチャーはデータが永続的ではないという理解の下に設計すべきです:
- データが無限に利用可能であるという前提を避ける。
- 欠損またはアーカイブされたデータの優雅な処理を実装する。
- データの利用可能期間を明確に伝えるユーザーインターフェースを設計する。
- 長期的な文脈での閲覧に最適化された長期ストレージ用データ構造を設計する。
- 特に、オンデマンドで優雅に再現できる派生/キャッシュデータに対して、必要に応じて「TTL（Time to Live）」メカニズムの実装を検討する。
3. ドキュメント推奨事項
各フィーチャーの実装には以下を含める必要があります:
- データ保持期間（GitLab.com およびデフォルト値がある場合）とビジネス上の理由/正当性の明確なドキュメント
- データ削除/アーカイブメカニズムの説明。
- データ削除が依存フィーチャーに与える影響の分析。
実装チェックリスト
新しいフィーチャーのマージリクエストを提出する前に:
- データ保持要件を文書化する。
- データ削除を念頭に置いてデータモデルを設計する。
- データ削除/アーカイブメカニズムを実装する。
- 欠損/アーカイブされたデータを使用したフィーチャーの動作をテストする。
- ユーザードキュメントに保持期間を含める。
- 依存フィーチャーへの影響を考慮する。
- バックアップ/リストアおよびエクスポート/インポートへの影響を考慮する。
- レプリケーション（例: Geo）への影響を考慮する。
