大規模データとの戦い方

Transcript

1. Kenichi Suzuki Loglass Inc. BtoB SaaSにおける ⼤規模データとの戦い⽅

2. 2 新卒でNTTデータに入社。アーキテクチャ設計や統括業務に従 事した後、より堅牢な開発を求めてプログラム言語理論（型シス テム、関数型等）の研究に踏み込む。 その後、よりセキュアな世界を目指して、 Visional（BizReach）に てサイバーセキュリティ事業の立ち上げや開発をリード、 ContractSにて開発部長、技術戦略室長、 VP of

   Development を経て、2023年に株式会社ログラスにジョイン。 X: @_knih 株式会社ログラス 鈴木健一 / Kenichi SUZUKI

3. 3 Finally, safely-extensible and efficient language-integrated query PEPM '16: Proceedings

   of the 2016 ACM SIGPLAN Workshop on Partial Evaluation and Program ManipulationJanuary 2016 Pages 37–48https://doi.org/10.1145/2847538.2847542 Multi-Stage Programming、そして脆弱性レジリエンス × Clean Architecture https://engineering.visional.inc/blog/212/scalamatsuri2020-interview-msp/ 脆弱性レジリエンスを高めるための Clean Architecture https://yamory.io/blog/architecting-for-resilience/ エンタープライズアジャイル開発における品質管理とセキュリティ対策を yamoryで考える https://yamory.connpass.com/event/198588/ Scala3でコードは爆速になるマルチステージプログラミングの考え方 https://logmi.jp/tech/articles/324146 Dotty ではじめるマルチステージプログラミング入門 https://www.youtube.com/watch?v=gpQHgcIIzFY From Tagless-Final to Typed-Final: Program Transformations in the Final Style https://speakerdeck.com/dcubeio/from-tagless-final-to-typed-final-program-transformations-in-the-final-style ContractS Tech Book Vol.1 第8章　型の力で高品質にドメインをモデリングする ー関数型DDDに向けてー. https://nextpublishing.jp/book/14565.html Publications …etc.

4. 4 ©2024 Loglass Inc. ログラスについて（5秒） 企業価値を向上する
 経営管理クラウド


5. 5 ©2024 Loglass Inc. 5 次世代型 経営管理クラウド

6. 6 ©2024 Loglass Inc. 経営企画は「企業価値の向上」をミッションに、企業経営にまつわるあらゆる業務を担っている

7. 前提 • 本発表ではBtoB SaaSプロダクトを前提とします ◦ とはいえ、アーキテクチャについて⾔及するためBtoCでも通⽤するとこ ろは多い

8. データ増⼤による問題 データ増⼤による問題

9. プロダクトスケール 湯浅エムレ秀和（2021）. シリーズA. https://note.com/emreyuasa/n/n03aca5b7a981

10. プロダクトスケール 湯浅エムレ秀和（2021）. シリーズA. https://note.com/emreyuasa/n/n03aca5b7a981 リクエスト数やデータ量が 増えていく 事業成⻑にあわせて、 プロダクトをスケール していく必要がある 実際の

    成⻑曲線

11. データの増⼤ データが増える要因 ユーザー数の増加 機能の拡充 ユーザー数の増加 利⽤頻度の増加 新規プロダクトの追加 ユーザー規模の拡⼤ 顧客分析の強化 ‧‧‧等々

12. データスケールを考慮していない アーキテクチャだとどうなるか？

13. Database データボリュームだけでなく、トランザクションボリュームも増加 データの増⼤ App 保持データ量 の増⼤ 変更量‧変更 頻度の増⼤

14. パフォーマンス問題 パフォーマンスが劣化すると、様々な問題が発⽣ • DB‧CPU負荷の増⼤ ◦ インフラコスト増⼤ ◦ リクエストが詰まりやすい状況を誘発 • タイムアウトによるユーザーリクエストの失敗

    ◦ 機会損失 • マテリアライズド‧ビューの更新遅延 ◦ タイムリネス（データ鮮度）の低下 • パフォーマンスチューニングの⼯数が増えることで、開発が遅くなる

15. 参考：マテリアライズド‧ビューの功罪 • マテリアライズド‧ビューは、事前に計算されたデータセット • 増分更新ではない場合、全件アップデートするためデータ量の増加につれ、 更新負荷があがっていく ◦ PostgreSQLでは基本的に⾮増分更新 （増分更新をサポートするアドオンはある） •

    さらに、集約関数を使うようなSQLは、メモリに乗らなくなった瞬間に急激 に遅くなる データ増加に伴い、 データの鮮度が落ちやすくなる

16. Big-O Cheat Sheet. https://www.bigocheatsheet.com/ データ量の増加で 一気に性能劣化する パフォーマンス問題を誘発しやすい作りになっていないか

17. 問題が起きてから対処しては遅い

18. パフォーマンスの 抜本的な改善には時間がかかる

19. パフォーマンスの抜本的な改善 • アーキテクチャの変更 • データモデルの修正、インデックスの再設計 • アプリケーション仕様の変更

20. パフォーマンスの検討に早過ぎるということはない “最⼤の理由は、どのような変更を加えた時に パフォーマンスが急降下したかがわかることで す。これならパフォーマンス問題に直⾯した時 に、アーキテクチャー全体を相⼿にせず、最近 に加えた変更に焦点を絞り込んでいけるので す。 Rebecca Parsons (2009).

    97 Things Every Software Architect Should Know - Chapter 13. O'Reilly Media.

21. スケールを成功させるためには洗練されたアーキテクチャが必要 “ソフトウェア‧システムの規模が⼤きく、 複雑であればあるほど、成功のためには よく練られたアーキテクチャが必要になる The greater the size and complexity

    of a software system, the more you will need a well thought-out architecture in order to succeed. Joseph Ingeno (2018). Software Architect's Handbook: Become a successful software architect by implementing effective architecture concepts. Packt Publishing.

22. パフォーマンスを検討するといっても、 デリバリが遅くなってはいけないのでは？

23. 開発速度をキープしつつ、 スケールしていきたい

24. そこで

25. データスケールを考慮した 継続的アーキテクチャ

26. Minimum Viable Architecture（MVA） • 実⽤に⾜る最⼩限のアーキテクチャ • MVP（Minimum Viable Product） •

    最低限の品質要件を満たしている • プロトタイプアーキテクチャ ◦ 理想的には特別な技術を必要としない（ペーパープロト等） • Just Enoughアーキテクチャ ◦ ⾼速な学習と改善、スケーリングしない 参考：Randy Shoup. Minimum Viable Architecture. YOW! Brisbane 2022. https://yowcon.com/brisbane-2022/sessions/2358/minimal-viable-architecture

27. 事業成⻑をキープし続けるためには

28. 事業が急速に成⻑するよりも前に、 次のアーキテクチャに進化させたい

29. 継続的アーキテクチャとその原則 以下の6原則に従ったアーキテクチャアプローチ 参考：Murat Erder (2015). Continuous Architecture: Sustainable Architecture in

    an Agile and Cloud-Centric World. Morgan Kaufmann. 1. プロジェクトではなく、プロダクトを設計 2. 機能要件ではなく、品質属性にフォーカス 3. 必要になるまで、設計の決定を遅らせる 4. 変化のために設計する — "⼩さな⼒ "を活⽤する 5. ビルド、テスト、デプロイのための設計 6. システムの設計後に組織をモデル化 顧客に集中する 品質属性の要件がアーキテク チャを推進 使われない無駄を避ける ⼩規模で疎結合に 継続的デリバリーも考慮 チームの編成⽅法がアーキテ クチャと設計を駆動する

30. 継続的アーキテクチャの主要な活動 • 品質属性を計測し、フィードバックループをまわす • 技術的負債を管理する Murat Erder, et al. Continuous

    Architecture in Practice. Addison-Wesley Professional. 2015.

31. データ増⼤による問題 品質属性と⾒積もり

32. システム/ソフトウェア製品品質 機能連合性 性能効率性 交互性 使⽤性 信頼性 セキュリティ 保守性 移植性 ‧適応性

    ‧設置性 ‧置換性 ‧モジュール 性 ‧再利⽤性 ‧解析性 ‧修正性 ‧試験性 ‧機密性 ‧インテグリ ティ ‧否認防⽌性 ‧責任追跡性 ‧真正性 ‧成熟性 ‧可⽤性 ‧障害許容性 （耐故障性） ‧回復性 ‧適切度認識 性 ‧習得性 ‧運⽤操作性 ‧ユーザエ ラー防⽌性 ‧ユーザイン タフェース快 美性 ‧アクセシビ リティ ‧共存性 ‧相互運⽤性 ‧時間効率性 ‧資源効率性 ‧容量満⾜性 ‧機能安全性 ‧機能正確性 ‧機能適切性 ソフトウェアの品質特性 品質特性 品質副特性 システム‧ソフトウェア製品の品質モデル（JIS X 25010:2013（IEC25010：2011）に基づく）

33. ソフトウェアの品質属性 • 品質属性＝品質特性を細分化した末端 ◦ 性能→時間効率→レスポンスタイム、スループット等 • 測定可能、テスト可能 • 品質属性要件はアーキテクチャと相互に影響しあう •

    品質属性間にトレードオフがある ◦ 例：セキュリティを⾼めるとユーザビリティが低下する 品質属性要件がアーキテクチャの肝になる

34. 品質特性シナリオ • 品質要求を⾔語化するためにシナリオを検討する • シナリオ ◦ 要求を具体的なストーリーにしたもの • シナリオの種類 ◦

    利⽤シナリオ、成⻑シナリオ、調査シナリオ（問題予測） ユーザー体験‧機能を軸にする ため、フィーチャー開発チーム が主体となるか、連携できる体 制で臨むのがよい Len Bass, et al. Software Architecture in Practice, 4th Edition. Addison-Wesley Professional. 2021.

35. 品質特性シナリオの例 • 品質特性 ◦ パフォーマンス • シナリオ例 ◦ 登録データが10億件以内である場合、ユーザーには3秒以内で⼀覧が返さ れる

    想定されるシナリオをリスト化し、 優先順位をつけるとよい

36. 想定リクエスト数、データ量 基礎データ（要件） • 当該ユースケースに対するリクエスト数 • データ量 SQL計算モデル • 計算量⾒積もり •

    インデックス設計 ◦ 結合、フィルタ、ソート • MENTORの法則

37. 参考：結合の計算コスト O(N × M) O(N log N) + O(M log

    M) + O(N + M) O(N) + O(M) ネステッドループ結合 ソートマージ結合 ハッシュ結合 掛け算が多いと、データ量の増加に⽐例して急激にコストが跳ね上がる

38. どこまでアーキテクチャを 設計‧実装すればよい？

39. 問題ではなくリスクに着⽬する

40. リスクと問題 潜在 顕在 未 対 応 対 応 リスク 問題

    課題 対応を決めた リスク インシデント 課題設定 リスク判定 応急措置 消⽕のマネジメント 防⽕のマネジメント 状況に応じて消化‧防⽕それぞれのアプローチをとる

41. 起こり得る可能性で⾒極める • リスクが顕在化したときの脅威の⼤きさと、可能性の⾼い シナリオに着⽬ • リスクが複数ある場合は、アーキテクチャバックログを作 成すると良い

42. リスクが低減したらパッシブモードへ リスク リスクしきい値 ⾼い 低い アーキテクチャのリスクを減らす ために、アクティブに動く アーキテクチャを受動的に監視し、 問題に対処する 時間

    Michael Keeling (2017). Design It!: From Programmer to Software Architect. Pragmatic Bookshelf. 消化アプローチ 防⽕アプローチ

43. データ増⼤による問題 ⼤規模データを考慮した アーキテクチャ観点 検討しておくべきリスク

44. 決定を遅らせる≠検討しない

45. 必要になった段階で決める ≠ 問題が起こってから決める

46. 決定が遅くなると‧‧‧ 意思決定のジレンマ、⼿戻りが発⽣しないようにしたい 時間 コスト 最終責任点 （Lost Responsible Moment; LRM） Tom

    Poppendieck, Mary Poppendieck. Lean Software Development: An Agile Toolkit. Addison-Wesley Professional. 2003. を参考に作成 誤ったものを 作るリスク 機会損失の リスク ⼿戻りコスト 決定コスト

47. 早期に考慮しておいたほうが良い観点 アーキテクチャを作り込むのは 適切なタイミングで

48. （再掲）プロダクトスケール 湯浅エムレ秀和（2021）. シリーズA. https://note.com/emreyuasa/n/n03aca5b7a981

49. マルチテナント Web App Web App Web App Web App

50. マルチテナント戦略 うるさい隣⼈（ノイジーネイバー）アンチパターン 時間 リソース 使⽤量 Tenant B Tenant C Tenant

    A データ量 キャパシティ C A B テナント

51. テナントの分離 Web App Web App Web App App App サイロ

    プール ブリッジ Web App Web App プールパターンはノイジーネイバーのリスクがある テナント別サブドメイ化もあ わせて検討しておくとよい https://xxx.example.com

52. データの分離 インスタンス分割 アクセス制御の開発コスト、スキーマバージョン管理の運⽤負荷を考慮しておく インスタンス‧DB分割は、後 述の論理分割⽅式によって決定 を遅らせることが可能 DB分割 テーブル 分割 レコード分割

    （RLS）

53. アプリケーションによる論理分割 論理分散キーによるアプリケーション制御による分散 ネーミング 接続プール BFF Backend 接続プール Backend 接続プール Backend

    接続プール Backend 分散キーはテナン トIDのハッシュ、 顧客ID下2桁等 拡張 ⼤規模であればコンテンツ ベースルーターパターンとあ わせて検討したほうがよい 特定のテナントをより ⾼いSLAのプールに ルーティングする等も 可能

54. イベントソーシング‧CQRS • 複数の境界付きコンテキストがあり、将来的にイベントソーシングにしてい く可能性があるなら、ドメインデータプロダクトとして分離しておくと良い ◦ イベントソーシングへの変更はデータモデルに⼤きく影響するため、依 存を分離しておいた⽅が良い • ⼤規模なシステムに、可能な限りリアルタイム性を持たせたいなら検討する Data

    Vaultパターンは運⽤コストは ⾼いが、後付けでInsert-onlyな分析 データベースを構築可能 Web Domain Write Domain Domain Read

55. データ分析 • ダッシュボードやレポート機能等、機能を横断したデータ 分析をどうするか ◦ データから重要な意思決定のための知識を抽出するニーズ • パフォーマンス要件次第 ◦ オペレーショナルデータベースをそのまま使う

    ◦ データプロダクト内部に分析データベースを持つ ◦ 分析データベースを共通化する • ポリグロット永続性もあわせて検討 ◦ サービスごとに最適なデータベース

56. 分析データベース Web Domain Domain データベースの持ち⽅によって、ETLやレプリケーションを通した全体の整合を考 慮する必要がある Web Domain Domain レポー

    トDB Web Domain 分析 DB Domain ケース1 ケース2 ケース3

57. CAP定理 ⼀貫性 C 分断耐性 P 可⽤性 A CAP定理 Cassandra等 MoongoDB

    BigTable等々 RDBMS

58. CAP定理からPACELC定理へ • PACELC定理 ◦ メリーランド⼤学のDaniel Abadi先⽣が提唱 ◦ CAP定理に対して遅延（Latency）の軸を含めたもの 参考：Daniel Abadi

    (2010). Problems with CAP, and Yahoo’s little known NoSQL system. https://dbmsmusings.blogspot.com/2010/04/problems-with-cap-and-yahoos-little.html

59. PACELC定理 Avabilability Consistency Consistency Latency Partion YES NO CAP Theorem

    PACELC Theorem 参考：Daniel Abadi (2010). Problems with CAP, and Yahoo’s little known NoSQL system. https://dbmsmusings.blogspot.com/2010/04/problems-with-cap-and-yahoos-little.html

60. データメッシュ セルフサービスプラットフォーム データガバナンス コンプライアンス・プライバシー ポリシー 相互運用ポリシー （データ標準化） ドキュメントポリシー ベストプラクティス 実装例

    チームへの提案 イネーブリング セキュリティポリシー ストレージ・ クエリエンジン データカタログ データ契約管理 ポリシー自動化 モニタリング・ 分析ツール 分析 データ 契約 運用 データ データプロダクト ドメインA ドメインB ドメインC ドメインD ドメインE Jochen Christ, ,Larysa Visengeriyeva, Simon Harrer, et al. DATA MESH ARCHITECTURE https://www.datamesh-architecture.com/ を参考に作成

61. 既存のデータベースに対する分解⼿順 • データドメインの分析 • テーブルをデータドメインに割り当てる • データドメインへのデータベース接続を分離する • スキーマを分離されたデータベースに移動 •

    独⽴したデータベースクラスタに分離する

62. 変化を設計する（適応可能アーキテクチャ） • シナリオ ◦ データ量の増⼤ ◦ テナント数の増⼤ ◦ トラフィック‧リクエスト数の増⼤ •

    シングルインスタンス → マルチインスタンス ◦ データ量の限界 ◦ 論理DB • 分散DB

63. アーキテクチャ設計のアジャイルへの組み込み • アーキテクチャの決定 • アーキテクチャガバナンス ⼈⽉の神話 継続的アーキテクチャ アーキテクチャの決定スタイル 概念の整合が重要 少数で決める

    コミュニケーション努⼒に よって概念を整合 概念が整合しやすい スケールしづらい コミュニケーション難易度が⾼い スケールできる

64. まとめ • 事前にリスクを起点としてアーキテクチャを検討する • MVAからはじまり、スケールに備えられるよう継続的アー キテクチャを実践する ◦ BtoBではデータ増⼤が主要リスク ◦ マルチテナント戦略とデータ分割は先に検討したほうがよい

    • アーキテクチャガバナンスで⺠主化と概念の整合を担保す る

65. 65 We are hiring! 一緒にプロダクト開発の次元をあげていきたい、良い景気づくりにご興味 のある方を絶賛募集しています！！ https://job.loglass.jp/ カジュアル面談Welcome です！

66. None