サーバーレス コンピューティングにより開発が容易になり、運用コストが削減される理由

エンタープライズ開発者は通常、ビジネス上の問題を解決するためにコードの作成に多くの時間を費やします。その後、運用チームは、まず開発者が作成したコードを利用可能なコンピューターで実行し、それらのコンピューターがスムーズに動作することを確認する方法を考えるのに多くの時間を費やしました。そして、これは終わりのない仕事のように思えます。他の人にそれをやらせてみてはどうでしょうか?

[[270041]]

過去 20 年間、IT における多くのイノベーション (仮想マシン、クラウド コンピューティング、コンテナーなど) は、企業がコードを実行する基盤となる物理マシンについてあまり考えなくてもよいようにすることに重点が置かれてきました。サーバーレス コンピューティングは、この要望を論理的な結論に導く、ますます人気の高いモデルです。サーバーレス コンピューティングでは、サービス プロバイダーがすべてを処理するため、企業はコードが実行されるハードウェアやオペレーティング システムについて何も知る必要がありません。

サーバーレス コンピューティングとは何ですか?

サーバーレス コンピューティングは、クラウド コンピューティング プロバイダーが特定のコードを実行するために必要なコンピューティング リソースとストレージを動的に割り当て、その分だけユーザーに課金するクラウド コンピューティングの実行モデルです。もちろん、サーバーは依然として関係しますが、そのプロビジョニングとメンテナンスは完全にプロバイダーの責任となります。 Amazon のサーバーレス推進者である Chris Munns 氏は、2017 年のカンファレンスで次のように述べています。「コードを記述してデプロイするチームの観点から見ると、管理または構成するサーバーはまったくありません。これには、ベアメタル、仮想、コンテナー、ホストの管理、ホストへのパッチ適用、OS レベルでの処理など、サーバーレスの世界では実行する必要のない作業が含まれます。」

開発者の Mike Roberts 氏の説明によると、この用語はかつて、モバイル アプリが完全にクラウドでホストされているバックエンド サーバーに接続する、いわゆる「サービスとしてのバックエンド」のシナリオで使用されていました。しかし現在、サーバーレス コンピューティングやサーバーレス アーキテクチャについて話す場合、顧客がビジネス ロジックを解決するだけのコードを記述し、それをプロバイダーにアップロードする「サービスとしての機能」を意味します。プロバイダーは、すべてのハードウェア構成、仮想マシンとコンテナの管理、さらにはアプリケーション コードに通常組み込まれているマルチスレッドなどのタスクも処理します。

サーバーレス関数はイベント駆動型であるため、リクエストによってトリガーされたときにのみコードが呼び出されます。プロバイダーは、物理サーバーまたは仮想サーバーの維持にかかる固定月額料金ではなく、その実行に使用されたコンピューティング時間に対してのみ料金を請求します。これらの関数は、相互に接続して処理パイプラインを作成したり、コンテナーまたは従来のサーバー上で実行されている他のコードと対話する、より大規模なアプリケーションのコンポーネントとして使用したりできます。

サーバーレスコンピューティングの利点と欠点

この説明から、サーバーレス コンピューティングの 2 つの最大の利点が明らかになります。開発者は、インフラストラクチャの問題ではなく、記述したコードのビジネス目標に集中できます。組織は、物理的なハードウェアを購入したり、ほとんど使用されていないクラウド コンピューティング インスタンスをレンタルしたりするのではなく、実際に使用するコンピューティング リソースに対してのみ、非常に具体的な料金を支払います。

業界の専門家である Bernard Golden 氏が指摘するように、これはイベント駆動型アプリケーションにとって特に有益です。たとえば、企業には、ほとんどの時間アイドル状態になっているアプリケーションがあるかもしれませんが、特定の条件下では、多数のイベント要求を同時に処理する必要があります。あるいは、企業には、グローバル インターネット接続が制限されているか断続的な IoT デバイスから送信されたデータを処理するアプリケーションがあるかもしれません。どちらの場合も、従来のアプローチでは、ピーク時のワークロードを処理できる強力なサーバーをプロビジョニングする必要がありますが、サーバーはほとんどの場合十分に活用されていません。サーバーレス アーキテクチャでは、企業は実際に使用したサーバー リソースに対してのみ料金を支払います。サーバーレス コンピューティングは、特定の種類のバッチ処理にも適しています。サーバーレス アーキテクチャのユースケースの標準的な例の 1 つは、一連の個別の画像ファイルをアップロードして処理し、アプリケーションの別の部分に送信するサービスです。

おそらく、サーバーレス関数の最も明らかな欠点は、一時的なものであり、長期的なタスクには適していないことです。ほとんどのサーバーレス プロバイダーでは、コードを数分以上実行することは許可されず、関数を開始すると、以前に実行されていたインスタンスの状態データは保持されません。関連する問題として、サーバーレス コードの起動には数秒かかることがあります。これは多くのユースケースでは問題になりませんが、アプリケーションで低レイテンシが求められる場合には注意が必要です。

Rohit Akiwatkar 氏と Gary Arora 氏が指摘しているように、その他の多くの欠点はベンダー ロックインに関連しています。オープンソースのオプションも利用可能ですが、サーバーレス市場は大規模な商用クラウド コンピューティング プロバイダーによって支配されています。これについては後ほど説明します。つまり、開発者はベンダーが提供するツールを使い続けることになり、不満が生じた場合に切り替えるのが難しくなります。また、サーバーレス コンピューティングの多くはベンダーのインフラストラクチャ上で行われるため、サーバーレス コードを社内の開発およびテスト パイプラインに統合することが困難になる可能性があります。

サーバーレスベンダー: AWS Lambda、Azure Functions、Google Cloud Functions

サーバーレス コンピューティングの現代は、Amazon のクラウドベース サービスである AWS Lambda のリリースとともに 2014 年に始まりました。 Microsoft は 2016 年に Azure Functions をリリースしました。2017 年からベータ版となっていた Google Cloud Functions が、ついに製品版に到達しました。これら 3 つのサービスには、制限、長所、サポートされる言語、実行方法が若干異なります。 Rohit Akiwatkar 氏が、3 つの違いについて詳しく説明しています。また、オープンソースの Apache OpenWhisk プラットフォームをベースとする IBM Cloud Functions も候補に挙がっています。

すべてのサーバーレス コンピューティング プラットフォームの中で、AWS Lambda は最も有名であり、明らかに開発と成熟に多くの時間を費やしてきました。業界メディアは、過去 1 年間に AWS Lambda に追加されたアップデートと新機能について報道してきました。

サーバーレススタック

ソフトウェアの多くの分野と同様に、サーバーレスの世界では、サーバーレス アプリケーションの構築に必要なさまざまなコンポーネントをスタックするソフトウェア スタックが開発されてきました。各スタックは、企業がコードを記述するプログラミング言語、企業コードの構造を提供するアプリケーション フレームワーク、およびプラットフォームが理解してコードの実行を開始するために使用する一連のトリガーで構成されます。

これらのカテゴリ内で特定の製品を組み合わせることはできますが、使用するベンダーによっては制限や重複が発生する場合があります。たとえば、言語については、企業は AWS Lambda で Node.js、Java、Go、C#、Python を使用できますが、Azure では JavaScript、C#、F# のみが動作します。 AWS Lambda にはトリガーに関してより多くの機能がありますが、その多くは Amazon Simple Email Service や AWS CodeCommit など AWS プラットフォームに固有のものです。一方、Google Cloud Functions は一般的な HTTP リクエストによってトリガーできます。業界の専門家 Paul Jaworski が、3 つの主要製品のスタックを詳細に解説します。

サーバーレスフレームワーク

この式のフレームワーク部分は、アプリケーションが最終的にどのように構築されるかを適切に定義します。 Amazon には独自のネイティブ製品であるオープンソースの Serverless Application Model (SAM) がありますが、他にも多くの製品があり、そのほとんどはクロスプラットフォームでオープンソースです。これらの中で最も目立つのはサーバーレスであり、AWS Lambda、Azure Functions、Google Cloud Functions、IBM OpenWhisk など、サポートされているすべてのプラットフォームで同じエクスペリエンスを提供することを強調しています。もう一つの人気製品は Apex で、特定の言語を扱う特定のプロバイダーに役立ちます。

サーバーレスデータベース

前述のように、サーバーレス コードを使用する際の癖の 1 つは、永続的な状態が存在しないことです。つまり、ローカル変数の値はインスタンス化を超えて保持されません。コードがアクセスする必要がある永続データは他の場所に保存する必要があり、主要ベンダーのスタックで利用可能なトリガーにはすべて、関数が対話できるデータベースが含まれています。

これらのデータベースの一部はサーバーレスと呼ばれます。つまり、データの永続的な保存という明らかな例外を除けば、この記事で説明した他のサーバーレス関数と非常によく似た動作をするということです。しかし、データベースの構成と保守に伴う管理オーバーヘッドの多くは見過ごされてきました。開発者の Jeremy Daly 氏は、「クラスターをプロビジョニングするだけで、メンテナンス、パッチ適用、バックアップ、レプリケーション、スケーリングはすべて自動的に処理されます」と述べています。 Function as a Service の提供と同様に、実際に使用したコンピューティング時間に対してのみ料金を支払い、需要に応じてリソースが拡大または縮小されます。

3 大サーバーレスプロバイダーはそれぞれ独自のサーバーレスデータベースを提供しています。Amazon には Aurora Serverless と DynamoDB、Microsoft には Azure Cosmos データベース、Google には Cloud Firestore があります。しかし、利用できるデータベースはこれだけではありません。 Nemanja Novkovic がさらに詳しい製品情報を提供します。

サーバーレスコンピューティングとKubernetes

コンテナはサーバーレス テクノロジーの強化に役立ちますが、コンテナの管理にかかるオーバーヘッドはベンダーの責任であるため、ユーザーには見えません。多くの人は、サーバーレス コンピューティングを、コンテナ化されたマイクロサービスの複雑さに対処することなく、そのメリットの多くを享受できる方法と見ており、ポストコンテナの世界について語り始めています。

実際には、コンテナとサーバーレス コンピューティングは今後何年も共存することはほぼ確実であり、実際にサーバーレス関数はコンテナ化されたマイクロサービスと同じアプリケーション内に存在する可能性があります。 Kubernetes は、サーバーレス インフラストラクチャも管理できる主要なコンテナ オーケストレーション プラットフォームです。実際、Kubernetes を使用すると、企業はさまざまな種類のサービスを単一のクラスターに統合できます。

オフラインのサーバーはありません

企業にとって、サーバーレス コンピューティングの導入は、始めるためにベンダーにサインアップしてその仕組みを理解する必要があるように思われるため、少し気が重いかもしれません。しかし、心配しないでください。自分のローカル ハードウェア上でサーバーレス コードをオフラインで実行する方法があります。たとえば、AWS SAM は、企業が Lambda コードをオフラインでテストできるローカル機能を提供します。 Serverless Application Framework を使用している場合は、コードをローカルで実行できるプラグインである Serverless Application Framework Offline をチェックしてみてください。