サーバーレス コンピューティング: クラウドにおける次の大きな混乱に備える

Braze は大量のクラウド インフラストラクチャを使用して、1 日あたり 15 億件を超えるメッセージを送信し、1 か月あたり 10 億人を超える消費者とやり取りしています。しかし、Braze のビジネスは予測不可能であるため、顧客のパーソナライズされたコミュニケーション ニーズをサポートするために変換する必要があるデータの量に応じて、コンピューティング リソースの需要が大きく変動する可能性があります。

「ある日は100台のサーバーが稼働しているかもしれませんが、別の日は1,000台のサーバーが稼働していることもあります」と、BrazeのDevOpsおよびセキュリティ担当ディレクター、サル・ポリアンドロ3世氏は語る。 Braze は、最終的には知識に基づいた最善の推測をサポートする一連のメトリックに基づいてクラウド インフラストラクチャを拡張していました。その後、Braze は Amazon のサーバーレス コンピューティング プラットフォームである Lambda を発見しました。

現在、このプロセスは完全に自動化されています。アルゴリズムによって必要な容量が決定され、インフラストラクチャ パートナーにアクセスして即座に拡張する機能が起動されます。 「以前はピーク負荷に基づいてスケーリングしていました。サーバーレスでは、そのことを心配する必要がありません」とポリアンドロ氏は言います。一般的な開発チームの場合、このプロセスは手動でサーバーをプロビジョニングするよりも少なくとも 10 倍高速であると見積もっています。

Braze は、クラウド、そして IT 全般の最もホットなトレンドを追いかける、増え続ける企業の 1 つにすぎません。サーバーレス コンピューティング (サービスとしての機能などのサブセットを含む) は、インフラストラクチャのプロビジョニングの煩雑さを排除し、コストを大幅に削減することで、開発者や CIO の注目を集めています。

最終的にはサーバーレスがほとんどのソフトウェアの構築方法になると考える人もいます。 「この基盤技術は、アプリケーションスタック全体、ソフトウェアの記述方法、アプリケーションの構築方法を再定義する機会を生み出すだろう」とベンチャーキャピタル会社メイフィールド・ファンドのマネージング・パートナー、ナビン・チャダ氏は語った。

狂信者たちは一歩先を進んでいるのかもしれない。結局のところ、サーバーレス コンピューティングはまだインキュベーション段階を抜け出していないのです。しかし、嬉しいことに、早期導入者からのフィードバックは励みになるものでした。

Cloudability は 1,500 の組織におけるクラウドの使用状況を分析した結果、サーバーレス プラットフォームの使用は、比較的小規模ではあるものの、2017 年第 4 四半期には 7 倍以上に増加したことが分かりました。 RightScale は、2017 年に調査した 1,000 人の IT プロフェッショナルの間で、サーバーレス テクノロジーが最も急速に成長している拡張クラウド サービスであり、採用率が 12% から 21% に増加したと報告しました。

スタートアップだけでなく、数多くのウェブサイトがあります。 AWS Lambda および関連サーバーレスサービスのゼネラルマネージャーである Tim Wagner 氏は、Lambda のユーザーベースで最も急速に成長しているのは、CapitalOne、Hearst、金融取引業規制機構などの大企業であると述べています。

実際、一部の企業はすでに、サーバーレス テクノロジーを主流のコンピューティング、さらには最先端のコンピューティングに導入し始めています。たとえば、住宅ローン金融会社である連邦住宅抵当金庫 (Fannie Mae) は、リスク分析シミュレーションを自社のサーバーから Lambda に移行し、金融業界初のサーバーレス高性能コンピューティング プラットフォームを構築しています。

まだ参加していないソフトウェア開発者は追いつこうと急いでおり、次世代の重要なテクノロジーに注目している大手テクノロジー企業もこれらのホットなトレンドに注目しています。たとえば、来週サンフランシスコで開催される Google Cloud Next カンファレンスでは、サーバーレスが 19 のセッションの 1 つになります。

「サーバーレス コンピューティングは、バックエンド コンピューティングの経済性を根本的に変えるだけでなく、分散コンピューティングの将来の中心となるだろう」と、マイクロソフト CEO のサティア ナデラ氏は昨年の Microsoft Build カンファレンスで語った。

心配事から解放される

つまり、サーバーレス テクノロジーにより、プログラムを実行するたびにサーバーとソフトウェアをセットアップする必要がなくなります。代わりに、人またはプログラムによってトリガーされたイベントに基づいて、さまざまな機能が自動的に実行されます。

「サーバーレス」という用語は、実際には少し誤解を招くものであり、機能を実行するには依然としてサーバーが必要です。ただし、仮想サーバーやソフトウェアを使用してエミュレートされたコンピューターをセットアップするには数時間または数日かかりますが、このプロセスは数ミリ秒で完了できます。その結果、顧客はサーバーのスペース時間ではなく、機能が使用されたときにのみ料金を支払うため、サーバーレス アプリケーションは非常に低コストでほぼ無限に拡張できます。

対照的に、従来の統合アプリケーションを展開するプロセスでは、CPU、メモリ、ストレージなどのインフラストラクチャと、一連のプラットフォーム ソフトウェアを割り当てる必要があります。アプリケーションがたまにしか使用されなくても、これらのリソースは常に利用可能である必要があります。過剰プロビジョニングはコストの増加、容量の浪費、そして「サーバーの無秩序な増加」、つまり IT 部門がめったに使用されない、または忘れ去られるクラウド インスタンスに対して料金を支払う状況につながります。

サーバーレス シナリオでは、開発者は、調整された方法でオンザフライでデプロイされる小さなコード ブロック (または関数) のコレクションとしてアプリケーションを構築します。つまり、無駄がなく、オーバーヘッドが低く、容量のニーズを満たすための迅速な拡張性が得られます。

多くのモバイル アプリケーションがサーバーレス設計に適しているため、モバイル コンピューティングは最近、サーバーレス領域への関心を高めています。たとえば、スマートフォンのユーザーが地元の天気予報やサッカー場への道順を調べる場合、これらのクエリはパッケージ化されてクラウドに保存され、必要なときに呼び出すことができます。プログラムは単にパラメータ (人の場所や目的地など) をサーバーに渡し、サーバーは単一のターゲット結果を返します。

サーバーレス テクノロジーは、より日常的なシナリオでも役割を果たします。たとえば、ユーザーが新しい写真でオンライン プロフィールを更新すると、サーバーレス関数によってその写真が自動的に別の場所にコピーされます。あるいは、Excel ファイルをデータベースにアップロードするユーザーは、サーバーレス関数をトリガーして、ファイルを JavaScript Object Notation 形式に変換し、データ レイクに保存することもできます。

サーバーレスは、Braze のような企業が予測できない使用シナリオを計画する際によく遭遇する問題を軽減します。大きな試合があるときやチームがプレーオフに進出したときにファンの活動が急増し、トラフィックが急増することが予想されるため、サーバーレスはニュース組織にとって優れたモデルとなります。多くの報道機関は、ピーク時の対応にリソースを割り当て、使用されていないリソースに対して料金を支払うだけです。

10年間の変化

サーバーレスの概念は新しいものではありません。 Google の App Engine には 2008 年から従量課金機能が搭載されています。しかし、このコンセプトが普及したのは、Amazon が 2014 年に Lambda をリリースしてからでした。 Google の Cloud Functions、Microsoft の Azure Cloud Functions、IBM の OpenWhisk など、他のクラウド サービス プロバイダーもこれに追随しています。この間、オンプレミスのオプションを含む、商用およびオープンソースの製品とサービスの大規模なエコシステムが繁栄しました。

サーバーレス アプリケーションの分散性は、最も興味深い機能の 1 つです。サーバーレス コードは必ずしも従来のコードよりも高速に実行されるわけではありませんが、ネットワーク全体に分散して並列実行することができます。たとえば、Google の BigQuery 分析データ ウェアハウスはクエリを複数の部分に分割し、サーバーが利用可能な場所であればどこでも処理します。

つまり、処理速度はシングルスレッド エンジンよりも数桁速くなります。分散エンジンは、どこからでも関数をトリガーできるため、リソースの使用方法に関してより柔軟でスケーラブルになります。水平スケーリングは自動的かつ柔軟であり、プロバイダーによって管理されます。

「コンピューターの究極の目標は、電卓のようになることです。非常にシンプルなインターフェースを持ち、コンピューターが答えを出してくれるようにしたいのです」と、Google Cloud の開発者であるケルシー・ハイタワー氏は語った。 「『これが私のアプリです。実行してください』という体験が得られるまで、私たちはこれを続けます。」

では、なぜこの技術はまだ世界を席巻していないのでしょうか?そうですね、まず、まだ初期段階です。 「ほとんどの顧客は、イベント処理やデータ収集など、非常に特殊なソリューションにサーバーレスを使用しており、大規模な導入はまだ本格的には始まっていません」と、New Relic の戦略アーキテクチャ担当シニアディレクター、リー・アッチソン氏は語る。

もう 1 つの理由は、サーバーレス モデルは構造的に制限されており、現在は限られたアプリケーション セットに限定されていることです。 「サーバーレスに全面的に取り組む企業はほとんどなく、IT部門は組み合わせたアプローチを取ることができると思う」と、レッドハットの製品管理担当シニアディレクター、リッチ・シャープルズ氏は語った。サーバーレスは単純なタスクを迅速に実行するのに最適な方法ですが、統合マイクロサービス プラットフォームが提供する重要な制御機能の一部が欠けています。

ガートナーのテクノロジーおよびサービスプロバイダーグループのリサーチディレクター、クレイグ・ローリー氏はより楽観的だった。 「人々はサーバーレス技術を理解していないので、それをニッチ市場として分類しています。」ガートナーは、サーバーレスの学習曲線を上っている 5 つの企業を調査し、それらのすべてがソフトウェア開発の従来の規範を放棄すると破壊的変化をもたらす企業になったことを発見しました。 「これまでの期待を捨て去れば、そのメリットを実感できるのです。」

AWSのCEO、アンディ・ジャシー氏は昨年、もしアマゾンが今年設立されるなら、サーバーレス・プラットフォーム上に構築されるだろうと述べ、大企業の間でもこの技術が急速に採用されていることに驚いている。

「Lambdaを最初に採用するとは思わなかった企業顧客が多数いる」とAWSの最高情報セキュリティ責任者オフィスのディレクター、マーク・ライランド氏は先週ニューヨークで開催されたAWSサミットで語った。 「しかし、大規模なアプリケーションの再構築を行っているため、彼らは『なぜコンテナを選ぶ必要があるのか​​？ 機能するアプリケーションを構築できる』と言います。」

ステートレスかつイベント駆動型

サーバーレス コンピューティングには、魅力的であると同時に、より広範な導入を妨げる 2 つの明確な特性があります。

まず、サーバーレス関数はステートレスです。つまり、対話のコンテキストが存在しません。履歴は保存されないため、各リクエストはそれに付随する情報のみを使用して処理されます。 「毎回白紙の状態ですが、複雑なアプリケーションロジックの重さに対処する必要がないため、非常に効率的です」と、Wikibon のアナリスト、ジェームズ・コビエルス氏は語ります。

もう 1 つの注目すべき特徴は、サーバーレスがイベント駆動型であることです。つまり、ユーザーまたはプログラムによって生成されたアクションに応答します。イベントには、ミネアポリスの現在の気温を調べるリクエスト、検索エンジンのクエリ、データベース レコードの更新などが含まれる場合があります。

イベント駆動型アプリケーションは、使用されていないときにリソースを消費しないため、非常に効率的です。このアプリケーションはプログラミングが簡単で、拡張も簡単です。 「イベントが来たら関数が実行されるようにアプリケーションを設定できます。100 万のイベントが来たら、100 万を処理できます」とローリー氏は言います。ただし、すべてのアプリケーションを一連のステートレス イベントに要約できるわけではありません。

これらを組み合わせると、サーバーレス コンピューティングは、米国ミネアポリスが暑いか寒いかをチェックするなどの特定のリクエストに最適なプラットフォームになります。ただし、ショッピングカートの管理や請求書の作成などの他のタスクでは、それほど役に立ちません。

「誰かが『購入』をクリックすると、一連のデータベースとランタイム関数が価格設定を行い、注文を確定し、確認を送信します。これらすべては、状態とトランザクションフローを伴う厳格な方法で実行されなければなりません」とコベリウス氏は述べた。このため、サーバーレス実行には適していないという。

新しいツールや拡張機能によって、サーバーレス テクノロジーが従来のアプリケーションでも実行可能になるかどうかはまだ明らかではありません。コンテナや軽量仮想マシンが基盤となるインフラストラクチャの違いを抽象化するのと同様に、ステートレス アプリケーションは、ステートフルな動作を示すように拡張または変更できます。コンテナもステートレスですが、商用およびオープンソースの拡張機能により、コンテキスト依存のアプリケーションでコンテナを使用できるようになります。

Microsoft の目標は、サービスとしての機能とサービスとしてのプラットフォーム間の境界をなくし、開発者がさまざまなプラットフォームを組み合わせて使用​​できるようにすることです。特に、Microsoft は、コンテナで機能を実行したりアプリケーションを完成させたりできる、12 月に発表した「Virtual Kubelets」と呼ばれるテクノロジを強調しました。サーバーレスは、マイクロ課金と自動インフラストラクチャ プロビジョニングにより、多くの企業顧客が求める柔軟性を提供します。 AWS は 11 月下旬に、サーバーやサーバー クラスターを管理せずにコンテナを実行できるサービスである Fargate を開始しました。

「これはまさに最高のサーバーレスです」と、マイクロソフトの Azure コンテナ プログラム管理責任者 Gabe Monroy 氏は、12 月に開催された KubeCon + CloudNativeCon North America カンファレンスで語った。 「インフラがなくなるなら、我々はインフラ分野で働くことになるだろう。」

Wikibon の Kobielus 氏は、分散型デジタル会計技術であるブロックチェーンが、データベース集約型のシナリオにおけるステートレス性を補完するものであるとさえ考えています。 「どの連合フレームワークで誰が何を呼び出したかという完全な記録をいつでもロールバックできます」と彼は語った。

その結果、サーバーレスの支持者は、特に古いアプリケーションを新しいパラダイムに移行し、新しい構築および実行方法を採用しようとする「リフト アンド シフト」の考え方を持つ企業にとって、このテクノロジーは大きな可能性を秘めていると考えています。

たとえば、ほんの数年前、ファニーメイは住宅ローンポートフォリオのリスクを分析するためにモンテカルロシミュレーションを実行しました。現在、彼らは金融業界でサーバーレスを使用した初の高性能コンピューティング プラットフォームを運用しています。約2,000万件の住宅ローンのシミュレーションでは、システムは以前よりも4倍以上速く動作しました。

「Lambda 上で主要なワークロードの使用を妨げるような固有の技術的制限はないと考えています」と AWS のギルバート氏は述べ、ファニーメイのサーバーレスに対する考え方を「クラウド上のスーパーコンピューター」と冗談交じりに呼んだ。 「サーバーレスは最もシンプルで簡単であり、多くの顧客にとって主流のコンピューティングを行うための好ましい方法となるだろう」と彼は語った。

開発者は大好き

サーバーレス モデルの優れた点の 1 つは、投資収益率の指標に簡単には表せないことです。それは、開発者がこのテクノロジーを気に入っているということです。サーバーレス アーキテクチャにより、インフラストラクチャの展開の負担がなくなり、コードを記述するだけで済みます。

「サーバーレス テクノロジーにより、当社のアプリケーション エンジニアと運用エンジニアは、よりわかりやすい方法で自分の責任について考えることができるようになりました」と Braze のポリアンドロ氏は述べています。 「より迅速に展開でき、周囲のインフラストラクチャについて心配する必要がありません。」

ただし、サーバーレス プラットフォーム上でアプリケーションを構築するには、開発者が何かを実行する方法についての考え方を大幅に変更する必要があります。 「Lambda を選択するということは、コードを書き直すことを意味しました」と Ryland 氏は認めています。

サーバーレス アーキテクチャの支持者は、制限はテクノロジーにあるのではなく、統合アプリケーションの開発における 60 年の歴史にあると主張します。 「サーバーレス技術は、ソフトウェアの開発方法に関するいくつかの前提と既存のパラダイムに挑戦する」とガートナーのローリー氏は述べた。 「顧客はこれに大きな価値を見出していますが、まったく新しいプログラミング方法を学ばなければなりません。」

ステートレスでイベント駆動型の環境向けの開発は、モノリシック アプリケーションの開発よりも必ずしも簡単ではありません。サーバーレス アーキテクチャは「複雑さをアプリケーションから接続性へと移行します」とアッチソン氏は述べています。 「これは万能の解決策ではありません。それ自体に問題があり、これらの問題に対処する必要があります。」

Microsoft では、開発者がイベント ベースの非同期パターンを使用したプログラミングに慣れ、関数オーケストレーター (Durable Functions プログラミング モデルや Logic Apps コネクタなど) を使用して長時間実行される操作と状態管理を作成する方法を学習することをお勧めします。

しかし支持者たちは、そのメリットは、より多くのツールだけでなく、ソフトウェア開発に対するより創造的なアプローチを必要とする厳しい学習曲線に見合う価値があると主張する。

「ほとんどのアプリケーションが実行する処理の大部分は、サーバーレス関数として実行できます」とコビエルス氏は言う。コンテナは機能をカプセル化し、それを独立して拡張可能なサービスとしてユーザーに提供するのに役立ちます。 ”

従来のアプリケーションも、特定のサーバーレス機能を活用するように変更できます。本質的にイベント駆動型の機能は、メイン アプリケーションとは別にカプセル化できます。

たとえば、「データベースやファイルシステムにデータが作成されるたびに、それがイベントになります」とローリー氏は言う。 「つまり、メインプログラムとは独立して他の処理を実行するように設定できるということです。これにより、アプリの寿命が延びます」と、アプリケーションプログラミングインターフェースを使用してアプリを拡張したり、他のアプリにフックしたりできるためです。

組織は、既存のアプリケーションを最初から書き直すのではなく、個々のコンポーネントを調整してサーバーレス実行のメリットを享受し、段階的に移行することができます。 「新しいアプリケーション機能をマイクロサービスとして作成し、ユーザー インターフェース コンポーネントをビジネス ロジックおよびデータ アクセス レイヤーから分離し、既存のマイクロサービスをサーバーレス機能に変換して分離します」と、サーバーに関する広範な発表を行っているモバイルおよび IoT サービス企業 Simform の技術コンサルタント、Rohit Akiwatkar 氏は述べています。 「時間が経つにつれて、機能の数が増え、開発チームの敏捷性と速度が向上します。」

ベストタイム

CIO がサーバーレスの波に乗るべき時が来ているのでしょうか?ローリー氏はそう考えている。 「私はCIOに、この技術は消え去ることはない、一時的な流行ではない、と伝えています。企業は従業員にこの技術を理解させるべきです。」

Simform の Akiwatkar 氏は、次の 3 つのステップを推奨しています。サーバーレス アーキテクチャの使用に関するベスト プラクティスを理解する。 ROI の高いアプリケーションを特定する。低リスク環境でサーバーレス関数を実験します。

これらすべてを考慮すると、開発者がサーバーレス テクノロジーを採用するのに最適な時期と言えます。コンテナからマイクロサービス、そして現在のサーバーレス コンピューティングまで、過去 5 年間で、アプリケーションの構築と展開において、過去 20 年間を合わせたよりも多くのイノベーションが導入されました。

人材がひどく不足している経済においては、次の大きな出来事に対して謙虚であり続けることが、最高の人材を引き付ける唯一の方法かもしれない。 「この技術を長期的に導入するための計画を立てなければなりません。そうしないと、必要な人材を確保できなくなります。開発者はこの技術に興奮するでしょう」とローリー氏は語った。

クラウド、コンテナ、マイクロサービスなど、DevOps のような終わりのないイノベーションへの対応に苦戦している組織にとって、サーバーレス コンピューティングは、また別の頭痛の種のように思えるかもしれません。しかし、すべての企業がソフトウェア企業になりたいと願うビジネスの世界では、最新のトレンドに遅れをとれば、存在感を低下させる間違いになる可能性があります。