データライフサイクル

重要な注意事項: このベストプラクティスのガバナンスと施行は現在も進行中です。

はじめに

データは消えることなく蓄積し続けます。そしてあなたのアプリケーションを埋め尽くすことになります。

アプリケーションが生成するデータには、時間の経過とともに複利的に増加する内在的なコストがあります。意図的なライフサイクル管理がなければ、無制限なデータ増加はパフォーマンスの課題、スケーラビリティの制限、クラウドコストの増大につながります。さらに、顧客は履歴データへの依存関係を構築してしまうため、後からポリシーを実施することが非常に困難になります。

肥大化したデータを後から管理することは、費用がかかり困難です。設計フェーズでアプリケーションのデータライフサイクルを検討することは、パフォーマンスの高いスケーラブルなアプリケーションを開発するために不可欠です。

なぜ重要なのか？

適切なデータライフサイクル計画がなければ、アプリケーションはデータを無制限に蓄積し続け、いくつかの深刻な問題を引き起こします:

  • パフォーマンスの劣化: テーブルが大きくなるにつれてデータベースのパフォーマンスが低下し、プランのフリッピングや TOAST ストレージによるクエリ遅延の増加などの問題を引き起こします。
  • クラウドコストの増大: データ増加を管理しないと、ストレージコストが増加し、膨れ上がったデータセットの処理に必要な過剰なコンピューティングリソースが必要になります。
  • 運用の複雑化: インデックスやカラムの追加などのデータベース変更がますます困難になります。
  • コンプライアンスリスク: データ保持を適切に管理しないと、データ最小化と保持期間の制限を義務付ける GDPR などの規制に違反することになります。
  • 顧客依存のトラップ: 最初から明確なライフサイクルポリシーを確立しないと、顧客が履歴データへの依存関係を構築してしまい、後からユーザーエクスペリエンスを損なわずに保持ポリシーを実施することがほぼ不可能になります。これはデータの文脈における Hyrum’s Law の一形態です。

コアデータライフサイクルフェーズ

すべてのアプリケーション設計において、以下のデータライフサイクルフェーズを考慮する必要があります:

1. データ作成

データモデルを設計する際、エンジニアは各データタイプをその目的と予想されるライフサイクルに応じて分類する必要があります:

  • 目的の分類:

    • 運用データ: コアアプリケーション機能に必要なデータ
    • ユーザー生成データ: ユーザーが作成し所有するデータ
    • 派生データ: パフォーマンス最適化のために生成されるデータ
    • メタデータ: システム操作とイベントに関するデータ

  • 重要な問い:

    • このデータはどのように生成されるか？（自動化、ユーザー入力、派生）
    • このデータはどのようなビジネス機能を果たすか？
    • このデータの所有者は誰か？（システム、ユーザー、第三者）
    • データ作成の予想される頻度と量はどの程度か？
    • 生成が許可されるデータ量に対してどのような制限を設けるか？

2. データの老化

すべてのデータモデルは、時間の経過に伴うデータの価値変化を明示的に考慮する必要があります。

以下の図はデータが老化するにつれた各フェーズを示しています。

flowchart LR
    A[新鮮] -->B[最近]
    B --> C[老化]

  • 価値劣化の分析:

    • 各データタイプが運用上の価値をどの程度の速さで失うかを定義する
    • データが「老化」ステータスに移行するタイミングを判断するための基準を確立する
    • 例: 1年以上前にクローズされたマージリクエストのパイプライン結果は、オープン中のマージリクエストのものよりも価値が低い

  • 重要な問い:

    • このデータタイプはどの程度の速さで陳腐化または関連性が低下するか？
    • 長期保持を有料機能にすべき閾値年齢はいくつか？
    • 運用上の有用性を超えてデータを保持すべき規制上の理由があるか？
    • 老化したデータをより安価に保存できるか？

3. データのオフロード

デフォルトでは、すべてのデータにデータ保持ポリシーを設ける必要があります。保持が必要なデータには、安価なストレージへのオフロード戦略が必要です。

  • 階層型ストレージ戦略:

    • データ移行の具体的な閾値とトリガーを定義する
    • シームレスなオフロードを実現するためのテーブルスペースのパーティショニングやオブジェクトストレージを実装する
    • オフロードされたデータに対して効率的に機能するクエリパターンを設計する

  • 重要な問い:

    • このデータタイプに適切なストレージ階層はどれか？
    • オフロードされたデータに対してどのようなアクセスパターンが必要になるか？
    • オフロードされたデータは必要時にどのようにインデックス化・検索されるか？

4. データ削除

デフォルトでは、すべてのデータに古いデータを削除するための保持ポリシーが必要です。

  • 削除フレームワーク:

    • 削除対象データを特定する自動化プロセスを実装する
    • コンプライアンスを証明するための削除アクションの監査証跡を作成する
    • 有料機能としての選択的アーカイブ機能を検討する

  • 重要な問い:

    • このデータタイプの最大有用保持期間はどの程度か？
    • 削除を義務付ける規制要件があるか（例: GDPR の忘れられる権利）？
    • プレミアム機能として提供すべき保持延長オプションは何か？
フィーチャー開発のためのデータ保持ガイドライン
概要 データ保持は GitLab におけるフィーチャー開発の重要な側面です。フィーチャーを構築・保守するにあたって、収集・保存するデータのライフサイクルを考慮する必要があります。このドキュメントでは、 …
最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License