Serverless化の機会を特定する

1. Serverless化はアプリケーション全体を一度に置き換えることではない

既存アプリケーションをモダナイゼーションするとき、このシステムをServerlessにするかしないか、という二者択一で考える必要はありません。

1つのアプリケーションの中にも、HTTPリクエスト処理、ファイル到着後の処理、定期的なデータ変換、長時間バッチ、常駐プロセス、ローカル状態へ依存する処理など、異なる性質の構成要素があります。

ワークロード全体
↓
構成要素へ分解
↓
既習のServerless実行モデルへ
変更可能な部分を抽出

Serverless Opportunityでは、このように構成要素単位で候補を特定します。重要なのは、すべてをAWS Lambdaへ移すことではありません。

2. Serverless Opportunityは現在の運用負荷と実行特性から探す

Serverless化候補を探すときは、現在のサーバー台数だけを見ません。

例えば、実際の処理時間は短い、イベントがない時間はほぼアイドル、需要変動への事前容量調整が必要、サーバーOSの保守は常時必要、という構成要素があるとします。

この場合、実際に価値を生む処理に対して、アイドル時の基盤維持、ピーク前の容量調整、OSやホストの定常保守といったOperational Overheadが大きくなっている可能性があります。

現在のOperational Overhead
↓
Serverless化で削減できる部分
↓
候補としての価値

まで含めて評価します。

3. Event-drivenは既存構成要素を切り出す境界として使う

Event-drivenな処理にAWS Lambdaが適すること自体は前提知識とします。

ここで新しく確認するのは、既存アプリケーションのどこまでを独立したイベント処理として切り出せるかです。

例えば既存の常駐プロセスが、

ファイル到着を監視
↓
ファイルを検証
↓
結果を保存
↓
再び待機

しているとします。

この場合、常時監視しているプロセス全体をそのまま移すのではなく、

ファイル到着
↓
検証処理
↓
結果保存

という独立した処理単位をServerless Opportunityとして切り出せるか確認します。

どのイベントルーティングサービスを使うか、どのようにファンアウトするかまではここでは扱いません。この段階の責任は、既存処理からイベント単位の実行境界を見つけることです。

4. Lambda適合条件を再講義せず、変更が必要な依存関係を確認する

既存構成要素をServerless Opportunityとして抽出したら、その処理をLambdaで実行できるかだけではなく、現在のどの依存関係を変更する必要があるかを確認します。

例えば、特定ホスト上のローカルファイル、ホスト固有の設定、常駐プロセスとの直接通信、ローカルメモリ上の継続状態へ依存している場合があります。

依存関係を外部サービスへ分離できるのであればServerless化へ近づきます。一方、ホスト固有の制御をそのまま維持しなければならないのであれば、最初のServerless Opportunityとしての優先度は下がります。

つまり、既存構成要素について、Serverless実行モデルへ変えるために何を分離・変更する必要があるかを明確にします。

5. Statelessは実行環境へ業務状態を依存させないこと

AWS Lambdaでは、実行環境が再利用される場合があります。その再利用を利用して、SDKクライアント、データベース接続、変更されない静的データなどを効率化できる場合があります。

しかし、前回のLambda呼び出しでローカルメモリへ保存した業務状態が次回も必ず存在するとは考えません。

Serverless Opportunityとして重要なのは、実行環境が再利用されなくても正しく処理できることです。

永続させる必要がある状態は、データベース、オブジェクトストレージ、キュー、その他の耐久性のある保存先へ分離します。

つまりStatelessとは、データを一切持たないことではなく、業務上必要な永続状態を特定のLambda実行環境へ依存させないことです。

6. Automatic Scalingで容量管理そのものを減らせるかを見る

需要変動に応じて実行環境を増減できることは、AWS Lambdaの既習特性として扱います。

Serverless Opportunityでは、その特性によって現在の容量管理作業を減らせるかを確認します。

例えば既存環境で、

キャンペーン3日前
↓
担当者がピークを予測
↓
サーバー台数を増加
↓
キャンペーン終了後
台数を削減

という作業を毎回実施しているとします。

対象処理がServerless実行モデルへ変更可能なら、手動のピーク予測、事前増設、事後縮小というOperational OverheadをAutomatic Scalingによって減らせる可能性があります。

したがって評価するのは、需要変動があるからLambdaを選ぶという単純なサービス選択ではありません。

既存の容量管理作業
↓
Serverless化
↓
Automatic Scalingによって
どの作業を不要にできるか

を確認します。

ただし、Automatic Scalingは無制限ではありません。同時実行クォータや接続先サービスの処理能力などは引き続き考慮します。

7. Pay-per-useはアイドル時間を持つ構成要素で評価する

標準のAWS Lambda関数は、主にリクエスト数とコードの実行時間に基づいて課金されます。

例えば、1日24時間サーバーは起動しているが実処理は合計15分、という既存処理なら、常時起動している時間ではなく実際の利用量に近い料金モデルへ変更できる可能性があります。

Amazon API GatewayもAPI利用量、AWS AppSyncもGraphQL操作やリアルタイム利用量などに応じた料金体系を持ちます。

ただし、Pay-per-useだから必ず最安とは限りません。呼び出し回数、実行時間、データ転送、必要な追加機能を含めて比較します。

また、現在のAWS Lambdaには、標準のLambda関数とは異なる料金・キャパシティモデルを持つLambda Managed Instancesもあります。したがって、Lambdaはすべて同じPay-per-useモデルとは一般化しません。

8. Amazon API GatewayはAPI入口のServerless Opportunityになる

既存システムでは、APIを公開するためのサーバー、ルーティング用プロキシ、認証処理、流量制御、API監視などを自前で運用している場合があります。

バックエンド処理自体が独立しているなら、

利用者
↓
Amazon API Gateway
↓
AWS Lambda
または
HTTPバックエンド
または
対応AWSサービス

という構成を評価できます。

Amazon API GatewayはREST API、HTTP API、WebSocket APIを提供できます。

Serverless Opportunityとして見ると、API入口のためだけに維持しているサーバー群を削減できる可能性があります。Amazon API Gatewayとバックエンド処理は別の役割です。

9. AWS AppSyncはGraphQL基盤のServerless Opportunityになる

既存アプリケーションが、GraphQL API、複数データソースの集約、クライアントへのリアルタイム更新を自前のサーバーで提供している場合があります。

AWS AppSync GraphQLでは、Amazon DynamoDB、AWS Lambda、Amazon OpenSearch Service、HTTPエンドポイント、対応するリレーショナルデータソースなどへ接続できます。

GraphQLサブスクリプションを使用したリアルタイム更新も提供できます。

そのため、GraphQLサーバーの運用、接続管理、API基盤のスケーリングがOperational Overheadになっている場合は、AWS AppSyncをServerless Opportunityとして評価できます。

ただし、APIであれば必ずAWS AppSyncではありません。既存クライアントが必要とするREST / HTTP API、GraphQL、双方向通信、リアルタイム更新の方式から入口サービスを評価します。

10. Serverless Opportunityでは削減対象の運用を明確にする

Serverless化後にも利用者側の責任が残ること自体は既習事項とします。

ここでは共有責任を再整理するのではなく、Serverless Opportunityを評価するときに、現在のOperational Overheadのうち何をServerless化によって削減したいのかを明確にします。

例えば、サーバーの常時起動、ピーク前後の容量変更、OSやホストの保守、API基盤のサーバー管理、GraphQL基盤のスケーリング管理が現在の負荷なら、そのうちどこまでをServerless化によって減らせるかを候補評価へ含めます。

Serverless Opportunity
≠
すべての運用をなくすこと

Serverless Opportunity
=
既存構成の中から
削減効果が大きい運用領域を見つけること

11. Serverless化しやすい部分としにくい部分を同じアプリケーション内で分ける

例えば既存システムに、イベント単位へ切り出せる検証処理、REST APIの入口、GraphQL APIとリアルタイム通知、特殊ハードウェアへ強く依存する処理、ローカル状態へ強く依存する常駐プロセスがあるとします。

最初からすべてを同じ方式へ変更する必要はありません。

イベント単位へ切り出せる処理
→ AWS Lambda

REST APIの入口
→ Amazon API Gateway

GraphQL APIとリアルタイム通知
→ AWS AppSync

のように、Serverless Opportunityを構成要素単位で評価できます。

特殊ハードウェアやローカル状態へ強く依存する処理は、そのまま同じ実行モデルへ移す前に依存関係を解決する必要があります。ここでは、それらの最適な移行先までは決めません。

12. Serverless Opportunityの判断表

13. 判断フロー

既存アプリケーション
        │
        ▼
構成要素へ分解
        │
        ▼
イベント / API単位へ
実行境界を切り出せるか
        │
        ▼
現在の依存関係を確認
        │
        ▼
Statelessにできるか
        │
        ▼
現在の容量管理作業を確認
        │
        ▼
Automatic Scalingで
削減できる作業を確認
        │
        ▼
アイドル時間と利用量を確認
        │
        ▼
Pay-per-useとの適合を評価
        │
        ▼
Operational Overheadを確認
        │
        ├─ コンピューティング
        │     → AWS Lambda候補
        │
        ├─ API入口
        │     → Amazon API Gateway候補
        │
        └─ GraphQL API
              → AWS AppSync候補
        │
        ▼
Serverless化で削減する
運用領域を明確化
        │
        ▼
Serverless Opportunityを特定

中心は、AWS Lambdaを使いたいから処理を探すことではありません。

既存構成要素
+
現在の依存関係
+
状態
+
容量管理
+
利用量
+
Operational Overhead
↓
Serverless化で
改善できる部分を特定

という順序で判断します。