はじめに

初級コース | 10 分

サーバーレス - ディープダイブでは、サーバーレスアプリケーションの構築を開始するのに役立つ基本的な概念、リファレンスアーキテクチャ、ベストプラクティス、実践的なアクティビティを紹介します。サーバーレスが初めての場合は、ここから始めるのが理想的です。経験豊富なサーバーレスビルダー向けのリソースと、より高度なトピックへのリンクがあります。

サーバーレスについて

サーバーレスのおかげで、アプリケーションとサービスを構築、実行する際に、サーバーに関して悩むことはなくなります。サーバーまたはクラスターのプロビジョニング、パッチ適用、オペレーティングシステムのメンテナンス、キャパシティーのプロビジョニングといったインフラストラクチャ管理のタスクが不要になります。ほぼすべてのタイプのアプリケーションやバックエンドサービス向けに構築でき、高可用性を実現しながら、アプリケーションの実行やスケーリングに必要な作業のすべてをユーザーに代わって行います。

サーバーレスアプリケーションはイベント駆動型で、テクノロジーに依存しない API またはメッセージングを介して疎結合されます。イベント駆動型コードは、状態の変化やエンドポイントリクエストなどのイベントに応答して実行されます。イベント駆動型アーキテクチャは、コードを状態から切り離します。疎結合コンポーネント間の統合は、通常、メッセージングを使用して非同期で行われます。

AWS Lambda は、イベント駆動型アーキテクチャに最適なサーバーレスコンピューティングサービスです。Lambda 関数は、Amazon Simple Queue Service (SQS)、Amazon Simple Notification Service (SNS)、Amazon Kinesis などの統合されたイベントソースを介して、非同期統合の作成に使用できるイベントによってトリガーされます。Lambda 関数は、他のサービスが消費できるイベントを消費および生成します。

サーバーレスアーキテクチャパターンは、同じくサーバーレスである他のマネージドサービスで Lambda を使用します。メッセージサービスおよびストリーミングサービスに加えて、サーバーレスアーキテクチャは、API 管理には Amazon API Gateway、データの格納には Amazon DynamoDB、オーケストレーションには AWS Step Functions などのマネージドサービスを使用します。サーバーレスプラットフォームには、サーバーレスアプリケーションモデル (SAM) を含む一連のデベロッパーツールも含まれています。これは、Lambda 関数とサーバーレスアプリケーションのデプロイとテストを簡素化するのに役立ちます。

サーバーレスを使う理由

サーバー管理なし: サーバーのプロビジョニングやメンテナンスは、必要ありません。保守および管理が必要なソフトウェアあるいはランタイムを、インストールする必要がありません。

柔軟なスケーリング: アプリケーションは、自動的にスケーリングすることも、個々のサーバー単位ではなく消費単位 (スループットやメモリなど) で切り替えて容量を調整し、スケーリングすることもできます。

価値に見合った支払い: サーバー単位ではなく、安定したスループットや実行時間に対して支払います。

自動化された高可用性: サーバーレスには、可用性と耐障害性機能が組み込まれています。これらの機能は、アプリケーションを実行しているサービスがデフォルトで提供するため、設計する必要はありません。

コアサーバーレスサービス

サーバーレスアプリケーションは、通常、フルマネージドサービスを使用して、コンピューティング、データ、メッセージングと統合、ストリーミング、ユーザー管理、ID レイヤー全体のビルディングブロックとして構築されます。AWS Lambda、API Gateway、SQS、SNS、EventBridge、Step Functions などのサービスは、DynamoDB、S3、Kinesis などのサービスでサポートされているほとんどのアプリケーションの中核にあります。

カテゴリ
サービス
説明
コンピューティング AWS Lambda AWS Lambda を使用すると、関数層でマイクロサービスアーキテクチャ、デプロイ、実行の管理をサポートする
ステートレスサーバーレスアプリケーションをマネージドプラットフォームで
実行できます
API プロキシ API ゲートウェイ Amazon API Gateway はフルマネージドサービスで、デベロッパーは
規模を問わず、API の公開、維持、監視、保護を簡単に実行できますAmazon API Gateway は
API 管理のための包括的プラットフォームを提供します。API Gateway を使用すると、
数十万の同時 API 呼び出しを処理し、トラフィック管理、承認とアクセス制御、監視、
および API バージョン管理を行えます。
メッセージング & 統合 SNS Amazon SNS は、フルマネージド型の pub/sub メッセージングサービスで、
マイクロサービス、分散システム、サーバーレスアプリケーションの疎結合化とスケーリングを簡単に行えるようにします。
SQS Amazon SQS は、フルマネージド型のメッセージキューイングサービスで、
マイクロサービス、分散システム、サーバーレスアプリケーションの疎結合化とスケーリングを簡単に行えるようにします。
EventBridge Amazon EventBridge はサーバーレスイベントバスで、独自のアプリケーション、
統合された Software-as-a-Service (SaaS) アプリケーション、AWS のサービスからのデータを使用して、
アプリケーションを簡単に接続できるようにします。
オーケストレーション Step Functions
AWS Step Functions により、視覚的なワークフローを使用し、分散アプリケーションとマイクロサービスのコンポーネントを
簡単に調整できます。

作ってみよう

以下は、主要なサーバーレスサービスの理解に役立つリソースです。

「Hello, World!」をサーバーレスで実行

AWS Lambda コンソールを使用して Hello World Lambda 関数を作成し、サーバーをプロビジョニングまたは管理せずにコードを実行する基本を学びます。

チュートリアルを開始する >>

アップロードした画像からサムネイルを作成する

画像ファイルが S3 バケットにアップロードされるたびに Amazon S3 によって呼び出される Lambda 関数を作成し、その画像のサムネイルを自動的に作成します。

チュートリアルを開始する >>

AWS Lambda を使用して最初のアプリケーションを構築する
シンプルなマイクロサービスを作成する

Lambda コンソールを使用して Lambda 関数を作成し、Amazon API Gateway エンドポイントでその関数をトリガーします。

チュートリアルを開始する >>

サーバーレスワークフローを作成する

AWS Step Functions を使用して、複数の AWS Lambda 関数を連携させたサーバーレスワークフローを設計して実行する方法を学習します。

チュートリアルを開始する >>

基礎

中級コース | 20 分

このセクションでは、スケーラブルなサーバーレスアプリケーションの背後にある主要原則であるイベント駆動型設計について学びます。

イベント駆動型設計

イベント駆動型アーキテクチャは、イベントを使用してトリガーし、デカップリングされたサービス間で通信します。イベントとは、e コマースウェブサイトのショッピングカートに商品が置かれるなど、状態が変化すること (または更新) です。イベントは、状態 (たとえば、購入したアイテム、その価格、および配送先住所) を持つことができます。または、イベントは識別子 (たとえば、注文が出荷されたという通知) となることができます。

イベント駆動型アーキテクチャには、イベントプロデューサー、イベントルーター、イベントコンシューマーの 3 つの主要コンポーネントがあります。プロデューサーはイベントをルーターに発行し、ルーターはイベントをフィルタリングしてコンシューマーにプッシュします。プロデューサーサービスとコンシューマーサービスは切り離されているため、それらを個別にスケーリング、更新、デプロイできます。

イベント駆動型アーキテクチャが望ましい理由を理解するために、同期 API 呼び出しを見てみましょう。

Serverless deep dive synchronous api call

顧客は HTTP API 呼び出しを行うことにより、マイクロサービスを活用します。Amazon API Gateway は RESTful HTTP リクエストと顧客への応答をホストします。AWS Lambda には、着信 API 呼び出しを処理し、DynamoDB を永続ストレージとして活用するビジネスロジックが含まれています。

同期的に呼び出された場合、API Gateway は即時応答を予期し、タイムアウトは 30 秒です。同期イベントソースでは、Lambda からの応答に 30 秒を超える時間が必要な場合は、再試行およびエラー処理コードを作成する必要があります。このため、DynamoDB の読み取り/書き込み容量ユニットなど、クライアントの下流にあるコンポーネントで発生するエラーまたはスケーリングの問題は、フロントエンドコードが処理できるようにクライアントにプッシュバックされます。非同期パターンを使用してこれらのコンポーネントを分離することにより、より堅牢で拡張性の高いシステムを構築できます。

ファンアウトイベント通知を送信

メッセージが複数のサブスクライバーに「プッシュ」されるファンアウトメッセージングシナリオを実装する方法を学びます。これにより、更新を定期的に確認またはポーリングする必要がなくなり、サブスクライバーによるメッセージの並列/非同期処理が可能になります。

チュートリアルを開始する >>

Amazon EventBridge をサーバーレスアプリケーションに統合する

AWS Lambda でイベントプロデューサーとイベントコンシューマーを構築する方法、およびイベントをルーティングするルールの作成方法を学びます。

チュートリアルを開始する >>

イベント駆動型アーキテクチャーへの移行
トリガーとイベントソース

Lambda 関数はイベントによってトリガーされます。次に、トリガーに応答してコードを実行し、独自のイベントを生成することもできます。Lambda 関数をトリガーするためのオプションが数多くあり、特定のニーズに合わせてカスタムイベントソースを作成する高い柔軟性があります。

イベントソースの主なタイプは次のとおりです。

  • Amazon S3、Amazon DynamoDB、Amazon Kinesis などのデータストア は、Lambda 関数をトリガーできます。変更を追跡したいデータが格納されている場合は、イベントソースとして使用できる可能性があります。
  • イベントを発行するエンドポイントは Lambda を呼び出すことができます。たとえば、Alexa に何かを依頼すると、Lambda 関数をトリガーするイベントが発生します。
  • Amazon SQS や Amazon SNS などのメッセージングサービスもイベントソースになる可能性があります。たとえば、SNS トピックに何かをプッシュすると、Lambda 関数がトリガーされる可能性があります。
  • AWS CodeCommit リポジトリにコードをコミットするときなど、特定のアクションがリポジトリ内で発生すると、Lambda 関数をトリガーして、たとえば CI/CD ビルドプロセスを開始できます。
Serverless deep dive event source trigger
AWS Lambda 関数の呼び出し

デベロッパーガイドで AWS Lambda 関数の呼び出しについて学びましょう。

デベロッパーガイドを見る >>

サーバーレスアプリケーションでイベント、キュー、トピック、ストリームを選択する
リファレンスアーキテクチャ

このセクションでは、一般的なサーバーレスアプリケーションのユースケースをカバーする一連のリファレンスアーキテクチャを紹介します。

  • RESTful マイクロサービス

    サーバーレステクノロジーは、可用性が高く耐障害性のあるインフラストラクチャの上に構築されているため、ミッションクリティカルなワークロード向けの信頼性の高いサービスを構築できます。AWS サーバーレスコアサービスは、他の数十の AWS のサービスと緊密に統合されており、AWS およびサードパーティパートナーツールの豊富なエコシステムからメリットを得られます。このエコシステムにより、ビルドプロセスの合理化、タスクの自動化、サービスと依存関係の調整、マイクロサービスのモニタリングが可能になります。AWS サーバーレスサービスは、従量課金制です。これにより、ビジネスで使用量を増やすことができ、また使用量が少ないときはコストを抑えることができます。このような機能により、サーバーレステクノロジーは、復元力のあるマイクロサービスの構築に最適です。

    RESTful マイクロサービスアーキテクチャの例

    Serverless deep dive restful microservice architecture

    顧客は HTTP API 呼び出しを行うことにより、マイクロサービスを活用します。理想的には、サービスレベルと変更管理への一貫した期待を実現するために、消費者は API と密接に結びついたサービスコントラクトを持っている必要があります。

    Amazon API Gateway は RESTful HTTP リクエストと顧客への応答をホストします。このシナリオでは、API Gateway は、組み込みの承認、スロットル、セキュリティ、耐障害性、リクエスト/レスポンスのマッピング、およびパフォーマンスの最適化を実現します。

    AWS Lambda には、着信 API 呼び出しを処理し、DynamoDB を永続ストレージとして活用するビジネスロジックが含まれています。

    Amazon DynamoDB は、マイクロサービスデータを永続的に保存し、需要に基づいてスケーリングします。マイクロサービスは多くの場合、1 つのことをうまく行うように設計されているため、スキーマレスな NoSQL データストアが定期的に組み込まれています。

  • 画像処理

    画像処理は、動的にスケールアップおよびスケールダウンを必要とする一般的なワークロードで、イベント駆動型にすることができます。そのため、サーバーレステクノロジーが適しています。通常、画像は Amazon S3 に保存され、Lambda 関数をトリガーすることで処理できます。処理後、Lambda 関数は変更されたバージョンを別の S3 バケットまたは API Gateway に返すことができます。

    以下の図は、ソリューション実装ガイドと付属の AWS CloudFormation テンプレートを使用して数分でデプロイできる Serverless Image Handler のアーキテクチャを示しています。

    Serverless deep dive image handler

    AWS Lambda はご使用の Amazon Simple Storage Service (Amazon S3) バケットから画像を取得し、変更済みの画像を Amazon API Gateway へ戻すために Sharp を使用します。このソリューションは画像ハンドラー API にキャッシュアクセスを提供する Amazon CloudFront ドメイン名を生成します。

    さらに、このソリューションはオプションのデモユーザーインターフェイスをデプロイします。ユーザーはそこですでに自分のアカウントにある画像ファイルを使用して、自分の画像ハンドラー API エンドポイントと直接やり取りできます。このデモ UI は Amazon S3 バケットにデプロイされ、お客様はシンプルなウェブインターフェイスで画像の操作をすぐに開始できます。CloudFront はソリューションのウェブサイトバケットのコンテンツに対するアクセスを制限するために使用されます。

    デプロイソリューション >>

  • ストリーム処理

    リアルタイムのストリーミングデータを AWS Lambda と Amazon Kinesis を使用して処理することで、アプリケーションのアクティビティのトラッキング、注文のトランザクション処理、クリックストリーム分析、データクレンジング、メトリクスの生成、ログのフィルタリング、インデックス作成、ソーシャルメディア分析、および IoT データのテレメトリと測定などが行えます。

    ストリーム処理アーキテクチャの例

    serverless deep dive stream processing

    この図で説明されているアーキテクチャは、AWS CloudFormation テンプレートを使用して作成できます。テンプレートは次のことを行います。

    • Kinesis ストリームを作成する
    • -EventData という名前の DynamoDB テーブルを作成する
    • Kinesis からレコードを受信して DynamoDB テーブルにレコードを書き込む Lambda 関数 1 (-DDBEventProcessor) を作成する
    • イベントを処理する Lambda 関数が Kinesis ストリームから読み取って DynamoDB テーブルに書き込むことができるようにする IAM ロールとポリシーを作成する
    • Kinesis ストリームにイベントを配置する権限と、API クライアントで使用する認証情報を持つ IAM ユーザーを作成する
  • ウェブアプリケーション

    AWS でサーバーレスコンピューティングを使用すると、サーバーを管理したり、容量をプロビジョニングしたり、アイドルリソースに料金を支払ったりすることなく、ウェブアプリケーションスタック全体をデプロイできます。さらに、セキュリティ、信頼性やパフォーマンスについて妥協することはありません。サーバーレステクノロジーを使用して構築されたウェブアプリケーションは可用性が高く、オンデマンドでグローバルに拡張できます。

    serverless deep dive web application
    1. このウェブアプリケーションの消費者は、地理的に集中しているか、世界中に分散している可能性があります。Amazon CloudFront を利用すると、キャッシングと最適なオリジンルーティングによってこのような消費者に優れたパフォーマンスエクスペリエンスを提供するだけでなく、バックエンドへの冗長な呼び出しを制限します。
    2. Amazon S3 はウェブアプリケーションの静的アセットをホストし、CloudFront を介して安全に提供されます。
    3. Amazon Cognito ユーザープールは、ウェブアプリケーションにユーザー管理と ID プロバイダー機能を提供します。
    4. 多くのシナリオで、消費者は Amazon S3 の静的コンテンツをダウンロードするため、動的コンテンツをアプリケーションで送受信する必要があります。たとえば、ユーザーがフォームを介してデータを送信すると、Amazon API Gateway は安全なエンドポイントとして機能し、このような呼び出しを行い、ウェブアプリケーションを通じて表示される応答を返します。
    5. AWS Lambda 関数は、ウェブアプリケーション向けの DynamoDB に加えて、作成、読み取り、更新、削除 (CRUD) 操作を行います。
    6. Amazon DynamoDB は、バックエンドの NoSQL データストアを提供して、ウェブアプリケーションのトラフィックに合わせて柔軟にスケーリングできます。
デプロイ

マイクロサービスアーキテクチャでのデプロイのベストプラクティスは、変更によって消費者のサービス契約が破られないようにすることです。API 所有者がサービスコントラクトに違反する変更を行い、消費者がその準備をしていない場合、障害が発生する可能性があります。

デプロイの変更がどのような影響を及ぼすかを理解するには、どのような消費者が API を使用しているのかを知る必要があります。API キーを使用して使用状況に関するメタデータを収集できます。API に重大な変更が加えられた場合、これは契約の一種としても機能します。

API への重大な変更による影響を緩和したい場合、API を複製し、顧客を別のサブドメイン (v2.my-service.com など) にルーティングして、既存の消費者が影響を受けないようにすることができます。このアプローチでは、お客様は新しい変更のみを新しい API サービスコントラクトへデプロイできますが、トレードオフが伴います。このアプローチを採用しているお客様は、API の 2 つのバージョンを維持する必要があり、インフラストラクチャの管理とオーバーヘッドのプロビジョニングに対処することになります。

デプロイ
お客様への影響
ロールバック イベントモデルの要因
デプロイ速度
一度に 一度に 古いバージョンを再デプロイする 同時実行率の低いイベントモデル すぐに
ブルー/グリーン 事前にある程度の本番環境テストを行って、一度に トラフィックを以前の環境に戻す 中程度の同時実行ワークロードでの非同期および同期イベントモデル向き 数分から数時間の検証後、すぐにお客様へ
Canary/Linear 1~10% の通常の初期トラフィックシフト、その後段階的に増加または一度に増加 トラフィックを 100% 元の配置に戻す 並行性の高いワークロード向き 数分から数時間
  • 一括デプロイ

    一括デプロイでは、既存の設定に加えて変更を加える必要があります。このスタイルのデプロイの利点は、リレーショナルデータベースなどのデータストアへのバックエンドの変更で、変更サイクル中にトランザクションを調整するために必要な作業がはるかに少なくなることです。このタイプのデプロイスタイルは手間が少なく、同時実行性の低いモデルにほとんど影響を与えずに作成できますが、ロールバックに関してはリスクが高まり、通常はダウンタイムが発生します。このデプロイモデルを使用するシナリオの例としては、ユーザーへの影響が最小限の開発環境があります。

    一括デプロイを試す >>

  • ブルー/グリーンデプロイ

    ブルー/グリーンデプロイパターンでは、システムをロールバックする必要がある場合に備えて、古い環境 (ブルー) をアクティブに保ちながら、トラフィックのセクションを新しいライブ環境 (グリーン) にシフトします。このパターンを使用する場合、ロールバックを迅速かつ簡単に実行できるように、変更を小さく保つことをお勧めします。ブルー/グリーンデプロイは、ダウンタイムを削減するように設計されており、多くのお客様が本番環境へのデプロイにそれを用いています。API Gateway では、新しいグリーン環境にシフトするトラフィックの割合を簡単に定義できるため、このデプロイパターンの効果的なツールになります。

    このデプロイスタイルは、ステートレスであり、基盤となるインフラストラクチャから切り離されているサーバーレスアーキテクチャに特に適しています。

    ロールバックが必要かどうかを知るには、適切なインジケーターが必要です。ベストプラクティスとして、1 秒間隔でモニタリングでき、下降傾向をすばやくキャプチャできる CloudWatch 高解像度メトリクスを使用することをお勧めします。CloudWatch アラームで使用すると、迅速なロールバックを行うことができます。CloudWatch メトリクスは、API Gateway、Step Functions、Lambda (カスタムメトリクスを含む)、および DynamoDB でキャプチャできます。

  • Canary デプロイ

    Canary デプロイはますます使われるようになってきている方法で、制御された環境でソフトウェアの新しいリリースを活用し、迅速なデプロイサイクルを可能にします。Canary デプロイでは、少数のユーザーへの影響を分析するために、少数のリクエストを新しい変更にデプロイします。

    API Gateway で Canary デプロイを使用すると、バックエンドエンドポイント (Lambda など) に変更をデプロイしながら、消費者に対して同じ API ゲートウェイ HTTP エンドポイントを維持できます。さらに、新しいデプロイにルーティングされるトラフィックの割合と、制御されたトラフィックカットオーバーを制御することもできます。Canary デプロイの実用的なシナリオは、新しいウェブサイトでしょう。すべてのトラフィックを新しいデプロイにシフトする前に、少数のエンドユーザーのクリックスルー率をモニタリングできます。

    エイリアストラフィックシフティングを使用した AWS Lambda 関数の Canary デプロイを実装する

    AWS Lambda 関数の Canary デプロイを実装する方法を学びましょう。

    ブログ記事を読む >>

    サーバーレスアプリケーションを段階的にデプロイする

    AWS SAM は、サーバーレスアプリケーションに Lambda デプロイを段階的に行います。

    デベロッパーガイドを見る >>

その他のリソース

ハンズオンチュートリアル
サーバーレスチュートリアルのすべてにアクセスして、より実践的な方法で知識を身に付けましょう。
ハンズオンチュートリアルを表示する >>
AWS サーバーレスブログ
AWS サーバーレスブログで、サーバーレスに関する最新のニュースと情報をお読みください。
ブログ記事を読む >>
カテゴリ別のディープダイブ
特定のテクノロジーを追求して、AWS クラウドを最大限に活用しましょう。
カテゴリ別のディープダイブを表示する >>