CACのAWS導入支援サービス「enterpriseCloud+」

本技術レポートは、「サーバーレスアーキテクチャで何が変わるのか」の記事の新章となります。
今後続章を追加で公開して参ります。

サーバーレスアーキテクチャにおけるフロントエンドの変化

はじめに

ソフトウェア工学の定義では、フロントエンドはソフトウェアのプレゼンテーション層、バックエンドはデータアクセス層に分類される。クライアント・サーバーモデルにおける定義では、クライアントがフロントエンド、サーバーがバックエンドに分類される。サーバーレス開発におけるフロントエンドの明確な定義は存在しない。しかし、アーキテクチャや用語の使われ方からその定義をある程度、限定させることができる。

1. フロントエンドの定義

ソフトウェアアーキテクチャ設計では、UIが存在する場合はインターフェースからデータアクセス層までの間に多くの層が存在し、その設計パターンも数多くあるが、インターフェースに近いものがフロントエンドと呼ばれ、データストレージやビジネスロジックを処理する部分をバックエンドと呼ぶ。また、通信の世界ではデバイスやサービスをフロントエンドと呼び、バックはそのサービスを支えるインフラストラクチャやシステムを指す場合が多い。

では、クラウド上のサーバーレスアーキテクチャではどのように解釈すべきか。以下にサーバーレスアプリケーションの特徴を前述の定義を元に示す。

• データストレージはクラウドのマネージドサービスとして提供される
• サービスを支えるインフラストラクチャもマネージドサービスとして提供される
• ユーザーがGUIで操作するコンポーネントはマネージドサービスに含まれないことが多いが、それ以外のアップロードなどユーザーが操作するあらゆるコンポーネントもマネージドサービスが直接提供している場合がある
• サーバーが存在せず、コードはVCSに存在しビルドしてデプロイされたものがサーバーレスアプリケーションのコンポーネントとして配置され、マネージドサービスとの組み合わせでサービスを提供する

AWSのS3を例にして、いくつか具体例をあげる。S3はデータストレージとして使うことができ、サービスを支えるインフラストラクチャなのでバックエンドである。しかし、ユーザーがアップロードするコンテンツを配置し、直接操作する場所なのでフロントエンドであるとも言える。静的コンテンツを配置して、ユーザーインターフェースに近いもしくはそれそのものを提供するコンポーネントになるのでフロントエンドである。

今回は例としてS3を使ったが、同一のマネージドサービスでも用途によって定義が変わる場合がある。よってマネージドサービス単体でこれはフロントエンド、これはバックエンドなど明確に定義するのは難しい。組み合わせや用途によってフロントエンド相当と考えるのが妥当である。

2． AWSにおけるサーバーレスアーキテクチャのフロントエンド

本題に入る前にAWSが提供するマネージドサービスの組み合わせ例を元に広義のフロントエンドと呼べるものを分類してみた。分類は使用するプロトコルや仕様に基づく観点のものと、これまでの概念・アーキテクチャに近いものから整理したものに分ける

プロトコルや仕様に基づく分類

（ア）HTTP・HTTPS、RestAPI、GraphQLなどオープンな仕様を元に外部と通信を行うもの

API Gateway、Cognito、AWS Amplifyなど

（イ）クラウドの独自仕様に基づき外部と通信を行うもの

IAM RoleベースでAWS SDKやAWS CLI、その他AWS製のツールやライブラリを使って通信を行うもの。

概念やアーキテクチャに基づく分類

（ア）クライアント・サーバーモデルに近いWebサービス

1. ① S3単独によるWebコンテンツ配信
2. ②CloudfronとAPI GatewayもしくはAWS Amplifyを使ってコンテンツを提供
3. ③AWS AppSyncを使ってコンテンツを提供
4. ④API Gateway
5. ⑤上記の組み合わせ

（イ）IAM Roleなどの認証を使ってインターネット経由でアクセスできるマネージドサービス

1. ①S3など専用クライアントが不要で、httpもしくはhttpsでアクセスできるマネージドサービス
2. ②AWS SDKもしくはCLIでアクセスできるマネージドサービス
3. ③Kinesisなど専用クライアントを経由してアクセスするマネージドサービス
4. ④ファイルのアップロード、操作などAWS Console経由でアクセスするマネージドサービス

（ウ）AWS内部のサービス間を繋ぐ際に使用されるインターフェースに近いもの

1. ①API Gateway
2. ②IAM RoleもしくはSecurityGroup・Cognitoなどでアクセス制御が可能なマネージドサービス
   直接連携できない場合はLambdaを作成する。この場合、データの連携元のアウトプット処理として作った時も、データの連携先のインプット処理として作った場合もどちらもフロントエンドになる。
3. ③ EventBridge・SQS・SNS Topicなどを使った連携
   イベントドリブン、Pub/Subなど様々な呼称で呼ばれるIAM経由の認証を利用した、リソース間のイベント・データのやりとりに近いもの

サーバーレスアーキテクチャにおけるフロントエンドの変化

サーバーレスアーキテクチャにおいてはWebフロントエンドの構成も変わる。物理的論理的なサーバーが存在しなくなり、設定する機能や配置するアプリケーションやコード・データ次第で役割が変わる。従来のサーバーが主体で考えられていた設計思想ではなく、本来必要な最低限の機能とマネージドサービスを使う上で必要な最低限の設定だけで目的が達成できるため、主軸となるものがサーバーの延長ではなく必要な機能側に集約される。

まず、ここではAWSでCloudFront、API Gateway、S3を使用した例を説明する。これは前回の記事の「クライアント・サーバーモデルに近いWebサービス」の例に該当する。
以下にシンプルな図を示す。

図1 AWSにおけるシンプルなWebフロントエンドの構成

この構成を前回の記事における定義を元に分類すると、フロントエンドの範囲を「ClodFront・S3・API Gateway」になり、API Gatewayと直接繋がるLambdaはグレーゾーン。Lambdaが参照するビジネスロジック・データアクセス層はバックエンドとなる。API Gatewayと直接繋がるLambdaがデータアクセス層になる場合もある。この図のLambdaより先の処理は明確にバックエンドと分類可能である。

これまでは上図のAPI Gatewayに相当する部分はWeb3層アプリケーションでは、アプリケーション層が担当していた。しかし、サーバーレスアーキテクチャではこの層は機能単位で分割され、それらを管理する広義のAPIゲートウェイと実際の処理を担当する関数に別れる。AWSのAPI GatewayにおけるAPIはAPI Gatewayが内包している状態に近い。

KubernetesのAmbassador API GatewayやIstio、KongやAWSのAppMeshは明確にAPIを提供する側とルーティングを担当する側に別れており、構造上仕分けが容易である。しかし、AWS API Gatewayの場合は他のAPIゲートウェイ製品と微妙に異なり、API相当の部分とAPIを統合し、API Gatewayの内部にその定義を持つ構成となる。これはHTTPでのエンドポイントを持たないAWSのマネージドサービスをAPIとして統合する機能を持っているからと推測される。

よくある質問

全般について

• 全般

契約について

• 契約
• 更新
• 解約

料金/
支払いについて

• 料金
• 支払

サービスについて

• 開始
• 技術支援
• サポート
• eC+管理コンソール
• その他
• DBマイグレーション