目次
元ネタはいつもお世話になっているAWS Architecture Blogにある下記2つの記事です。非常に簡潔にまとまっており、良い内容と思いましたので、これから使い始める方向けに、さくっと5分で要点を理解できる内容を、日本語で解説します。
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 CloudFront (Lambda@Edge)
非同期呼出し
CLIを使用した非同期呼出しの例を示します。
aws lambda invoke —function-name MyLambdaFunction —invocation-type Event —payload “[JSON string here]”Invocation-typeフラグに「Event」が指定されていることに注意してください。関数がエラーを返した場合、AWSは自動的に2回、合計3回の呼出しを再試行します。
これは、Lambda関数を非同期的に呼び出すサービスのリストです。
Amazon Simple Notification Service
非同期呼出しは呼出しリクエストをLambdaサービスキューに登録し、それらが到着すると同時に要求を処理します。 AWS X-Rayを使用して、Lambda サービスキューで経過した時間(dwell time)を確認することで、リクエストがサービスキューでどれくらいの時間を費やしたかを確認します。
Pollベースの呼出し
この呼出しモデルは、コードやサーバ管理なしでAWS StreamおよびQueueベースのサービスと統合できるように設計されています。 Lambdaはあなたに代わって以下のサービスをポーリングして、レコードを取得したのち関数を呼出します。 サポートされているサービスは次のとおりです。
AWSは我々の代わりにポーリング処理を管理し、本タイプで統合した関数の同期呼出しを実行します。 このモデルの再試行動作は、データソース内のデータの有効期限に基づいています。たとえば、Kinesis Dataストリームは、デフォルトで24時間（最大168時間）のレコードを保存します。 各統合の具体的な詳細は、上記にリンクされています。
まとめ
３つの方式をまとめると下図の通りです。
- カテゴリー
この記事をシェアする
