今日学んだこと：アーキテクチャに関して2

概要

今日はアーキテクチャの種類について学んだ。

スペースベースアーキテクチャ

ほとんどのWebベースのビジネスアプリケーションは、いずれも一般的なリクエストフローに従っている。ブラウザからのリクエストは、Webサーバー、アプリケーションサーバー、データベースへと渡っていく。このパターンは、ユーザー数が少ない場合には効果的だが、ユーザー負荷が増加するとボトルネックが生じる。ユーザー負荷の増加に伴うボトルネックには、Webサーバーのスケールアウトで対応するのが一般的だ。これは比較的簡単で安価な方法であり、ボトルネックへの対応として適切な場合もある。しかし、ユーザー負荷が高い場合には、Webサーバーをスケールアウトしても、ボトルネックがアプリケーションサーバーに移動してしまうケースがほとんどだ。アプリケーションサーバーのスケーリングは、Webサーバーよりも複雑でコストがかかるし、通常はそれをしても、ボトルネックがデータベースサーバーに移るだけだ。

スペースベースアーキテクチャは、高いスケーラビリティ、弾力性、高い同時実行性といった問題に対処することを目的に設計されたアーキテクチャスタイルだ。このアーキテクチャスタイルは、同時接続ユーザー数が変動して予測できないようなアプリケーションにも有効だ。弾力的なスケーラビリティをアーキテクチャ的に解決することは、データベースをスケールアウトさせようとしたり、スケーラビリティのないアーキテクチャにキャッシュ技術を後付けしたりするよりも、良いアプローチであることが多い。

スペースベースアーキテクチャは、アプリケーションのトランザクション処理をする際にキャッシュに依存する。データベースへの直接の読み書きの必要性を排除することで、スペースベースアーキテクチャは高いスケーラビリティと弾力性、パフォーマンスを実現している。スペースベースアーキテクチャが依存するのは、主にレプリケーションキャッシュだが、分散キャッシュを使用することも可能だ。

コンサートチケット販売システムやオンラインオークションシステムで使用される。

オーケストレーション駆動サービス指向アーキテクチャ

アーキテクチャスタイルは、芸術運動と同様、その時代の文脈の中で理解されなければならない。そして、このアーキテクチャは他のどのアーキテクチャよりも、この法則をよく体現している。アーキテクチャ決定に影響を与えがちな外力と、論理的ではあるが最終的には害をなす組織哲学とが相まって、このアーキテクチャは無用の長物になってしまった。このアーキテクチャスタイルは、ある組織的な考え方が、理屈は通っているとしても、開発プロセスの最も重要な部分を妨げてしまうことがあるという好例を示している。

オーケストレーションエンジンは、この分散アーキテクチャの核を形成するものだ。トランザクションの調整やメッセージ変換などの機能を含むオーケストレーションを使用して、ビジネスサービスの実装をつなぎ合わせる。このアーキテクチャは通常、マイクロサービスアーキテクチャのようにサービスごとにデータベースを用意するのではなく、単一のリレーショナルデータベースか、または数個のデータベースに結びつけられる。したがって、トランザクションの動作は、データベースではなくオーケストレーションエンジンで宣言的に処理される。

オーケストレーションエンジンは、ビジネスサービスとエンタープライズサービスの関係、それらのマッピング方法、トランザクションの境界がどこにあるかを定義する。また、オーケストレーションエンジンは、カスタムコードをパッケージやレガシーソフトウェアシステムと統合するための統合ハブとしても機能する。

もしかすると、このアプローチが魅力的なものに聞こえたかもしれない。しかし、実際には、こうしたアプローチのほとんどが失敗に終わった。トランザクションの動作をオーケストレーションツールにオフロードすることは良いことのように聞こえるが、トランザクションの粒度を適切なレベルで見つけ出すのは、ずっと難しいものだった。分散トランザクションに包まれたサービス群の構築自体は可能だが、開発者はサービス間の適切なトランザクション境界がどこにあるのかを把握しなければならないため、アーキテクチャはますます複雑になってしまう。

マイクロサービスアーキテクチャ

マイクロサービスアーキテクチャは、近年非常に人気のあるアーキテクチャスタイルであり、その勢いは非常に高まっている。

マイクロサービスは、ソフトウェアプロジェクトの論理的設計プロセスであるDDD（ドメイン駆動設計）の考え方に大きく影響を受けている。DDDのコンセプトの一つである「境界づけられたコンテキスト（Bounded Context）」は、マイクロサービスに決定的な影響を与えた。境界づけられたコンテキストという概念は、分離のスタイルを表している。開発者がドメインを定義するとき、そのドメインには、多くのエンティティと振る舞いが含まれる。そして、それらはコードやデータベーススキーマといったアーティファクトによって識別される。

マイクロサービスの大きさは、その単一目的の性質のため、オーケストレーション駆動サービス指向アーキテクチャなどの他の分散アーキテクチャよりもずっと小さくなる。アーキテクトは、データベースやその他の依存コンポーネントを含め、各サービスが独立して動作するために必要なすべての部品を含むことを期待している。

マイクロサービスアーキテクチャは分離を推奨しているが、これはバックエンドだけに限った話ではない。理想的には、ユーザーインターフェイスも含めた分離が望まれる。実際、マイクロサービスの当初のビジョンでは、DDDの原則に忠実に、ユーザーインターフェイスも境界づけられたコンテキストの一部として含んでいた。しかし、Webアプリケーションで要求される分割の実用性や、その他の外部制約によって、その目標を達成するのが困難だったのだ。そのため、マイクロサービスアーキテクチャでは、一般に2つのスタイルのユーザーインターフェイスが登場する。

モノリシックなフロントエンドは、ユーザーのリクエストを満たすためにAPI層を介して呼び出す単一のユーザーインターフェイスを特徴とする。フロントエンドは、リッチデスクトップ、モバイル、Webアプリケーションのいずれかになる。たとえば、多くのWebアプリケーションは現在、JavaScriptフレームワークを使用して単一のユーザーインターフェイスを構築している。

ユーザーインターフェイス側のコンポーネントを用いて、バックエンドサービスと対応した粒度と分離をユーザーインターフェイスに持たせている。各サービスは、自サービス用のユーザーインターフェイスを提供し、フロントエンドはそれぞれのサービスから提供されたUIコンポーネントを組み合わせて利用する。このパターンを使うことで、チームはユーザーインターフェイスからバックエンドサービスまでをサービス境界で分離でき、ドメイン全体を1つのチームに統一できる。

開発者は、ReactのようなコンポーネントベースのWebフレームワークを使用するか、このパターンをサポートするいくつかのオープンソースフレームワークを使用して、さまざまな方法でマイクロフロントエンドパターンを実装できる。