サーバーレスアーキテクチャとサービス化

サーバーレスとは何か

サーバーレス（Serverless）は、サーバーを全く意識せずに利用できるPaaS型（Platform as a Service）のクラウド機能です。従来のインフラストラクチャ管理から解放され、ビジネスロジックに集中できる設計パラダイムとなります。

サーバーレスの本質

サーバーレスの根本的な特徴は、インフラストラクチャ管理をAWS側に委譲することにあります。ユーザーは以下のようなインフラ関連の決定を一切不要とします：

• インスタンスタイプの選択
• インスタンスの起動・停止管理
• オペレーティングシステムの保守
• 容量計画
• パッチ適用

これにより、開発者やアーキテクトはビジネス機能の実装に専念できます。

主要なAWSサーバーレスサービス

AWS は以下の主要なサーバーレスサービスを提供しており、これらを組み合わせて完全なサーバーレスアーキテクチャを構築できます：

• Lambda: コンピュートサービス。イベント駆動型の関数実行
• SNS: メッセージ配信サービス。Pub/Sub型の通知機能
• SQS: キューイングサービス。ポーリング型のメッセージ処理
• DynamoDB: NoSQL データベース。スケーラブルなサーバーレスDB
• Step Functions: ステートマシン。複雑なワークフロー管理
• SES: Eメール送信サービス。大規模メール配信
• Aurora Serverless: リレーショナルDB のサーバーレス版
• API Gateway: REST API / HTTP API 管理
• Cognito: ユーザー認証・認可管理
• Fargate: コンテナのサーバーレス実行
• Kinesis: ストリームデータ処理サービス

アンマネージド型・マネージド型・サーバーレス型の比較

クラウドサービスの管理範囲は3つのレベルに分類されます。各レベルでユーザーとAWSの責任範囲が異なります。

アンマネージド型

特徴：

• ユーザーがインスタンスタイプを選択して仮想サーバーを設定
• インスタンスの起動・停止、ネットワーク設定、セキュリティグループなどユーザーが管理
• ソフトウェアのインストール、更新、運用などユーザーが実施
• インフラストラクチャ管理の責任がユーザー側

典型例：

• Amazon EC2
• オンプレミスサーバー

用途：

• 細かい制御が必要なアプリケーション
• 既存のオンプレミスシステムをそのまま移行したい場合
• カスタマイズが多く必要な環境

コスト・スケーラビリティ：

• 事前にインスタンスサイズを決定する必要があり、柔軟なスケーリングが難しい
• ほぼ常時コストが発生

マネージド型

特徴：

• ユーザーがインスタンスタイプや基本設定を選択
• AWS がインフラの可用性、スケーラビリティ、バックアップなどを管理
• ユーザーはソフトウェアの設定・運用を実施
• インフラ部分の責任をAWSが負う

典型例：

• Amazon RDS（リレーショナルデータベース）
• Amazon Elasticache（インメモリキャッシュ）
• Amazon ElastiSearch（検索エンジン）

用途：

• データベースなど、運用負荷を軽減したい場合
• 標準的なオプションで十分な環境
• ある程度のカスタマイズが必要な場合

コスト・スケーラビリティ：

• インスタンスサイズは固定だが、AWS が可用性を確保
• 変更時は手動でのスケーリングが必要

サーバーレス型

特徴：

• ユーザーがインスタンスタイプを選択しない
• インスタンスの起動・停止、スケーリング、パッチすべてAWSが管理
• ユーザーはビジネスロジックのみを記述
• インフラストラクチャ管理の全責任がAWS側

典型例：

• AWS Lambda
• Amazon DynamoDB
• Amazon Aurora Serverless
• API Gateway

用途：

• インフラストラクチャ運用を最小化したい場合
• 自動スケーリングが必須の環境
• 開発スピードを優先したい場合

コスト・スケーラビリティ：

• 実際の使用分のみコスト発生
• 自動的にスケーリングされ、使用量に応じて課金

3つのモデルの比較表

項目	アンマネージド型	マネージド型	サーバーレス型
インスタンスタイプ選択	ユーザー	ユーザー	AWS（選択不要）
インスタンス管理	ユーザー	AWS	AWS
ソフトウェア運用	ユーザー	ユーザー	AWS
インフラ管理	ユーザー	一部AWS	AWS
スケーリング	手動	手動	自動
コスト形態	固定	固定	従量課金
初期設定負荷	高	中	低
運用負荷	高	中	低

データベースの3つのモデル

同じ分類がデータベースにも適用されます：

アンマネージド型データベース

• ユーザーが EC2 インスタンスに MySQL、PostgreSQL などをインストール
• バックアップ、レプリケーション、スケーリングすべてユーザーが管理
• 完全な制御が可能だがメンテナンス負荷が大きい

マネージド型データベース

• Amazon RDS（MySQL、PostgreSQL、Oracle、SQL Server など）
• AWS がバックアップ、マルチAZ、読み取りレプリカなどを管理
• ユーザーはインスタンスタイプを選択し、パラメーター調整を実施

サーバーレス型データベース

• Amazon DynamoDB
• Amazon Aurora Serverless
• インスタンスタイプの選択不要、自動スケーリング
• ビジネスロジックに専念可能

コンピューティングの3つのモデル

アンマネージド型コンピューティング

• Amazon EC2
• ユーザーがインスタンスタイプを選択し、OS から全管理
• 最大の制御と最大の運用負荷

サーバーレスコンピューティング

• AWS Lambda
• 関数のコードを送信するだけで実行
• スケーリングは自動、コストは使用量のみ

サーバーレス化の意義

サーバーレス化とは

サーバーレス化は、従来のサーバー（EC2インスタンス）ではなく、Lambda などのコンピュートサービスによるシステム構成を出来る限り利用するアプローチです。

従来型アーキテクチャの課題

EC2 インスタンスを活用した従来型設計には以下の課題があります：

1. 高コスト：

   • 24時間365日インスタンスが稼働
   • 実際の使用が少なくてもコスト発生
   • スケーリング判断が遅れると過剰にコスト増加

2. 密結合なアーキテクチャ：

   • インスタンス上で複数機能が共存
   • 機能の独立したスケーリングが困難
   • 障害が連鎖する可能性

サーバーレス化による改善

課題	従来型（EC2）	サーバーレス
コスト	常時発生	実行時のみ計課金
スケーリング	手動で対応	自動で自動スケーリング
結合度	密結合	疎結合化可能
運用負荷	高い	最小化可能

疎結合化とマイクロサービス化

サーバーレス化から疎結合化へ

サーバーレス設計によって、自然と疎結合なアーキテクチャが実現されます。その理由は：

1. 機能ごとの独立実行：

   • Lambda 関数が個別の機能を担当
   • 各関数が独立してスケーリング

2. イベント駆動型設計：

   • SNS、SQS、EventBridge などでサービス間を疎結合に
   • 直接呼び出しではなく、イベント経由での連携

3. マネージドサービスの活用：

   • 各機能を専門的なマネージドサービスで実装
   • サービス間の依存を最小化

疎結合化からサービス化へ

疎結合化によって実現される設計パラダイムがサービス化（Service-Oriented Architecture の進化）です。

サーバーレス化 → 疎結合化 → サービス化

この流れによって、マイクロサービスアーキテクチャが自然に形成されます。

サービス化の2つのアプローチ

サービス指向アーキテクチャ（SOA）

SOA（Service-Oriented Architecture）は、昔ながらの大規模サービス分割アプローチです。

特徴：

• 一通りの機能が揃った大きなサービス単位でコンポーネントを分割
• アプリケーションをコンポーネント化して、通信プロトコルによる連携でサービスを提供
• ESB（Enterprise Service Bus）などの複雑な統合基盤が必要な場合が多い

具体例：

複雑なエンタープライズシステムの場合、以下のような大きな単位でサービス分割：

• ユーザー管理サービス
• 決済サービス
• レポーティングサービス

課題：

• サービス単位が大きく、スケーリングが制限される
• サービス間の結合度が高くなりやすい

マイクロサービス

マイクロサービスは、SOA の思想をさらに細分化したアプローチです。

特徴：

• SOA よりも小さな機能単位のプロセスでサービス化
• 各プロセスでは1つの小さなタスクをサービスとして提供
• プロセス間通信は REST API など軽量なプロトコルを使用

利点：

1. 独立したスケーリング：

   • 負荷が高い機能だけをスケールアップ
   • リソース効率が向上

2. 技術スタックの多様性：

   • 各マイクロサービスで異なる技術を採用可能
   • 最適なツールを選択できる

3. 迅速なデプロイ：

   • サービス単位での独立したデプロイ
   • リリース速度の向上

4. 障害の隔離：

   • 1つのマイクロサービスの障害が全体に影響しない

5. チーム編成の柔軟性：

   • チーム単位でマイクロサービスを所有可能
   • 開発の並列性向上

SOA とマイクロサービスの比較

項目	SOA	マイクロサービス
サービス粒度	大きな機能単位	小さなタスク単位
スケーリング	サービス単位	個別タスク単位
プロトコル	複雑なものも対応	REST API など軽量
結合度	比較的高い	低い
複雑さ	比較的簡単	複雑な場合がある
スケーラビリティ	限定的	高い

疎結合化とマイクロサービス化の表裏一体の関係

疎結合化とマイクロサービス化は、密接に関連しており、相互に支援する関係にあります：

疎結合化（Loose Coupling）
    ↓
サービス間の依存を最小化
    ↓
マイクロサービス化（Microservices）
    ↓
各サービスが独立して動作・スケーリング可能
    ↓
システム全体の柔軟性・スケーラビリティ向上

実装例

Before（密結合）：

[Web App] → [App Server (複数機能)] → [Database]

• 1つのアプリケーションサーバーで複数の機能を処理
• 機能ごとのスケーリングが困難
• 障害が全体に影響

After（疎結合・マイクロサービス化）：

[API Gateway] → [User Service (Lambda)]
             → [Order Service (Lambda)]
             → [Payment Service (Lambda)]
             → [Notification Service (Lambda)]

各サービスが独立し、以下が実現：

• 機能ごとに独立したスケーリング
• 障害の隔離
• チーム単位での開発
• 技術スタックの多様性

AWSサーバーレスサービスの連携パターン

イベント駆動型アーキテクチャ

サーバーレス化による疎結合設計では、イベント駆動型の連携が一般的です：

1. Lambda トリガー型：

   • S3 アップロード → Lambda 関数 → DynamoDB
   • API 呼び出し → Lambda 関数

2. SNS/SQS 経由：

   • プロデューサー → SNS/SQS → コンシューマー Lambda
   • 複数の処理を非同期で実行

3. EventBridge：

   • AWS のあらゆるイベントをキャッチして処理を分岐
   • 複雑なイベントルーティングが可能

4. Step Functions：

   • 複数のマイクロサービスを統合したワークフロー管理
   • 順序制御、エラーハンドリング、リトライロジック

サーバーレス化のポイント

サーバーレス化の判断基準

サーバーレスアーキテクチャへの移行を検討する際、以下のポイントに注意が必要です：

1. インスタンスの必要性の見直し

検討項目：

• シンプルな機能や処理を実行するだけのためにインスタンスを利用していないか
• ピーク時と通常時でリソース利用に大きな差がないか
• インスタンス上で複数の独立した機能が動作していないか

例：

• サーバーレス化に適した例：

  • 定期的なバッチ処理（Lambda + EventBridge）
  • API エンドポイント（API Gateway + Lambda）
  • ファイル処理（S3 トリガー + Lambda）

• サーバーレス化に不向きな例：

  • 常時接続が必要なアプリケーション（WebSocket など）
  • 実行時間が15分を超える処理（Lambda の制限）
  • 大量の永続的なストレージが必要な処理

2. インスタンスの利用率の見直し

検討項目：

• インスタンスがアイドル状態の時間が多くないか
• トラフィック変動に対応できていないか
• スケーリング判断に遅延がないか

3. 多目的インスタンスの分割検討

検討項目：

• 1つのインスタンス上で複数の機能が動作していないか
• 機能ごとにリソース要件が異なるないか
• 機能ごとのスケーリングが必要ないか

マイクロサービス化によって、これらを解決できます。

4. インフラ運用負荷の削減

検討項目：

• OS パッチ、ソフトウェア更新に時間を費やしていないか
• スケーリング管理に手作業が入っていないか
• インスタンス構成の詳細管理に時間をかけていないか

効果：

サーバーレス化により、これらのすべてがAWSに委譲され、開発チームはビジネスロジックに専念できます。

サーバーレス化による全体効果

ビジネス的効果

1. コスト削減：

   • 使用量ベースの課金により、無駄が排除される
   • インフラ管理の人件費削減

2. タイムトゥマーケット短縮：

   • インフラ準備期間の削減
   • デプロイまでのリードタイム短縮

3. スケーラビリティ：

   • 事前の容量計画が不要
   • トラフィック急増に自動対応

技術的効果

1. 疎結合化：

   • サービス間の依存を最小化
   • 変更の影響が局所化

2. 可視性向上：

   • CloudWatch、X-Ray による監視が容易
   • マネージドサービスのメトリクスが充実

3. セキュリティ：

   • インフラの脆弱性管理をAWSに委譲
   • IAM ベースの細かいアクセス制御

AWS SAA-C03 試験での出題ポイント

サーバーレスアーキテクチャはSAA試験で頻出のテーマです。以下のポイントが重要です：

設計問題での出題パターン

1. 最適なサービス選択：

   • 要件に応じた Lambda、DynamoDB、Aurora Serverless などの選択
   • アンマネージド型との使い分け

2. アーキテクチャ評価：

   • 疎結合化による設計改善
   • マイクロサービス化のメリット・デメリット

3. コスト最適化：

   • サーバーレス化による節約効果
   • スケーリング戦略

4. トレードオフ分析：

   • サーバーレス型の制限（実行時間制限など）
   • マネージド型との使い分け

よく出題される組み合わせ

• API Gateway + Lambda + DynamoDB
• S3 + Lambda + SQS
• EventBridge + Lambda + SNS
• Step Functions + Lambda + その他のマネージドサービス

まとめ

サーバーレスアーキテクチャとサービス化は、クラウドネイティブな設計の中核概念です：

1. インフラストラクチャ管理の委譲：

   • サーバーレスにより、AWS が全インフラ管理を負う
   • 開発チームはビジネスロジックに集中

2. 段階的な管理責務：

   • アンマネージド型 → マネージド型 → サーバーレス型
   • 段階が進むほどAWSの管理が増加、運用負荷が軽減

3. 疎結合化の実現：

   • サーバーレス設計によって自然に疎結合が形成される
   • マイクロサービス化が加速

4. ビジネス・技術的効果：

   • コスト削減、スケーラビリティ向上
   • 開発速度の加速、品質向上

5. SAA試験での重要性：

   • アーキテクチャ設計の最重要テーマ
   • 実務でも最も活用されるパターン

AWS Solutions Architect を目指す上で、サーバーレスアーキテクチャとサービス化の理解は必須です。