サーバレス導入には複数の異なるアプローチがある。「Flask」「Rails」「Express」といった従来のフレームワークから移行する開発者のほとんどは、サーバレスフレームワークを選ぶかもしれない。サーバレスフレームワークには「Python」用の「Chalice」や「Node.js」用の「Serverless」などがある。これらのフレームワークは従来のものと似ている。そのため、こうした開発者にとっては移行しやすい。

　残念ながら、単一フレームワークによるアプローチは規模と複雑さに限りがある。そのため、従来型のモノリシックアプリケーションを構築する開発者がそのアプリをサーバレスに移行しようとすると、即座に問題に突き当たることになるだろう。例えば、1つの「AWS Lambda」関数に対する上限はわずか50MB程度だ。このサイズは大きく感じられるかもしれない。だが、これには導入時に組み込まなければならないサードパーティーの依存関係も全て含まれる。

　「AWS CloudFormation」を使用すると、APIの複雑さに限界があることも分かるだろう。従ってエンドポイントや操作が多くなり過ぎた場合は、APIの分割が必要になる。さらに、モノリシックサービスと同じ問題点が全て当てはまる。そのためアップグレードと管理が難しくなり、環境の単一障害点になる。ただし機能が1つなら、コールドスタートには比較的簡単に対処できる。

　マイクロサービスはサーバレス導入とは異なるアプローチだ。この場合もフレームワークは使用できる。だがAPIを複数のマイクロサービスに分割することになる。このアプローチでは、AWS Lambdaの呼び出しにより通信を行うプライベートパッケージを介してサービス間でコードを共有できる。企業がメールマーケティングシステムを運営しているシナリオについて考えてみよう。このシステムは複数の異なるマイクロサービスから構成されている。そのアプリケーションは「Amazon CloudFront」からホストされる。このアプリケーションでは、1つのサービスを使用してユーザーがテンプレートを構築できる。また、別のサービスを使ってユーザーが受信者を選択し、実際にメールを送信する3つ目のサービスも選択できるようにする。これらの各サービスも別々のマイクロサービスに分割されている。メールサービスではまず1つの機能で受信者リストを構築する。次に、メールテンプレートと受信者リストを一緒に別の機能に渡す。その機能は渡された受信者リストを分割したら、メール送信を行う3つ目の機能に各受信者とメールを渡す。

　サーバレス機能同士は連携することが多い。これはよくあるパターンで、5分の実行時間制限と50MBのサイズ制限を緩和できる可能性がある。このメールマーケティングシステムの例では、受信者リストの構築を担当する最初の機能では、「Amazon DynamoDB」にアクセスできる必要がある。それにより受信者を取得する。だがメールテンプレートを処理したり実際にメールメッセージを送信したりするためのコードが実装されている必要はない。

　実際にメールを送信する最後の機能ではAmazon DynamoDBへのアクセスは不要だ。それでも、入力データからテンプレートを構築する方法は把握していなければならない。だが、最も重要なのは、これらのいずれの機能もAWSの「Amazon API Gateway」を介して公開する必要がないことだ。代わりに、個別のサービスを通じて処理される。これらのサービスは単純にユーザーの要求を受け取り、認証してから、AWS Lambda呼び出し経由でメールスタックに直接渡すことになる。

　前述したメールのような相互接続型の複雑なサービスの場合、開発者はLambda関数を手動で接続する代わりに「AWS Step Functions」を使用できる。これによりエラー調整用の追加サポートが組み込まれ、さらに多くの再試行ロジックが追加される。また、状態と、機能間でのデータ転送を自動的に処理できるようにもなる。各機能が完全に分離されているのは変わらないが、全ての状態と遷移がAWSによって処理される。

サーバレスアーキテクチャをデバッグするツール

　従来なら、開発者は単純にシステムにログインしてアプリケーションを実行し、ログを追跡して、入力をテストすることでデバッグできた。サーバレスアーキテクチャではログインするサーバが存在しない。そのためローカルでの実行は大幅に複雑になり得る。「Serverless Offline」や「SAM Local」など、一部のAWSプラグインでは、大半のアプリケーションをオフラインで実行するためのサポートが用意されている。だが別のリポジトリで認証手順が行われる場合、これらはあまり適切に機能しない。複数の機能を連携させる必要がある場合も同様だ。開発者は開発とテスト用の独自のスタックを実行してから、開発用AWSアカウントに変更をプッシュしなければならないことが多い。

　開発者と運用チームによるアプリケーションの問題特定を支援できるツールは複数ある。これらはパフォーマンスの問題を見つけ出すのにも役立つ。「AWS X-Ray」は、AWSのその他の呼び出しに関する問題を自動的に追跡できる。ほとんどのアプリケーションではわずか数行のコードでAWS X-Rayが有効になる。その後、ネットワーク図を表示して問題を指摘できる。例えばAmazon DynamoDBテーブルでプロビジョニングされるスループットや、AWS Lambdaの並列処理制限などに伴う問題などだ。AWS Lambdaアプリケーション内での標準エラーと出力の両方をもとにしたコンソールログは、「Amazon CloudWatch Logs」に転送される。これは同社の「Amazon Elasticsearch」インスタンスに取り込むか、APIまたはAWSマネジメントコンソールから直接操作できる。

　サーバレス追跡を支援するサードパーティー製ツールやサービスもある。IOpipeの「IOpipe」やNew Relicの「New Relic」などである。またAmazon API Gatewayのような他のAWSサービスからログを取得する場合もある。こうしたログには問題をデバッグする際に大いに役立つ情報が含まれている。サービスを積極的に監視する作業はより複雑になる。Pingdomの「Pingdom」などの従来の監視ツールでは機能をテストする方法が提供されない。これらのツールではAPIエンドポイントのみがテストされる。そのため、従来のインフラ監視システムを使う場合、テストの実行と、API経由でのこれらの機能を公開するツールを開発者が構築しなければならない。

サーバレスのトレードオフ

　全体的に見て、サーバレスによって開発チームは製品や企業の生産活動にもっと専念できるようになる。だがテストや監視に対応するため多くの計画が必要になる。サーバレスの使用を予定している企業では最初にプロジェクトマップを作成すべきだ。それがあれば、API要求の処理にマイクロサービスアーキテクチャを使用するか、単一機能のルーターを利用するかを判断する際に役立つ。正しく実行すれば、サーバレスアーキテクチャによって新機能の導入時に開発チームの時間を節約できる。また、ほぼ無制限に拡張することが可能だ。だが、事前計画を省略して警戒を怠ったなら、さらなる問題を引き起こす恐れがある。