ピュアサーバーレス構成でウェブシステムを構築・運用した所感

はじめに

AWS Lambda を活用することで、サーバーを一切立てずにウェブシステムを構築・運用することが可能です。 弊社では、複数の社内ツールだけでなく、一般利用者向けのウェブシステムもサーバーレス構成で構築・運用しているものがあります。

この構成を採用した理由としては、該当案件に対して大きなメリットがあると判断したためですが、実際に運用してみると、いくつかのデメリットも見えてきました。

本記事では、弊社が導入した AWS ベースのピュアサーバーレスシステムの概要と、そのメリット・デメリットを解説します。

ピュアサーバーレスシステムの概要

実際に運用しているサーバーレスシステムの構成概要は以下のとおりです。

この構成では、EC2 や RDS が提供するようなサーバー型のリソース（VPC 内に構築される要素）を使用せず、代わりに Lambda、S3、DynamoDB など、AWS が提供するマネージドな SaaS 型サービスのみを活用しています。 本記事では、このようにサーバー（ホスト）を一切持たずに完結する構成を「ピュアサーバーレスシステム」と定義し、以降この用語を利用します。

AWS Lambda には Python 製のフレームワークである AWS Chalice を採用しており、内部ではテンプレートエンジンを用いて Content-Type: text/html のレスポンスを返すことで、HTML コンテンツを生成・提供しています。

画像や JavaScript、CSS ファイルといった静的リソースは S3 にアップロードし、CloudFront でパスごとにオリジンを切り替えることで、Lambdaを経由することなく静的リソースに利用者がアクセスできるようにしています。 さらに、Lambda 側で適切なレスポンスヘッダ（例：Cache-Control や ETag）を付与することで、CloudFront のキャッシュ機能を活かした配信を実現しています。

デプロイには AWS CodeBuild や CodeDeploy を利用し、CodePipeline を通じて特定のブランチの変更をトリガーに、自動でデプロイが実行される CI/CD の仕組みを構築しています。

このシステムは、モダンなフロントエンドフレームワークを使って SPA（Single Page Application）を構築するのではなく、テンプレートエンジンによるサーバーサイド HTML 出力を前提としています。 そのため、JavaScript フレームワークの深い知識がなくても、テンプレートの修正のみで比較的容易に機能追加やデザイン変更が可能となっており、小規模な変更であればエンジニア以外でも対応できる設計となっています。

サーバーレスシステム採用の理由（メリット）

サーバーレスシステムの採用理由は、以下の3点に集約されます。

1. ランニングコストの削減

ユースケース次第では、サーバーを常時稼働させる構成に比べて大幅にコストを抑えることが可能です。アクセス頻度が少ないシステムや利用頻度にムラのあるサービスでは、稼働させていれば常に課金が発生するインスタンスよりも、コードを実行した分だけ課金される Lambda の課金モデルが非常に有利なためです。

2. 運用の安定性

AWS Lambda は、必要に応じて自動的に同時実行数をスケーリングする仕組みを持っています。

コールドスタート時間が十分に短ければ、EC2 のオートスケーリングよりも高速にスケーリングが行えるため、短期的なアクセススパイクにも柔軟に対応できます。

AWS アカウントには Lambda 関数の同時実行数に関する制限がありますが、デフォルトでは 1,000 の並列実行が割り当てられており、1秒あたり2,000〜3,000回程度の関数呼び出しが継続的に発生しない限りは、多くのユースケースで安定した運用が可能だと考えています。

さらに、今回の構成では CloudFront を前段に配置し、CDN キャッシュを活用することで Lambda 関数の呼び出し回数そのものを抑制し、パフォーマンスと安定性の両立を図っています。

3. インフラ管理の省略

EC2インスタンスや Docker 環境でシステムを稼働させる場合、それらの基盤上で動く OS やミドルウェアに関する脆弱性管理やアップデート対応は、運用チームが担う必要があります。
一方サーバーレス環境では、これらの管理責任をAWS 側に委ねることができるため、運用負荷を大きく軽減でき、サービス開発に集中できます。

 

これらのメリットが求められる環境に対して、先に紹介した構成を用いたシステムの導入・運用を行っています。 

実際にシステムを構築・運用してから感じたこと

開発者に求める前提条件

サーバーレス構成を導入することで、前述のようなメリットを享受できましたが、本番導入に至るまでには、従来とは異なる開発スタイルが求められました。

特に印象的だったのは、「フレームワーク志向」から「インフラ志向」への転換が必要だと感じたことです。 一般的なウェブサービス開発では、Laravel などのウェブフレームワークに従って機能を構築していくことが多いと感じていますが、今回のようなサーバーレス構成では、まずインフラ構成ありきで、それに最適化されたコードを書く必要があるように感じました。
つまり、「フレームワークに合わせてインフラを用意する」のではなく、「インフラに合わせてシステムを設計する」という発想が求められます。 そのため、上記のようなメリットが得られるとしても、予備知識なしで開発を行うのが難しいと感じました。

そのため、いくらサーバーレスによってインフラコストを抑えられるとしても、その構成に適応できる開発者やチームを確保すること自体が難易度の高い課題であり、場合によっては、サーバーのランニングコストを削減した以上に、開発体制を整えるための人件費の方が大きくなる可能性もあると感じました。

DynamoDBを用いた設計上の注意点

強いスケーリング処理性能・コスト削減の観点から DynamoDB を選定したのですが、この選択にも注意点がありました。 特にDynamoDB では柔軟な検索が困難であり、RDB のように後からクエリを増やしていく設計は適していません。

• 検索要件はテーブル設計段階での ソートキーやインデックスの設計に強く依存します
  
• インデックス数には上限があり、結合や集計といった処理は基本的にサポートされません
  
• 条件に合うデータをすべて取得して、アプリケーション側でフィルタリングするアプローチもありますが、これは経験上、対象データ件数が 1000 件程度が限界で、それ以上になるとレスポンスが大幅に劣化するため、何らかの工夫や割り切りをする必要があります

工夫した点・ハイブリッド構成の活用

サーバーレス構成の制約に対応しつつメリットを得るために、以下のようなハイブリッド構成を採用した事例もあります。

• 管理機能は、Laravel を用いた従来型のウェブアプリケーション（EC2 + RDB）として構築
  
• フロントの一部（ユーザー向けで、定期的なスパイクや、高負荷アクセスが想定されるページ）をサーバーレス構成で最適化（※この構成では、CDNによるキャッシュだけでは対応できない要件があったため、HTML出力に加え、該当ページ内で使用されるAPIについてもサーバーレスで提供しています）
  
• フロントで利用するデータは RDB から DynamoDB に同期して Lambda から参照する（※RDS Proxy を採用しなかったのは、Lambda の同時実行数が増加すると RDS への接続数も比例して増え、結果としてデータベースに過大な負荷がかかる可能性があったためです。これに対して、DynamoDB は高いスケーラビリティと柔軟なプロビジョニングが可能であることから、今回の構成に適していると判断しました）

このように、システム全体を完全サーバーレスにするのではなく、適材適所でサーバーレスを取り入れることも、効果的な運用方法だと感じました。

導入事例

例えば、過去に投稿済の以下の社内システムはピュアサーバーレスで構築・運用されています。

Chatwork のチャットに対してメールで送信した内容を投稿する仕組みを作成する

まとめ

本記事では、AWS を活用したピュアサーバーレス構成を用いたウェブシステムの構築・運用事例をご紹介しました。

今回取り上げた構成は、ランニングコストの削減やスパイク耐性のある安定運用、インフラ管理負荷の軽減といった大きなメリットがあります。 一方、コストを抑えるために RDS を用いていないため、RDB 的な柔軟な検索処理が難しく、状態管理や開発面での工夫が求められるなどの制約も抱えています。これらを前提としたアプリケーションの設計・開発が必要となるため、規模が大きくなると、開発者にかなりの負荷がかかることになります。

そのため、ピュアサーバーレス構成に固執することなく、システムの特性や目的に応じてハイブリッド構成を取り入れることで、より現実的かつ効果的な運用が可能となるケースも多いのではないかと考えています。

本記事でご紹介した構成や実装上の工夫が、今後のシステム設計において「サーバーレスをどう取り入れるか？」を検討する一助となれば幸いです。