サーバーレス コンピューティング
クラウド コンピューティングの初期の時代、Amazon や Microsoft などのクラウド サービス プロバイダーは、さまざまな IaaS サービスをお客様に提供することに重点を置いていました。 これにより、お客様は、オンプレミスの物理サーバーまたは仮想マシンで実行していたワークロードをクラウド内の仮想マシンに比較的簡単に移行でき、パブリック クラウドの成長が促進されました。 しかし、IaaS には責任が伴います。 クラウドで VM を稼働させる組織は、VM の内容 (オペレーティング システム、必要なランタイム、それらのランタイムを利用するアプリケーションなど) を維持する責任も担います。
PaaS では、そのような責任の一部がクラウド サービス プロバイダーに移行されて、クラウドへの投資がさらに進んでいます。 AWS Elastic Beanstalk や Azure App Service などのサービスを使用することで、お客様は、Java、Node.js、Microsoft .NET などの一般的なランタイムを備えた仮想 Web サーバーをプロビジョニングし、数分でソフトウェアを稼働させることができます。 仮想マシンは内部で大量の処理を実行しますが、これらの仮想マシンの存在の大部分は抽象化されています。 PaaS により、お客様は、VM を管理したり、プラットフォームを修正して最新の状態に維持することではなく、ビジネス上の問題を解決するために自分達で作成するアプリケーションに集中できます。
"サーバーレス コンピューティング" は、そのような抽象化をさらに推し進める、クラウド コンピューティングにおける比較的最近のイノベーションです。 ミッション クリティカルなデータのバックアップを毎晩実行したり、毎週の課金を実行したり、請求書がクラウド ストレージにアップロードされるたびに電子決済を送信したりするコードの作成と保守を行っている組織を想像してみてください。 この場合、包括的な目標は、このコードを適切なタイミングで実行することです。 コードを格納する場所や、コードを実行する方法と場所など、それ以外はすべて二次的なことです。
コードを実行するために 1 つ以上の VM を作成し、必要なプラットフォームとライブラリをインストールすることにより、IaaS のアプローチを利用することが "できます"。 Elastic Beanstalk または App Service のインスタンスをプロビジョニングし、そこでコードをホストすることができます。 または、AWS Lambda や Azure Functions などの関数ランタイムを使用して、ホストする場所や方法に関係なく、必要に応じてコードを実行することもできます。 AWS Lambda と Azure Functions はどちらもサーバーレス コンピューティング (具体的には "サーバーレス関数") の例であり、Google Cloud Functions も同様です。 以上の 3 つはすべて、IaaS からサーバーレスという、クラウド コンピューティングの自然な進化における次のステップです。IaaS ではすべてのことに対する責任はお客様にありますが、サーバーレスでは、お客様はクラウドで実行したいアクション (実行したいコード) に集中し、それ以外のすべてのものの管理をクラウド サービス プロバイダーに任せることができます。
クラウド内の関数ランタイムによって実行されるサーバーレス関数は、サーバーレス コンピューティングの最も一般的な形式ですが、唯一の形式ではありません。 Amazon、Microsoft、Google では、サーバーレス データベースなど、他の PaaS サービスのサーバーレス バージョンが提供されています。 一部のプロバイダーでは、"サーバーレス ワークフロー" がサポートされています。これにより、お客様は、クラウドでビジネス ワークフローを定義し、外部イベント (クラウド ストレージへの請求書のアップロード、指定した間隔でのタイマーの発動、受信トレイへのメールの到着など) に応答してフローを実行できます。多くの場合、コードを 1 行も書かずに済みます。 最後に、クラウド サービス プロバイダーによって提供されているコンテナー サービス (Azure Container Instances や AWS Elastic Container Service など) の多くは、クラウドでコンテナーを実行し、基になるインフラストラクチャを抽象化できるため、サーバーレス コンピューティングの例として認められています。
サーバーレス コンピューティングの利点
クラウド コンピューティングを利用する組織にとって、サーバーレス コンピューティングの利点は主に次の 3 つです。
コンピューティング コストの削減: 通常、お客様は、IaaS 仮想マシンおよび PaaS サービス (Elastic Beanstalk や Azure App Service など) に対して月額料金を支払います。 サービスがアイドル状態の場合でも、課金は続きます。 一方、ほとんどのサーバーレス コンピューティング サービスでは "従量課金" がサポートされており、コードの実行時間に対してのみ課金されます。 ミッション クリティカルなデータの夜間バックアップを実行するコードの実行専用に、1 か月あたり 100 ドルかかる VM を使用していて、そのコードは毎晩 30 分間実行される場合を想像してください。 1 か月の 1/48 の時間 (1 日にもなりません) だけコードを実行するために、毎月 100 ドルを支払っていることになります。 同じコードをサーバーレス関数としてデプロイすると、1 か月あたり最低数ドルのコストで済む可能性があります。 従量課金制では、アイドル時間に対して料金は請求されません。
自動スケーラビリティ: クラウド プロバイダーでは、AWS Auto Scaling や Azure の仮想マシン スケール セットなどの製品で、IaaS サービスをスケーリングするためのメカニズムが提供されています。 また、PaaS サービスの手動スケーリングと自動スケーリングのオプションも用意されています。 ただし、スケーリングが自動的に実行される場合でも、クラウド管理者は、スケーリングを行う方法とタイミングをクラウド プロバイダーが認識できるように、自動スケーリングを有効にして構成する必要があります。 管理者が考慮する必要のある、基になる考慮事項の 1 つは、支払いは IaaS および PaaS サービスの個々のインスタンスに対して行うので、"十分な" サイズにスケーリングされるようにサービスを構成し、"過剰に" スケーリングしないということです。 サーバーレス コンピューティングには、需要が増えたときのスケールアウトと減ったときのスケールインを、透過的かつ自動的に行うオプションが用意されています。 クラウド管理者は、通常、サービスでこのオプションを有効にする以外の構成を実行しません。 サーバーレス関数の実行に対して一度に 100 件の要求が発生した場合、クラウド サービス プロバイダーにより、要求は並列 (またはほとんど並列) に実行されます。 従量課金制では、実行が直列か並列かに関係なく、関数を 100 回実行するためのコストは同じなので、コストが影響を受けることはありません。
管理コストの削減: サーバーレスでは、お客様はコードとワークフローの実行に専念でき、基になるプラットフォームの保守など、他のすべてのことに対する責任はクラウド サービス プロバイダーに委ねられます。
サーバーレス コンピューティングにも欠点があります。 次のような制限事項を考慮する必要があります。
一部の関数ランタイムには、関数を実行できる時間数に制限が設けられています。
関数ランタイムによっては、そのための追加料金を払わない限り、関数がすぐに実行されることは保証されません。 従量課金制の価格を使用するように構成された Azure Functions では、関数がトリガーされてから最大 10 分間実行されないことがあります。 これは、夜間バックアップでは問題にならない可能性があります。おそらく、バックアップの実行は午前 1:00 でも午前 1:10 でも問題はありません。しかし、リアルタイム (またはほぼリアルタイム) に実行する "必要がある" 関数のようなタイム クリティカルな関数では、問題になることがあります。
サーバーレス関数は一般にステートレスです。つまり、内部的にデータを格納することはできず、関数の呼び出しと呼び出しの間でデータが保持されることは期待できません。 Amazon S3 や Azure Storage などの外部のクラウド ストレージ サービスを使用して、呼び出しの間でデータを保持することは "できます" が、このようにすると関数のコードがいっそう複雑になります。
一部のクラウド サービス プロバイダーでは、ステートフル関数がサポートされていますが (Azure では "Durable Functions" と呼びます)、状態を保持する関数は、サーバーレス コンピューティングに対する比較的最近の追加機能であり、一般にはサポートされていません。
サーバーレス関数
サーバーレス コンピューティングの最も一般的な例は、サーバーレス関数です。 ユーザーはコードをクラウドにアップロードして、実行するタイミングを通知します。 コードは、Java や C# など、さまざまな言語で記述できます。
図 11 に、このドキュメントの執筆時点で、Azure、AWS、GCP のサーバーレス関数によってサポートされているプログラミング言語を示します。
| 言語 | Azure Functions | AWS Lambda | Google Cloud Functions |
|---|---|---|---|
| C# | x | x | |
| F# | x | ||
| Go | x | x | |
| Java | x | x | |
| JavaScript (Node.js) | x | x | x |
| PowerShell | x | x | |
| Python | x | x | x |
| Ruby | x | ||
| TypeScript | x |
図 11: 一般的なサーバーレス関数ランタイムでサポートされるプログラミング言語。
関数を作成し、実行するコードを指定するときに、関数実行の契機になる外部イベントも示します。 一般的なクラウド プラットフォームでは、タイマー、他のクラウド サービスでのイベント発生 (クラウド ストレージへのドキュメントのアップロードなど)、HTTP 呼び出しなど、さまざまな種類の "トリガー" がサポートされています。 請求コードを関数ランタイムにアップロードし、1 日に 1 回、1 週に 1 回、またはひと月に1回実行するように構成するのは簡単です。 また、請求書がクラウド ストレージ (Amazon S3 や Azure Storage など) にアップロードされるたび、または関数に関連付けられている REST エンドポイントが呼び出されるたびに、関数をアクティブ化するのも同じように簡単です。
サーバーレス関数は、夜間バックアップや請求など、スタンドアロンタスクを実行するためによく使用されます。 また、他のクラウド サービスに接続し、クラウド サービスを構成要素として使用してリッチなソリューションを作成する場合にも使用されます。 図 12 では、複数の Azure サービスを組み合わせて北極地方でのシロクマの活動を監視するためのソリューションを紹介します。 アーキテクチャにおいて重要な役割を果たす Azure 関数は、Azure Stream Analytics から出力を取得し (HTTP 呼び出しによってトリガーされて)、Azure Blob Storage から写真を取得して、Azure Custom Vision Service でトレーニングされたモデルに写真を送信します。そこでは、人工知能 (AI) を使用して、写真にシロクマが写っているかどうかが判断されます。 関数は、Stream Analytics、Blob Storage、Custom Vision の各サービスを結び付ける接着剤です。
図 12: Azure 関数を使用した他の Azure サービスの接続。
サーバーレス ワークフロー
一部のサーバーレス コンピューティング サービスでは、ユーザーはコードを書かなくてもビジネス ワークフローを自動化できます。 たとえば、Azure Logic Apps には、Oracle データベースから X などのソーシャル メディア サービスまで、データ ソースとのインターフェース用に、100 を超える組み込みの "コネクタ" が用意されています。ワークフローを実行するタイミング (ファイルが Box.com にアップロードされた際や、指定されたハッシュタグでツイートされた際など) を定義するための "トリガー" が用意されています。 また、トリガーが発生したときに行うことを定義し、連結して複雑なワークフローを形成できる多数の定義済み "アクション" や、条件付きでアクションを実行できる "条件" も、提供されています。 そして、Azure Logic Apps でサポートされているアクションの 1 つは、Azure 関数を呼び出すアクションなので、無限に拡張することができます。 アクションにカプセル化されていないカスタム ロジックがワークフローに含まれる場合、そのロジックを実装するコードを指定して、定義済みのアクションであるかのようにワークフローに組み込むことができます。
図 13 では、Azure Logic Apps デザイナーでのそのようなワークフローの 1 つを示します1。 メールが到着すると、ロジック アプリのアクションが開始されて、メールの件名行にキー フレーズが含まれるか、また添付ファイルが存在するかどうかがチェックされます。 両方の条件が満たされている場合、ロジック アプリは Azure 関数を呼び出して、メールの本文から HTML を除去します。 その後、サニタイズされたメールと付随している添付ファイルを Azure Blob Storage に格納し、Blob Storage 内の関連ドキュメントへのリンクを含むメールを送信して、関心を持つユーザーに、利用できる情報があってレビューを待っていることを通知します。 この例では、コード (少なくとも組織内のユーザーが作成するコード) なしでアクションを実行するロジック アプリと、ワークフローをカスタマイズするためのユーザー提供コードが含まれている Azure 関数という、2 つのサーバーレス パラダイムが組み合わされています。これは、ユーザーがすべてを自分で行う仮想マシンから、組織が仮想マシンの管理およびランタイムのインストールとメンテナンスではなく、ビジネス上の問題の解決に集中できる高レベルの抽象化へのシフトという、クラウド コンピューティングで発生していることの典型的な例です。
図 13: Azure Logic Apps でのワークフローの定義。
Amazon では、AWS Step Functions の形式で同様のサービスが提供されています。 Step Functions を使うと、AWS Lambda や AWS ECS などの他のサービスを組み合わせてビジュアル ワークフローを作成できます。 ワークフローは一連のステップで構成され、1 つのステップからの出力が次のステップへの入力になります。 Azure Logic Apps と同様に、AWS Step Functions では分岐と並列実行のためのプリミティブが提供されており、コードを記述しなくても同じことができます。 実際には、ビジネス ワークフローは、理解しやすく、他のユーザーに簡単に説明できて、簡単に変更できる、ステートマシン図になります。
サーバーレス データベース
初期のクラウド コンピューティングでは、クラウドでデータベースをホストするには、仮想マシンをプロビジョニングし、MySQL、PostgreSQL、SQL Server などのデータベース製品をインストールする必要がありました。 PaaS によりデータベースがサービスとして提供されることで、これが変わりました。 たとえば、Azure SQL Database や Amazon Relational Database Service (RDS) では、数分かけてインスタンスをプロビジョニングするだけで、クラウドでホストされたデータベース サービスをクライアントに提供できるようになります。 さらに、クラウド サービス プロバイダーにより、ソフトウェア更新プログラムと修正プログラムが適用されて、データベース プラットフォームは最新の状態に維持されます。
クラウド コンピューティングにおけるさらに新しいイノベーションはサーバーレス データベースであり、使用パターンが不規則な単一データベースに最適な、最適化された価格パフォーマンス モデルが提供されます。 たとえば、Azure には、Azure SQL Database のサーバーレス バージョンが用意されています。 Azure SQL Database のメインストリーム バージョンでは、データベースで処理することが予想される最大負荷に基づいて、価格パフォーマンス レベルを選択します。 負荷が "スパイク性" または断続的である場合、データベースの負荷が常に高くなっているかのような支払いになることがよくあります。
サーバーレス バージョンの Azure SQL Database では、発生した負荷を処理するために必要に応じてデータベースをスケーリングすることで、これが軽減されます。また、コストは、コンピューティング コストとストレージ コストを合計したものが基になります。 従量課金モデルを使用するサーバーレス関数と同様に、支払いは使用した分だけです。 Amazon では、Amazon の Aurora データベース サービスのサーバーレス バージョンである AWS Aurora Serverless の形式で、同様のサービスが提供されています。Google では、Google Cloud Firestore と呼ばれるサーバーレスの NoSQL データベース サービスが、顧客に提供されています。
参考資料
- Microsoft (2019)。 Azure Logic Apps で電子メールと添付ファイルの処理を自動化する。 https://learn.microsoft.com/azure/logic-apps/tutorial-process-email-attachments-workflow。