サーバーレス: サーバーレスとは​​何か、なぜ違うのか

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

開発者コミュニティでサーバーレスに関する最近の誇大宣伝を目にしたことがあるかもしれません。 それで、それは正確には何ですか？ つまり、コードはまだ適切な場所で実行する必要があるということですが、実際にサーバーレスとは​​どのようなものでしょうか?

つまり、開発者と運用チームは、実際のサーバーを監視、管理、または気にする必要さえありません。 これはクラウド コンピューティングと非常に似ているように聞こえるかもしれませんが、いくつかの重要な違いがあります。 そして、これらの違いは主に、他のモデルと比べてあなたが知らないことにあります。

不明なオペレーティング システム!?!?

サーバーレスを Kubernetes のような洗練されたクラウド オーケストレーションと区別する簡単な方法の 1 つは、コードを実行するサーバーがどのオペレーティング システムを使用しているかを社内の誰も知らないことです。 .Net コードを実行しているので Windows である、または Ruby であるために Linux であると信じているかもしれませんが、最終的には確信が持てず、開発には何の影響もありません。

サーバーレス プロバイダーがサポートする言語を使用してコードを記述できます。提供されるボックスの範囲内にとどまっている限り、その機能を提供するオペレーティング システムやバージョンなどの知識がなくても問題ありません。

実際、サーバーレスの強みの 1 つは、いつでもアプリケーションが複数の異なるオペレーティング システムで実行されている可能性があることです。 これらはすべて、プロバイダーによって管理および運用されます。

トラフィックを処理するために必要なサーバーの数は?

この質問に X サーバー程度の推測で答えられる場合、または Y CPU が必要な場合は、サーバーレス開発を行っていません。

サーバーレス契約は、アプリケーションを強化するために必要なコンピューティングの数と強度が、開発者にとって何の関心事でもないことを意味します。 課金されないという意味ではなく、あなたやあなたのチームが管理したり気にかけたりするものではないというだけです。 優れたプロバイダーは、高可用性と応答性を維持するためにサービスを自動的に管理します。

コンピューティング、ストレージ、ネットワークに基づく請求モデル。 サーバー、CPU、ハードドライブではありません

アプリケーションの下で実際に実行されているハードウェアがどのように認識されていないかを見て、新しい請求方法がそれに伴い発生します。 サーバーレス クラウド プラットフォーム プロバイダーは、コンピューティング、ストレージ、およびネットワーク転送の従量制使用に対して課金します。 これは、CPU、ディスク ドライブ、およびネットワーク接続によって課金される他の課金モデルに取って代わります。 サーバーレスの世界では、彼らはその部分を管理しており、アプリでの正確な使用量に対してのみ請求されます.

これにより、コンピューティングは電気のモデルに非常に近くなります。 電力会社は、従量制の電気使用量である KWH で請求します。 電力自体は、石炭、原子力、ガスなどによって生み出されます。 ただし、ソースに関係なく、課金は同じように計測されます。

ゼロでアイドル

サーバーレスのもう 1 つの大きな変更点は、アプリが使用されていない場合、自動的にゼロにスケーリングされることです。 CPU ではなく計算を使用して請求されるため、使用していないときの請求はゼロです。

プロバイダーは、必要に応じていつでも計算を計測する準備ができていますが、サーバーが使用されたときに備えてサーバーに料金を支払う必要はありません。 これは、アプリの実行中に実際に消費された計算の 1 秒に対して支払う計算です。

食料品店のようなものと考えることができます。 のどが渇いたお客様が店内に立ち寄り、牛乳を購入して飲んで帰ることができるように、店に牛乳をストックしておくのが彼らの仕事です。 牛乳が必要になる前に支払う必要はありません。また、誰も購入しなかったために腐った牛乳を持っていても、支払う必要はありません。 食料品店の仕事は、過剰在庫や腐った牛乳を無駄にしないように注意しながら、利用可能な在庫があることを確認することだけです. あなたが知っているのは、彼らがあなたが望むときにあなたが望むものを持っているということだけです.残りはあなたの懸念から離れて単純化されています.

サーバーレスのトレードオフ

したがって、この単純化はすべて非常にうまく聞こえます。 請求の簡素化、運用上の責任の軽減、スケーリングの容易さなど、これらすべてを必要としないのはなぜでしょうか。 すべてのことと同様に、これにはいくつかのトレードオフがあります。 それでは、それらについて話しましょう。

オペレーティング システムのロックインをクラウド プロバイダーのロックインに置き換える

他のモデルでは、コードを実行するオペレーティング システムやサーバーが原因で、さまざまなトレードオフや制限がありました。 サーバーレス フレームワークがこの責任をプロバイダーにオフロードするようになったので、従わなければならない新しい制約があります。

現在のところ、サービス プロバイダー間の制約と保証を定義する、合意された一連の標準はありません。 これは、たとえばアプリケーションを Windows から Linux に移行することがかつてどれほど困難であったかと同様であることを意味します。 サーバーレス アプリを Google のクラウドから Amazon のクラウドに移行しようとすると、この問題に直面することになります。

これらの企業は、顧客がサーバーレス ワークロードを企業間で簡単に移動できるようにするための共通のフレームワークをまだ提供していません。 そして率直に言って、彼らはあなたを彼らの提供物にできるだけ閉じ込めたいと思っているので、今それをすることは彼らの最善の利益ではありません. そのため、初期のサーバーレス製品には独自の問題が多く、そこから抜け出すのが難しいことを十分に認識しておく必要があります。

パフォーマンスとコストの可視性の低下

コードのパフォーマンスを詳しく調べるためのツールは、以前のプログラミング モデルで十分に確立されています。 特定のプログラムが使用している CPU や RAM の量を把握するなどの作業は、すべて一般的です。

サーバーレス モデルでは、コードが使用する計算、ネットワーク、および API 呼び出しの量に応じて最適化が変わります。 公平を期すために、これらは過去の CPU と RAM に関連しています。 しかし、それらがさらに抽象化されると、これらのツールの有用性が妨げられます。

私は、デバッグとパフォーマンス最適化のための新しいオープンソース ツールがこの市場に役立つようになると確信しています。 ただし、サーバーレス アーキテクチャがプロバイダーによってどのように実装されているかをよりよく理解する必要があります。 これは、これらのツールを効果的にするのに十分な詳細なビューを提供できるのはクラウド ベンダーだけであることを意味している可能性があります。 また、リソースを効率的に使用したかどうかに関係なく、それらのリソースに対して料金が請求されるため、リソースの使用を減らすことは彼らの利益にはなりません。

長時間実行されるアプリケーションは最適な場所ではありません

サーバーレスが提供するすべての柔軟性を得るために、通常、アプリケーション開発者はこれらの機能をサービスとして時間ベースで制限します。 これは、コードが最大 1 分の応答時間を持つ Web 要求に応答できるように最適化することを意味します。

これらの固定された最大時間は、プロバイダーがサーバーレスの約束を果たすのに役立ちます。 彼らは、必要に応じて実際の物理 CPU と場所の間でワークロードを移動できることを期待しており、開発チームに機器の障害から自動スケーリングと修復を行うサービスを提供します。 長時間実行されるワークロードは、この仮定を破ります。 実際、これは通常、製品の要件の 1 つとして挙げられています。 コードは X 時間以内に完了するか終了する必要があります。

Web リクエストやモバイル アプリケーション API などの場合、これらの制限は大した問題ではありません。 しかし、ビデオのエンコード、リアルタイム ゲーム サーバーの操作、ビデオ会議ソリューションなどの他のユース ケースでは、これらの制限は実現できません。 多くの場合、サーバーレス リソースを創造的に使用することで、これらの制限を回避して運用できますが、通常は、より多くの費用がかかり、運用がはるかに遅くなるソリューションを押し付けていることになります。 クラウド プロバイダーは、使用量が増えるほどコストがかかるため、喜んでこれを支援します。 そのため、サーバーレスが最適な Web アプリケーションとシステムには必ずサーバーレスを使用してください。