Azure Managed Service Column ＜Azure運用コラム＞サーバーレスとは？仕組みや活用シーン、代表的なサービスを徹底解説！

向き・不向きを理解し、アプリケーション開発に集中できる理由を解説

業務システムの運用では、サーバーの構築や保守、リソース調整など、インフラ管理に関わる負荷が継続的に発生します。こうした作業に時間やコストを取られることで、本来注力したいアプリケーション開発や機能改善に十分なリソースを割けないケースも少なくありません。

こうした課題への対応策として注目されているのが、サーバーレスという考え方です。サーバーレスはサーバー管理の一部をクラウド事業者に任せることで、運用負荷を軽減する仕組みです。

本記事では、サーバーレスの仕組みや位置付けを整理し、向き・不向きや活用シーン、代表的なサービスを解説します。

1.サーバーレスとは

サーバーレスとは、名前の通り、サーバーの構築や管理を利用者が意識することなく、アプリケーションを実行する技術のことを指します。

サーバーレスは、クラウドを前提とした技術です。実際はアプリケーションを実行させるためのサーバーが存在しますが、抽象化されており利用者からは存在を意識されることがありません。サーバーはクラウドサービス事業者が管理し、インフラのプロビジョニング、運用保守、スケーリングはクラウドサービス事業者が責任をもって実施します。

サーバーレスの仕組み

サーバーレスは、あらかじめ用意したプログラムを、特定のきっかけ（イベント）が発生したときだけ実行する仕組みを採用しています。たとえば、データの更新やファイルのアップロード、外部サービスからのリクエストなどをトリガーとして処理が開始されます。

このとき、アプリケーションを実行するためのサーバー環境は自動的に用意され、処理が終わると不要なリソースは解放されるのが特徴です。利用者はサーバーの起動や停止、スケーリングといった作業を意識する必要がなく、実行した処理の分だけリソースを利用する形となります。

従来のインフラ構成との違い

従来のインフラ構成（オンプレミス環境）では、自社でサーバーを構築・管理するのに対し、サーバーレスではサーバー管理の大部分をクラウド事業者に委ねられる点が大きな違いです。

オンプレミス環境では、サーバーの台数や性能を事前に見積もり、 OS やミドルウェアの設定、監視、障害対応などを行う必要があります。利用状況に応じたリソース調整も不可欠で、システムの規模や利用頻度にかかわらず、一定の管理負荷が発生し続けます。

一方、サーバーレスでは、サーバーの構築やスケーリング、保守といった実務をクラウド事業者に任せられるため、利用者はアプリケーションの処理内容に集中しやすくなることが特長です。

2. サーバーレスの位置付け

クラウドサービスは、提供される範囲によって分類されます。インフラを提供する IaaS 、実行環境までを提供する PaaS など複数の種類があり、サーバーレスはその中で FaaS（ Function as a Service ） に分類されます。

FaaS は、アプリケーションを構成する処理を「機能（ファンクション）」単位で実行する形態です。実行環境や基盤の管理をクラウド事業者に委ねるため、利用者はサーバー管理をほとんど意識せずに利用できます。

IaaS や PaaS と比べると、利用者の管理範囲は最も小さく、処理内容の実装に専念できる点が特長です。

サーバーレスとコンテナの違い

コンテナとは、アプリケーションを実行するために必要なライブラリやアプリケーションモジュールを一つにまとめたものです。

サーバーレスとコンテナは、どちらもクラウド環境でアプリケーションを効率的に実行する手段のため、比較されることが多くあります。ただし、両者は次のようなポイントで異なり、サーバーレスは管理負荷を最小限に抑えたい場合に、コンテナは構成や実行環境を柔軟に制御したい場合に適しています。

3.サーバーレスのメリット・デメリット

サーバーレスはクラウド上で簡単にセットアップして利用できる便利なサービスですが、具体的にどのようなメリット、デメリットがあるのでしょうか。ここでは、サーバーレスのメリットとデメリットについて解説します。

サーバーレスのメリット

サーバーレスのメリットは下記の通りです。

• ランニングコストの削減
• 高い可用性とスケーラビリティ
• 利用した分だけの課金

ランニングコストの削減

サーバーレスにより、開発者の生産性が向上し、運用コストを削減することが可能です。ソースコードの作成・修正の負荷が軽減され、 OS のメンテナンスや障害対応など、サーバーの運用保守負担も軽減されます。それにより、開発者はその分アプリケーション開発業務に集中する時間を増やすことができます。

高い可用性とスケーラビリティ

サーバーを利用してシステムを構成する場合、可用性を高めるために、サーバーやデータセンターの冗長化などを検討する必要があります。また、アクセス数やデータ量の増加に伴い、サーバーの増設などを検討する必要もあります。

サーバーレスはクラウドサービス上で提供されるため、可用性やスケーラビリティはクラウドサービス事業者側の責任で担保されます。そのため、自前でシステムを導入するより高い可用性やスケーラビリティを実現することが可能です。

利用した分だけの課金

サーバーレスは、一般的に、処理を実行した分だけコストがかかる従量課金制となっています。そのため、処理を実行しない時間はコストがかからず、コスト削減につなげることができます。

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

サーバーレスのデメリットは下記の通りです。

• カスタマイズ性の低下
• 処理性能・応答性が低い
• ベンダーロックイン

カスタマイズ性の低下

サーバーレスは、クラウドサービス事業者が提供するサービスです。こうしたサービスは、インターフェースの連携方法やキャパシティなどに制約を設けている場合があります。こうした場合、ユーザー固有のシステムの柔軟性やカスタマイズの度合いに影響を及ぼす可能性を考慮する必要があります。

処理性能・応答性が低い

サーバーレスは、オンプレミスで高性能なサーバー上で常にアプリケーションが稼働しているアーキテクチャと比較すると、リクエストを受けてからアプリケーションの起動までタイムラグがあるため、応答性が低いと言われています。高い応答性・処理性能が求められるシステムには向かない場合があります。

ベンダーロックイン

サーバーレスアーキテクチャは、一般的にクラウドサービス事業者が定める仕様に準拠しており、基本的に複数のクラウドや、オンプレミスでの実行を想定していません。

また、1つのクラウド上で開発したサーバーレスアプリケーションを他のクラウドへ移行することに制約・制限が発生することもあります。そのため、ベンダーロックインに陥る可能性があるということも考慮する必要があります。

4.サーバーレスが向くシステム・向かないシステム

メリット・デメリットを勘案しても、非常に便利なサーバーレスですが、どんなシステムにも向いているのでしょうか。ここでは、サーバーレスが向くシステムと向かないシステムについて解説します。

サーバーレスが向くシステム

サーバーレスは、独立性が高く、疎結合な単純処理に最も向いています。例えば下記のような処理・アーキテクチャを採用したシステムが向いています。

• 送信されてきたデータの加工を行う処理
• イベント駆動の業務処理

サーバーレスは、リクエスト量に応じて自動的にスケールする特性を持ちます。
そのため、大規模な受信データに対して、細かく分割された単純な処理を用いて並列処理を行うような目的には非常に向いていると言えます。

サーバーレスが向かないシステム

サーバーレスの注意点として、起動時にコールドスタートが発生することがあり、即応性が求められる低レイテンシな処理では不利になるケースがあります。また、サーバーレスは疎結合で独立性の高いものに向いているため、他の処理と密接に連携するものも性能面で不利となる恐れがあります。

5. サーバーレスの活用シーン

ここでは、業務でよく見られる代表的なサーバーレスの活用シーンを紹介します。

アクセス数が大きく変動するWebサービス

キャンペーンサイトやメディアサイト、 EC サイトの一部機能など、時間帯やイベントによってアクセス数が大きく変動する Web サービスでは、サーバーレスがよく活用されます。これらは、サーバーリソースの調整が課題になりやすいためです。

サーバーレスを活用すれば、アクセスやリクエストの増減に応じて自動的に処理が実行されるため、事前のリソース見積もりやスケール対応を意識せずに運用できます。常時稼働が不要な処理を切り出すことで、リソースの効率化と運用負荷の軽減につながります。

決まったタイミングで処理が発生する業務システム

日次・月次のデータ集計、定期的なファイル生成、バッチ処理など、特定のタイミングでのみ実行される業務処理にもサーバーレスは適しています。

従来は処理の有無にかかわらずサーバーを稼働させる必要がありましたが、サーバーレスでは必要なタイミングでのみ処理を起動できます。これにより、インフラの常時管理に手間をかけることなく、業務処理を安定して実行できる構成を実現可能です。

外部サービスや他システムと連携するシステム

API 連携やデータ連携など、外部サービスや他システムとのやり取りが発生する処理も、サーバーレスの代表的な活用シーンです。

たとえば、外部サービスからの通知を受けて処理を実行したり、データ更新をトリガーに別システムへ連携したりする用途が考えられます。イベントの発生をきっかけに処理を実行する仕組みと相性が良く、疎結合な連携構成を取りやすい点が特長です。

6. 代表的なサーバーレスサービス

サーバーレスサービスは各クラウドベンダーから提供されており、基本的な考え方は共通しているものの、連携しやすいサービスや想定される利用シーンには違いがあります。ここでは、代表的なサーバーレスサービスの特徴を解説します。

Azure Functions

HTTP リクエストやスケジュール、ストレージの更新など、さまざまなイベントをトリガーとして処理を実行できる点が特徴です。 Azure の他サービスとの親和性が高く、 Azure Logic Apps や Event Grid 、 Microsoft 365 などと組み合わせた業務システムを構成しやすい点もメリットです。

すでに Microsoft 製品や Azure 環境を利用している企業にとっては、取り入れやすい選択肢でしょう。

AWS Lambda

S3 や DynamoDB 、 API Gateway など、 AWS の各種サービスとイベント駆動で連携できる点が強みです。エコシステムが成熟しており、 Web サービスからバックエンド処理まで幅広い用途で採用されています。

一方で、利用する AWS サービスが多くなるほど構成が複雑になりやすいため、設計段階で全体像を整理しておくことが重要です。

Google Cloud Functions

シンプルな構成で利用を開始しやすく、 Firebase や BigQuery など、 Google のデータ分析・アプリ開発基盤と連携しやすい点が特徴です。

特にデータ処理やイベント連携を中心とした用途に適しており、小規模な処理やプロトタイプ開発などで活用されるケースが多く見られます。

いずれのサービスも基本的な機能は共通していますが、既存システムとの親和性や社内の運用体制によって最適な選択肢は異なります。すでに利用しているクラウド基盤や、連携対象となる業務システムを踏まえたうえで選定することが重要です。

7.まとめ

サーバーレスは、サーバーの構築や保守といった管理作業をクラウド事業者に委ねることで、運用負荷を軽減するアーキテクチャです。 IaaS や PaaS との違いを理解したうえで、システムの特性や業務要件に応じて採用を判断することが重要になります。

なかでも Azure Functions は、 Azure の各種サービスと連携しやすく、アクセス変動への対応や定期処理、システム連携などを効率的に実現しやすい点が特長です。

Rworks の「 Azure 導入支援サービス」では、利活用のプランニングから PoC 、移行設計、運用設計までを一貫して支援し、 Azure を活用したサーバーレス導入を現実的に進めるための検討をサポートしています。

Tag： サーバーレス

• 

  Azureへデータ移行するには？移行のためのステップと環境に合わせた移行方法を紹介！

• 

  Azure Virtual Desktop（AVD）導入に必要なライセンスとは？