デジタル時代のアプリケーション開発におけるアーキテクチャーの4つの選択肢

3層アプリケーション・アーキテクチャーについては誰もが知っています。これは、プレゼンテーション層、アプリケーション層、データベース層で構成される典型的な構造を備えたクライアント・サーバー・アーキテクチャーです。

ユーザー・インターフェース、ビジネス／データ・アクセス・ロジック、データ・アクセスを備えているものです。多くのエンタープライズ・アプリケーションは、単純な3層アプリケーション・アーキテクチャーを使用して作成されています。

簡単に言えば、3層アプリケーションモデルは時代遅れです。パブリッククラウドやモバイルアプリケーションが普及する前のアプリケーション開発用に設計されていることから、クラウドへの適応が困難です。

時間が経つにつれて、アプリケーションが過度に肥大化・複雑化し、頻繁に変更を加えることができなくなる可能性があります。それだけでなく、少なくとも3層のハードウェアとソフトウェアの保守も必要となるため、ビジネスの面で非効率になる場合があります。

3層アプリケーション・モデルは、モノリシック・アーキテクチャーとも呼ばれます。最近では複数の新しいアーキテクチャー・モデルも登場しています。ここからはクラウド時代に利用できる、いくつかのモデルをご紹介しましょう。

クラウドモデルでは、サービスとデータの集合体として設計された複雑なアプリケーションは、アプリケーションから完全に独立しています。マイクロサービスは、アプリケーションをサービスの集合体として構造化するアーキテクチャー方式です。各サービスは異なるプログラミング言語で記述し、別々にテストすることができます。独立したデプロイが可能であり、ビジネス機能を中心に組織されます。

マイクロサービス・アーキテクチャを使って開発されたeコマース・アプリケーションを例に取りましょう。各マイクロサービスは、単一のビジネス機能（ショッピングカート、検索、レビューなど）に焦点を当てることができます。これらはそれぞれ、異なるプログラミング言語で記述された個別のサービスであり、異なるインフラストラクチャにデプロイされ、異なるチームによって管理されます。

各サービスは軽量なプロトコルを使用して他のサービスと通信します。3層の場合は、誰もが知るModel View Controller（MVC）フレームワークが存在します。マイクロサービス・アーキテクチャーをサポートするフレームワークには、Sidecar、Ambassador、Adaptorなどがあります。

マイクロサービス・アーキテクチャーとモノリシック・アーキテクチャーの比較

モノリシック・アーキテクチャーでは、これらすべてのコンポーネントが単一のモジュールとして共存し、（ほとんどの場合）単一のチームによって管理されます。すべてが結合されています。更新が必要な場合はアプリケーション全体を展開しなければならず、これにより大規模で複雑なアプリケーションの変更は遅くなります。小規模なアプリケーションの場合には、しばしばモノリシック・アーキテクチャーが最適なソリューションとなります。

マイクロサービス、コンテナ、Kubernetes

マイクロサービス・アプリケーション・アーキテクチャーを作成して実行するための最良の選択肢の1つが、コンテナの使用です。コンテナは、アプリケーション用の軽量仮想化ランタイム環境をカプセル化し、開発者のデスクトップから本番展開までアプリケーションを移動できるようにします。利用可能なオペレーティング・システムの大部分では、仮想マシンまたは物理マシン上でコンテナを実行できます。コンテナは一貫したソフトウェア環境を提供し、アプリケーションのすべての依存関係をデプロイ可能なユニットとしてカプセル化できます。コンテナは、ノートPC、ベアメタル・サーバー、またはパブリッククラウドで実行できます。

多くの組織では、 Kubernetesを使用してコンテナを管理し、ダウンタイムの発生を防いでいます。Kubernetes は複数のホストでコンテナ・オーケストレーションを提供し、コンテナのライフサイクル管理に使用されます。Kubernetesを使用することで、デプロイメントを自動化し、アプリケーションを自動スケーリングし、迅速に構築して迅速に納品することができます。

Kubernetesのさらに詳しい情報については、動画「Kubernetesの解説」をご覧ください。

Red Hat OpenShiftは、最も人気のある主なハイブリッドクラウドのエンタープライズ・コンテナ・プラットフォームの1つです。多くのクラウド・プロバイダーがContainers-as-a-Service（CaaS）を提供しています。その他に利用可能なKubernetesエンジンとしては、 IBM Cloud Kubernetes Service 、オープンソース Kubernetes、AWS (EKS、ECS、Fargate)、Google GKS、Azure AKS などがあります。

通常、各マイクロサービスは別個の小規模チームによって構築され、各チームがプログラミング言語とデプロイメント・スケジュールを選択します。企業によるマイクロサービスとマネジメントの間の通信のガバナンスには、Istioのようなサービス・メッシュが使用されます。サービス・メッシュでは、リクエストはマイクロサービス間のプロキシー（Sidecarなど）を介してルーティングされます。

クラウドネイティブ・アーキテクチャーは、クラウドへのデプロイを計画するアプリケーションのために特別に設計されており、マイクロサービスはその重要な一部分を担います。

クラウドネイティブとは、クラウド・コンピューティングによる配信モデルの利点を活用したアプリケーションを構築および実行するアプローチです。クラウドネイティブとは、コンテナベースの環境を説明するために使用される用語であり、アプリケーションをどこで作成するかではなく、どのように作成してデプロイするかに関わる概念です。

クラウドネイティブ・テクノロジーにより、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドでアプリケーションを実行できるようになります。クラウドネイティブによる開発は、アプリケーションを迅速に市場に投入するために不可欠であり、クラウドに対応したアプリを構築、デプロイ、管理するための人材、プロセス、テクノロジーを支援します。

クラウドネイティブ・アーキテクチャーのモデルでは、 DevOps 、継続的統合（CI）、継続的デリバリー（CD）、マイクロサービス、コンテナを活用します。ほとんどの企業は、スケーラブルで堅牢なクラウドネイティブ・アプリケーションを設計するために12の要素からなる方法論を使用しています。

クラウドでは、アプリケーションは複数のノードで同時に実行でき、構成／セッション状態を共有し、一元化されたロギング・メカニズムを持ち、DevOpsとCI/CDプロセスを使ってデプロイできる必要があります。多くのクラウドプロバイダーがクラウドネイティブ開発のガイドラインを提供しています。Amazon Web Services（AWS）にはWell-Architected Framework、Googleにはクラウドネイティブアプリケーションの構築方法に関するさまざまなガイド、Microsoft Azureにはクラウドパターン・ガイドが存在します。

通常、クラウドネイティブ・アプリケーションは本質的にステートレスです。サービスは、RESTベースのプロトコルまたはメッセージングを使用して相互に通信します。APIゲートウェイ、コンテナ・レジストリー、メッセージ指向ミドルウェア（MOM：パブリッシュ／サブスクライブ、またはリクエスト／レスポンス）、サービス・メッシュ、オーケストレーションは、クラウドネイティブ・アーキテクチャーの一部になる場合があります。

イベント駆動型アーキテクチャー（EDA）は、イベントへの応答で実行される分離型システムをベースとしています。イベント駆動型アーキテクチャーでは、分離されたサービス間での通信をトリガーするためにイベントを使用します。EDAは昔から存在していましたが、現在ではクラウドとの関連性が高まっています。

何が新しい点なのでしょうか。適切に使用すれば、俊敏性、コスト削減、運用上のメリットが大幅に向上します。分散型のサーバーレスEDAは、REST APIまたはイベントのトリガーに応じて自動的にスケーリングされる、関数として知られるコードを実行できます。

サーバーレスモデルでは、サーバーの管理は必要ありません。サーバーレスモデルはまた、スケーラブル（ゆえに迅速なアップデートとデプロイメントが可能）であり、またステートレスです。

現在、さまざまなクラウド・プロバイダーが提供しているクラウド・サーバーレス・サービスの一例を以下に挙げます。

サーバーレスの種類

• Functions-as-a-Service (FaaS)：関数の一部をクラウドにアップロードし、部分的に独立して実行できるようにします。
• Backend-as-a-Service（BaaS）：アプリケーション管理、データベース管理、クラウド・ストレージなどのサード・パーティーのサービスを利用します。
• Mobile-Backend-as-a-Service (MBaaS)：モバイルアプリケーション向けの関数です。

モノリシック・アプリケーションをクラウド環境で適切に動作させるにはどうすればよいでしょうか。クラウドベースのアーキテクチャーは、最新のWebアプリケーション（静的／動的Webサイト）の構築、アプリケーションのデプロイ、データベースへの接続、ユーザー行動の分析に最適です。

従来のクラウドベースのアプリケーション・アーキテクチャーには、ロードバランサー、Webサーバー、アプリケーション・サーバー、データベースが含まれます。リソースの弾力性、ソフトウェア定義ネットワーキング、自動プロビジョニング、高可用性、拡張性などのクラウド機能の利点を活かすことができます。

このタイプのアーキテクチャーは、サーバーの保守を心配する必要のない組織にとって理想的です。サーバーレス機能は、PHP、Java、.NET、Node.js、Python、Ruby、Docker、Goなどさまざまなプログラミング言語をサポートしています。

API Gatewayは、開発者がセキュアなAPIを簡単に作成・公開できるようにする重要なサービスです。APIは、アプリケーションがデータやビジネスロジックにアクセスするためのフロントドアとして機能します。また、認証とアクセス制御も担当します。開発者はAPI Gatewayを使って、APIコールごとに異なるサーバーレス関数を呼び出します。

アーキテクチャーモデルを選定する際の決断は、プロジェクトの成否を左右するものです。アプリケーションと非機能要件に基づいて選択する必要があります。例えば、ほんの数マイル移動したいときに飛行機を選ぶことはないでしょう。

アプリケーション・プロジェクトのアーキテクチャーを選択する前に、まず次の点を考慮しましょう。

• モノリシック・ファーストか、マイクロサービス・ファーストか。（単純なアプリケーション要件の小規模なプロジェクトでは、モノリシックが正しい選択となる場合があります。）
• チームではマイクロサービスを活用する準備ができているか。
• チームには、すでにクラウドベースのDevOpsとCI/CDプロセスが存在しているか。
• ホスティングモデルは何か。プライベート、パブリック、ハイブリッドのどれか。
• アプリケーション・アーキテクチャはプロジェクトにどのような影響を与えるか。
• 複数のアーキテクチャー・モデルの組み合わせは有効か。
• アプリケーションには永続性とセッションが必要か。

Webアプリケーション・アーキテクチャーは、デジタル・ビジネスの要件と変化するITインフラストラクチャー環境に合わせて進化し続けています。人工知能、分析、オートメーション、高度なロボティクス、エッジコンピューティング、ブロックチェーン、IoT（モノのインターネット） 、API などのテクノロジーは、多くの業界の可能性を広げています。インフラストラクチャー、アプリケーション、データ・サイズの複雑化には、新しいアーキテクチャーのアプローチが必要です。ほとんどの企業では1つ以上のクラウド・プロバイダーを使用するマルチクラウドのアプローチを採用しています。大企業では、プライベート、パブリック、または SaaS、 PaaS 、 IaaSによるハイブリッド・モデルでクラウド・サービスを利用しています。

以前は、アプリケーションのデプロイメントは困難なプロセスであり、通常の業務時間内に行うことができませんでした。しかし、さまざまなデプロイメント手法（ブルー・グリーンやカナリア・デプロイメントなど）、DevOps、CI/CD（継続的統合と継続的デリバリー）により、今ではアプリケーションを停止することなく、いつでもデプロイメントが可能です。

モノリシック・アーキテクチャーは現在も多くのアプリケーションに有効ですが、俊敏性と市場投入までの時間短縮を達成するには、デジタル・ユースケースに適切なアーキテクチャーを使用する必要があります。シンプルなアプリケーションの場合は、従来のモノリシックなアプローチを選択することを検討してください。クラウドネイティブ、またはマイクロサービスのパターンは、複雑で進化するアプリケーションに最適です。複数の言語やデプロイメント・スケジュールを使用する経験豊富なチームをいくつも擁していれば、マイクロサービス・アーキテクチャーを使用することが理にかなっています。参考として、以下に従来の3/N層アプリケーションとクラウドベースのアーキテクチャー・モデルの比較をまとめています。

IBMidに登録して IBM Cloudアカウントを作成し、構築を開始しましょう。