こんにちは。 先日のAWS re:Invent 2022で CTOのWerner VogelsよりAWS Application Composerの発表がありました。
Application Composerにより、サーバレスアプリケーションを構築する際に ビジュアルデザイナー上でのリソースを設計、テンプレートコードの自動生成が可能になります。
今回は本サービスを使用することで、サーバレスアプリの開発体験がどのように変わるのか検証してみました。
AWS Application Composerとは
AWS Application Composerは、複数のAWSサービスからサーバーレスアプリケーションを構築するために使用できるビジュアルデザイナーです。 コンソール上に表示されたキャンバス上でAWSリソースをドラッグアンドドロップで選択、 リソース間の接続をすることで、アプリケーションアーキテクチャを簡単に設計することができます。
さらに設計したアーキテクチャからAWSのベストプラクティスに則ったインフラストラクチャー・アズ・コード（IaC）テンプレートを自動生成することができます。
今まで、サーバレスアプリケーションを作る際にはアーキテクチャの設計とテンプレートの作成を別々に行う必要がありましたが、 Application Composerを使うことによってテンプレートファイルの作成に時間を使う必要がなくなり、 その分、担当者は設計に集中できるようになります。
またCloudFormationの専門家がいなくてもサーバレスアプリケーションの構築が可能になることが期待されます。
実際に試してみた
それではプレビュー版がサポートされている東京リージョンで試していきます。 まずコンソール上でApplication Composerを開きます。 今回はデモ版を試すため、右上の「Open demo」をクリックします。
クリックすると、下記のようなオプション選択画面が表示されます。
ここでは接続タイプを「Connected」か「Unconnected」を選択します。 「Connected」を選択すると、自動的にテンプレートを含めたプロジェクトフォルダがローカルに保存され、 キャンバス上でコンポーネントを編集すると自動でローカルにも編集内容が同期されるようになります。 一方で「Unconnected」を選択すると同期されないため、テンプレートファイルのインポートとエクスポートを手動で行う必要があります。 今回は「Connected」を選択します。 次に「Select folder」ボタンをクリックして、ローカル環境で保存したい空のディレクトリを選択後、「Create」をクリックします。
ポップアップが表示されるので、「変更を保存」を選びます。
すると下記のようにデモアプリのアーキテクチャが既に作られたデザイナー画面が表示されます。
アーキテクチャの構成としてはシンプルなAPI Gateway, Lambda, DynamoDBの三層構成で、 各HTTPリクエストに応じたLambda関数を呼び出し、DynamoDBを操作するような作りとなっています。
ここで各コンポーネントを見ていきましょう。
まずAPI Gatewayについてです。キャンバスに表示されたApiを選択し、Detailsをクリックしてみると右にAPI Gatewayのプロパティ画面が表示されます。
ここでHTTPルートの追加、編集、削除やAuthorizerの追加、CORSの設定等ができるようです。
次にLambdaです。同様にDetailsを見てみると、IDやランタイム、メモリ、ポリシーからLambda Layerまで基本的な設定はほとんどできるようでした。
DynamoDBに関してはシンプルでキーの定義設定のみができるようです。キャパシティユニットやセカンダリインデックスの設定はまだサポート外のようですね。
次にサービス間のコネクタ定義を見てみましょう。
コネクタを作ることでどのようにテンプレートが書き変わるのかを見たいため、デモで作成されたコネクタを一旦削除してみます。下記のようにコネクタを選択すると「Disconnect」ボタンが表示されるので、クリックしてすべてのコネクタを削除してみます。
次にサービス間でコネクタを再作成してみます。下記のようにコンポーネントに付いている端子をドラッグして、API GatewayのGET /itemsとLambdaのListItems関数、ListItems関数とDynamoDBのitemsテーブルをつなげてみます。
次に画面左上部の「Template」タブを選択して、変更されたテンプレートファイルを確認してみます。
まずAPI Gatewayの定義を見ると、コネクタを作成したパス、メソッドにLambdaを呼び出す定義が追加されたことがわかります。
次にLambdaのListItemsの定義を見てみます。 赤枠で囲っている箇所が修正されており、EventsにはAPIのパス、メソッド定義が追加され、 Policies、EnvironmentにはDynamoDBにアクセスするための定義が追加されました。
ここでDynamoDBのポリシーについては注意が必要です。 テンプレートファイルを見てみると過去に紐付けたReadPolicyが削除されずに残ってしまっていたり、 今回紐付けたポリシーがCRUDポリシーになってしまっていたりするため、ここは手動で修正をします。
このようにリソースをキャンバス上で動かすだけでテンプレートファイルを簡単に書き換えることができました。
なお現在対応しているサービスについてですが、下記の左側の「Resources」に表示されているサービスだけのようです。
なお「Resources」には表示されていませんが、隠しリソースとしてそれらを含むテンプレートをロードすると、キャンバス上に表示されるようなサービスがあるようです。 現在、隠しリソースの例としては、以下のようなものがあります。 - AWS::ECS::TaskDefinition - AWS::CloudFront::Function - AWS::CloudFront::Distribution
ただし、機能がApplication Composerで完全にサポートされているわけではないそうなので注意が必要です。
次にこの作成されたアーキテクチャをデプロイしてみます。 先に設定したローカルのディレクトリを参照すると、下記のようにテンプレートやLambdaリソース、AWS SAMの設定ファイルが読み込まれていることがわかります。
ではこのリソースをAWS SAMを使用してデプロイしてみましょう。 AWS Serverless Application Model (AWS SAM) とは、AWS でサーバレスアプリケーションを構築するために使用できるオープンソースのフレームワークです。
SAM CLIが未インストールの場合は以下に記載の手順でインストールを行います。 https://docs.aws.amazon.com/ja_jp/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html
インストール後、コマンドラインインターフェース上でプロジェクトのルートディレクトリに移動し、以下のコマンドを実行し、テンプレートをビルドします。
$ sam build -t template.yaml
成功の場合はBuild Suceededと表示されます。続いてデプロイを行います。 なお、Lambdaパッケージを保存するS3バケットが必要なため作成しておきます。
$ aws s3api create-bucket --bucket {bucket-name}--region ap-northeast-1 --create-bucket-configuration LocationConstraint=ap-northeast-1
上記で作成したバケット名を設定し、デプロイします。
$ sam deploy --s3-bucket {bucket-name}
コマンド実行後、出力されるログを見ると、下記のようにリソースが作られているのがわかります。完了まで待ちましょう。
完了後、それぞれのリソースがデプロイされたかをAWSコンソール上で確認してみます。
Lambda
DynamoDB
それぞれ作成されていることが確認できました。 疎通テストを行いたい場合は、作成されたAPI Gatewayリソースのステージに記載されたURLにリクエストを送信することで確認ができます。
試した後は必ず、プロジェクトのルートディレクトリ上で下記のSAMコマンドを実行し、リソースを削除しましょう。
$ sam delete
さいごに
今回、Application Composerを試してみて、サーバレスアプリケーションの開発体験がどのように変わるのか確かめてみました。 個人的には今回くらいのシンプルな構成であれば、自動生成されたテンプレートファイルがそのまま使用できるため、構築時間の短縮に繋がるのではないかと思いました。 今後、対応リソースの追加や設定プロパティの追加されることによって、Application Composer上でできることが増え、サーバレスアプリケーションがより一層かんたんになっていくことを期待したいです。
