🏗️
入門ソフトウェアアーキテクチャ4種
TLDR
- 4種のSWアーキテクチャの紹介
- アーキテクチャはトレードオフ 。必ずメリット・デメリットが存在する
| アーキテクチャ名 | 概要 | メリット | デメリット | 変更容易性 | デプロイ容易性 | テスト容易性 | パフォーマンス | スケーラビリティ | 開発容易性 |
|---|---|---|---|---|---|---|---|---|---|
| 階層型アーキテクチャ | OSI参照モデルのように階層式にアクセスする構造 | 隣接層どうし以外は基本疎結合にできる | データをバイパスすると簡単に疎結合が崩れる（sinkhole anti-pattern） | ✖ | ✖ | 🔵 | ✖ | ✖ | 🔵 |
| イベント駆動型アーキテクチャ | メディエーターもしくはリレー構成（ブローカー）により非同期アーキテクチャを実現 | モジュールを疎結合に保ち大規模アプリケーションを実現可能 | 比較的複雑。 一般の分散アーキテクチャに起こる問題が発生 |
🔵 | 🔵 | ✖ | 🔵 | 🔵 | ✖ |
| マイクロカーネルアーキテクチャ | パッケージ形式のアプリケーション向き | - 独立したプラグインを自由に追加/削除可能 - このアキテクチャ自体をほかのアーキテクチャに組込み能 |
● 単一マシンでの稼働が前提 ● プラグイン―カーネル間のコントラクトをしっかり定義しておく必要あり |
🔵 | 🔵 | 🔵 | 🔵 | ✖ | ✖ |
| マイクロサービスアーキテクチャ | 一番重要。階層化アーキテクチャ／SOAから発展 | SOA等の課題を解決 | ● コンポーネントの粒度決定が難しい ● DRY原則違反が起こりがち |
🔵 | 🔵 | 🔵 | ✖ | 🔵 | 🔵 |
始めに
本記事ではソフトウェアアーキテクチャ本「Software Architecture Patterns」をもとにソフトウェアアーキテクチャの基本を紹介します。この本はオライリーサブスクで読めます。本記事は以前にQiita投稿した記事の再構成です。
| 原題 | 「Software Architecture Patterns」 |
| リリース年月 | 2015/02 |
| カテゴリ | ソフトウェアアーキテクチャ |
| お勧め度（5段階） | ⭐⭐⭐⭐⭐ |
| 対象者 | ソフトウェアアーキテクチャ初心者 |
- 50ページ程度の小冊子に代表的なアーキテクチャパターン5種が紹介されています
- 階層化アーキテクチャ
- イベント駆動型アーキテクチャ
- マイクロカーネルアーキテクチャ
- マイクロサービスアーキテクチャ
- スペースベースのアーキテクチャ（Space-based Architecture)
- 本書ではこのアーキテクチャは扱いません
アーキテクチャの紹介
1. 階層化アーキテクチャ（Layered Architecture）
概要
- 基本のアーキテクチャ（迷った時はまずこのアーキテクチャから開始して、後から別のアーキテクチャにするのも良い）
- 一般的には下記4層で構成される
- プレゼンテーション層
- ビジネス層
- 永続化層
- データベース層
- 【構成】
利点
- 隣接する層どうし以外は（基本）互いに疎（結合度の低い設計が可能）
- 実装が用意
欠点
- 基本はモノリシックシステムかつ小規模向け
- 「陥没穴アンチパターン（sinkhole anti-pattern)」に容易になりえる
- 前段の層から渡されたデータをバイパスして次の層にそのまま渡す等の処理を入れてしまうと、離れた層どうしが結合状態になってしまう
2. イベント駆動型アーキテクチャ
概要
- イベントをキューもしくはメッセージトピックを介してやりとりするアーキテクチャ
- 実装形態として中央管理機構（メディエーター)が存在する「メディエータートポロジー」と数珠つなぎで処理を実行する「ブローカトポロジー」の2種が存在する
メディエータートポロジ
- ある程度のオーケストレーションを必要とするアプリケーション向け
- 中央管理処理コンポーネントであるイベントメディエーターがオーケストレーションの役割を担い、各イベントプロセッサーにイベントの受け渡しを行う。イベントプロセッサー内には複数のモジュールがあり、要求された処理を実行する
- 全体の処理はメディエーターに初期イベントが投げられてから開始する
ブローカトポロジ
― メディエーターがおらず、各イベントプロセッサーが処理が終わったら次のキューにイベントを渡して 数珠つなぎ で処理がハンドリングされる
- 細かい制御が不要なアプリケーション向け
利点
- スケーラブル（大規模アプリケーションにも対応可能）
欠点
- トランザクションがビジネスプロセス単位に閉じていない
- イベントプロセッサーが細かく分けられているため、複数のトランザクションが混ざり合ってしまう（分離が必要な際に手間がかかる）
- イベントプロセッサーのコントラクト（入出力形式仕様）の管理がたいへん
- 例：コントラクトのバージョン変更をする際に複数のバージョンに整合性をどうとるかが難しい
3. マイクロカーネルアーキテクチャ
概要
- パッケージ（製品）向けのアーキテクチャ
- 中央カーネルとそれにつながるプラグインの構成
- 重要なことは「プラグイン間の通信を行わない（結合度を下げる）」「コントラクトをしっかり決めておく」
利点
- 他のアーキテクチャの一部として本アーキテクチャを組み込める
- 段階的な開発が可能
欠点
- モノリシックサービス向け（大規模アプリケーションの1サービス内に本アーキテクチャを埋め込む等の対応は可能）
4. マイクロサービスアーキテクチャ
概要
-
階層化アーキテクチャパターンを使用して開発されたモノリシックアプリケーションと、サービス指向アーキテクチャパターンを介して開発された分散アプリケーションの2つから進化した形のアーキテクチャ
-
サービス間の依存を極力排し、オーケストレーションを不要にすることで複雑なアプリケーションの実現に対応している
-
実装形態挟まざまあるが、代表的なものは以下の3種
1. API RESTベーストポロジ
- 各サービスにREST APIでアクセスする構成
- サービスの単位は非常に小さくする
- 小さな自己完結型Webサイトなどで使われている
2. アプリケーションRESTベーストポロジ
- サービスコンポーネントはAPI RESTベースよりも大きく粗い
- 1つのサービスコンポーネントが1つのビジネス機能に相当する粒度
- リクエストも複雑なデータをやりとりする
3. 集中型メッセージングトポロジ
- RESTの代わりにメッセージブローカ（AmazonMQ、RabbitMQ等）を使用する以外はRESTベースとポロジに似ている
- RESTと比べてキューイングのしくみが高度だったり、負荷分散／スケーリングの点で優位
利点
- サービスの追加・更新が容易
- オーケストレーション機能が不要
- どうしてもオーケストレーション機能が必要な場合はそもそもマイクロサービスアーキテクチャに適していないサービスの可能性がある
- サービスどうしが疎結合
- どうしてもサービス間通信が必要な場合、共有データベースを介して結合を避けることを検討する余地あり
欠点
- サービスコンポーネント粒度決定が難しい
- 細かすぎると従来の分散システム（SOA）の問題が発生してしまう
- 粗すぎるとマイクロサービスアーキテクチャの利点が損なわれる（モノリシックアーキテクチャに近付く）
- DRY原則違反しやすい
- 同じ機能が複数サービスに点在しがち
最後に
- 現在アーキテクチャ本「Fundamentals of Software Architecture」を読んでいるんですが、内容が濃くボリュームも多いのでなかなか読み進められていませんでした。そこにきて本記事の元となったオライリー・ジャパンポートはサクッとソフトウェアアーキテクチャの概要に触れることができて非常に助かりました。古いですが短くて初心者にお勧めのレポートです（「Software Architecture Patterns」（2015）)
オライリー・ジャパンブスクについて
オライリー・ジャパンサブスクO'Reilly「Learning Platform」では、オライリー・ジャパン書籍を初めに、約6万冊の書籍や動画等が読み放題です。話題になった技術書は半数以上は読める印象です。英書がメインなのがネックですが、ブラウザの翻訳機能を使えば問題なく読めます。個人的にこのサブスクで学習の質が劇的に改善したので、全然関係ない立場ですが勧めて回っています。
概要／使い方／価格などは 以前にまとめたこちらの記事 を参考にしてください
Discussion