はじめに
近年、IT業界のトレンドの中で「サーバレス」という言葉を頻繁に耳にすることが増えてきましたが、サーバレス未経験の方にはミステリアスな部分が多いかもしれません。
本稿ではサーバレスの基本的な概念を解説し、AWSが提供するサーバレスのサービスと利用ケースを簡単にご紹介します。
サーバレスとは
サーバレスとは、個々の利用ユーザ企業の管理者がクラウド上にあるサーバの存在を意識せずにアプリケーションやデータベースの利用ができるクラウド利用形態のことを指します。
たとえば、Amazon EC2インスタンスをベースとしたアーキテクチャを構成する場合、必要なミドルウェアのインストールやセキュリティパッチの適用などのサーバ運用が必要となり、これが「サーバを意識すること」に繋がります。
これらを意識せずにアプリケーションを設計・開発できるのがサーバレスという考え方です。
サーバーが存在しないのではなく、サーバーの準備・運用が不要であることを意味します。
AWSにおけるサーバレスサービス
AWSはサーバレスアーキテクチャを構築するためのさまざまなサービスを提供しています。
以下ではAWSにおける主なサーバレスサービスをご紹介します。
AWS Lambda
サーバーのプロビジョニングや管理をせずにコードを実行できるサービスです。
サーバを構築・管理する必要がないためユーザーはアプリケーション開発にすぐに取り組むことができます。
Amazon EventBridge
イベント駆動型アプリケーションを簡単に構築できるサーバレスサービスです。
イベント駆動型とは、イベントの発生をきっかけとして処理を行う実行形式のことです。
AWS Step Functions
複数の処理を連携して実行するワークフローを簡単に作成・管理できるサービスです。
AWS Step Functionsを使用することで、サーバレスアプリケーションのオーケストレータとして各プログラムの呼び出し順序を制御できます。
Amazon SQS(Simple Queue Service)
フルマネージドのキューイングサービスです。
キューイングを利用することでシステム間を疎結合にでき、変更を加えたい場合や障害が発生した場合の影響範囲を最小限にとどめることができます。
また、Amazon SQSはトラフィックが急増した場合でもメッセージがキューに溜まり、後続のシステムが一度に多くのリクエストを処理しなくても済みます。
逆にリクエストが少ない時にはリソースを節約することで、必要に応じたリソース量で処理を行うことができます。
結果として、Amazon SQSはシステムの負荷を時間にわたって平準化し全体の安定性と効率を向上させます。
Amazon SNS(Simple Notification Service)
大規模にメッセージを送信できるPub/Sub型のメッセージングサービスです。
Pub/Sub型とは多数のシステム間で非同期にメッセージを配信する仕組みのことを指し、1つのメッセージを複数の送信先へ効率的に通知できます。
Amazon API Gateway
RESTful APIとWebSocket APIを作成、公開、および管理するためのサービスです。
バックエンドサービスとの接続やデータの変換、アクセス制御などを効率的に管理できます。
Amazon S3
高いスケーラビリティと可用性を持つオブジェクトストレージです。
静的ウェブサイトのホスティングやデータストレージ、バックアップなど多様な用途に利用できます。
またAmazon S3の基本機能に加えられた追加オプションとしてイベントトリガーがあります。
この機能を通じてS3バケット内の操作（たとえばファイルのアップロードや削除など）が行われた際に自動的に他のAWSサービスが起動するような設定をすることが可能です。
Amazon DynamoDB
フルマネージドのNoSQLデータベースサービスです。
サーバレスアプリケーションにおけるデータの保存と検索に使用されます。
NoSQLデータベースであるため単純な検索とクエリ処理に優れていますが、SQLデータベースのような複雑なクエリや結合操作には適していません。
サーバレスアーキテクチャのメリット・デメリット
サーバ運用を意識する必要がないということは純粋に運用負荷が減って幸せなイメージですが、そのようなメリットだけでなくデメリットも存在します。
サーバレスのメリット
- サーバ管理等の運用作業を考慮する必要がない
上述の通り、サーバレスではサーバの運用作業は必要ありません。
サービス側で必要なランタイムやソフトウェアがインストールされ、継続的なパッチ適用もサービス側で行われます。
- 柔軟なスケーリングが可能
サーバレスではスケーリングの仕組みがサービス側に組み込まれています。
そのため急激なトラフィックの増加にも柔軟に対応できます。
- 従量課金制
サーバはユーザーがアプリケーションを利用しているかどうかにかかわらず、起動時間によって課金されます。
サーバレスでは実行時間やスループットに対して課金されるため、リソースの使用が少ない場合にはコストを大きく節約できます。
- 可用性と耐障害性
サーバレスではサービス側に可用性や耐障害性を高める機能が組み込まれています。
たとえば自動フェイルオーバー機能など障害が発生した際にも迅速に対処できる仕組みがあり、これによりシステムのダウンタイムを最小限に抑えることができます。
サーバレスのデメリット
- 長時間実行時のコストメリットが低い
サーバレスは従量課金制であることからリソースの使用が少ない（実行時間が短い）場合に高いコストメリットを享受できます。
一方でリソースの使用量が多い（実行時間が長い）場合には、サーバを使用したときよりもコストが高くなってしまう場合があります。
- コールドスタート
Lambda関数は使用されていないときは停止状態にあり呼び出された時にはじめて起動するため、関数がロードされるまでの初期化時間が発生します。
また急激なアクセス数上昇で新しく関数を起動しないといけない場合もあり、これが遅延の原因になることがあります。
- ベンダーロックインと特定サービスへの依存
サーバレスはクラウドサービスの仕様にしたがってアプリケーションを開発する必要があります。
めったにないですが、クラウド事業者がサービス仕様を大幅に変更したりサービスを停止したりするとアプリケーションの改修が必要になる場合があります。
何らかの事情で他のクラウドサービスへ移したい場合も大きな改修が必要となる場合があります。
- 商用製品の選択肢減少
利用したい商用製品が動作しない可能性があります。
とくに従来のサーバベースの環境で導入するようなセキュリティ製品はほぼ導入できず、専用の製品を探す必要が出てきます。
サーバレス利用が向いているケースと向いていないケース
上述のメリット・デメリットを踏まえて考えると、以下ケースでサーバレスの向き不向きを分類できます。
サーバレスが向いているケース
- 新規サービスを開発するケース
サーバレスを使用することでサーバ導入にかかる費用や運用に関わる費用を削減できるため、手軽に新規サービスの開発に取り組みやすくなります。
また柔軟なスケーリングが可能なため、市場投入時の需要に応じたトラフィックの増減にも自動で対応できます。
- バッチサーバを部分的にサーバレス化するケース
Webアプリケーションは1機能ずつ切り出すことは難しいですが、バッチは1機能ごとに独立して動作する場合が多いと思います。
対象機能が限定されるのでテスト範囲も限られ、小規模なチームでサーバレス化作業を実施しやすくなります。
またサーバレスアーキテクチャで使用されるマネージドサービスはクラウド内ですでに冗長構成が取られています。
つまり何も考えずとも最低限の冗長構成となり、さらに再試行の設定等により耐障害性を高めることもできます。
サーバレスが向いていないケース
- 旧来サーバ向けアプリケーションを活用する場合
旧来サーバ向けアプリケーションをサーバレスアーキテクチャに移行する場合、大幅な再設計が必要になります。
Lambdaを使用する場合はMVCフレームワークのアプリケーションを再設計する必要があり、S3を使用する場合はそのための実装変更も必要です。
また前述のサーバレスのデメリットでもあるように利用していた製品が使えなくなる場合もあり、サーバレスアーキテクチャを導入するための開発費が享受できるメリットを上回る可能性があります。
- 応答速度の要求が厳しいケース
サーバレス利用が応答速度の要求が厳しいケースに向いていない理由は、上述のデメリットであげたコールドスタートの問題に起因します。
リアルタイムでの高速応答を必要とするアプリケーションやゲームなどではこの遅延が許容できない場合があります。
まとめ
サーバレスは特定のケースにおいて理想的な選択となり得ますが、すべてのケースに適しているわけではありません。
開発・運用するプロジェクトにおける制約の種類と程度を必ず把握し、サーバレスのメリット・デメリットと照らし合わせた上で最適な選択をしてください。
