バックエンド アーキテクチャとは、ウェブ アプリケーションのバックエンドの構造を指します。バックエンド アーキテクチャにより、アプリケーションの各部分が相互に通信して受信リクエストを処理する方法と、レスポンスを作成する方法が決まります。ウェブ アプリケーションを構築する際は、費用（継続的および大規模の両方）、アプリケーションの複雑さ、スケーリングの目標、チームの専門知識など、特定の要件と要因に基づいてバックエンド アーキテクチャを選択します。
特に e コマース、新聞、ブログなどのコンテンツ主導のウェブ アプリケーションの場合、特にアプリケーションがグローバル規模に成長し、分散が進む可能性がある場合、データとパフォーマンスの一貫性が重要な要件となります。コンテンツ主導のウェブ アプリケーションの場合、アプリケーションで使用されるデータ ストレージも重要です。詳細については、データ ストレージ ガイドをご覧ください。アプリのパフォーマンスを最適化するには、一般的なアプリケーション アーキテクチャを超えて、コンテンツをホストし、アクセス可能にすることが重要です。適切なホスティング戦略の選択とアプリの最適化について詳しくは、ホスティング ガイドをご覧ください。
ウェブ アプリケーション用の既存のバックエンドがある場合は、現在のアーキテクチャの制限を考慮してください。たとえば、アプリケーションがスケールアップし、パフォーマンスと信頼性の向上が要求される場合は、アプリケーションの一部をリファクタリングするか、拡大したスケールに適した別のアーキテクチャに移動する必要があるかどうかを検討します。たとえば、ハイブリッド（またはマルチクラウド）アーキテクチャでは、完全な移行を行う前に、一部のワークロードをクラウドに移行できます。このような移行に伴う費用、時間、リスクを考慮することも重要です。
モノリシック アーキテクチャ
モノリシック アーキテクチャは統一された構造を持ち、アプリケーションのすべてのコンポーネントが 1 つのコードベースに緊密に統合されています。アプリケーション全体が単一の自己完結型ユニットとしてビルドされます。モノリシック アーキテクチャは多層構造であり、アプリケーションのさまざまなレイヤが特定のタスクを実行します。
構造レイヤ
- アプリケーションの機能を表示するためのコンポーネントを含むユーザー インターフェース（UI）は、通常はユーザーとやり取りするウェブベースのアプリケーションまたはデスクトップ アプリケーションです。
- アプリケーション ロジックは、コア機能が存在する場所です。コードベースのこの部分には、アプリの動作を定義するルール、計算、オペレーションが含まれます。
- データアクセス レイヤには、データの読み取りと書き込み、およびアプリケーションのデータ構造とデータベース スキーマ間の変換を行う関数が含まれています。このレイヤは、アプリのデータベースまたはデータ ストレージとやり取りします。
- データベースは、アプリケーションがデータを保存する場所です。通常、ユーザーデータ、構成、その他の情報など、アプリケーションのすべてのデータを格納する単一のデータベースがあります。
- ミドルウェア コンポーネントは、認証、リクエストのルーティング、データ検証などのタスクを処理します。これらのコンポーネントは、データとリクエストのフローの管理に役立ちます。
- 一部のモノリシック アプリケーションには、外部サービスまたは API との統合ポイントがあります。これらのポイントにより、アプリケーションはサードパーティのサービス、データソース、その他のシステムとやり取りできます。
構造レイヤは通常、単一のコードベースの一部です。このコードベースにはアプリケーション全体が含まれ、通常はディレクトリ、モジュール、クラスで構成されています。デベロッパーは、コードベースのさまざまな部分に取り組み、アプリケーションをビルドしてメンテナンスします。ただし、アプリケーション全体は通常、単一のユニットとしてデプロイされます。更新や変更が行われると、アプリケーション全体が再デプロイされます。
想定される課題
- モノリシック アプリケーションが大きくなるにつれて、コードベースが複雑になり、メンテナンスが困難になる傾向があります。その結果、開発サイクルが長くなり、コードベース全体を把握することが困難になります。
- コードの一部で行った変更がアプリケーションの他の部分に影響する可能性があるため、モノリシック アプリケーションへの変更のデプロイにはリスクが伴います。このため、デプロイ プロセスが長くなり、エラーが発生しやすくなります。
- モノリシック アプリケーションは、単一のユニットとしてデプロイされるため、スケーリングが難しい場合があります。1 つのコンポーネントだけで需要が増加している場合でも、アプリケーション全体をスケーリングする必要があります。
- モノリシック アプリケーションは、多くの場合、単一の技術スタックまたはプログラミング言語に依存しているため、アプリケーション内の特定のタスクに最適なツールを使用する能力が制限される場合があります。
- 需要が低い期間でも、モノリシック アプリケーションの運用には膨大なリソースが必要です。また、アプリケーションの経年劣化に伴い、回帰を発生させることなくアプリケーションの更新やパッチ適用が難しくなるため、メンテナンス費用も増加します。
- モノリシック アプリケーションに取り組む開発チームは、アプリケーション全体を中心として編成されることが多く、チームの規模が大きく、チームメンバー間の調整が複雑になります。
推奨される使用方法
モノリシック アーキテクチャは、アプリケーションの要件が厳しく、開発チームが小規模の場合に適しています。アプリケーションの複雑さと規模が増大する、またはアプリケーションの異なる部分が異なるテクノロジーやデプロイ戦略を必要とする場合、モノリシック アーキテクチャは柔軟性が低下し、メンテナンスが困難になる可能性があります。
Compute Engine でモノリシック アプリケーションを実行できる仮想マシンを作成して管理できます。モノリシック アプリケーションを実行するために、これらの仮想マシンのオペレーティング システム、ソフトウェア、管理を完全に制御できます。
App Engine などの Platform as a Service サービスを使用すると、アプリケーションを構築し、リクエストに応じて自動的にスケーリングするフルマネージド インフラストラクチャで実行できます。
モノリシック アプリケーションがコンテナ化されている場合は、Google Kubernetes Engine（GKE）または Cloud Run を使用して実行できます。Cloud SQL や Cloud Spanner などのサービスを使用して、モノリシック アプリケーションのデータを保存できます。アプリケーション固有の要件に基づいてサービスとシステムの組み合わせを検討してください。
サーバーレス アーキテクチャ
サーバーレス アーキテクチャを使用すると、物理サーバーや仮想サーバーを管理することなく、アプリケーションをビルドして実行できます。クラウド プロバイダがインフラストラクチャ、スケーリング、リソース割り当てを自動的に管理するため、デベロッパーはアプリケーションのコードの作成に集中できます。サーバーレス アーキテクチャでは、サーバーを保守する必要がないため、開発を簡素化し、運用上のオーバーヘッドを削減し、費用を最適化できます。マイクロサービス、リアルタイム データ処理、ワークロードが変化するウェブ アプリケーション、イベント処理に適しています。
イベントベースのサーバーレス アーキテクチャ
イベントベースのサーバーレス アーキテクチャは、イベントまたはトリガーを使用して関数またはマイクロサービスの実行を開始する特定のタイプのサーバーレス コンピューティング アーキテクチャです。システム コンポーネントはイベントを介して通信し、そのイベントに応じて関数が呼び出されます。関数がイベントによってトリガーされてから独立して処理され、その後に後続のアクションをトリガーするイベントが生成されるため、多くの場合、非同期通信に依存します。このタイプのサーバーレス アーキテクチャは、スケーラブルで応答性の高い、疎結合のシステムを構築する場合に適しています。
Google Cloud Functions と Cloud Functions for Firebase を使用すると、フルマネージドのサーバーレス環境でイベント ドリブン関数をビルドしてデプロイできます。インフラストラクチャを管理することなく、HTTP リクエスト、Cloud Pub/Sub メッセージ、Google Cloud Storage の変更、Firebase Realtime Database の更新など、さまざまなイベントやトリガーに応じてコードを実行できます。主な機能には、多言語サポート、スケーラビリティ、きめ細かな課金、サードパーティ統合、堅牢なロギングとモニタリング、他の Google サービスや Firebase サービスとの統合などがあります。
サーバーレス アーキテクチャは、多くのユースケース、特にさまざまなワークロード、急速な開発ニーズ、予測不可能なトラフィックを持つアプリケーションにおいて費用対効果が高い可能性があります。信頼性はクラウド プロバイダに左右され、特定のパフォーマンスと信頼性の目標を確保するためにサービスレベル契約（SLA）が設定されています。特定のユースケースと要件を評価して、サーバーレス アーキテクチャが最適なオプションかどうかを判断する必要があります。
コンテナ化
コンテナ化により、アプリケーションとその依存関係を軽量でポータブルなコンテナにパッケージ化できます。さまざまなシステムやプラットフォームにまたがる開発とデプロイをサポートする一貫したアプリケーション環境を提供します。一部のサーバーレス プラットフォームでは、コンテナ化されたワークロードを実行できます。サーバーレス環境でコンテナを実行すると、基本関数として表現できない複雑なワークロードやステートフル ワークロードがある場合に便利です。言語サポートとランタイム環境に柔軟性があります。
Cloud Run はサーバーレス コンピューティング プラットフォームで、デベロッパーはこれを使用して、コンテナ化されたアプリケーションをフルマネージド環境にデプロイして実行できます。基盤となるインフラストラクチャを管理することなく、アプリケーションを簡単にビルド、デプロイ、スケーリングできます。幅広いウェブ アプリケーションとマイクロサービス アプリケーションに適しています。特に、ワークロードが変動し、コンテナ化によりアプリケーションのパッケージングと整合性の点でメリットがあります。
マイクロサービス アーキテクチャ
アプリは疎結合された小さな部分に分割され、個別の機能を実装します。これらのサービスは、非同期メッセージ、イベントベースのチャネル、またはインターフェースを公開して直接通信できます。各サービスはコンテナ内で個別に開発、テスト、スケーリングされ、多くの場合、Kubernetes などのオーケストレーション サービスを介して管理されるか、Cloud Run などのマネージド プラットフォームを使用してデプロイされます。
マイクロサービス デプロイでは通常、一元化されたサーバーに依存せずにサーバーレス アプリケーション パラダイムも利用します。
アプリケーションを自律サービスに分割すると、複雑なシステムを簡素化できます。境界と目標を明確に定義することで、開発をスピードアップし、メンテナンスを改善できます。マイクロサービスは、最も効果的なフレームワークやツールを使用して個別に開発できます。サービス間の通信は通常、イベント、パブリッシュ / サブスクライブ通信、メッセージ パイプライン、gRPC などのリモート プロシージャ コールを使用して処理されます。
マイクロサービス アーキテクチャ内でタスクのオーケストレーションを行う場合は、対象のプラットフォームをサポートするフレームワークを使用し、オーケストレーション対象のタスクとワークフローの種類に対して十分な深さ、問題をデバッグするためのエラー処理とテレメトリーの使用を検討してください。一般的な選択肢には、Conductor や、Google Workflows などのクラウド プロバイダが提供するサービスがあります。
マイクロサービス ベースのアプリケーションは、分散型の性質上、サービス内通信の必要性から、開発と保守が複雑になる可能性があります。したがって、デプロイ、モニタリング、ロギングの管理は、他のアーキテクチャ オプションよりも複雑です。信頼性は個々のサービスのアーキテクチャに依存するため、特にモニタリングとテレメトリーがデプロイされ、必要に応じて有効になっている場合は、分散型の特性によって復元力が向上する可能性があります。
コンテンツ ドリブン ウェブ アプリケーション バックエンドのさまざまなアーキテクチャの比較
次の表は、コンテンツ ドリブン ウェブ アプリケーションのバックエンドの主な要件とアーキテクチャを比較したものです。
| モノリシック アーキテクチャ | サーバーレスのイベントベースのアーキテクチャ | サーバーレス、マイクロサービス アーキテクチャ | |
|---|---|---|---|
| 複雑さとメンテナンス |
|
|
|
| スケーラビリティとパフォーマンス |
|
|
|
| 復元力とフォールバック戦略 |
|
|
|
| 開発環境 |
|
|
|
| 費用 |
|
|
|
コンテンツ ドリブン ウェブ アプリケーションのバックエンド アーキテクチャの詳細
アプリを別のアーキテクチャに移行する方法など、コンテンツ ドリブン ウェブ アプリケーションのアーキテクチャの詳細については、次のリソースをご覧ください。
- 階層化されたモノリシック ウェブ アプリケーションやサーバーレス ウェブ アプリケーションなど、疎結合ウェブアプリ バックエンド アーキテクチャの詳細を確認する。