First write!
"); responseStream.write("${loremIpsum1}
`); await new Promise(r => setTimeout(r, 1000)); responseStream.write("DONE!
"); responseStream.write(""); responseStream.end(); } ); ``` 以下は、`template.yaml` ファイルの例です。Lambda 関数のレスポンスストリーミングは、`FunctionUrlConfig` プロパティを使用して設定されます。 ``` AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 Description: > Sample SAM Template for lambda-streaming-nodejs-app Resources: StreamingFunction: Type: AWS::Serverless::Function Properties: CodeUri: src/ Handler: index.handler Runtime: nodejs18.x Architectures: - x86_64 Timeout: 10 FunctionUrlConfig: AuthType: AWS_IAM InvokeMode: RESPONSE_STREAM Outputs: StreamingFunction: Description: "Streaming Lambda Function ARN" Value: !GetAtt StreamingFunction.Arn StreamingFunctionURL: Description: "Streaming Lambda Function URL" Value: !GetAtt StreamingFunctionUrl.FunctionUrl ``` 通常は、`sam build` および `sam deploy --guided` を使用して本番アプリケーションを構築し、デプロイすることができます。この例では、開発環境を想定し、アプリケーションを構築してデプロイするために `sam sync` コマンドを使用します。 **注記** `sam sync` コマンドは開発環境に推奨されます。詳細については[を使用して sam sync に同期する方法の概要 AWS クラウド](using-sam-cli-sync.md)を参照してください。 `sam sync` を実行する前に、プロジェクトが `samconfig.toml` ファイル内で正しく設定されていることを確認します。最も重要なのは、`stack_name` と `watch` の値を確認することです。設定ファイル内でこれらの値が指定されていれば、コマンドラインでそれらを指定する必要がありません。 ``` version = 0.1 [default] [default.global.parameters] stack_name = "lambda-streaming-nodejs-app" [default.build.parameters] cached = true parallel = true [default.validate.parameters] lint = true [default.deploy.parameters] capabilities = "CAPABILITY_IAM" confirm_changeset = true resolve_s3 = true s3_prefix = "lambda-streaming-nodejs-app" region = "us-west-2" image_repositories = [] [default.package.parameters] resolve_s3 = true [default.sync.parameters] watch = true [default.local_start_api.parameters] warm_containers = "EAGER" [default.local_start_lambda.parameters] warm_containers = "EAGER" ``` 次に、`sam sync` を実行してアプリケーションを構築し、デプロイします。設定ファイルで `--watch` オプションが設定されていることから、 AWS SAM CLI がアプリケーションを構築し、アプリケーションをデプロイして、変更を監視します。 ``` $ sam sync The SAM CLI will use the AWS Lambda, Amazon API Gateway, and AWS StepFunctions APIs to upload your code without performing a CloudFormation deployment. This will cause drift in your CloudFormation stack. **The sync command should only be used against a development stack**. Queued infra sync. Waiting for in progress code syncs to complete... Starting infra sync. Building codeuri: /Users/.../lambda-streaming-nodejs-app/src runtime: nodejs18.x metadata: {} architecture: x86_64 functions: StreamingFunction package.json file not found. Continuing the build without dependencies. Running NodejsNpmBuilder:CopySource Build Succeeded Successfully packaged artifacts and wrote output template to file /var/folders/45/5ct135bx3fn2551_ptl5g6_80000gr/T/tmpavrzdhgp. Execute the following command to deploy the packaged template sam deploy --template-file /var/folders/45/5ct135bx3fn2551_ptl5g6_80000gr/T/tmpavrzdhgp --stack-nameFirst write!
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quisque vitae mi tincidunt tellus ultricies dignissim id et diam. Morbi pharetra eu nisi et finibus. Vivamus diam nulla, vulputate et nisl cursus, pellentesque vehicula libero. Cras imperdiet lorem ante, non posuere dolor sollicitudin a. Vestibulum ipsum lacus, blandit nec augue id, lobortis dictum urna. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia curae; Morbi auctor orci eget tellus aliquam, non maximus massa porta. In diam ante, pulvinar aliquam nisl non, elementum hendrerit sapien. Vestibulum massa nunc, mattis non congue vitae, placerat in quam. Nam vulputate lectus metus, et dignissim erat varius a.
DONE!
START RequestId: 1e4cdf04-60de-4769-b3a2-c1481982deb4 Version: $LATEST END RequestId: 1e4cdf04-60de-4769-b3a2-c1481982deb4 REPORT RequestId: 1e4cdf04-60de-4769-b3a2-c1481982deb4 Duration: 4088.66 ms Billed Duration: 4089 ms Memory Size: 128 MB Max Memory Used: 68 MB Init Duration: 168.45 ms ``` 関数コードを変更すると、 AWS SAM CLI が変更を即座に検出して、それらを直ちにデプロイします。以下は、関数コードに変更を行った後の AWS SAM CLI 出力の例です。 ``` Syncing Lambda Function StreamingFunction... Building codeuri: /Users/.../lambda-streaming-nodejs-app/src runtime: nodejs18.x metadata: {} architecture: x86_64 functions: StreamingFunction package.json file not found. Continuing the build without dependencies. Running NodejsNpmBuilder:CopySource Finished syncing Lambda Function StreamingFunction. Syncing Layer StreamingFunctione9cfe924DepLayer... SyncFlow [Layer StreamingFunctione9cfe924DepLayer]: Skipping resource update as the content didn't change Finished syncing Layer StreamingFunctione9cfe924DepLayer. ``` これで、`sam remote invoke` を再度使用して、クラウド内の関数とやり取りし、変更をテストできるようになりました。 ### SQS の例 #### 基本的な例 **ARN をリソース ID として指定して Amazon SQS キューを呼び出します。** ``` $ sam remote invoke arn:aws:sqs:us-west-2:01234567890:sqs-example-4DonhBsjsW1b --event '{"hello": "world"}' --output json Sending message to SQS queue MySqsQueue { "MD5OfMessageBody": "49dfdd54b01cbcd2d2ab5e9e5ee6b9b9", "MessageId": "4f464cdd-15ef-4b57-bd72-3ad225d80adc", "ResponseMetadata": { "RequestId": "95d39377-8323-5ef0-9223-ceb198bd09bd", "HTTPStatusCode": 200, "HTTPHeaders": { "x-amzn-requestid": "95d39377-8323-5ef0-9223-ceb198bd09bd", "date": "Wed, 08 Nov 2023 23:27:26 GMT", "content-type": "application/x-amz-json-1.0", "content-length": "106", "connection": "keep-alive" }, "RetryAttempts": 0 } }% ``` ### Step Functions の例 #### 基本的な例 **物理 ID をリソース ID として指定してステートマシンを呼び出します。** まず、`sam list resources` を使用して物理 ID を取得します。 ``` $ sam list resources --stack-name state-machine-example --output json [ { "LogicalResourceId": "HelloWorldStateMachine", "PhysicalResourceId": "arn:aws:states:us-west-2:513423067560:stateMachine:HelloWorldStateMachine-z69tFEUx0F66" }, { "LogicalResourceId": "HelloWorldStateMachineRole", "PhysicalResourceId": "simple-state-machine-HelloWorldStateMachineRole-PduA0BDGuFXw" } ] ``` 次に、物理 ID をリソース ID として使用してステートマシンを呼び出します。コマンドラインで `--event` オプションを指定してイベントを渡します。 ``` $ sam remote invoke arn:aws:states:us-west-2:01234567890:stateMachine:HelloWorldStateMachine-z69tFEUx0F66 --event '{"is_developer": true}' Invoking Step Function arn:aws:states:us-west-2:01234567890:stateMachine:HelloWorldStateMachine-z69tFEUx0F66 "Hello Developer World"% ``` **空のイベントを渡してステートマシンを呼び出します。** ``` $ sam remote invoke HelloWorldStateMachine --stack-name state-machine-example Invoking Step Function HelloWorldStateMachine "Hello World"% ``` ## 関連リンク `sam remote invoke` および の使用に関するドキュメントについては AWS SAM CLI、以下を参照してください。 + [sam remote invoke](sam-cli-command-reference-remote-invoke.md) + [AWS SAMCLI トラブルシューティング](sam-cli-troubleshooting.md) # を使用してローカル統合テストを自動化する AWS SAM [sam local invoke を使用したテストの概要](using-sam-cli-local-invoke.md) を使用してコードを手動でテストできますが、 では自動統合テストを使用してコードをテスト AWS SAM することもできます。統合テストは、開発サイクルの早い段階で問題を検出し、コードの品質を向上させ、コストを削減しながら時間を節約するのに役立ちます。 で自動統合テストを作成するには AWS SAM、まずローカル Lambda 関数に対してテストを実行してから AWS クラウドにデプロイします。[sam local start-lambda を使用したテストの概要](using-sam-cli-local-start-lambda.md) コマンドは、Lambda 呼び出しエンドポイントをエミュレートするローカルのエンドポイントを起動します。これは、自動化されたテストから呼び出すことができます。このエンドポイントは Lambda 呼び出しエンドポイントをエミュレートするので、テストの記述後は、ローカルの Lambda 関数、またはデプロイされた Lambda 関数にも、変更なしでこれらのテストを実行できます。CI/CD パイプライン内のデプロイされた AWS SAM スタックに対しても、同じテストを実行できます。 プロセスの仕組みは以下のとおりです。 1. ローカル Lambda エンドポイントを起動する。 AWS SAM テンプレートを含む ディレクトリで次のコマンドを実行して、ローカル Lambda エンドポイントを起動します。 ``` sam local start-lambda ``` このコマンドは、`http://127.0.0.1:3001` をエミュレートする AWS Lambdaでローカルエンドポイントを起動します。自動化されたテストは、このローカル Lambda エンドポイントに対して実行できます。 AWS CLI または SDK を使用してこのエンドポイントを呼び出すと、リクエストで指定された Lambda 関数がローカルで実行され、レスポンスが返されます。 1. ローカル Lambda エンドポイントに対して統合テストを実行する。 統合テストでは、 AWS SDK を使用してテストデータで Lambda 関数を呼び出し、レスポンスを待機し、レスポンスが期待どおりであることを確認します。統合テストをローカルで実行するには、前のステップで起動したローカル Lambda エンドポイントを呼び出すための Lambda Invoke API コールを送信するように AWS SDK を設定する必要があります。 以下は Python の例です (他の言語 AWS SDKs の設定は似ています）。 ``` import boto3 import botocore # Set "running_locally" flag if you are running the integration test locally running_locally = True if running_locally: # Create Lambda SDK client to connect to appropriate Lambda endpoint lambda_client = boto3.client('lambda', region_name="us-west-2", endpoint_url="http://127.0.0.1:3001", use_ssl=False, verify=False, config=botocore.client.Config( signature_version=botocore.UNSIGNED, read_timeout=15, retries={'max_attempts': 0}, ) ) else: lambda_client = boto3.client('lambda') # Invoke your Lambda function as you normally usually do. The function will run # locally if it is configured to do so response = lambda_client.invoke(FunctionName="HelloWorldFunction") # Verify the response assert response == "Hello World" ``` このコードは、`running_locally` を `False` に設定することによって、デプロイされた Lambda 関数のテストに使用できます。これにより、 AWS クラウド AWS Lambda で に接続するように AWS SDK がセットアップされます。 # を使用してサンプルイベントペイロードを生成する AWS SAM Lambda 関数をテストするには、他の AWS サービスによってトリガーされたときに Lambda 関数が受け取るデータを模倣するサンプルイベントペイロードを生成してカスタマイズできます。これには、API Gateway、 CloudFormation、Amazon S3 などのサービスが含まれます。 サンプルのイベントペイロードを生成すると、ライブ環境で作業することなく、さまざまな入力を使用して Lambda 関数の動作をテストできます。また、このアプローチにより、 関数をテストするための AWS サービスイベントサンプルを手動で作成するよりも、時間を節約できます。 サンプルイベントペイロードを生成できるサービスの完全なリストについては、以下のコマンドを使用します。 ``` sam local generate-event --help ``` 特定のサービスに使用できるオプションのリストについては、以下のコマンドを使用します。 ``` sam local generate-event [SERVICE] --help ``` 例: ``` #Generates the event from S3 when a new object is created sam local generate-event s3 put # Generates the event from S3 when an object is deleted sam local generate-event s3 delete ``` # 耐久性のある関数のテストとデバッグ 耐久性のある関数のテストとデバッグは、通常の Lambda 関数と同様に機能し、チェックポイントとリプレイを自動的にサポートします。このガイドでは、一般的なテストシナリオとトラブルシューティング手法について説明します。 ## ローカルテストワークフロー 耐久性のある関数をローカルでテストする場合、ワークフローは通常の Lambda 関数とは異なります。 **耐久性のある関数テストワークフロー** 1. アプリケーションを構築します。 ``` $ sam build ``` 1. 耐久性のある 関数を呼び出します。 ``` $ sam local invoke MyDurableFunction --durable-execution-name test ``` 1. 必要に応じて実行履歴を確認します。 ``` $ sam local execution history execution-id ``` ## 一般的なテストシナリオ ### チェックポイント動作のテスト 関数が 状態を適切にチェックポイントすることをテストするには: ``` # Example Python durable function def handler(event, context): # This will create a checkpoint context.wait(10) # Wait 10 seconds # Function resumes here after wait return {"message": "Function resumed after wait"} ``` この関数をローカルで呼び出すと、待機期間は自動的に処理されます。 ### コールバックシナリオのテスト 外部コールバックを待機する関数の場合: 1. コールバックを待機する耐久性のある関数を開始する 1. 別のターミナルで、コールバックを解決します。 ``` $ sam local callback succeed callback-id ``` 1. 関数の実行再開を確認する ## トラブルシューティング ### 耐久性のある関数が正しく実行されない **問題:** 関数は耐久性のある関数として動作しません。 **解決方法:** + SAM テンプレートで `DurableConfig`が設定されていることを確認します。 + 関数コードが耐久性のある関数 SDK メソッド (例: `context.wait()`) を使用していることを確認します。 + サポートされているランタイム (TypeScript、JavaScript、Python) を使用していることを確認します。 ### 実行履歴を取得できません **問題:** `local execution history` コマンドは結果を返しません。 **解決方法:** + 実行 ID が正しいことを確認する + 関数が少なくとも 1 回呼び出されたことを確認します。 ### コールバックコマンドが機能しない **問題:** コールバックコマンドは保留中のオペレーションを解決しません。 **解決方法:** + コールバック ID が正しいことを確認する + 関数が実際にコールバックを待っていることを確認します。 + 正しいコールバックコマンド構文を使用していることを確認します。 ## デバッグのヒント + **実行履歴を使用する** - 実行履歴を確認して、耐久性のある関数のフローを理解します。 + **段階的にテスト**する - 複雑なロジックを追加する前に単純な待機操作から開始する + **詳細ログ記録の使用** - 詳細ログ記録を有効にして実行フローをトレースする ## 詳細情報 テストとデバッグの詳細については、以下を参照してください。 + [sam local invoke を使用したテストの概要](using-sam-cli-local-invoke.md) - ローカル呼び出しドキュメント + [sam local execution history](sam-cli-command-reference-sam-local-execution-history.md) - 実行履歴