【解説】データ指向アプリケーションデザイン 12章 データシステムの未来
•
0 likes•924 views
データ指向アプリケーションデザイン 12章 データシステムの未来について解説です。輪読会で12章担当だったため解説スライドを公開します。 また、データ指向アプリケーションデザイン解説についてはこちらのブログからご覧ください。 https://blog.mosuke.tech/entry/2021/01/24/designing-data-intensive-applications/
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 【解説】データ指向アプリケーションデザイン 12章 データシステムの未来
Similar to 【解説】データ指向アプリケーションデザイン 12章 データシステムの未来 (20)
More from Shinya Mori (@mosuke5)
More from Shinya Mori (@mosuke5) (20)
Recently uploaded
Recently uploaded (12)
【解説】データ指向アプリケーションデザイン 12章 データシステムの未来
- 2. 自己紹介 名前 もーすけ @mosuke5 いま KubernetesやDevOpsに関するプロフェッショ ナルサービス それまで Alibaba Cloudの日本リージョンの立ち上げ・ 運営 データストアサービスがたくさん。アリババメンバーからオブジェクトストレー ジやバッチ系コンピューティングなどの実装を教えてもらって調べたり。今に なって理解したことも多い。。 モバイルネットワークの監視システムの開発・ 運用 メインはRDB（大規模の場合は管理対象にあわせてシャーディング ?とかし てた）。キャッシュやジョブ管理で Redis, memcached。基地局からのデータ は非同期に受け取り。ある程度ならロストしても良かった。性能情報は FTP でとんできたり。基地局マスターは csvでばらまき、バッチ回収 Webアプリケーションエンジニア メインはRDB。 コロナで挑 戦したこと 家系ラーメンの内製化、 ハンドドリップ珈琲、筋トレしながらのミーティング
- 4. 12章 データシステムの将来 これまでは現在の姿についての説明してきた。 視点を将来に向け、あるべき姿について説明する。将来の話については、筆者の主観が入って いる点は注意が必要。 そもそもこの書籍の目標は、信頼性があり、スケーラブルで、メンテナンス性の高い アプリケー ションやシステムを作る方法を調べること。その１つ１つの要素を説明してきたので、 12章ではま とめて基盤としての未来を考える。 12.1. データのインテグレーション 12.2. データベースを解きほぐす 12.3. 正確性をもとめて 12.4. 正しいことを行う ←この節だけメンタリティの話
- 7. 導出データシステム 導出データシステム＝「導出システム内のデータは、他のシステムの既存データを 何らかの方法で変換あるいは処理した結果です。導出データは失ったとしても、オリ ジナルのソースから再作成できます。」（p424） 任意の処理 id name describe price image 1 Product a Product aは〇〇 780 https://xxx 2 Product b Product bは〇〇 1,800 https://xxx 3 Product c Product cは〇〇 980 https://xxx は〇〇 導出データシステム。 失ってもいつでもオリジナル データから再作成できる
- 8. RDB（単一ソフトウェア）ですべてをまかなえる？ 例えば、検索エンジンという文脈で言えば、 PostgreSQLには全文検索を提供するモジュール pg_bigm (ピージーバイグラム ) を備える。導出データシステムって本当に必要？ 実現したいことは、pg_bigm は機能として充分？単一ソフトウェア（ PostgreSQL）だけで、信頼性があり、 スケーラブルで、メンテナンス性の高いシステムは構築できる？ 任意の処理 id name describe price image 1 Product a Product aは〇〇 780 https://xxx 2 Product b Product bは〇〇 1,800 https://xxx 3 Product c Product cは〇〇 980 https://xxx は〇〇 全文検索の機能もあ る。ElasticSearchで データを管理する必要 などない JSON型も習得した レプリケーションも できる
- 9. 導出データと分散トランザクション 役割に合わせて導出データシステムをつくる意味はわかってきた。ではどうやって導出データを作っていけ ばいいか？まずは分散トランザクションで考えてみる。 例として、ECサイトを開発運用しているとする。 ECサイトの商品管理を担当するチームと検索エンジンを 管理するチームがある。商品管理チームがあたらしい商品を登録することを想像する。 ・商品登録と同時に、検索エンジンに反映される（即時的な一貫性）点はよいが、それは必要？ ・エラー時のロールバックは容易か？ ・検索エンジンが障害だったときの業務はどうなるか？ ・商品管理チームが業務スコープ外の検索エンジンのことを考えるべきか？ アプリケーション （商品登録サービス） 商品データベース 検索エンジン 商品登録担当 ①商品登録操作 ②商品登録 ③検索エンジンへの商品登録
- 10. 非同期での導出データシステム 分散トランザクションの限界を知ると、非同期での導出データを作成する方法の重要性がわかる。例として CDC(Change Data Capture, 変更データキャプチャ )。詳しくは「11.2.2 変更データキャプチャ (p497)」を参 照。 イベントの順序を保ったまま、非同期に、 変更を導出データシステムへ反映できる。 記録システ ムDB ... X = A X = B 検索エンジン データウェアハウス データ変更ログ ログの適応 導出データシステム 変更データキャプチャ（ 章）
- 11. 全順序の限界 小さなシステムであれば、全順序を保つイベントログを構築することができる。規模が大きくなり、複雑にな ると限界にぶつかる。 全順序を保つには、単一のリーダーノードがすべてのイベントが処理することで実現可能。たとえば、地理 的に分散したマルチマスターの RDBでは全順序は保証できなくなる。 記録システ ムDB ... X = A X = B 検索エンジン データウェアハウス 変更データキャプチャ（ 章） データ変更ログ ログの適応 導出データシステム 記録システ ムDB マルチマスター レプリケーション 全順序の崩壊 レプリケーションについて は 章で解説
- 13. バッチ処理はデータの「再処理」 バッチ処理は大量に蓄積された履歴データを「再処理」し、既存のデータから新たなビューを導 出できる（バッチ処理の詳細は10章）。既存データの再処理によって、導出データのメンテナンス 性があがる。再処理のため既存の導出データに影響を受けず実行可能。完全に異なるデータモ デルの導出データの作成も可能。ただし、量が膨大だと当然時間がかかる。リアルタイム性もな い。 例）1日1回最新データで分析用テーブルを作る。 商品データベース Amazon Redshift スキーマ v1 購入履歴データベース バッチ処理 データ分析 チーム BIツール クエリ発行、可視化 Amazon Redshift スキーマ v2 データ取得、結合、集 計などへて分析用 へ投入
- 14. ラムダアーキテクチャ 出典 http://www.intellilink.co.jp/article/column/bigdata-kk03.html 「サービスレイヤーとスピードレイヤーの双方に対して問合せをし、 その結果をマージしてユーザーに提供 するようなクエリ機構を構築する ことで、バッチ処理の細やかな集計結果も、スピードレイヤーの最新の集 計結果も、分析に反映させることができるものである。」 専用インターフェイスや Hiveとか 課題もたくさんある - バッチ処理とストリーム処理の両方で 同じロジックをメンテするのが大変。 - ストリームパイプラインとバッチパイプ ラインは別の出力を生成するので マージが必要。 - データの再処理は規模が大きくなる と負荷が大きい。 - インクリメンタルなバッチ処理にする と、はぐれイベントやバッチ間の境界 をまたぐウィンドウの処理といった時 間の問題
- 15. バッチ処理とストリーム処理の統合 最近の研究で、ラムダアーキテクチャの欠点もなくしながらも、その利点を享受できるようにも なってきた。バッチ演算とストリーム演算を同じシステム上で実装できるようになってきた。実現 するには、以下のような機能が必要。 - 履歴にあるイベントをリプレイし直近のイベントのストリームを処理するのと同じエンジンに 流す機能 - ストリームプロセッサのexactly-onceセマンティクス - 処理の時間ではなく、イベントの発生時刻によってウィンドウ処理を行うツール ※現状の製品ベースだとどこまで実装され ているのかわからなかったのでもししって いたら教えて下さい。
- 16. データベースを解きほぐす
- 18. 巨大なデータベースと 考えられる CREATE INDEXは導出データシステムと同じ？ CREATE INDEXは本質的には既存のデータセットを再処理し、既存のデータに対する新しい ビューとしてインデックスを導出する。組織全体にわたるデータフローは１つの巨大なデータベー スのようにみえてくる。 記録システ ムDB ... X = A X = B 検索エンジン （導出データシステム） 変更データキャプチャ データ変更ログ ログの適応 テーブル インデックス （導出データとみなせる） 導出データシステム 本質的に同じでは！？
- 19. 全てに関するメタデータベース すべてのユースケースに適する１つのデータベースは存在しないと いう前提に立つと、様々なストレージや処理のツールが１つのシス テムにまとめる道筋は２つある。 1. フェデレーテッドデータベース（読み取りの統合） 例としてPostgreSQLのforeign data wraper 2. 解体されたデータベース（書き込みの統合）★本書のターゲッ ト →書き込みを同期させるための方法に分散トランザクション があるが、前に見たようにあまり賢いアプローチではない。非 同期のイベントログを用いたアプローチを使っていきたい。
- 20. 解体されたデータベース (1) システムレベルの話で、耐障害性があがる。イベントログはメッセージをバッファリングできるため、他 のコンポーネントが一時的に障害が発生しても復旧後においつくことが可能。 (2) 人間レベルでは、業務の分離がしやすい。異なるチームで独立した作業がおこないやすい。下の例で 言えば記録システムを扱っているチームと検索エンジン、データウェアハウスを扱っているチームで独立性 がある。 記録システ ムDB ... X = A X = B 検索エンジン データウェアハウス 変更データキャプチャ データ変更ログ ログの適応 導出データシステム のイメージ： サイトの商品登録担当 と検索エンジンを作っている担当とで分 担など。（某 ショッピングの検索エンジ ンチーム友人の話より）
- 23. アプリケーションコードと状態の分離 あるデータセットが他のデータセットから導出される場合、なんらかの種類の変換関数を経由す る必要がある。セカンダリインデックスの生成のように標準的で型通りなればいいが、そうではな い場合、固有のコードを書く必要がある。固有コード部分をデータベースに実行させることも実装 されてきた。トリガーやストアドプロシージャ、ユーザー定義関数など。しかし、データベースに は、依存関係やパッケージ管理、バージョン管理、ローリングアップデート、進化性、モニタリン グ、メトリクス、ネットワークサービスの呼び出しとアプリケーション管理には不十分。 Mesos, YARN, Docker, Kubernetesなどでアプリケーションのオーケストレーションが容易に なった。永続データとロジックの独立性を高めることができるように。 テーブル ストアドプロシージャ テーブル こいつの管理、アップ デートなど。。。
- 25. 正確性をもとめて
- 27. データベースのエンドツーエンド論 1. 操作を厳密に一度だけ実行する （正確性を得るのに手間） メッセージングシステムのセマンティクスは、at-least-onceかat-most-onceが一般的。メッセージをロストするか、重複 して送られる可能性を考慮する。重複して送られても問題なくするためにはアプリケーション側で冪等な処理にする必 要がある。冪等な処理をするにはメタデータの管理など必要。 2. 重複の抑制（正確性なし） RDBのトランザクションでCOMMITしたが、そのレスポンスを受け取れなかった場合、アプリ側は再送して二重処理と なる。ネットワークを介す操作を冪等にするのに、トランザクション処理だけでは不十分。 3. 操作識別子（エンドツーエンド）★ リクエストのエンドツーエンドのフローを考慮する必要あり。クライアント側からデータベースまでの一貫したリクエストID をもつ必要がある。 アプリケーション Database ユーザ からユーザ へ送金 送金 入金 引き落とし はユニークキー エンドツーエンドで考える
- 28. 制約の強制 パーティショニングされたログを使うことで、アトミックなコミットなしに実現できる。前 のことを非同期かつスケーラブルな環境で行うことが可能。 メッセージング （リクエストIDの パーティション） ユーザ からユーザ へ送金 送金 メッセージング （ユーザAを含む パーティション） メッセージング （ユーザBを含む パーティション） Database ユーザごとの順序を保ったまま、 （最低一度は処理）でロスト なく処理を実行。 を持っている ので重複処理対策。 ログベースのメッセージブローカーの利点は、コンシューマが単一 パーティション内のメッセージをシーケンシャルに処理のため、順序 性を守りながら、効率良く処理可能（11章で解説） 因果律において一貫している
- 30. 正しいことを行う
- 32. 予測分析 予測分析はビッグデータ時代のブームのひとつ。もちろんいい面もおおいが、アルゴリズムによってはじき 出されえる人々がいる可能性があることを忘れてはいけない。 1. バイアスと差別 アルゴリズムは、バイアスを学習することもある。 それにどう対応するか決めているか？ 2. 説明と説明責任 アルゴリズムがミスを犯した場合だれが責任をとるか？アルゴリズムがだした結果に対して説明が できるか？アルゴリズムを説明可能で透明性のあるものにする方法や、既存のバイアスの強化を避 ける方法、データに基づく意思決定が間違いを犯してしまった場合にそれを修復する方法は考えて いるか？ 3. フィードバックループ アルゴリズムによる負のスパイラルが起きているか判断できる状態か？システム思考（事象ではなく パターンに着目する方法）で、システム全体について考えるようにする。
- 34. データ指向アプリケーションデザイン データシステムを理解するための要素技術の解説が満 載。基礎を抑えた、システムアーキテクチャ、技術選定が できるようになろう。 ● リレーショナルモデルとドキュメントモデル ● データベースを駆動するデータ構造（ハッシュイン デックスやSSTableとLSMツリー、Bツリー、列指向 ストレージ） ● データエンコードのフォーマット（ JSON, XML, Protocol Buffers, Avroなど） ● レプリケーション（シングルリーダー、マルチリー ダー、リーダーレス方式） ● パーティショニング ● トランザクション ● 一貫性と合意 ● バッチ処理とストリーム処理 https://amzn.to/3sNOOcp