re:Invent 2022 の Keynote で発表された Application Composer を数日使って見えてきた課題と期待

アドベントカレンダーの季節がきたので、久しぶりにQiita 記事を書いています。

# re:Invent 2022
Keynote は毎年、現地のラスベガスで朝8時半、日本時間だと翌日1時半から2時間ほど行われるのが定番になっています。現地にはいけませんでしたが、Keynote が日本語通訳付きで Live配信されていたので夜な夜な深夜に視聴していました。

AWS の CTO である Dr. Werner Vogels 氏の Keynote で発表された新サービスのひとつが、AWS Application Composer です。コンソールの検索から探すと青いアイコンが出てくることから、Code3兄弟やCDKなどが所属する開発ツールカテゴリという位置づけのようです。

https://aws.amazon.com/jp/application-composer/

日本語版ブログでの紹介記事
https://aws.amazon.com/jp/blogs/news/visualize-and-create-your-serverless-workloads-with-aws-application-composer/

ざっくりいうと、コンポーネントをキャンバスに並べて線をつないでパラメータを設定していくと、AWS SAM + CloudFormation のテンプレートをインタラクティブに生成してくれるGUIツールで、ローカルファイルとの同期が可能です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/18306/a8aba70d-0055-d954-6654-469ac23045db.png)

https://twitter.com/edjgeek/status/1598370719045296129

開始時には、まっさらなキャンバスから始めるほか、ローカルマシンに持っている既存のテンプレートファイルを選択することができます。ローカルマシンのディレクトリを選択すると、ブラウザからローカルマシンのファイルを読み書きする権限の許可を求められます。これを許可すると、ブラウザ上での操作結果がローカルファイルに、VSCode や IDE から編集したローカルファイルの変更も、即座にブラウザを通じて同期されます。ファイルをアップロードするだけだった既存のよくあるツールでは叶わなかった双方向での同期が行われます。（同期せずに使うこともできます。）

スクリーンショットを見て「だいたい理解した」と思った方、ちょっと待って下さい。画面には書いていない便利機能がいくつも用意されているのです。

## よくある Serverless 構成をつくってみる

API Gateway + Lambda + DynamoDB 

先程のスクリーンショットであるように、API Gateway とLambda をキャンバスに並べて線をつないでいくと、API Gateway と Lambda を使った API を作るテンプレートを生成してくれます。Lambda をひとつ選択すると、関数名、デプロイ方法（Zip/Container）、Runtime、 アーキテクチャ（x68/arm64）、コードのパスとhandler など、通常必要とするパラメータは画面上から入力や選択ができます。選択した Runtime に応じて、ローカルのディレクトリには指定したディレクトリに Handler のファイルと最低限のコードが生成されているのです。
SAMのテンプレートでも別リソースとして追加しなければいけない LogGroup もちゃんとデフォルト装備です。CORSの設定だってプロパティ設定のフォームから入力できます。

次はスクリーンショットに倣ってDynamoDBを追加します。テーブル名を決めたらLambdaと線を繋いでいきます。そうすると何ということでしょう！Lambda関数のプロパティにはPoliciesでDynamoDBへのアクセスを許可する設定と、Environment には DynamoDB のテーブル名、ARN が自動で追加されています。

冒頭で選択したローカルのディレクトリにはSAMのプロジェクトが一式揃っています。Lambda関数の中身のコードを書き始めるだけです。Lambda関数の実装を始めるまでにかかる時間は、5-10分程度でしょうか。慣れている方でも `sam init` から始めて同じようにLambda関数の実装を始められる環境を用意するのは、意外と手間のかかる作業です。

コードの実装中は、 ローカルマシン上で `sam local invoke` でhandlerのローカル実行をしたり、APIを立てて curl コマンドや Postman のようなツールからリクエストを送って動作確認しながら開発することができます。

AWSへのデプロイは、Application Composer の機能としては持っていません。ローカルに同期されたSAMプロジェクトを使って、SAMコマンドでデプロイを行います。直接 `sam deploy` でデプロイを行うほか、`sam pipeline` でCI/CDパイプラインを作る機能もリリース済みです。

- CodePipeline (IAM)
- GitHub Actions (OIDC)
- GitLab (OIDC)
- Bitbucket (OIDC)


Application Composer に出てくるコンポーネントの中にも、SAM 非対応のリソースがいくつか履いています。Application Composer には並んでいない別なサービスを使いたいこともあるでしょう。SAM テンプレートはCloudFormation テンプレートの上位互換となっているため、CloudFormation のコードをそのまま追加することができます。そして一緒に CloudFormation テンプレートとしてデプロイすることができます。


## 現状の課題

数日触ってみたところの感触で、課題に感じるところもありました

### Step Functions
プロパティが1つのテキストエリア（改行ありテキスト）になっていて、そこに入力するUIになています。Application Composer のターゲットユーザーを考えると、Step Functions のコンソールで GUI を使って作成したくなるでしょう。 新規で開発するのであれば、テンプレートに直接YAML形式で記述するのが良さそうです。

### ブラウザ上で選択中のリソースが迷子になってしまう問題
3-4回遭遇しました。 リソース選択がどれもできなくなって困惑しますが、慌てて画面更新してはいけません。 キャンバス左側が、 Lists・Resource のタブになっていて、現状だとここのLists を一度選択してやるとキャンバス上で選択されているリソースがリセットされるようです。

### 同期のコンフリクト
同期タイミングの都合上、コンフリクトしてしまうことがあります。IDEがどちらを優先するかを選択するダイアログを出してくれるのですが、Git のコンフリクト解消時のようなそれぞれの差分を表示したり一部を取り込むといった柔軟な対応はできません。ローカル・リモート（ブラウザ上の操作による変更） どちらを採用するか？の選択になります。かなりリアルタイムに近い速度で同期してくれているので、リモートで変更した直後にローカルでコンフリクトするような変更を行わない、ローカルの変更も慌てず一呼吸おきながら、をユーザー側が心がけるだけでも随分と防げるようにも見えました。


## 今後に期待

- 対応リソースの拡大 StepFunctions が AWS SDK に対応したことで一気に200以上のサービスに対応したことを皆さん覚えていますよね？これは期待しないで、っていうほうが無理かもしれません。
- Application Composer が発表された直後、re:Inventで行われた Brakeout Sessionで、CDK の Builder たちが CDK にも対応しようと登壇者に群がっていたという噂を聞きました。こちらも楽しみです。

## まとめ

Application Composer の持つポテンシャルが伝わったでしょうか？
AWSの他のサービスと同様に、一般提供開始やその先も、ユーザーのニーズを取り入れながら拡充されていくものと期待しています。

> tweet with the tag #AWSAppComposerWishlist.

要望や提案があれば、 [#AWSAppComposerWishlist](https://twitter.com/search?q=%23AWSAppComposerWishlist&f=live) のハッシュタグをつけてツイートしましょう！！