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

サーバーレス コンピューティングは、クラウド プロバイダーがオンデマンドでリソースを割り当て、顧客に代わってサーバーを管理するクラウド コンピューティング 実行モデルです。ISO/IEC 22123-2 によると、「サーバーレス コンピューティングは、顧客がハードウェアまたはソフトウェア リソースをプロビジョニング、展開、管理することなく、さまざまなクラウド機能を使用できるクラウド サービス カテゴリです。顧客アプリケーション コードの提供や顧客データの提供は別です。サーバーレス コンピューティングは、仮想化コンピューティングの一形態です。」^[1] Function as a Service とサーバーレス データベースは、サーバーレス コンピューティングの 2 つの形態です。^[1]

サーバーレスは、クラウド サービス プロバイダーが開発者のコ​​ードを実行するためにサーバーを依然として使用しているという意味で、誤った名称です。サーバーレス コンピューティングの定義は時間の経過とともに進化し、さまざまな解釈が生まれています。Ben Kehoe 氏によると、サーバーレスは厳密な定義ではなく、スペクトルを表しています。厳密な定義と特定のテクノロジーから、サーバーレスの考え方を取り入れ、サーバーレス ソリューションを活用してビジネス上の課題に対処することに重点を置くようにシフトする必要があります。^[2]

サーバーレス コンピューティングは、コードを本番環境にデプロイするプロセスを簡素化できます。Gregor Hohpe 氏によると、サーバーレスを使用しても複雑さが完全になくなるわけではなく、主に運用チームから開発チームに複雑さが移行されます。また、アプリケーションの粒度が細かくなるほど、管理が難しくなります。^{[説明が必要] [3]}

サーバーレスコードは、マイクロサービスやモノリスなどの従来のスタイルでデプロイされたコードと組み合わせて使用​​できます。また、アプリケーションを純粋にサーバーレスで作成し、プロビジョニングされたサーバーをまったく使用しないようにすることもできます。^{[4]これを、}ピアツーピア(P2P)などの実際のサーバーを必要としないコンピューティングモデルやネットワークモデルと混同しないでください。

Yan Cui氏によると、サーバーレスは顧客価値をより早く提供できる場合にのみ導入すべきだ。そして、導入するにあたっては、組織は小さなステップを踏みながらリスクを軽減していくべきだという。^[5]

サーバーレス ベンダーは、アプリケーション ロジックを実行し、データを保存しないコンピューティング ランタイムを提供しています。一般的なランタイム モデルは、Function as a Service (FaaS) とContainer as a Serviceです。サーバーレス ランタイムでサポートされている一般的な言語は、 Java、Python、PHPです。通常、関数はLinux コンテナーなどの分離境界内で実行されます。

最初の従量課金制のコード実行プラットフォームは2006年にリリースされたZimkiでしたが、商業的には成功しませんでした。 ^[6] 2008年にGoogleはGoogle App Engineをリリースしました。これはカスタムPythonフレームワークを使用するアプリケーションに対して従量課金制を採用していましたが、任意のコードを実行することはできませんでした。^[7] 2010年にリリースされたPiCloudは、PythonのFaaSサポートを提供しました。

2008 年に導入された Google App Engine は、最初の抽象的なサーバーレス コンピューティング サービスでした。^[8] App Engine には、60 秒のタイムアウトを持つ HTTP 関数と、独自のタイムアウトを持つ BLOB ストアとデータ ストアが含まれていました。メモリ内の永続性は許可されていませんでした。すべての操作はこれらの制限内で実行する必要がありましたが、これにより App Engine で構築されたアプリはほぼ無限に拡張でき、Snapchatなどの初期の顧客や、多くの外部および内部の Google アプリをサポートするために使用されました。言語サポートは、ネイティブ Python モジュールを使用する Python と、Google が選択した C の Python モジュールの限られた選択に限定されていました。後のサーバーレス プラットフォームと同様に、App Engine でも従量課金制が使用されました。^[9]

2014年にAmazonが導入したAWS Lambda ^{[10]は、抽象的なサーバーレスコンピューティングモデルを普及させました。これは、AWS Serverless Application Model (AWS SAM)、} Amazon CloudWatchなど、数多くのAWSサーバーレスツールによってサポートされています。

Google Cloud Platformは2016年に2番目のサーバーレスサービスであるGoogle Cloud Functionsを開発しました^。[11]

Oracle Cloud FunctionsはOracle Cloud Infrastructureで提供されるサーバーレスプラットフォームであり、オープンソースのFnプロジェクトに基づいているため、開発者は他のクラウドやオンプレミス環境に移植可能なアプリケーションを作成できます。Python、Go、Java、Ruby、Nodeのコードをサポートしています。[ 12 ^]

サーバーレス実行モデルをRDBMSに拡張し、仮想化または物理データベース ハードウェアをプロビジョニングまたは拡張する必要性をなくすサーバーレスデータベースがいくつか登場しています。

Nutanixは、 Oracle、MariaDB、PostgreSQL、Microsoft SQL Serverなどの既存のRDBMSをサーバーレスサービスに変換するEraというソリューションを提供しています。 ^[13]

Amazon AuroraはMySQLとPostgreSQLをベースにしたサーバーレスバージョンのデータベースを提供しており、オンデマンドの自動スケーリング構成を提供しています。^[14]

Azure Data Lake は、高度にスケーラブルなデータ ストレージおよび分析サービスです。このサービスは、Microsoft のパブリック クラウドであるAzureでホストされています。Azure Data Lake Analytics は、リソースを動的に割り当てたり割り当て解除したりできる分散インフラストラクチャを提供するため、顧客は使用したサービスに対してのみ料金を支払います。

Oracle Cloudは、Oracle Autonomous Databaseのサーバーレス版であるAutonomous Transaction Processingサービスを提供しています。サーバーレスサービスにはJSONエディションも含まれています。^[15]

FirebaseもGoogleが所有しており^{[16] 、}階層型データベースが含まれており、固定プランと従量課金プランで利用できます。^[17]

サーバーレスは、一定数のサーバーをレンタルまたは購入するよりもコスト効率が高くなります。 ^[18]通常、サーバーレスでは、使用率の低い期間やアイドル時間の期間が長くなります。^{[19]基盤となるマシンリソースの}ビンパッキングがより効率的であるため、自動スケーリンググループをプロビジョニングするよりもコスト効率が高くなる場合もあります。

これは従量課金コンピューティング^[18]またはベアコード^[18]とも呼ばれ、コードを実行するために割り当てられた時間とメモリに基づいてのみ課金され、アイドル時間に関連する料金は発生しません。^[18]ここで役立つ類推は、レンタカー (従来のクラウド仮想マシン) と Uber や Lyft などのライドシェア アプリ (サーバーレス コンピューティング) の比較です。即時のコスト メリットは、ライセンス、インストール、依存関係、メンテナンス、サポート、パッチ適用のための人件費など、運用コストがかからないことに関係しています。^[18]無限のスケーラビリティにより、開発者は欠陥のあるコードやサービス拒否攻撃の結果として請求書の衝撃を経験する可能性があります。ただし、これはサービス プロバイダーの費用で返金されることがよくあります。^[20]

さらに、サーバーレスアーキテクチャは、開発者やオペレーターが自動スケーリングポリシーやシステムの設定や調整に時間を費やす必要がないことを意味します。クラウドプロバイダーが需要に合わせて容量をスケーリングする責任を負います。^{[19] [21] [18]} Googleは「プロトタイプから本番環境、そして地球規模まで」と言っています。^[18]

クラウド ネイティブ システムは本質的にスケールアップだけでなくスケールダウンも可能なため、これらのシステムはスケーラブルではなく、弾力性があると言われています。

小規模な開発者チームは、インフラストラクチャやサポートエンジニアのチームに依存せずに、自分たちでコードを実行できます。より多くの開発者がDevOpsのスキルを身につけ、ソフトウェア開発者とハードウェアエンジニアの区別が曖昧になっています。^[18]

Function as a Serviceでは、外部に公開されるコード単位は単純なイベント駆動型関数です。つまり、通常、プログラマーはマルチスレッド化やコード内でのHTTPリクエストの直接処理について心配する必要がなく、バックエンド ソフトウェア開発のタスクが簡素化されます。

サーバーレスアプリケーションは分散コンピューティングの誤解に陥りやすい。さらに、次のような誤解に陥りやすい: ^{[22] [23]}

• バージョン管理は簡単
• 補償取引は常に機能する
• 可観測性はオプションです

あまり使用されないサーバーレスコードは、専用サーバー、仮想マシン、またはコンテナ上で継続的に実行されるコードよりも応答遅延が大きくなる可能性があります。これは、オートスケーリングとは異なり、クラウドプロバイダーは通常、使用されていないサーバーレスコードを完全に停止するためです。つまり、ランタイム（Javaランタイムなど）の起動にかなりの時間を要する場合、追加の遅延が発生します。^{[24]これは、サーバーレスコンピューティングでは}コールドスタートと呼ばれます。

サーバーレスコンピューティングは、クラウドプロバイダーによって課せられるリソース制限のため、また、特定の時点で必要と思われるサーバーの数を一括プロビジョニングする方が安価になる可能性が高いため、高性能コンピューティングなどの一部のコンピューティングワークロードには適していません。 ^{[25]これにより、複雑なアプリケーション（関数の}有向非巡回グラフを含むアプリケーションなど）をデプロイすることが困難になります。すぐに使用できるサーバーレスコンピューティングは、個々のステートレス関数の実行に最適です。AmazonのAWS Step FunctionsやMicrosoftのAzure Durable Functionsなどの一部の商用製品は、この課題を軽減することを目的としています。

サーバーレスコードでは、パフォーマンスや過剰なリソース使用の問題を診断することが、従来のサーバーコードよりも難しい場合があります。これは、関数全体の時間を計測することはできるものの、^[4]プロファイラー、デバッガー、またはAPMツールを接続して詳細を掘り下げる機能が通常はないためです。^{[26]さらに、コードが実行される環境は通常オープンソースではないため、そのパフォーマンス特性を}ローカル環境で正確に再現することはできません。

OWASPによると、サーバーレスアプリケーションは、従来の攻撃のバリエーション、安全でないコード、および一部のサーバーレス特有の攻撃（ウォレット拒否^[27]など）に対して脆弱です。したがって、リスクは変化しており、攻撃を防ぐには考え方の転換が必要です。^{[28] [29]}

サーバーレスは、従来のアーキテクチャよりも安全であると誤解されることがあります。OS の脆弱性はクラウド プロバイダーによって処理されるため、これはある程度は真実ですが、従来のアーキテクチャと比較してアプリケーションのコンポーネントの数が多く、各コンポーネントがサーバーレス アプリケーションへのエントリ ポイントであるため、攻撃対象領域全体が大幅に大きくなります。さらに、侵入検知/防止システム(IDS/IPS)など、エンドポイントおよびネットワークレベルで制御およびインストールできないため、クラウド ワークロードを保護するために顧客が使用していたセキュリティ ソリューションは無関係になります。^[30]

これは、サーバー ネットワーク全体の単一文化特性によって強化されます (1 つの欠陥がグローバルに適用される可能性があります)。Protego によると、「サーバーレス アプリを保護するためのソリューションは、開発者、DevOps、および AppSec (DevSecOps とも呼ばれます) の緊密な連携です。開発者がセキュリティを所有するのではなく、責任から免除されることもないバランスを見つけます。これを全員の問題にするための措置を講じます。部門横断的なチームを作成し、セキュリティ専門家と開発チームの緊密な統合に向けて取り組みます。組織がサーバーレスの速度でセキュリティ リスクを解決できるように協力します。」^[31]

多くのサーバーレス機能環境は、独自のパブリック クラウド環境に基づいています。ここでは、共有リソースや外部従業員によるアクセスなど、プライバシーへの影響を考慮する必要があります。ただし、サーバーレス コンピューティングは、 Kubernetesプラットフォームなどを使用して、プライベート クラウド環境やオンプレミスでも実行できます。これにより、従来のサーバー設定でのホスティングと同様に、企業はプライバシー メカニズムを完全に制御できます。

サーバーレスコンピューティングは、国際データセンター機構（IDCA）のフレームワークAE360で取り上げられています。^[32]しかし、ビジネスロジックをパブリッククラウド間で移動する場合、移植性に関する部分が問題になる可能性があり、そのためにDockerソリューションが作成されました。Cloud Native Computing Foundation （CNCF）もOracleと共同で仕様の開発に取り組んでいます。^[33]

サーバーレス コンピューティングは、サードパーティのサービスとして提供されます。サーバーレス環境で実行されるアプリケーションとソフトウェアは、デフォルトで特定のクラウド ベンダーにロックされます。この問題はサーバーレス コンピューティングでさらに深刻化します。抽象化のレベルが上がると、パブリック ベンダーは、顧客が基盤となる環境を構成する権限なしで FaaS プラットフォームにコードをアップロードすることしか許可しません。さらに重要なのは、バックエンド アズ ア サービス (BaaS) を含むより複雑なワークフローを考慮すると、BaaS オファリングは通常、同じプロバイダーからの FaaS オファリングをネイティブにトリガーすることしかできないことです。これにより、サーバーレス コンピューティングでのワークロードの移行は事実上不可能になります。したがって、マルチクラウドの観点からサーバーレス ワークフローを設計および展開する方法を検討することは有望に思われ、普及し始めています^{[いつ? ]}。^{[34] [35] [36]}

DevSecOpsの実践に従うことで、サーバーレス技術をより効果的に使用し、保護することができます。^[37]サーバーレスアプリケーションでは、インフラストラクチャとビジネスロジックの境界が曖昧で、アプリは通常、さまざまなサービスに分散しています。 Yan Cuiによると、テストの取り組みから最大の価値を得るには、サーバーレスアプリケーションは主に統合についてテストする必要があり、複雑なビジネスロジックがある場合にのみユニットテストを使用する必要があると言えます。また、サーバーレスアプリケーションのデバッグと実装を容易にするために、開発者はマイクロサービスの境界付けられたコンテキスト内でオーケストレーションを使用し、境界付けられたコンテキスト間で振り付けを使用する必要があります。 ^[5]

Yan Cuiによると、高い凝集性を実現するためには、一時的なリソースをまとめて保持する必要がある。ただし、スピンアップ時間が長い共有リソース（AWS RDSクラスタなど）とランディングゾーンには、独自のリポジトリ、デプロイメントパイプライン、スタックを用意する必要がある。^[5]

サーバーレス関数は次のような用途に使用できます。^[38]

• データ分析
• ストリーミングビデオ処理
• CI/CD オペレーション
• ファイル変換
• ログの集約と再構築
• 動的なウェブサイトコンテンツのサポート

• クラウドコンピューティング
• サービスとしての機能

• Roberts, Mike (2016 年 7 月 25 日)。「サーバーレス アーキテクチャ」。MartinFowler.com。2016年7月 30 日閲覧。
• Jamieson, Frazer (2017 年 9 月 4 日)。「サーバーがなくなる? 誰もがサーバーレス アーキテクチャについて話している」BCS、Chartered Institute for IT。2017年11 月 7 日閲覧。
• アンダーソン、デビッド (2022 年 3 月 9 日)。「『バリュー フライホイール効果』で未来を強化し、組織を最新のクラウドとサーバーレスに加速」。The Serverless Edge。2022年3 月 9 日閲覧。
• カリフォルニア大学バークレー校の14人の著者（2019年2月9日）。「クラウドプログラミングの簡素化：サーバーレスコンピューティングに関するバークレーの見解^[1]」。