DIGGLEの分析基盤アーキテクチャ

以下イベントの登壇資料
https://aws-startup-community.connpass.com/event/299342/

Transcript

1. DIGGLEの
   分析基盤アーキテクチャ
   zakky
   

   View Slide

2. Agenda 自己紹介
   背景
   課題
   解決策
   まとめ
   

   View Slide

3. 自己紹介
   私って誰？
   

   View Slide

4. DIGGLEでフルスタックエンジニアとしてイ
   ンフラに限らず、バックエンド、フロントエン
   ドなんでも広くやっています。
   zakky
   

   View Slide

5. 背景
   DIGGLEについて
   

   View Slide

6. DIGGLEについて
   

   View Slide

7. DIGGLEについて
   経営管理で求められる分析とは？
   2023年度
   計画 実績 差異
   売上高 1,200 1,280 +80
   売上原価 400 393 -7
   売上総利益 800 887 +87
   販売管理費 230 345 +115
   営業利益 570 542 -28
   勘定科目を
   細かくしたい
   月単位で
   管理したい
   任意の分析軸
   で見たい
   企業が成長すると
   管理したい軸が増え、細分化する
   

   View Slide

8. 課題
   DIGGLEに求められること
   

   View Slide

9. 数字を扱うSaaSであるため、データの整合性を担保
   する必要がある
   10,000セルを超えるテーブルの描画など、描画時に
   もパフォーマンスを求められる
   BigDataという程ではないが、RDBで扱うには難しい
   データ量を扱う必要がある
   BIツールのような自由度の高い分析を行う必要があ
   る
   任意軸での分析 データ量 データの整合性
   リアルタイム性 高速な描画
   データ更新後の合計値や計算式（Excelの計算式の
   ようなもの）の再集計をオンライン処理の範囲内で行
   う必要がある
   経営管理の特徴
   

   View Slide

10. 数字を扱うSaaSであるため、データの整合性を担保
    する必要がある
    10,000セルを超えるテーブルの描画など、描画時に
    もパフォーマンスを求められる
    BigDataという程ではないが、RDBで扱うには難しい
    データ量を扱う必要がある
    BIツールのような自由度の高い分析を行う必要があ
    る
    任意軸での分析 データ量 データの整合性
    リアルタイム性 高速な描画
    データ更新後の合計値や計算式（Excelの計算式の
    ようなもの）の再集計をオンライン処理の範囲内で行
    う必要がある
    DIGGLEが抱えていた課題
    パフォーマンスに課題があり、自由度に対して一定の
    制限がある
    RDBで実装していたがパフォーマンスの問題が発生
    した
    RDBを 使 っているため 問 題 になっていないが、
    Redshiftなどへそのままリプレイスすることはできな
    い
    更新箇所に関係なく全体を再計算していたためパ
    フォーマンス問題が発生した
    tableタグを使 用しての描 画では10,000セルを超え
    ると性能劣化が激しく発生する
    2017年7月のサービスローンチから 5年以上経過し、色々な課題が見えてきた
    

    View Slide

11. 解決策
    何をしたのか
    

    View Slide

12. 数字を扱うSaaSであるため、データの整合性を担保
    する必要がある
    10,000セルを超えるテーブルの描画など、描画時に
    もパフォーマンスを求められる
    BigDataという程ではないが、RDBで扱うには難しい
    データ量を扱う必要がある
    BIツールのような自由度の高い分析を行う必要があ
    る
    任意軸での分析 データ量 データの整合性
    リアルタイム性 高速な描画
    データ更新後の合計値や計算式（Excelの計算式の
    ようなもの）の再集計をオンライン処理の範囲内で行
    う必要がある
    課題を切り分ける
    パフォーマンスに課題があり、自由度に対して一定の
    制限がある
    RDBで実装していたがパフォーマンスの問題が発生
    した
    RDBを使っているため現 状 問 題になっていないが、
    Redshiftなどへそのままリプレイスすることはできな
    い
    更新箇所に関係なく全体を再計算していたためパ
    フォーマンス問題が発生した
    tableタグを使 用しての描 画では10,000セルを超え
    ると性能劣化が激しく発生する
    1 2 2
    2 3
    1
    

    View Slide

13. 課題を切り分ける
    BIツールのような自由度の高い分析を実現し、RDS
    では扱えない大量データを用いても高速に分析でき
    る基盤
    分析基盤
    1
    顧客が入力したデータを整合性を保った状態でリア
    ルタイムに集計・計算する基盤の構築
    データ入力基盤
    2
    大量の表データなどのクライアント負荷が高い画面描
    画を高速実現する基盤の構築
    描画基盤
    3
    任意軸での分析
    データ量
    データの整合性
    リアルタイム性
    高速な描画
    

    View Slide

14. 分析基盤
    BIツールのような自由度の高い分析の実現と、大容量データを受け
    入れ可能な基盤の構築
    

    View Slide

15. 分析基盤
    分析基盤で参照するデータについては、多次元データモデルを採用することで、自由度
    の高い分析を実現。
    データに対する分析に特化し、キャッシュなども十全に活用することで高速な分析基盤
    を実現。
    多次元データモデル
    自由度の高い分析を行う必要がある業務特性上、分析基盤の自製を決断。機械学習
    などで有名なpandasを使用して分析基盤を構築。
    pandasを使用して分析基盤を実現することにより、コンパイラ言語と同等の高速な分
    析基盤をPythonで実現。
    https://diggle.engineer/entry/dataframe_python_rust
    pandas（Python）
    

    View Slide

16. データ入力基盤
    顧客が入力したデータを整合性を保った状態でリアルタイムに集計・
    計算する基盤の構築
    

    View Slide

17. データ入力基盤
    旧来通りRDBを利用し、データ整合性担保などRDBの利点を最大限活用。
    リアルタイム性（高速なデータ更新、更新データの取得など）に関してもRDBを採用する
    ことにより実現。
    RDB
    計算式の計算を必要最小限の範囲だけ再計算をするように最適化。更新をRDB上で
    プロシージャとして行うことにより高速な更新を実現。
    計算式の高速化
    

    View Slide

18. 描画基盤
    大量の表データなどのクライアント負荷が高い画面描画を高速実現
    する基盤の構築
    

    View Slide

19. 描画基盤
    DOM（tableタグ）描画コストが掛かるものについてはcanvasを採用することで10倍以
    上の高速化を実現
    canvasの利用
    画面の再描画を必要最小限の範囲だけに絞ることにより描画コストを最適化
    https://diggle.engineer/entry/introduce_jotai
    再描画の抑止
    

    View Slide

20. まとめ
    さいごに
    

    View Slide

21. システム概要
    データ入力基盤
    描画基盤
    分析基盤
    API
    API
    データ連携
    描画 / データ入力 / 分析の3つに分離
    

    View Slide

22. We are hiring!
    

    View Slide