サーバレス(APIGateway,Lambda)についてまとめてみた #AWS

サーバレスとは

サーバについて考える必要なくアプリケーション開発が行える。
仮想サーバ構成の場合以下について考える必要性がある。

サーバーの維持コスト
アカウントのアクセス制御範囲
デプロイ方法について
etc..

サーバレスアーキテクチャが生まれた背景

オンプレミス（物理サーバ）
→データセンターの仮想サーバ
→クラウド環境の仮想サーバ
→サーバレス

インフラ構成はオンプレミスの物理データサーバを利用していた時代からサーバレスまで変化しました。
この背景はアプリケーションのアーキテクチャ設計が関係していると思われます。

アプリケーション開発のアーキテクチャ設計は
モノリシックアーキテクチャ
→サービス思考アーキテクチャ（SOA)
→マイクロサービスアーキテクチャ
のようにサービス、ロジック、インフラが密結合に設計されたアーキテクチャ構成から疎結合化したアーキテクチャに変更されてきました。
今回紹介するサーバレスはマイクロサービスを構築する上で利用しやすいサービスになります。

サービス責任モデル

	オンプレミス	クラウド	Faas	マネージドサービス
アプリケーション	ユーザー	ユーザー	ユーザー	クラウドベンダー
ランタイム	ユーザー	ユーザー	クラウドベンダー	クラウドベンダー
ミドルウェア	ユーザー	ユーザー	クラウドベンダー	クラウドベンダー
OS	ユーザー	ユーザー	クラウドベンダー	クラウドベンダー
仮想基盤	ユーザー	クラウドベンダー	クラウドベンダー	クラウドベンダー
ハードウェア	ユーザー	クラウドベンダー	クラウドベンダー	クラウドベンダー

上記のようにサービス責任が問われます。
今回紹介しているサーバレスはこの表のFaas、マネージドサービスにあたります。

メリット

サービス開発の時間の短縮により、サービスロジックの構成に集中できる
運用保守の省力化
従量課金であるためインフラ維持コストがかからない

上記のメリットから以下のユースケースが想定される。

既存機能の一部置き換え
新規実装の概念実証
マイクロサービスとして定義したシステムの構築
キャンペーンサートなどの一時的機能
管理サイトなどの特定の利用を行う機能

デメリット

モノリシックなアプリケーション開発には有効でない
トランザクションが頻繁に利用されるシステムに向いていない
低レイテンシ（遅延）が求められるサービスに向いていない

従来のAWS構成との比較

従来のEC2によるインフラ構成
APIGateway,lambdaを利用したサーバレスなインフラ構成

デザインパターン例

モバイルバックエンド AWS AppSyncを利用してリアルタイム処理。オフライン用件のモバイルシステム。
画像処理・データ加工 S3,SQSと連携してイベント発生時にlambdaによる加工処理が実行される。
Amazon Alexaスキルの作成音声認識時にlambda実行が行われる。

APIGatewayとlambdaを利用して簡単なAPIを作成してみる

今回はAPIGatewayのリクエストをトリガーにlambda関数を実行するAPIを作成してみます。

lambda関数の作成 AWSコンソールからlambdaを選択し、lambda関数の作成ボタンを押下します。

「一から作成」を選択して
任意の関数名、記述言語を選択します。

今回のLambda関数の他のAWSサービスへのアクセス許可を設定します。

ロール名は任意のロール名を入力して、
ポリシーテンプレートは
「基本的な Lambda@Edge のアクセス権限(CloudFront トリガーの場合)」を選択します。
このテンプレートには、CloudWatchへのアクセス権限が含まれているので、今回作成したロールが付与されたサービスは、CloudWatchにログを出力できるようになります。

上記のように入力したら、「関数の作成」ボタンをクリックします。

関数はサンプルをそのまま使います。
API Gatewayで作成したAPIがリクエストを受けると、Lambda関数が呼ばれて、そのリクエスト情報一式が1行目のeventに渡されます。
eventは今回は使わずに、APIには「"Hello from Lambda!"という文字列をレスポンスとして返すように」という指示を、処理結果として返します。

APIGatewayの作成

次にAPIGatewayの作成をしていきます。
RESTAPIの「構成」ボタンを押下します。

新しいAPIを選択して、任意のAPI名を選択し、「APIの作成」ボタンを押下します。

APIの作成ができたら、まずはエンドポイントを作成します。
アクションボタンを押下して「リソースの作成」を選択します。

任意のリソース名を記入して、「APIGateway CORSを有効にする」にチェックを入れます。
チェックを入れると、testリソースの作成と共に、optionメソッドのエンドポイントが作成されます。
これによりブラウザからAPIを呼び出すことができます。

testリソースに、GETメソッドのエンドポイントを作成します。

「GET」を選択してチェックをクリックします。

GETメソッドのエンドポイントがリクエスト受けた時、どのように処理するか設定します。
統合タイプとして「Lambda関数」を選択して、「Lambda プロキシ統合の使用」にチェックをいれ、Lambda関数に先ほど作成したLambda関数を指定します。

「Lambda プロキシ統合の使用」にチェックを入れると、このエンドポイントに対するリクエスト情報一式を、Lambdaのevent変数（後述）に渡します。
保存ボタンを押すと、以下のようにAPIGatewayからlambda関数にアクセスする権限を与えるか確認がありますのでOKを押下します。

lambdaに戻って「デザイナー」を選択して構成を確認します。

最後にAPIGatewayのデプロイをします。

デプロイされるステージに「新しいステージ」を選択して、ステージ名を「production」としてデプロイボタンを押下します。

GETメソッドのエンドポイントを選択すると、エンドポイントのURLが表示されます。
URLにアクセスして想定通りの挙動をしているか確認してみます。

以下のように「Hello from Lambda!」と表示されれば完成です。

サーバーレスの背景、メリットデメリット、簡易的なAPIの作成と簡単にサーバレスに触れてみました。
今回紹介できなかったこと意外にもたくさんのできるととがあります。
参考記事にはこの記事以上の情報量、質があります。
この記事をみてもしもさらに調べてみたいと思った方がいましたら、是非とも一読してみてください！

参考

実践プロダクションサーバーレス - AWS CDK と TypeScript によるWebアプリケーション開発パターン
 【初級】いまから始めるサーバレスアプリケーション | AWS Summit Tokyo 2019
サーバーレスシステムのチーム開発
 API Gateway + LambdaでREST API開発を体験しよう [10分で完成編]
サーバレスとは