週8ElastiCache / SQS / SNS

2026-09-24（木）ElastiCache, SQS, SNS

この記事の目次
  1. この範囲の全体像
  2. 重要キーワード・サービス一覧
  3. 試験で問われる比較ポイント
  4. ひっかけ注意ポイント
  5. 一問一答セルフテスト

1. 【この範囲の全体像】

本範囲は、複数のAWSサービスや分散コンポーネントを組み合わせた「ビジネスロジックの実行順序（ワークフロー）」を自律制御・調整するためのアプリケーション統合（オーケストレーション）設計を学びます [p.21, p.225]。

プログラム内部に処理順序や例外処理を直書きする「密結合」な設計を排除し、状態管理をサービス側に外出しして「疎結合化」するための核心機能です [p.218, p.225]。

試験では、サーバーレスな AWS Step Functions の選定基準と、レガシーな Amazon SWF との仕様境界が確実に問われます [p.225]。

2. 【重要キーワード・サービス一覧】

キーワード 説明
AWS Step Functions [p.225] ビジュアルワークフローを使用して、AWS LambdaやECS、SQSなどの複数のAWSサービスを、サーバーレスで安全に調整・集中管理できるオーケストレーションサービス [p.72, p.77, p.225]。
ステートマシン (State Machine) [p.225] Step Functionsにおけるワークフロー全体の定義。JSONベースの宣言型言語である ASL (Amazon States Language) を用いて、各ステップの遷移ルールやエラーハンドリングを記述します [p.225]。
タスクステート (Task State) [p.225] ワークフローにおける1つの具体的な作業実行単位。Lambda関数の実行、Fargateタスクの起動、あるいはDynamoDBへの書き込み要求など、実際のAPIアクションを呼び出します [p.72, p.77, p.143, p.225]。
Amazon SWF (Simple Workflow Service) [p.225] 分散アプリケーションのステップをコーディネートする、開発初期から存在するワークフローサービス [p.225]。Step Functionsよりも歴史が古く、実行プログラムは自前でコード記述して実装する必要があります [p.225]。
決定者 (Decider) とワーカー (Activity Worker) [p.225] Amazon SWFを構成するプログラム要素。次にどのタスクを実行すべきかを判断・指示する「Decider」と、指示を受けて実際の処理を実行する「Worker」をユーザーがプログラムとして実装・維持します [p.225]。

3. 【試験で問われる比較ポイント】

ワークフロー管理サービスの決定境界：Step Functions vs Amazon SWF [p.225]

比較項目 AWS Step Functions [p.225] Amazon SWF (Simple Workflow Service) [p.225]
設計アプローチ サーバーレス・宣言型。ASL（JSON）で視覚的なグラフィックモデルを定義する [p.225]。 デベロッパー主導型。プログラミングコードを記述してワークフローを実装・維持する [p.225]。
開発と運用の手間 極めて低い（AWSがインフラ、実行ログ、ビジュアル表示、可用性をフルマネージドで管理） [p.225]。 高い（DeciderやWorkerのプロセスを稼働し続け、ポーリングを自前制御する必要がある） [p.225]。
AWSサービス統合 多数のAWSサービスとネイティブに統合。APIを直接呼び出し可能（Lambda、ECS、SQS、SNS等） [p.72, p.77, p.220, p.225, p.227]。 限定的。自前のワーカープログラムを経由してAPIを実行する必要がある [p.225]。
最大実行期間 最長 1 年間（標準ワークフローの場合） [p.225]。 最長 1 年間 [p.225]。
決定的な選定シグナル 🎯 「 新規のサーバーレス開発において、複数のLambdaやECSを組み合わせた条件分岐、並列処理、エラー再試行を最小の管理工数で実現したい 」 [p.72, p.77, p.225] 🎯 「 オンプレミス環境のカスタムサーバーとAWSリソースが複雑に混在し、人間による高度で長期的な介入（承認や手動プロセス）を含む、過去にJava等のコードで実装されたレガシーな処理体系を移行したい 」 [p.225]。

4. 【ひっかけ注意ポイント】

  • ひっかけ①：複数のLambda関数の順次実行やエラーリカバリを、Lambdaのコード内で「直接呼び出し」して制御する罠 [p.77, p.218, p.225]

    • 罠パターン: 「画像アップロード後、画像変換Lambdaを実行し、その成否をコード内でキャッチして、成功なら通知送信Lambdaを呼び出すという直列プロセスを、最初の呼び出し元Lambdaの中にtry-catchコードで自作実装した。」
    • なぜ間違いか（密結合とコストオーバーヘッド）: 呼び出し元のLambdaが、後続のLambdaの処理終了をその場で待ち続ける「同期的な密結合状態」となり、無駄な待機時間コスト（二重課金）が秒単位で発生します [p.77, p.218]。さらに、後続の処理が重い場合、Lambda本来の 15分というタイムアウト制限 に引っかかり、ワークフロー全体が途中でクラッシュする原因になります [p.77]。
    • ベストプラクティス: 個々のLambdaは単機能でステートレスに保ち [p.77, p.291]、実行シーケンス、条件分岐、再試行ロジック、および状態（ステート）管理はすべて AWS Step Functions（ステートマシン） に外出しして一元制御します [p.225]。

  • ひっかけ②：新規構築するサーバーレスなマイクロサービスの連携要件に対し、「Amazon SWF」をベストアーキテクチャとして選択する罠 [p.225]

    • 罠パターン: 「AWS Lambdaを用いたモダンなサーバーレスAPIを開発している。注文、決済、在庫引当の各マイクロサービスを疎結合に順序制御するため、オンプレミスでの動作要件はないものの、カスタムデシジョンコードが自由に書けるAmazon SWFを採用してシステムをデプロイした [p.225]。」
    • なぜ間違いか（管理負荷の増大）: Amazon SWFは、意思決定エンジン（Decider）やタスク処理用の実行プログラムをユーザーがプログラミングコードとして自律開発し、そのプロセスを常にホストしてポーリングし続けなければ動作しません [p.225]。これは、Well-Architectedの「運用上の優秀性」における「管理オーバーヘッドの最小化」という原則に真っ向から違反します。
    • ベストプラクティス: 新規のサーバーレスシステム、および標準的なAWSリソース間の連携制御には、サーバーのホストや自作ポーラーコードが100%不要な AWS Step Functions を指定するのが絶対の正解です [p.225]。

5. 【一問一答セルフテスト】

選択肢を選ぶと、その場で正誤と解説が表示されます。