💨

SaaSプロダクトのインフラアーキテクチャ

に公開
AWS
Security
スタートアップ
SaaS 設計
サーバレスアーキテクチャ
tech

※本記事は2024年6月に私が作成した記事を書き直して再投稿になりますので、若干知識が古かったりしますがご了承ください。

SaaSプロダクトのインフラアーキテクチャについて、全体像を簡単にご紹介します。

  • インフラは AWS 上に構築
  • ソフトウェア（アプリケーション）レイヤの話はスコープ外
  • 先に言ってしまうと サーバーレスアーキテクチャを採用

という前提で進めます。

アーキテクチャ検討の前提

まず今回のアーキテクチャは

  • セキュアであること
  • 安定稼働すること

を目的にした設計になっています。

加えて、

  • 立ち上がったばかりのスタートアップ
  • メンバー数は少なめ
  • インフラ専任は不在

という状況かつ、

  • インフラ監視
  • スケール対応
  • 運用作業

といった運用コストは極力小さくしたいと考えていました。

また、

エンジニアリングの力で経営を支える

というのが私のポリシーでもあるため、
SaaSプロダクトのランニングコストは可能な限り低く抑えることを目標にしています。

アーキテクチャ設計の目標

以上を踏まえ、アーキテクチャ設計では次の5点を満たすことを目標にしました。

  • 高セキュリティ
  • 高スケーラビリティ
  • 高可用性
  • メンテナンスフリー
  • 低インフラコスト

以下、それぞれをAWS上でどう実現するかをブレイクダウンしていきます。

高セキュリティ

サーバー管理をなくす

ミドルウェアの脆弱性対応を限りなくゼロにしたかったため、
サーバーを持たない構成を前提にしました。

  • フロントエンド
    • 静的コンテンツとして実装
    • S3に配置
  • バックエンド
    • API Gateway + Lambda構成

AWSセキュリティサービスの活用

  • CloudFront / WAF によるDDoS対策
  • Cognito / Lambda Authorizer による認証・認可

データ保護

  • データベースはプライベートサブネットに配置
  • データはすべて暗号化

高スケーラビリティ

AWSが持つ膨大なリソースを活かし、高い拡張性を確保します。

  • フロント
    • S3のスケーラビリティを活用
  • バックエンド
    • API Gateway + Lambda による自動スケール
  • データベース
    • AWSマネージドDBを採用

高可用性

AWSの高可用性を前提としたサービス構成を選択しています。

  • フロント
    • S3（99.99%の可用性）
  • バックエンド
    • Multi AZで動作するLambda
  • データベース
    • 単一AZ構成は避け、可用性の高い構成を採用

メンテナンスフリー

インフラメンテナンスからの解放も重要なポイントです。

  • EC2は利用しない
  • サーバーレス構成（S3 / Lambda）
  • ミドルウェア管理はAWSに委譲
  • DBもAWSマネージドサービスを利用

低インフラコスト

  • フロントは安価なS3を利用
  • 初期の低トラフィックを考慮し、従量課金モデルを採用
  • バックエンドはミリ秒課金のLambdaを利用

アーキテクチャ設計まとめ

検討の結果、ベースとなる構成は以下の通りです。

  • フロントエンド：S3
  • バックエンド：API Gateway + Lambda
  • データベース：Aurora（RDBが必要なため）
  • CDN / セキュリティ
    • CloudFront
    • WAF
  • 認証
    • Cognito（ユーザープール）
    • Lambda Authorizer
  • マルチAZ構成

アーキテクチャ実践

フロントエンド

  • S3に静的サイトを配置
  • バックエンドAPIからデータを取得して表示
  • いわゆる SSG（Static Site Generator）構成
  • CloudFront / Route53 / ACM で一般的なWebサイト構成を実現

バックエンド

  • API Gateway + Lambda + Aurora
  • CloudFront / Route53 / ACM
  • WAFでSQLインジェクションなどの攻撃を防御
  • Lambda Authorizerによる認証強化

【バックエンドアーキテクチャ概要】

やってみてどうだったか

高セキュリティ

  • セキュリティ事故は発生していません
  • 大手金融系企業様によるクラウドセキュリティチェックもすべて通過

高スケーラビリティ

  • 現時点ではリソース増強は不要
  • CloudWatchで監視中（評価は今後）

高可用性

  • 運用開始以降、システムエラーによるサービス停止なし

メンテナンスフリー

  • メンテナンスはAuroraのエンジンアップデートのみ

※ Lambdaの言語バージョンアップはありますが、
　インフラではないので今回はスコープ外ということで…

低インフラコスト

  • 具体的な金額は出せませんが、かなり安く運用できています

課題

当然、良いことばかりではありません。

エンジニアに一定以上のスキルが求められる

正直、当時はこれが一番大きな課題でした。

  • サーバーレスに馴染めず、立ち上がらないまま去っていく業務委託エンジニアも複数いました
  • 採用時にもアーキテクチャ理解力は重要なポイント

結果的には、強いエンジニアチームができたとも言えます。

制約が多い

サーバーレスアーキテクチャは制約が多いです。

  • VPC接続時のコールドスタート問題
  • デプロイの複雑さ
  • ローカル環境構築の手間

なお、当時は AWS SAM + CDK で実現しました。
（Terraform使ってないの、ダサいですかね？）

フレームワークが使いにくい

ソフトウェアはスコープ外と言っておきながら、最後にどうしても触れざるを得ません。

Rails、Django、Spring といった
フルスタックフレームワークを素直に使うのは難しいです。

まとめ

サーバーレスアーキテクチャは、正直言って簡単ではありません。

サーバーを立ててフレームワークでサクッと作る方が、
楽なのは間違いないと思います。

それでも、

  • AWSリソースをパズルのように組み上げ
  • 大きな目標を達成できたこと
  • 運用・コスト面でしっかり成果が出たこと

を振り返ると、やってよかったと胸を張って言えます。

最後まで読んでいただきありがとうございました。

Discussion