はじめに
こんにちは！テクノロジー本部ITE部の櫻田です。 この記事では、Findy社主催の「アーキテクチャConference 2024」に参加した際の学びと感想をお伝えします！特に印象に残ったNeal Fordさんの講演『Modern Trade-off Analysis for Distributed Architectures and Future Software Architecture』についてまとめています！また、こちらの記事はエムティーアイ - Qiita Advent Calendar 2024 - Qiitaの12月20日分の記事です。
イベント概要
開催情報
- 日時：2024/11/26(火)
- 場所：浜松町コンベンションホール＆Hybridスタジオ
- 資料：公式アーカイブ
📝 セッション内容：分散アーキテクチャにおける現代のトレードオフ分析
ソフトウェアアーキテクトとして直面する最も重要な課題の一つは、トレードオフ分析である。なぜなら、完璧な解決策はほとんど存在せず、常に何かを得るためには何かを犠牲にする必要があるからだ。
ソフトウェアアーキテクチャの普遍的な原則
ソフトウェアアーキテクチャには2つの普遍的な法則がある：
すべてはトレードオフである
- 完璧な解決策はほとんど存在しない
- 各選択には必ず長所と短所がある
トレードオフは必ず存在する
- 一見トレードオフがないように見える選択でも、実は見落としているだけ。
- これは私たちが「ベストプラクティス」という考え方に慎重になるべき理由の一つ。
アーキテクチャと設計の境界線
トレードオフを考える際、まず理解すべき重要な区別がある。それは、アーキテクチャの決定と設計の決定の違いである：
- アーキテクチャの決定 は長期的で戦略的な影響を持ち、変更に多大なコストがかかる。
- 設計の決定 は比較的短期的で戦術的であり、変更も容易。
この区別を理解することで、どのレベルのトレードオフを検討すべきかが明確になる。
マイクロサービスにおけるトレードオフの実践
マイクロサービスアーキテクチャは、現代のソフトウェア開発で頻繁に採用されているが、サービスの分割と統合に関する重要なトレードオフが存在する。
分割を促す要因（Disintegrators）
機能による分割
- 例：通知システムの分割（SMS/メール/郵便）
- ただし、ドメインの結合度も考慮する必要がある
変更頻度による分割
- 変更の頻度が異なる部分は分離
- 例：法規制対応が必要な部分
負荷による分割
- 処理量の大きな差異への対応
- 例：SMS（22万件/分）vs メール（500件/分）vs 郵便（1件/分）
統合を促す要因（Integrators）
トランザクションの必要性
- サービス間トランザクションは避けるべき
- 必要な場合は統合を検討
データの依存関係
- 強い依存関係がある場合
- データの一貫性確保が重要な場合
アーキテクトの役割：バランスの取れた判断
これらのトレードオフを効果的に扱うため、アーキテクトには以下の役割が求められる：
客観的な分析の提供
- 特定の解決策の推奨者ではなく、トレードオフの明確な提示者として
ビジネスとの整合性確保
- 技術的な最適化だけでなく、ビジネス価値との整合性を重視
継続的な評価
- 環境の変化に応じた再評価
- フィードバックループの確立
👤 参加しての感想
このセッションで紹介された2つの原則は、アーキテクチャに限らず、世の中の様々な場面に当てはまる普遍的な考え方だと感じました。
Neal Fordさんの同様の講演は、ヨーロッパで開催されたDDDのイベントでも行われており、YouTubeで視聴可能です。興味のある方はぜひご覧ください。
Conference全体を通して、非常に充実した内容で、多くの学びがありました。様々なセッションが用意されており、アーキテクチャに関する最新の知見を得られる貴重な機会となりました。
