AWS Lambdaを使用したサービス指向アーキテクチャ：ステップバイステップのチュートリアル

公開: 2022-03-11

Webアプリケーションを構築する場合、コミットすると将来的にアプリケーションを支援または妨害する可能性のある多くの選択肢があります。 言語、フレームワーク、ホスティング、データベースなどの選択は非常に重要です。

そのような選択の1つは、サービス指向アーキテクチャー（SOA）を使用してサービスベースのアプリケーションを作成するか、従来のモノリシックアプリケーションを作成するかです。 これは、スタートアップ、スケールアップ、およびエンタープライズ企業に同様に影響を与える一般的なアーキテクチャ上の決定です。

サービス指向アーキテクチャーは、多くの有名なユニコーンや、Google、Facebook、Twitter、Instagram、Uberなどのトップテクノロジー企業によって使用されています。 このアーキテクチャパターンは大企業では機能するようですが、あなたにとっては機能しますか？

AWS Lambdaを使用したサービス指向アーキテクチャ：ステップバイステップのチュートリアル

AWS Lambdaを使用したサービス指向アーキテクチャ：ステップバイステップのチュートリアル
つぶやき

この記事では、サービス指向アーキテクチャーのトピックと、AWS LambdaをPythonと組み合わせて活用して、スケーラブルでコスト効率の高いサービスを簡単に構築する方法を紹介します。 これらのアイデアを示すために、Python、AWS Lambda、Amazon S3、およびその他のいくつかの関連ツールとサービスを使用して、単純な画像のアップロードとサイズ変更のサービスを構築します。

サービス指向アーキテクチャとは何ですか？

サービス指向アーキテクチャー（SOA）は新しいものではなく、数十年前にルーツを持っています。 近年、Web向けアプリケーションに多くのメリットを提供することにより、パターンとしての人気が高まっています。

本質的に、SOAは、1つの大きなアプリケーションを多くの通信する小さなアプリケーションに抽象化したものです。 これは、分離、関心の分離、単一責任アーキテクチャなど、ソフトウェアエンジニアリングのいくつかのベストプラクティスに従います。

SOAの実装は、粒度の点で異なります。機能の広い領域をカバーする非常に少数のサービスから、「マイクロサービス」アーキテクチャと呼ばれる数十または数百の小さなアプリケーションまでです。 粒度のレベルに関係なく、SOAの実践者の間で一般的に合意されているのは、それが決して無料の昼食ではないということです。 ソフトウェアエンジニアリングの多くのグッドプラクティスと同様に、それは追加の計画、開発、およびテストを必要とする投資です。

AWS Lambdaとは何ですか？

AWS Lambdaは、アマゾンウェブサービスプラットフォームによって提供されるサービスです。 AWS Lambdaを使用すると、Amazonが管理するオンデマンドコンテナで実行されるコードをアップロードできます。 AWS Lambdaは、コードを実行するサーバーのプロビジョニングと管理を管理するため、ユーザーが必要とするのは、実行するコードのパッケージセットと、サーバーが実行されるコンテキストを定義するためのいくつかの構成オプションだけです。 これらのマネージドアプリケーションは、Lambda関数と呼ばれます。

AWS Lambdaには、2つの主要な操作モードがあります。

非同期/イベント駆動型：

Lambda関数は、非同期モードのイベントに応答して実行できます。 S3、SNSなどのイベントのソースはブロックされず、Lambda関数は、イベントのチェーンの処理パイプラインを確立するなど、さまざまな方法でこれを利用できます。 多くの情報ソースがあり、ソースに応じて、イベントはイベントソースからLambda関数にプッシュされるか、AWSLambdaによってイベントがポーリングされます。

同期/要求->応答：

応答を同期的に返す必要があるアプリケーションの場合、Lambdaを同期モードで実行できます。 通常、これはAPI Gatewayと呼ばれるサービスと組み合わせて使用​​され、AWS LambdaからエンドユーザーにHTTP応答を返しますが、Lambda関数はAWSLambdaへの直接呼び出しを介して同期的に呼び出すこともできます。

AWS Lambda関数は、ハンドラーの操作に必要な依存関係に加えて、ハンドラーコードを含むzipファイルとしてアップロードされます。 アップロードされると、AWS Lambdaは必要に応じてこのコードを実行し、消費者が特別な介入を必要とせずに、サーバーの数を0から数千にスケーリングします。

LambdaはSOAの進化として機能します

基本的なSOAは、この記事で前述した方法でアプリケーションに利益をもたらすために、コードベースを小さなアプリケーションに構造化する方法です。 このことから、これらのアプリケーション間の通信方法に焦点が当てられます。 イベント駆動型SOA（別名SOA 2.0）は、SOA 1.0の従来の直接的なサービス間通信だけでなく、変更を通信するためにアーキテクチャ全体にイベントを伝播することも可能にします。

イベント駆動型アーキテクチャは、緩い結合と構成可能性を自然に促進するパターンです。 イベントを作成してそれに反応することにより、サービスをアドホックに追加して既存のイベントに新しい機能を追加したり、いくつかのイベントを構成してより豊富な機能を提供したりできます。

AWS Lambdaは、SOA2.0アプリケーションを簡単に構築するためのプラットフォームとして使用できます。 Lambda関数をトリガーする方法はたくさんあります。 Amazon SNSを使用した従来のメッセージキューアプローチから、Amazon S3にアップロードされたファイルによって作成されたイベント、またはAmazonSESで送信されたEメールまで。

シンプルな画像アップロードサービスの実装

AWSスタックを利用して画像をアップロードおよび取得するためのシンプルなアプリケーションを構築します。 このサンプルプロジェクトには、2つのラムダ関数が含まれます。1つは単純なWebフロントエンドを提供するために使用されるrequest-> responseモードで実行され、もう1つはアップロードされた画像を検出してサイズを変更します。

最初のラムダ関数は、アップロードされた画像を格納するS3バケットでトリガーされたファイルアップロードイベントに応答して非同期で実行されます。 提供された画像を取得し、400x400の画像に収まるようにサイズを変更します。

他のラムダ関数はHTMLページを提供し、ユーザーが他のラムダ関数によってサイズ変更された画像を表示する機能と、画像をアップロードするためのインターフェイスの両方を提供します。

AWSの初期設定

始める前に、IAMやS3などの必要なAWSサービスを設定する必要があります。 これらは、ウェブベースのAWSコンソールを使用して設定されます。 ただし、ほとんどの設定は、後で使用するAWSコマンドラインユーティリティを使用して行うこともできます。

S3バケットの作成

S3（またはSimple Storage Service）は、あらゆるデータの信頼性が高く費用効果の高いストレージを提供するAmazonオブジェクトストアサービスです。 S3を使用して、アップロードされる画像と、処理した画像のサイズ変更されたバージョンを保存します。

S3サービスは、AWSコンソールの[ストレージとコンテンツ配信]サブセクションの[サービス]ドロップダウンにあります。 バケットを作成するときに、バケット名とリージョンの両方を入力するように求められます。 ユーザーに近いリージョンを選択すると、S3はレイテンシーとコスト、およびいくつかの規制要因を最適化できます。 この例では、「USStandard」リージョンを選択します。 この同じリージョンは、後でAWSLambda関数をホストするために使用されます。

S3バケット名は一意である必要があるため、選択した名前を使用する場合は、新しい一意の名前を選択する必要があることに注意してください。

このサンプルプロジェクトでは、「test-upload」と「test-resized」という名前の2つのストレージバケットを作成します。 「test-upload」バケットは、画像をアップロードし、アップロードされた画像を処理してサイズ変更する前に保存するために使用されます。 サイズが変更されると、画像は「テストサイズ変更」バケットに保存され、アップロードされた生の画像が削除されます。

S3アップロード権限

デフォルトでは、S3パーミッションは制限されており、外部ユーザーまたは非管理ユーザーでさえ、バケット上のパーミッションまたはオブジェクトの読み取り、書き込み、更新、または削除を許可しません。 これを変更するには、AWSバケットのアクセス許可を管理する権限を持つユーザーとしてログインする必要があります。

AWSコンソールを使用している場合、バケットを名前で選択し、画面の右上にある[プロパティ]ボタンをクリックして、折りたたまれた[アクセス許可]セクションを開くと、アップロードバケットのアクセス許可を表示できます。

匿名ユーザーがこのバケットにアップロードできるようにするには、バケットポリシーを編集して、アップロードを許可する特定の権限を許可する必要があります。 これは、JSONベースの構成ポリシーによって実現されます。 この種のJSONポリシーは、IAMサービスと組み合わせてAWS全体で広く使用されています。 [バケットポリシーの編集]ボタンをクリックしたら、次のテキストを貼り付けて[保存]をクリックし、公開画像のアップロードを許可します。

 { "Version": "2008-10-17", "Id": "Policy1346097257207", "Statement": [ { "Sid": "Allow anonymous upload to /", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::test-upload/*" } ] }

これを行った後、バケットに画像をアップロードすることで、バケットポリシーが正しいことを確認できます。 次のcURLコマンドでうまくいきます。

 curl https://test-upload.s3.amazonaws.com -F 'key=test.jpeg' -F '[email protected]'

200範囲の応答が返された場合、アップロードバケットの構成が正常に適用されたことがわかります。 これで、S3バケットが（ほとんど）構成されているはずです。 画像アップロードイベントをサイズ変更関数の呼び出しに接続するために、後でコンソールでこのサービスに戻ります。

LambdaのIAM権限

Lambdaロールはすべて、パーミッションコンテキスト内で実行されます。この場合、IAMサービスによって定義された「ロール」です。 このロールは、Lambda関数が呼び出し中に持つすべての権限を定義します。 このサンプルプロジェクトの目的のために、両方のLambda関数間で使用される汎用ロールを作成します。 ただし、実稼働シナリオでは、セキュリティの悪用が定義されたアクセス許可コンテキストのみに分離されるように、アクセス許可の定義をより細かくすることをお勧めします。

IAMサービスは、[サービス]ドロップダウンの[セキュリティとID]サブセクションにあります。 IAMサービスは、AWSサービス全体のアクセスを管理するための非常に強力なツールであり、同様のツールに慣れていない場合、提供されるインターフェイスは最初は少し圧倒される可能性があります。

IAMダッシュボードページが表示されると、ページの左側に「役割」サブセクションが表示されます。 ここから、「新しい役割の作成」ボタンを使用して、役割の権限を定義するためのマルチステップウィザードを表示できます。 一般的なパーミッションの名前として「lambda_role」を使用しましょう。 名前の定義ページから続行すると、役割の種類を選択するオプションが表示されます。 S3アクセスのみが必要なため、「AWS Service Roles」をクリックし、選択ボックス内で「AWSLambda」を選択します。 この役割に関連付けることができるポリシーのページが表示されます。 「AmazonS3FullAccess」ポリシーを選択し、次の手順に進んで、作成するロールを確認します。

作成されたロールの名前とARN（Amazonリソース名）に注意することが重要です。 これは、関数の呼び出しに使用されるロールを識別するために新しいLambda関数を作成するときに使用されます。

注： AWS Lambdaは、ロギングサービスであるAWSCloudwatchの関数呼び出しからのすべての出力を自動的にログに記録します。 実稼働環境で推奨されるこの機能が必要な場合は、Cloudwatchログストリームへの書き込み権限をこのロールのポリシーに追加する必要があります。

コード！

概要

これで、コーディングを開始する準備が整いました。 この時点で、「awscli」コマンドを設定したと想定します。 そうでない場合は、https：//aws.amazon.com/cli/の指示に従って、コンピューターにawscliをセットアップできます。

注：これらの例で使用されているコードは、画面を表示しやすくするために短くなっています。 より完全なバージョンについては、https：//github.com/gxx/aws-lambda-python/のリポジトリにアクセスしてください。

まず、プロジェクトのスケルトン構造を設定しましょう。

 aws-lambda-python/ - image_list/ - handler.py - list.html - Makefile - requirements.txt - image_resize/ - handler.py - resize.py - Makefile - requirements.txt - .pydistutils.cfg

構造体には2つのサブディレクトリがあり、ラムダ関数ごとに1つずつあります。 これらのそれぞれに、共通のhandler.py、Makefile、およびrequirements.txtファイルがあります。 handler.pyファイルには、各ラムダ関数の呼び出しを呼び出すメソッドが含まれ、関数のエントリポイントと見なすことができます。 Requirements.txtファイルには依存関係のリストが含まれているため、要件を簡単に指定および更新できます。 最後に、awscliと対話するための簡単なメカニズムを提供するために使用するMakefileコマンド。 これにより、ラムダ関数の作成と更新のプロセスがはるかに簡単になります。

プロジェクトディレクトリのルートにある.pydistutils.cfgファイルに気付くでしょう。 このファイルは、HomebrewでPythonを使用している場合に必要です。 Lambda関数（次のセクションで説明）をデプロイする方法のため、このファイルが必要です。 詳細については、リポジトリを参照してください。

画像ラムダ関数のサイズ変更

コード

resize_image関数から始めて、 Wand==0.4.2をrequirements.txtに保存することにより、画像処理ライブラリであるWand依存関係をフリーズします。 これは、image_resizeラムダ関数の唯一の依存関係になります。 resize.pyのresize_image関数は、Wandライブラリの画像リソースを処理し、指定された幅と高さのパラメーターに従ってサイズを変更する必要があります。 サイズ変更中の画像を保持するために、元の画像の画像比率を維持しながら、指定された幅と高さに収まるように画像サイズを縮小する「最適な」サイズ変更アルゴリズムを使用します。

 def resize_image(image, resize_width, resize_height): ... original_ratio = image.width / float(image.height) resize_ratio = resize_width / float(resize_height) # We stick to the original ratio here, regardless of what the resize ratio is if original_ratio > resize_ratio: # If width is larger, we base the resize height as a function of the ratio of the width resize_height = int(round(resize_width / original_ratio)) else: # Otherwise, we base the width as a function of the ratio of the height resize_width = int(round(resize_height * original_ratio)) if ((image.width - resize_width) + (image.height - resize_height)) < 0: filter_name = 'mitchell' else: filter_name = 'lanczos2' image.resize(width=resize_width, height=resize_height, filter=filter_name, blur=1) return image

それが邪魔にならないように、ハンドラー関数は、アップロードされた画像S3によって生成されたイベントを受け入れ、それをresize_image関数に渡し、結果のサイズ変更された画像を保存する必要があります。

 from __future__ import print_function import boto3 from wand.image import Image from resize import resize_image def handle_resize(event, context): # Obtain the bucket name and key for the event bucket_name = event['Records'][0]['s3']['bucket']['name'] key_path = event['Records'][0]['s3']['object']['key'] response = boto3.resource('s3').Object(bucket_name, key_path).get() # Retrieve the S3 Object # Perform the resize operation with Image(blob=response['Body'].read()) as image: resized_data = resize_image(image, 400, 400).make_blob() # And finally, upload to the resize bucket the new image s3_connection.Object('test-resized', key_path).put(ACL='public-read', Body=resized_data) # Finally remove, as the bucket is public and we don't want just anyone dumping the list of our files! s3_object.delete()

展開

コードが完成したら、新しいLambda関数としてAmazonLambdaにアップロードする必要があります。 ここで、ディレクトリ構造に追加されたMakefileが機能します。 このMakefileは、作成しているLambda関数定義をデプロイするために使用されます。

 ROLE_ARN = arn:aws:iam::601885388019:role/lambda_role FUNCTION_NAME = ResizeImage REGION = us-west-1 TIMEOUT = 15 MEMORY_SIZE = 512 ZIPFILE_NAME = image_resize.zip HANDLER = handler.handle_resize clean_pyc : find . | grep .pyc$ | xargs rm install_deps : pip install -r requirements.txt -t . build : install_deps clean_pyc zip $(ZIPFILE_NAME) -r * create : build aws lambda create-function --region $(REGION) \ --function-name $(FUNCTION_NAME) \ --zip-file fileb://$(ZIPFILE_NAME) \ --role $(ROLE_ARN) \ --handler $(HANDLER) \ --runtime python2.7 \ --timeout $(TIMEOUT) \ --memory-size $(MEMORY_SIZE) update : build aws lambda update-function-code --region $(REGION) \ --function-name $(FUNCTION_NAME) \ --zip-file fileb://$(ZIPFILE_NAME) \ --publish

このMakefileの主な機能は、「作成」と「更新」です。 これらの関数は、最初に現在のディレクトリをパッケージ化します。これは、Lambda関数を実行するために必要なすべてのコードを表します。 次に、 requirements.txtファイルで指定された依存関係が、パッケージ化される現在のサブディレクトリにインストールされます。 パッケージ化の手順では、ディレクトリの内容をzipして、後で「awscli」コマンドを使用してアップロードします。 Makefileは、他のLambda関数定義での使用に適合させることができます。

ユーティリティMakefileでは、イメージの作成/更新に必要ないくつかの変数を定義します。 Makefileコマンドが正しく機能するように、必要に応じてこれらを構成します。

  • ROLE_ARN ：これは、Lambda関数を実行するためのロールを識別するAmazonリソース名です。
  • FUNCTION_NAME ：作成/更新しているLambda関数の名前。
  • REGION ：Lambda関数が作成/更新されるリージョン。
  • TIMEOUT ：Lambda呼び出しが強制終了されるまでの秒単位のタイムアウト。
  • MEMORY_SIZE ：Lambda関数が呼び出されたときにアクセスできるメモリのサイズ（メガバイト単位）。
  • ZIPFILE_NAME ：Lambda関数コードと依存関係を含むzip形式のパッケージの名前。
  • HANDLER ：ハンドラー関数のドット表記での絶対インポートパス。

構成が完了したら、 make createコマンドを実行すると、次のような出力が生成されます。

 $ make create pip install -r requirements.txt -t . ... find . | grep .pyc| xargs rm zip image_resize.zip -r * ... aws lambda create-function --region ap-northeast-1 \ --function-name ResizeImage2 \ --zip-file fileb://image_resize.zip \ --role arn:aws:iam::11111111111:role/lambda_role \ --handler handler.handle_resize \ --runtime python2.7 \ --timeout 15 \ --memory-size 512 { "CodeSha256": "doB1hsujmZnxZHidnLKP3XG2ifHM3jteLEBvsK1G2nasKSo=", "FunctionName": "ResizeImage", "CodeSize": 155578, "MemorySize": 512, "FunctionArn": "arn:aws:lambda:us-west-1:11111111111:function:ResizeImage", "Version": "$LATEST", "Role": "arn:aws:iam::11111111111:role/lambda_role", "Timeout": 15, "LastModified": "2016-01-10T11:11:11.000+0000", "Handler": "handler.handle_resize", "Runtime": "python2.7", "Description": "" }

テスト

作成コマンドを実行すると、画像のサイズ変更機能を使用できるようになりますが、イベントを受信するためにS3バケットに接続されていません。 AWSコンソールを介して関数をテストし、関数がS3ファイルのアップロードイベントを適切に処理することを確認できます。 [サービス]ドロップダウンの[計算]サブセクションにあるAWSLambdaダッシュボードで、作成した関数の名前を選択します。 このLambda関数の詳細ページには、「テストイベントの設定」というラベルの付いたオプションを含む「アクション」というラベルの付いたドロップダウンがあります。

これをクリックするとモーダルが開き、テストイベントといくつかのサンプルテンプレートを指定できます。 「S3Put」の例を選択し、バケット名の記載を、設定されているバケットの名前に置き換えます。 これが設定されると、Lambda関数のページで「テスト」ボタンを使用すると、以前に設定されたイベントが実際に発生したかのようにLambda関数が呼び出されます。

エラースタックトレースまたはログメッセージを監視するために、Cloudwatchでログストリームを表示できます。 Lambda関数が作成されると同時に、新しいロググループが作成されます。 これらのログストリームは便利であり、他のサービスにパイプすることができます。

S3バケットイベントへの接続

S3ダッシュボードに戻り、[プロパティ]メニューにある折りたたまれた[イベント]セクションを展開して、[イベント通知]フォームを表示します。 入力する必須フィールドは、「イベント」と「送信先」の入力です。 「イベント」から「オブジェクト作成（すべて）」イベントを選択します。 これにより、アップロードバケットにオブジェクトを作成するすべてのイベントをインターセプトできます。 「SentTo」入力には、「Lambdafunction」ラジオボタンを選択します。 オプションとして設定した「ResizeImage」ラムダ関数を含むドロップダウンを含む新しいセクションが表示されます。 「保存」をクリックすると、「オブジェクト作成」イベントが「ResizeImage」Lambda関数の呼び出しへの入力としてルーティングされるようになります。

これで、アプリケーションのコア機能ができました。 別のcURLテストを実行して、すべてが期待どおりに機能していることを確認しましょう。 cURLを使用して画像をS3バケットにアップロードし、画像がサイズ変更バケットにアップロードされていることを手動で確認します。

 curl https://test-upload.s3.amazonaws.com -F 'key=test.jpeg' -F '[email protected]'

このコマンドを実行すると、Lambda関数がすでに「ウォームアップ」されているかどうかに応じて、サイズ変更されたイメージが50〜1000ミリ秒後に「テストサイズ変更」バケットに作成されます。

リスト画像ラムダ関数

コード

ListImage Lambda関数は、サイズ変更された画像のリストを取得し、ユーザーのHTMLページに表示します。 このHTMLページは、ユーザーが自分の画像をアップロードするための機能も提供します。 Jinja2は、テンプレート定義からHTMLをレンダリングする関数で使用されます。 以前と同様に、これらの要件はrequirements.txtファイルで指定されています。

 from __future__ import print_function import os import boto3 from jinja2 import Environment from jinja2 import FileSystemLoader def _render_template(image_urls): env = Environment(loader=FileSystemLoader(os.path.abspath(os.path.dirname(__file__)))) template = env.get_template('list.html') rendered_template = template.render(image_urls=image_urls) return rendered_template def handle_list_image(event, context): bucket = boto3.resource('s3').Bucket('test-resized') image_summaries = sorted((image_summary for image_summary in bucket.objects.all()), key=lambda o: o.last_modified) image_urls = [] for summary in image_summaries: image_urls.append( boto3.client('s3').generate_presigned_url( 'get_object', Params={ 'Bucket': summary.bucket_name, 'Key': summary.key } ) ) return {'htmlContent': _render_template(image_urls)}
 <html> <head> <title>List Images</title> <script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.4/jquery.min.js"></script> <script> var uploadImage = (function () { var inProgress = false; return function () { if (inProgress) { return; } inProgress = true; var formData = new FormData(); var fileData = $('#image-file').prop('files')[0]; formData.append('key', parseInt(Math.random() * 1000000)); formData.append('acl', 'public-read'); formData.append('file', fileData); $.ajax({ url: 'https://test-upload.s3.amazonaws.com/', type: 'POST', data: formData, processData: false, contentType: false, success: function (data) { window.location.reload(); } }); } })(); </script> <style type="text/css"> .image__container { float: left; width: 30%; margin-left: 2.5%; margin-right: 2.5%; max-width: 400px; } </style> </head> <body> <nav> <input type="file" onchange="uploadImage()" value="Upload Image" /> </nav> <section> {% for image_url in image_urls %} <div class="image__container"> <img src="{{ image_url }}" /> </div> {% endfor %} </section> </body> </html>

ここでも、前のMakefileを変更し、createコマンドを使用してラムダ関数をデプロイできます。

APIゲートウェイ

ImageList Lambda関数は完了していますが、どのユーザーにも提供できません。 これは、Lambda関数は、別のサービスからのイベントに応答して、またはプログラムでのみ呼び出すことができるためです。 ここで、Amazon AWSAPIGatewayサービスが導入されます。 API Gatewayは、「アプリケーションサービス」サブセクションにあります。

API Gatewayは、エンドポイントを一連のリソースとメソッド、本質的にはRESTインターフェースとしてモデル化する方法です。 API Gatewayは、リクエストを検証および変換する機能を提供するだけでなく、スロットル/レート制限リクエストの提供などの他の機能を実行します。

API Gatewayダッシュボードから、ListImage関数を提供するための新しいAPIを作成します。 名前と説明はお好みに合わせて設定できます。 作成したら、新しいAPIの名前をクリックして、APIの詳細にアクセスします。 ルートURL「/」の新しいリソースを作成します。 このURLは、HTMLページを提供するために使用されます。

ルートリソースページの詳細を表示しながら、GETメソッドを追加します。 「IntegrationType」を「LambdaFunction」に設定し、「LambdaRegion」を「us-west-1」または選択したリージョンに設定して、ListImageLambda関数の名前を入力します。

応答をHTML出力にマッピングする前に、この応答をコンテンツタイプにマッピングすることに加えて、サーバーからの応答のスキーマを定義する「モデル」を定義する必要があります。 APIの「モデル」セクションを選択し、「作成」をクリックして新しいモデルを作成します。 モデルに「HTML」という名前を付け、コンテンツタイプを「text / html」にして、スキーマを次のように定義します。

 { "$schema": "http://json-schema.org/draft-04/schema#", "title" : "HTML", "type" : "object" }

APIダッシュボードに戻り、作成したリソースを選択して、「統合応答」セクションに移動します。 このセクションでは、Lambda関数から応答を受け取った後、応答を最終ステップにパイプする前に処理する変換を定義します。

「マッピングテンプレート」セクションを開き、「text/html」の新しい「コンテンツタイプ」を追加します。 古い「コンテンツタイプ」を同時に削除します。 右側で、ドロップダウンを「出力パススルー」から「マッピングテンプレート」に変更します。 これにより、API Gatewayで受け入れられる生のJSONを変更し、代わりに、返されたデータの「htmlContent」プロパティ内のHTMLコンテンツを使用できるようになります。 マッピングテンプレートには、テンプレートとして「$input.htmlContent」を指定します。 最後に、「ResponseModelsfor200」から「application/json」を削除し、代わりに「text / html」を追加して、「MethodResponse」セクションを変更します。

APIのダッシュボードに戻ると、ページの左上に「DeployAPI」というラベルの付いたボタンがあります。 このボタンをクリックして、指定されたリソース、メソッド、モデル、およびマッピングを使用してAPIを更新または作成します。 これが完了すると、選択された展開ステージ（デフォルトではステージング）のURLが表示されます。 最後に、例が完成しました。 いくつかのファイルをアップロードして、サイズ変更された画像をテストおよび表示できます。

まとめ

AWSは大規模なサービスであり、すぐになくなることはありません。 ベンダーロックインは常に注意が必要ですが、AWS Lambdaは、豊富な補助構成オプションを備えた比較的薄いサービスを提供します。 AWSが提供するサービスを活用して、スケーラブルで保守が容易なアプリケーションを実装すると、AWSプラットフォームを使用する最大のメリットが得られます。 AWS Lambdaは、非常に多くの消費者が使用するエンタープライズグレードのプラットフォームに裏打ちされた、エレガントでスケーラブルで費用効果の高いソリューションを提供します。 「サーバーレス」アプリケーションは未来の道だと思います。 以下のコメントであなたの考えを教えてください。