SpeedData

APIを介した接続

サーバレスの景観をナビゲートする：トレースコレクタAPIの旅からの教訓

サーバレスの旅―初のステップから大規模な挑戦へ

2023年9月4日
翻訳: 島田 麻里子

この記事は米Catchpoint Systems社のブログ記事「Navigating the Serverless Landscape: Lessons from our Tracing Collector API Journey 」の翻訳です。
Spelldataは、Catchpointの日本代理店です。
この記事は、Catchpoint Systemsの許可を得て、翻訳しています。

本シリーズの前回のブログでは、Amazon Prime Videoの再設計されたアーキテクチャと、最適なパフォーマンスとコスト効率を実現するための異なるアーキテクチャスタイルの統合方法について掘り下げました。
また、Amazonの決定が「サーバレスファースト」の考え方に与える影響についても議論し、特定のユースケースや要件に基づいて別のアーキテクチャアプローチを検討することの重要性を強調しました。

今回は、Prime Videoのケーススタディと並行しながら、トレーシングコレクタAPIの実装にまつわる私たちの旅にスポットライトを当てます。
私たちの経験、直面した課題、そして学んだ教訓を共有します。
さらに、AWS Lambdaのスケーラビリティ、様々なシナリオにおけるサーバレスアーキテクチャの適用可能性、あらゆるアーキテクチャセットアップにおける監視の重要性にまつわる重要な疑問を解決することを目標とします。

サーバレスコンポーネントの経験：トレーシングコレクタAPIのケーススタディ

私たちのトレーシングコレクタAPIを実装する旅は、Prime Videoの経験と非常によく似ています。
AWS LambdaとAWS API Gatewayをベースにした最初の実装では、最初のバージョンを迅速にデプロイし、ユーザからのフィードバックを速やかに収集することができました。

この初期バージョンの製品化に取り組む中で、いくつかの課題に突き当りました。

コールドスタートの遅延

私たちはコレクタLambda関数をJavaで開発し、JVM上で実行していましたが、コールドスタートによる大きな遅延が発生しました。
入ってくるリクエスト（とユーザ）の数が増えるにつれて、コールドスタートの平均はリクエストの総数と比較して非常に低くなりました。
しかし、ユーザのテレメトリデータリクエストに3～4秒のレイテンシを追加することは、たとえそれが稀であったとしても、良いことではありませんでした。

今日、AWS Lambdaはこの問題を解決するために「Provisioned Concurrency」や「SnapStart」といった機能を提供していますが、当時はまだ存在していませんでした。
コールドスタート問題を解決するために、私たちは偽の空のリクエストでLambda関数をトリガーしてLambdaインスタンスが破壊されるのを防ぐツールを社内で開発しました（オープンソースとして公開されています）。
このツールを使うことで、コールドスタートの発生を数桁減らすことができました。

しかし、それでもコールドスタートは時折発生します。
そのため、これは私たちのプラットフォームにとっては満足のいく結果ではありませんでしたが、他のアプリケーションにとってはそうかもしれません。

API Gatewayのリクエストコスト、AWS LambdaのアイドルCPUコスト

私たちが遭遇したもう1つの問題は、ユーザ数が増えるにつれてコレクタAPIへのリクエスト数が増え、リクエストあたりのAWS API Gatewayコストが増加したことです。
さらに、私たちはコレクタでI/Oに制限された操作（例えば、Kinesisストリームへのテレメトリデータの送信）をよく行うので、Lambdaの実行のかなりの部分がI/O操作が終了するのを待つのに費やされていました。
Lambdaは一度に1つのリクエストしか処理しないため、LambdaインスタンスではCPUがアイドルであるにもかかわらず、I/Oレスポンスを待つ計算時間を費やしていたため、これは重要です。

これらの理由（コールドスタートの遅延、API Gatewayのリクエストコスト、AWS LambdaのアイドルCPUコスト）から、私たちはコレクタAPIをサーバレスアーキテクチャから非サーバレスアーキテクチャに移行することにしました。
この場合、AWS API GatewayをAWS ALBサービスに、AWS LambdaをAWS ElasticBeanstalkサービスに置き換えて、コレクタAPIを再設計しました。

この変更を行った後、私たちのプラットフォームの残りの部分（特に、直接ユーザと接することのない非同期処理の部分）は何年もサーバレスのままであり、コストの問題もなく、素晴らしいスケーラビリティを提供してくれました。

コレクタアーキテクチャをサーバレスアーキテクチャで開始したことで、必須要件である製品の早期リリースが可能になりました。
そのおかげで、顧客から重要なフィードバックを早期に得ることができました。
もし同じようなシナリオに再び遭遇したら、私たちはおそらくサーバレスファーストの考え方に従い、再びサーバレスアーキテクチャから始めることを検討するでしょう。

主要なポイント

トレースコレクタAPIを実装する過程で、AWS API GatewayとAWS Lambdaを使用することによるコールドスタートの遅延やコストの増加など、さまざまな課題が明らかになりました。
これらの課題は、私たちのユーザベースが拡大し、その結果、コレクタAPIへのリクエスト量が増加するにつれて、さらに深刻化しました。
サーバレスアーキテクチャの間違いない利点にもかかわらず、私たちの特定のケースでは、非サーバレスアーキテクチャへの移行がこれらの課題に対してより効率的なソリューションを提供することを認識しました。

そのため、私たちは重要な問いかけをすることになりました。
「AWS Lambdaにはスケーラビリティの問題があるのか？」
この問いに答えることが、本シリーズの次回のベースとなります。