サーバーレスの解説とメリット・デメリット

サーバーレスとは、文字通りに「サーバーがなし」との意味があります。現在、サーバーレスは非常に人気のある技術であり、世界中の多くの大企業や会社によって使用されています。この記事では、VTIはサーバーレスの概念、このアーキテクチャの導入件数が増えていく理由、およびその長所と短所についてご紹介します。

サーバーレスとは何か？

 

実際、サーバーが完全にないわけではないが、第三者（サードパーティ）が開発者に必要に応じて提供する、データベース、メッセージ、認証などの機能、サービスを使用することです。

サーバーレスでは、オペレーティングシステムやファイルシステムの管理、セキュリティパッチ、ロードバランシング、容量管理、スケーリング、ロギング、モニタリングなどの一般的なタスクがすべてクラウドサービスプロバイダーに管理されます。

従来のサーバーモデルでは解決できない問題

クラウドコンピューティングは、コストの問題を解決するとともに、Elastic（伸縮性）、High Availability（高可用性）などの要素を確保するサーバーの構築をより簡素化するために生まれました。ただし、従来のサーバーモデルでは次のような制限があります。

• コストの面：サーバーの数を適切に増減することは、サーバーの負荷が低い時にコストを削減できます。ただし、すべてのサーバーをオフにすると、システムが完全にオフになって要求に応答できなくなるため、これは実行不可です。
• 時間の面：処理量が多い場合、サーバーの数を増やす必要が発生する時点からリクエスト処理の開始ができるまで、一定の時間がかかります。その要する時間はサーバーの設定によって異なります。 リクエストの数が急増減する時、システムがタイムリーに反応できなくなり、過負荷あるいは負荷不足の状態になる可能性があります。
• サーバー数量の面：サーバーのスケールアップ・スケールダウンのために、システムのサーバー数の上下限を指定する必要があります。こういうことは、サーバー数の判断が間違っている、つまりサーバーの最小数が大きすぎるか最大数が少なすぎると、システムの負荷不足、又は過負荷になるという問題につながります。
• メンテナンスの面：サーバーの実行では、システムが最適に動作するように、OSおよび使用しているサービスを更新する必要があります。更新時にサーバーが稼働停止（ダウンタイム）になりますが、サーバーの数が多いほど手間が多くかかります。

サーバーレスのメリット

基本的には、サーバーレスアーキテクチャでは、開発するシステムはサードパーティによって完全に管理されるサーバーに実装されます。このように、サーバーレスを活用することにより、サーバーの存在を意識せずに設計に集中することが可能になります。以前は、オンラインアプリケーションを実装するには、必要なサーバーの数、使用容量、およびデータベースを事前に知る必要がありました。

• 従量制料金：サーバーレスアプリケーションを実装する場合、サーバーの管理と運用にコストはかからなくなりますが、関数が呼び出されるたびのリクエスト数と実行時間、および使用容量に基づいて課金されます。リクエスト数が全くないなら、料金はゼロになることもあります。
• 伸縮性（エラスティック）：管理者は、適切なサーバー設定数量を考慮したり、大量のトラフィックが発生した場合に心配したりする必要はありません。サーバー数の設定は、すべての要求が応答されるように、システムへのアクセス数に基づいてサービスプロバイダーによっていつでもできるだけ迅速で自動的に実行されます。（ただし、通常、各プロバイダーは同時処理可能なリクエスト数に制限を課すため、この制限を超えたい場合は直接プロバイダーに連絡する必要があります。）
• メンテナンス不要：サーバー管理はプロバイダーに任せているので、メンテナンスや更新等には頭を悩ませずに済みます。
• 開発に全集中：上記のような問題から頭が離れたため、開発者はアプリケーションの調査、研究、開発に全集中し、ユーザーの要望への対応力を最大限に生かすことができます。

こういう「サーバーレス」概念から「Functions as a Service」という用語もあります。これは独立した多数の個別の関数でシステムを開発する仕組みを指します。各リクエストは関数単位で個別に処理されるため、リクエストが完全にステートレスになっているようにアプリケーションを設計する必要があります。

サーバーレスのデメリット

すべてのことには、独自の長所と短所があります。従来のサーバーの問題への対処法として生まれたサーバーレスにも、それ自身の問題も発生します。

• サーバーレスのプロバイダーに依存：サーバーの管理をプロバイダーに一任にしているため、調整を自由に行うことはできなくなり、提供されたサービス内容に囚われてしまいます。例として、プロバイダは現在NodeJS 12.x、x版しかサポートしませんため、より新しい版に更新したい場合でも、サービスプロバイダにサポートされるまで待機するしかありません。
• 容量・時間の制限：各サービスプロバイダーは、関数の実行時間と使用可能な容量の上限を設定します。例えば、AWSの場合、使用可能な容量が10GB、タイムアウト時間が900s、Googleの場合は540s、Azureは10分です。
• したがって、処理時間が長く、多くのリソースの使用が必要となる要求に対して対応できず、対応しようとしても他のサービスと組み合わせる必要があります。この場合のサーバーレスの各関数がトリガーの役割を担います。
• ストレージなし：サーバーレスの各関数はステートレスであるため、ローカルメモリの代わりに、S3、RDS などのストレージサービスを利用してデータを格納することが望ましいです。
• デバッグ：障害が起きた時にデバッグするのが難しいですが、フレームワークを使用することで、ローカル開発環境の構築、デプロイ、デバッグができるようになりました。しかし、それはまだかなり限られています。
• レスポンスタイムの遅さ：要求が到着した時、関数を起動するのに少し時間（数ミリ秒から数秒）がかかるため、即時の応答が必要なシステムには適していません。

サーバーレスシステムの展開方法

現在、サーバーレスモデルを使用した関数を簡単に作成することを可能にするサービスを提供するプロバイダーは多数あります。

• AWS Lambda：現在のクラウドインフラストラクチャ市場では、AWSはトップシェアを占めます。ユーザーがサーバーレスモデルで関数を作成できるLambdaサービスを提供しています。API Gateway、S3などの他のサービスと組み合わせると、APIサーバーやファイルがS3にアップロードされる時の自動処理システムが作成できます。AWS Lambdaは、js、Java、C#、Pythonなどの多くの言語をサポートしています。
• Google Cloud Functions：Google Cloud Functionsは現在、jsのみサポートしています。
• Azure Functions：Microsoftの提供で、C# 、JavaScript、F#、Python、Batch、PHP、PowerShellをサポートサポートしています。

Kubeless、Fnなど他にも多くのプロバイダーがありますが、上記の3社は、上位の市場シェアを占め、より人気があります。以下は、AWS Lambda、Google Cloud Functions、およびAzure Functionsの詳細比較表です。

 

機能	AWS Lambda	Google Cloud	Azure Functions
スケーラビリティ	自動スケーリング	自動スケーリング	自動スケーリング
機能制限	無制限	プロジェクトごとに1,000	無制限
同時実行	アカウントごとにリージョンにあたり1000（ソフトリミット）	機能にあたり3000	無制限
最大実行時間	900秒（15分）	540秒（9分）	600秒（10分）
対応言語	Java, Go, PowerShell, Node. js, C#, Python, and Rub	Nodejs, Python, Go, Java, .Net, Ruby, PHP	Net, Nodejs, Python, Java, PowerShell
展開	ZIP upload (to Lambda or S3) – Docker	ZIPアップロード、Cloud StorageまたはCloud Source Repositories	Visual Studio Team Services、OneDrive、Local Git repository、GitHub、Bitbucket、Dropbox、External repository
ブラウザ内ソースコードエディタ	有り	Cloud Source Repositoriesのみ対応	Functions environment、App Service editor
モニタリング	CloudWatch、X-Ray	Stackdriver Monitoring	Application Insights
バージョニング	バージョン版数とエイリアス	クラウドソースのブランチ／タグ	クラウドソースのブランチ／タグ
イベントドリブン	S3、SNS、SES、DynamoDB、Kinesis、CloudWatch、Cognito、API Gateway、CodeCommitなど	Cloud Pub/Sub、オブジェクト変更通知	Blob、EventHub、Generic WebHook、GitHub WebHook、Queue、Http、ServiceBusキュー、ServiceBus トピック、タイマートリガ
HTTP(S)対応	APIゲートウェイ	HTTPトリガ	HTTPトリガ
オーケストレーション	AWS Step Functions	Google Cloud Workflows	Azure Logic Apps
ロギング	CloudWatch Logs	Stackdriver Logging	App Services monitoring
リクエスト料金	最初リクエスト100万件無料、以降リクエスト100万件あたり 0.20USD。GB-秒あたり 0.00001667USD（期間）	最初リクエスト100万件無料、以降リクエスト100万件あたり 0.40USD。GB-秒あたり 0.00000231USD（期間）	最初リクエスト100万件無料、以降リクエスト100万件あたり 0.20USD。GB-秒あたり $0.000016USD（期間）

 

 

どの企業がサーバーレスに適切か

Industryarcのレポートによると、2018年のサーバーレスの採用率では、大手企業が58.7%を占めました。さらに、サーバーレスの導入は、リアルタイムのWebアプリケーションとデータ処理を行う大企業に偏っています。その理由は、サーバーレスが企業にIT・インフラの低コストと高い拡張性などの利点を提供できることが考えられます。しかし、コスト効率の高い技術に対する需要が高まる中、2020年から2025年にかけて、中小企業も積極的にサーバーレスを導入することが期待されています。

 

まとめ

現在、サーバーレスに高い注目が集まり、クラウドサービスプロバイダーがこのモデルを自社のサービスに適用する傾向にあります。サーバーレスによって、他のタスクの処理時間を節約することで、開発に全力を尽くすことができます。また、多くの企業がこのモデルに切り替えたいもう一つの理由としては、大幅なコスト削減です。しかし、従来サーバーとサーバーレスのどちらかを選択するには、各モデルの長所と短所から、システム要件要件への適合性や開発チーム自体の能力を考慮する必要があります。したがって、サーバーレスを導入するか、従来のサーバーを使用し続けるかを決定する前に、企業が明確な開発戦略を立て、自社の実力を把握すべきです。

参考資料：

• AWS Serverless Computing and Applications
• CloudAcademy – Microsoft Azure Functions vs. Google Cloud Functions vs. AWS Lambda
• Serverless Computing Pros and Cons