サーバーレスでイベント駆動型アプリケーションを実現 ! AWS Lambda をグラレコで解説
Author : 米倉 裕基 (監修 : 下川 賢介, 福井 厚)
※ 本連載では、様々な AWS サービスをグラフィックレコーディングで紹介する awsgeek.com を、日本語に翻訳し、図の解説をしていきます。awsgeek.com は 、Jerry Hargrove 氏が運営しているサイトです。
builders.flash 読者のみなさん、こんにちは ! テクニカルライターの米倉裕基と申します。
本記事では、サーバーレスなイベント駆動型コンピューティングサービス、AWS Lambda についてご紹介します。
近年、新たにシステムアーキテクチャを設計する上で、「サーバーレスアーキテクチャ」を検討・導入する企業が増えてきています。サーバーレスなサービスを組み合わせてアーキテクチャを構築することで、サーバーを自社で管理することなく、完全なアプリケーションスタックを構築し、開発速度を上げ、サーバー管理コストを削減できるためです。
AWS が提供するサーバーレスサービスは、コンピューティング、統合、データストアの 3 つのレイヤーで構成されます。本記事で紹介する AWS Lambda は、それら 3 つのレイヤーの中でコンピューティングを担うサービスです。各レイヤーに含まれる AWS サービスについて詳しくは、『製品』ページの「AWS でのサーバーレス」をご覧ください。
それでは、AWS Lambda の主な特徴と提供する機能について見ていきましょう。
1. イベント駆動型アプリケーション
AWS Lambda やその他 AWS が提供するサーバーレスサービスを組み合わせることで、AWS 上のイベントソースで発生するイベントを起点として処理を実行するイベント駆動型アプリケーションを実現できます。
AWS Lambda を使ったイベント駆動型アプリケーションは、多様な構成パターンが考えられます。Amazon S3 バケットにオブジェクトがアップロードや、Amazon API Gateway による HTTP リクエスト の受信をイベントトリガーとして Lambda 関数を呼び出すこともできますし、Amazon SNS や Amazon SQS、Amazon Kinesis などイベントストア / ルーター / バスとして動作する様々なメッセージングサービスを介して、Lambda 関数を呼び出すこともできます。
本記事では、上記の構成の中でイベントバスとしての役割を持つ Amazon EventBridge を中継点として利用した構成をイベント駆動型アプリケーションの例としてご説明します。その他のメッセージングサービスを使ったイベント駆動型アプリケーションについて詳しく知りたい場合は、「メッセージ連携からイベント駆動へ」を合わせてご覧ください。
Amazon EventBridge を使ったイベント駆動型アプリケーションは主に、イベントの送信元となるイベントソース、イベントの発生を他のサービスに伝えるイベントバス、イベントの送信先となるイベントシンクの 3 つのレイヤーで構成されます。
各レイヤーの役割とサービスリストは以下のとおりです。
レイヤー |
内容 |
サービスリスト |
イベントソース |
イベントの送信元であるアプリケーションやサービスを指します。AWS サービスの他にサードパーティーや独自のアプリケーションもイベントソースとして利用できます。 |
Amazon S3、Amazon Kinesis、Amazon API Gateway など 90 種類を超える AWS サービス |
イベントバス |
イベントを受信するバスです。発生したイベントをルールに基づいてフィルタリングし、別の AWS サービスに送信します。 |
Amazon EventBridge |
イベントシンク |
受信したイベントを元に Lambda 関数を実行します。 |
AWS Lambda (Amazon EventBridge は、AWS Lambda を含め 15 種類を超える AWS サービスをイベント送信先のターゲットとして利用できます) |
クリックすると拡大します
なお上図のように、Amazon DynamoDB や Amazon S3 のイベントデータを Amazon EventBridge に渡すためには、Amazon CloudTrail でイベントソースのデータイベントを記録するように証跡を作成する必要があります。詳しくは、「証跡のデータイベントの記録」をご覧ください。
イベント駆動型アプリケーションでは、例えば「ユーザーが登録された」や「予約注文が入った」などあらかじめ条件を設定したイベントを起点として、自律的に処理が実行されるように実装できます。特定の処理ごとに分割された小さな独立したサービスでソフトウェアを構成 (マイクロサービスアーキテクチャ) することで、単一のシステムですべての処理を管理する「モノリシック」なアプリケーションと比較して、スケールしやすく、拡張性の高い、柔軟なアプリケーションを構築できます。
AWS サービスを使ったイベント駆動アーキテクチャについて詳しくは、Amazon Web Servicesブログの「Operating Lambda: イベント駆動型アーキテクチャを理解する」をご覧ください。
2. CODE more / SERVE(r) less
「サーバーレス」とは、「サーバーが存在しない」ということではありません。AWS Lambda のようなサーバーレスのコンピューティングサービスを利用していても、コードを実行したり、APIを呼び出したりする後ろではクラウド上でサーバーが稼働しています。「サーバーレス」とは、OSやランタイムなどコードの実行基盤を、 AWS がユーザーに代わって管理することを意味し、それによりユーザーはサーバーの存在を意識することなくビジネスロジックに関わるコード開発に集中できます。
クリックすると拡大します
インフラ管理の手間とコストを減らしつつ、コード開発にもっと多くの力を割く (CODE more / SERVE(r) less) サーバーレスアーキテクチャが提示する考え方については、#ServerlessForEveryone というハッシュタグの元、AWS の Principal Developer Advocate を務める Eric Johnson 氏が中心となり、Twitter 上でさまざまな情報発信、意見交換が行われています。サーバーレスアーキテクチャの最新の動向をお知りになりたい場合は、ぜひ Eric Johnson 氏のアカウント (@edjgeek) のフォロー、または #ServerlessForEveryone で検索してみてください。
3. Lambda ランタイム
AWS Lambda では、複数言語のランタイムを正式にサポートしています。ランタイムとは、プログラムの実行環境を指し、例えば「Python 3.9」の標準機能を使ったプログラムであれば、AWS Lambda の Python 3.9 ランタイムを利用するだけで、ユーザーは自分で実行環境の構築をしなくてもすぐにコードを実行できます。
2022 年 2 月現在サポートされているランタイムの種類は以下の通りです。
ランタイム |
バージョン |
.Net Core (C#/Powershell) |
3.1 |
Go |
1.x |
Java |
11 / 8 on Amazon Linux 2, 8 on Amazon Linux 1 |
Node.js |
14.x, 12.x |
Python |
3.9, 3.8, 3.7, 3.6 |
| Ruby | 2.7 |
クリックすると拡大します
ランタイムバージョンのサポート状況については、『AWS Lambda デベロッパーガイド』の「ランタイムサポートポリシー」をご覧ください。非推奨 (サポート終了) になったランタイムバージョンであっても引き続き Lambda 関数の呼び出しに利用できますが、AWS によるセキュリティ性の確保やテクニカルサポートを受けられなくなるため、サポート対象のランタイムバージョンへの移行をお勧めします。
ただし、カスタムランタイムを構築することで、AWS がサポートしていないいかなるプログラム言語のランタイムも自由に利用できます。カスタムランタイムについて詳しくは、「AWS Lambda のカスタムランタイム」をご覧ください。
なお、コンテナベースのアプリケーション開発の需要の高まりを受け、2020 年 12 月より、AWS Lambda は従来の .zip ファイルのアーカイブに加えてコンテナイメージをサポートするようになりました。これにより、Lambda 関数を、上記のランタイムと依存関係をまとめてコンテナイメージとしてパッケージ化しデプロイすることができるようになりました。詳細に関しては こちらの Amazon Web Service ブログ記事 をご覧ください。
4. AWS Lambda の関数設定
前述のように、AWS Lambda ではコードの実行環境は AWS 側で管理されるため、ユーザーはコードの開発に集中できます。ユーザーが Lambda 関数を作成する際は、実行されるコード自体の開発と、メモリーやタイムアウト、IAMロール、イベントトリガーなど Lambda 関数を実行する上での関数オプションの設定が主な作業になります。
クリックすると拡大します
なお、Lambda 関数オプションの設定は、Lambda コンソールおよび Lambda API で設定できます。詳しくは、「Lambda 関数オプションの設定」をご覧ください。
5. 複数の Lambda 関数間でのライブラリの共有
AWS Lambda で、ランタイムの他にライブラリや依存関係を利用するには、.zip アーカイブやコンテナイメージに該当のライブラリや依存関係を同梱してデプロイパッケージを作成します。ただし、複数の Lambda 関数で同じライブラリなどを利用する場合、関数ごとに同じライブラリを同梱することはデプロイパッケージのサイズが膨らむ要因になります。
そのためAWS Lambda では、複数の Lambda 関数間で共通のライブラリや依存関係を共有できる仕組みとして Lambda レイヤーが提供されています。
クリックすると拡大します
Lambda レイヤーには、ライブラリ、 カスタムランタイム 、データ、または設定ファイルを含めることができます。Lambda レイヤーを使用することで、コードの共有と責任の分離を促進し、ビジネスロジックの記述をより迅速に繰り返すことができます。
なお、コンテナイメージでは Lambda レイヤーをサポートしていません。コンテナイメージ内で Lambda レイヤーを利用したい場合は、Amazon Web Services ブログの「コンテナイメージ内で Lambda レイヤーと拡張機能を動作させる」をご確認ください。
最新アップデート : AWS Lambda の進化
2014 年にサービスを開始した AWS Lambda は、現在も進化を続けています。例えば、2021 年 9 月 29 日から、従来の x86 プロセッサに加えて、ARM ベースの AWS Graviton2 プロセッサを利用できるようになりました。
これにより、Lambda 関数は、20% 低いコストで最大 19% 優れたパフォーマンスを実現できるようになりました。
AWS Graviton2 プロセッサの利用開始について詳しくは、Amazon Web Services ブログの「AWS Graviton2 プロセッサを搭載した AWS Lambda 関数 – Arm で関数を実行し、最大 34% 優れた料金パフォーマンスを実現」をご覧ください。
クリックすると拡大します
まとめ
本記事では、AWS Lambda の機能を 5 つの項目に分けてご紹介しました。
最後に、全体の図を見てみましょう。
本記事は、従来型のモノリシックアーキテクチャと比較して、「サーバーレス」や「マイクロサービス」アーキテクチャが優れていると主張するものではありません。サーバーレスアーキテクチャであっても、ケースバイケースでメリットもデメリットも存在しています。より堅牢で、単一のシステムで統合的に各種プロセスを管理することが望ましいアプリケーションの場合は、従来型のモノリシックアーキテクチャが向いているケースも十分に考えられます。
AWS では、各アプリケーションの特性に合わせて最も効果的なアーキテクチャを設計・構築いただけるよう、サーバーレスを含む多様なサービスを提供しています。
なお、サーバーレスの便利な点や勉強方法については、過去の builders.flash 記事「サーバーレスって何が便利なの ?」や「サーバーレスの勉強方法について聞いてみた」にも掲載されておりますので、ぜひご一読ください。
また、AWS Lambda のサービスの詳細に関しましては、こちら をご覧ください。
AWS グラレコ解説のその他の記事はこちら
- 選択
- 今話題のブロックチェーンをAWSで実現する仕組みをグラレコで解説 »
- サーバーレスって何が便利なの ? AWS でサーバーレスを構築するためのサービスをグラレコで解説 »
- 機械学習のワークフローってどうなっているの ? AWS の機械学習サービスをグラレコで解説 »
- 外部から AWS のバックエンドサービス利用を実現する仕組みをグラレコで解説 »
- AWS でデプロイの自動化を実現するベストプラクティスをグラレコで解説 »
- コンテナを使ってモノリスを分割する方法をグラレコで解説 »
- クラウドへ移行する理由とそのステップをグラレコで解説 »
- Windows ワークロードをクラウドへ移行するためのベストプラクティスをグラレコで解説 »
- サーバーレスのイベントバスって何 ? Amazon EventBridge をグラレコで解説 »
- サーバーレスで SaaS を構築する方法をグラレコで解説 »
- 「あなたへのおすすめ」はどう生成するの ? Amazon Personalize で簡単に実現する方法をグラレコで解説 »
- クラウド設計・運用のベストプラクティス集「AWS Well-Architectedフレームワーク」をグラレコで解説 »
- 特定の顧客セグメントにメッセージ送信。「Amazon Pinpoint」の仕組みをグラレコで解説 »
- アプリにユーザー認証機能を簡単に追加できる「Amazon Cognito」をグラレコで解説 »
- わずか数分で WordPress サイトを構築できる「Amazon Lightsail」をグラレコで解説 »
- 異なるアプリケーション同士の疎結合を実現。「Amazon SQS」をグラレコで解説 »
- Web アプリを高速に開発できる「AWS Amplify」をグラレコで解説 »
- 機械学習の知識ゼロでもテキストデータを分析。Amazon Comprehend をグラレコで解説 »
- ビジネスデータをまとめて可視化 & 分析。Amazon QuickSight をグラレコで解説
- 人工衛星の地上局を 1 分単位で利用。AWS Ground Station をグラレコで解説
- カオスエンジニアリングで本当にカオスにならないための進め方をグラレコで解説
- GraphQL API を簡単に作成 & 運用。AWS AppSync をグラレコで解説
- IoT 環境を必要な機能を選択するだけで構築。AWS IoT をグラレコで解説
- 高い可用性と耐久性のオブジェクトストレージ。Amazon S3 をグラレコで解説
- サーバーレスでイベント駆動型アプリケーションを実現。AWS Lambda をグラレコで解説
- データサイエンス教育の強い味方。Amazon SageMaker Studio Lab をグラレコで解説
- 高速で柔軟な NoSQL データベースサービス。Amazon DynamoDB をグラレコで解説
- リレーショナルデータベースを簡単・迅速に実現。Amazon RDS をグラレコで解説
- アプリのワークフローを視覚的に構成。 AWS Step Functions をグラレコで解説
- データ保護に使う暗号化キーを一元管理。AWS KMS をグラレコで解説
- アプリケーションへのトラフィックを効率的に負荷分散。Application Load Balancer をグラレコで解説
- AWS で簡単にコンテナアプリケーションを構築 ! Amazon ECS をグラレコで解説
- 大規模データセットも簡単クエリ! Amazon Athena をグラレコで解説
- キャッシュ機能でアプリの高速化を実現 ! Amazon ElastiCache をグラレコで解説
- 使い慣れたプログラミング言語でクラウド環境を構築 ! AWS CDK をグラレコで解説
- ストリーミングデータを簡単にキャプチャ、処理、保存 ! Amazon Kinesis Data Streams をグラレコで解説
- AWS で始める機械学習はじめの一歩 ! AWS の主要な AI/ML サービスをグラレコで解説
- リレーショナルデータベースをサーバーレス化 ! Amazon Aurora Serverless をグラレコで解説
- ML 駆動の検索エンジンで企業の情報管理を革新！ Amazon Kendra をグラレコで解説
- オンプレミス、エッジ、どこでも楽々コンテナ管理 ! Amazon EKS Anywhere をグラレコで解説
- 生成 AI アプリケーション開発をもっと身近に、簡単に ! Amazon Bedrock をグラレコで解説
- わずか数クリックで多様な脅威を監視しクラウドを保護 ! 脅威検出サービス Amazon GuardDuty をグラレコで解説
- データの改ざん耐性と変更履歴の検証可能性を実現 ! 台帳データベース Amazon QLDB をグラレコで解説
- 生成 AI x クラウドがもたらす次世代のイノベーション ! AWS Summit Japan Day 1 基調講演をグラレコで解説
- ビジネス向け生成 AI アシスタント Amazon Q Business をグラレコで解説
- 生成 AI コーディングアシスタント Amazon Q Developer をグラレコで解説
- フロントエンドとバックエンドを統合開発 ! フルスタック TypeScript 開発環境 AWS Amplify Gen 2 をグラレコで解説
筆者プロフィール
米倉 裕基
アマゾン ウェブ サービス ジャパン合同会社
テクニカルライター・イラストレーター
日英テクニカルライター・イラストレーター・ドキュメントエンジニアとして、各種エンジニア向け技術文書の制作を行ってきました。
趣味は娘に隠れてホラーゲームをプレイすることと、暗号通貨自動取引ボットの開発です。
現在、AWS や機械学習、ブロックチェーン関連の資格取得に向け勉強中です。
監修者プロフィール
下川 賢介 (@_kensh)
アマゾン ウェブ サービス ジャパン合同会社
シニア サーバーレススペシャリスト ソリューションアーキテクト
Serverless Specialist Solutions Architect として AWS Japan に勤務。
Serverless の大好きな特徴は、ビジネスロジックに集中できるところ。
ビジネスオーナーにとってインフラの管理やサービスの冗長化などは、ビジネスのタイプに関わらず必ず必要になってくる事柄です。
でもどのサービス、どのビジネスにでも必要ということは、逆にビジネスの色はそこには乗って来ないということ。
フルマネージドなサービスを使って関数までそぎ落とされたロジックレベルの管理だけでオリジナルのサービスを構築できるという Serverless の特徴は技術者だけでなく、ビジネスに多大な影響を与えています。
このような Serverless の嬉しい特徴をデベロッパーやビジネスオーナーと一緒に体験し、面白いビジネスの実現を支えるために日々活動しています。
福井 厚
アマゾン ウェブ サービス ジャパン合同会社
シニアソリューションアーキテクト サーバーレススペシャリスト
2015 年からアマゾンウェブサービスジャパンでソリューションアーキテクトとして活動。サーバーレススペシャリストとして日々モダンアプリケーション開発とサーバーレスの活用の技術支援を行なっています。
AWS を無料でお試しいただけます