TOP > ブログ > サーバーレスアーキテクチャで何が変わるのか②
技術レポート

サーバーレスアーキテクチャで何が変わるのか②

ブログ

※記事は週に1回、追加で公開して参ります。
今すぐ全文をご覧になりたい方は、こちらから。(簡易登録が必要です。)




3. API GatewayとLambdaの検証

今回のPoCでは、外部サービスからREST APIを用いてデータをデータベースへ書き込むという処理を、API GatewayとLambdaでRDS(MySQL)へ書き込むというシナリオで検証した。API Gatewayは、インターネットへ公開されたAPIなので、利用サーバーを限定しセキュリティを保つために、IPアドレスで利用制限するためのカスタム認証モジュールを作成し検証をした(図1)。

図1 POC検証環境イメージ
図1 PoC検証イメージ

(ア)Lambdaの構築と運用

構築手順(概要)
①IAM Roleの作成

Lambda Functionの実行に必要なAWSサービスへのアクセス権限の設定を行う。

②Lambda Functionの作成

Function名を指定し、以下の設定パラメータを記述する。
設定パラメータは、事前に作成したIAM Roleと、メモリーサイズ、最大実行時間、実行環境などを指定する。当PoCではRDS(リレーショナルデータベースサービス)を用いるためVPC(仮想的なプライベートネットワーク)上での実行環境を選択した。

③アプリケーションの作成とデプロイ

当PoCでは、RDBへのアクセスがあるため、O/Rマッパの豊富なJava言語で実装することにした。開発環境は、EclipseにAWSから提供されているLambda SDKを導入することで、通常のJavaアプリケーション開発と同等な生産性を得ることができた。プログラムのバージョン管理機能があらかじめ備わっているので、本番実行バージョンをそのままで、プログラム保守、テストが可能となっている。1つ難点としては単体テストが容易に行えないということである。Eclipse上でLambda SDKによりコードチェックなどは可能であるが、実行エンジンが提供されているわけではないので、実行テストを行うためには都度Lambdaへデプロイし実環境でテストを行う必要がある。クライアント側でのデバック用Lambdaエンジンの提供など今後の改善に期待したい。

運用・監視

監視機能としてはCloudWatchのパフォーマンス情報が提供されており、呼び出し回数、レスポンス、エラー回数などが監視可能だ。また、アプリケーションが書き出すログは、CloudWatch Logsで管理される。

インフラ監視が必要なものは唯一スロットル回数だけである。Lambdaの同時実行数はデフォルトで100となっている。同時実行数が100を超えるとスロットルが発生し、呼び出し元プログラムにはエラーが応答される(非同期呼び出しの場合は、AWS側で再処理が行われる)。呼び出し側アプリケーションは時間をおいて再度実行を要求しなければならない。頻繁にスロットルが発生する場合は、サポートに申請することで同時実行数の上限を増加することが可能だ。

アプリケーション監視は、CloudWatchのエラー回数を監視し、エラー発生時はログを分析し原因究明を行うことができる。問題分析を容易に行うためには、アプリケーションはエラー発生時に問題分析に必要な内容を出力する必要がある。

パフォーマンスに関しての設定はメモリーサイズだけである。メモリーサイズを大きくするとCPU性能も比例するようになっており、目標のレスポンスタイムに応じメモリーサイズを増減させるだけである。

(イ)API Gatewayの構築と運用

設計と構築
①外部設計(I/F設計)

API Gatewayは、Web API(REST)とバックエンド(Lambda Function)のインタフェース変換が主な機能である。

外部アプリケーション(クライアント)とAPI Gateway間のI/F(REST)設計と、Lambda Functionを呼び出すときのI/F(JSON)の設計を行う。API (アプリケーション)ごとに設計してもよいが、ある程度APIの目的別に外部I/Fは標準化しておいたほうが良いだろう。当PoCでは、APIの処理目的別に標準的なI/Fを設計することとした。考慮すべき点は、将来の拡張性を意識して設計することであろう。

②API Gatewayの設計

API Gatewayは、1つのAPIが1つの独立したURLを持つ。Lambda Functionとのマッピングは、1API:1Lambda Functionでもよいし、1API:複数Lambda Functionでもよい。この場合URLの下のPathごとにLambda Functionがマッピングされる。前者は、1対1の関係であるため、API Gateway設定変更時の影響範囲が限定されるという利点があるが、API数が非常に多数となってしまう。拡張可能ではあるが、アカウント当たりのAPI数のデフォルトの上限は60である。後者は、API Gateway変更時の影響範囲が配下のLambda Functionに及ぶ。利点としては、API数を削減できることと、同一URL下であることでCookieを共有可能ということである。当PoCでは、サブシステム(アプリケーション)単位でAPIを定義し、機能別(データ種別ごと)にLambda Function を作成しPathにマッピングすることとした。

③API Gatewayの構築

API Gatewayの構築は、Web API (REST)とLambdaFunctionのインタフェースのマッピングを定義するのが主な設定項目である。外部設計で作成したI/Fを基にリクエストとレスポンスのマッピングを定義する。

リクエスト(Web API→Lambda)のマッピングは、主にPOSTのBody部(JSON形式)とQueryストリング、CookieなどのインタフェースをLambdaへ受け渡すオブジェクト(JSON形式)に変換するためのマッピングを定義する。レスポンス(Lambda→Web API)のマッピングは、Lambdaからのレスポンスオブジェクト(JSON形式)に応じ、HTTPレスポンスコードへのマッピングと、HTTP Content Body(JSON形式)へのマッピングを定義する。そのほかに、認証方式の選択、スロットル制限(秒あたりのリクエスト数)の設定、APIキャッシュの設定、カスタム認証モジュールの設定などがある。

当PoCでは、クライアント側のIPアドレスによる利用制限が要件であったため、カスタム認証モジュールを作成し、IPアドレスによる認証を検証した。

④API(URL)とLambda Functionの関連付け

API Gatewayには、複数ステージで実行を行う機能が備わっており、URLの一部にステージ識別IDを含めることで、本番、ステージング、テストなどのステージング環境が簡単に得られる。Lambdaとの連携も容易で、ステージごとにLambda Functionのどのバージョンを実行するかを定義できるようになっている。

運用監視

監視機能としてCloudWatchのパフォーマンス情報と、API GatewayのエラーメッセージがCloudWatchログへ出力される。

インフラ面で監視が必要なものは、HTTPエラーコードが主なものとなる。5XX、4XXエラーの発生時には、ログを分析し、アプリケーションのエラーの場合は、Lambda Functionのログから原因究明を行うことができる。スロットル制限でエラーとなっている場合は、制限値の増加を検討するだけである。従来のWebサーバーシステムのように、サーバーの台数、CPU、メモリー、DISK容量などの監視やチューニング、高可用性のための冗長化の検討などは不要だ。




記事は週に1回、追加で公開して参ります。
今すぐ全文をご覧になりたい方は、こちらから。(簡易登録が必要となります)

よくある質問

全般について

契約について

料金/
支払いについて

お問い合わせ・無料診断はこちら

お電話
03-6667-8049 受付時間(平日)9:00~17:30
メールフォーム
お問い合わせ

関連記事

  • Amazon Web Servicesにおける 監視・監査の管理手法