NRIネットコム Blog

NRIネットコム社員が様々な視点で、日々の気づきやナレッジを発信するメディアです

トップ > Technology > AWS Application Composerの概要とCDKとの比較

AWS Application Composerの概要とCDKとの比較

Technology Technology - AWS Technology - AWS - CDK イベント・告知 - アドベントカレンダー #アドベントカレンダー2022

本記事は NRIネットコム Advent Calendar 2022 11日目の記事です。
🎁 10日目 ▶▶本記事 ▶▶ 12日目 🎄

こんにちは！　re:Inventで貰ったライトセーバーを肩掛けバックに入れて手に持つとSAMURAIスタイルになっていた志水です。やはり海外行くと自然に出ちゃいますね、サムライハートが。

はじめに

さて、みなさんはre:Invent期間中に発表された新サービス・新機能で心惹かれたものはありますか？　私はダントツでAWS Application Composer（以降Application Composer）でした。

Wernerから発表されたとき、ついにローコードがきたかとテンション爆上がりしてました。最近IaCの教育方法について悩んでいたので、心に響きました。

じゃあぼくのだいすきなCDKさんとの棲み分けはどうなるの？　Application ComposerにCDKサポートされることの意義ってあるの？　と思ったので、いくつかの観点で比較して、答えていきます。
ちなみにタイトルのApplication ComposerとCDKではターゲットが違ってくるので、正確にはApplication Composer+SAMとCDKを比較することになります。

Application Composerとは

Application Composerについて説明します。Application Composerとは、サーバレスアーキテクチャにおけるインフラのローコードツールで、画面上でサーバレスサービスのアイコンを置いたり繋げるだけでインフラのコードを作れます。LambdaのアプリケーションコードはHello World的なコードが自動生成されます。

また、事前に作成されたインフラコードをインポートすると、その内容に沿ったアイコンとその繋がりが表示され、更にそれを修正することも出来ます。その為、現状コードしか無く構成図が無いチームでも、Application Composerを利用して構成図を作成することが可能になります。Application Composerでサポートされていないリソースも取り込むことは可能ですが、設定の変更等は出来ず画面に出てくるだけです。

ちなみに、Application Composer単体ではデプロイが出来ないため、インフラコード作成の支援ツールという立ち位置になります。 また、Application Composerの発表時点で作成できるコードはSAMテンプレートのみとなっております。CDKやTerraformのサポートは現状無いみたいですが、必要性を説いていけば追加されると開発Tの方が言っていました。なのでこのブログを書いています。

やってみた

上記のように文字だけの説明だと分かりにくいので、実際にApplication Composerを利用してみましょう。

S3→Lambdaの構成を例として作ってみます。 まず左のメニューからS3探し、右側へドラッグ&ドロップしてみます。

すると、コードに下記のようなS3リソースが作られます。

Resources:
  Bucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub ${AWS::StackName}-bucket-${AWS::AccountId}
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          - ServerSideEncryptionByDefault:
              SSEAlgorithm: aws:kms
              KMSMasterKeyID: alias/aws/s3
      PublicAccessBlockConfiguration:
        IgnorePublicAcls: true
        RestrictPublicBuckets: true
  BucketBucketPolicy:
    Type: AWS::S3::BucketPolicy
    Properties:
      Bucket: !Ref Bucket
      PolicyDocument:
        Id: RequireEncryptionInTransit
        Version: '2012-10-17'
        Statement:
          - Principal: '*'
            Action: '*'
            Effect: Deny
            Resource:
              - !GetAtt Bucket.Arn
              - !Sub ${Bucket.Arn}/*
            Condition:
              Bool:
                aws:SecureTransport: 'false'

S3バケットの設定として、サーバサイド暗号化が入っていたり、暗号化された通信のみ接続出来るようになっていたりとWell-Architectedな設定になっていることが分かります。

次に、S3のアイコンをクリックすると下記のように現在の設定が見られます。 そこで、S3の設定を下記のようにパブリックアクセスブロックを無しに変更してみます。

すると、コードもそれに合わせて変更されていることが分かります。

              SSEAlgorithm: aws:kms
              KMSMasterKeyID: alias/aws/s3
-      PublicAccessBlockConfiguration:
-        IgnorePublicAcls: true
-        RestrictPublicBuckets: true
  BucketBucketPolicy:
    Type: AWS::S3::BucketPolicy

では、次にLambdaを配置すると、そのコードも追加されます。 

              Bool:
                aws:SecureTransport: 'false'
+  Function:
+    Type: AWS::Serverless::Function
+    Properties:
+      Description: !Sub
+        - Stack ${AWS::StackName} Function ${ResourceName}
+        - ResourceName: Function
+      CodeUri: src/Function
+      Handler: index.handler
+      Runtime: nodejs18.x
+      MemorySize: 3008
+      Timeout: 30
+      Tracing: Active
+  FunctionLogGroup:
+    Type: AWS::Logs::LogGroup
+    DeletionPolicy: Retain
+    Properties:
+      LogGroupName: !Sub /aws/lambda/${Function}
+Transform: AWS::Serverless-2016-10-31

ここでS3と違うのが、Lambdaを配置するとテンプレート修正だけでなく、アプリケーションコードの雛形が作られます。最初はLambdaの言語設定がNode.jsを指定しているので、index.jsとpackage.jsonが作成されます。これをPythonに変更するとhandler.pyとrequirements.txtが出来ます。

ちなみに、現在Lambdaの名前や言語の変更をすると変更前のファイルやディレクトリが残ってしまう事に注意が必要です。現在プレビュー中なので、適宜修正されると思います。

そして、S3からLambdaに線を引くと、下記のようにS3にオブジェクトを配置・削除することでLambdaが起動されるように修正されます。 

      Timeout: 30
      Tracing: Active
+      Events:
+        Bucket:
+          Type: S3
+          Properties:
+            Bucket: !Ref Bucket
+            Events:
+              - s3:ObjectCreated:*
+              - s3:ObjectRemoved:*
  FunctionLogGroup:
    Type: AWS::Logs::LogGroup

発火するイベントはApplication Composerからは設定出来ないので、出力後のテンプレートを修正することになります。

さらに面白いのが、S3とLambdaの順番を逆にすると、

下記のようにLambdaの環境変数にS3の名前とarnが自動でセットされます。

      Timeout: 30
      Tracing: Active
+      Environment:
+        Variables:
+          BUCKET_NAME: !Ref Bucket
+          BUCKET_ARN: !GetAtt Bucket.Arn
+      Policies:
+        - S3CrudPolicy:
+            BucketName: !Ref Bucket
  FunctionLogGroup:
    Type: AWS::Logs::LogGroup

このように、リソース間の前後関係もしっかり理解してテンプレートが出来るので、触っていて非常に楽しいです。また、変更される内容を見てこういう書き方をするのかと勉強にもなるので、勉強ツールとしても良い気がしました。繋ぐことが出来ない場合はエラーが出るので、アーキテクチャ的に接続出来ないことについても学ぶことが出来ます。

ちなみに、デプロイが出来ない部分はSAMで補うことになります。Application Composer画面はローカルのファイルと同期出来ます。そのため、 sam sync --watch を実行すると、画面から変更した時に自動的にSAMからデプロイする事が出来るので非常に便利です。もし、Application Composerの出力にCDKがサポートされるようになると、同じようにcdk watchコマンドで同じことが出来るようになるはずです。

CloudFormationデザイナーとの違い

ちなみに、似ているサービスとしてCloudFormationデザイナーがあります。使い分けとしては、CloudFormationデザイナーはCloudFormationテンプレートの視覚化で、Application ComposerはSAMテンプレートの視覚化になります。CloudFormationデザイナーはIAMなど全リソースの表示がされますが、Application Composerは必要最低限になります。同じテンプレートをCloudFormationデザイナーとApplication Composerで出力したものが下記になります。

左がCloudFormationデザイナーで、右がApplication Composerになります。CloudFormationデザイナーのほうはログとバケットポリシーが追加で出ています。バケットポリシーはS3バケットへ矢印が出てるので繋がっていることが分かりますが、ログについては孤立しているので何のためのものかこの図からは判断出来ません。逆にApplication Composerに関してはバケットポリシーやログについての記載が無くシンプルですが、その2つがあるのかどうかが判断が出来ません。昔ながらのインフラな方はこの状況が少し苦手かもしれません。どちらが良い悪いなどは無いですが、全て見たいのかざっくり見たいのかで使い分けていけば良いでしょう。

Application Composer + SAMとCDKの比較

サーバレスアーキテクチャを構築するAWSのメジャーなIaCツールはSAMですが、私は大好きなCDKも使っています。なので、Application Composer + SAMとCDKをそれぞれ比較してそれぞれのターゲットを見ていきます。TerraformやPulumiに関しては比較は行いませんが、CDKとそこまで大きく変わることも無いのでCDKでの比較を参考にしてください。

できること

サーバレスアーキテクチャを構築するにあたって、各ツールのできる範囲は下記の通りになります。

SAMはテンプレートを直接コーディングするのに対してCDKはプログラミング言語を介してテンプレートを生成しています。また、Application ComposerはGUIの画面を通してテンプレートを生成していますが、デプロイは出来ません。そのため、デプロイ部分をSAMで利用することで、CDKと同じようにコーディングからデプロイまで一貫して行うことができます。

必要な知識

必要な知識としては、どのツールを利用するにあたっても、構築するサーバレスアーキテクチャに関する知識は必要かと思います。Application Composerは他に画面の操作方法が分かれば、リソースを組み合わせるだけでテンプレートを作れます。他のSAMやCDKはサーバレスアーキテクチャに関する知識やツールの操作方法は同じく必要で、追加でコードに関するyaml/json、各種言語の知識が必要になります。

Application Composerは必要な知識が少ないので、構築初心者の方などに非常に良いツールかと思われます。また、Application Composerを利用して学ぶことも出来るので構築初心者の方は是非使ってほしいサービスになります。ある程度SAMの知識がある場合は、最初はApplication Composerを利用して後からSAMで詳細を詰める利用方法が最も効率の良い進め方になります。Application Composer+SAMとCDKを比較すると、必要な知識量に差はあまり無いです。

構築スピード

構築する速さとしては、圧倒的にApplication Composerが早いです。むしろ早すぎてデプロイ追いつかない問題が出てきそうなレベルです。SAM比較すると若干CDKの方がプログラミング言語を利用しているというメリットがあるため構築スピードは早いです。なので、Application Composerで作成したテンプレートから修正する点が多ければ多いほどApplication COmposer+SAMよりCDKの方が早く構築できます。

網羅率

Application Composerのスピードは早いですが、サポートされていないリソースや細かい設定は出来ないので、その部分はSAMで設定することになります。それに対して、CDKは大体のリソースとその設定は可能です。そのため、サーバレス以外のリソースも合わせて利用する場合や、細かい設定・権限制御を入れたい場合は最初からCDKが良いかと思われます。例えばS3->Lambda構成をApplication Composerから作ると、オブジェクトの作成・削除でLambdaを起動するようなテンプレートが作られます。しかし、削除時にLambdaを起動したくない場合はSAMから修正が必要です。このようなApplication Composerだけで終わらない修正が所々入るのであればCDKが良いです。

コード量

SAMとCDKでコード量の比較をしてみます。対象リソースが少ないうちはSAMとCDKは同じくらいのコード量になるかと思います。しかし、対象リソースが増えてくると、CDKだと同じものを括って関数化出来るので、その分コード量は減ります。またCDKは書くべき設定も最小限になっているので、その分少なく書くことが出来ます。そのため、大規模なものはCDKの方がコード量としては少なくなります。

比較のまとめ

では、比較した内容をまとめます。

Application Composer + SAM CDK
デプロイ 可能 可能
自動デプロイ 可能 可能
インタフェース GUI/CUI CUI
言語 yaml/json Python/TypeScript/JavaScript/Java/C#/Go
必要な知識 サーバレスアーキテクチャ
ツールの使い方
yaml/json 		サーバレスアーキテクチャ
ツールの使い方
プログラミング言語
構築スピード 早い＋遅い 普通
網羅性 広い 広い
コード量 多い 少ない

上記をまとめると、Application Composer + SAMのターゲットとしては、下記になります。

  • サーバレスアーキテクチャ初心者が多いチーム
  • 小規模アーキテクチャ
  • サーバレス以外のアーキテクチャが少ないもの
  • セキュリティなどの独自要件が多くないもの

逆にCDKのターゲットとしては下記になります。

  • 大規模アーキテクチャ
  • サーバレス以外のアーキテクチャも多く採用している
  • 様々な要件が発生するもの

そのため、自分たちのチームがどれに当てはまるかを考えて選択していくべきです。

Application ComposerにCDKを適用する意義

今までの話でApplication Composerを使うことのメリットは下記になります。

  • 初心者がコードの書き方を学べる
  • コーディングのスピードアップ
  • コードがWell-Architectedな状態になる

CDKとしても3番目の「Well-Architectedな状態になる」に関してはクリア出来ています。しかし、1番目と2番目に関してはCDKだけでは対応出来ません。

そこで、Application ComposerにCDKが適用されると、下記のような構成になります。

まずはユーザはApplication ComposerのGUI画面でアーキテクチャを作り、そこからCDKのコードが出力されます。今まではCDKドキュメントを眺めて必要なリソースのページからサンプルをコピーしてトライアンドエラーを繰り返して作っていきました。公式ドキュメントですら間違っているコードもあるので、そこを適宜修正する必要がありました。それをApplication Composerから変換できれば、基本的には修正する必要のないコードが出来上がるので、最初のドキュメント探しとコード修正の時間が不要になります。

また、今回利用したS3->Lambdaの構成でS3からLambdaに線を繋いだ時にCDKコードでlambda_.add_event_sourceのコードが追加されることで、Lambdaの関数からイベントの追加が出来る事も学べます。今までは検索するかドキュメントからなんとか探し当てるしか無かったので、圧倒的な時間の節約になります。

なので、Application ComposerからCDKサポートされると、初心者の敷居が下がりコーディングスピードも劇的に上がるので、CDK人口がどんどん増えてハッピーになる未来しか見えません。皆さんガンガン要望上げていきましょう。

さいごに

Application Composerはサーバレスアーキテクチャを始めたばかりの方にとっては視覚的に作れるのですごく良いサービスなので、周りにドンドン勧めていってサーバレス作れる人材を増やしていきましょう。そして、CDKがサポートされるとプログラミング言語だからと敬遠していた人たちも入りやすくなるので、CDKサポートされる日を楽しみにしています。

では、踏まれて壊れたライトセーバーの捨て方を調べてきます。

執筆者志水友輔

2021/2022 APN ALL AWS Certifications Engineers & 2021 AWS Top Engineer
大阪でAWSを中心としたクラウドの導入、設計、構築を専門に行っています。

Twitter：https://twitter.com/shimi023

Amazon著者ページ：Amazon.co.jp: 志水友輔:作品一覧、著者略歴