サーバーレス関数ビギナーガイド

サーバーレス関数とは、サーバーレスコンピューティングにおける単一機能のプログラムのことで、適切に活用することでチームや組織に多くのメリットをもたらします。

この記事では、サーバーレス関数の仕組み、活用方法、組織にとってのメリットについて解説します。また、サーバーレス関数の導入方法とメリットを最大限に引き出す方法もご紹介します。

「サーバーレス」のコンピューティング、アーキテクチャ、フレームワークとは？

まずは背景について説明しましょう。

サーバーレスコンピューティングはクラウドコンピューティングモデルの1つであり、単に「サーバーレス」とも呼ばれます。このモデルでは、クラウドプロバイダーが顧客の要求に応じてコンピューティングリソースをプロビジョニングし、クラウドインフラを含むすべてのアーキテクチャを管理します。名前が「サーバーレス」となっていますが、実際にはクラウドと物理サーバーを利用してコードを実行します。どういうことかと言うと、ここで言う「サーバーレス」とは、開発者や運用担当者がサーバー、オペレーティングシステム、その他のインフラを直接扱うことがないという意味なのです。サーバーはどこか別の場所にあり、なくなったわけではありません。

サーバーレスアーキテクチャは、サーバーレスフレームワークとも呼ばれ、組織のソフトウェアアプリケーションをサードパーティのクラウドサービスプロバイダーがホストし、イベントドリブンで実行する形態を指します。これにより、組織はハードウェアやソフトウェアのインフラを管理する必要がなくなるとともに、ベンダーロックインを避けることができます。

インターネット上でアプリケーションを公開する場合、以前は、アプリケーションの実行に必要な物理サーバーまたは仮想サーバー、オペレーティングシステム、ネットワーク、その他のインフラコンポーネントを組織が自ら管理する必要がありました。その後、アマゾン ウェブ サービス (AWS)やMicrosoft Azureなどのクラウドサービスの登場により物理サーバーの管理は不要になりましたが、仮想サーバーのオペレーティングシステムやWebサーバーソフトウェアのプロセスなどは依然として組織が管理する必要がありました。

サーバーレスアーキテクチャでは、ハードウェア、仮想マシン(VM)のオペレーティングシステム、Webサーバーソフトウェアのいずれもプロバイダーが管理します。そのため、開発者はアプリケーションのコーディングにのみ集中できます。

サーバーレスアーキテクチャはFaaS (Function-as-a-Service)としての機能を提供するため、アプリケーションを個々の独立した機能の組み合わせとして構築できます。各機能はFaaSプロバイダーがホストし、トラフィックの増減に合わせて自動的にスケーリングされます。

ここで登場するのがサーバーレス関数です。

サーバーレス関数の仕組み

サーバーレス関数の実体は、ステートレス(データを保持しない)かつエフェメラル(不要になったら破棄される)という性質を持つ小規模なビジネスロジックです。特定の条件が満たされたときに実行され、場合によってはわずか数秒後に破棄されます。サーバーレス関数実行のトリガーとなるのは、次のようなアクションです。

• eコマースで注文を行う
• テキストファイルをアップロードする
  
• ニュースレターに登録する

API呼び出しをトリガーに実行できるものであれば、どのような機能でもサーバーレス関数として実装できます。わかりやすく説明するために、アプリケーション全体の仕組みから考えてみましょう。

概要：Webアプリケーションの仕組み

アプリケーションのアーキテクチャは、通常、フロントエンドとバックエンドに分けられます。

• フロントエンドは、Webインターフェイスなど、ユーザーとやり取りする部分です。
• バックエンドには、アプリケーションのファイルを管理するサーバーやデータベースなど、ユーザーからは見えないあらゆるコンポーネントが含まれます。

たとえば、ユーザーがオンラインショッピングサイトにアクセスすると、そのWebサイトのフロントエンド、つまりテキスト、画像、検索バー、その他の入力フォームなどが表示されます。ユーザーが商品を検索すると、検索リクエストがWebサイトのバックエンドに送られ、それがトリガーとなって、データベースをチェックするコードが実行され、商品の在庫の有無、在庫数、価格などが確認されます。その後、検索結果のデータがバックエンドからフロントエンドに送られ、ユーザーに見やすい形で表示されます。

アプリケーションのバックエンドで動作するサーバーレス関数

アプリケーションのバックエンドはさまざまな機能で構成されます。サーバーレスコンピューティングでは、開発者は個々のバックエンド機能を、独立して実行する単一用途のコードモジュールとして構築できます。これらは、Java、Python、PowerShell、Rubyをはじめ、代表的なプログラミング言語を使って、関数として実装できます。また、サーバーレスプラットフォームで使用できるそのほかの言語も継続的に追加されています。

サーバーレス関数について唯一厳格なルールは、外部のソフトウェアやコードに依存せずに実行できるようにすることです。この自己完結性のおかげで、アクティブ化、実行開始、停止をすばやく行うことができるのです。

サーバーレス関数を使用するには、関数のコードを記述して、マネージド環境にデプロイする必要があります。サーバーレス関数の一般的なプロセスは次のとおりです。

1. 関数の作成：開発者が、アプリケーションコード内の特定の目的(メールフォームの作成など)を実行する関数を記述します。
2. イベントの定義：開発者が、クラウドネイティブサービスで関数を実行するトリガーとなるイベントを定義します。HTTPリクエストなどがよく使われます。
3. イベントのトリガー：ユーザーがボタンをクリックするなどのアクションを実行して、イベントがトリガーされます。
4. 関数のデプロイと実行：クラウドサービスで、関数がまだ実行されていない場合は、関数の新しいインスタンスが起動されます。
5. クライアントへの結果送信：アプリケーション内で実行された関数の結果がユーザーに表示されます。

サーバーレス関数の一般的なプロセス

クラウドサービスプロバイダーは、関数の実行だけでなく、リソースの割り当ても行います。たとえば200件のリクエストが同時に発生した場合は、クラウドプラットフォームによって200以上のインスタンスが用意されます。同時リクエスト数が50件に減ると、インスタンス数もそれに応じて減らされます。クラウドサービスを利用する組織は、関数実行のために実際に使用されたリソース分のみの料金を支払うことになります。

サーバーレス関数のユースケース：いつ、どのように使用するか

サーバーレスフレームワークは柔軟性が非常に高く、アプリケーションに関する幅広い問題に対応できます。一般的なユースケースには以下のものがあります。

• Webアプリケーション：サーバーレス関数は、WebサイトやWebアプリケーションの作成に最適です。開発者はインフラの構築や保守を行う必要がなく、コア機能の開発に集中できます。
• 画像処理：サーバーレス関数と機械学習を組み合わせて、画像の選別、分類、サイズ変更、形式変換などを実行できます。
• アプリケーションの多言語開発：開発チームは、特定のプログラミング言語に縛られず、異なる言語で記述されたサーバーレス関数を連携させてタスクを実行できます。そのため、チームメンバーがそれぞれ好きな言語を使ってコードを記述できます。
• IoT (モノのインターネット)：サーバーレス関数を使って、IoTセンサー、デバイス、その他のエンドポイントのデータのフィルタリング、ログの収集、応答を自動化できます。
• データ操作タスク：サーバーレス関数を使ってデータのETL (抽出、変換、ロード)タスクを実行すれば、専用のETLソフトウェアよりも大幅にコストを節約できます。アプリケーション間でデータを移動したり、フロー処理したりすることもできます。
• スケジュールに基づくタスクの自動実行：サーバーレス関数を使用すれば、特定の日時や間隔で実行する必要のあるタスクやワークフローを自動化できます。場合によってはcronジョブの代わりに使用することもできます。

サーバーレス関数のユースケースはほかにもたくさんありますが、どのような目的に使用できるかは大体おわかりいただけたと思います。サーバーレスは拡張性にも優れているので、サーバーレス関数は今後登場するほぼあらゆる用途に対応できると考えてよいでしょう。

サーバーレス関数を使用すれば、IoTセンサーのデータのフィルタリング、ログの収集、応答を自動化できます。

サーバーレス関数のメリット

サーバーレス関数を使用することにはいくつかの大きなメリットがあります。サーバーレス関数を使用すれば、開発者はアプリケーションの機能向上とコードの品質改善に集中することができます。コードのデプロイやスケーリングなどのインフラの定型的な管理作業は、サーバーレスプロバイダーが行ってくれるためです。組織全体でも、コンピューティングリソースの料金は使用した分だけ支払えばよいため、物理ハードウェアに対する過剰なプロビジョニングや、使用していないクラウドインスタンスの支払いが発生する心配もなく、コストを節約できます。

以下に示すように、多くのメリットがあります。

インフラの管理が不要：ハードウェアとソフトウェアを管理する大きな負担をサーバーレスプロバイダーに引き受けてもらうことができるため、開発者はその分コーディングに時間をかけて、アプリケーションの品質を向上させることができます。

多言語での開発：通常、アプリケーションを開発するときはチーム内でプログラミング言語を統一しますが、一部のメンバーがその言語に不慣れな場合もあるでしょう。サーバーレス関数なら、メンバーそれぞれが好きな言語やフレームワークを使ってコードを記述できます。

バックエンドコードのシンプル化：サーバーレスなら、1つの機能を独立して実行する自己完結型のシンプルな関数を作成すればよいため、複雑なコードを書く負担を解消できます。

コストの削減：サーバーレスプラットフォームの利用料はリクエスト量に応じて課金されるため、関数の実行に使用されたリソース分のみの料金を支払えばよく、高いコスト効果が得られます。CPUのアイドル時間や未使用の領域には料金が発生しないため、全体としてコストを大幅に節約できます。

容易なスケーリング：サーバーレスでは需要に応じて関数が自動的にスケールアップ/ダウンされるため、キャパシティ管理の手間はほとんどかかりません。また、従量課金のため、過剰または不十分なプロビジョニングによるコストを心配したり、ベンダーロックインによるコストの高止まりに悩まされたりすることもありません。

コードの削減：サーバーレスなら、開発者がコードの記述に専念できるだけでなく、管理するコードの量自体を減らすことができます。

Webアプリケーションフレームワークの知識が不要：サーバーレス関数を使用する場合は、サーバーの管理が不要で、新しいアーキテクチャの仕組みや命名規則を覚えたり、リクエストパイプラインを構築したりする必要がなく、コードの実行に集中できます。

市場投入までの時間短縮：サーバーレスアーキテクチャでは、デプロイプロセスがシンプルであり、コードを断片的に追加または修正するのも簡単です。そのため、アプリケーションのバグ修正や新機能の追加をすばやく行えます。

サーバーレス関数のトラブルシューティング

サーバーレス関数の問題を調査するには、サードパーティのサーバーレス監視ソリューションが必要です。サーバーレスプラットフォームではそれぞれ独自の監視ソリューションが提供されていますが(AWS LambdaならCloudWatchなど)、通常、これらのソリューションでは関数が問題の兆候を示し始めたときのトラブルシューティングに必要なメトリクスは収集されません。

サーバーレス監視ソリューションやオブザーバビリティツールは、以下の点について関数レベルでの重要なメトリクスを収集できます。

• 関数の実行速度
• 関数がアクセスされる頻度
• 関数の応答性
• 関数を追跡することで、遅延などのアプリケーションパフォーマンス低下の原因となっているサービスを特定して隔離

サーバーレス関数の監視の仕組み

アプリケーションのパフォーマンスが最適な状態に保たれているかどうかを確認するには、アプリケーションが生成するメトリクスを監視します。これはサーバーレス関数でも同じです。

個々の関数に問題があると、アプリケーション全体に影響が及び、パフォーマンスの低下やダウンタイムにつながります。そのため、サーバーレス関数のエラーや障害を監視することは非常に重要です。サーバーレス関数の場合、トラブルシューティングしようとした時点で関数のインスタンスが消失している可能性があるため、完全忠実なデータを収集することが欠かせません。

サーバーレスアプリケーションの監視には、従来のアプリケーションの監視にはないさまざまな問題があります。まず、サーバーレス関数では、その管理のほとんどをアプリケーションオーナーではなくサーバーレスプロバイダーが担うため、トラブルシューティングのための情報収集が難しくなります。また、関数の実行時にのみサーバーが起動するため、エラーの追跡と特定も容易ではありません。さらに、このエフェメラルな性質によって、リソースの使用状況の追跡も困難になります。

従来の監視ツールは、サーバーレスアプリケーションの複雑さを想定していません。そこで近年は、ステートレス環境の重要なメトリクスを収集できるサーバーレス監視ソリューションが登場しています。

監視要件は、ビジネスニーズや使用するプラットフォームによってさまざまです。たとえば、AWS LambdaとMicrosoft Azureで監視すべきメトリクスには以下のものがあります。

コールドスタート

Lambdaでは、関数が呼び出されると、関数実行のためのコンテナがAWSで起動されます。しかし関数がしばらく呼び出されずにいると、コード実行の待機状態のコンテナが破棄されることがあります。この場合、関数の実行時にコンテナの生成に数百ミリ秒から数秒の時間がかかり、アプリケーションのパフォーマンスが遅く感じられます。

そのため、この「コールドスタート」を監視することは、関数のパフォーマンスを可視化して改善策を探るために重要です。

呼び出しと呼び出しエラー

サーバーレス監視ツールでは、以下の2つの重要なデータを追跡できる必要があります。

• 関数の呼び出し成功数と失敗数(イベントまたはAPI呼び出しに応じて関数が実行された回数)
  
• 関数のエラーが原因で呼び出しが失敗した回数
  

処理時間

関数の実行時間は、イベントによって実行が開始されてから関数内の処理が終了するまでのわずかな間であるため、リソースの使用状況を把握および予測することが困難です。呼び出しに応じて関数が実行を開始してから終了するまでの時間を監視すれば、プロバイダーの利用コストを管理するために役立ちます。

カスタムメトリクス

関数がビジネスやカスタマーエクスペリエンスの向上にどのくらい貢献しているかを知るためのメトリクスを監視することも重要です。たとえば、ユーザーリクエストの総数や地域ごとの売上などがあります。

サーバーレス関数のベストプラクティス

以下のベストプラクティスを実践すれば、サーバーレスアーキテクチャを最大限に活用できます。

• タスクをできるだけ小さい単位に分ける：関数に複数の依存関係が含まれると、インスタンス化に時間がかかり、遅延が長くなります。タスクを小さい単位に分けて実行時間を短くすれば、アプリケーション全体のパフォーマンスが向上し、関数の実行数が増えてもリソースのコストを抑えることができます。
• 自動スケーリングを前提に設計する：依存関係ができるだけ少なくなるようにタスクを設計すれば、同時実行が容易になり、結果としてパフォーマンスの向上とコスト削減につながります。
  
• サードパーティのサービスを活用する：サーバーレス関数はAPI呼び出しを通じて連携できるため、サードパーティのサービスを組み込むのも簡単です。すべての機能を自社で開発する代わりに、一般的なタスクについてはサードパーティのサービスを関数から呼び出すようにすれば、カスタムコードを記述する手間を減らすと同時に市場投入までの時間を短縮できます。
  
• 関数のセキュリティを確保する：サーバーレスのセキュリティは、責任共有モデルに従います。これにより、攻撃ベクトルが大幅に減る一方で、認証や暗号化など、アプリケーション自体のセキュリティについては開発者が責任を持って対処する必要があります。
  

サーバーレス関数の導入方法

サーバーレス関数を導入するための第一歩は、サーバーレスプラットフォームプロバイダーのアカウントを作成することです。人気があるのはAWS Lambda、Google Cloud Functions、Microsoft Azure Serverless Computing/Azure Functions Serverless Computeですが、ほかにもたくさんのプロバイダーがあります。プロバイダーを選ぶときは、開発予定のソフトウェアのタイプや組織の目標など、さまざまな要因を考慮します。クラウドへの移行が進んでいる場合よりも、レガシーアプリケーションをサーバーレス化する場合の方が、幅広い選択肢があります。

技術的な要件についても検討する必要があります。たとえば、サポートされる言語やデプロイ、依存関係の管理、永続的ストレージリソース、トリガーのタイプなどです。これらのサポート状況はプラットフォームによって異なるため、適切なプロバイダーを選べるようによく調べておくことが重要です。

プラットフォームが決まって登録が完了したら、開発予定の中でできるだけシンプルな関数を最初に実装します。主要なプロバイダーはチュートリアルを提供しているので、サーバーレス環境やプラットフォームの仕様を学んでおくとよいでしょう。

クラウドプラットフォームを利用する前に、ローカル環境でサーバーレスコードを実行する方法もいくつかあります。たとえば、AWS Serverless Application Model (AWS SAM)には、Lambdaのコードをオフラインでテストするための機能があります。

サーバーレス関数は時間とコストの節約につながる

サーバーレス関数を導入すれば、インフラ管理の負担を軽減して、開発者が最も重要な仕事、つまり優れたアプリケーションの開発に集中できるようになります。組織全体にも、複雑さの解消、コストの低減、俊敏性の向上といったメリットがあります。サーバーレス関数を導入することで新たな課題も生まれますが、適切なプラットフォームと適切なサーバーレス監視ツールを組み合わせれば、この革新的なテクノロジーがもたらすメリットを余すところなく享受できます。

このブログはこちらの英語ブログの翻訳です。