サーバーレスアーキテクチャの長所と短所

サーバーレスアーキテクチャとは、インフラを管理することなく、アプリケーションやサービスを構築・実行する方法のことです。

デイブ・グリーン著　2021年12月17日

目次

1. サーバーレスアーキテクチャとは？
2. なぜサーバーレスアーキテクチャを採用する必要があるのか？
3. 最終的な考え

テクノロジーは誰も待ってはくれません。

あるツールやアーキテクチャの使い方に慣れた頃に、新しいものが出てくると、また最初からやり直すのか？と自問することになるかと思います。大規模なリストラやコードのリファクタリングにつながるため、投げやりになりかねない厳しい苦境に立たされてしまいます。

もし、現在のマイグレーションを終了させ、数年後に新しい製品でもう一度やり直すとしたらどうでしょうか。簡単なことではありませんし、調査や検討が必要です。

結局のところ、お客様に素晴らしいサービスを提供できているのであれば、このような大きな変化を検討することはあまり意味がないのでしょう。逆に、イノベーションを拒むと、過去に留まってしまうかもしれません。しかしそういう時こそ、より良い、より明るい未来に向けて、テクノロジーが劇的に飛躍することがあります。

そしてこれは、「サーバーレスアーキテクチャ」といった言葉をあちこちで見かけるようになったとき、私たちの脳裏をよぎるようになります。

もし、あなたが変化を考えることで頭が痛くなるのなら、次の言葉を考えてみることをお勧めします。「Webアーキテクチャに関しては、コンポーザビリティが最も重要である。」

筆者個人的にはそう思っています。私のフロントエンド・アプリケーションがどのように構成されているか、そして多くの組織が伝統的なモノリシック・アーキテクチャ・パターンからデカップリングされたマイクロサービス・アーキテクチャ・パターンに移行して成功を収めていることを考えると、サーバーレス・アーキテクチャにまっすぐつながる明確なロードマップを見ることができるのです。この記事の最後には、あなたにもそれがわかると思います。サーバーレスアーキテクチャとは何か、その良い点、悪い点を分析してみましょう。

1. サーバーレスアーキテクチャとは？

まず始めに、サーバーレスアーキテクチャとは何かについて、説明します。

サーバーレスアーキテクチャは、マイクロサービスの代わりでもなければ、サーバーがないことを意味するものでもありません。実際、クラウドサービスプロバイダーがサーバーインフラを代行してくれますし、マイクロサービスアーキテクチャとサーバーレスコンピューティングは、同じアプリケーション内でも、一緒に働くことも、別々に使うことも可能です。

クラウドサービスには様々な種類があり、何がサーバーレスアーキテクチャなのか、その境界線が曖昧になりがちです。

サーバーレスはFunction-as-a-Service（FaaS）であると考える人は多く、最もシンプルな形では確かにその通りだと思います。

FaaSはサーバーレスのサブセットで、別称サーバーレス機能と呼ばれています。これらの関数は、ユーザーがボタンをクリックしたときなどのイベントをトリガーとして実行されます。クラウドサービスプロバイダーは、これらの機能が動作するインフラを管理するので、文字通り、コードを書いてデプロイするだけでよいのです。フロントエンドとサーバーレス機能の間の通信は、APIの呼び出しと同じくらいシンプルです。

サーバーレスコンピューティングのクラウドサービスは、2014年にAmazon Web ServicesがAWS Lambdaで初めて紹介しました。その他、クラウドベンダーのFaaSとして人気があるのは以下の通りです。

Netlify Functions
Vercel Serverless Functions
Cloudflare Workers
Google Cloud Functions
Microsoft Azure Functions
IBM Cloud Functions

クラウドベンダーは、サーバーレスと混同されがちな他の多くのサービスを提供しています。

IaaS（Infrastructure-as-a-Service）
Platform-as-a-Service（PaaS）
SaaS（Software-as-a-Service）
BaaS（Backend-as-a-Service）

これらのテクノロジーはそれぞれ独立したトピックであり、今回はサーバーレスのハイレベルな概要を説明するものであるため、詳しく説明するつもりはありません。ただ、共通して言えるのは、クラウドサービスプロバイダーがサービスのインフラをすべて面倒を見るので、お客様が面倒を見る必要はないということです。

つまり、時間、リソース、複雑さ、コストを削減しながら、アプリケーションとカスタマーエクスペリエンスにのみ焦点を当てることができるのです。

これはもともと、Jam（stack）の「A」が意味するものであり、サーバーレスアーキテクチャがしばしば重要な構成要素となるMACH（マイクロサービス、APIファースト、クラウドネイティブ、ヘッドレス）エコシステムの基本的な利点でもあります。

2. なぜサーバーレスアーキテクチャを採用する必要があるのか？

サーバーレスや関連するクラウドサービスはまだ比較的新しいものですが、毎年新しい技術が市場にリリースされ、驚くほどの進化を遂げています。

しかし、サーバーレス・コンピューティングは、従来のアーキテクチャと比較して多くの利点を提供するものの、特効薬のようなものではありません。

何事もそうですが、サーバーレスアーキテクチャが要件に合致しない理由もあります。

2-1 サーバーレスアーキテクチャの長所

サーバーの管理が不要なサーバーレス・コンピューティングはサーバー上で動作しますが、そのサーバーはクラウドサービスプロバイダーによって管理されます。サーバー管理は一切不要で、スケーリングオプション、最適な可用性、アイドル容量の排除などが可能です。

コストサーバーレスがコスト削減に役立つ方法はいくつもあります。従来のサーバーアーキテクチャでは、アプリケーションがパフォーマンスのボトルネックやダウンタイムに直面しないように、通常、必要以上のサーバー容量を予測して購入する必要がありました。サーバーレスでは、バックエンドサービスが必要なときにイベントをトリガーとしてコードが一度だけ実行されるため、クラウドサービスプロバイダーは使用した分だけ課金します。さらに、サーバーのオーバーヘッドやメンテナンスはプロバイダーが行うので、開発者などのIT専門家に時間を割く必要は一切ありません。クラウドコンピューティングがハードウェアのコストを大幅に削減するように、サーバーレスも人的コストを大幅に削減することができるのです。

サーバーレスアーキテクチャで構築されたアプリケーションは、無限に、そして自動的に拡張することができます。固定サーバーのように、アクセス集中によるサイトのダウンやパフォーマンスの低下を心配する必要はありません。もちろん、ユーザー数や使用量が増えればコストは上がります。

セキュリティサーバーレスアーキテクチャに関する多くの記事で、セキュリティがデメリットとして挙げられているのを見たことがあります。しかし、トップクラスのクラウドベンダーは、最も安全でパフォーマンスと可用性の高いサービスを提供することに専念しています。このようなビジネスモデルは彼らの重要な要素であるため、サービスを作り、維持するために、ビジネスにおける最高の人材を採用しているのは当然であり、もちろん、彼らが絶対的なベストプラクティスを提供していることも確かです。アプリケーション自体のセキュリティについては、開発者が考慮しなければならないこともありますが、その大部分は業界の専門家が対応してくれるので、これは大きなメリットだと思います。

開発環境の構築が容易で、サーバーを管理する必要がないため、納期の短縮と迅速な展開につながります。これは、特に最小有効製品（MVP）にとって重要です。さらに、すべてがデカップリングされているので、モノリスアプリケーションのように膨大な量のコードを変更しなくても、自由にサービスを追加したり削除したりすることができます。

コンテンツデリバリーネットワーク（CDN）とエッジネットワークのおかげで、サーバーレス機能を世界中のエンドユーザーにより近いサーバーで実行することができるようになり、待ち時間の短縮も実現しました。Jamstackのエッジコンピューティングプロバイダーの代表的な例として、以下のようなものがあります。

Cloudflare Workers
AWS Lambda@Edge
Netlify Edge
最近ではVercel Edge Functions

2-2 サーバーレスアーキテクチャの短所

さまざまなベンダーのサービスを選んで利用することは可能ですが、ベンダーごとにやり方が異なるため、最も簡単な方法はAWSなどの単一のクラウドサービスプロバイダーを利用することでしょう。このため、別のプロバイダーに移行する場合、常に最適なサービスを提供してくれるベンダーに完全に依存することになります。何らかのインフラの問題があれば、それが解決するのを待つ必要があります。

多くの場合、同じサーバー上で複数の顧客のコードを常時実行します。マルチテナンシーと呼ばれる技術でこれを実現していますが、わかりやすく言うと、お客様はサーバーの自分のシェアにしかアクセスできないテナントです。そのため、そのサーバーの設定ミスによりデータが流出する可能性があります。

サーバーレスコンピューティングは常時稼働しているわけではありません。初めて関数を呼び出すときは、「コールドスタート」、つまり、関数を実行する前にコンテナをスピンアップさせる必要があります。これはパフォーマンスを低下させるかもしれませんが、コンテナはAPI呼び出しが完了した後も一定期間実行し続け、レイテンシーを追加することなく「ウォームスタート」することができます。また、エッジコンピューティングのおかげで、コールドスタートの問題は少なくなりつつあり、これは時間とともに改善されていくはずです。

クラウド事業者が管理するバックエンドプロセスの可視性が低下するため、デバッグが複雑になります。また、サーバーレス環境では、統合テストを実施するための複製が困難な場合があります。しかし、悪いニュースばかりではありません。サーバーレスのエコシステムが成長し続ける中、このような課題を解決するための新しいプラットフォームやサービスが市場にリリースされています。その解決策として考えられるのが、DatadogのEnd-to-end Serverless Monitoringです。