What is the Serverless architecture?

時が経つにつれ、Serverless アーキテクチャはますます普及してきました。弾力的なスケーリング、従量課金制、低コストの運用保守といった特徴を備え、さまざまな分野で重要な役割を果たしています。機械学習の分野も近年非常に注目されており、ますます多くの業界で応用されています。

実際、機械学習プロジェクトには常に二つの課題があります。

・特にトラフィックのピークと谷の差が大きいプロジェクトでは、リソース占有率が高く利用率が低いため、リソースの無駄がより顕著です。

・デプロイメント、更新、保守の複雑性が高いことです。

Serverless は弾力的なスケーリング、従量課金制、低コストの運用保守などの特徴を備えています。Serverless アーキテクチャを機械学習プロジェクトに適用すれば、機械学習プロジェクトのパフォーマンスを確保するだけでなく、コスト削減とリソース利用率の向上も実現できます。これは研究と探求に値するテーマです。

これに基づき、Alibaba Cloud が公式に制作し、Alibaba Cloud と Ant Group の 4 名の専門家、Liu Yu、Tian Chudong、Lu Mengkai、Wang Renda（順不同）が Alibaba の Serverless アーキテクチャ下での AI 経験を体系的にまとめ、共著で新刊『Serverless アーキテクチャ下での AI アプリケーション開発：入門、実践、パフォーマンス最適化』を刊行しました。

本書は Serverless 公式アカウント（Serverless Devs）で無料連載されます。ぜひフォローしてください。

まえがき

本書は、Serverless アーキテクチャ下での機械学習実践に関する技術書です。Serverless アーキテクチャの基本的な紹介、プロジェクト開発経験のまとめ、および一般的な機械学習アルゴリズム、モデル、フレームワークの学習を通じて、機械学習プロジェクトを Serverless アーキテクチャに適用する方法、さまざまな機械学習プロジェクトと Serverless アーキテクチャの組み合わせ、および Serverless アーキテクチャに基づく機械学習アプリケーションの開発を探求しています。わかりやすい言葉、実践的なケーススタディ、オープンソースコードを通じて、Serverless アーキテクチャと機械学習の基礎知識を読者に伝えたいと考えています。

読者が本書を通じて、Serverless アーキテクチャと機械学習の組み合わせの重要な価値を真に理解し、Serverless アーキテクチャ下で機械学習プロジェクトをスムーズに開発・リリースして、クラウドコンピューティングがもたらす技術的配当をより直接的に享受できるよう願っています。

本書は基礎的な理論知識だけでなく、豊富な経験の共有や最新技術の実践的な応用も含んでおり、Serverless アーキテクチャ下での GPU インスタンスの活用、多次元コールドスタート最適化スキーム、Serverless アーキテクチャのマルチモードデバッグ機能などが含まれます。本書の学習を通じて、読者が Serverless アーキテクチャについてより包括的かつ直感的な理解を得て、Serverless アーキテクチャ下での機械学習についてより深い理解を持つことを願っています。

同時に、本書が読者の Serverless アーキテクチャ下での機械学習プロジェクトの実装と、クラウドコンピューティングの発展による技術的配当の獲得に役立つことを願っています。

第 1 章：Serverless アーキテクチャの基礎を紹介します。その発展、利点、課題などを含みます。

第 2 章：Serverless アーキテクチャの開発プロセス、ServerFul との開発プロセスの比較、従来のフレームワークからの移行などの観点から、Serverless アーキテクチャ下でのアプリケーション開発を紹介します。

第 3 章：サポートベクターマシンやニューラルネットワークなどのアルゴリズムとモデルの学習と研究を含め、機械学習に関連する探求を紹介します。

第 4 章：一般的な機械学習フレームワークと実践プロジェクトでの応用を紹介し、読者が一般的な機械学習フレームワークと Serverless アーキテクチャへのデプロイ計画を理解できるようにします。

第 5 章：機械学習が広く利用されているいくつかの分野でのプロジェクト実践を紹介します。画像認識、感情分析、モデルのアップグレード反復に関連する分野での探求が含まれ、コンテナイメージ、リザーブドインスタンス、GPU インスタンスなど、Serverless アーキテクチャの多くの新機能や特徴を取り上げています。

第 6 章と第 7 章：Serverless アーキテクチャと AI の組み合わせに関する二つの完全なケースを紹介します。プロジェクトの背景から関連モジュールの設計、プロジェクトの開発とデプロイまで、Serverless アーキテクチャ下での機械学習プロジェクトの起動、開発、保守の全プロセスを完全な流れで説明します。

第 8 章：Serverless アーキテクチャ上の関連する開発経験を共有し、Serverless アーキテクチャ下でのコールドスタート最適化スキームや開発時の注意事項を含め、Serverless アプリケーションの最適化方法をまとめます。

第 1 章 Serverless アーキテクチャの初歩的理解

本章では、Serverless アーキテクチャの概念を探求し、その利点、価値、課題と困難を分析し、アプリケーションシナリオを共有することで、読者に Serverless アーキテクチャの基本的な内容を紹介します。本章の学習を通じて、読者は Serverless アーキテクチャの理論的基礎について一定の理解を得ることができます。

Serverless アーキテクチャの概念

クラウドサービスの発展に伴い、コンピューティングリソースは高度に抽象化されてきました。物理マシンからクラウドサーバー、そしてコンテナサービスへと、コンピューティングリソースは段階的に細分化されています。

2012 年、Iron.io の副社長 Ken Form が「Why The Future of Software and Apps is Serverless」の記事で、サーバーレスの概念を初めて提唱しました。「クラウドコンピューティングが徐々に台頭しているにもかかわらず、人々は依然としてサーバーを中心に活動しています。しかし、この状況は長くは続きません。クラウドアプリケーションはサーバーレス化へと向かっており、これがアプリケーションの作成と配布に大きな影響を与えるでしょう」と指摘しました。

2019 年、UC Berkeley が論文「Cloud Programming Simplified: A Berkeley View on Serverless Computing」を発表しました。論文の中で著者は、「新しい BaaS ストレージサービスが発明され、Serverless コンピューティング上でより適応的に実行できるアプリケーションの種類が拡大されます。このようなストレージはローカルブロックストレージと同等の性能を発揮でき、一時的および永続的な選択肢を備えています。Serverless コンピューティングに基づく料金は ServerFul コンピューティングよりも安くなり、少なくとも同等以下となります。Serverless コンピューティングが技術的ブレークスルーを達成すれば、ServerFul サービスの衰退を招きます。Serverless はクラウド時代のデフォルトのコンピューティングパラダイムとなり、ServerFul コンピューティングに取って代わります。これは、サーバークライアントモデルの終焉も意味します」と鋭く断言しました。

Serverless アーキテクチャは 2012 年に初めて公の場に登場し、2019 年には UC Berkeley の鋭い断言の主役としてクラウドコンピューティング分野で注目を集め、「新たな視点」から「注目のアーキテクチャ」への移行を完了しました。この 7 年間で、Serverless アーキテクチャはほとんど知られていない状態から商用アプリケーションへと移行し、主要なクラウドベンダーがクラウドコンピューティング戦略として導入するまでになり、誰もが知る新しい技術パラダイムへと段階的に進化してきました。

もちろん、この 7 年間で、Serverless は技術アーキテクチャを段階的にアップグレード・改善しただけでなく、その概念と発展方向もより明確になってきました。Serverless の定義について、Martin Fowler は「Serverless Architectures」の記事で、Serverless は実際には BaaS と FaaS の組み合わせであると指摘しました。

このシンプルで明確な定義は、Serverless アーキテクチャの構成の基礎を築きました。図 1-1 に示すように、Martin Fowler は、Serverless アーキテクチャではアプリケーションのサーバー側のロジックの一部は依然として開発者によって実装されるが、従来のアーキテクチャとは異なり、ステートレスなコンピューティングコンテナで実行され、イベント駆動で、短いライフサイクル（場合によっては一度の呼び出しのみ）を持ち、サードパーティによって完全に管理されると考えています。この状況を Functions as a Service (FaaS) と呼びます。

さらに、Serverless アーキテクチャはサーバーロジックと状態を管理するために、サードパーティの（クラウド）アプリケーションやサービスにも部分的に依存しています。これらのアプリケーションは通常、リッチクライアントアプリケーション（シングルページアプリケーションやモバイルアプリ）であり、データベース（Parse、Firebase）やアカウントシステム（Auth0、AWS Cognito）などを含むクラウドサービスエコシステム上に構築されています。これらのサービスは元々 Backend as a Service (BaaS) と呼ばれていました。

図 1-1 Serverless アーキテクチャの構成

Serverless を FaaS と BaaS の組み合わせと考える見方は CNCF にも共有されています。CNCF は「CNCF WG Serverless Whitepaper v1.0」で Serverless アーキテクチャの定義をさらに精緻化しました。Serverless とは、サーバー管理を必要としないアプリケーションの構築と実行に関する概念を指します。より細かい粒度のデプロイモデルを表しており、アプリケーションを一つ以上の機能モジュールとしてパッケージ化し、プラットフォームにアップロードして、その時の正確なニーズに応じて実行、スケール、課金されます。

同時に、2019 年の UC Berkeley の論文「Cloud Programming Simplified: A Berkeley View on Serverless Computing」も、Serverless アーキテクチャの特性の観点から、Serverless の補足説明と定義を提供しています。端的に言えば、Serverless = FaaS + BaaS であり、弾力的なスケーリングと従量課金制の特性を備えている必要があります。

Serverless の概念は、中国信息通信研究院（以下、「研究院」）のクラウドネイティブ産業連盟が発表した「クラウドネイティブ開発白書（2020）」でも説明されています。サーバーレス（すなわち Serverless）はアーキテクチャ概念であり、その核心的な考え方は、サービスリソースを提供するインフラストラクチャをさまざまなサービスとして抽象化し、API インターフェースの形でオンデマンドにユーザーに提供し、本当の意味でのオンデマンドスケーリングと使用量ベースの課金を実現することです。

このアーキテクチャにより、従来の大量の常時稼働サーバーコンポーネントが不要になり、開発と運用保守の複雑さが軽減され、運用コストが削減されると同時にビジネスシステムの納期が短縮され、ユーザーはより価値密度の高いビジネスロジックの開発に集中できるようになります。

ここまでで、構造、動作、特性の観点からの Serverless アーキテクチャの定義を図 1-2 にまとめることができます。

図 1-2 さまざまな観点から Serverless アーキテクチャを定義する

Serverless アーキテクチャの特徴

ご存知の通り、物事には二面性があります。今日、クラウドコンピューティングの発展は大きく進展していますが、クラウドコンピューティングの最新のプロダクトである Serverless アーキテクチャには、その大きな利点の裏に無視できない課題もあります。

利点と価値

Amazon AWS の首席クラウドコンピューティング技術コンサルタント Fei Lianghong はかつて次のように述べています。現在、ほとんどの企業がアプリケーションを開発してサーバーにデプロイする際、パブリッククラウドかプライベートデータセンターかに関わらず、事前に必要なサーバー数、ストレージ容量、データベース機能を把握し、インフラ上にアプリケーションと依存ソフトウェアをデプロイして実行する必要があります。

これらの細部に時間をかけたくない場合、この要件を満たすシンプルなアーキテクチャはあるでしょうか。Serverless アーキテクチャが徐々に身近な存在になってきた今日、その答えは明らかです。

プロジェクトの立ち上げ過程では、一般的にホストリソースを申請する必要があります。このとき、ピーク時の最大コストを評価するために多くの時間と労力を費やす必要があります。あるサービスに最大消費量に基づいてリソースを申請した場合でも、ビジネスの安定性を確保しながらコストを節約するために、異なる時間帯でリソースを拡張・縮小する専任の担当者が必要です。

一部のサービスでは、申請されたリソースを最大コストを基準に評価する必要があります。トラフィックの谷が多く、大量のリソースの無駄が生じる可能性があっても、そうせざるを得ません。たとえば、データベースなど拡張が難しいアプリケーションでは、「ピーク時にリソース不足でサービスが提供できなくなるよりはましだ」という考え方です。

Fei Lianghong が述べたように、Serverless アーキテクチャではこの問題がより適切に解決されています。使用するリソース量を事前に計画するのではなく、実際のニーズに基づいてリソースを要求し、使用時間に応じて支払い、毎回適用されたコンピューティングリソースに基づいて課金されます。さらに、課金の粒度がより細かいため、リソースコストの削減にさらに有利です。

Serverless アーキテクチャには六つの潜在的な利点があります。

・オンデマンドで無制限のコンピューティングリソース

・クラウドユーザーの事前コミットメントを排除

・必要に応じて短期間でコンピューティングリソースに課金する能力

・大規模なコスト削減

・リソース仮想化による運用の簡素化と利用率の向上

・異なる組織からのワークロードの再利用によるハードウェア利用率の向上

従来のアーキテクチャと比較して、Serverless アーキテクチャにはビジネスへの集中、弾力的なスケーリング、従量課金制などの利点があります。これらの利点は、開発者が技術選定を行う際の重要な判断材料となることが多いです。

1. ビジネスへの集中

ビジネスへの集中とは、開発者が基盤リソースに多くの注意を払うことなく、自身のビジネスロジックにより集中できるようにすることを指します。

ご存知の通り、単一アーキテクチャ時代のアプリケーションは比較的シンプルで、物理サーバーのリソースでビジネスのデプロイを支えることができました。ビジネスの複雑さが急速に増すにつれて機能モジュールが複雑かつ膨大になり、単一アーキテクチャが開発とデプロイの効率を深刻に阻害するようになりました。その結果、ビジネス機能を切り離し、個別モジュールを並行開発・デプロイするマイクロサービスアーキテクチャが徐々に普及しました。ビジネスの細分化された管理は、必然的に基盤リソースの利用率向上を推進しました。

図 1-3 に示すように、仮想化技術は継続的に改善され広く採用されることで、物理リソースとのギャップを埋め、ユーザーのインフラ管理の負担を軽減してきました。コンテナと PaaS プラットフォームはさらに抽象化を進め、アプリケーションの依存サービス、実行環境、および基盤に必要なコンピューティングリソースを提供しています。これにより、アプリケーション開発、デプロイ、運用保守の全体的な効率がさらに向上しました。Serverless アーキテクチャはコンピューティングをより徹底的に抽象化し、アプリケーションアーキテクチャスタック内のあらゆるリソース管理をプラットフォームに委任することで、インフラの運用保守を不要にし、ユーザーが高価値のビジネス領域に集中できるようにします。

図 1-3 仮想マシン、コンテナ、Serverless アーキテクチャの進化図

2. 弾力的なスケーリング

弾力的なスケーリングとは、ビジネストラフィックの変動に応じてリソースを自動的に割り当て・破棄することで、安定性、高性能、リソース利用率の最適なバランスを最大化することを指します。

ご存知の通り、IaaS から PaaS、そして SaaS へと、脱サーバーの傾向がますます顕著になっています。Serverless アーキテクチャにより、脱サーバー化は新たな高みに達しました。ServerFul と比較して、Serverless はビジネスユーザーにとっての NoServer の考え方を強調しています。

NoServer とは、サーバーから切り離されることやサーバーが不要になることではなく、サーバーの稼働状態に関する懸念を取り除くことを意味します。つまり、サーバーの拡張・縮小に関する操作はもはやビジネス担当者の注意を必要とせず、すべてクラウドベンダーに任せられます。図 1-4 に示す折れ線グラフは、あるウェブサイトの一日のトラフィック推移です。

図 1-4 従来の仮想マシンアーキテクチャと Serverless アーキテクチャの弾力モードにおけるトラフィックと負荷の比較

図 1-4a の分析は以下の通りです。

・技術担当者はウェブサイトのリソース使用量を評価する必要があります。評価結果では、ウェブサイトの最大ピークトラフィックは 800 PV/時であり、対応する ECS を購入しました。

・しかし同日の 10:00 に、運用保守担当者はトラフィックが急増し、徐々に 800 PV/時に近づいていることを発見しました。このとき、運用保守担当者は新しい仮想マシンを購入してオンラインにし、環境を設定しました。最後に、マスターマシンに対応するポリシーを追加し、10〜15 時のトラフィックピークを乗り切りました。

・15:00 以降、運用保守担当者はトラフィックが通常に戻ったことを確認し、ポリシーを追加した仮想マシンを停止して追加リソースを解放しました。

・18:00 に、過負荷トラフィックの再到来を発見しました。

図 1-4b から、ロード容量が常にトラフィックに一致していることが明確に見て取れます（もちろん、実際のロード容量はある程度現在のトラフィックをやや上回る可能性があるという点はこの図自体の問題です）。つまり、従来の仮想マシンアーキテクチャでは技術者の介入なしにトラフィックのピークと谷を処理する必要がなく、その柔軟性（拡張と縮小の両方）はクラウドベンダーによって提供されます。

図 1-4 の分析から、Serverless アーキテクチャの柔軟性はある程度ベンダーの運用保守技術サポートに依存していることが容易に推測できます。

Serverless アーキテクチャは「より専門的な作業をより専門的な人々に任せ、開発者が自身のビジネスロジックにより集中できるようにする」ことを提唱しており、これは弾力的なモデルの非常に直感的な体現でもあります。

3. 従量課金制

従量課金制とは、Serverless アーキテクチャがユーザーの実際のリソース使用量に基づく支払いをサポートすることを意味し、ユーザー側のリソース利用効率を最大化し、コストを削減できます。従来の仮想マシンアーキテクチャでは、サーバーを購入して稼働させると、継続的にリソースを消費しコストが発生します。各サーバーの利用可能なリソースは限られており通常は固定されていますが、サーバーの負荷は刻々と異なり、リソース利用率も異なるため、従来の仮想マシンアーキテクチャでは比較的明らかなリソースの無駄が生じます。

一般的に、日中のリソース利用率は比較的高く、リソースの無駄は少なくなります。夜間のリソース利用率は低く、リソースの無駄は比較的高くなります。Forbes 誌の統計によると、商用および企業データセンターの典型的なサーバーは、平均最大処理能力出力のわずか 5%〜15% しか提供していないとのことであり、これは従来の仮想マシンアーキテクチャのリソース利用率と無駄に関する分析の正しさを疑いなく証明しています。

Serverless アーキテクチャでは、ユーザーがサービスプロバイダーにサーバー、データベース、アプリケーション、さらにはロジックの管理を委託できます。一方で、この方法はユーザーのメンテナンスの煩わしさを軽減し、もう一方で、ユーザーは実際の使用粒度に基づいてコストを支払うことができます。サービスプロバイダーにとっては、より多くのアイドルリソースを処理できます。これはコスト面でもグリーンコンピューティングの観点でも非常に優れています。

図 1-5 従来の仮想マシンアーキテクチャと Serverless アーキテクチャの弾力モードにおけるトラフィックとコストの比較

図 1-5 に示すように、折れ線グラフはあるウェブサイトの一日のトラフィック推移です。

図 1-5a は従来の仮想マシンアーキテクチャ下でのトラフィックとコストを示しています。一般的に、ビジネスの稼働前にリソース使用量の評価が必要です。スタッフがウェブサイトのリソース使用量を評価した後、1 時間あたり最大 1,300 PV に耐えられるサーバーを購入しました。

一日全体で、このサーバーが提供するコンピューティング能力の総量が影の面積であり、必要なコストも影の面積に対応するコンピューティング能力のコストです。しかし、明らかに、本当に有効なリソース使用とコスト支出はトラフィック曲線の下の部分のみであり、トラフィック曲線上の影の部分はリソース損失と追加支出です。

図 1-5b は Serverless アーキテクチャの弾力モード下でのコスト図を示しています。支出とトラフィックの関係が基本的に比例していることが明確に見て取れます。つまり、トラフィックが低い値のとき、対応するリソース使用量は比較的少なく、対応する支出も比較的少なくなります。トラフィックが高い値のとき、リソース使用量と支出は正の相関を示します。

プロセス全体を通じて、Serverless アーキテクチャは従来の仮想マシンアーキテクチャのように大幅なリソースの無駄や追加コストを発生させないことが明確に見て取れます。

図 1-5 の分析を通じて、Serverless アーキテクチャの柔軟なスケーラビリティが従量課金モデルと有機的に組み合わされることで、リソースの無駄を最小限に抑え、ビジネスコストを削減できることが容易に理解できます。

4. その他の利点

前述のビジネスへの集中、弾力的なスケーリング、従量課金制などの利点に加えて、Serverless アーキテクチャにはその他の利点もあります。

・ビジネス革新サイクルの短縮：Serverless アーキテクチャはある程度「クラウドベンダーがより多くの作業を引き受け、開発者が自身のビジネスにより集中できるようにする」モデルであるため、開発者は ServerFul アーキテクチャの OS レベル、仮想マシンレベル、システム環境レベルに費やす時間と労力を削減し、自身のビジネスロジックにより集中できると考えられます。この直接的な効果は、プロジェクトのリリース効率の向上、ビジネスの革新サイクルの短縮、開発とデリバリーの速度向上です。

・より高いシステムセキュリティ：Serverless アーキテクチャはある程度「ブラックボックス」的な視覚的印象を持っていますが、まさにこのため、Serverless アーキテクチャは通常インスタンスへのログイン機能を提供せず、システムの詳細を外部に公開しません。同時に、OS などのレベルのメンテナンスもクラウドベンダーに任せられます。これは、Serverless アーキテクチャがある程度より安全であることを意味します。一方で、Serverless アーキテクチャはスケジュールされたサービスとインターフェースのみを公開するため、仮想マシンと比較してブルートフォース攻撃のリスクがある程度回避されます。もう一方で、クラウドベンダーはより専門的なセキュリティチームとサーバー運用保守チームを持ち、開発者の全体的なビジネスセキュリティとサービスの安定性の確保を支援します。

・より安定したビジネス変更：Serverless アーキテクチャは、クラウドサービスプロバイダーが提供する天然の分散アーキテクチャです。同時に、NoServer の特徴により開発者がサーバーの稼働状態に対する懸念を払拭できるため、Serverless アーキテクチャ下では、開発者はクラウドベンダーが提供するツールを使用してビジネスコードと設定を簡単に変更できます。新しいビジネスロジックがスムーズに有効化された後、開発者はもはやそれに注意を払う必要がありません。したがって、Serverless アーキテクチャはビジネスのスムーズなアップグレード、変更管理、アジャイル開発、機能の反復、グレーリリースなどの面で大きな利点を持っています。

もちろん、上記で多くの Serverless アーキテクチャの利点を説明しましたが、それでもすべての利点と価値を列挙することはできません。しかし、Serverless アーキテクチャがより多くのチームや個人に注目され、受け入れられ、適用されており、その価値が急速に明確になってきていることは疑いようがありません。