この記事の説明

アーキテクト同士の会話で出現するキーワードとその意味を集めました。例）結合（動的、静的）、アーキテクチャ量子、通信方式など

アーキテクチャ用語集

参考記事

本記事は以下の二冊をもとに作成しています。アーキテクトを目指す人に対しておすすめの二冊です。

気になった方はこのページから購入していただけると自分に少しお小遣いが入るので差し入れとしてお願いいたします！

アーキテクチャ用語集

コンポーネント

アプリケーション内部で何らかのビジネスロジックや基盤機能を持つ、アーキテクチャの構成要素

パッケージ構造
名前空間
ディレクトリ構造
サービス

など言語やスケールによって変化する。

サービス

分散アーキテクチャ、特にマイクロサービスアーキテクチャで頻繁に使われるキーワード。独立して実行できるものとしてデプロイされる機能のまとまりを表す。

結合

あるコンポーネントで機能を維持するためにほかのコンポーネントの稼働が必要となる状態。依存ともいう。

依存、結合が発生していない例としては、

パイプラインアーキテクチャのフィルター（あるフィルターはデータを受け取った後、そのフィルターに設定されたルールでデータの変更を行い、次のフィルターに渡しているだけ）
イベント駆動アーキテクチャのブローカータイプ（一つ一つのコンポーネントはあるイベントが発生した後、そのイベントにまつわる処理を実行し再度イベントを発火するが、コンポーネントは次のイベントがどんな状態で受け渡されるか考える必要はなく、イベントは誰も興味を持たなくなるまで存続するため）

また、結合には二種類存在し、それが静的結合と動的結合である。

静的結合

何も実行していない時に、どのようにつながるかを説明するもの

マイクロサービスアーキテクチャ内部に存在するビジネスロジックを含むコードとデータベースは静的結合している。

動的結合

サービス実行時にお互いがどのような通信方式でつながるか説明するもの

マイクロサービスが他のサービスをAPIで呼び出す場合はマイクロサービスである。

結合を取り巻くトレードオフ

アーキテクチャの基本的な考え方の一つに、「疎結合の考え方に従うべきだ」という文言がある。

しかし、その文言に従うと、「全てが分離され、他と通信できるものが何も無くなっている状態が望ましい」ということになる。その状態ではソフトウェアを作ることは難しいだろう。

結合のトレードオフは厄介な問題

アーキテクトが直面する困難な課題の一つは、分散アーキテクチャに作用する力を分解し、トレードオフを分析することだ。分散アーキテクチャに作用する力を分析するためには、アーキテクチャを分解することが一番である。

しかし、価値あるシステムを構築しつつ、分離をどのように達成するかの手引きは私たちには与えられていない。

トレードオフの分析手法

問題が複雑に絡み合った状態で事象を暗記しながら対応するのは難しい。そこでまず最初に行うべきことは、システムの分解である。

どの部分がお互いに絡み合っているかを見つける:結合を見つける
それらがどのように作用しているかを分析する:結合を分析する
変更時にどのような影響が出るか見極める:結合をシミレーションする

アーキテクチャ量子

アーキテクチャ量子は、「部品がどのように接続されて互いに通信するか」を評価するための基準である。

主に三つあり

独立してデプロイ可能
高度な機能的凝縮
高度な静的結合

を満たす単位をアーキテクチャ量子と言う。これらのアーキテクチャ量子が互いに同期/非同期で通信することで一つの巨大なサービスを生み出すこともある。

アーキテクチャ量子が増える際のメリットとして

片方のサービスがダウンしても、別のサービスは稼働させ続けることのできる耐久性
高度に分離したサービスは開発者が依存関係を考慮せずに開発できる。

などがある。

逆にアーキテクチャ量子が減る際のメリットとして

結合の数自体は少なくなる。
非同期通信などの不安定な要素に頼る部分が減る。

アーキテクチャ量子が重要な理由

アーキテクチャ量子として表される境界線は、アーキテクト、運用T、開発T(企画開発T)で共通言語として機能するからだ。

例えば「独立してデプロイ可能」と言うキーワードは運用Tにとって大きな関心ごととなるが、「高度な機能的凝縮」と言うキーワードは開発Tにとっての大きな関心ごととなる。

アーキテクトはサービスごとの量子を明確に分けたり、分けれなくても役割分担の指標として活用できる。

また、過去のサービスと共通の言語で照らし合わせることで、過去の事例をベストプラクティスとして活用できる。

独立してデプロイ可能

ビルド可能な単位を表す。

例えば一般的なWebサービスにて、バックエンドとフロントエンドを別のサーバーで立てており、バックエンドのAPIをフロントエンドが呼び出している場合はビルド可能な単位は二つになる。

また、モノシリックなサービス（VscodeやEclipseなど）は単一のユニットとしてデプロイされる。

マイクロサービスアーキテクチャでは、それぞれのサービスは独立してデプロイされる傾向があり、「独立してデプロイ可能」と言う観点ではマクロサービスアーキテクチャは二つ以上の量子となる。

高度な機能的凝縮

特定の事業のワークフローを実行するデータと振る舞いのこと。

他のアーキテクチャ量子を表す言葉よりは明確な基準はない。

理想的には、マイクロサービスアーキテクチャの各サービスはある一つの事業をモデル化したものであり、高度な機能的凝縮を持つと言える。

高度な静的結合

高度な静的結合とはアーキテクチャ量子内部の要素が密に結び付けられていることを表す。

例えば、モノシリックなアーキテクチャは必ず量子数が一になる。

サービスベースアーキテクチャの量子数

また、たとえ分散アーキテクチャを使用しているとしても、すべてのコンポーネントが単一のデータベースシステムに依存している場合でも量子数が一になる。

たとえば、サービスベースアーキテクチャは単一のデータベースに依存するため量子数は一だ

イベント駆動アーキテクチャの量子数

また、イベント駆動アーキテクチャのメディエータータイプも単一のデータベースに依存するため、量子数は一になる。

仮に、イベント駆動アーキテクチャとほとんど別のシステムとして別のイベント駆動アーキテクチャが存在する場合は、当然量子数は2になる｡また、イベント駆動アーキテクチャ同士が非同期通信で繋がっていたとしても、単一のサービスに依存するわけではなく、片方のサービスがダウンしても動いているととらえられるので量子数は2になる。

マイクロサービスアーキテクチャの量子数

マイクロサービスアーキテクチャでは一つのサービスにデータとビジネスロジックコードが含まれるため、お互いに静的な結合は発生しない。（ＡＰＩによる動的な結合は発生するかもしれないが）

ただし、サービスを提供する際に必ずAPI層を経由しなければならない際には、API層での結合が発生するため、量子数は1になる。

この場合、API層での何らかの致命的なトラブルが発生した場合、サービスすべてが利用不可能になる。（したがって、API層での結合を考慮しない場合は量子数は1以上になる）

上記の内容はユーザーインターフェースでも置き換えられる。

動的な量子結合

アーキテクチャ量子の最後の定義は、実行時の結合の有無である。

動的な量子結合を網羅するとすれば、簡単に言えば次の三つの組み合わせで表せる。

通信:使用する通信方式。
- 同期通信：結合度が高くなる
- 非同期通信：結合度が低くなる
調整:サービス間の協調方法
- コレオグラフィ：結合度が高くなる
- オーケストレーション：結合度が低くなる
整合性:サービス間のデータの一貫性
- アトミック：結合度が高くなる
- 結果整合性：結合度が低くなる

結果整合性とは？

簡単に言えば「一時的にデータベースAとデータベースBの値が違ってもよい」という考え方のことである。

データベースAである商品の値段が-100円される処理が発生したとする。
データベースBではまだ-100円されていないが、その処理をデータレプリケーションエンジンで複製しようとしたとして
その処理が障害等で行われなかった場合、
この状態では結果整合性を取れていない。
データベースAがデータベースBの障害を受けてロールバックしてはじめて、
結果整合性が取れる。