アプリケーション・アーキテクチャとは

アプリケーション・アーキテクチャは、アプリケーションの設計と構築に使用されるパターンと手法を記述したものです。アプリケーションを構築する際に従うべきロードマップとベストプラクティスが提供されるため、使用することでアプリケーションが適切に構造化されます。

ソフトウェアの設計パターンは、アプリケーションの構築に役立ちます。パターンとは、問題に対する反復可能なソリューションのことです。

複数のパターンを組み合わせて、より汎用性の高いアプリケーション・アーキテクチャを作成することもできます。アーキテクチャをすべて自作するのではなく、既存の設計パターンを使用できるので、機能が想定どおりに動作することも保証されます。

アプリケーション・アーキテクチャを構成するものとして、フロントエンドサービスとバックエンドサービスの両方があります。フロントエンド開発はアプリケーションのユーザーエクスペリエンスに関係し、バックエンド開発はアプリケーションを機能させるデータ、サービス、その他の既存のシステムへのアクセスを提供することに注力します。

アーキテクチャは、アプリケーションを構築するための出発点またはロードマップですが、アーキテクチャで規定されない実装については、選択する必要があります。たとえば、最初のステップは、アプリケーションを作成するプログラミング言語を選択することです。

ソフトウェア開発に使用されるプログラミング言語はたくさんあります。中には、モバイルアプリ向けの Swift、フロントエンド開発向けの JavaScript のように、特定のタイプのアプリケーション構築に特化して使用される言語があります。 

HTML と CSS で使用される JavaScript は、現在、Web アプリケーション開発でよく使用されるプログラミング言語の 1 つです。 

他の一般的なプログラミング言語には、Ruby、Python、Swift、TypeScript、Java、PHP、SQL などがあります。アプリケーションを構築する際に使用される言語は、アプリケーションのタイプ、利用可能な開発リソース、および要件によって異なります。 

歴史的に、アプリケーションは単一のコード単位として記述され、コンポーネントはすべて同じリソースとメモリ空間を共有していました。このアーキテクチャのスタイルは、モノリスと呼ばれます。

先進的なアプリケーション・アーキテクチャは、多くの場合、マイクロサービスとアプリケーション・プログラミング・インタフェース (API) を使用してサービスを接続する疎結合であり、クラウドネイティブ・アプリケーションの基盤を提供します。 

クラウドネイティブ開発では、新しいアプリケーションの構築を加速し、既存のアプリケーションを最適化して、プライベートクラウド、パブリッククラウド、ハイブリッドクラウド全体で一貫した開発と自動化された管理エクスペリエンスが提供されます。

新しいアプリケーションに使用するアプリケーション・アーキテクチャを決定する場合や、現在のアーキテクチャを評価する場合は、戦略的な目標を決定することから始めます。

すると、最初にアーキテクチャを選択してアプリケーションをその構造に適合させるのではなく、目標に対応するアーキテクチャを設計することができます。 

顧客や運用上のニーズを満たすためにどの程度の頻度で更新をリリースするべきか、そして、ビジネス目標の達成や開発ニーズの充足のためにどのような機能が必要なのかについて考えてみましょう。 

新しいサービスや機能を顧客に迅速に提供する能力は、企業にとって主要な競争上の差別化要因の 1 つです。また、開発が迅速になることで、企業は新機能をより頻繁にリリースし、脆弱性が発見された場合はすぐに更新を公開することができます。

アプリケーション・アーキテクチャにはさまざまなタイプがありますが、サービス間の関係に基づいて考えた場合に現在最も優れているのは、モノリスと多層アーキテクチャ (密結合)、マイクロサービス (分離)、イベント駆動型アーキテクチャとサービス指向アーキテクチャ (疎結合) です。

階層化または多層アーキテクチャは、オンプレミスおよびエンタープライズ・アプリケーションの構築によく使用される従来のアーキテクチャであり、しばしばレガシー・アプリケーションに関連付けられます。

階層化アーキテクチャでは、アプリケーションを構成するいくつかのレイヤーまたはティア (多くの場合は 3 つだがそれより多い場合もある) があり、それぞれに独自の役割があります。 

レイヤーは、依存関係の管理と論理関数の実行に役立ちます。階層化アーキテクチャのレイヤーは水平に配置されるため、呼び出せるのは下層のレイヤーだけです。 

直下のレイヤーに限定されていることもあれば、下層レイヤーの中の任意のレイヤーを呼び出せる場合もあります。 

レガシーシステムに関連するもう 1 つのアーキテクチャタイプであるモノリスは、その 1 つのアプリケーション内のすべての機能を包含する単一のアプリケーションスタックです。これは、サービス間の相互作用と、サービスの開発および配信方法の両方において、密結合されています。 

モノリシック・アプリケーションの 1 つの側面を更新または拡張すると、アプリケーション全体とその基盤となるインフラストラクチャに影響を与えます。 

アプリケーションコードを 1 カ所変更するだけで、アプリケーション全体を再リリースする必要が生じます。このため、更新や新しいリリースは通常、年に 1 回か 2 回のみで、新機能を提供するのではなく、一般的なメンテナンスが実施されるだけになります。 

対照的に、先進的なアーキテクチャでは、機能性やビジネス能力によってサービスを分割し、アジリティを高めようとします。

マイクロサービスは、 アーキテクチャであると同時に、ソフトウェア作成のアプローチでもあります。マイクロサービスでは、アプリケーションを互いから独立した最小単位のコンポーネントに分割します。それぞれのコンポーネント (つまりプロセス) が、マイクロサービスとなります。

マイクロサービスは分散されており、疎結合であるため、相互に影響を及ぼしません。これは、動的なスケーラビリティとフォールトトレランスの両方にとってメリットになります。個々のサービスは、重いインフラストラクチャを使用しなくても必要に応じて拡張でき、他のサービスに影響を与えることなくフェイルオーバーできます。

マイクロサービス・アーキテクチャを使用する目的は、高品質のソフトウェアをより迅速に提供することです。複数のマイクロサービスを同時に開発することができます。また、サービスは個別にデプロイされるため、変更が加えられる場合に、アプリケーション全体を再構築したり、再デプロイしたりする必要はありません。 

これにより、アプリケーション全体を更新するのではなく、個々のサービスに同時に取り組む開発者が増えるため、開発に費やされる時間を短縮し、新しい機能をより頻繁にリリースできるようになります。

API と DevOps チームに加えて、コンテナ化されたマイクロサービスもクラウドネイティブ・アプリケーションの基盤となります。

イベント駆動型システムでは、イベントのキャプチャ、通信、処理、永続性がソリューション構造の中核を担っています。これが従来の要求駆動型モデルとの違いです。

イベントは、システムのハードウェアまたはソフトウェアの状態における何らかの意味のある出来事または変化です。イベントのソースは、内部入力の場合も外部入力の場合もあります。

イベント駆動型アーキテクチャでは結合が最小限になるので、先進的な分散アプリケーション・アーキテクチャにとって効果的なオプションとなります。

イベント駆動型アーキテクチャは、イベントプロデューサーとイベントコンシューマーで構成されています。イベントプロデューサーはイベントを検出または感知し、イベントをメッセージとして表現します。イベントのコンシューマーやイベントの結果を知ることはありません。

検出されたイベントは、イベントプロデューサーからイベントチャネルを通じてイベントコンシューマーに送信され、イベント処理プラットフォームで非同期的に処理されます。

イベント駆動型アーキテクチャは、Pub/Sub モデルまたはイベント・ストリーム・モデルをベースにして構築できます。

pub/sub モデルは、イベントストリームへのサブスクリプションに基づいています。このモデルでは、イベントが発生したりパブリッシュされたりすると、通知を受ける必要があるサブスクライバーに送信されます。

これは、イベント・ストリーミング・モデル (イベントコンシューマーがイベントストリームをサブスクライブしない) とは異なります。ストリームの任意の部分から読み取って、いつでもストリームに参加できます。

IoT (モノのインターネット) デバイス、アプリケーション、ネットワークなどのイベントソースで発生したイベントはすぐにキャプチャされ、ステータスと応答情報はイベントプロデューサーとイベントコンシューマー間でリアルタイムで共有されます。

サービス指向アーキテクチャ (SOA) は、定評のあるソフトウェア設計スタイルで、マイクロサービス・アーキテクチャのスタイルに類似しています。 

SOA は、エンタープライズ・サービス・バス (ESB) を介してやり取りする、個別の再利用可能なサービスの集合としてアプリケーションを構築する手法です。 

このアーキテクチャでは、特定のビジネスプロセスを中心に編成された個々のサービスが、SOAP、ActiveMQ、Apache Thrift などの通信プロトコルに準拠し、ESB のプラットフォームを介して公開されます。つまり、ESB を介して統合されたこのサービススイートは、フロントエンド・アプリケーションによって使用され、企業や顧客に価値を提供します。

Red Hat のソリューションは、モノリシック・アプリケーションをマイクロサービスに分割して管理、調整し、マイクロサービスで作成されたデータを処理することでビジネスのアジリティを向上させ、チームが顧客に対してより迅速に高品質のソリューションを提供できるよう支援します。  

新しいビジネスアプリケーションを作成するとき、将来を念頭に置いて作業できるようになります。アジャイルで拡張が容易なクラウドネイティブ・アプリケーションを構築し、他のビジネスとはじめから統合できるようになります。

この Web セミナーシリーズでは、Red Hat® OpenShift® 上のエンタープライズ向けデータプラットフォームでアプリケーションの構築、実行、デプロイ、モダナイズを行う方法に関する専門家の視点を学ぶことができます。

既存システム全体をオーバーホールしなくても、有益なメリットを得られます。オープンソース、オープンスタンダード、そして長年の経験から、貴社に最適なマイクロサービスベースのソリューションを見つけ出します。

Red Hat® Enterprise Linux®、Red Hat OpenShift および Red Hat Application Services を含むオープンソース・ポートフォリオを取り揃えた Red Hat は、急速に変化するソフトウェア駆動の市場で競争するために変革が必要な企業にとって、唯一無二のパートナーです。