AWSサーバーレスは、サーバーの管理やスケーリングを気にすることなく、アプリケーションを構築・実行できるアーキテクチャです。代表的なサービスとしては、AWS Lambda、Amazon API Gateway、Amazon DynamoDB、Amazon S3などがあります。これらのサービスを組み合わせることで、高可用性かつスケーラブルなシステムを短期間で構築できるため、近年注目を集めています。
AWSサーバーレスについての詳細は、公式サイトをご覧ください。 AWS サーバーレスコンピューティング
しかし、AWSサーバーレスにも適さないケースやデメリットが存在します。本記事では、AWSサーバーレス開発の経験が豊富な筆者が、そのデメリットと適さないケースについて解説します。
AWS Lambdaは、一定期間リクエストがない場合、コンテナがシャットダウンされます。次のリクエストが来た際に、コンテナの起動処理が発生するため、レイテンシが増加します。これをコールドスタートと呼びます。コールドスタートによるレイテンシの増加は、ユーザー体験を損なう可能性があります。
AWSサーバーレスを利用する場合、AWS独自のサービスや機能に依存することになります。他のクラウドプロバイダーへの移行や、オンプレミス環境への移行が困難になる可能性があります。
AWSサーバーレスは、複数のサービスを組み合わせて利用するため、デバッグが難しくなる傾向があります。各サービスのログを追跡し、問題の原因を特定するのに時間がかかる場合があります。
※ X-RAYやその他のAWSのDevOps製品を活用することでデバッグの容易性を向上できます
AWS Lambdaは、最大実行時間が15分に制限されています。バッチ処理など、長時間実行するタスクには不向きです。
ゲームアプリケーションなど、リアルタイム性が求められるアプリケーションでは、コールドスタートによるレイテンシの増加が問題になります。レイテンシを最小限に抑える必要がある場合、AWSサーバーレスは適していません。
ビッグデータの処理など、大規模なデータ処理が必要な場合、AWSサーバーレスは適していません。AWS Lambdaのメモリ制限(最大10GB)や実行時間制限(最大15分)により、処理が完了しない可能性があります。
複雑なビジネスロジックを含むアプリケーションでは、コードの管理やデバッグが難しくなります。モノリシックなアーキテクチャの方が、管理が容易な場合があります。
金融システムなど、高いセキュリティ要件が求められるアプリケーションでは、AWSサーバーレスが適していない場合があります。サーバーレスアーキテクチャでは、セキュリティ対策の一部をAWSに委ねることになるため、自社でセキュリティを完全にコントロールしたい場合は、従来のサーバー管理型アーキテクチャの方が適しています。
コールドスタートによるレイテンシの増加を軽減するために、以下の対策が有効です。
AWS Step Functionsを使用すると、Lambda関数を組み合わせて、ワークフローを定義できます。複雑なビジネスロジックを、複数のLambda関数に分割することで、管理がしやすくなります。
Serverless Frameworkや AWS SAMなどのサーバーレスフレームワークを活用すると、インフラのコード化やデプロイの自動化が容易になります。
AWSサーバーレスは、高可用性かつスケーラブルなシステムを短期間で構築できる一方で、コールドスタートによるレイテンシの増加、ベンダーロックイン、デバッグの難しさ、長時間実行するタスクへの不向きさなどのデメリットがあります。また、リアルタイム性が求められるアプリケーション、大規模なデータ処理、複雑なビジネスロジックを含むアプリケーション、高いセキュリティ要件が求められるアプリケーションでは、AWSサーバーレスが適さない場合があります。
AWSサーバーレスを採用する際は、これらのデメリットや適さないケースを理解した上で、アプリケーションの要件に合わせて適切なアーキテクチャを選択することが重要です。コールドスタート対策やステップ関数の活用、サーバーレスフレームワークの活用など、デメリットを軽減する方法もあるため、それらを積極的に取り入れることをお勧めします。
スモールスタート開発支援、サーバーレス・NoSQLのことなら
ラーゲイトまでご相談ください
低コスト、サーバーレスの
モダナイズ開発をご検討なら
下請け対応可能
Sler企業様からの依頼も歓迎