サーバレスとは

サーバーレスはクラウド・ネイティブ環境でより効率的にアプリケーションを構築、展開、利用するためのな方法です。
サーバーレス・コンピューティングは最初の本格的なクラウドネイティブコンピューティングのパラダイムとも云えます。しかしまだ多くのエンジニアは「サーバーレス」が実際に何を意味するかについて、結論を出せていない状況です。

サーバーレスの提唱者であるSimon Wardley氏は以下のように定義しています。

サーバーレスとは、コードを書いてサービスを消費する、イベントドリブンでユーティリティベースのステートレスなコード実行環境である。

RedMonkのRachel Stephens氏は、さらに簡潔な定義をしています。

サーバーレスとは、ゼロまでスケールするマネージドサービスを意味する。

どちらもサーバーレスという新たなパラダイムの最も重要な側面を強調しています。
・開発者はアプリケーション以外は何も管理しません。
・開発者の視点ではインフラの管理は一切ありません。
・プロビジョニングもパッチもありません。
・パッチの適用もありません。
・キャパシティプランニングもしません。
・拡張性も気にしません。
必要なのはコードやマネージドサービスを持ち込むことだけです。
あとはサーバーレスのランタイムがすべての面倒を見てくれます。

以下の表は、サーバーレスと従来のアプローチ（サーバーフル）の違いをまとめたものです。

出典 Cloud Programming Simplified: A Berkeley View on Serverless Computing

これがサーバーレスの運用モデルです。
サーバーレスのワークロードは、特定のアーキテクチャパターンのセットに従うのが一般的です。サーバーレスアプリケーションを構築する開発者は、通常これらの原則に従います。

ファンクションとしてのコード

ファンクションとは以下のようにマイクロサービスの最も純粋な形と考えることができます
・動的に駆動する
・１つの目的の小さなコード
・(通常は)イベントをきっかけに呼び出される(トリガー)
・ステートレス
多くのサーバーレスでは、この機能をFaaS(Functions-as-a-Service)サービスとして提供しています。
FaaSを利用するには、開発者はファンクションのコードを持ってきて、トリガーとなるイベント紐付けます。

「サーバーレス」と「ファンクション」は同じ意味で使われることがあります。
確かにファンクションはサーバーレス・ワークロードのコンピューティング・レイヤーとしてよく使われます。
しかし決して両者は同じものではありません。

サーバレスにファンクションは必須ではありません。
ファンクションを使わずにサーバーレス・アプリケーションを開発することも可能です。

ファンクションにとってもサーバレスは必須ではありません。
サーバーレス・プラットフォームで動作しないファンクションを書くこともできます。

イベント駆動型アーキテクチャ(EDA)

イベント駆動型アーキテクチャ(EDA)とは、イベントに応じてコードが実行されるシステムのことです。
イベントとは下記のような、システムのあらゆる状態の変化が含まれます。
・メッセージ受信
・ファイルアップロード完了
・データベースへのレコード挿入

ファンクションは通常、このようなイベントやデータストリームを扱うことを目的として作られています。だからこそファンクションはEDAに最適なのです。
実際、一般的にFaaSではメッセージブローカーやデータストアなどのコンポーネントが統合されています。開発者はこれらのサービスに関連するイベントに応答するためにファンクションを起動することができます。

マネージドサービスとの接続

ファンクションはステートレスであるため、すべての状態と設定はバックエンド・サービスに存在します。
バックエンド・サービスとしては以下のようなものがあります
・SQLデータベース：MySQL、Postgresなど
・キーヴァリューストア(KVS)：GemFire、Apache Geodeなど
・メッセージキュー：RabbitMQ、IBM MQなど
・認証プロバイダ：LDAP、Active Deirectory、Oktaなど
・APIゲートウェイ：Spring Cloud Gateway、Amazon API Gateway、Azure API Management、Apigee

サーバーレス・アーキテクチャでは、これらのサービスはすべてマネージドサービスとして提供される必要があります。
開発者がコードを実行するために必要なインフラを管理しない以上、関連するサービスをサポートするために必要なインフラについても心配する必要をなくすべきです。
開発者は機能を「グルーコード」として、マネージドサービス同士を接続するので、インフラについて考える必要はどこにもありません。

スケール・トゥー・ゼロ（Scale-to-zero/ゼロへのスケール）

Scale-to-Zero はサーバーレスの重要なコンセプトです。
サーバーレスではリソースは使用されるときにのみ消費されます。
サーバーレスのランタイムは、負荷の増加に対応するために自動的にスケールアウトします。
ランタイムは、同様にファンクションが使用されていないときには、使用リソースがゼロとなるようにスケールダウンします。
その後に次のリクエストが来ると、ランタイムは最初のリクエストに応じてすぐさま立ち上がることができるようになっています。
パブリッククラウドのサーバーレス製品では、お客様は機能が稼働している間のみ課金されます。

サーバーレスが重要な理由

Joe Emison氏が指摘するように、サーバーレスは「何を最適化したいか」に応じてさまざまな形でビジネスに貢献します。
例えば、コンピュートコストを全体的に削減したいと考えている場合。
また市場投入までの時間を短縮したいと考えている場合もあるでしょう。
サーバーレス・アーキテクチャは、適切に実行されれば、ソフトウェア開発と保守性の最適化に役立つ多くのメリットをもたらします。

新たに書くコード量を削減

FaaSモデルは、開発者ができるだけ少ないコードを書けるようにすることを目指しています。
狭い範囲のコードユニットを書くことで、ビジネスロジックを書くことに集中しやすくなります。
サーバーレス・プラットフォームは、パッケージング、デプロイメント、イベント消費の複雑さを抽象化します。
これにより開発者は複雑な統合や定型的なコードに煩わされることがなくなります。

コードが少ないことには多くのメリットがあります。
複雑さが減ればバグも減ります。
攻撃対象が小さくなり、コードセキュリティが向上します。
そしてコードが少ないということは、技術的負債が少ないということでもあり、長期的なメンテナンスが容易になります。
つまりサーバレスはレガシーアプリケーションを発生しづらくします。

使用量に応じた支払い

サーバーレス・アーキテクチャが実現するスケール・トゥ・ゼロにより、必要なときに必要な分だけのリソースだけを使用することができます。
これはパブリック・クラウドでは、使用した分だけ支払うことを意味します。
つまりクラウドの通常の割り当てモデルより利用者が理解しやすく、満足度の高い請求を実現します。

通常の仮想マシンによる仕組みでは、実際にファンクションが消費するかしないかにかかわらず、割り当てられたコンピュートやメモリの量に対して料金を支払います。

サーバーレスモデルでは、使用されていない場合は料金を支払う必要はありません。
使用量が予測できない、特にバースト的なワークロードの場合、これは非常に費用対効果が高いことがわかります。

より早いアプリケーションの提供

ユーザはアプリケーションをできるだけ早く市場に投入する方法を常に模索しています。
サーバーレス技術は、これまでになく迅速なアプリケーション提供を実現します。
開発者はファンクションを活用し、マネージドサービスとして提供される機能をシステムとしてつなぎ合わせることができます。
ゼロから構築する必要はありません。
カスタムコンポーネントの配線を気にする必要もありません。
ルーティング、DNS、ロードバランシング、ファイアウォールのルールなどもサーバーレスで処理できます。
サーバーレスのランタイムがこれらの面倒な作業をすべて処理します
これによりシステムの導入が非常に簡単にすることができます。

自ら構築したものだけを管理

サーバーレスのワークロードは、ほとんどがマネージドサービスに依存します。
つまりチームはチーム自身が構築したものだけに責任を負えばいいのです。
つまりファンクションとして自らが実装したコードだけで責任を負います。
Day 2と呼ばれる運用タスクは、従来のサーバーベースのモデルとは異なります。
チームは低レベルな実装の詳細に対処する必要はありません。

ビジネスの成果に集中

サーバーレス・アーキテクチャではビジネスロジックを書くことに重点が置かれます。
これにより開発者がビジネス上の課題解決に専念できるようにします。
つまり組織はテクノロジーを管理するのではなく、これらの成果に集中することができるのです。
これはクラウドネイティブモデルの純粋な実現であり、基盤となるインフラの複雑さは抽象化されます。

サーバーレス導入検討時の留意点

サーバーレスは強力なアイデアです。
あなたの組織で多くの有望な機能を実現することができます。
ただしソフトウェアについての考え方も、これまでとは異なります。
サーバーレスの道を突き進む前に、以下のことを考慮してください。

サーバーレスは新たな分野

人気が高まっているとはいえ、サーバーレスはまだ初期の段階にあります。
この分野はまだ始まったばかりで、新しいフレームワークが日々登場し、パターンも常に進化しています。
Knativeのようないくつかのプロジェクトは人気を博し始めています。
しかし業界が標準に落ち着くまでには、さらなる時間が必要です。
特に企業にとってはサーバーレスの確実な選択肢がどこにあるのか、まだ明確ではありません。
不確実性が高く、変化の可能性を認識しておくことが重要です。

新しいスキルセットが必要かもしれない

サーバーレス・アーキテクチャを採用したアプリケーションを構築することは、根本的な変化をもたらします。
他の新しいテクノロジーと同様に、学習曲線があり、開発者はサーバーレスで作業する際に、新しい種類の課題に直面します。
イベント駆動型のパターンや非同期操作など、新しい概念を習得しなければならない人もいます。
チームは採用するマネージドサービスに精通しなければなりません。
サーバーレスの機能は、既存のプロセスでは監視やデバッグが難しい場合があります。
ローカルでコードをテストするのも難しい場合があります。
開発者はこのような状況下で新たなツール群に適応する必要があります。

一部の企業は、サーバーレスをクラウドへの道として期待しています。
しかし既存の仮想マシンを前提としたアプリケーションをサーバーレス・アーキテクチャへリフト＆シフトできる可能性はありません。
より大規模なアプリケーションの変更作業が必要になります。
我々の経験則では、マイクロサービスへの対応ができていなければ、サーバーレスへの対応もできていないと言えます。

すべてのワークロードがサーバーレスに適しているわけではない

多くの利点がありますが、サーバーレス・アーキテクチャがすべてのワークロードに適しているわけではありません。
サーバーレスモデルで実行できるアプリケーションには制限があります。
カリフォルニア大学バークレー校の論文が既存のサーバーレス・ソリューションの制約を具体的に指摘しています。
例えば非常に大規模なデータセットに依存するシステムは、FaaSプラットフォームとは必ずしもうまくいかないことが指摘されています。

サーバーレス技術は、今後もサポートするシナリオの種類を増やしていくでしょう。
しかし今のところ、サーバーレスはクラウドネイティブ・ツールボックスの中の1つに過ぎません。
アプリケーションがサーバーレスのコンテキストでうまく機能しない場合は、アプリケーション・プラットフォームやContainer as a Service / Kubernetes as a Serviceのような他の抽象的なサービスを検討する必要があります。

パフォーマンスへの考慮

パフォーマンスを気にするのであれば、それに応じた計画が必要です。
使用した分だけ支払うモデルは魅力的に見えます。
しかしメリットだけがあるわけではありません。

例えば機能がゼロになっても、何かのきっかけですぐに起動できるようにしておく必要があります。
最初のリクエストに対するために必要な時間を「コールドスタート」と呼バレます。
コールドスタートに対するパフォーマンスの低下は、コード、選択したサーバーレス・ランタイム、ユースケースに応じて大きくなる可能性があります。
起動時間やネットワークのレイテンシーも忘れずに考慮する必要があります。
また隣接するマネージドサービスに関連する追加料金にも注意が必要です。
通信料や接続コストを抑えるために、データを一括して送受信することが必要かもしれません。
サーバーレスのやり方を間違えると、コストがかかる可能性もあります。

新しいアーキテクチャを採用するときは、現実的に考えることが必要です。
テクノロジーだけでなく、それに付随する文化や実践がなければ十分とは言えません。
サーバーレスを使って、レガシーなデータサービスをつなげようとしてはいけません。
クラウドネイティブサービスのAPIを使用していない場合、持続的な接続に関する問題が発生する可能性があります。
長時間実行する関数は避け、依存関係が多すぎる関数は書かないようにする必要があります。
マイクロサービスと同様に、サーバーレスのやり方を間違えると、有害な結果となり、さらにコストがかかることになります。

マネージドサービスの選択は慎重に

サーバーレスを用いたい場合「カスタムコードではなく、カスタムリサーチを推奨」とジョー・エミソンは言います。
サーバーレス・アプリケーションに基づくコーディングよりも調査・学習に時間を費やすことになるかもしれません。
それは開発者がカスタムコードではなく、マネージドサービスに頼るからです。
開発者はしばしば、ID管理、データベース、メッセージングキュー、APIゲートウェイ、モバイル通知などのソリューションを決める必要があります。

マネージドサービスの選択肢は増え続けています。
その中から適切なものを選び、アプリケーションと適切に統合しなければいけません。
間違った選択をすると、そもそもサーバーレスを使うことで避けようとしている技術的負債が発生してしまいます。

VMware によるサーバーレス

VMwareはGoogleをはじめとする業界のリーダーと提携し、Knativeを開発し、これをベースにしたサーバーレス・ランタイム「Cloud Native Runtimes for VMware Tanzu」の提供を開始しましたました。
Cloud Native RuntimesはKubernetesにサービングとイベントのランタイムを提供します。
つまりKnativeはファンクションやイベントだけでなく、マイクロサービスの実行にも有効です。

いくつかのVMwareのお客様は、既にサーバーレス・アーキテクチャに基づくイベントドリブンなパラダイムを使用しています。
Spring Cloud Data Flowを使えば、開発者はSpring BootとSpring Cloud Streamを使って、柔軟なデータ統合とリアルタイムのデータ処理パイプラインを構築できます。
またSpring Cloud Functionはクラウドにまたがるサーバーレス・プロバイダーでSpring Bootの機能を活用するための優れた方法です。

今日の多くのテクノロジーがサーバーレスを新たなレベルに引き上げます。
そしてVMwareは長きにわたり、その基本原則を支持してきました。
VMware Tanzu Application Serviceは、開発者のワークフローを簡素化し、基盤となるインフラを隠蔽、開発者はコードを入力するだけで、あとはプラットフォームが処理してくれます。
またOpen Service Broker APIを使用することで、アプリケーションがマネージドサービスを容易に利用可能にしています。

夢のようなこの世界を既に実際に実現したいと感じたならばVMware Tanzuの世界へ飛び込んでください。
そこには、あなたの知る VMware とは全く違った世界が広がっています。

原文