パブリッククラウドにおけるサーバーレスコンピューティングの比較: AWS vs Google Cloud vs Azure

AWS Lambda、Google Cloud Functions、Microsoft Azure Functions では、少しのビジネスロジックで大きな効果が得られます。

サーバーの問題で午前 3 時に起こされたことがあるなら、「サーバーレス コンピューティング」などの流行語の魅力がわかるでしょう。物理サーバーのプロビジョニングには数時間、数日、あるいは数週間かかることがあり、その後はバグやセキュリティの脆弱性を修正するために継続的な更新が必要になります。これらのアップデートは、新しいアップデートによって非互換性が生じて他のアップデートが必要になったり、終わりが見えないなど、独自の問題を引き起こすことがよくあります。

稼働中のサーバーによって引き起こされる問題の終わりのない連鎖は、大手クラウド企業が「サーバーレス コンピューティング」アーキテクチャを採用した理由の 1 つです。彼らは、上司たちが次のような言い訳をあまりにも多く聞いてきたことを知っています。サーバーにはこの問題があり、サーバーにはあの問題がある、そして同様の問題が多すぎるのです。もしサーバーを廃止できれば、上司は間違いなくそれを望むでしょう。

[[228391]]

サーバーレス コンピューティングは素晴らしいセールス用語ですが、唯一の問題はそれが完全に正確ではないことです。これらのアプリケーションは、レストランにキッチンがないのと同じようにサーバーレスです。食べたいものがメニューに載っていて、シェフの調理法が気に入ったら、レストランで食事をするのは最高です。しかし、別の種類の料理が欲しかったり、別のスパイスが欲しかったりする場合は、専用のキッチンが必要です。

Amazon、Google、Microsoft は、サーバーレス API に記述され、自動化レイヤーを通じて管理される将来のアプリケーションに注目している 3 つの大企業です。これらのプラットフォームがあなたの望みどおりに機能し、新しいモデルが普及すれば、数十億ドル規模のユニコーン Web アプリを作成する最も簡単かつ迅速な方法になる可能性があります。重要なロジックの部分だけを記述すれば、プラットフォームがすべての詳細を処理します。

サーバーレス コンピューティング機能は、すべてのクラウド機能を接続する接着剤またはスクリプト言語になりつつあります。かつては独立していたマッピングや AI ツールが、今ではイベント駆動型のサーバーレス関数を介してリンクされています。今では、イベント ストリームによってトリガーされ、あらゆるクラウドの隅々まで波及して飛び交うリクエストによって、より多くの作業を解決できるようになりました。機械学習を調査し、それを使用してデータを分析する場合、最も簡単な方法の 1 つは、サーバーレス アプリケーションを作成し、クラウド機械学習部分にイベントの送信を開始することです。

暗黙の約束は、すべてをより薄くスライスすることで、クラウド内でリソースを共有しやすくなるということです。昔は、誰もが夢中になって、たとえば自分の仮想マシン上で動作する Ubuntu サーバーの新しいインスタンスを作成していました。誰もが同じ OS を使用し、12 個以上の仮想 Ubuntu ボックスを装った同じ実際のボックスに何十億回もコピーされています。サーバーレス コンピューティングの運用により、こうした作業の重複が排除され、クラウド コンピューティングのコストが大幅に削減されます。特に、散発的に実行され、空調の効いたサーバー ルームに古いサーバーが詰め込まれたままになることのないジョブの場合、コストが大幅に削減されます。

もちろん、こうした利便性には隠れたコストが伴います。コードを別のサイトに移動したり残したりしたい場合は、スタックの大部分を書き直さなければならない可能性があります。これらの API はそれぞれ異なり、JavaScript などの一般的な言語ではある程度の標準化が行われていますが、独自のテクノロジーに非常に近いため、ベンダー ロックインにつながります。

サーバーレス コンピューティングの魅力を理解するために、私はいくつかの機能を構築し、スタックを調べることに時間を費やしました。あまりコードを書きませんでしたが、これが鍵です。すべてを設定するには、ボタンをクリックしたり、Web フォームに入力したりするのに多くの時間を費やしました。すべてを XML と JSON で構成したときのことを覚えていますか?今では、Web フォームに入力するだけで、クラウドが代わりに処理してくれます。それでも、プログラマーのように考え、舞台裏で何が起こっているのか、そしてそれを制御できないことを理解する必要があります。

AWS ラムダ

AWS Lambda は、Amazon のクラウド全体のシェル スクリプト レイヤーへと成長しています。これは、AWS IaaS が生成できるほぼすべてのイベントに応じて関数を埋め込むことができる基本システムです。新しいファイルが S3 にアップロードされた場合、何か興味深いことを実行する関数をトリガーすることができます。一部のビデオが Amazon Elastic Transcoder によってトランスコードされている場合は、完了後に Lambda 関数がトリガーされるのを待つことができます。これらの関数は、他の Lambda アクションをトリガーしたり、単に更新を誰かに送信したりすることもできます。

Lambda 関数は、JavaScript (Node.js)、Python、Java、C#、Go で記述できます。これらの言語は他の多くの言語に埋め込むことができるため、Haskell、Lisp、さらには C++ などの他のコードを実行することも可能になります。

Amazon は多くの設定および最適化オプションを提供しているため、Lambda 関数の作成は予想以上に複雑になることがよくあります。技術的にはほんの数行のコードを書いて素晴らしい成果を達成できますが、コードの実行方法を構成するためにより多くの時間を割く必要があると感じました。作業のほとんどは、テキスト ファイルに入力するのではなく、ブラウザーでフォームに入力することによって行われます。テキスト エディターをブラウザー フォームに置き換えただけのように感じることもありますが、これは Amazon が Lambda ユーザーに拡張した柔軟性をすべて維持するための代償です。

これらの追加手順の一部は、Amazon がユーザーにさらに多くの選択肢を公開し、より多くの VPN ライターを期待しているために発生します。 Google または Microsoft で機能を作成すると、ブラウザで正しい URL を指定してすぐにテストできます。 Amazon では、クリックするだけで API ゲートウェイを構成し、ファイアウォールに適切な穴を開けることができました。

AWS Lambda 設定ページでは、関数をトリガーするイベントソースと、その他のイベントの送信先をクリックできます。

***、これらのクリック操作により、テキスト ファイルから始めるよりも作業が少し簡単になるハンドヘルド ツールのレイヤーが追加されます。関数を作成すると、ブラウザに「この関数には外部ライブラリが含まれています」という警告が表示されます。

サーバーレス コンピューティングによってサーバー管理の手間が軽減される場合、Amazon には AWS Lambda など、「サーバーレス コンピューティング」向けのオプションが他にも多数あります。サーバーの起動とシャットダウンを行う Amazon EC2 Auto Scaling や AWS Fargate、アップロードしたコードを Web サーバーにデプロイして負荷分散とスケーリングを処理する AWS Elastic Beanstalk などの弾力性ツールがあります。もちろん、これらの自動化ツールの多くでは、サーバー イメージを作成する責任は依然としてユーザーにあります。

さらに便利な製品は、ソフトウェアアーキテクトがワークフローと呼ぶパターンをシミュレートするステートマシンを作成するためのコード不要のフローチャートツールである AWS Step Functions です。問題の一部は、すべてのサーバーレス関数が完全にステートレスであることです。これは、非常に基本的なビジネス ロジックを実行する場合にはうまく機能しますが、一部のクライアントにリストやフローチャートを説明する場合には、少々悪夢になる可能性があります。クライアントに関する情報を再ロードするために、データベースに頻繁にアクセスします。ステップ関数は、Lambda 関数と状態を結合します。

Google Cloud Functions と Firebase

サーバーの設定の手間を省きたい場合、Google Cloud では、ルート パスワードを必要とせず、コマンド ラインも使用せずにさまざまな自由を提供するサービスが多数提供されています。

Google は、2008 年の Google App Engine を皮切りに、さまざまなメッセージングとデータの透明性を組み合わせたさまざまな「サーバーレス コンピューティング」オプションを徐々に追加してきました。 Google Cloud Pub/Sub と呼ばれるものはメッセージ キューを非表示にするため、データ プロデューサーとコンシューマー用のコードのみを記述すれば済みます。 Google Cloud Functions は、特定の主要ツールや API を含む多くの主要製品にイベント駆動型の計算機能を提供します。さらに、Google Firebase は、データをクライアントに配信するデータ ストレージ レイヤーに JavaScript コードを組み込んだデータベースです。

その中でも、私が最も興味を持っているのは Firebase です。データベースは、データ構造とディスク ストレージの煩雑さを抽象化してすべての情報を TCP/IP ポート経由で配信する、元祖サーバーレス コンピューティング アプリケーションであると考える人もいます。 Firebase は、JavaScript コードとメッセージングを追加することでこの抽象化を極限まで高め、認証を含むサーバー側インフラストラクチャで実行したいあらゆることを実行します。技術的には単なるデータベースですが、スタックのビジネス ロジックとメッセージングの大部分を処理します。クライアント側の HTML、CSS、JavaScript、Firebase を使用すれば、実際に問題なく動作します。

Oracle が行ったように、Firebase の JavaScript レイヤーを「ストアド プロシージャ」と呼びたくなるかもしれませんが、そうすると全体像が見えなくなります。 Firebase コードは JavaScript で記述されているため、Node.js のローカル バージョンで実行されます。 Node の世界にはこのワークフローを処理するライブラリがすでに豊富にあるため、ビジネス ロジックのほとんどをこのレイヤーに埋め込むことができます。さらに、クライアント、サーバー、そしてデータベース上で実行される同型コードを活用できるようになります。

私の注目を引いたのは、Firebase に組み込まれた同期レイヤーです。データベースのオブジェクトのコピーをネットワーク経由で同期します。秘訣は、クライアント アプリケーションを、関連データ (関連データのみ) の変更をサブスクライブする別のデータベース ノードとして設定できることです。ある場所でデータが変更されると、すべての場所で変更されます。 Firebase が必要な場所に情報をコピーするため、メッセージングの煩わしさをすべて回避し、Firebase への情報の書き込みに集中できます。

Google Firebase には、正常なイベントと異常なイベントのタイムラインを表示するエラー コンソールが用意されています。

Firebase に重点を置く必要はありません。より基本的な Google Cloud Function を使用すると、カスタム コードを Google Cloud に埋め込むのがより簡単になります。現在、Cloud Functions は主に Node.js コードを記述するためのオプションにすぎず、事前に構成された Node 環境で実行されます。 Google Cloud Platform の残りの部分では、Java や C# から Go、Python、PHP まで幅広い言語がサポートされていますが、Cloud Functions は JavaScript と Node に厳密に制限されています。他の言語オプションも登場するというヒントはありましたが、近いうちに登場しても驚かないでしょう。

Google Cloud Functions は、少なくとも現時点では AWS Lambda のようなものではなく、Google ドキュメントとやり取りする関数の構築を検討していくうちに、おそらく REST API を使用して、Apps Script と呼ばれるアプリケーションでコードを記述する必要があることがわかりました。言い換えれば、Google ドキュメントの世界には独自の REST API があり、長い間サーバーレスでした。

特に、Google App Engine は引き続き強力です。当初は、Web サイトにアクセスするすべてのユーザーのニーズを満たすために Python アプリケーションを起動する方法を提供していましたが、長年にわたって拡張され、さまざまな言語のランタイムを処理できるようになりました。コードを実行ファイルにバンドルすると、App Engine はトラフィックを処理するのに十分なノードを起動するプロセスを処理して、ユーザーがリクエストを送信するとスケールアップまたはスケールダウンします。

念頭に置くべき障害がいくつかあります。 Cloud Functions と同様に、コードは比較的ステートレスな方法で記述する必要があり、各リクエストは制限された時間内に完了する必要があります。しかし、App Engine は、すべてのサポートを放棄したり、リクエスト間ですべてを忘れたりするわけではありません。 App Engine はサーバーレス革命の大きな部分を占めており、Python、PHP、Java、C#、Go を使用して昔ながらの方法で独自のスタックを構築した人にとっては今でも最もアクセスしやすいものです。

Microsoft Azure 関数

もちろん、Microsoft は、Azure クラウドを使用してユーザーがこれらすべての優れたサーバーレス コンピューティングを実行できるようにするために、他の誰よりも懸命に取り組んでいます。同社は独自の基本機能である Azure Functions を作成し、セミプログラマーにとって使いやすい、より複雑なツールも構築しました。

マイクロソフトが持つ最大の強みは、以前のデスクトップ実行可能ファイルである Office アプリケーションのコレクションであり、ゆっくりと、しかし着実にクラウドに移行しつつあります。実際、クラウド コンピューティングの収益に関するある計算では、Microsoft が Amazon を上回っており、これは Office 収益の一部を「クラウド」に含めているからでもある。

Azure Functions ドキュメントで最も人気のある例の 1 つは、誰かがスプレッドシートを OneDrive に保存したときにクラウド関数をトリガーする方法を示しています。突然、雲の中の小さな妖精が生き返り、スプレッドシートで何かを行います。 Excel スプレッドシート (またはその他の Office ドキュメント) を愛用する IT サポート チームにとって、これはまさに天の恵みです。 Azure Functions を記述して、ほぼ何でも実行できます。クラウドへの唯一のインターフェースは HTML と Web であると考えられることがよくありますが、Microsoft Word や Excel などのドキュメント形式を使用できない理由はありません。

Azure Logic Apps は、セマンティクスや構文を気にせずにフォームに入力できるツールの 1 つとして私の注目を集めました。プログラマーのように考え、抽象化とデータについて賢明な判断を下す必要はありますが、フォームに記入しているというよりは「コード」を書いているのだと自分に言い聞かせるかもしれません。

Microsoft Azure の Web IDE を使用すると、Azure 関数を記述して実行し、ログ呼び出しを挿入してデバッグすることができます。

Amazon の Step Functions と同様に、Logic Apps は、ある種の状態を利用できるため、平均的な「関数」よりも複雑なものを表す流行語である「ワークフロー」をエンコードすることを目的としています。さまざまな関数とコネクタをリンクするロジックをフローチャートのような方法で記述することはできますが、正式なコンピューター言語で詳しく説明することはできません。

Logic Apps の大きな利点の 1 つは、いくつかの大規模な Microsoft アプリやサードパーティ アプリにアクセスできる、事前に構築された「コネクタ」です。 SalesApp、Twitter、Office 365 などのロジック アプリからデータを効率的にプッシュまたはプルできます。これらの接続は企業の IT スタッフにとって非常に価値があり、シェル スクリプトを作成するのと同じように、ロジック アプリを記述して外部ツールに接続できるようになりました。

Azure のもう 1 つの興味深い側面は、NoSQL データベースと SQL データベースの両方である Azure Cosmos DB です。 Microsoft は Cassandra および MongoDB API をコピーしたので、Cassandra または MongoDB コードを書き直すことなく情報を出し入れできます。または、SQL を記述したい場合は、それも可能です。 Cosmos DB は物事を整理し、すべてをインデックス化して高速に実行できるようにします。共同作業したい SQL および NoSQL コードが大量にある場合、これは興味深い中心的な結びつきになります。あるいは、将来的に別のアプローチをとる余地を残しておきたいだけかもしれません。

サーバーレスコンピューティングの比較

あなたに最適なサーバーレス コンピューティング プラットフォームはどれですか?基本的な関数の記述は 3 つのサイロすべてでほぼ同じですが、違いもあります。最も明白なのは、おそらく利用可能な言語です。各言語は、Node.js と JavaScript のサポートが終了した後、お気に入りを選択するからです。 Microsoft の Azure で C# を記述できることは驚くことではありませんが、F# と TypeScript のサポートは抜群です。 Amazon では Java、C#、Python を使用します。 Google の現在の基本機能は JavaScript に厳密に制限されていますが、App Engine でより多くの言語をサポートすることに取り組んでいます。

サーバーレス コンピューティングを比較する上で最も難しいのは、価格と速度を把握することです。なぜなら、その裏には多くのことが隠されているからです。 VM の価格を時間単位で設定すると、自分が無駄遣いをしているように感じることがよくあります。現在、ベンダーはサラミを非常に薄くスライスしているため、1 ドル未満で数十万の関数呼び出しを取得できます。

もちろん、この見かけの安さは、通貨が大きく異なる見知らぬ国で休暇を過ごしているときと同じように、私たちの脳の合理的で予算を意識する部分をすぐに損ないます。すぐに、カンクンでグラスワインを購入するときのように、実際のコストを判断できるほど迅速に割り当てることができず、そのデータベースをさらに 100 万回注文することになります。

クラウド コンピューティングで生の仮想マシンが起動されたときは、メモリと CPU の能力を推測できましたが、サーバーレス コンピューティングの世界では、実際に何が起こっているのかはわかりません。

サーバーレス コンピューティング モデルでは、コード内に状態を保持することが実際には許可されていないため、データをローカル クラウド データベースに保存することがほぼ強制されることに注意してください。これらのバックエンドを信頼する必要があります。他のバージョンは常に作成および破棄されるため、関数はローカル キャッシュや構成なしで実行する必要があります。つまり、データベース グルー コードは、「ストレンジャー シングス」の逆さまになったつる植物のようにコードを埋め尽くすことになります。

コストを比較する唯一の現実的な方法は、すべてのプラットフォームでアプリを構築することですが、これは困難な課題です。これら 3 つはすべて Node.js を実行するため、一部のコードを 3 つ間で移動することは可能ですが、それでも、対処しなければならない違いに遭遇することになります。 (たとえば、Microsoft と Google では HTTP リクエストを直接処理しますが、AWS では API Gateway を介して処理します。)

幸いなことに、それほど心配する必要はありません。私の実験では、多くの基本的なアプリケーションはほとんどリソースを使用しないため、貧しい開発者を引き付けるために、これら 3 つの利点すべてを無料レベルで提供することができます。サーバーレス コンピューティング モデルは確かにコストを節約します。サーバーをほぼフル稼働させて無料のエアコンを利用しているタイプの人でない限り、サーバーレスにすることでかなりの費用を節約できる可能性があります。 100 万回の通話あたり 1 ドルか 1.50 ドルかを議論する必要がなくなるほどの金額を節約できます。

もっと深刻な問題があります。こうした雲が多すぎると、困ったことになります。コードを取得して別の商用サーバーで実行するだけというほど簡単ではありませんが、独自のコードが満載された Docker コンテナを使用すれば実行できます。運が良ければ、同じ元のスキーマと基本的な JavaScript 関数を複製できますが、その後はデータベース グルー コードを全面的に書き直すことになります。これら 3 社はそれぞれ独自のデータ ストレージ レイヤーを持っています。

何か問題が起きたときに何が起こるかは不明です。独自のサーバーを運用するということは、サーバーが機能しないときに上司が監視することを意味します。この分野で何が起こるかは不明です。 Google のページの 1 つに、次のような無害な警告が含まれています。「これは Google Cloud Functions のベータ版です。この API は互換性のない方法で変更される可能性があり、SLA や非推奨ポリシーの対象ではありません。」

Amazon の利用規約は、この分野に参入した当初よりも改善されていますが、それでも「AWS Lambda に 3 か月以上アップロードされていないコンテンツは、30 日前に通知することで責任を負うことなく削除される場合があります」などの留意すべき警告が含まれています。保持したい内容に対してコードが実行されていることを確認します。このような警告は確かに妥当です (古い Lambda 関数はもう使用されないことはわかっています) が、制御の一部を放棄することを示しています。

Microsoft は、Azure サービスに対してサービス レベル アグリーメントを提供し、サービス クレジットを通じてダウンタイムに対する金銭的補償を約束しています。これらは機能のダウングレードに適用されますか?おそらく、サービスのテストエリアに迷い込まない限りは。子供向けのチャットルームよりももっと本格的なものを設定する予定がある場合は、少し時間をかけてこれらの詳細に注意を払う価値があります。