AWS によるサーバーレスアプリケーションの構築と運用

AWS サービスを、プライベート注文 API、回復可能なキューコンシューマー、注文レポートワークフローに統合します。各プロジェクトで、学習済みのスキルを結びつけ、具体的な業務結果を確認します。

AWS

💡 このチュートリアルは英語版からAIによって翻訳されています。原文を確認するには、 ここをクリックしてください

はじめに

AWS サービスを、プライベート注文 API、回復可能なキューコンシューマー、注文レポートワークフローに統合します。各プロジェクトで、学習済みのスキルを結びつけ、具体的な業務結果を確認します。

完全な解説付きの解答を備えた 3 つの独立した課題で構成されています。アプリケーションコード、インターフェース、架空のデータ、無関係な補助要素は提供され、サービス接続、権限、障害対応、クリーンアップに集中できます。

学習する内容

  • Lambda、DynamoDB、範囲限定の設定を使い、ログインが必要な注文 API を起動する
  • 匿名リクエストと無効なトークンを拒否しながら、公開ヘルス機能を維持する
  • 修正済みの業務結果が存在してから、問題のあるメッセージを回復する
  • 新しい重複メッセージを処理するときに保存済み注文を保護する
  • S3 入力と管理された設定から、保存とレポートのワークフローを作る
  • 一時的、永続的、権限不足の失敗を観察できる結果として扱う
  • ダウンロードしたレポートのバイト列を確認し、自分の状態と非公開ファイルを削除する

このコースの対象者

関連する AWS サービスのラボを完了し、自主的に統合を練習したい学習者が対象です。

前提知識: 以下の能力に対応する分岐を選んでください。3 つのプロジェクトは独立して開始します。

PS01 は JWT オーソライザーで API ルートを保護する (A05) のルートと呼び出しの認可、その Lambda–DynamoDB の前提、Secrets Manager からアプリケーションの認証情報を読み込む (SEC03) の認証情報処理、Parameter Store で設定を分離する (SEC04) のパラメータと環境設定を組み合わせます。価格には通常の String パラメータを使い、SEC04 の SecureString/KMS 演習は不要です。CORS と Lambda のバージョン/エイリアスは任意です。

PS02 は デッドレターキューで失敗したジョブを隔離する (Q03)/重複した効果を生まずにキュージョブを処理する (Q05) の可視性と現在の receipt handle、回数を制限した失敗の隔離、Lambda のコード/ロール更新、DynamoDB の条件付き書き込みを組み合わせます。SNS と他のプロジェクトは任意で、以前の VM のリソースは再利用しません。

PS03 は ワークフローの再試行で業務上の効果を繰り返さないようにする (EV05) とその FN03/D04/FN02 の前提、S3 にアップロードされたレポートを処理する (FN04) の S3 オブジェクト読み書き、Secrets Manager からアプリケーションの認証情報を読み込む (SEC03)/Parameter Store で設定を分離する (SEC04) の認証情報と設定処理を組み合わせます。FN04 は「S3 にアップロードされたレポートを処理する」で、FN05 のバージョン/エイリアスは不要です。このワークフローには S3 通知、EventBridge ルーティング、SecureString/KMS、前の 2 プロジェクトは不要です。

学習環境: すべての演習は、ブラウザーから利用できる LabEx の Linux 環境で行います。AWS CLI のコマンドには Terminal を使い、上部の AWS View で同じリソースとアプリケーションの状態を確認します。ツールと接続は準備済みで、個人の AWS アカウントやアクセスキーは不要です。各ラボは新しい VM で独立して開始します。 AWS View は API の判断、安全なログ、設定、キュー処理、ワークフロー履歴、テーブルデータを関連付けます。スクリーンショットやレポートの提出は不要です。

よくある質問

3 つの課題を同じ VM で終える必要がありますか?

いいえ。それぞれ独立して開始します。引き継ぐのは知識であり、リソース、認証情報、トークンではありません。推奨される段階は、API、メッセージング、ワークフローのサービスコースに続きます。

プライベート API 課題では何を確認しますか?

ログイン済みリクエストが計算された注文を作成、取得し、設定変更が後の料金計算に影響します。匿名または無効なトークンのリクエストは Lambda の前で止まり、無効な入力や設定アクセスの拒否は注文を作成しません。JWT によるルートアクセスはユーザーごとの所有権を証明しません。架空のパスワード、トークン、パートナー認証情報は非公開にしてください。

失敗したメッセージをいつ処理済みとして確認できますか?

修正したジョブが実際の業務結果を生成した後です。その後、元の失敗配信を削除し、新しい重複をテストします。条件付き書き込みは 1 つの業務上の効果を保護しますが、キューとデータベースのアトミックなトランザクションや、厳密に 1 回の配信を保証しません。

レポートワークフローはどう評価しますか?

実行履歴、保存済み注文、ダウンロードしたレポートのバイト列で、一時的な失敗や繰り返し実行の下でも完了したことを示します。永続的な失敗や権限不足は明確なままにしてください。機能確認を終え、自分の状態と認証情報を含む設定だけを削除し、無関係なリソースを保持します。

講師

labby
Labby
Labby is the LabEx teacher.