サーバーレスアーキテクチャで何が変わるのか③
サーバーレスアーキテクチャで何が変わるのか
※記事は週に1回、追加で公開して参ります。
今すぐ全文をご覧になりたい方は、こちらから。（簡易登録が必要です。）
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）。
| リソースまたはオペレーション | デフォルトの制限 | 拡張可否 | |
|---|---|---|---|
| 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）。
| ステータス | 概要 | クライアント側の動作 |
|---|---|---|
| 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）を記す。
| 管理対象・運用項目 | オンプレミス | サーバレス | |
|---|---|---|---|
| ファシリティ | スペース・電源容量・空調能力 | ○ | |
| 入退室管理、搬入搬出管理 | ○ | ||
| ネットワーク | 回線帯域、品質 | ○ | |
| ルータ、ファイアウォール、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技術者はいつまでも勉強し続ける必要がありそうだ。
＜参考文献＞
- 「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
記事は週に1回、追加で公開して参ります。
今すぐ全文をご覧になりたい方は、こちらから。（簡易登録が必要となります）
お問い合わせ・無料診断はこちら
- お電話
- 03-6667-8049 受付時間（平日）9：00～17：30
- メールフォーム
-
