Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

オニオンアーキテクチャで実現した 本質課題を解決する インフラ移行の実例

オニオンアーキテクチャで実現した 本質課題を解決する インフラ移行の実例

Hiroto Ryushima

October 27, 2024
Tweet

Other Decks in Technology

Transcript

  1. © 2024 Loglass Inc. Profile 龍島 広人 株式会社ログラス エンジニア フォルシア株式会社にて独自検索技術を利用した

    旅行会社向けの検索システム開発に従事。 同社のSaaSプロダクト立ち上げをリード。 2022年3月に株式会社ログラスへ入社。 レポーティング機能の開発を牽引し、現在は Enabling & Platform部アプリケーション基盤 チームとして集計基盤の構築やパフォーマンス改善、 アーキテクチャ設計を行っている。 Hiroto Ryushima
  2. © 2024 Loglass Inc. Contents 1. テーマ概要 2. オニオンアーキテクチャと依存性逆転の原則 3.

    実例: PostgreSQLからBigQueryへのデータソース切り替え 4. まとめ
  3. © 2024 Loglass Inc. 02|オニオンアーキテクチャと依存性逆転の原則 レイヤードアーキテクチャ UI Application Infrastructure ユーザとのや

    取 責務 ユースケース、処理の流 のハンドリング Domain 中心とな ロジック、ビジネスルール 外部(DB, サービス)とのや 取 依 存 の 方 向
  4. © 2024 Loglass Inc. 02|オニオンアーキテクチャと依存性逆転の原則 DB, 外部サービスの変更ってそんなにあ ? 歴史的に、業界では少なくとも 3

    年ごとにデータ アクセス手法が変更されて います。したがって、ビジネスにとってミッション クリティカルな、健全で長寿命 のシステムでは、3 年後にはデータ アクセスを変更する必要があると予想でき ます。 引用元: The Onion Architecture : part 1, 2008,Jeffrey Parelmo
  5. © 2024 Loglass Inc. 02|オニオンアーキテクチャと依存性逆転の原則 DB, 外部サービスの変更要因 • サービスの成長でパフォーマンスに課題が出る •

    新技術(新DB)の登場 • 古いDBのサポートが終了する • ビジネス上コスト削減が必要になる • 外部サービスの変更、廃止(直近だと生成AIなど) • グローバル展開による法規制への対応 • …
  6. © 2024 Loglass Inc. 02|オニオンアーキテクチャと依存性逆転の原則 依存性逆転の原則 Dependency Inversion Principle, DIP

    高レベルモジュールを低レベルモジュールに依存させない 低レベルモジュールを高レベルモジュールに依存させ (逆転) Infrastructure Domain 中心となるロジック、ビジネスルール(高レベル) 外部(DB, 外部サービス)とのやり取り(低レベル) ✕ ◯
  7. © 2024 Loglass Inc. 02|オニオンアーキテクチャと依存性逆転の原則 依存性逆転の原則 Dependency Inversion Principle, DIP

    コアなものをコアではないものに依存させない Infrastructure Domain 中心となるロジック、ビジネスルール(コア) 外部(DB, 外部サービス)とのやり取り(コアではない) ✕ ◯
  8. © 2024 Loglass Inc. 02|オニオンアーキテクチャと依存性逆転の原則 オニオンアーキテクチャ UI Application Infrastructure Domain

    依 存 の 方 向 DB, 外部サービスの変更が コアなロジックに影響を与えないので 変更が容易(柔軟性↑) コアなロジックは何にも依存せず メンテナンス、テストが容易(保守性↑)
  9. © 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え • 集計、レポーティング処理

    ◦ Repositoryでデータ更新、 QueryServiceで参照するCQRS構成 ◦ データ量増加に 参照の性能に限界が見えていた 対象のシステム アプリケーション Postgres Repository Postgres QueryService PostgreSQL 更新 参照(遅い)
  10. © 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え データソース切 替え

    アプリケーション Postgres Repository BigQuery QueryService データ連携 更新 参照 BigQuery 参照をBigQueryにすることで高速化を図る
  11. © 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え データソース切 替えに必要な対応

    アプリ改修 Postgres Repository BigQuery QueryService データ連携構築 更新 参照 BigQuery最適化
  12. © 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え そ ぞ

    の対応にかかった時間 アプリ改修 データ連携構築 BigQuery最適化 対応期間 どの対応にどれくらい時間がかかったか
  13. © 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え 対応に ってユーザに届く価値

    アプリ改修 データ連携構築 BigQuery最適化 入れたデータを早く 見れる! レスポンスが速い! ?
  14. © 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え 対応に ってユーザに届く価値

    アプリ改修 データ連携構築 BigQuery最適化 入れたデータを早く 見れる! レスポンスが速い! ? 本質的な 課題解決 本質的 ではない
  15. © 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え 悲しい時間配分 アプリ改修

    データ連携構築 BigQuery 最適化 対応期間 本質ではない部分で 時間が取られている
  16. © 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え 理想的な時間配分 アプリ

    改修 データ連携構築 BigQuery 最適化 対応期間も短く 本質的な課題解決に 時間をかける 本質じゃない部分は短く
  17. © 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え 短期間でアプリケーション改修を実現できた要因 •

    最小限で独立したアプリケーション改修 • 既存のQueryServiceへの網羅的なテストの転用
  18. © 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え 最小限で独立したアプリケーション改修 •

    PostgreSQLのQueryServiceと同じInterfaceを BigQuery用に実装する ◦ オニオンアーキテクチャによりInfrastructureに閉じた修正で 影響範囲が明確、限定的 • 他チームのDomain層、Application層への変更に干渉がない ◦ 同時に開発が進んでいたがコンフリクトはほぼ発生せず ◦ プロダクトの成長を止めない
  19. © 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え QueryServiceへの網羅的なテストの転用 •

    元々PostgreSQL用のQueryServiceに対して厚いテストが存在 ◦ 重要な数値計算ロジックを含むため • 同じテストケースを通すことで妥当性を持った実装と確認できた ◦ テストデータ、入力値生成ロジックもそのまま転用 ※この要素はオニオンアーキテクチャでなくても実現可能
  20. © 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え 実際の時間配分 アプリ改修

    データ連携構築 BigQuery最適化 2.5week 6week 2.5week 1week ここに集中できた結果どうなったか?
  21. © 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え BigQuery向けにデータ構造、クエリの大幅な変更 •

    パフォーマンス向上のため、データ構造、クエリを変更 ◦ 階層構造の持ち方を経路列挙モデルから閉包テーブルモデルに変更 ◦ それに伴いクエリも大幅に変更し、PostgreSQLとは全く違うSQLに ◦ パフォーマンスが大幅に向上 • 詳細は別記事 ◦ 列指向、行指向データベースの特性を 木構造を用いた集計クエリから理解する
  22. © 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え 本質課題 =

    パフォーマンスが悪い 集中して時間を投下し高度に解決!
  23. © 2024 Loglass Inc. 04|まとめ オニオンアーキテクチャで本質的な課題解決に集中 • パフォーマンス悪化によってデータソースの変更が必須となった • オニオンアーキテクチャによってInfrastructureの変更のみで済んだ

    • Infrastructureに対しての厚いテストを転用できたため更に変更は容易 • 本当に解決したかった課題(パフォーマンス改善)に集中 • ユーザに対して素早く、高品質な価値提供