Cron
サーバーレス設計でCronジョブを自動化すると、定期的なcronジョブを実行するためだけにサーバーを管理して支払う負担がなくなります。 Lambdaは、この小さいながらも面倒なアクションを簡単に置き換えることができます。 AWSのCloudWatch Eventsを使用すると、Lambdaを簡単にトリガーして、これらのCronジョブを実行して負担を取り除くことができます。
ウェブアプリ
Webアプリケーションへのサーバーレス設計の最も一般的な実装は、HTML、CSS、JavaScript、およびユーザーのブラウザーにロードされるAmplifyによってホストおよびデプロイされる画像ファイルなどの静的リソースを備えたフロントエンド用のシングルページアプリケーション（SPA）を使用することです。 次に、Javascriptの実行は、LambdaとAPIGatewayを使用して構築されたバックエンドAPIを介して送受信されます。 Cognitoは、バックエンドAPIを保護するためのユーザー管理と認証を提供するために使用されます。 DynamoDBは、APIのLambda関数によってデータを保存できるデータベースを提供します。
RESTful APIの場合、API Gatewayは次の機能への即時アクセスを提供します。
- アクセスを制御するための堅牢な方法
- 各エンドポイントとメソッドへのスロットルダウンをリクエストする
- キャッシング
- テストおよび製品リリースのためのカナリア展開
- 分析
DynamoDBおよびElasticsearchとの直接統合に加えて、Lambdaを使用してAppSyncAPIをAuroraなどの他のデータソースと統合することもできます。
バッチ処理
サーバーレスのもう1つの使用例は、バッチ処理またはファンアウトを実装することです。 これは、これらのシステムにはスパイク状の負荷がかかる傾向があり、次のバランスを維持することが難しいためです。
- 大量のタスクが発生したときにリソースをすばやくプロビジョニングする
- 特にリソースを使用しない場合にインフラストラクチャのコスト効率を維持する
SNSとLambdaは一般的にバッチ処理に使用されます。 SNSはLambdaの非同期イベントソースであり、公開されたすべてのメッセージがLambda呼び出しをトリガーします。 これにより、システムは非常に高いスループット（地域の同時実行制限によって制限されます）とその同時実行をスケールアップするための制限をすばやく達成できます。 また、SNSには自動再試行機能があり、Lambda呼び出しエラーが発生すると、失敗した呼び出しをさらに2回再試行します。
レガシーデータベースのように、SNSやLambdaほどスケーラブルではないダウンストリームシステムでは、Lambdaの同時実行数を制御することが重要です。 スパイクを受信するように設定されていない場合、公開するメッセージが多すぎると、システムが圧倒される可能性があります。 このような状況では、KinesisとSQSを使用すると、メッセージをバッチで処理でき、同時実行性を優れた方法で制御できます。
IoT
IoT Coreを使用すると、IoTデバイスはMQTT、WebSocket、またはHTTPを使用してバックエンドサービスに接続できます。 S3、Kinesis、Lambdaなどのサービスを使用して、接続されたデバイスによって生成されたデータを簡単に収集、処理、分析できます。
LambdaやIoT Coreなどのサーバーレステクノロジーにより、企業はインフラストラクチャにリソースを費やす代わりに、機能の提供に集中できます。 従量制の価格設定モデルにより、使用されなくなったリソースに潜在的に支払う代わりに、運用コストを簡単に直線的に表示できます。
Conclusion
AWSでサーバーレスシステムを設計するには、Lambdaと、それを他のAWSサービス（DynamoDB、S3、Cognitoなど）で適切に使用して、システムに最も効率的でスケーラブルで費用効果の高いソリューションを作成する方法を深く理解する必要があります。 InCloudは、AWSでのサーバーレスシステムの設計、開発、デプロイに関する専門知識を備えており、最高のシステムの構築を支援します。