AWS Lambdaを紐解く：スケーラビリティと適用性を探る

スケーラビリティの真実とサーバレスの明確な監視

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

この記事は米Catchpoint Systems社のブログ記事「Unraveling AWS Lambda: Exploring Scalability and Applicability 」の翻訳です。
Spelldataは、Catchpointの日本代理店です。
この記事は、Catchpoint Systemsの許可を得て、翻訳しています。

前回のブログでは、サーバレスコンポーネントを使用してトレースコレクターAPIを実装した実体験を共有しました。
Amazon Prime Videoのアーキテクチャー再設計との類似点を示しながら、コールドスタートの遅延やコストの増加など、私たちが遭遇した課題について議論しました。

マイクロサービスとサーバレスアーキテクチャに関するこのブログシリーズの最終回では、私たちの経験から生じた中心的な疑問の1つをより深く探ります。
「AWS Lambda にはスケーラビリティの問題があるのか？」
AWS Lambdaのスケーラビリティの複雑さを深く掘り下げ、その強みと潜在的なボトルネックを検証します。

また、様々なシナリオにおけるサーバレスアーキテクチャの適用性を検討し、どのようなアーキテクチャ設定においても監視が重要であること、そしてサーバレスの世界でどのようにこれを実現できるかを強調します。
さあ、飛び込みましょう！

AWS Lambdaにはスケーラビリティの問題があるのか？

AWS Lambdaは、一般的なアカウントレベルの制限と関数レベルの制限、2種類の同時並行制限が適用されています。

アカウントレベルの同時並行性制限

これは、AWSアカウントの単一リージョン内の全機能の同時並行性制限の合計です。
デフォルトの同時並行性の上限は1リージョンあたり1000ですが、AWSに上限引き上げをリクエストすることで10Kまで引き上げることができます。

関数レベルの同時並行性制限（または予約同時並行性）

アカウント内の単一の関数に対して、特定の同時並行性を設定できます。
これは、特定の関数がアカウントの利用可能な同時並行数をすべて消費しないようにするのに便利です。
関数に同時並行数を予約することで、特定の実行数を同時に処理するための最低限の容量を確保することができます。

さらに、AWSは「Provisioned Concurrency」として知られる機能を導入しました。
これによって、コールドスタート（Lambdaコンテナの初期化とLambda関数のユーザコードの初期化）の遅延にぶつかることなく、関数を初期化してハイパーレディな状態に保ち、迅速に対応できるようになります。
これは、コールドスタートの待ち時間を減らすことができるため、予測可能なトラフィックパターンを持つアプリケーションに役立ちます。

これらのことから、多くの同時実行（10K以上）を処理する必要がある場合、AWS Lambdaはあなたのケースに合わないかもしれません。
その場合、コンテナの利用を検討する必要があるかもしれませんが、その前に、これほど高い同時並行性が本当に必要かどうかを判断してください。
1つのサーバレスアプリケーションの並行性要件を減らすには、主に2つのアプローチがあります。

バッチ処理の検討

特にイベント・ドリブン・アーキテクチャ（例えば、10Kまでのレコード・バッチを持つKinesisストリームや、10Kまでのメッセージ・バッチを持つSQSキューからLambdaをトリガーする）を使っている場合は、バッチ処理を検討しましょう。
その代償としては、ロジックが若干複雑になり、処理が若干遅れるということです。
もちろん、特にトラフィックパターンが予測できない場合は、遅延を最小限に抑えるロジックを追加することもできます。

複数のリージョン・複数のAWSアカウントでのAWS Lambda関数実行

あなたのアーキテクチャでバッチがオプションでない場合、複数のリージョン、あるいは複数のAWSアカウントでAWS Lambda関数を実行することを検討するかもしれません。
このオプションはどちらかというと回避策であり、既に多くのユーザを抱えている場合、アプリケーションに必要なスケーラビリティはありません。

AWS Lambdaでは、同時並行性の制限に加えて、関数に対して2種類の同時並行性制御を行います。
「予約同時並行性（reserved concurrency）」と「未予約同時並行性（unreserved concurrency）」です。
アカウントレベルの上限を持つ未予約同時並行性プールは、指定されたレベルの予約同時並行性を持たない関数間で共有されます。

さらに、AWSは地域の容量に応じてバースト同時並行性を制御します。
これらの制限があっても、Lambda関数はAWS上の他のタイプのコンピュートよりもはるかに優れたスケールを実現します。
AWS Lambdaのスケーリング速度が他のAWSサービスと比較してどうなのかは、こちらのブログ記事をご覧ください。

サーバレスはすべてのケースに有効か？

AWS Lambdaは多くのアプリケーションにとって強力なツールですが、最適な選択とは言えないケースもあります。

長時間稼働プロセス

AWS Lambdaファンクションには実行上限があります（現在は15分）。
そのため、より長い処理時間を必要とするタスクはLambdaに適さない可能性があり、EC2インスタンスやECSやEKS上のコンテナで処理した方がよいかもしれません。

ステートフル・アプリケーション

AWS Lambdaはステートレスコンピューティングのために設計されています。
もしあなたのアプリケーションが、呼び出しの間に永続的な状態を必要としたり、長時間の接続を必要とするのであれば、それはLambdaに適していないかもしれません。

高性能コンピューティング

グラフィックスを多用するアプリケーションなど、強力な処理能力を持つハイパフォーマンス・コンピューティングを必要とするワークロードには、Lambdaは最適ではないかもしれません。

大容量ファイル処理

AWS Lambdaでは、デプロイパッケージのサイズとエフェメラルディスク容量（/tmp領域）に制限があります。
これらの制限を超える巨大なファイルを処理する必要があるアプリケーションの場合は、別のコンピュートサービスを利用した方がよいかもしれません。

リアルタイム・マルチプレーヤー・ゲーム

AWS Lambdaは、持続的にオープンな接続と低レイテンシの通信を必要とするリアルタイムのマルチプレイヤーゲームには最適な選択ではないかもしれません。

シルバーブレッドは存在しないので、AWS Lambdaと他のサービスのどちらが最適かを決める前に、特定のユースケースと要件を評価することを忘れないでください。
経済学者のThomas Sowell氏が言うように、解決策はない、あるのは妥協だけなのです。
（書籍「A Conflict of Visions: Ideological Origins of Political Struggles」より）

サーバレスアプリケーションの監視

アプリケーションを設計するときはいつも、最初から次のような質問を自分に投げかけてください。
「何かがうまくいかなくなったとき、何かが間違っていることをどうやって知るのか、何が間違っているのかをどうやって知るのか、それを修正するために何をすべきかをどうやって知るのか、そしてその修正がうまくいったことをどうやって検証するのか？」
潜在的な問題は、アプリケーションの一部(「バグ」)や、アプリケーションと他のアプリケーションやサービスとの間の相互作用(上流のキューの過負荷か？サービスプロバイダからの未処理の例外か？)、または、あなたが依存していることを知らないサービス(アプリケーションとユーザとの間のISP障害か？)によって引き起こされる可能性があることを覚えておいてください。

Catchpointでは、常に顧客が体験することを測定することから監視を開始します。
アプリケーションに接続するWebブラウザは、DNSルックアップ、アプリケーションURLへのリクエスト、各コンポーネントへの個別のリクエストなどを行います。
モノリシックなアプリケーションでは、単一の親サービスがすべてのリクエストを処理することがあるため、このサービスはすべてのリクエストを追跡することができます。

サーバレスで異なるのは、個々のリクエストはそれぞれ全く別の機能で処理される可能性があるということです。
監視メカニズムは、ある機能によって処理されたリクエストが、別の機能によって処理されたリクエストと関連付けられることを保証する必要があります。

サーバレスアプリケーションの監視の良い点は、アーキテクチャがすでに小さなコンポーネントに分解されていることです。
そのため、各コンポーネントを介してリクエストのパフォーマンスをトレースすることは、単に関数の開始時刻と停止時刻を見つけるだけの問題です。
これは、マイクロサービスによってなされた約束事と同じです。

マイクロサービスは、全体的なアーキテクチャを断片に分割するので、それぞれの断片が何をするのかを理解しやすくなります。
システム全体のアーキテクチャと同じように、関数、マイクロサービス、コンテナ、従来のコンピュートのどれを使うにせよ、監視は最初から分析し、設計に組み込むべきものなのです。

Catchpointがマイクロサービスとサーバレス監視を進化させる

今年に入ってから、私たちはクラウド監視のパイオニアであるThundra.ioの資産を買収したと発表しました。
これは、インターネット・パフォーマンス・モニタリング（IPM）の重要な側面である、高度なマイクロサービスとAPI監視機能を備えたCatchpointのアプリケーション体験ソリューションを強化する動きです。
Catchpoint のエンジニアリングチームは現在、Thundraのコア機能を、すでに業界をリードするIPM プラットフォームにシームレスに組み込んでいるところです。

まもなく、 Catchpointのユーザは、ユーザからAPIコール、そしてサーバトレースまで、顧客体験全体を観察できるようになります。

進化し続ける景観をナビゲートする

私たちはこのブログシリーズを通して、マイクロサービスとサーバレスアーキテクチャの利点、妥協点、そして実際のアプリケーションについて包括的な調査を行ってきました。
Amazon Prime Videoの戦略的なアーキテクチャ再設計の背後にある論理的根拠を理解することから、トレースコレクタAPIを使った私たち自身の旅をナビゲートすることに至るまで、私たちはサーバレス・コンポーネントをアプリケーションに統合することから学んだ複雑さと教訓を解き明かしました。

このシリーズを締めくくるにあたり、マイクロサービスとサーバレスアーキテクチャの世界は常に進化しており、特効薬は存在しないことを認めます。
各アーキテクチャの選択には、独自の引き替え条件や課題が伴います。
思慮深く十分な情報に基づいたアプローチを採用し、アプリケーション固有の要件を理解し、監視と最適化の力を活用することで、優れたパフォーマンスを駆動し、卓越したユーザ体験を提供する、堅牢でスケーラブルかつ信頼性の高いシステムを構築することができます。

Happy building!（良き構築を！）