サーバーレス モデルを使用して Kubernetes (K8s) 上でコンテナを実行できる Google の Cloud Run サービスが一般提供され、El Reg がこれを簡単に試してみました。
Cloud Run は Google Cloud Platform と Anthos の両方に対応しており、オンプレミスまたは他のクラウドの Google Kubernetes Engine (GKE) で Cloud Run を使用するさまざまな方法を提供します。
このサービスのコンセプトは、開発者がコードとそれが実行されるコンテナに集中できるようにすることです。Cloud Runでコンテナをデプロイすると、需要に応じて0から1,000（デフォルトの最大値）以上まで自動スケーリングされます。
自動スケーリングは、CPU使用率、同時実行性（コンテナインスタンスあたりのリクエスト数）、そしてリクエスト数という3つの要素に基づいて行われます。デフォルトでは、各インスタンスは最大80件の同時リクエストをサポートしますが、Cloud RunがCPU使用率の上限に達したことを検出すると、上限に達する前に新しいインスタンスが作成されます。
コンテナベースであるため、64ビットLinuxベースであれば、ランタイムと依存関係に関するコンテナの構成は開発者の判断に委ねられます。コンテナはステートレスであるため、必要に応じてデータを提供および永続化するための追加サービスが必要になります。
Googleはこのモデルを「サーバーレスコンテナ」と呼んでいます。AWS Lambda、Azure Functions、Google Cloud Functionsなどのサーバーレスプラットフォームでは、フルマネージドのランタイムにコードをデプロイできます。コンテナを意識する必要がないため、よりクリーンな構成ですが、ランタイム環境の詳細にほとんど影響を与えられないため、柔軟性が低くなります。また、非効率になる可能性もあります。Cloud Functionsは一度に1つのリクエストしか処理できないため、混雑時にはインスタンスが複数作成されます。Cloud Runでは、この効率性を最大限に高めるために、この調整が可能です。
Hello World Cloud Run プロジェクト
私たちは Cloud Run をちょっとだけ実行してみました。GCP Cloud Shell をダウンロードし、Node.js 用に数行の JavaScript を記述し、Cloud Run でそれを GCP にデプロイしました。
Cloud RunはKnative APIをベースにしています。これはK8sを拡張し、Cloud Runで使用されるデプロイメント機能と自動スケーリング機能を提供します。ただし、GCP版のCloud Runを使用する場合、K8sが使用されない可能性があります。「KnativeはCloud RunのベースとなるAPIです。フルマネージド版のCloud Runでは、実際にはK8sクラスタを実行していません」と、Knative運営委員会のメンバーでもあるプロダクトマネージャーのDonna Malayeri氏はポッドキャストで述べています。「ただし、K8s APIサーバーはあります。つまり、アプリケーションのデプロイに使用するAPIは…Knative APIなのです。」
Cloud Run for Anthos や独自の K8s クラスタなどの他のシナリオでは、Cloud Run は K8s クラスタを使用します。
一つの企業が結果をコントロールしようとすべきではない
Apache 2.0ライセンスの下でオープンソース化されているKnativeをめぐっては、業界内で政治的な駆け引きが見られます。Kubernetesは、Linux Foundation傘下のCloud Native Computing Foundation（CNCF）によってメンテナンスされています。Knativeと、Knativeが利用するサービスメッシュであるIstioは、いずれCNCFに移管されると予想されていました。しかし、10月にGoogleは「当面の間」移管しないと発表し、コミュニティの多くの関係者を失望させました。
Googleは、運営委員会（現在はGoogleメンバー4名、Pivotal、IBM、Red Hat各1名）からの公開書簡という形でブログ投稿で回答しました。書簡では、運営委員会と技術監督委員会の今後のメンバー構成は、プロジェクトへのコード貢献と非コード貢献の両方に基づいて決定されると述べられています。また、「一つの企業が成果をコントロールしようとすべきではない」と述べ、「Knative商標」の保護に積極的に取り組み、必要に応じてGoogleからの法的支援を約束しています。これは、他社がKnativeをフォークするのを抑止することになるかもしれません。
この書簡は、Googleがなぜこのプロジェクトを財団に委託したがらないのかという疑問には触れていない。マラエリ氏は前述のポッドキャストでこの点について間接的に言及しているものの、かなり混乱を招いている。「運営委員会のパートナーとコミュニティ全体から聞いたフィードバックは、Googleはもはや唯一の貢献者ではないというものでした。今ではGoogleが貢献の60%を占めています。もう一度検討し、この領域を広げてみてはどうでしょうか」とマラエリ氏は述べ、「Knativeの多様性を高める」ことを約束した。そしてこう続けた。
Googleは、ベンダー中立の財団に管理を委ねることは「壁を突き飛ばす」ことであり、「オープンで活気のあるコミュニティ」の形成を妨げると考えているのでしょうか？
実のところ、GoogleはKnativeのコントロールを手放したくはなく、これを商業上の利点と捉えざるを得ません。同時に、クロスベンダープロジェクトであることを適切にアピールしたいとも考えています。この緊張関係は、今後も解消される可能性は低いでしょう。®
