Tech Fielders アーキテクトナイト ～データアーキテクチャについて語ろう～に参加してきました 2015/05/12(火)

2015/05/12(火)に開催された『Tech Fielders アーキテクトナイト - データアーキテクチャについて語ろう』に参加してきました。

■ イベント概要

アーキテクト ナイト第二回目は、少し具体的に「データ アーキテクチャ」です。
データベースの話題に限定しません。今必要な、あるいは今考えるべきデータのアーキテクチャについてであれば、どんな角度からの話題でも結構です。
問題提起や、事例紹介、アイデアの共有などなど、2 時間半語りましょう。30 分のプレゼンテーション登壇者、15 分のライトニングトーク登壇者ともに募集中です。

データ・アーキテクチャ「データモデル百景」

• データアーキテクチャとは

  • プロセス、システム、テクノロジー、そしてスタッフの実践によって、データの保存、アクセス、移行といった操作を最適化するための設計手法を指す用語
  • データ・アーキテクチャの設計では、設計の初期段階からデータのライフサイクルを念頭に置き、それをデータのアーカイビングや廃棄に対するアプローチの設計に反映させる必要がある
  • 引用元： アクセンチュアのサイト内「データ・アーキテクチャ」
    • http://www.accenture.com/jp-ja/technology/systems-integration/information-management/data-management-architecture/Pages/data-architecture.aspx

• 情報ライフサイクル管理 5フェーズ + 1例外 / 実装上の要点

  • 作成と受容
    • 入力可能なデータ形式、整合性範囲と品質担保 → UI・UX
  • 配布
    • データ意味づけとその共有方法 → APIフォーマット
  • 使用
    • 統計情報と学術的観点での模索 → ビッグデータ・機械学習
  • 保守
    • 現実的速度で応答するデータ構造 → アルゴリズム・設計
  • 廃棄
    • 法令対応と現実的な手段 → クラウド対応 vs. 物理基盤対応
  • 例外
    • 同上

• [失敗内容] UI・UX：株価情報におけるトライと失敗 #0

  • API実装の際、RESTful指向でのAPI設計（定石
    • 情報操作対象に注目する操作ベースの実装（OOP的Entity的）
      • GET / Symbols, PUT / Orders
        • API Endpoint に対して、Verbで操作を決める
      • 1リクエスト内でのライフサイクル整合性担保は近寄る傾向がある
        • 注文に管理する情報の鮮度と有効期限は、レスポンス全体で収束に向かう
  • その結果、、、
    • サーバークライアント間のやりとりが増えて "遅い"
      • 筐体内操作とネット経由では "遅延" が100倍以上違う
      • クライアントサイドで並行アクセスに発想届く人が少ない

• API化すると遅くなるのは自明なのに、プロジェクト初期になかなか気づかれにくいのが課題

• [改善後] UI・UX：株価情報におけるトライと失敗 #1

  • 結果的に機能単位指向へ回帰気味（≠画面単位指向）
    • 注文を取得するなら、その関連情報もまとめて取得
  • データ構造を理解していないと、、、、

• APIフォーマット：設計と実装の分離は害悪 #0

  • 座組「設計は事業会社・企画はマーケティング会社・実装はSIer」
  • 背景：内製化へのトライ／情シス提示コストとの戦い
  • 承認押印された設計に仕様バグがある場合、そのPJでは直ちに改善することができる余地はあるか？

• ビッグデータ機械学習：統計処理の功罪

  • 統計は恣意的な数値を作り出すための学問だ（師曰く
    • 平均値・中央値・最頻値の違い
      • 何かの説得に利用され始めたとたんにウソ大げさに
    • 因果関係と疑似相関
      • 疑似であたってる場合には予測になる
  • とはいえ、数字を見なさすぎるケースも
  • 数字は決めて集計した途端に一人歩きする

• アルゴリズム・設計：データストアの多重化

  • 大量データでの検索性担保
    • データの持たせ方を、検索にあわせ多重化するしかない
      • でもこれって、クラスタインデックス＋インデックスみたいなノリでコード書く人が考えるのには限界がある
      • RDBMSでも出来はするが、苦労しかしないアプローチ
    • BigQueryなど技術観点でクラウド化活用の見せ場にも
      • 大量スピンドル／コアでの（ほんとの）並列処理
  • RDBMSの正規化とはほど遠い時代観
    • 過度な正規化制約条件は性能を引っ張るが

• データアーキテクチャに正解はあるのか

  • データライフサイクルも変わる
    • データは破棄しない時代に（見せない仕組みへ）
  • データモデルは参照・更新の規模、業務次第で選択だが
    • 投入・加工・保存時
    • 参照時
    • バッチ的視点からリアルタイム指向への変化
  • 設計の範囲は実装技術的にも業務的にも広がる傾向

• データアーキテクチャ方法論的アプローチへの道 #0

  • A) 業務の見姿・青写真
  • B) 箱絵のシステム概要設計
  • C) 変更容易低遅延でテスト可能な実装コード
  • ウォーターフォールでの成功パターンは、隣接上下での調整を密にする
    • B <-> A、C <-> A のケース
  • アジャイルスクラムでの成功パターンは、上下を飛び越えて調整を密にする
    • C <-> A のケース

• データアーキテクチャ方法論的アプローチへの道 #1

  • 王道は
    • ドメインレベルでのライフサイクル
    • 機能単位での参照更新頻度と有効期限の把握
    • 緩めてよい制約と守るべき制約
    • 低レイテンシー指向でのモデルとロジックの模索
  • そのうえで、こぎ見よい定石はあるのか
    • 現時点であまりみない→結局データの使い方によるから
    • 結局「あとで引けるように」溜めておけ、を基盤側でカバー
  • Reactive のトレンドが何かを解決するかも？

スケーラブルなデータアーキテクチャ これから注目される原理

• 非同期伝搬 - Primary-Backup Replication
  • バックアップに時間かかる
  • 更新に時間がかかるとクライアント側に待ちが発生する
  • メッセージをQueueに入れて、Queueからバックアップタスクを実施

• 弱いアイソレーションモデル - Snapshot Isolation

  • 更新と読み取りは互いにブロックしない
  • ロックを使わない（厳密には使っているが）
    • 更新中のデータが読める
    • 読み込んでいる最中に更新出来る
  • 最初にコピーを取って読む
  • 最初にコピーを取って読み取りようにし、更新する
  • トランザクション処理で問題が発生する
    • トランザクションAを実施中に別トランザクションBが更新を行っても、トランザクションAの後続処理の内容が更新されない
    • トランザクションAが終わって、再度トランザクションを作成した場合、トランザクションBの内容が反映される

• データベース技術における最適化法の進展

  • これから
    • バッチ技術の拡張
    • Commutativity（半順序）の応用
  • 今日は「Commutativity（半順序）の応用」のみ紹介

• Commutativity とは

  • 日本語訳： 可換性
  • AB = BA

• 割り込んではいけないトランザクション処理
  • 計算の途中にその値を使う式を使ってはいけない
  • 更新の順番が変わってはいけない

• Serialization Graph
  • Serializable schedule
    • r1(x)w2(x)w1(y)r2(y) ≡ r1(x)w1(y)w2(x)r2(y)
  • Non serializable schedule
    • r1(x)w2(x)r2(y)w1(y)

• Concurrency Control の役割（RDBMSが現状行っている処理内容）
  • ロックをどこからどこまでかけるかをコントロールする仕組み

• Serialization Graph の例
  • データベースは、実行時にSerialization Graphを作成し、一番効率の良い実行ルートを探して実行

• DAG: Directed Acyclic Graph
  • 有向非巡回グラフ
  • 下図の例の場合、もし B → C の赤い → 部分がなかった場合、B と C は並列処理が可能
  • DAGは様々な分野で使われている

• データベース技術における最適化法の進展
  • これまで
    • 非同期伝搬
    • 弱いアイソレーションモデル
  • これから
    • バッチ技術の拡張
    • Commutativity（半順序）の応用