低レイテンシーのイベントドリブン型アプリケーションの構築

Pulisher : AI & Data Analytics Center チェ・スンヒョン
Description : リアルタイムデータをイベントベースアプリケーションに実装する方法について紹介したセッション

はじめに

顧客データを活用し、リアルタイムでおすすめ商品を提示するビジネスが徐々に増えている中、要件を実装するためにはどのようなサービスを活用して実装できるのか、セッションを申し込みました。 リアルタイムデータをどのようにイベントベースで実装するのか学びたいです。

セッションの概要紹介

最小限の遅延時間でイベントベースのアプリケーションを構成できるかどうか、そしてその過程でどのような要素が考慮されるべきか、様々な側面でセッションが構成されています。

アプリケーションで遅延が発生した場合、大きく4つの要素を検討することができます。

１．Public Internet : インフラ環境で発生する遅延時間で、物理的な時間です。
２．Front Door : API、up sync方式など、最初にリクエストを受けた部分で発生する遅延です。
３．Computational service : 収集されたデータを処理する過程で発生する遅延です。
４．Integration services : 他のサービスと統合されて自動化したり、複数のサービスに渡ってアプリケーションを構築するところで発生する遅延タイプです。

ラムダが実行される環境でのlifecycleは次のような順序で構成されています。

1.新しい環境生成
2.ラムダコードのダウンロード
3.Extension初期化
4.Runtime初期化
5.イベントを処理する関数コードのハンドラメソッドの実行
6.関数コードの実行
7.完了後終了

この段階で実行時間の最適化の面でユーザー/AWS領域に区分されます。
関数内コード領域の場合、ユーザーのコード最適化を通じて時間を短縮することができます。
AWS X-Ray with Lambdaでどの部分で遅延時間が発生するのか確認することができます。

Lambdaの場合、繰り返し関数が実行できるため、ストリーミングデータを処理するのに適しています。

API GateWayと一緒にLambda、DynamoDBを接続して簡単な構造を構成することができますが、LambdaではなくStep Functionsで構成して内部的にビジネスロジックが入る場合、実行時間が長くなる可能性があります。

実際にLambdaとEventbridgeを活用してApplicationを構成する時、次のようなアーキテクチャで構成することができます。携帯電話アプリから発生したデータがREST APIを通じて様々な形で収集され、収集された後、Eventbridgeでイベントが検出され、その後のデータ分析、処理などのプロセスが行われます。

セッションを終えて

リアルタイム推奨システム、リアルタイムデータ処理などの業務で”遅延時間”に関連する内容が核心に入っているケースを見て、どのようなサービスを活用すれば、そのアーキテクチャを実装できるのかが気になりました。 そして、Lambdaをリアルタイム業務構成時に多く使用していますが、サービス内のどのような構造で回っていて、どの部分が最適化できる部分なのか知ることができました。最近、クラウドでもリアルタイム分析に対する要件が多く収集されていますが、Lambda、eventbridgeなどのサービスを活用して要件を満たすことができると期待されます。