サーバーレスで SaaS を構築する方法をグラレコで解説

次に、API Gateway から先はどうなるのか見てみましょう。

無事 API Gateway を通過したリクエストは、ソフトウェアを実行するマイクロサービスへと転送されます。最初のオンボーディングの段階で「各テナントの契約プランに応じたテナント設定を行う」と書きましたが、テナントによっては「他社から分離された環境でソフトウェアを実行する必要がある」といった要件がある場合があります。その場合には、他のテナントからマイクロサービスを分離して実行する「サイロ型」モデルを用います。サイロ型モデルの場合、Lambda 関数の実行には、オンボーディングの際にテナントごとに設定した「IAM 実行ロール」を使います。

一方、要件によっては、複数のテナントが同じマイクロサービス を共有する「プール型」モデルでもかまわない場合もあります。その場合は全テナント共通の単一の IAM 実行ロールで Lambda 関数を実行することになります。プール型モデルの場合、テナントごとにアクセスできるリソースを定めるために、Lambda 関数は「分離トークンマネージャー (Isolation token manager)」を使って各テナントに対するトークンの払い出しを受け、各テナントがアクセスできるリソース (S3 バケット等) の範囲を制御します。

分離トークンマネージャーは、テナントごとにオンボーディングの際に設定された IAM 実行ロールを基にトークンを生成しますが、代わりに「トークンベンディングマシン(Token vending machine)」を使ってトークンを動的に生成することもできます。テナント数が多くオンボーディングの際にテナントごとに IAM 実行ロールの設定が難しい場合、トークンベンディングマシンが役立ちます。

また、プール型の場合は、テナントごとに

• 分離トークンマネージャーからトークンの払い出しを受ける (前処理部分)
• トークンを基に Lambda 関数を実行 (本体部分)
• 遅延データなどのメトリクスを記録 (後処理部分)

といった一連の処理を行う必要がありますが、これらの処理をラッピングして、単一のラッパー関数とすることで、前処理部分・後処理部分を Lambda 関数本体のコードから分離させることができ、開発効率が向上します。