Brian Cox

The Latest From Brian Cox

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

  8月 26, 2021 | < 1 min read

  私はIT業界に入って数十年になりますが、コンピュータをより簡単に、より安く、より高い稼働率で使えるようにすることを常に追求しながら、テクノロジーの波を立ち上げる手助けをしてきました。これは私がIT業界に入る前から始まっており、私が引退する頃まで続くでしょう。しかし、私たちがどこにいたかを理解し、どのくらい進歩したかを見ることは、どうすればさらに良くしていくことができるかを理解する上で、常に良いことだと思います。結局のところ、コンピュータとは組織がお客様や市民に、より良いサービスを提供するために、手作業を自動化することなのです。 例えば、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のアップデートやセキュリティパッチなどが必要になります。 「コンテナオーケストレーションプラットフォームではトラフィックの変動を自動的に処理するように設定することができますが（セルフヒーリングやオートスケーリング）、それらのトラフィックパターンの変化を検知してコンテナを起動させたり、停止させたりするプロセスは瞬時にはできません。また、コンテナ関連のインフラがまったく稼働していない完全なシャットダウン（トラフィックがない場合など）もできません。ランタイムコストは必ず発生します。」 Serverless Inc社のPhillip Muns氏 サーバーレス 仮想化の次の進化はサーバーレス（Functions as a Service、FaaSと呼ばれることもあります）です。サーバーレス機能はコンテナ型のマイクロサービスよりも規模が小さく、システムへの依存関係を設定する必要がないため、迅速に導入することができます。コンテナは業界標準のx86マシン上で、現行のLinuxや特定バージョンのMicrosoft Windows Server OS上で動作するように構成されていますがサーバーレスは通常、パブリッククラウドサービス上に展開され、パブリッククラウドのアーキテクチャと密接に結びついています。そのため、サーバーレスの実装が異なると、機動性には優れているものの、独自性が高く、異なるクラウドベンダープラットフォーム間での移植性がないと考えられます。 現在、ベンダーのサポートやエコシステムのロックインにはいくつかの制限があります。プログラミング言語やランタイムはプロバイダがサポートしているものに限られます（ただし、これらの制限を克服するための回避策（または「shims」）もあります）。イベントソース（すべての機能のトリガーとなるもの）は通常、特定のクラウド・プロバイダが提供するサービスです。 Source: XenonStack サーバーレスという名前がついていますがサーバーレス機能はパブリッククラウドプロバイダのサーバー上で動作します。しかし、このサービスはバックエンドサービスを提供することに重点を置いており、アプリケーションを必要に応じて起動して実行することができますが特定のハードウェアへの設定の負担を開発者から取り除くことができるため、サーバーレスと呼ばれています。サーバーレスの例としてはGoogle Cloud Functionsなどがあります。サーバーレスの利点はソフトウェア開発者がビジネスロジックに集中し、インフラはパブリッククラウドベンダーが提供するため、気にしなくて済むことです。 「その意味でトラフィックパターンの変化を自動的に検知し、瞬時に処理する必要がある場合にはサーバーレスは最適です。トラフィックがまったくない場合はアプリケーションを完全にシャットダウンすることさえできます。サーバーレスアプリケーションでは使用したリソースに対してのみ料金を支払うことになり、使用量がなければコストもかかりません。」ITNext社Javier Ramos氏    サーバーレスはコンテナの代替品ではありません。むしろ、両者は異なる目的を持ったツールであり、場合によっては組み合わせることもできます。詳しくは後述します。 サーバーレスはステートレスで短期的なアプリケーションのインスタンスに焦点を当てており、小さなサービス（または機能）の集合体としてリアルタイムに構築され、頻繁にプロビジョニングされ、使用されなくなるとデコミッションされます。これらのサーバーレスアプリケーションはビジネス機能を中心に構築されており、機能の起動はイベントによってトリガーされ、完全に自動化されたデプロイメントマシンによって独立してデプロイすることができます。典型的なユースケースは以下の通りです。 ステートレスなHTTPアプリケーション Webとモバイルのバックエンド リアルタイムまたはイベントドリブンなデータ処理 サーバーレス機能の利用者はレンタルされた固定のリソース（プロセッサのコア数やネットワーク帯域幅の割り当てなど）ではなく、これらの機能による計算時間の使用量に基づいて課金されます。サーバーレスは自動でスケールアップ、スケールダウンすることを目的としているため、使用量または消費量ベースのモデルは理にかなっています。未使用でレンタルされた固定のコンピュータ容量に無駄なコストをかける必要はありません。リソースをオートスケールするために遵守しなければならないポリシー上の前提条件もありません。そのため、必要に応じて容量を拡張することができ、新しいビジネス機能を展開するための市場投入までの時間を短縮することができます。デメリットとしてはサーバーレス機能がしばらく呼び出されなかった場合、過剰なプロビジョニングを避けるためにクラウドプロバイダが割り当てられたリソースを破棄し、他のサーバーレスアプリケーションが使用できるようにリソースを解放することが挙げられます。その場合、同じサーバーレス機能のセットを再構築したい時には、「コールドスタート」と呼ばれるように、一からやり直す必要があります。 前述したように、サーバーレスとコンテナは互いに後継者や代替となる技術ではなく、異なる用途をターゲットにしています。場合によっては両者を組み合わせて使うことで、両者のメリットを享受することができます。 JFrogのカンファレンス「SwampUp 2021」でGoogle社Phil…

  さらに見る