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

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

技術レポート

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

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

第3稿（本記事）
4．サーバーレスで何が変わるのか

おわりに

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

先行して全文PDFを入手する

4．サーバーレスで何が変わるのか

（ア）インフラ管理面で見たサーバーレスアーキテクチャ

インフラ管理面から見たサーバーレスアーキテクチャは、究極の運用レスということができる。これまでも、クラウド化（IaaSやPaaS）によってインフラ運用業務がなくなると言われていたが、実際のところは、OS以上の管理、運用は利用者側の責任範囲であり、DISKのバックアップやリカバリ、サーバーの稼働監視と障害発生時の対応、セキュリティパッチの適用、定期的なWindows Update、SPの適用など、サーバー単体で見たらそれほどインフラ運用作業が削減されることはなかった。

サーバーレス（LambdaとAPI Gateway）のケースでは、場合によっては構築フェーズから開発側で実施することが可能となっている。高度なインフラ知識や高可用性構成の設計などは不要であり、必要な性能目標と、アプリケーションインタフェースの設定さえ行えば、アプリケーションが実装できてしまうのである。

強いてインフラ担当の役割をあげるのであれば、同時実行プロセス数、スロットル制限などの制限値に達していないかの監視と制限値の増加と、AWS側のサービス障害時のサポート問い合わせなどが残された役割となる。

（イ）アプリケーション実行環境としてのサーバーレス

もともとアプリケーション開発ではインフラ環境を意識することは少なかった。

サーバーレスなアプリケーション実行環境であるLambdaは、Java、C#、JavaScript（Node.js）、Pythonに対応している。API Gatewayが、HTTPの状態管理、認証機能の提供、リクエスト時のJSONからオブジェクトへの変換、レスポンス時のオブジェクトからJSONへの変換を行うため、Lambdaアプリケーションは、API Gatewayから受け渡されたオブジェクトを処理し、オブジェクトとして結果を応答するだけの簡単なプログラムで、REST APIを実装することができる。API GatewayとLambdaを組み合わせることでRESTfulなAPIを容易に作成することができるのである。

ただし、Apatch/Tomcat環境などのように細かなパラメータの設定等はない代わりに、いくつかの制約事項を守る必要がある。アプリケーション要件によってはその制約を回避するための機能を実装する必要がある場合がある（表1）。

表1　主要な制限事項

	リソースまたはオペレーション	デフォルトの制限	拡張可否
Storage Gateway	アカウントあたりのスロットル制限	1 秒あたり 1000 回のリクエスト (rps) で、バースト制限は 2000 rps	はい
	アカウントあたりの API 数	60	はい
	アカウントあたりの使用プラン	300	はい
	API ごとのカスタム認証	10	はい
	API あたりのステージ数	10	はい
	統合のタイムアウト	Lambda および HTTP 統合の両方について 30 秒	いいえ
	ペイロードサイズ	10 MB	いいえ
Lambda	リクエストあたりの最大実行時間	300 秒	いいえ
	「Invoke 」リクエスト本文のペイロードサイズ(RequestResponse)	6 MB	いいえ
	「Invoke 」リクエスト本文のペイロードサイズ(Event)	128 K	いいえ
	「Invoke 」レスポンス本文のペイロードサイズ(RequestResponse)	6 MB	いいえ
	同時実行数	100	はい
	Lambda 関数デプロイパッケージのサイズ (.zip/.jar ファイル)	50 MB	いいえ
	リージョンあたりのアップロードできるすべてのデプロイパッケージの合計サイズ	75 GB	いいえ
	デプロイパッケージ (非圧縮 zip/jar サイズ) に圧縮できるコード/依存関係のサイズ	250 MB	いいえ

今回の検証では、一度のリクエストで多数（Max5000件）のデータ更新を想定していたため、制約事項の1つであるGateway統合のタイムアウト30秒が課題となった。データ更新中に30秒に達してしまった場合、処理が中断され再処理を余儀なくされてしまうが、全件を再実行しても再度30秒を超過してしまうことが予想された。この問題を回避するために、一度のリクエストで受け取ったデータの部分再送を可能とするように再送機能を実装する必要があった。処理時間が30秒に達する前にそれまでの処理をコミットし、データ行ごとの処理ステータスをクライアント側に返すことで部分再送を実現した。

サーバーレスアーキテクチャでは、IaaSでの環境構築とは異なり、フレームワークの制約に合わせた外部設計（特にI/F設計）が重要となる。RESTの電文形式はもとより、HTTPレスポンスに対するクライアント側に求める動作も定義しておく必要がある（表2）。

表2　HTTPレスポンスとクライアント側動作

ステータス	概要	クライアント側の動作
200	正常（部分エラーを含む）	Resultコードを確認し、部分エラーの場合はエラーデータのみを再送する
400	JSON形式エラー	プログラム・データを確認し再送
401	認証エラー	認証キーを確認し再送
403	APIキーエラー、無効なHTTPメソッド	プログラム・データを確認し再送
413	データサイズ超過	データを修正し再送
415	サポートされていないContext-Typeの指定	プログラム・データを確認し再送
429	リクエスト数が設定値を超えた場合	時間をおいて再送
500	サーバ側処理エラー（再送不可）	サーバ側の復旧を待って再送
503	サーバ側一時エラー（再送可）	時間をおいて再送
504	API Gateway タイムアウト(30秒)	時間をおいて再送

（ウ）サーバーレスアーキテクチャで変わること

検証の結果判明したことは、インフラ運用すべき項目がほとんどないということである。オンプレミスのシステムの場合、性能やセキュリティを維持するための監視、運用や、H/W、S/Wの老朽化対応などのライフサイクルマネジメント、そしてHW障害の対応など、運用フェーズに入った後にも多くのインフラ運用作業が存在した。サーバーレスアーキテクチャではそのほとんどをマネージドサービスの組み合わせで実現するので、アプリケーションの保守、運用が必要なだけで、インフラ運用はほとんど存在しないことになる。

以下に、一般的なシステムとのインフラ運用項目の比較（表3）と、サーバーレス環境で管理可能な監視項目（表4）を記す。

表3　運用項目比較

	管理対象・運用項目	オンプレミス	サーバレス
ファシリティ	スペース・電源容量・空調能力	○
ファシリティ	入退室管理、搬入搬出管理	○
ネットワーク	回線帯域、品質	○
	ルータ、ファイアウォール、LB、SWの余力、空きポート	○
	ルータ、ファイアウォール、LBのパッチ管理	○
ハードウェア	資産管理、余力、保守	○
ハードウェア	障害管理、対応、冗長化	○
ソフトウェア・フレームワーク	構成管理、導入、保守	○	△（パラメータ設定）
ソフトウェア・フレームワーク	パッチ適用、バージョンアップ	○
アプリケーション	開発、実装	○	○
	アプリケーション保守	○	○
	障害対応	○	○

表4　監視項目一覧

	項目名	単位	説明
Lambda	Invocation	Count	Functionの呼び出し回数。成功および失敗した呼び出しが含まれる
	Errors	Count	失敗した呼び出し回数。同時実行制限エラー、内部サービスエラーを除く回数
	Throttles	Count	同時実行数制限により失敗した呼び出し回数
	Duration	mSec	Function実行時間
	ログ	Text	アプリケーションが書きだしたログおよびLambdaのログ
API Gateway	Count	Count	APIメソッドの呼び出し回数
	IntegrationLatency	mSec	バックエンド処理時間
	Latency	mSec	APIの処理時間
	CacheHitCount	Count	APIキャッシュにヒットしたリクエストの数
	CacheMissCount	Count	APIキャッシュにヒットせず、バックエンドから提供されたリクエストの数
	4XXError	Count	クライアント側のエラー数
	5XXError	Count	サーバー側のエラー数
	ログ	Text	API Gatewayが出力するログ

日常の稼働監視では、性能（レスポンス、スロットル）とエラー（エラー回数、アプリケーションログ）の監視は最低限行う必要があるが、これらについてもAWSで用意されている監視機能（CloudWatch）を活用することで自動化が可能だ。

このように、サーバーレスアーキテクチャを利用することで、アプリケーションのみを意識すればよい理想的なコンピューティング環境を手に入れることができるのである。

おわりに

コンピュータシステムの黎明期であった1961年頃にすでにユーティリティコンピューティングという概念があった。電力、水道、電話と同じようにコンピューティングが公共設備となるであろうという考えである。それから50年余りたった現在、サーバーレスアーキテクチャを以てようやくその域へ到達したように思える。長らくコンピュータシステムは、ファシリティ（データセンター）、ネットワーク、ハードウェアなどのIT基盤と、そのうえで動くミドルウェア（データベース、アプリケーション処理基盤）、アプリケーションで構成されており、これらの構築、管理、運用がSIerの主な生業であった。近い将来、IT基盤、ミドルウェアは、クラウドサービスベンダーからサービス提供されるものとなり、狭義のインフラ運用技術者の仕事はなくなってしまうことが考えられる。このような変化の中を生き抜いていくためには、よりお客様視点（ビジネス、業務）に立って、どのようなIT技術（クラウドサービス）の組み合わせがお客様にとって最適なシステムアーキテクチャであるかを提案できる人材となっていく必要がある。クラウドサービスは、常に新しい概念、新しいサービスが生まれてくる。IT技術者はいつまでも勉強し続ける必要がありそうだ。

＜参考文献＞