enterpriseCloud+｜CACのAWS導入支援サービス「enterpriseCloud+」

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）。

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

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

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

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

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

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

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

おわりに

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

＜参考文献＞

「Serverless Architectures」、Martin Fowler、2016年8月4日

http://martinfowler.com/articles/serverless.html

「ユーティリティ・コンピューティングそのコンセプトの出自と背景」、P42、Open Enterprise Magazine Dec2003

http://www.itmedia.co.jp/enterprise/0405/16/0517_feature.pdf

「Amazon API Gatewayとは」、Amazon Web Services（AWS）ドキュメント

http://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/welcome.html

「AWS Lambdaとは」、Amazon Web Services（AWS）ドキュメント

https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/welcome.html