キッチンレスレストラン、サーバーレスコンピューティング

午前3時に、コンピューター室のサーバーが再びダウンしました。これらのサーバーの復元には数時間、数日、あるいはそれ以上かかる場合があり、その後システムを更新してセキュリティの脆弱性を修正する必要があります。アップデートにより新たな非互換性が生じ、業務運営に影響を及ぼします。それは「悪循環」のようです。

[[261128]]

この時点で、「サーバーレス」の魅力を理解する必要があるかもしれません。サーバーによって引き起こされる終わりのないトラブルは、「サーバーレス」アーキテクチャが普及している重要な理由の 1 つです。上司は、サーバー障害を言い訳にして業務に影響を及ぼすことを必ずしも容認しません。 「サーバーレス」により、こうした悩みから解放されます。

「サーバーレス」とは何ですか?

多くの初心者にとって、「サーバーレス」という言葉を聞くと、間違いなく非常に衝撃を受けるでしょう。サーバーレス？では、コンピューティングをどのように提供するのでしょうか?実際、いわゆるサーバーレスとは​​、サーバーが存在しないという意味ではなく、すべてをクラウド プロバイダーが処理することを意味します。インフラストラクチャの障害によって業務運営が影響を受けることを心配する必要がなくなりました。

サーバーレス サービス モデルでは、開発者は適切なコードをデプロイするだけで、他のすべてをサーバーレスに任せることができます。ただし、サーバーレス サービスは使用できますが、所有したり管理したりすることはできないことに注意してください。クラウド モデルと同様に、使用量に基づいてのみ料金を支払います。

サーバーレスは魅力的なセールス用語ですが、厳密に言えば、アプリケーションがサーバーレスであると言うのは正確ではありません。例えるなら、サーバーレスはキッチンのないレストランのようなものです。メニューにある標準的な料理をご希望の場合は、共有のシェフが、優れたスピード、サービス、味で調理いたします。注文する食べ物の量に応じて価格も決まります。これは間違いなく、一部の人々にとって素晴らしい選択です。

しかし、メニューに載っていない特製料理をご希望の場合は、必ずご自身のキッチンをご利用ください。サーバーレスの利点は、サーバーの購入、構成、展開、運用にかかる労力と時間を節約し、必要な最適な環境を提供できることです。しかし、特別なニーズがある場合、サーバーレスは適切な選択ではない可能性があります。

サーバーレスはどのように機能しますか?

サーバーレスの定義を紹介したので、サーバーレスがどのように機能するかを見てみましょう。従来の IT サービスの場合、独自のインフラストラクチャを用意する必要があり、また、これらのインフラストラクチャの安定性、拡張性、セキュリティなどの要件も確保する必要があります。たとえば、Web サーバーはクライアントからの要求に対して「応答」で応答します。トラフィックが大きすぎる場合は、サーバーを拡張する必要があります。

クラウド時代では、クラウド サーバー調達モデルにより、ユーザーは物理サーバーを購入する事前のプロセスを省くことができます。ビジネスをサポートするためにクラウド サービスを購入することができますが、クラウド サーバーを購入する際には、負荷分散、サーバー システムの構成、セキュリティ ポリシーなども考慮する必要があります。まだ大きな問題が残っています。

サーバーレス モデルは、従来のモデルとはまったく異なるアプローチを提供します。サーバーやクラウド サーバーを購入する必要はありません。サーバーレスは、ビジネス アプリケーション用に展開されたシステムと同様に、さまざまな一般的な要件を標準モードで展開し、コンピューティング コンテナーで実行します。コードを入力するだけで、リアルタイムで自動的に処理されます。リクエストが来ると、サーバーレス システムで自動的に実行されます。

サーバーレスは、アプリケーションの負荷とサーバー要求に基づいて、数秒でスケールアップまたはスケールダウンします。現在の状況を理解し、増大するインフラストラクチャのニーズに合わせて調整します。つまり、サーバーレス コンピューティングは柔軟なイベント駆動型のスケーラビリティを備えています。また、「従量課金制」モデルで運営されています。インフラの購入にかかる時間を節約できるだけでなく、開発コストも大幅に削減できます。

サーバーレス アーキテクチャにより、アプリケーション リソースをより適切に共有できるようになります。以前は、人々は自分の仮想マシンで Ubuntu Server を実行するなど、新しいアプリケーション インスタンスを必死に作成していました。全員が同じオペレーティング システムを使用しており、Ubuntu システム内のさまざまな仮想マシンで同じ要件が何百回、何千回も繰り返されていました。サーバーレスは、こうした作業の重複をすべて回避し、クラウド コンピューティングを安価にします。特に、時々実行され、実際には高い負荷要件がないエンタープライズ インフラストラクチャ プラットフォームの場合、人的資源と物的リソースを大幅に節約できます。

サーバーレスの長所と短所

サーバーレスには多くの利点があり、そのいくつかは上で説明しました。たとえば、ユーザーの運用コストを削減できます。サーバーレス自体は、要件ごとに専用のアプリケーション環境を構築する必要がなく、ユーザーが直接使用できるソリューションに相当します。また、トラフィックに基づく支払いモデルも採用しており、常に変化する初期のアプリケーション負荷要件に対して特に運用コストを大幅に削減できます。

同時に、サーバーレス システムはよりスケーラブルであり、この拡張を計算する必要がありません。代わりに、アプリケーションが認識することなく、ビジネス ニーズに基づいて数秒以内にニーズを自動的に拡張できます。ニーズが減少すると、リソース要件も自動的に削減されるため、追加コストを支払う必要はありません。ビジネス ニーズを満たすために必要なプロセッサの数を考える必要すらなく、ニーズに応じて自動的に拡張されます。

もちろん、サーバーレスは完璧ではありません。サーバーは第三者によって運営・保守されているため、ユーザーは制御できません。プロバイダー システムのダウンタイム、機能の損失、必須のアップグレードなどの理由により、ユーザーはシステムを制御できなくなり、その結果、ビジネス オペレーションを制御できなくなる可能性があります。さらに、サーバーレス モデルでは、長時間実行されるアプリケーションは必要ありません。長期にわたってサーバーレスを導入するコストは、実は非常に高くなります。プロセスが長時間実行され続ける場合は、独自のサーバーを実行する必要がある場合があります。

上記の 2 つの点に加えて、ユーザーはサーバーレスのベンダー ロックインも気にする場合があります。サーバーレスの開発はまだ初期段階であるため、ベンダーごとに標準アーキテクチャが異なります。これにより、ベンダー ロックインが発生しやすくなり、変更が困難になります。このベンダーで実現できる機能は、別のベンダーに移行すると実現できない可能性があります。移行できたとしても、プロセスが非常に複雑になる可能性があります。

現在、多くのパブリッククラウドプロバイダーはサーバーレスサービスに非常に楽観的であり、関連サーバーを立ち上げています。たとえば、Amazon がリリースした AWS Lambda、Microsoft がリリースした Azure Functions、Google CloudFunctions はすべてサーバーレス サービスを提供できます。さらに、IBM OpenWhisk や Alibaba Cloud も同様のサービスを提供できます。現時点では、サーバーレスはまだ限界があり、主流にはなっていませんが、革新的な技術や新機能の登場により、将来的には主流のコンピューティング手法の 1 つになる可能性があります。