開発者のためにアプリのデプロイを簡素化する – タイムシェアリングからサーバーレスまでの歴史

例えば、1880年にはアメリカの人口が増え過ぎて、国勢調査の結果を手作業で集計するのに7年もかかっていました。アメリカの国勢調査は十年に一度しか行われないのが幸いです。

Source: Wikipedia

自動化が重要な理由

コンピュータの最初の用途が政府機関のニーズであったことは驚くことではありません。しかし、このような自動化の需要はすぐに企業にも広がりましたが、そのためにはコンピュータがより手頃で、より利用しやすく、より柔軟にならなければなりませんでした。

コンピュータの黎明期には、お客様はそれぞれ自分のコンピュータシステムを所有し、管理していました。サービスプロバイダは存在しませんでした。その後、メインフレームのタイムシェアリングが登場し、これがサービスプロバイダがビジネスを開始するための入り口となりました。その後、ハイパーバイザーによる仮想マシン、コンテナそしてサーバーレスなど、さらなるパーティショニング/仮想化技術が登場しました。この記事のポイントはコンピュータをより軽快に、より利用しやすく、より柔軟に、そしてより低コストにするための、これらの「仮想化」技術の進歩を振り返ること、そしてこのことが開発者と運用者の両方にとって重要である理由を説明することです。その目的は私たちを平凡な作業から解放し、エンドユーザーにより良いサービスを提供するために、ビジネスのためのサービスを提供する新しいアプリケーションを作成してデプロイするという、真の付加価値を生み出す作業に専念できるようにすることです。

最初の飛躍

1970年代にデータセンターが大きく進化したのは1台のマシンに1人のユーザーや1つのアプリケーションが入っていた状態から、タイムシェアリングと呼ばれる共有サービスモデルに移行したことでした。ユーザごとの専用PCが比較的安価な現在とは異なり、1950年代から1970年代のメインフレーム・コンピュータはハードウェアだけで数百万ドルもする恐ろしく高価なマシンでした。さらに、1人のユーザーが1つのプログラムを使用するために、パンチカードや紙テープを使って入力するために、大量の計算待ち時間が必要でした。このような大型のシングルユーザー/シングルアプリケーションマシンでは投資対効果が低いため、複数のユーザーが1台のコンピューターを同時に使用できるように、計算資源を分割して割り当て、その分だけ請求するタイムシェアリングが始まりました。

Source: Computer Notes

タイムシェアリングは現在の仮想マシンやコンテナ、サーバーレスコンピュータの先駆けでした。しかし、タイムスシェアリングは利用可能なすべてのリソースが異なるタスクのためにユーザ間で迅速に切り替えられるという、粗い実装でした。ユーザは自分が唯一のユーザであるかのように錯覚するほど、十分に速い応答時間を経験しました。しかし、タイムシェアリングは障害が発生するたびにすべてのユーザに影響を与えました。タイムシェアリングにより、開発者は希少なメインフレームのリソースにアクセスできるようになりましたが、許容できるレイテンシーの限界を常に超えていました。

仮想マシン

仮想マシン、コンテナ、サーバーレスコンピュータはシステムの故障や侵害が異なるユーザに与える影響を最小限に抑えることで、この脆弱性に対処します。IBMがメインフレーム用に開発し、その後VMwareがx86業界標準コンピューティングで普及させた仮想マシンは特定のワークロードやユーザにリソースを割り当てる方法として、それぞれが独自のオペレーティングシステムとアプリケーションスタックを備えた個別のコンピューティングインスタンスを提供しました。これにより開発者は開発したアプリケーションがタイムシェアリングのレイテンシーに悩まされることがなくなりました。

Source: USF Explorer

コンテナ

コンテナはアプリケーション用に独立したインスタンスを提供しつつ、そのインスタンスがすべて単一のオペレーティングシステムを共有することで、システムのオーバーヘッドの負担を最小限に抑え、重要なリソースをより効率的に割り当てます。また、コンテナはハイパーバイザーを必要としないため、仮想マシンよりも高速に動作し、より迅速に起動・停止させることができます。コンテナはサイズが小さいため、1台のサーバーで数十台の仮想マシンを動かすのに比べて、数百台、数千台のコンテナを動かすことができます。コンテナの代表的な製品はシングルノードではDockerとOpen Container Initiative（OCI）、クラスタではKubernetesです。

Source: Docker

コンテナはOS、プログラミング言語、実行環境などバージョンごとのソフトウェアパッケージを自由に展開することができます。もちろん、この自由度にはコストがかかります。コンテナのセットアップや長期的なメンテナンスには労力が必要です。さらにモノリシックなアプリケーションをより小さなマイクロサービスに分割することで、それぞれにコンテナが必要になり、それらを連携させるためには何らかのオーケストレーションが必要になります。また、これらのコンテナには、それぞれOSのアップデートやセキュリティパッチなどが必要になります。

サーバーレス

仮想化の次の進化はサーバーレス（Functions as a Service、FaaSと呼ばれることもあります）です。サーバーレス機能はコンテナ型のマイクロサービスよりも規模が小さく、システムへの依存関係を設定する必要がないため、迅速に導入することができます。コンテナは業界標準のx86マシン上で、現行のLinuxや特定バージョンのMicrosoft Windows Server OS上で動作するように構成されていますがサーバーレスは通常、パブリッククラウドサービス上に展開され、パブリッククラウドのアーキテクチャと密接に結びついています。そのため、サーバーレスの実装が異なると、機動性には優れているものの、独自性が高く、異なるクラウドベンダープラットフォーム間での移植性がないと考えられます。
現在、ベンダーのサポートやエコシステムのロックインにはいくつかの制限があります。プログラミング言語やランタイムはプロバイダがサポートしているものに限られます（ただし、これらの制限を克服するための回避策（または「shims」）もあります）。イベントソース（すべての機能のトリガーとなるもの）は通常、特定のクラウド・プロバイダが提供するサービスです。

Source: XenonStack

サーバーレスという名前がついていますがサーバーレス機能はパブリッククラウドプロバイダのサーバー上で動作します。しかし、このサービスはバックエンドサービスを提供することに重点を置いており、アプリケーションを必要に応じて起動して実行することができますが特定のハードウェアへの設定の負担を開発者から取り除くことができるため、サーバーレスと呼ばれています。サーバーレスの例としてはGoogle Cloud Functionsなどがあります。サーバーレスの利点はソフトウェア開発者がビジネスロジックに集中し、インフラはパブリッククラウドベンダーが提供するため、気にしなくて済むことです。

 サーバーレスはコンテナの代替品ではありません。むしろ、両者は異なる目的を持ったツールであり、場合によっては組み合わせることもできます。詳しくは後述します。

サーバーレスはステートレスで短期的なアプリケーションのインスタンスに焦点を当てており、小さなサービス（または機能）の集合体としてリアルタイムに構築され、頻繁にプロビジョニングされ、使用されなくなるとデコミッションされます。これらのサーバーレスアプリケーションはビジネス機能を中心に構築されており、機能の起動はイベントによってトリガーされ、完全に自動化されたデプロイメントマシンによって独立してデプロイすることができます。典型的なユースケースは以下の通りです。

• ステートレスなHTTPアプリケーション
• Webとモバイルのバックエンド
• リアルタイムまたはイベントドリブンなデータ処理

サーバーレス機能の利用者はレンタルされた固定のリソース（プロセッサのコア数やネットワーク帯域幅の割り当てなど）ではなく、これらの機能による計算時間の使用量に基づいて課金されます。サーバーレスは自動でスケールアップ、スケールダウンすることを目的としているため、使用量または消費量ベースのモデルは理にかなっています。未使用でレンタルされた固定のコンピュータ容量に無駄なコストをかける必要はありません。リソースをオートスケールするために遵守しなければならないポリシー上の前提条件もありません。そのため、必要に応じて容量を拡張することができ、新しいビジネス機能を展開するための市場投入までの時間を短縮することができます。デメリットとしてはサーバーレス機能がしばらく呼び出されなかった場合、過剰なプロビジョニングを避けるためにクラウドプロバイダが割り当てられたリソースを破棄し、他のサーバーレスアプリケーションが使用できるようにリソースを解放することが挙げられます。その場合、同じサーバーレス機能のセットを再構築したい時には、「コールドスタート」と呼ばれるように、一からやり直す必要があります。

前述したように、サーバーレスとコンテナは互いに後継者や代替となる技術ではなく、異なる用途をターゲットにしています。場合によっては両者を組み合わせて使うことで、両者のメリットを享受することができます。

JFrogのカンファレンス「SwampUp 2021」でGoogle社Phil Beevers氏が発表したサーバーレスの概要がよく分かるセッションビデオ「The future of serverless, developing apps for the fast-paced world」をご紹介します。

Google Cloud Runを使ったハイブリッド・サーバーレスコンテナ

コンテナとサーバーレスの要素を組み合わせた例として、Google Cloud Runがあります。Google Cloud Runでは従来のサーバーレスのように何らかのイベントに基づいて関数群をトリガーするのではなく、サーバーレスと同じように軽快にHTTPリクエストを介してコンテナの実行を呼び出します。アプリケーションをコンテナにデプロイすることで、永続性を維持し、アクティブに使用されていないときに自動的にインスタンスをデコミッションしないというオプションがあります。さらに、Google Cloud Runでは従来のサーバーレスとは異なり、OSやランタイムのバージョン、割り当てられるハードウェアの種類や容量をより細かく管理できます。

Google Cloud Runがどのように機能し、どのようなメリットがあるのかについてはGoogle社Guillaume Laforge氏とAyrat Khayretdinov氏によるSwampUp 2021のセッションビデオ「Going Serverless, with Artifactory and Containers on Cloud Run」をご覧ください。

Source: Rob Morgan

開発者にとってはアプリケーションの永続性、割り当てるハードウェアの柔軟性、レガシーサービスの移行が必要な場合にコンテナとコンテナオーケストレーションを選択します。開発のスピード、自動スケーリング、ランタイムコストの大幅な削減が必要な場合はサーバーレスを選択します。Google Cloud Runのようなコンテナベースのハイブリッドサーバーレスではアクティブでないときでもインスタンスを維持でき、さらに消費ベースの課金で自動的にスケーリングできます。

タイムシェアリング、仮想マシン、コンテナ、サーバーレスなどコンピュータを仮想化する各段階でコスト、アプリケーションの導入のし易さ、またはその両方という、さまざまな問題に取り組んできました。

• タイムシェアリングではユーザやアプリケーションに割り当てられるハードウェアのコストを削減し、より多くの開発者がコンピュータにアクセスできるようにすることに重点が置かれた
• 仮想マシンではソフトウェアを基盤となるハードウェアから抽象化し、インフラの利用率を高め、インスタンスのサイズ変更や移行を可能にすることを目指した
• コンテナによってレガシーなプラットフォームから最新のプラットフォームまで、ハードウェアを超えたアプリケーションのポータビリティが得られ、何百、何千ものインスタンスを起動できるようになった
• サーバーレスではイベントをトリガーにして、アプリケーションに機能を自動的に組み込むことができ、非常にきめ細かい方法で利用した分だけ支払うことができる
• ハイブリッド・サーバーレスコンテナでサーバーレスの軽快さとコンテナの永続性を手に入れる

サーバーレスの革新性と開発者や開発者の管理者にもたらされるメリットについての詳細は「Serverless Guide to Success」をダウンロードしてください。