天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

Data Engineering Study #18「データ指向アプリケーションデザイン」に参加してきた

forkwell.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。(時間の都合で斎藤さんの基調講演だけの参加でした)

会の概要

以下、イベントページから引用です。

本イベントは、Infra Study Meetup を運営する Forkwell と、分析基盤向けデータ統合SaaS「trocco」の開発・運営を行う primeNumber による共催イベントです。データ分析に精通した講師をお招きし、データ分析基盤の「これまで」と「これから」を学ぶことを趣旨として開催いたします。

会の様子

30分でわかるデータ指向アプリケーションデザイン

データ指向アプリケーションデザインとは?

原著はDesigning Data-Intensive Applicationsで、「データ指向」(データの量や複雑さ...を中心に考える)という言葉はこの本のために生み出された訳語であるというお話からまずスタートしました。

本書は5年前に発表された書籍ですが、データ指向アプリケーションデザインの基礎はまだまだ色褪せず使えるのも本書の特徴で、分散データシステム本の決定版といっても差し支えないのではないか?というお話がありました。

データの量・複雑さ・変化の速度に対応できるシステム設計とは?

データ量が少ない場合はデータとして完結しているような自己記述型データフォーマットが使える一方で、データ量が多い場合はデータ基盤に省メモリ/圧縮しやすさ/ストレージへの格納のしやすさが重視されるよね、という話がありました。

データ量が多い場合は、列指向フォーマット/行指向フォーマット/テーブルフォーマットの3つが代表的なフォーマットになってくるという話もありました。

データの高速化

読み込み特化の不変データ(蓄積されていくログデータなど、変化しないデータ)を高速化したい場合は、パーティショニングなどといったようにデータの分散化を行っていくのが基本になってくるというお話がありました。

一方で、データが頻繁に更新される書き込み特化型では、高速化の際には更新をいかに早くするか?が問題になるため、B-TreeやHash index、SSTable、LSM Treeなどが基本になってくるということです。

分散データの考え方

分散データになると考えるべき問題の複雑さは数段階上がるよね、という話がありました。具体的には、

  • 分散システム(分散ステートマシン)の実装
  • 複数箇所で頻繁にデータが更新される場合はどの状態が正解かを決めるためのルール作り(Paxos, 2PC, coordination avoidance...)
  • エラーハンドリング、リトライ、冪等性...を障害対応として考えないといけない
24時間365日動くシステムの設計

稼働率、クライアント側のリトライ処理、冪等性の担保といった観点が、24時間365日動くシステムの設計では重要になるというお話がありました。

また、常にデプロイがし続けられるようにCompute-Storageの分離するのが近年の標準になっているそうです。

トランザクション処理

まず、トランザクション処理といえばよく聞くキーワードということで、ACIDが紹介されました。ただ、何がどのように保護されるかは実装をみないとわからないため、ACIDという言葉が指し示す意味は専門家になるにつれてどんどんわからなくなるということです。

トランザクション処理では分散化の概念が最も重要で、まずは直列化可能性の観点から考え始めるものの、オーバーヘッドの観点から弱い分離(Read-commited, snapshot Isolation, MVCC)やSSIが採用されることが多いということでした。

また、ファントムやWrite skewといったトランザクション異常時の考慮も重要だというお話が出ていました。

分散トランザクション

続いて、複数ノード/複数システム間でシステムを実装する分散トランザクションの話がありました。

分散トランザクションでは、一貫性や合意、耐障害性といった観点が重要になってくるということで、具体的にはリーダー選出、サービスディスカバリ、メンバーシップ管理*1といった技術が挙げられるということでした。

なお、Amazon Auroraは見事に分散トランザクションを実現しているということで、MySQLのデータベース更新操作をログの書き込みだけに簡略化している点など、多数の注目すべき点があるということです。

テーブルの意味の変化

データの複雑さが上がった要因の話として、これまではRDBMSにある最新データの意味しか持っていなかったものの、時間とともに変化するデータや派生データの誕生、列指向クエリエンジンの発展に伴う導出データの大量化などが挙げられていきました。

また、こうした大量のデータを処理するために分散バッチ処理やストリーム処理の発展が進んだということです。

データモデルの多様性とその歴史

1970年頃からデータモデルの議論はあったということで、歴史から学ぶことが多くあるという話がありました。

大まかには、

  • ネットワークモデルが主流の時代
  • 品質を担保しているRDBMSが圧倒し始める時代
  • NoSQL(当初はインプーダンスミスマッチなどを理由に、No SQLを突きつけたスタートだった)
  • RDBMSも必要だよね、という流れになり次第にNoSQLはNot only SQLとして解釈されるようになる(GraphQLの誕生は好例)
より深い世界に飛び込むために

本書はあくまでも基本本なので、より深い世界に飛び込むためには、以下のような情報源をあたるといいという話がありました。

  • 本にある引用論文
  • Industrial Paperを読む
  • Audibleで本書の英語版を聞き流す

会全体を通した感想

基調講演だけの参加でしたが、非常にボリューミーな内容をざっとまとめてくれて、業務で必要なユースケースに応じて参照したい章にインデックスづけができた素晴らしい発表でした。

ただ本の内容をまとめただけではなく、深く学ぶための手引や本の内容を実現している技術の好例を指し示してくれた点も、満足感が高かったです。

*1:本書の第9章にある