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

開発者は、コードに関するビジネス上の問題を解決するために数え切れないほどの時間を費やしています。次に、運用チームは数え切れないほどの時間を費やす番です。まず、開発者が作成して利用可能なコンピューターで実行するコードを取得する方法を理解し、次にそれらのコンピューターがスムーズに動作することを確認します。第二の部分は本当に終わりのない仕事です。その部分を他の人に任せてみませんか?

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

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

サーバーレスコンピューティングはクラウドの実行モデルであり、クラウドプロバイダーは、特定のコードを実行するために必要なコンピューティングリソースとストレージのみを動的に割り当て、ユーザーに課金します。当然、関係するサーバーはまだありますが、それらのプロビジョニングとメンテナンスはプロバイダーによって完全に処理されます。 Amazonのサーバーレスの提唱者であるChrisMunnsは、2017年の会議で、コードの作成と展開の観点から、「管理またはプロビジョニングするサーバーはまったくありません。これには、ベアメタルとなるもの、仮想となるもの、コンテナとなるものは含まれません。ホストの管理、ホストへのパッチ適用、またはオペレーティングシステムレベルでの処理に関連するものはすべて、サーバーレスの世界。」 

開発者のMikeRobertsが説明するように、この用語はかつて、モバイルアプリが完全にクラウドでホストされているバックエンドサーバーに接続する、いわゆるサービスとしてのバックエンドシナリオで使用されていました。しかし、今日、人々がサーバーレスコンピューティング、またはサーバーレスアーキテクチャについて語るときそれらはサービスとしての機能の提供を意味します。このサービスでは、顧客はビジネスロジックにのみ取り組むコードを記述し、それをプロバイダーにアップロードします。そのプロバイダーは、すべてのハードウェアプロビジョニング、仮想マシンとコンテナーの管理、さらにはアプリケーションコードに組み込まれることが多いマルチスレッドなどのタスクも処理します。

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

サーバーレスコンピューティングのメリットとデメリット

その説明から、サーバーレスコンピューティングの最大の利点の2つは明らかです。開発者は、インフラストラクチャの質問ではなく、作成するコードのビジネス目標に集中できます。組織は、物理ハードウェアを購入したり、ほとんどアイドル状態のクラウドインスタンスをレンタルしたりするのではなく、実際に使用するコンピューティングリソースに対して非常にきめ細かい方法でのみ支払います。

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

おそらく、サーバーレス機能の最も明らかな欠点は、それらが意図的に一時的なものであり、AlexSoftが言うように、「長期的なタスクには不適切」であることです。ほとんどのサーバーレスプロバイダーは、コードを数分以上実行させません。関数を起動すると、以前に実行されたインスタンスからのステートフルデータは保持されません。関連する問題は、サーバーレスコードが起動するまでに数秒かかる可能性があることです。多くのユースケースでは問題ありませんが、アプリケーションで低レイテンシが必要な場合は警告が表示されます。

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

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

サーバーレスコンピューティングの現代は、2014年にAmazonのクラウドサービスに基づくプラットフォームであるAWSLambdaの発売から始まりました。Microsoftは2016年にAzureFunctionsに続きました。2017年からベータ版であったGoogleCloud Functionsは、ついに本番環境に到達しました。 3つのサービスには、わずかに異なる制限、利点、サポートされている言語、および処理方法があります。Rohit Akiwatkarは、3つの違いについて詳細に説明しています。また、オープンソースのApacheOpenWhiskプラットフォームに基づくIBMCloudFunctionsも実行されています。

すべてのサーバーレスコンピューティングプラットフォームの中で、AWS Lambdaが最も有名であり、明らかに進化と成熟に最も時間がかかっています。過去1年間にAWSLambdaに追加されたアップデートと新機能をカバーしています。

サーバーレススタック

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

これらの各カテゴリでさまざまな特定の製品を組み合わせて組み合わせることができますが、使用するベンダーによっては制限があり、一部重複しています。たとえば、言語の場合、AWS LambdaでNode.js、Java、Go、C#、Pythonを使用できますが、Azure関数でネイティブに機能するのはJavaScript、C#、F#のみです。トリガーに関しては、AWS Lambdaが最も長いリストを持っていますが、それらの多くは、Amazon Simple EmailServiceやAWSCodeCommitなどのAWSプラットフォームに固有のものです。一方、Google Cloud Functionsは、一般的なHTTPリクエストによってトリガーできます。Paul Jaworskiは、3大製品のそれぞれのスタックを詳しく調べています。

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

方程式のフレームワークの部分について少し長引く価値があります。それは、最終的にアプリケーションを構築する方法について多くを定義するからです。Amazonには独自のネイティブサービスであるオープンソースのサーバーレスアプリケーションモデル(SAM)がありますが、他にもあり、そのほとんどはクロスプラットフォームであり、オープンソースでもあります。最も人気のあるものの1つは、一般的にサーバーレスと呼ばれ、サポートされている各プラットフォーム、つまりAWS Lambda、Azure Functions、Google Cloud Functions、IBMOpenWhiskで同じエクスペリエンスを提供することを強調しています。もう1つの人気のある製品はApexです。これは、特定のプロバイダーでは利用できない言語を争いに巻き込むのに役立ちます。

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

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

これらのデータベースの一部は、それ自体がサーバーレスと呼ばれますこれは、データが無期限に保存されるという明らかな例外を除いて、この記事で説明した他のサーバーレス関数とほとんど同じように動作することを意味します。ただし、データベースのプロビジョニングと保守に関連する管理オーバーヘッドの多くは捨てられます。開発者のJeremyDaly氏は、「クラスターを構成するだけで、すべてのメンテナンス、パッチ適用、バックアップ、レプリケーション、スケーリングが自動的に処理されます」と述べています。サービスとしての機能の提供と同様に、実際に使用する計算時間に対してのみ料金を支払い、需要に合わせて必要に応じてリソースを上下に回転させます。

3大サーバーレスプロバイダーはそれぞれ独自のサーバーレスデータベースを提供しています。AmazonにはAuroraServerlessとDynamoDBがあり、MicrosoftにはAzure Cosmos DBがあり、GoogleにはCloudFirestoreがあります。ただし、利用可能なデータベースはこれらだけではありません。Nemanja Novkovicには、その他の製品に関する情報があります。

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

コンテナーは、内部でサーバーレステクノロジーを強化するのに役立ちますが、コンテナーを管理するオーバーヘッドはベンダーによって処理されるため、ユーザーには見えません。多くの人は、サーバーレスコンピューティングを、コンテナ化されたマイクロサービスの複雑さに対処することなく多くの利点を得る方法と見なしており、コンテナ後の世界についても話し始めています。

実際、コンテナとサーバーレスコンピューティングは、今後何年にもわたってほぼ確実に共存します。実際、サーバーレス機能は、コンテナ化されたマイクロサービスと同じアプリケーションに存在する可能性があります。最も人気のあるコンテナオーケストレーションプラットフォームであるKubernetesは、サーバーレスインフラストラクチャも管理できます。実際、Kubernetesを使用すると、さまざまなタイプのサービスを1つのクラスターに統合できます。  

サーバーレスオフライン

サーバーレスコンピューティングを開始する可能性は少し怖いかもしれません。ベンダーにサインアップして、それがどのように機能するかを確認する必要があるように思われるからです。ただし、恐れることはありません。サーバーレスコードを独自のローカルハードウェアでオフラインで実行する方法があります。たとえば、AWS SAMは、Lambdaコードをオフラインでテストできるローカル機能を提供します。また、サーバーレスアプリケーションフレームワークを使用している場合は、コードをローカルで実行できるプラグインであるserverless-offlineを確認してください。幸せな実験!