4-2 アーキテクチャ設計
Architecture Design
1. ソフトウェアアーキテクチャとは
1.1 アーキテクチャの定義
ソフトウェアアーキテクチャとは、システムの基本的な構造であり、 コンポーネント、コンポーネント間の関係、そしてそれらの設計・進化を 導く原則で構成される。ISO/IEC/IEEE 42010では「システムの基本的な 概念または特性を、その要素、関係、設計・進化の原則で具体化したもの」 と定義されている。
1.2 アーキテクチャの重要性
アーキテクチャはシステム全体の品質に大きな影響を与える。
| 観点 | アーキテクチャの影響 |
|---|---|
| 品質特性 | 性能、可用性、セキュリティなどの実現方法を決定 |
| 開発体制 | チーム分割、並行開発の可能性を左右 |
| 技術選定 | 使用する技術スタック、フレームワークの選択 |
| コスト | 開発・運用コストに大きく影響 |
| リスク | 技術的リスクの識別と対策 |
アーキテクチャの変更は、システム全体に影響する大規模な作業になる。 初期段階での適切なアーキテクチャ選択が、プロジェクトの成否を左右する。 ただし、「完璧な設計」を追求しすぎて分析麻痺に陥らないことも重要である。
2. アーキテクチャパターン
2.1 レイヤードアーキテクチャ
システムを複数の層（レイヤー）に分割するパターン。 最も一般的なアーキテクチャパターンの1つである。
| レイヤー | 責務 | 例 |
|---|---|---|
| プレゼンテーション層 | ユーザーインターフェース | 画面、API |
| ビジネスロジック層 | 業務ルール、処理ロジック | サービス、ドメインモデル |
| データアクセス層 | データの永続化 | DAO、リポジトリ |
| データベース層 | データ保存 | RDBMS、NoSQL |
2.2 MVCパターン
Model-View-Controllerの3つのコンポーネントに分離するパターン。 Webアプリケーションで広く採用されている。
| コンポーネント | 責務 |
|---|---|
| Model | データとビジネスロジック |
| View | ユーザーへの表示 |
| Controller | ユーザー入力の処理、ModelとViewの調整 |
2.3 マイクロサービスアーキテクチャ
システムを小さな独立したサービスの集合として構築するパターン。 各サービスは独立してデプロイ・スケール可能である。
| 特性 | モノリシック | マイクロサービス |
|---|---|---|
| 構造 | 単一のアプリケーション | 複数の小さなサービス |
| デプロイ | 全体を一括デプロイ | サービス単位でデプロイ |
| スケーリング | 全体をスケール | 必要なサービスのみスケール |
| 技術選択 | 統一された技術スタック | サービスごとに最適な技術を選択可能 |
| 複雑性 | コード内の複雑性 | 運用・インフラの複雑性 |
| 適用 | 中小規模システム | 大規模、高頻度デプロイ |
マイクロサービスは万能ではない。運用の複雑性、分散システムの難しさ、 チーム体制との適合など、多くの考慮事項がある。 「モノリスファースト」の考え方で、まずモノリシックに構築し、 必要に応じてサービス分割していくアプローチも有効である。
2.4 イベント駆動アーキテクチャ
イベント（状態変化の通知）を中心にシステムを構築するパターン。 疎結合で拡張性の高いシステムを実現できる。
| コンポーネント | 役割 |
|---|---|
| イベントプロデューサー | イベントを発生させる |
| イベントブローカー | イベントの仲介・配信 |
| イベントコンシューマー | イベントを受信して処理 |
3. クラウドアーキテクチャ
3.1 クラウドネイティブの原則
クラウドネイティブアプリケーションは、クラウドの特性を 最大限に活用するよう設計される。
| 原則 | 説明 |
|---|---|
| コンテナ化 | アプリケーションをコンテナとしてパッケージング |
| 動的オーケストレーション | Kubernetesなどによる自動管理 |
| マイクロサービス | 小さな独立したサービスの集合 |
| 宣言的API | 望ましい状態を宣言的に定義 |
3.2 Twelve-Factor App
Herokuが提唱したSaaS開発のベストプラクティス。 クラウドネイティブアプリケーションの設計指針として広く参照される。
| Factor | 説明 |
|---|---|
| 1. コードベース | バージョン管理される1つのコードベース |
| 2. 依存関係 | 依存関係を明示的に宣言 |
| 3. 設定 | 設定を環境変数に格納 |
| 4. バックエンドサービス | バックエンドサービスをリソースとして扱う |
| 5. ビルド、リリース、実行 | ビルド・リリース・実行を厳密に分離 |
| 6. プロセス | ステートレスなプロセスとして実行 |
| 7. ポートバインディング | ポートバインディングでサービスを公開 |
| 8. 並行性 | プロセスモデルでスケールアウト |
| 9. 廃棄容易性 | 高速な起動とグレースフルシャットダウン |
| 10. 開発/本番一致 | 開発・ステージング・本番を可能な限り一致 |
| 11. ログ | ログをイベントストリームとして扱う |
| 12. 管理プロセス | 管理タスクを1回限りのプロセスとして実行 |
4. アーキテクチャ設計のプロセス
4.1 アーキテクチャドライバー
アーキテクチャ設計は、以下のドライバー（駆動要因）に基づいて行われる。
| ドライバー | 例 |
|---|---|
| 機能要件 | 主要なユースケース、機能 |
| 品質属性 | 性能、可用性、セキュリティ、拡張性 |
| 制約 | 技術制約、予算、スケジュール、法規制 |
| 原則 | 組織の技術方針、標準 |
4.2 アーキテクチャ決定記録（ADR）
重要なアーキテクチャ決定は、ADR（Architecture Decision Record）として 文書化する。
| 項目 | 内容 |
|---|---|
| タイトル | 決定内容を簡潔に表現 |
| ステータス | 提案中、承認済み、廃止など |
| コンテキスト | 決定が必要になった背景 |
| 決定 | 何を決定したか |
| 選択肢 | 検討した代替案 |
| 結果 | この決定による影響、トレードオフ |
ADRの例
タイトル：認証にOAuth 2.0 + OpenID Connectを採用
コンテキスト：複数のクライアント（Web、モバイル）から
APIにアクセスする必要があり、外部IDプロバイダとの連携も求められている。
決定：認証基盤としてOAuth 2.0 + OpenID Connectを採用し、
KeycloakをIDプロバイダとして使用する。
結果：標準プロトコルにより外部連携が容易になる一方、
Keycloakの運用・保守が必要になる。
アーキテクチャ設計を学んだら、次は「4-3 データベース設計」で データの構造設計について学習しよう。
[1] Richards, M. (2015). Software Architecture Patterns.
[2] Newman, S. (2015). Building Microservices.
[3] Wiggins, A. (2017). The Twelve-Factor App.