第12章 データシステムの将来
前の章
前の章である第11章 ストリーム処理はこちらです。
データインテグレーション
この本の目標は、信頼性、拡張性、保守性の高いアプリケーションとシステムを作成することでした。（1章からのテーマ）
唯一の正しい解決策はありませんが、状況に応じて適切なさまざまなアプローチが存在します。ソフトウェア実装では通常、特定のアプローチを 1 つ選択する必要があります。
したがって、最適なソフトウェア ツールの選択も状況によって異なります。すべてのソフトウェアは、いわゆる「汎用」データベースであっても、特定の使用パターンに合わせて設計されています。
ツールの組み合わせ
データの異なる表現の数が増加するにつれて、統合の問題は難しくなります。データ統合の必要性は、多くの場合、ズームアウトして組織全体にわたるデータフローを検討して初めて分かります。
ここでは、OLTP データベースと全文検索インデックスを統合することを例として挙げています。
一部のデータベース (PostgreSQL など) には全文インデックス作成機能が含まれており、単純なアプリケーションには十分ですが、より高度な検索機能には専門の情報検索ツールが必要です。
逆に、検索インデックスは一般に耐久性のある記録システムとしてはあまり適していません。
データフローについての考慮
アプリケーションが検索インデックスとデータベースの両方に直接書き込むことを許可すると、2 つのクライアントが競合する書き込みを同時に送信し、2 つのストレージ システムがそれらを異なる順序で処理するという問題が発生します。
すべての書き込みの順序を決定する単一のシステムを介してすべてのユーザー入力を集中させることができれば、書き込みを同じ順序で処理することで、データの他の表現を導出することが非常に簡単になります。
CDC（変更データキャプチャ）とイベントソーシングログのどちらを使用するかは、原則よりも重要になります。
導出データと分散トランザクション
異なるデータシステム間の一貫性を保つための古典的なアプローチの1つには、分散トランザクションがあります。
分散トランザクションは相互排他のためのロックを使用して書き込みの順序を決定しますが、CDC とイベントソーシングは順序付けにログを使用します。分散トランザクションはアトミックコミットを使用して、変更が 1 回だけ有効になることを保証しますが、ログベースのシステムは多くの場合、決定的な再試行と冪等性に基づいています。
全順序の限界
単一のリーダーノードはすべてのイベントを処理する。しかし、複数のノードから書き込むと全順序は保証できなくなります。
アプリケーションがマイクロサービスである場合、2つのイベントが異なるサービスから発生するケースがあります。
ユーザからの入力に基づいて更新されるクライアント側の状態を管理し、オフラインでも作業を継続できるものがあります。クライアントとサーバーは異なる順序でイベントを見る可能性があります。
バッチ処理とストリーム処理
データ統合の目標は、データが適切な形式で適切な場所に確実に配置されるようにすることだと思います。これを行うには、入力の使用、変換、結合、フィルタリング、集約、モデルのトレーニング、評価、そして最終的には適切な出力への書き込みが必要になります。
バッチプロセッサとストリームプロセッサは、この目標を達成するためのツールです。
ラムダアーキテクチャ
ラムダ アーキテクチャの中心的な考え方は、イベント ソーシングと同様に、常に増加するデータセットに不変のイベントを追加することによって受信データを記録する必要があるということです。これらのイベントから、読み取りに最適化されたビューが導出されます。
ラムダ アーキテクチャは、Hadoop MapReduce などのバッチ処理システムと、Storm などの別個のストリーム処理システムという 2 つの異なるシステムを並行して実行することを提案しています。
この設計の背後にある理由は、バッチ処理が単純であるためバグが発生しにくいのに対し、ストリームプロセッサは信頼性が低く、フォールトトレラントにするのが難しいと考えられているためです。さらに、ストリーム プロセスは高速な近似アルゴリズムを使用できますが、バッチ プロセスは低速の正確なアルゴリズムを使用します。
データベースを解きほぐす
高い抽象度では、データベース、Hadoop、オペレーティングシステムはすべて同じ機能を実行します。つまり、データを保存し、そのデータの処理とクエリを実行できるようになります。
データベースはデータを何らかのデータ モデルのレコード (テーブルの行、ドキュメント、グラフの頂点など) に保存し、オペレーティングシステムのファイルシステムはデータをファイルに保存します。
インデックスの生成
データベースは一貫性のあるテーブルのスナップショットに対してスキャンを行い、インデックスの対象となるフィールドのすべての値を取り出し、そうとしてインデックスを書き出します。その後、一貫性のあるスナップショットがとられた後のゴミのバックログを処理しなければなりません。
このプロセスは、新たにフォロワーのレプリカをセットアップすることに非常に似ており、ストリーミングシステムで変更データキャプチャを立ち上げることにも似ています。
データフローを中心としたアプリケーションの設計
データ変更によりトリガーが起動されたとき、またはインデックス付けされているテーブルの変更を反映するためにセカンダリインデックスが更新されたときに、データベース内で問題が発生します。
この目的のために、ストリーム処理システムとメッセージングシステムを使用できます。
状態変化とアプリケーションコード間の相互作用
データフローの観点からアプリケーションを考えることは、アプリケーションコードと状態管理の間の関係を再交渉することを意味します。アプリケーション コードは、ある場所での状態変化に応答して、別の場所で状態変化をトリガーします。
補足
OutboxパターンとCDCを利用したCQRS
OutboxパターンとCDCを利用したCQRS（コマンド/クエリ責務分離）の実装がまとめれた記事です。 システムを疎結合に保ち、データの不整合を防ぐというパターンで順序保証がされない場合の対処も記載されています。
まとめ
以上、データシステムの将来について解説しました。
この章ではこれまでの技術を踏まえて、私達がどのような選択を取る必要があるのかについて書かれています。
この記事の冒頭でも書いている通り、たった一つの解はありません。それぞれの状況からメリットとデメリットを並べて選択する必要があります。
この本は2016年に発売されているため、現状とは少し異なる部分もあるかとは思いますが、大枠は変わらないと思っています。個人的には、データインテグレーションの部分だけでも読んでいただけると非常に勉強になるかと思います。
データシステムの将来について特に重要な点を解説しました。ただし、非常に量が多いため解説していない部分が多々あります。詳細は本書を手にとってみて下さい。
いいなと思ったら応援しよう！
