データ集約型アプリケーション設計フレームワーク

信頼性高く、スケーラブルで、保守性に優れたデータシステムを構築するための原理的なアプローチです。データベースの選択、スキーマ設計、分散システムアーキテクチャ、一貫性とフォルトトレランスについて推論する際に、これらの原則を適用します。

中心原則

データはコードより長生きする。 アプリケーションは書き直され、言語は変わり、フレームワークは去ってきます。しかし、データとその構造は数十年間保持されます。すべてのアーキテクチャ上の決定は、データレイヤーの長期的な正当性、耐久性、発展性を最優先にしなければなりません。

基礎: ほとんどのアプリケーションは計算集約型ではなく、データ集約型です。難しい問題は、データの量、その複雑性、変化の速度です。一貫性、可用性、パーティション耐性、遅延、スループット間のトレードオフを理解することが、堅牢なシステムと脆いシステムを分けます。

スコアリング

目標: 10/10。 データアーキテクチャをレビューまたは設計するときは、以下の原則への準拠に基づいて、0～10でスコア付けしてください。10/10は、データモデル、ストレージエンジン、レプリケーション、パーティショニング、トランザクション、処理パイプラインについて意図的なトレードオフの選択を意味します。低いスコアは、偶然の複雑性または無視されたフェイルモードを示します。常に現在のスコアと10/10に到達するために必要な特定の改善を提供してください。

DDIAフレームワーク

データ集約型システムについて推論するための7つのドメイン:

1. データモデルとクエリ言語

中心概念: データモデルは、問題をどう考えるかを形作ります。リレーショナル、ドキュメント、グラフモデルは、それぞれ異なる制約を課し、異なるクエリパターンを可能にします。

なぜこれが機能するのか: 間違ったデータモデルを選ぶと、表現のミスマッチを補うようにアプリケーションコードが強制され、時間の経過とともに複合する偶然の複雑性が追加されます。

主要な洞察:

• リレーショナルモデルは、多対多の関係とアドホッククエリに優れています
• ドキュメントモデルは、一対多の関係とデータの局所性に優れています
• グラフモデルは、高度に相互接続されたデータと再帰的なトラバーサルに優れています
• スキーマオンライト(リレーショナル)は早期にエラーを捉えます。スキーマオンリード(ドキュメント)は柔軟性を提供します
• ポリグロット永続化 -- 異なるアクセスパターンに対して異なるストアを使用する -- は、しばしば正しい答えです
• オブジェクトとリレーション間の意思疎通のミスマッチは実際のコストです。ドキュメントモデルは、自己完結した集約に対してそれを削減します

コード応用:

コンテキスト	パターン	例
ネストされたデータを持つユーザープロファイル	自己完結した集約用のドキュメントモデル	プロファイル、住所、設定を1つのMongoDBドキュメントに保存
ソーシャルネットワーク接続	関係トラバーサル用のグラフモデル	Neo4j Cypherクエリ: MATCH (a)-[:FOLLOWS*2]->(b) 友人の友人向け
結合を伴う財務台帳	参照整合性用のリレーショナルモデル	アカウント、トランザクション、エントリ間の外部キーを持つPostgreSQL
混合アクセスパターン	ポリグロット永続化	トランザクション用PostgreSQL + フルテキスト検索用Elasticsearch + キャッシング用Redis

参照: references/data-models.md

2. ストレージエンジン

中心概念: ストレージエンジンは、読み取り性能と書き込み性能間の基本的なトレードオフを行います。ログ構造化エンジン(LSMツリー)は書き込みを最適化します。ページ指向エンジン(Bツリー)は読み書きのバランスを取ります。

なぜこれが機能するのか: データベースのストレージエンジンの内部を理解すると、パフォーマンス特性を予測し、適切なインデックスを選択し、病的なワークロードを回避できます。

主要な洞察:

• LSMツリー: アペンドのみの書き込み、定期的な圧縮、優れた書き込みスループット、高い読み増幅
• Bツリー: インプレース更新、予測可能な読み取りレーテンシ、ページ分割からの書き込み増幅
• 書き込み増幅は、1つの論理的な書き込みが複数の物理的な書き込みを引き起こすことを意味します -- 書き込みサイクルが限られたSSD用に重要
• カラム指向ストレージは、圧縮とベクトル化処理を通じて、分析クエリのパフォーマンスを劇的に改善します
• メモリ内データベースが高速なのは、ディスクを回避するからではなく、エンコーディングオーバーヘッドを回避するからです

コード応用:

コンテキスト	パターン	例
高い書き込みスループット	LSMツリーエンジン	100K+書き込み/秒でのタイムシリーズ取り込み用CassandraまたはRocksDB
混合読み書きOLTP	Bツリーエンジン	トランザクションワークロードとポイント検索用PostgreSQL Bツリーインデックス
大規模データセットの分析クエリ	カラム指向ストレージ	数十億行をスキャンする少数のカラム用ClickHouseまたはParquetファイル
低遅延キャッシング	メモリ内ストア	サブミリ秒検索用Redis、シンプルなキー値キャッシング用Memcached

参照: references/storage-engines.md

3. レプリケーション

中心概念: レプリケーションは、複数のマシンにデータのコピーを保持して、フォルトトレランス、スケーラビリティ、遅延削減を実現します。中心的な課題は、レプリケートされたデータへの変更を一貫して処理することです。

なぜこれが機能するのか: すべてのレプリケーション戦略は、一貫性、可用性、遅延間のトレードオフを行います。このトレードオフを明示的に行うことで、負荷またはフェイル下でのみ表面化する微妙なデータ異常を防止します。

主要な洞察:

• シングルリーダーレプリケーション: シンプル、強い一貫性が可能ですが、リーダーはボトルネックであり単一障害点です
• マルチリーダーレプリケーション: データセンター全体での書き込み可用性が向上しますが、競合解決が複雑です
• リーダーレスレプリケーション: 最高の可用性、クォーラム読み書きを使用しますが、慎重な競合処理が必要です
• レプリケーション遅延は、読み取り書き込み違反、単調読み取り違反、因果性違反を引き起こします
• 同期レプリケーションは耐久性を保証しますが遅延を増加させます。非同期レプリケーションはリーダー障害でのデータ損失のリスクがあります
• CRDTとlast-writer-winsは、非常に異なる正当性保証を持つ競合解決戦略です

コード応用:

コンテキスト	パターン	例
読み取り集約的なウェブアプリ	シングルリーダーと読み取りレプリカ	PostgreSQLプライマリ + pgBouncer背後の読み取りレプリカで読み取りスケーリング
マルチリージョン書き込み	マルチリーダーレプリケーション	地理的に分散した書き込みと制限された鮮度用CockroachDBまたはSpanner
ショッピングカートの可用性	マージを備えたリーダーレス	last-writer-winsまたはショッピングカート競合用アプリケーションレベルのマージを持つDynamoDB
協調編集	競合なしマージ用CRDT	リアルタイム協調ドキュメント編集用YjsまたはAutomerge

参照: references/replication.md

4. パーティショニング

中心概念: パーティショニング(シャーディング)は、各ノードが総データのサブセットを処理するように、複数のノードにデータを分散させ、単一マシンを超えた水平スケーリングを可能にします。

なぜこれが機能するのか: パーティショニングなしでは、単一のノードがストレージ容量とスループットのボトルネックになります。効果的なパーティショニングは、負荷を均等に分散させ、ホットスポットを回避します。

主要な洞察:

• キー範囲パーティショニングは効率的な範囲スキャンをサポートしますが、順序キーのホットスポットのリスクがあります
• ハッシュパーティショニングは負荷を均等に分散させますが、ソート順序を破棄し、範囲クエリを高額にします
• セカンダリインデックスは、ローカルに(各パーティションが独自のインデックスを持つ)またはグローバルに(インデックスが別にパーティション化される)パーティション化できます
• ローカルセカンダリインデックスにはスキャッターギャザークエリが必要です。グローバルセカンダリインデックスにはクロスパーティション更新が必要です
• ハッシュパーティショニングであっても、1つのキーが非常に人気がある場合(セレブリティの問題)、ホットスポットが発生する可能性があります
• リバランシング戦略: パーティション数固定、動的分割、またはノード数に比例

コード応用:

コンテキスト	パターン	例
タイムシリーズデータ	時刻とソースによるキー範囲パーティショニング	(sensor_id, date)でパーティション化して、現在の日のホットスポットを回避
スケール時のユーザーデータ	ユーザーIDでのハッシュパーティショニング	均等な分散用user_idのCassandra一貫性ハッシュ
グローバル検索インデックス	グローバルセカンダリインデックス	プライマリデータストアから独立してシャーディングされたElasticsearchインデックス
セレブリティ/ホットキーの問題	ランダムサフィックス付きキー分割	ホットパーティションキーにランダムな数字を追加、10個のサブパーティション全体で読み取りをファンアウト

参照: references/partitioning.md

5. トランザクションと一貫性

中心概念: トランザクションは安全保証(ACID)を提供することで、フェイルと並行処理がトランザクションのスコープ内に存在しないと見なすことを許可することで、アプリケーションコードを簡素化します。

なぜこれが機能するのか: トランザクションなしでは、すべてのアプリケーションコードが部分的なフェイル、競合状態、並行変更を処理する必要があります。トランザクションは、この複雑性をデータベースに移動させ、一度正しく処理できます。

主要な洞察:

• 分離レベルはスペクトラムです: read uncommitted、read committed、snapshot isolation(repeatable read)、serializable
• ほとんどのデータベースは、read committedまたはsnapshot isolationをデフォルトにします -- serializableではなく -- アプリケーション開発者はこれが許可する異常を理解する必要があります
• 書き込みスキューは、2つのトランザクションが同じデータを読み取り、それに基づいて決定を行い、異なるレコードを書き込むときに発生します -- 行レベルロックはこれを防止しません
• Serializable snapshot isolation(SSI)は、楽観的並行処理で完全なシリアライザビリティを提供します -- ブロッキングなし、ただし競合で中止
• 2フェーズロッキングはシリアライザビリティを提供しますが、高並行性下で競合とデッドロックを引き起こします
• 分散トランザクション(2フェーズコミット)は高額で脆いです。単一パーティション操作の周囲に設計することで、可能な限り回避してください

コード応用:

コンテキスト	パターン	例
アカウント残高転送	Serializableトランザクション	BEGIN; UPDATE accounts SET balance = balance - 100 WHERE id = 1; UPDATE accounts SET balance = balance + 100 WHERE id = 2; COMMIT;
在庫予約	SELECT FOR UPDATEで書き込みスキューを防止	減少させる前にSELECT stock FROM items WHERE id = X FOR UPDATE
読み取り集約的なダッシュボード	一貫した読み取りのためのSnapshot isolation	PostgreSQL MVCCはライターをブロックせずにポイントイン時間スナップショットを提供
クロスサービス操作	分散トランザクションの代わりにSagaパターン	補償トランザクション: カード請求、在庫予約、失敗時にカード払い戻し

参照: references/transactions.md

6. バッチおよびストリーム処理

中心概念: バッチ処理は、制限されたデータセットを一括で変換します。ストリーム処理は、無制限のイベントストリームを継続的に変換します。どちらも導出データ計算の形式です。

なぜこれが機能するのか: 信頼できるシステム(真実の源)を導出データ(キャッシュ、インデックス、具体化されたビュー)から分離することで、それぞれが独立して最適化でき、要件が変わるときに源から再構築できます。

主要な洞察:

• MapReduceは概念的にはシンプルですが、運用上は不便です。データフローエンジン(Spark、Flink)は任意のDAGで一般化します
• イベントソーシングは、すべての状態変更を不変イベントとして保存し、完全な監査証跡と時間的クエリを可能にします
• 変更データキャプチャ(CDC)は、データベース書き込みをストリームに変え、ダウンストリームシステムが消費できます
• ストリームテーブル双対性: ストリームはテーブルのチェンジログです。テーブルはストリームの具体化された状態です
• ストリーム処理での一度きりセマンティクスは、べき等操作または取引結果を必要とします
• 時間ウィンドウイング(タンブリング、ホッピング、セッション)は、無制限ストリーム集約に不可欠です

コード応用:

コンテキスト	パターン	例
日次分析パイプライン	Sparkでのバッチ処理	S3から日のイベントを読み取り、メトリクスを集約し、データウェアハウスに書き込み
リアルタイム不正検出	Flinkでのストリーム処理	Kafkaから支払いイベントを消費、5秒のタンブリングウィンドウ内で規則を適用
検索インデックスの同期	変更データキャプチャ	Debeziumがpostgresql WALの変更をキャプチャ、Kafkaに発行、Elasticsearchコンシューマーが インデックスを更新
監査証跡/イベント再生	イベントソーシング	OrderPlaced、OrderShipped、OrderRefundedイベントを保存、再生による現在の状態を再構築

参照: references/batch-stream.md

7. 信頼性とフォルトトレランス

中心概念: フォルトは必ずしも起こりますが、フェイルは必ずしも起こりません。信頼できるシステムは、個別のコンポーネントが失敗しても、正しく操作を続けます。フォルトに対して設計しましょう。

なぜこれが機能するのか: ハードウェアは失敗し、ソフトウェアにはバグがあり、人間は間違いを犯します。完全な操作を仮定するシステムは脆いです。フォルトを予想して上手に処理するシステムは回復力があります。

主要な洞察:

• フォルトは、1つのコンポーネントが仕様から逸脱することです。フェイルは、システム全体が停止することです。フォルトトレランスはフォルトがフェイルになるのを防止します
• ハードウェアフォルトはランダムで独立しています。ソフトウェアフォルトは相互に関連し、体系的です(より危険)
• 人間エラーは停止の主な原因です。システムを設計して、間違いの機会を最小化し、復旧能力を最大化します
• タイムアウトは、分散システムの基本的なフォルト検出器です。ただし、正しいタイムアウトを選択するのは難しいです(短いと誤検知、長いと復旧を遅延)
• 安全性プロパティ(悪いことは起きない)は常に保持する必要があります。生存性プロパティ(良いことはついに起きる)は一時的に違反される可能性があります
• ビザンチン障害耐性は、ブロックチェーン外ではめったに必要ありません -- ほとんどのシステムは、非ビザンチン(クラッシュストップまたはクラッシュリカバリ)モデルを仮定します

コード応用:

コンテキスト	パターン	例
サービス通信	タイムアウト + 指数バックオフを備えた再試行	retry(max=3, backoff=exponential(base=1s, max=30s)) ジッターを伴う
リーダー選出	コンセンサスアルゴリズム(Raft/Paxos)	分散ロックとリーダー選出用etcdまたはZooKeeper
データパイプラインの信頼性	べき等操作 + チェックポイント	Kafkaコンシューマーは成功した処理後にのみオフセットをコミット
グレースフルデグラデーション	サーキットブレーカーパターン	Hystrix/Resilience4j: 10秒ウィンドウで50%の失敗後に開くサーキット

参照: references/fault-tolerance.md

一般的な間違い

間違い	なぜ失敗するのか	修正
人気度に基づいてデータベースを選択する	異なるエンジンは根本的に異なるトレードオフを持ちます	ストレージエンジン特性を実際の読み書きパターンと照合
レプリケーション遅延を無視する	ユーザーは古いデータ、ファントム読み取り、または失われた更新を見ます	読み取り書き込み一貫性を実装、単調読み取り保証を使用
どこでも分散トランザクションを使用する	2フェーズコミットは遅く脆いです。コーディネーターは単一障害点です	単一パーティション操作用に設計、クロスサービス調整用sagaを使用
すべてをハッシュパーティション化する	範囲クエリ能力を破棄します。一部のワークロードはソート済みアクセスが必要です	タイムシリーズにはキー範囲パーティショニングを使用。局所性のための複合キー
Serializableな分離を想定する	ほとんどのデータベースは弱い分離をデフォルトにします。書き込みスキューバグが本番に表示されます	データベースの実際のデフォルト分離レベルをチェック。必要に応じて明示的ロックを使用
バッチとストリームを混同する	ストリーミングデータのバッチツールは遅延を追加します。制限されたデータのストリームツールは複雑さを浪費します	処理モデルをデータの境界性と遅延要件と照合
すべてのフォルトを復旧可能として扱う	いくつかのフェイル(データ破損、ビザンチン)は根本的に異なる処理を必要とします	フォルトを分類し、各クラスに対して特定の復旧戦略を設計

クイック診断

質問	「いいえ」の場合	アクション
このデータベースを代替案より選択した理由を説明できますか?	決定は要件ではなく、なじみに基づいていました	データモデル適合性、読み書き比率、一貫性ニーズ、スケーリングパスを評価
データベースのデフォルト分離レベルを知っていますか?	見つけていない並行処理バグがあるかもしれません	ドキュメントをチェック。書き込みスキューとファントム読み取りシナリオをテスト
レプリケーション戦略は明示的に選択されていますか(デフォルトではなく)?	一貫性と耐久性について暗黙的な仮定があります	トレードオフを文書化: 同期対非同期、フェイルオーバー動作、遅延許容度
ホットパーティションキーをシステムが処理できますか?	単一の人気のあるエンティティがクラスターを停止させる可能性があります	キー分割戦略またはホットキー用アプリケーションレベルの負荷削減を追加
システム的記録を導出データから分離していますか?	スキーマの変更または新機能には、すべてをマイグレートする必要があります	CDCまたはイベントソーシングを導入して、源から導出ストアを切り離す
タイムアウトと再試行がチューニングされ、デフォルトではありませんか?	カスケード失敗または不要な遅延が発生します	p99遅延を測定、タイムアウトをp99より上だがカスケード閾値より下に設定
本番状態でフェイルオーバーをテストしましたか?	復旧計画は理論的で、検証されていません	カオスエンジニアリング実験を実行: リーダー削除、ネットワークパーティション、ディスク充填

リファレンスファイル

• data-models.md: リレーショナル対ドキュメント対グラフモデル、スキーマオンリード対スキーマオンライト、クエリ言語、ポリグロット永続化
• storage-engines.md: LSMツリー対Bツリー、書き込み増幅、圧縮、カラム指向ストレージ、メモリ内データベース
• replication.md: シングルリーダー、マルチリーダー、リーダーレスレプリケーション、レプリケーション遅延、競合解決、CRDT
• partitioning.md: キー範囲対ハッシュパーティショニング、セカンダリインデックス、リバランシング、リクエストルーティング、ホットスポット
• transactions.md: ACID、分離レベル、書き込みスキュー、2フェーズロッキング、SSI、分散トランザクション
• batch-stream.md: MapReduce、データフロー エンジン、イベントソーシング、CDC、ストリームテーブル双対性、一度きりセマンティクス
• fault-tolerance.md: フォルト対フェイル、信頼性メトリクス、タイムアウト、コンセンサス、安全性と生存性保証

さらに読む

このスキルは、Martin Kleppmannのデータシステムの原則と実用性に関する包括的なガイドに基づいています。完全な扱いと詳細な図および研究参考文献については、以下を参照:

• "Designing Data-Intensive Applications" by Martin Kleppmann

著者について

Martin Kleppmannは、分散システムの研究者であり、LinkedInおよびRapportiveの元ソフトウェアエンジニアです。彼はケンブリッジ大学の上級研究員であり、CRDT、ビザンチン障害耐性、ローカルファーストソフトウェアに広く取り組んでいます。Designing Data-Intensive Applications(2017)は、データシステムを構築するエンジニアのための決定的なリファレンスとなり、複雑な分散システムの概念を明確な説明と実例を通じてアクセスしやすくすることで賞賛されています。Kleppmannの研究は、データ一貫性、分散協力、分散システムの正当性確保に焦点を当てています。彼は、学術研究と業界実務の間のギャップを埋める会議トークと教育ライティングでも知られています。