成長企業3社はデータベースとどう向き合っているか に参加なう

今回も参加レポ
https://twitter.com/hashtag/db_how?src=hashtag_click
https://estie.connpass.com/event/313405/

「事業の成長に DB アーキテクチャをアラインするために AWS DMS を活用した話」

taisa831 さん テックタッチ株式会社

• マイクロサービスを切り離しした話

  • マイクロサービスを使っていますか？
  • マイクロサービスとは
    • ビジネスドメインを中心にモデル化された、独立してリリース可能なサービス

• なぜマイクロサービスを切り直ししたか？

  • テックタッチは初期の頃からマイクロサービスアーキテクチャを採用している
  • 事業の成長とともに環境が変化し、ドメイン教会が初期の思想と変わってきた
    • 分散モノリス状態になった
      • 複数のサービスで構成されているものの、何らかの理由でシステム全体が一緒にデプロイされなければならなくなっているシステムのこと
      • 分散システムの全ての欠点と単一プロセスモノリスの欠点を持ちどちらの利点も教示できなくなった

• どうマイクロサービスを切り直ししたのか

  • モジュラーモノリス化
    • サービス A と サービス B をくっつけた
      • 加重ルーティングでリクエストを振り分け移行
        • すぐに戻せる状態に
  • 別のドメイン協会でサービスを切り直し
    • 横串でドメインを切る
      • イベントストーミングを実施し裏付け
        • ビジネスプロセスやドメインの知識を共有
      • サービスの独立性が高まりマイクロサービスの利点の多くが享受できるようになった
      • 一方で Database を跨いだ状態になっている
  • AWS DMS を活用して DB 統合した
    • なぜ DB 統合したか
      • 分かれてしまっているため DB 周りの開発効率が良くない
      • RDS のコストが無駄にかかる
        • 統合を実施
    • やりたいこと
      • 別々のスキーマから同一のスキーマに DB 統合したい
    • 制約
      • 同じ名前のテーブルが存在するのでテーブル名をリネームする必要がある
    • DB の特徴
      • Aurora 2.x系だとテーブル単位のレプリケーションができなかった
    • サービスの特性
      • サービス AB-main
        • 停止可
      • サービス AB-Reader
        • 無停止
    • どう統合したか
      • ３段階に分けて統合
        • DMS　でレプリケーションを貼る
          • Database A で binlog 有効化
          • DMS でレプリケーション
            • スキーマ名リネーム
            • 同一テーブル名リネーム
          • 向き先変更

• 今後の課題

  • サービスの進化によってデータ構造がひろくと言うより深くなってきた
    • リレーショナルで表現するのが難しい Json のネストが深くなってきたイメージ
  • 適切なデータアーキテクチャ選定で適切に事業要求と DB　制約を捌いていきたい

• まとめ

  • 事業の成長に合わせてアーキテクチャをアラインしていこう！
    • サービスのアーキテクチャに合わせた手法を使う
    • 難しければアーキテクチャを変更するのも手
    • DMS 使えば意外とやれそう

• AWS DMS で気をつけるポイント

  • DMS の設定
    • Source と Target でレプリケーション
      • 外部キー制約やインデックスなどのメタデータは同期されない
        • メタデータが必要な場合には事前にテーブルを作成しておく
    • Max LOB サイズを適切に設定しないとデータが切り捨てられる
      • 制限付き LOB モードが推奨、最大 LOB サイズを設定する
        • LOB カラムの最大値をチェックしいましょう

「パフォーマンスを求めてDBに機能を寄せる戦略」

青柳康平 さん ユニークビジョン株式会社

• DB に機能を寄せるとは
  • 一般的な Web アプリケーション
    • Web サーバーから DB サーバにデータを検索や投入してユーザーに返す
  • ロジックをなるべく DB で処理するようにするようにすること
    • Web サーバの役割
      • フロントエンドでデータをバリデーション
      • DB に入力データを渡して戻り値を受け取る
      • フロントエンドに返すデータの構築
      • その他、DB ではできないガオイブ API との処理
    • 何で DB に寄せるのか？
      • Web サーバと DB との通信の往復を減らす
        • N+1 問題等
      • SQL を直接扱うことで細かなパフォーマンスの調整ができる
        • ORM だと最適な SQL を得るかどうかわからない
        • DB に寄せることで細やかなパフォーマンスチューニングが可能となる
  • SQL だけでは難しい処理は手がつづき型言語
    • SQL だけでできることは限界がある
      • 代入
      • 判定
      • ループ
    • PostgreSQL で利用できる手続き言語は割とある
      • ライブラリコンパイル時に限定される
      • ここでは PL/ｐｇSQL
  • PL/pgSQL
    • 他のプログラミング言語ベースに対してSQL との親和性が高い
    • ほぼほぼ SQL がそのままかけて代入、判定、ループと融合している
      • やりたいことができている
  • ２種類のユーザー定義
    • 目的ごとに２種類のユーザー定義処理を作成できる
      • Function
        • 主に値を返すことが目的
      • Procedure
        • 主にトランザクション制御が目的
    • 任意の型の定義
      • 例えば二つのテーブルを結合したような型を定義して Function の戻り値に設定できる
        • VIEW みたいな感じ
  • メリットとデメリット
    • メリット
      • 手続き型言語を導入することにより、SQL ではできない複雑な処理が書ける
      • アプリケーションサーバとの通信が少なくなる
      • Function の機能で擬似テーブルが作れるので共通化ができる、View よりも柔軟
      • Procedure の機能で細かいトランザクション制御ができる
    • デメリット
      • 新しい言語の習得
        • 慣れるにはある程度の時間が必要
      • ループの使いすぎに注意
        • 集合を使った方がパフォーマンスは高い
      • エディターの補助がない
• まとめ
  • 複雑な要件が多いため DB で処理をさせるのがいい
  • まとめておくことで利用する側が細かい仕様を意識しなくて良い

「Snowflake で眠ったデータを起こそう！データをフル活用するデータウェアハウス生活」

kenkoooo さん estie

• スタッフエンジニア
  • みんなが連携を気にしなくても会社として空中分解しないように人柱となって繋ぎ止めている
• snowflake
  • snowflake 社が開発するデータプラットフォーム
    • めちゃくちゃでかいデータベース
    • めちゃくちゃ強い
  • SQL でクエリが書ける
    • PostgreSQL 互換
• 課題
  • データがめちゃくちゃ増えてきた
    • データソースが増えてきた
    • カバー範囲が広がってきた
    • ユーザーが増えてきた
• 全てのデータが集まる場所
  • S3 にデータが置けるものなら Snowpipe で同期できる
  • MySQL のデータも fivetran で寄せられる
    • あらゆる場所に散っているデータが LEFT JOIN で扱える！
• パワフルデータ加工場
  • 受領したデータをそのまま出すことはない
    • 名寄せとか重複削除とか加工してた
  • dbt で加工
    • embulk -> MySQL に戻す
• Streamlit
  • Python で簡単にデータアプリが作れる
  • Snowflake が買収
    • 社内向けデータアプリが簡単に作れる！
      • アカウントを持っているとアクセスできる
        • アカウント管理が凋落
        • データの権限もアカウントに紐づいている
      • 社内用途なら Streamlit で十分
      • インフラの設定も不要
        • Snowflake の高級なインスタンスで Web アプリが動く
• まとめ
  • あらゆるデータが１箇所に集まるのは最高！
  • データの加工もできて最高！
  • データアプリも簡単位作成できて最高！

株式会社いい生活はデータベースとどう向き合っているのか

• 使っている DB
  • Aurora　MySQL
    • ３０クラスタ 60インスタンス くらい
  • 870テーブル、18,000カラム
    • 家の情報
      • 210テーブル, ４５０0カラムくらい
    • 人の情報、やり取り
      • 230テーブル、５０００カラムくらい
    • 契約
      • 190テーブル、6000カラムくらい
    • 賃貸管理
      • 80テーブル、1300 カラムくらい
  • DB や API のドキュメントを作ると大抵見づらい
    • DB 定義を見やすく使いやすくした内省ドキュメントツールがある
    • チューニングが大事で放置するとすぐに遅くなる
    • データ分析は弱い
    • Aurora インスタンスサイズの拡張にまだ余裕がある今のうちに DB 再設計を計画している