基幹クラウド構築

【5分でわかる】AWS Lambda連携するときに、誰もが調べるアプリ設計考慮点

【5分でわかる】AWS Lambda連携するときに、誰もが調べるアプリ設計考慮点

目次

元ネタはいつもお世話になっているAWS Architecture Blogにある下記2つの記事です。非常に簡潔にまとまっており、良い内容と思いましたので、これから使い始める方向けに、さくっと5分で要点を理解できる内容を、日本語で解説します。


How to Design Your Serverless Apps for Massive Scale | Amazon Web Services

Serverless is one of the hottest design patterns in the cloud today, allowing you to focus on building and innovating, rather than worrying about the heavy lifting of server and OS operations. In this series of posts, we’ll discuss topics that you should consider when designing your serverless architectures. First, we’ll look at architectural patterns […]

aws.amazon.com

og_img

Understanding the Different Ways to Invoke Lambda Functions | Amazon Web Services

In our first post, we talked about general design patterns to enable massive scale with serverless applications. In this post, we’ll review the different ways you can invoke Lambda functions and what you should be aware of with each invocation model. Synchronous Invokes Synchronous invocations are the most straight forward way to invoke your Lambda […]

aws.amazon.com

og_img

Special Thanks to  George-san,your blog is very useful.

大規模サーバーレスアプリケーションを設計する方法

サーバーレスは、今日のクラウドで最も注目されているデザインパターンの1つであり、サーバやOSの運用負荷を気にすることなく、構築(Build)やそれによる革新に集中することができます。 この一連の記事では、サーバーレス・アーキテクチャを設計する際に考慮すべきトピックについて説明します。 まず最初に、サーバーレスで大規模を実現するように設計されたアーキテクチャパターンについて見ていきます。

スケーリングにおける考慮点

一般に、「サーバーフル」な世界(=サーバを意識して、アプリを開発する世界)の開発者は、1日、1週間、または1ヶ月の間に合計でどれだけのリクエスト数を処理できるかどうか、およびシステムをどれだけ早く拡張できるかを考慮する必要があります。しかしサーバーレスの世界に入ると、理解しなければならない最も重要な質問は「あなたのシステムが処理するように設計されているConcurrency(同時並行性)はどのようなものですか?」となります。

AWS Serverlessプラットフォームは、需要に応じて非常に迅速に拡張(スケーリング)されます。 以下は、完全同期処理のアプリケーションにおけるサーバーレス設計の例です。高負荷時には Amazon API GatewayとAWS Lambdaは、その負荷に応じて拡張されます。この設計では、AWS Lambdaは負荷に応えるため数千から数万に拡張されます。それに伴い、バックエンドのRDB(リレーショナルデータベース)にも同時に数千から数万の接続が行われることとなり、RDBには非常に高い負荷がかかることになります。 殆どの場合RDBはここまで多くの同時接続を受け入れるようには設計されていません。

この設計においては、RDBがボトルネックとなる危険性があり、それによるサービスの停止を引き起こす可能性があります。 またスロットリング(=リソースの制限値を超えてしまう)やデータベースコネクションの枯渇によるデータ損失の危険性もあります。

クラウドネィティブなデザイン

非同期モデルの疎結合なアーキテクチャに移行することを検討します。このアーキテクチャでは、Amazon KinesisやAmazon Simple Queue Service(SQS)のような仲介役となるサービスを利用し受信リクエストをバッファリングします。

Amazon KinesisやAmazon SQSは、AWS Lambdaのイベントソースとして設定できます。 以下の設計では、AWSは自動的にAmazon KinesisストリームまたはSQSリソースにある新しいレコードを自動的にポーリングして、それらをLambda関数にデリバリーします。 配信毎のバッチサイズを制御し、さらにLambda関数毎に同時実行数を制御することができます 。

この設計により、大量の要求を受け入れ、その要求を堅牢性のあるデータストアに格納し、システムが処理できる速度にコントロールすることができます。

まとめ

このようにサーバーレスコンピューティングを使用すると、サーバーベースのアプリケーションよりもはるかに迅速に拡張できますが、アプリケーション設計者は、拡張による後続サービスへの影響を常に考慮する必要があります。 サーバーレスアプリケーションを構築するときは、常にコスト、速度、および信頼性に留意するようにしてください。

Lambda関数を呼び出すためのさまざまな方法を理解する

前章では、サーバーレスアプリケーションで大規模を実現するための一般的なデザインパターンについて説明しました。 この記事では、Lambda関数を呼び出すことができるさまざまな方法と、各呼び出しモデルについて知っておくべきことについて説明します。

同期呼出し

同期呼出しは、Lambda関数を呼び出すための最も簡単な方法です。 このモデルでは、Lambda Invoke API呼出しを実行すると、すぐに関数が実行されます。 これはCLIまたはサポートされているSDKの使用など様々な方法で実現することができます。

CLIを使用した同期呼出しの例を示します。

 aws lambda invoke —function-name MyLambdaFunction —invocation-type RequestResponse —payload “[JSON string here]”

Invocation-typeフラグは、「RequestResponse」の値を指定します。 これはAWSにLambda関数を実行して関数が完了するのを待つように指示します。 同期呼出しを実行するときには、応答を確認し、エラーがあったかどうか、また呼出しを再試行する必要があるかどうかを判断する必要があります。

多くのAWSサービスは、Lambda機能をトリガーするイベントを発行できます。 これは、Lambda関数を同期的に呼び出すサービスのリストです。

Elastic Load Balancing (Application Load Balancer)

Amazon Cognito

Amazon Lex

Amazon Alexa

Amazon API Gateway

Amazon CloudFront (Lambda@Edge)

Amazon Kinesis Data Firehose

非同期呼出し

CLIを使用した非同期呼出しの例を示します。

 aws lambda invoke —function-name MyLambdaFunction —invocation-type Event —payload “[JSON string here]”

Invocation-typeフラグに「Event」が指定されていることに注意してください。関数がエラーを返した場合、AWSは自動的に2回、合計3回の呼出しを再試行します。

これは、Lambda関数を非同期的に呼び出すサービスのリストです。

Amazon Simple Storage Service

Amazon Simple Notification Service

Amazon Simple Email Service

AWS CloudFormation

Amazon CloudWatch Logs

Amazon CloudWatch Events

AWS CodeCommit

AWS Config

非同期呼出しは呼出しリクエストをLambdaサービスキューに登録し、それらが到着すると同時に要求を処理します。 AWS X-Rayを使用して、Lambda サービスキューで経過した時間(dwell time)を確認することで、リクエストがサービスキューでどれくらいの時間を費やしたかを確認します。

Pollベースの呼出し

この呼出しモデルは、コードやサーバ管理なしでAWS StreamおよびQueueベースのサービスと統合できるように設計されています。 Lambdaはあなたに代わって以下のサービスをポーリングして、レコードを取得したのち関数を呼出します。 サポートされているサービスは次のとおりです。

Amazon Kinesis

Amazon SQS

Amazon DynamoDB Streams

AWSは我々の代わりにポーリング処理を管理し、本タイプで統合した関数の同期呼出しを実行します。 このモデルの再試行動作は、データソース内のデータの有効期限に基づいています。たとえば、Kinesis Dataストリームは、デフォルトで24時間(最大168時間)のレコードを保存します。 各統合の具体的な詳細は、上記にリンクされています。

まとめ

3つの方式をまとめると下図の通りです。


カテゴリー

この記事を書いたメンバー

bxadm
bxadm

このメンバーの記事一覧

SAPシステムや基幹システムのクラウド移行・構築・保守、
DXに関して
お気軽にご相談ください

03-6260-6240 (受付時間 平日9:30〜18:00)

  • TOP
  • ブログ
  • 【5分でわかる】AWS Lambda連携するときに、誰もが調べるアプリ設計考慮点