サーバーレスに関して無視できる3つの一般的な考え方

サーバーレスはクラウドの世界で人気急上昇中です。 少なくとも 3 分の 1 (33%) の組織が過去 1 年以内にサーバーレス アプリを導入しました。 （ソース： Digital Ocean 2018年第2四半期開発者調査) CNCF 2018調査の回答者のうち、38%が現在サーバーレスを使用していると回答しました。 さらに 26% が今後 12 か月以内にこのテクノロジーを使用する予定です。

この新興のクラウド オプションは急速に普及しているだけでなく、誤解されることも多く、コストを削減し、価値実現までの時間を短縮し、ベッドで朝食をとれるほどの超自然的な力があると考えられています。 

さらに、それだけでは混乱を招くだけではないと思われるのが、Function as a Service (FaaS) と Serverless の混同です。 これら 2 つは同じではないため、一般的な企業がこの素晴らしい新技術をどのように活用するかについて、別の誤解が生じます。

そこで今日は、過去 6 か月間に顧客やカンファレンスの参加者から繰り返し聞いた 3 つのよくある誤解を打ち破ってみようと思います。 なぜなら、時間をかけて調べる価値があるかどうかを判断する前に、そのテクノロジーが何であるか、また何ではないかを理解する必要があるからです。

まず、サーバーレスと FaaS の違いを明確にしましょう。 

神話: サーバーレス === FaaS

サーバーレスはシステムです。 プラットフォーム。 フレームワーク。 これは、ジャストインタイムの弾力的な実行環境として最もよく説明されます。 サーバーレスは、何らかの分離された環境でオンデマンドで何かを実行することにより、運用上のオーバーヘッドと摩擦を排除することを目指しています。 その分離された環境は通常はコンテナですが、仮想マシンと Web Assembly を使用する製品も存在します。 簡潔にするために、ここでは「コンテナ」を広い意味で 3 つすべてを指すものとして使います。

サーバーレスはイベント駆動型です。 つまり、プロビジョニングと処理は、API リクエストの到着や時計が午後 2 時 7 分になったなどの何らかのトリガーによって開始されます。 これは、自動的に生成されるイベントの場合もあれば、Web アプリのフォームのボタンを押すなどのインタラクティブなイベントの場合もあります。サーバーレス モデルでは、イベントは「コンテナー」内に存在するものの実行を開始します。 

「コンテナ」は、要求された時点でリポジトリからロードされることが多い (コールド スタート) か、すでに待機している (ウォーム スタート) 場合があります。 その「コンテナ」内に存在するものはすべて実行され、実行をトリガーしたシステムに応答を返します。

サーバーレスの背後にあるビジネス モデルは通常、 「コンテナ」の実行中に消費されたリソースに対してのみ料金を支払うというものです。 運用モデルは、環境の運用に関するすべてを図から取り除き、人々に「何か」の構築を心配させるというものです。

それがサーバーレスです。 Function as a Service は、「何か」を「関数」として定義するサーバーレスの具体的な使用法です。 

FaaS を使用すると、マイクロサービスから始まったアプリケーションの分解を、最終的な結論である関数にまで進めることができます。

サーバーレスと Function as a Service には違いがあることを知ることは、次の誤解を解くために重要です。

神話: リファクタリングが必要 

FaaS と Serverless が混同されているため、市場では、Serverless を活用するにはアプリケーションを複合関数にリファクタリングする必要があるという誤った印象を抱く人が多くいます。

サーバーレスでは、アプリケーションをリファクタリングしたり、機能レベルで新しいアプリを設計したりする必要はありません。 サーバーレスでは、あらゆる種類のアプリケーション、プロセス、デーモン、関数を使用して「コンテナ」を簡単に実行できます。 「コンテナ」にパッケージ化され、呼び出すことができる限り、サーバーレス コンテキストで実行できます。

また、サーバーレスを活用して既存のアプリケーション アーキテクチャを拡張 (最新化) する成功した実装も見てきました。 登録、注文処理、その他の非クリティカルパス プロセスのバッチ スタイルおよびアウトオブバンド処理は、従来のアプリケーションを完全にリファクタリングすることなく、サーバーレス モデルで実装できます。 このような目的ですでに外部の API ベースの統合を活用しているアプリケーションでは、Serverless がより適していることがわかります。 既存のクライアント サーバー ベースのアプリケーションでは、サーバーレスを活用するために何らかの変更が必要になることはほぼ確実ですが、完全なリファクタリングに必要なほど大規模な作業ではありません。 

散発的または予測不能に発生する特定のイベントに基づいて、たまにしか実行されないプロセスも、サーバーレスに適しています。 「コンテナ」を常に実行し続けるよりも、定期的に「コンテナ」を起動して何かを実行する方がはるかにコスト効率が高くなります。 これは、パブリック サーバーレスとオンプレミス サーバーレスの両方に当てはまります。

ここで、場所に焦点を当てた 3 番目の神話に移ります。

神話: サーバーレスはオンプレミスでは機能しない

私は、遠く離れた IT 関係者や評論家がこの主張をしているのを聞いたことがあります。 これは、「クラウド」をオンプレミスで実行できないという考えと同じくらい明らかに誤りです。 確かに可能です。Developer Economics の State of the Developer Nationによると、かなりの数の組織がそうしています。

より大規模で、より頻繁に使用されるアプリケーションでも、非常に効率的なスケーリングのメリットを享受でき、高負荷のアプリケーションの特定の部分に対してのみ追加リソースを支払う必要があり、それらをより簡単に識別して最適化できるようになります。 大規模なアプリケーションに対するこの利点は、現在サーバーレス コンピューティングを導入している企業の 17% が自社のデータ センターでソリューションを実行している主な理由であると考えられます。

オンプレミスのサーバーレス実装におけるコスト効率の向上は、スケーラビリティにとどまりません。 同じリソースを再利用し、散発的に使用されるアプリケーション間で共有する機能は重要です。 サーバーレスは、その中核となるイベント駆動型の性質を利用して、アプリケーションや運用機能に付加価値機能を追加する機能も提供します。 サーバーレスの利点は、開発者の日常生活から運用上の摩擦を排除するだけにとどまらないことを理解せずに、オンプレミスでの使用を軽視すべきではありません。 これは確かに恩恵ですが、唯一の利点ではなく、組織がオンプレミスでサーバーレスを実験している唯一の理由でもありません。  

つまり、サーバーレスはオンプレミスで実装可能であり、実際に実装されているというのが現実です。 前述の CNCF 調査では、最も人気のある「インストール可能な」サーバーレス プラットフォームについて詳しく調べています。

• キューブレス（2%から42%に増加）
• Apache OpenWhisk （12%から25%に増加）
• OpenFaas （10%から20%に増加）

他にもたくさんありますが、この技術が加速するにつれて、他のものも必ず増えるでしょう。

サーバーレスと Function as a Service はどちらも、組織が新しいクラウドネイティブ アプリケーションと近代化の取り組みの両方で使用するためにテクノロジーを試行錯誤し、評価するにつれて、驚異的な採用率を誇っています。 よくある誤解を認識して無視することは、テクノロジが組織内のアプリケーションに適しているかどうかを判断するための重要な第一歩です。