なぜ私は Kubernetes に「洗脳」されたのでしょうか?

Kubernetes はコンテナ オーケストレーションの戦いに勝利し、将来的には「マルチクラウド」の上位の標準レイヤーとなり、分散システムの分散と運用に根本的な変化をもたらす可能性があります。徐々に Linux カーネルのようなシステムレベルのサポートになり、注目されなくなるでしょう。

この記事からの引用:

• Kubernetes を使用すると、分散システム ツールにネットワーク効果が生まれます。 Kubernetes 用の新しいツールが作られるたびに、他のすべてのツールも改善されます。したがって、これにより、Kubernetes の標準としての地位がさらに強化されます。
• クラウド プロバイダーは互換性のある商品ではありません。さまざまなクラウドによって提供されるサービスは、ますます独自性と差異性を持つようになります。企業は、さまざまなクラウド プロバイダーのさまざまなサービスにアクセスできるというメリットを得られます。
• マルチノード アプリケーションの信頼性がシングルノード アプリケーションと同等になると、価格モデルに変化が見られます。
• だからこそ、私は Kubernetes にとても惹かれたのです。Kubernetes は異機種システム全体にわたる標準レイヤーなのです。
• 今後は、コンパイラやオペレーティング システム カーネルについて話すのと同じように Kubernetes について話す予定です。 Kubernetes は、一般的なアプリケーション開発者の手の届かない低レベルの配管システムになります。

Kubernetes は分散アプリケーションをデプロイするための標準的な方法になりました。それほど遠くない将来、新しく設立されたインターネット企業は、認識しているかどうかにかかわらず、Kubernetes を使用することになるでしょう。多くのレガシー アプリケーションも Kubernetes に移行されています。

Kubernetes 以前は、特定の分散システム プラットフォームの標準は存在しませんでした。 Linux が個々のノードの標準的なサーバー側オペレーティング システムであるのと同様に、Kubernetes はアプリケーション ノードをオーケストレーションする標準的な方法になっています。

Kubernetes を使用すると、分散システム ツールにネットワーク効果が生まれます。 Kubernetes 用の新しいツールが作られるたびに、他のすべてのツールも改善されます。したがって、これにより、Kubernetes の標準としての地位がさらに強化されます。

Google、Microsoft、Amazon、IBM はいずれも独自の Kubernetes-as-a-service を提供しており、主要なクラウド プロバイダー間でインフラストラクチャを切り替えることが容易になっています。

おそらく、Digital Ocean、Heroku、その他のロングテール クラウド プロバイダーが、マネージドおよびホスト型の Kubernetes サービスの提供を開始するでしょう。

この記事では、以下の質問について検討します。

• なぜこのようなことが起こるのでしょうか?
• これは開発者にとって何を意味するのでしょうか?
• クラウドプロバイダーはどのような影響を受けるでしょうか?
• Kubernetes が標準化された世界では、どのような新しいビジネス モデルが生まれるのでしょうか?

ソフトウェア標準

標準化されたソフトウェア プラットフォームには、利点と欠点の両方があります。

標準により、開発者はソフトウェアがどのように機能するべきかについて一定の期待を持つことができます。開発者が標準化されたプラットフォーム向けに製品を構築する場合、そのソフトウェアの総対象市場規模を推定できます。

JavaScript でプログラムを書くと、それが誰のブラウザでも実行されることがわかります。 iOS 向けのゲームを作成した場合、iPhone を持っている人なら誰でもそれをダウンロードできることがわかります。

.NET でガベージ コレクションを分析するツールを構築した場合、多数の Windows 開発者がメモリの問題を抱えていることがわかり、彼らはそのソフトウェアを購入するでしょう。

標準化された独自のプラットフォームは、プラットフォームプロバイダーに莫大な利益を生み出すことができます。 1995 年当時、Windows は非常に優れたプラットフォームであったため、Microsoft は段ボール箱に入った CD を 100 ドルで販売することができました。

2018年、iPhoneは非常に優れたプラットフォームとなり、Appleは同プラットフォーム上の全アプリ販売の30%を占めることができました。

しかし、独自の標準は断片化につながる可能性があります。

たとえば、iPhone アプリは Kindle Fire では動作しません。 Snapchat ARステッカーをFacebook Messengerで使用できません。

私のお気に入りのデジタルオーディオワークステーション[1]はWindowsでしか動作しないため、音楽を作るにはWindowsコンピューターを使用する必要があります。

開発者はこのような断片化を見ると不満を漏らします。彼らは、金儲けのためにソフトウェアの品質を犠牲にすることをいとわない貪欲な資本家を思い浮かべるでしょう。

開発者たちは疑問に思う。「なぜ人々は仲良くやっていけないのか？」なぜすべてをオープンかつ自由にしておくことができないのでしょうか?開発者も、「独自の標準は必要ありません。オープン標準を使用できます。」と考えるでしょう。

これは、LAMP (Linux、Apache、MySQL、PHP) スタックの一部である Apache の成長とともに Linux で起こりました。

現在、ほとんどの新しいサーバー側アプリケーションは Linux を使用しています。しかし、これが物議を醸した時代もありました。上の画像の一番左の部分をご覧ください。

最近、新しいオープン スタンダードである Docker も登場しました。 Docker は、単一のノードをパッケージ化、デプロイ、配布するためのオープンで標準化された方法を提供します。

これは非常に貴重です！しかし、Docker が解決するすべての大きな問題の中で、1 つの新しい問題が際立っています。それは、これらのノードをどのようにオーケストレーションするかということです。

結局のところ、アプリケーションは単なる単一のノード以上のものになります。 Docker コンテナをデプロイしたいのはわかっていますが、コンテナは互いにどのように通信すればよいのでしょうか?コンテナインスタンスをどのようにスケールアップしますか?コンテナインスタンス間でトラフィックをどのようにルーティングしますか?

コンテナオーケストレーション

Docker が普及した後、コンテナ オーケストレーションの問題を解決するために、多数のオープン ソース プロジェクトと独自のプラットフォームが登場しました。

Mesos、Docker Swarm、Kubernetes はすべて、コンテナを管理するためのさまざまな抽象化を提供します。 Amazon ECS は、AWS ユーザーに Docker コンテナのインストールとスケーリングを提供する専用のマネージドサービスを提供します。

一部の開発者はオーケストレーション プラットフォームを使用せず、BASH、Puppet、Chef などのツールを使用してデプロイメントをスクリプト化します。

開発者がコンテナをデプロイするためにオーケストレーション プラットフォームまたはスクリプトを使用するかどうかにかかわらず、Docker は開発をスピードアップし、開発者と運用の間の調和を高めることができます。

コンテナのデプロイに Docker を使用する開発者が増えるにつれて、オーケストレーション プラットフォームの重要性がますます高まっています。コンテナは分散システムにとって、オブジェクトがオブジェクト指向プログラムにとってであるのと同じである[2]。

誰もがコンテナ プラットフォームを使いたいと考えていますが、多くのプラットフォーム間で競争があり、最終的にどのプラットフォームが勝つかはわかりません。そのため、iOS と Android の競争のように、この競争は 10 年以上続く可能性があります。

こうした競争が分裂を生み出している。これは、一般的なオーケストレーション フレームワークが独自のものであるためではなく (Swarm、Kubernetes、Mesos はすべてオープン ソースです)、各コンテナ オーケストレーション コミュニティがすでに独自のシステムに多大な投資を行っているためです。

そのため、2013年から2016年にかけて、Dockerユーザーは不安感を抱いていました。コンテナ オーケストレーション フレームワークの選択はギャンブルです。間違ったオーケストレーションシステムを選択した場合、それはビデオ店を開いてBlu-rayディスクの代わりにHD DVDを選択するようなものです[3]。

[[222273]]

コンテナ船が転覆する映像はいつまでも色褪せない。

あらゆる戦争と同様に、互いの姿が見えにくくなる霧が常に存在していました。コンテナ オーケストレーション戦争を取材していたとき、私はコンテナ オーケストレーションの専門家との会話を録音したポッドキャストを作成し、「それでは、どのコンテナ オーケストレーション システムが勝利するのでしょうか?」などの質問をしていました。

私が大いに尊敬する人が、そのような質問をするのは無意味であり、異なるオーケストレーター間の技術的なトレードオフを評価する方が良いと私に言うまで、私はこれを続けました。

振り返ってみると、さまざまなコンテナ オーケストレーター間の争いの話に巻き込まれてしまったことを後悔しています。

コンテナ オーケストレーターに関する議論が激化し、私のようなジャーナリストでさえも興奮して派閥争いの話になるだろうと思っていたのですが、最も賢い人々のほとんどは冷静かつ科学的に話していました。

コンテナ オーケストレーション戦争は派閥争いというより、意見や開発者のエンジニアリングの違いに関するものです。

[[222274]]

そうですね、コンテナ オーケストレーション戦争は単なる意見の相違以上のものなのかもしれません。なぜなら、この分野は多くの富を生み出すからです。現在、私たちは、徐々にクラウドに移行しつつある銀行、通信会社、保険会社などの数十億ドル規模のレガシー組織との契約について話し合っています。

通信事業者が適切なプラットフォームに移行するのを支援すれば、ビジネスはうまくいくでしょう。しかし、間違ったプラットフォームを採用すると、倉庫が HD DVD でいっぱいになってしまうでしょう。

2016年末、Docker社が自社のコンテナオーケストレーションシステムであるDocker Swarm[4]に適合するようにDocker標準を変更したかったため、Docker社が袂を分かつかもしれないという噂が流れ、対立は最悪となった。しかし、その場合でも、楽観主義者でいるのが賢明です。

破壊的なイノベーションは痛みを伴いますが、進歩の兆候でもあります。コンテナ オーケストレーションの優位性をめぐる戦いでは、多くの破壊的なイノベーションが起こってきました。

しかし、2016 年後半に霧が晴れると、Kubernetes が明確な勝者として浮上しました。

現在、Kubernetes が安全な選択肢となり、CIO は企業内でコンテナ オーケストレーションを導入することについてより安心感を抱いており、ベンダーは Kubernetes 固有のツールに投資してこれらの CIO に販売する意欲が高まっています。

現在の状況を見てみましょう:

• オープンソース開発者も同じ方向に進んでおり、何を構築できるかに興奮しています。
• 新旧を問わず大企業が徐々に Kubernetes を導入し始めています。
• 大手クラウドプロバイダーも、低コストの Kubernetes をサービスとして導入する準備ができています。
• 監視、ログ記録、セキュリティ、コンプライアンス ソフトウェア ベンダーも、統合する基盤となるソフトウェア スタックをより簡単に予測できるため、期待しています。

マルチクラウドへの移行

現在、独自のバックエンド開発者インフラストラクチャの最も収益性の高いプロバイダーは Amazon AWS です。開発者が AWS を嫌うのは、AWS が革新的で、機能が豊富で、安価だからではありません。 AWS に多額の資金を投入すれば、良いビジネスになります。

AWS を使用すると、開発者は 1990 年代に主流だった独自プラットフォームと同じようなロックインを感じることはありません。

しかし、まだロックダウン感は残っています。 AWS エコシステムに深く根ざし、DynamoDB、Amazon Elastic Container Service、Amazon Kinesis などのサービスを使用すると、Amazon から離れることは難しくなります。

ただし、Kubernetes はインフラストラクチャ用のオープンな共有レイヤーを作成するため、Kubernetes クラスターをあるクラウド プロバイダーから別のクラウド プロバイダーに「移行」することが理論的には可能です。

アプリケーションを移行する場合は、Amazon 固有のサービス (Amazon S3 など) の使用を停止するようにアプリケーションの一部を書き直す必要があります。

たとえば、どのクラウドでも動作するS3の代替品が必要な場合は、Rook[5]を使用してKubernetesクラスターを構成し、S3で使用するのと同じAPIを使用してRookにオブジェクトを保存できます。

これは素晴らしい選択肢ですが、Dropbox[6]を除いて、実際にアプリケーションをクラウドから移行したという話は聞いたことがありません。Dropboxの移行は非常に大規模だったため、2年半もかかりました[7]。

もちろん、Dropbox 以外にも Amazon S3 に多額の投資をしている企業は確かに存在し、独自のオブジェクト ストレージを作成したいと思っていても、移行には非常に手間がかかります。

(Kubernetes はアプリケーションの移行に使用できますが、異なるクラウド間で同様のオペレーティング レイヤーを提供するために使用される可能性が高くなります)

Kubernetes は、近い将来、アプリケーション移行に広く使用されるツールにはならないかもしれません。より可能性の高いシナリオは、Kubernetes が企業が複数のクラウドで使用できるユビキタスなコントロール プレーンになることです。

NodeJS は便利な類推です。サーバーサイドアプリケーションに NodeJS が好まれるのはなぜでしょうか?これは必ずしも NodeJS が最速の Web サーバーだからではなく、クライアントとサーバーの両方で同じ言語を使用することが好まれるためです。

NodeJS を使用すると、言語を切り替えることなくクライアントノードとサーバーノードを切り替えることができるのと同様に、Kubernetes を使用すると、操作方法を変更せずに異なるクラウドを切り替えることができます。

各クラウドには、Kubernetes によって実行され、そのクラウドによって提供されるマネージド サービスと対話するカスタム アプリケーション コードがいくつかあります。

企業がマルチクラウドを望むのは、災害復旧を考慮するためという理由もありますが、異なるクラウド上のマネージド サービスにアクセスできることに実用的な利点があるためでもあります。

新たなパターンとして、インフラストラクチャを AWS (ユーザー トラフィック用) と Google Cloud (データ エンジニアリング用) に分散することが挙げられます。 Thumbtack[8]はこのモデルを使用しています。

Thumbtack では、AWS にある本番環境インフラストラクチャでユーザーリクエストを処理します。トランザクション ログは AWS から Google Cloud にプッシュされ、そこでデータ エンジニアリングが行われます。

Google Cloud では、トランザクション レコードは Cloud PubSub のキューに入れられます。 Cloud PubSub はメッセージ キュー サービスです。これらのトランザクションはキューから取得され、大量のデータを保存およびクエリするためのシステムである BigQuery に保存されます。

BigQuery は、機械学習タスクを調整するときに人間がデータを取得するデータレイクとして機能します。これらの機械学習タスクは、Apache Spark を実行するサービスである Cloud Dataproc で実行されます。

モデルは Google Cloud でトレーニングされた後、ユーザー トラフィックを処理するために AWS にデプロイされます。 Google Cloud 側では、これらのさまざまなマネージド サービスのオーケストレーションは Apache Airflow によって行われます。

Apache Airflow はオープンソース ツールです。 Thumbtack が Google Cloud 上で管理される場合、Apache Airflow が必要です。

現在、Thumbtack はユーザーリクエストの処理に AWS を使用し、PubSub でのデータエンジニアリングとキューイングに Google Cloud を使用しています。 Thumbtack は Google で機械学習モデルをトレーニングし、AWS にデプロイします。

これは今日よく見られる現象です。 Thumbtack は、最終的にはユーザー向けサービスにも Google Cloud を使用する可能性があります。

日本企業が使用するマルチクラウド データ エンジニアリング パイプライン

複数のクラウドに移行する企業は徐々に増え、クラウドごとに個別の Kubernetes クラスターを管理する企業も出てくるでしょう。

Google では、BigQuery、Cloud PubSub、Google Cloud ML 間のワークロードをオーケストレーションするための GKE Kubernetes クラスタを導入している場合があります。

また、DynamoDB、Amazon Aurora、および本番環境の NodeJS アプリ間の負荷を調整するために、Amazon EKS クラスターを使用することもできます。

クラウド プロバイダーは互換性のある商品ではありません。さまざまなクラウドによって提供されるサービスは、ますます独自性と差異性を持つようになります。企業は、さまざまなクラウド プロバイダーのさまざまなサービスにアクセスできるというメリットを得られます。

分散システム分散

Google BigQuery および AWS Redshift サービスは、シンプルな API を備えた強力でスケーラブルなマルチノード ツールを提供するため、非常に人気があります。開発者は、これらのマネージド サービスが非常に使いやすいため、これらを選択することがよくあります。

個々のノード用の有料ツールは一般的ではありません。 NodeJS、React、Ruby on Rails に料金を支払う必要はありません。

単一ノード用のツールは、分散システム用のツールよりも使いやすいです。多数のサーバーに Hadoop を展開するのは、ラップトップで Ruby on Rails アプリを実行するよりもはるかに困難です。しかし、Kubernetes を使用すると、これらすべてが変わります。

Kubernetes を使用している場合は、Helm と呼ばれる分散システム パッケージ マネージャーを使用できます。 Kubernetes アプリケーション用の npm のようなものです。

Kubernetes を使用している場合は、どのクラウド プロバイダーを使用するかに関係なく、Helm を使用して複雑なマルチノード アプリケーションを簡単にインストールできます。

Helm の説明は次のとおりです。

Helm は Kubernetes アプリケーションの管理に役立ちます。 Helm Charts は、Kubernetes アプリケーションがどんなに複雑であっても、その定義、インストール、アップグレードに役立ちます。チャートは簡単に作成、バージョン管理、共有、公開できるので、Helm を使い始めて、コピー アンド ペーストの煩わしさから解放されましょう。

分散システム用のパッケージ マネージャー。信じられない！何をインストールできるか見てみましょう。

また、WordPress、Jenkins、Kafka もリストに含まれていません。

分散システムの構成は難しい。信じられない場合は、Kafka クラスターを設定した人に聞いてみてください。 Helm を使用すると、MacBook に Photoshop の新しいバージョンをインストールするのと同じくらい簡単に Kafka をインストールできます。そして、これはどのクラウドでも実行できます。

Helm以前、分散システムパッケージマネージャーに最も近いもの（私が知る限り）は、AWS[9]、Azure[10]、Google Cloud Launcher[11]上のアプリケーションマーケットプレイスでした。

ここでも、プロプライエタリなソフトウェアが断片化につながる可能性があることがわかります。 Helm が登場する前は、ワンクリックで Kafka をインストールできる、プラットフォームに依存しない標準的な方法はありませんでした。

AWS、Google、Azure での Kafka のワンクリック インストール方法が見つかります。ただし、これらの各インストールは、特定のクラウド プロバイダーごとに個別に作成する必要があります。 Digital OceanにKafkaをインストールするには、この10ステップのチュートリアルに従ってください[12]。

Helm は、任意の Kubernetes インスタンス上でマルチノード ソフトウェアを配布するためのクロスプラットフォーム システムです。任意のクラウド プロバイダーまたは独自のハードウェアに Helm がインストールされたアプリケーションを使用できます。

Apache Spark または Cassandra システムを簡単にインストールできます。セットアップと操作が非常に難しいことで有名です。

Helm は Kubernetes のパッケージ マネージャーですが、Kubernetes アプリ ストアのプロトタイプのようにも見えます。アプリ ストアを使用すると、Kubernetes 用のソフトウェアを販売できます。

どのようなソフトウェアを販売できますか?

Cloudera Hadoop、Databricks Spark、Confluent Kafka などの分散システム プラットフォームのエンタープライズ バージョンを販売できます。あるいは、Prometheus のような新しい監視システムや、インストールが難しい Cassandra のようなマルチノード データベースもあります。

Zendesk のような、より高度な消費者向けソフトウェアを販売することもできるかもしれません。

セルフホスト型の Zendesk というアイデアはクレイジーに聞こえるかもしれませんが、誰かがそれを構築して独自のバイナリとして販売し、サブスクリプションではなく定額料金を請求することは可能です。

Zendesk-for-Kubernetes を 99 ドルで販売し、AWS 上の Kubernetes クラスターで簡単に実行できれば、チケット ソフトウェアのサポート費用を大幅に節約できます。

企業では、自社のブログを管理するために独自の WordPress を運用することがよくあります。 Zendesk のソフトウェアは WordPress よりも複雑ですか?そうは思いませんが、企業は独自のブログ ソフトウェアを管理することよりも、独自のヘルプ デスク ソフトウェアを管理することを恐れています。

私は非常に小さな会社を経営していますが、さまざまな SaaS (Software as a Service) ツールを契約しています。高価な WordPress ホスト、広告販売用の高価な CRM ソフトウェア、ニュースレター用の MailChimp などが含まれます。

これらのサービスに料金を支払うのは、信頼性と安全性が非常に高く、複雑なマルチノード アプリケーションでもあるからです。自分のコンピューター室で実行したくありません。自分で管理するのも嫌です。ニュースレターの送信に失敗した場合、技術的な問題を自分で解決したくありません。あまり多くのソフトウェアを実行したくない[13]。

対照的に、スタンドアロン ソフトウェアが失敗することについて私は心配していません。

スタンドアロン ソフトウェアはサービスとして購入する必要がないため、コストがはるかに安くなることがよくあります。私が音楽を書くために使用するソフトウェアには、一度限りの固定費用がかかります。

Photoshop には 1 回限りの固定料金がかかります。コンピューターを稼働させるために電気代を払っていますが、それ以外に Photoshop を稼働させるための継続的な設備投資は必要ありません。

マルチノード アプリケーションの信頼性がシングルノード アプリケーションと同等になると、価格モデルに変化が見られます。

いつか Zendesk-for-Kubernetes を購入できるかもしれません。 Zendesk-for-Kubernetes は必要なものをすべて提供してくれます。

電子メール サーバーが起動し、チケットを管理するための Web フロント エンドが提供されます。何か問題が発生した場合、必要なときにサポート料金を支払うことができます。

Zendesk は素晴らしいサービスですが、固定価格モデルであればさらに良いでしょう。

メタ粒子

Kubernetes を使用すると、分散アプリケーションのデプロイと管理が容易になります。 Helm を使用すると、これらのアプリケーションを他のユーザーに配布することがさらに簡単になります。しかし、分散システムの開発は依然として非常に困難です。

これは、最近のCloudNative Con / KubeConでBrendan Burns氏が行った基調講演「分散システム開発を民主化するための新しいツール、パターン、パラダイムを構築することは信じられないほど難しい[14]」の焦点でした。

ブレンダンはスピーチの中で、Metaparticle と呼ばれるプロジェクトについて言及しました。 Metaparticle は、分散システムの民主化を目標としたクラウドネイティブ開発用の標準ライブラリです。ブレンダンはMetaparticle[15]の序文で次のように書いている。

クラウド ネイティブ開発はカスタムかつ複雑であり、少数の専門開発者に限定されます。 Metaparticle は、開発者の現在の状況に適合し、使い慣れたプログラミング言語でクラウドネイティブ システムの開発を開始できるようにする一連のユーティリティを使い慣れたプログラミング言語で導入することで、この状況を変えます。

Metaparticle は Kubernetes プリミティブ上に構築されており、分散調整を容易にします。 Metaparticle は、使い慣れたプログラミング言語で簡単に使用できる抽象化として、ロックとマスター選択のための言語に依存しないモジュールを提供します。

数十年にわたる分散システムの研究と応用を経て、これらのシステムを構築する方法のパターンが生まれました。 2 つのノードが非決定論的な方法で変数に書き込むことができないように、変数をロックする方法が必要です。

マスター ノードが停止したときに、他のノードが新しいノードを選択してシステムを調整できるように、マスター選択を行う方法が必要です。

現在、マスターの選択とロックを支援するために etcd や Zookeeper などのツールを使用していますが、これらのツールには統合コストがかかります。

Brendan は Zookeeper の例でこれを説明します。 Hadoop と Kafka はどちらもリーダー選出に Zookeeper を使用します。

Zookeeper の操作方法を学ぶには、多くの時間と労力を費やす必要があります。 Hadoop と Kafka を構築するにあたり、これらのプロジェクトの創設エンジニアは、Zookeeper と連携してマスター ノードを維持できるシステムを設計しました。

分散 MapReduce を実行するシステムを作成する場合、ノード障害や競合状態の影響を受けないようにする必要があります。 Brendan のアイデアは、これらの問題を標準ライブラリにプッシュして、次の開発者がマルチノード アプリケーションの新しいアイデアを思いつきやすくすることでした。

重要なメタポイント: Metaparticle を使用する前提は Kubernetes を使用することです。 Metaparticle は、基盤となる (分散) オペレーティング システムに関する想定に基づいて構築された言語レベルの抽象化です。これで標準の話題に戻ります。

全員が同じ分散オペレーティング システムを使用している場合、プロジェクトの下流のユーザーについてより詳細な想定を行うことができます。

これが私がKubernetesに洗脳された理由です。これは異種システム全体にわたる標準レイヤーです。

サーバーレスワークロード

Functions as a Service（「サーバーレス」関数とも呼ばれる）は、開発者が Kubernetes と一緒に、Kubernetes 上で、または場合によっては独自に使用できる強力で安価な抽象化です。

サーバーレス アプリケーションの現状を簡単に確認し、サーバーレスと Kubernetes の関係について考えてみましょう。

Function as a Service[16]の簡単な概要:

Function as a Service は、実行に特定のサーバーに依存しない展開可能な機能です。

Function as a Service は、開発者からの 1 回の呼び出しでデプロイ、実行、拡張できるように設計されています。サーバーレス関数を呼び出すまで、関数はどこでも実行されないため、生のコードが保存されているデータベース以外のリソースは使用されません。関数をサービスとして呼び出す場合、クラスターは関数のスケジュールと実行を担当します。

新しいマシンを起動してそのマシンを監視したり、アイドル状態のマシンをシャットダウンしたりする必要はありません。関数を実行したいことをクラスターに伝えるだけで、クラスターは関数を実行し、結果を返します。

サーバーレス関数をデプロイしても、関数コードは実際にはデプロイされません。コードはプレーンテキストとしてデータベースに保存されます。この関数を呼び出すと、コードがデータベース エントリから取得され、Docker コンテナーに読み込まれて実行されます。

AWS Lambdaは2014年に「サービスとしての機能」という概念を先駆的に導入しました[17]。それ以来、開発者はさまざまなユースケースを考えてきました。

開発者がサーバーレスをどのように使用しているかの完全なリストについては、CNCF Serverless Working Groupが作成した共有Google Doc（公開時点で34ページ）[18]を参照してください。

Software Engineering Daily での私の会話から、これらの機能をサービスとして使用する明確なユースケースが少なくとも 2 つあることがわかりました。

• バースト的なワークロードを処理するために迅速かつ安価に拡張できるコンピューティング（例：Yublのソーシャルメディアのスケーラビリティのケーススタディ[19]）。
• さまざまなワークロード頻度でのイベント駆動型グルーコード (複数のデータベース コンシューマーを持つイベント ソーシング モデルなど)。

Function as a Service (FaaS) プラットフォームを作成するために、クラウド プロバイダーは、invoker と呼ばれる Docker コンテナーのクラスターを提供します。

これらの呼び出し元は、コードの一部がディスパッチされるまで待機します。コードの実行を要求すると、コードが呼び出し元に読み込まれて実行されるまでしばらく待つ必要があります。この待機が「コールド スタート」の問題です。

コールド スタートの問題は、アプリケーションの一部を FaaS で実行することを決定したときに考慮しなければならないトレードオフの 1 つです。サーバーが何も作業していないときはサーバー実行時間に対して料金は発生しませんが、関数を呼び出す場合は、コードが呼び出し元にディスパッチされるまで待機する必要があります。

AWS では、AWS Lambda へのリクエストに呼び出し元が割り当てられます。 Microsoft Azure では、Azure Functions リクエストに呼び出し元が割り当てられます。 Google Cloud では、呼び出し元は Google Cloud Functions 用に予約されています。

ほとんどの開発者にとって、AWS、Microsoft、Google、または IBM の Function-as-a-Service プラットフォームを使用すれば十分でしょう。コストが低いため、ほとんどのアプリケーションではコールド スタートの問題は発生しません。しかし、開発者の中にはコストの削減を望む人もいるでしょう。

あるいは、呼び出し元コンテナにコードをスケジュールする方法を定義する独自のスケジューラを作成することもできます。これらの開発者は独自のサーバーレス プラットフォームを構築できます。

Kubeless のようなオープンソースの FaaS プロジェクトを使用すると、Kubernetes 上に独自のサーバーレス クラスターを構成できます。独自の呼び出し元のプールを定義し、計画に従ってコンテナをスケジュールする方法を決定し、クラスターのコールド スタートの問題を解決する方法を決定できます。

Kubernetes のオープンソース FaaS は単なるリソース スケジューラです。これらは、Kubernetes 上の他のカスタム スケジューラの単なるプレビューです。開発者は常に新しいスケジューラを構築しており、その上にさらに効率的なサービスを構築することができます。

では、Kubernetes 上には他にどのようなタイプのスケジューラが存在するのでしょうか?まあ、言われているように、未来はすでにここにありますが、これらのスケジューラは AWS マネージドサービスとしてのみ利用可能です。

AWS には、ストレージとコンピューティングを自動的に拡張するデータベースである Amazon Aurora Serverless という新しいサービスがあります。 AWS Serverless Auroraに関するJeff Barrの投稿[20]より:

Aurora DB インスタンスを作成するときに、必要なインスタンス サイズを選択し、読み取りレプリカを使用して読み取りスループットを向上させることができます。

処理のニーズやクエリ レートが変わった場合は、必要に応じてインスタンス サイズを変更したり、読み取りレプリカの数を変更したりできます。このモデルは、ワークロードが予測可能で、要求レートと処理要件が一定の範囲内にある環境で非常にうまく機能します。

場合によっては、ワークロードが断続的かつ予測不可能であり、1 日または 1 週間あたり数分または数時間続くリクエストのバーストでのみ発生することがあります。

フラッシュセール、不定期または 1 回限りのイベント、オンライン ゲーム、レポート ワークロード (時間単位または日単位)、開発/テスト、グリーンフィールド アプリケーションはすべて対象となります。適切な容量計画には多くの作業が必要になる場合があります。継続的に支払うことは賢明ではないかもしれません。

ストレージと処理は分離されているため、ゼロまでスケールダウンして、ストレージに対してのみ料金を支払うことが可能です。

これは本当に素晴らしいことだと思いますし、新しいタイプの一時的なアプリケーションにつながることを期待しています。スケーリングには数秒しかかからず、お客様のニーズを満たすことに熱心な「ホット」リソースのプール上に構築されます。

AWS がこのようなものを構築できたことに驚きはありませんが、Kubernetes が登場するまでは、これがオープンソース プロジェクトになるとは想像もつきませんでした。どの開発者でも、Kubernetes 上にこれらのタイプのシステムを構築できます。

Kubernetes 上に独自のサーバーレス データベースを構築する場合は、いくつかのスケジュールの問題を解決する必要があります。ネットワーク、ストレージ、ログ、バッファリング、キャッシュには、異なる層のリソースが必要です。異なるリソース層ごとに、需要に応じてリソースをスケールアップおよびスケールダウンする方法を定義する必要があります。

Kubeless が機能コードのごく一部にスケジューラを提供するのと同じように、大規模なアプリケーションのビルディング ブロックとして使用される他のカスタム スケジューラも登場する可能性があります。

サーバーレス データベースを実際に構築したら、Helm App Store で 99 ドルの 1 回限りの購入で販売できるかもしれません。

要約する

Kubernetes の歴史と将来についての考察を巡るこの旅を楽しんでいただけたなら幸いです。

2018 年はすでに始まっていますが、今年私たちが探求したい分野は次のとおりです。

• Kubernetes 上で機械学習モデルのデプロイメントをどのように管理するのでしょうか?私たちはマット・ザイラー[21]と一緒にプレゼンテーションを行い、そこで彼はこのことについて議論しましたが、それは複雑に聞こえます。
• Kubernetes は自動運転車で使用されていますか?もしそうなら、車全体を管理するためにクラスターを展開しますか?
• Kubernetes IoT のデプロイメントはどのようなものですか?ネットワーク接続が断続的なマシンのクラスターで Kubernetes を実行するのは意味があるでしょうか?
• Kubernetes を使用して構築された新しいインフラストラクチャ製品と開発ツールとは何ですか?新しいビジネスチャンスとは何でしょうか?

Kubernetes は最新のアプリケーション バックエンドを構築するための優れたツールですが、あくまでも単なるツールにすぎません。 Kubernetes がその使命を果たせば、最終的には背景に消えていくでしょう。今後は、コンパイラやオペレーティング システム カーネルについて話すのと同じように Kubernetes について話す予定です。

Kubernetes は、一般的なアプリケーション開発者の手の届かない低レベルの配管システムになります。

参照アドレス:

[1] https://www.image-line.com/flstudio/

[2] https://youtu.be/gCQfFXSHSxw?t=611

[3] https://en.wikipedia.org/wiki/High-definition_optical_disc_format_war

[4] https://softwareengineeringdaily.com/2016/10/03/docker-fork-with-alex-williams-and-joab-jackson/

[5] https://rook.io

[6] https://softwareengineeringdaily.com/2016/05/17/dropboxs-magic-pocket-james-cowling/

[7] https://www.wired.com/2016/03/epic-story-dropboxs-exodus-amazon-cloud-empire/

[8] https://softwareengineeringdaily.com/2017/11/28/thumbtack-infrastructor-with-nate-kupp/

[9] https://aws.amazon.com/marketplace

[10] https://aws.amazon.com/marketplace

[11] https://cloud.google.com/launcher/

[12] https://www.digitalocean.com/community/tutorials/how-to-install-apache-kafka-on-ubuntu-14-04

[13] https://softwareengineeringdaily.com/2017/11/20/run-less-software-with-rich-archbold/

[14] https://www.youtube.com/watch?v=gCQfFXSHSxw

[15] https://metaparticle.io/posts/welcome-to-metaparticle/

[16] https://www.softwaredaily.com/#/post/5a251d5f0cbcbe0004c932e1

[17] https://aws.amazon.com/cn/blogs/aws/run-code-cloud/

[18] https://docs.google.com/document/d/1UjW8bt5O8QBgQRILJVKZJej_IuNnxl20AJu9wA8wcdI/edit#Heading=h.yiaul8is1ki

[19] https://softwareengineeringdaily.com/2017/08/04/serverless-startup-with-yan-cui/

[20] https://aws.amazon.com/cn/blogs/aws/in-the-works-amazon-aurora-serverless/

[21] https://softwareengineeringdaily.com/2017/05/10/convolutional-neural-networks-with-matt-zeiler/