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

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

image

■ イベント概要

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

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

image

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

  • 情報ライフサイクル管理 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 のトレンドが何かを解決するかも?

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

image

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

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

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

    • 日本語訳: 可換性
    • AB = BA
S X
S true false
X false false
  • 割り込んではいけないトランザクション処理
    • 計算の途中にその値を使う式を使ってはいけない
    • 更新の順番が変わってはいけない

image

image

  • 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)

image

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

image

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

image

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

image

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

-未分類