非機能品質を作り込むための実践アーキテクチャ

Forkwell Library #77

Transcript

1. © 2024 Loglass Inc. 1 © 2024 Loglass Inc. Forkwell Library 非機能品質を作り込むたの 実践アーキテクチャ 株式会社ログラス 鈴木 健一 X: @_knih
2. © 2024 Loglass Inc. 2 自己紹介 NTTデータで大規模ミッションクリティカルシステムや基幹システムのアーキテク チャ設計、開発統括業務に従事した後、より堅牢な開発を求めてプログラム言語 理論（型システム、関数型等）の研究に踏み込む。 その後、よりセキュアな世界を目指して、Visional（BizReach）にてサイバーセ キュリティ事業の立ち上げや開発、プロダクトマネジメントをリード。ContractS にて開発部長、プロダクト部長、技術戦略室長、VP of Developmentを経て、 2023年に株式会社ログラスにジョイン。 株式会社ログラス 開発本部 Enabling&Platform部 部長 鈴木 健一 Kenichi Suzuki（knih） X: @_knih
3. © 2024 Loglass Inc. 3
4. © 2024 Loglass Inc. 4 Loglassについて
5. © 2024 Loglass Inc. 5 Loglassについて
6. © 2024 Loglass Inc. 6 00 | 目次 本日のお品書き 01 | データ増大による問題 02 | 継続的アーキテクチャ 03 | 非機能要件と品質属性と品質属性シナリオ 04 | 非機能要件の直交性をあげる 05 | 複雑性の分離とアーキテクチャ量子 06 | まとめ
7. © 2024 Loglass Inc. 7 データ増大による問題
8. © 2024 Loglass Inc. 8 01 | データ増大による問題 プロダクトスケール 湯浅エムレ秀和（2021）. シリーズA. https://note.com/emreyuasa/n/n03aca5b7a981
9. © 2024 Loglass Inc. 9 01 | データ増大による問題 プロダクトスケール 湯浅エムレ秀和（2021）. シリーズA. https://note.com/emreyuasa/n/n03aca5b7a981 実際には急激なカーブを 描く場合もある
10. © 2024 Loglass Inc. 10 事業成長にあわせてプロダクトを スケールしていく必要がある
11. © 2024 Loglass Inc. 11 データスケールを考慮していない アーキテクチャだとどうなるか？
12. © 2024 Loglass Inc. 12 利用ユーザーが増加、データが急増 その結果... クエリ負荷が増大！
13. © 2024 Loglass Inc. 13 01 | データ増大による問題 CPUが高負荷状態に 長時間クエリでロックが発 生しやすい状態に 高負荷状態に
14. © 2024 Loglass Inc. 14 結合が多い…！ 問題のあるクエリ
15. © 2024 Loglass Inc. 15 01 | データ増大による問題 結合の計算コスト Nested Loop Join O(N × M) Sort Merge Join O(N log N) + O(M log M) + O(N + M) Hash Join O(N) + O(M) b-treeインデックスが効く場合は、 O(log n)
16. © 2024 Loglass Inc. 16 01 | データ増大による問題 計算コストのモデル化
17. © 2024 Loglass Inc. 17 01 | データ増大による問題 コスト試算
18. © 2024 Loglass Inc. 18 01 | データ増大による問題 コスト試算 https://en.wikipedia.org/wiki/Japanese_numerals
19. © 2024 Loglass Inc. 19 01 | データ増大による問題 計算量の増加イメージ https://www.bigocheatsheet.com/ データ増加に伴い、 爆発的に計算量が 増加する構造
20. © 2024 Loglass Inc. 20 01 | データ増大による問題 PostgreSQLの仕組み Parser Analyzer Rewriter Planner Executor SQL Result Set ここで実⾏計画が作られる stats data
21. © 2024 Loglass Inc. 21 01 | データ増大による問題 PostgreSQLのクエリ最適化アルゴリズム 最低コストパス 式書き換え（前処理） リレーション情報抽出 動的計画法 ベース 遺伝アルゴリズム ベース（GEQO） クエリ実行 少ない 多い 結合パス次第でアルゴリズム が変わり、パフォーマンスが 安定しにくい結果に パス探索 パス探索と枝刈りは同時に行われるため、PlannerとOptimizerの区別はない 結合 パス
22. © 2024 Loglass Inc. 22 計算コストが変動的で複雑
23. © 2024 Loglass Inc. 23 01 | データ増大による問題 ソフトウェア構造体における概念上の複雑性の大半は、 アプリケーションそのものの自由さがもたらす複雑性 からきている “ Frederick P. Brooks, JR. 著, 滝沢徹, 牧野祐子, 富澤昇 訳. 『人月の神話』, 第17章. 丸善出版 （2014）
24. © 2024 Loglass Inc. 24 01 | データ増大による問題 パフォーマンス問題 パフォーマンスが劣化すると、さまざまな問題につながりやすい • DB・CPU負荷の増大 ◦ → インフラコスト増大、リクエストが詰まりやすい状態を誘発 • タイムアウトによるユーザーリクエストの失敗 ◦ → ユーザーへの業務影響、機会損失 • マテリアライズド・ビューの更新遅延 ◦ → データ不整合 • パフォーマンスチューニングの工数増加 ◦ → 開発が遅くなる
25. © 2024 Loglass Inc. 25 問題が起きてから対処しては遅い
26. © 2024 Loglass Inc. 26 01 | データ増大による問題 パフォーマンスの検討に早すぎるということはない “ 最大の理由は、どのような変更を加えた時にパフォーマンスが急降下し たかがわかることです。これならパフォーマンス問題に直面した時に、 アーキテクチャー全体を相手にせず、最近に加えた変更に焦点を絞り 込んでいけるのです。 Rebecca Parsons 編 (2009). ソフトウェアアーキテクトが知るべき97のこと- 第13章. オライリー・ジャパン.
27. © 2024 Loglass Inc. 27 01 | データ増大による問題 スケールを成功させるためには洗練されたアーキテクチャが必要 “ ソフトウェア・システムの規模が大きく、複雑であればあるほど、成功の ためにはよく練られたアーキテクチャが必要になる 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.
28. © 2024 Loglass Inc. 28 継続的アーキテクチャ
29. © 2024 Loglass Inc. 29 パフォーマンスを検討するといっても、 デリバリが遅くなってはいけないのでは？
30. © 2024 Loglass Inc. 30 開発速度をキープしつつ、 スケールしていきたい
31. © 2024 Loglass Inc. 31 そこで
32. © 2024 Loglass Inc. 32 データスケールを考慮した 継続的アーキテクチャ
33. © 2024 Loglass Inc. 33 Murat Erder (2015). Continuous Architecture: Sustainable Architecture in an Agile and Cloud-Centric World. Morgan Kaufmann.
34. © 2024 Loglass Inc. 34 02 | 継続的アーキテクチャ 継続的アーキテクチャの原則 参考：Murat Erder (2015). Continuous Architecture: Sustainable Architecture in an Agile and Cloud-Centric World. Morgan Kaufmann. 1. プロジェクトではなく、プロダクトを設計 2. 機能要件ではなく、品質属性にフォーカス 3. 必要になるまで、設計の決定を遅らせる 4. 変化のために設計する — “小さな力 "を活用する 5. ビルド、テスト、デプロイのための設計 6. システムの設計後に組織をモデル化 顧客に集中する 品質属性の要件がアーキテク チャを推進 使われない無駄を避ける 小規模で疎結合に 継続的デリバリーも考慮 チームの編成方法がアーキテ クチャと設計を駆動する
35. © 2024 Loglass Inc. 35 02 | 継続的アーキテクチャ 継続的アーキテクチャの主要な活動 • 品質属性を計測し、フィードバックループをまわす • 技術的負債を管理する Murat Erder Pierre Pureur, Eoin Woods (2021). Continuous Architecture in Practice:Software Architecture in the Age of Agility and DevOps. Addison-Wesley Professional.
36. © 2024 Loglass Inc. 36 非機能要件と 品質属性と 品質属性シナリオ
37. © 2024 Loglass Inc. 37 03 | 非機能要件、品質属性と品質属性シナリオ 機能要件と非機能要件 機能要件 非機能要件 概要 システムが提供する必要のあ るビジネス機能と実行時の動 作を説明したもの システムが機能要件を実現する ために満たす必要のある品質に ついて説明したもの 目的 プロダクトが何をするか プロダクトがどのように動くか どの程度提供するか フォーカス ユーザー課題 動作や機能 ユーザー期待 品質、性能、制約等 最終結果 プロダクトのフィーチャー プロダクトの性質 特徴 認識しやすい 認識しづらい
38. © 2024 Loglass Inc. 38 03 | 非機能要件、品質属性と品質属性シナリオ ソフトウェアの品質特性 システム/ソフトウェア製品品質 機能連合性 性能効率性 交互性 使用性 信頼性 セキュリティ 保守性 移植性 ・適応性 ・設置性 ・置換性 ・モジュール性 ・再利用性 ・解析性 ・修正性 ・試験性 ・機密性 ・インテグリティ ・否認防止性 ・責任追跡性 ・真正性 ・成熟性 ・可用性 ・障害許容性（耐 故障性） ・回復性 ・適切度認識性 ・習得性 ・運用操作性 ・ユーザエラー 防止性 ・ユーザインタ フェース快美性 ・アクセシビリ ティ ・共存性 ・相互運用性 ・時間効率性 ・資源効率性 ・容量満足性 ・機能安全性 ・機能正確性 ・機能適切性 品質特性 品質副特性 システム‧ソフトウェア製品の品質モデル（JIS X 25010:2013（IEC25010：2011）に基づく）
39. © 2024 Loglass Inc. 39 03 | 非機能要件、品質属性と品質属性シナリオ 品質特性、品質副次特性、品質属性 Bevan, Nigel & Azuma, Motoei. (1997). Quality in Use: Incorporating Human Factors into the Software Engineering Lifecycle. Software Engineering Standards, International Symposium on. 169. 10.1109/SESS.1997.595963. 内部品質 外部品質 品質特性 品質副特性 品質属性
40. © 2024 Loglass Inc. 40 03 | 非機能要件、品質属性と品質属性シナリオ 品質属性（Quarity Attributes） • 品質属性＝品質特性を細分化した末端 ◦ 性能→時間効率→レスポンスタイム、スループット等 • 測定可能、テスト可能 • 品質属性要件はアーキテクチャと相互に影響しあう • 品質属性間にトレードオフがある ◦ 例：セキュリティを高めるとユーザビリティが低下する 品質属性がアーキテクチャの肝
41. © 2024 Loglass Inc. 41 品質属性からアーキテクチャへ
42. © 2024 Loglass Inc. 42 03 | 非機能要件、品質属性と品質属性シナリオ 品質属性シナリオ（Quality Attribute Scenario） • 非機能要件を具体的で計測可能な形で記述する方法 • 品質属性を正確に捉え、設計の判断基準に活用する 書籍によっては「品質 特性シナリオ」と訳され ることもあるがquality characteristic と混同す るので、ここでは「属性」に統一
43. © 2024 Loglass Inc. 43 03 | 非機能要件、品質属性と品質属性シナリオ 品質属性シナリオ（Quality Attribute Scenario） ソース 刺激を引き起こした要因や主体 刺激 システムに何かしらの影響を与える 外部または内部の出来事 環境 シナリオが発生する状況や 条件 測定 応答が成功したかどうかを評 価するための具体的な基準 応答 刺激に対してシステムが取 るべき行動や結果 アーティファクト 刺激を受ける対象となるシステムやコ ンポーネント Murat Erder Pierre Pureur, Eoin Woods (2021). Continuous Architecture in Practice:Software Architecture in the Age of Agility and DevOps. Addison-Wesley Professional.
44. © 2024 Loglass Inc. 44 03 | 非機能要件、品質属性と品質属性シナリオ 品質属性シナリオの例 項目 内容 ソース ユーザ操作 刺激 集計・レポート機能をリクエストする アーティファクト 集計データベース 環境 データ量XXX件、条件XXX レスポンス 集計されたレポートを返す 測定 ・集計レポート生成が完了するまでの応答時間が5秒以内であること ・CPU使用率が70%を超えないこと ・メモリ使用量がXGBを超えないこと 実際には同時実行数や 分間リクエスト等の状況も盛り込む
45. © 2024 Loglass Inc. 45 非機能要件の直交性をあげる
46. © 2024 Loglass Inc. 46 04 | 非機能要件の直交性をあげる 非機能要件の直交性をあげる • 複雑性が増すとフィーチャーを作るのが大変になる • 非機能は横断的に関わる（Cross Functional） • 複雑さと横断事項の掛け算で、アーキテクチャの実現が困難になる 機能A 機能B 機能C 機能D 非機能要件
47. © 2024 Loglass Inc. 47 04 | 非機能要件の直交性をあげる 直交性（Orthogonality） • システムの要素が独立性を保ち、互いに干渉しないこと、またはその度合い • 例： ◦ テーブル設計が正規化されており、1つのテーブルを修正しても、他の テーブルには影響を及ぼさない ◦ ボタンの見た目（デザイン）と機能（イベントハンドラ）が独立している 　　　　　　　　 直交性が高いと、変更に強く、複雑性が低くなる
48. © 2024 Loglass Inc. 48 04 | 非機能要件の直交性をあげる 非機能要件の直交性をあげる • 複雑性が増すとフィーチャーを作るのが大変になる • 非機能は横断的に関わる（Cross Functional） • 複雑さと横断事項の掛け算で、アーキテクチャの実現が困難になる 機能A 機能B 機能C 機能D 非機能要件
49. © 2024 Loglass Inc. 49 複雑性の分離とアーキテクチャ量子
50. © 2024 Loglass Inc. 50 05 | 複雑性の分離とアーキテクチャ量子 オニオンアーキテクチャ Presentation層 Infrastructure層 UseCase層 Domain層 Repository（実装クラス） ・Entityの永続化/検索 Repository (Interface) ・Repositoryの仕様定義 Entity, Value Object, Domain Service ・ドメイン知識（ルール/制約） の表現 Controller ・エンドポイント定義 ・HttpRequestで渡された値とUseCase層に 渡す値のマッピング ・入力値のValidation UseCase ・ユースケースの実現 ・Entity, Value Objectの 生成、使用、永続化依頼 ・EntityからPresentation層に渡す値への変換
51. © 2024 Loglass Inc. 51 05 | 複雑性の分離とアーキテクチャ量子 オニオンアーキテクチャ Presentation層 Infrastructure層 Application層 Domain層 UI Application Domain Infrastructure 依存性が反転 している
52. © 2024 Loglass Inc. 52 05 | 複雑性の分離とアーキテクチャ量子 オニオンアーキテクチャ Presentation層 Infrastructure層 Application層 Domain層 UI Application Domain Infrastructure コア ノンコア パフォーマンス問題がある箇所（クエリ）をノン コアとして切り出し
53. © 2024 Loglass Inc. 53 これだけでは層を分離しただけ 層内の影響も分離できるようにしたい
54. © 2024 Loglass Inc. 54 05 | 複雑性の分離とアーキテクチャ量子 Port and Adapters パターン Application adapters クエリ サービス REST 外部 サービス ストリーム Publisher パフォーマンスが不安定に なりやすいため、 独立して進化させたい
55. © 2024 Loglass Inc. 55 05 | 複雑性の分離とアーキテクチャ量子 アーキテクチャ量子（Architecture Quantum） 自己完結した独立して展開可能なユニット 量子内のコードが目的に沿って統一されている（凝集性が高い） “ アーキテクチャ量子は、システムが適切に機能するために必要なすべての構造要素を含む、 高い機能的結合性を備えた独立して展開可能なコンポーネントです An architectural quantum is an independently deployable component with high functional cohesion, which includes all the structural elements required for the system to function properly Neal Ford, Rebecca Parsons, Patrick Kua, Pramod Sadalage (2022). “Building Evolutionary Architectures: Automated Software” 2nd Edition. O’Reilly Media.
56. © 2024 Loglass Inc. 56 05 | 複雑性の分離とアーキテクチャ量子 コナーセンス（connascence） 2つ以上の要素がどれだけ密接に関連し、変更に伴って影響を及ぼし合うかを表す概念 種類 内容 例 名前のコナーセンス 要素が名前で関連づけられている メソッド名の修正 型のコナーセンス 要素が型で関連づけられている 関数の引数の型を修正すると、呼び出 し側も修正 順序のコナーセンス 要素が順序に依存している 引数の順番を入れ替えると、呼び出し 側も修正 同期的なコナーセンス 要素が時間的に連携して動作する必要がある依存 関係 サービスAがサービスBにAPIリクエス トし、レスポンスを待つ 独立したアーティファクトの塊を考 えるときにコナーセンスを意識する
57. © 2024 Loglass Inc. 57 05 | 複雑性の分離とアーキテクチャ量子 Port and Adapters パターン Application adapters クエリ サービス REST 外部 サービス ストリーム Publisher 集計 サービス データ セット 独立進化させたい領域を単独 ユニットとして量子化する リスコフの置換原則（LSP） 集計・レポート量子
58. © 2024 Loglass Inc. 58 05 | 複雑性の分離とアーキテクチャ量子 量子化するメリット • 品質属性シナリオの独立性が高まる • テストしやすくなる • 独立進化させやすい ◦ 技術基盤の刷新や検証がしやすい ◦ 一般に、データベースを変更するのは大事だが、影響が局所化されてい ればそうでもない
59. © 2024 Loglass Inc. 59 05 | 複雑性の分離とアーキテクチャ量子 非機能品質を作り込む Application adapters クエリ サービス REST 外部 サービス ストリーム Publisher 集計 サービス データ セット 集計・レポート量子 品質属性から アーキテクチャ改善 品質属性シナリオで要件、品質基準を 明確にする （アーキテクチャの形をあぶり出す） 直交性をあげ、独立 進化可能にする シナリオの独立性が高まる （検証・アーキテクチャ判断しやすい）
60. © 2024 Loglass Inc. 60 まとめ
61. © 2024 Loglass Inc. 61 06 | まとめ まとめ • 非機能要件は影響が広範囲になりやすい • 品質属性シナリオを明確化することで、アーキテクチャの形がみえてくる • 複雑性をコントロールし、直交性を高めることで、アーキテクチャ量子化できる • 量子化されると独立進化させられるため、中長期的に技術開発をしながらケイ パビリティをアップグレードできる • 非機能品質を作り込める状態になる
62. © 2024 Loglass Inc. 62 一緒にプロダクト開発の次元をあげていきたい、良い景気づくりにご興味 のある方を絶賛募集しています！！ https://job.loglass.jp/ カジュアル面談 Welcomeです！ We are Hiring! X: @_knih ご質問や雑談・ 相談はこちら
63. © 2024 Loglass Inc. 63