連載
» 2018年08月20日 05時00分 公開

Google Cloud Next ‘18発表まとめ(3):Google Cloud Next’18で発表された Cloud Services Platform、Knativeとは

Googleのクラウド事業部門Google Cloudが、2018年7月にサンフランシスコで年次カンファレンス「Google Cloud Next ‘18」を開催した。本連載では、同イベントにおける数々の発表を、クラウドエースおよび吉積情報のエンジニアが解説する。第3回は、Cloud Services PlatformおよびKnativeを紹介する。

[富永裕貴,クラウドエース株式会社]

 Google Cloudが2018年7月に開催したGoogle Cloud Platform(GCP)に関するイベント、Google Cloud Next ‘18では、コンテナ開発に関する数多くの新サービスが発表された。このうち、Cloud Services PlatformおよびKnativeを紹介する。

GCPの力をオンプレミスに、Cloud Services Platform発表

 これまでパブリッククラウド事業者は、オンプレミスでワークロードを実行している企業に対して、パブリッククラウドへのコンピューティングの移行を促すことがほとんどであった。

 Google Cloudが今回のイベントで発表した「Cloud Services Platform」は、このような従来の考え方とは異なる。クラウドのコンピューティングをオンプレミスで実行する手段として、自社製品として「GKE On-Prem」を用意している。

 GKE On-Premを利用することで、企業は自分たちのデータセンター内でGCPとの互換性が完全に保証された形でKubernetesクラスタを構築し、GCPのコンソールでそれらを集中的に管理できる。

 また、サービスメッシュを提供する「Istio」も、GoogleによるマネージドサービスとしてCloud Services Platformに含まれている。

 Istioを利用することで、Kubernetesクラスタ内で実行されるサービス間のトラフィックをアプリケーションレベルで分散し、カナリアリリースやBlue/Greenデプロイメントが可能になる。

 Istioは、2018年8月1日にバージョン1.0がリリースされた。

参照記事:「サービスメッシュ」「Istio」って何? どう使える? どう役立つ?

 同じくCloud Service Platformを構成する要素として、IstioとStackdriverの統合により新たに生まれた Stackdriver Service Monitoringは、サービス運用の改善を図るための指標を提供する。

 今回のイベント1日目の基調講演で確認できるように、クラスタで実行される全てのサービスの依存関係をグラフィカルに表示したり、GoogleがGoogleのサービスに対して実施しているのと同じ方法でモニタリングとアラートを行ったりすることで、自分たちのサービスのサービスレベルを計測することも可能である。

 Istioを用いることでマイクロサービスを管理し、サービスディスカバリを実現できるようになるが、これらのマイクロサービスはAPIとして社内外に提供される場合がほとんどである。

 一方、マイクロサービスとAPIの管理を担うものが Apigee API Management for Istioである。

 Apigeeを利用することで、APIの利用状況の表示、アクセスの提供などの機能に加え、開発者のためのポータルが利用できる。

 これらに加え、コンテナ向けに定義済みのワークロードを提供するGCP Marketplaceも登場しており、コンテナを用いたワークロードをすぐに構築することも可能である。

記事執筆時点でMarketplaceに存在する Kubernetes app

 パブリッククラウドのマネージドサービスにロックインされたくないという要望は常に存在していることは事実である。これらの定義済みのワークロードとGKE On-Premを併用することにより、自分たちの保有する環境でKubernetesクラスタを構築し、素早くシステムを構築することが可能になる。

 このように、クラウド、オンプレミスの場所を選ばず、コンテナのワークロードをサーバレスに、安定して実行するための基盤がCloud Services Platformである。

コンテナワークロードを「サーバレス」にするKnative

 Kubernetesは近年非常に注目されているオープンソースソフトウェア(OSS)であるが、Kubernetesクラスタで実行されるアプリケーションの開発や運用のためには、Kubernetesの設定ファイルを数多く作成し、クラスタへ設定を反映させる必要がある。

 開発者がこれらの設定ファイルに時間を掛ける必要がなく、アプリケーションコードの開発のみに集中できるようにするため、Kubernetes上でインフラストラクチャの運用、管理が不要なサーバレスアーキテクチャを実現するものがKnativeである。

 Knativeには、Knative Build、Knative Eventing、Knative Servingの3つの機能がある。

Knative Build

 Knative Buildは、コンテナのビルド設定ファイルに基づいてビルド方法を定義する役割を担う。

 全く新しいものであるかのように見えるが、Cloud Services Platformの登場と共にCloud Buildへと名前を変え、GitHubレポジトリとの連携が可能となった旧Container Builderと同一の役割を担うものであり、ビルドステップの定義方法も共通している部分が多い。

 Knative Buildは、Cloud Buildとは異なり、Kubernetesクラスタ上でGitHubなどからソースを取得し、自動テストやコンテナのビルドを実行した後にGoogle Container Registryへコンテナのpushを行い、Knativeへのデプロイを実行できる。

Knative Eventing

 Knative Eventingは、Google Cloud Pub/SubやApache Kafkaをデータソースとして、メッセージを受信して処理を実行できる。

 Knative EventingはCloud Native Computing Foundationが策定するCloud Eventsをデータソースとして利用できるように現在開発が進められている。

 イベントソースは抽象化されており、開発者はメッセージバスとして何が使われるのかを知る必要はない。

Knative Serving

 Knative Servingは、デプロイしたコンテナをホスティングする役割を担う。Servingを構成するのは、Service、Route、Configuration、Revisionの4つである。

 ServiceはConfigurationとRouteをコントールし、新しいRevisionのアプリケーションがデプロイされた際に、常に最新のRevisionへトラフィックを割り振るような設定が可能になっている。

 Configurationはアプリケーションコードと設定値を分離することが可能であり、Configurationを更新すると新しいRevisionが作成される。

 Routeはエンドポイントを1つ以上のRevisionへひも付けることができる。トラフィックに対して割合を指定して特定のRevisionへ割り振ることができ、カナリアリリースも可能になっている。

Knativeのユースケース

 Google Cloud Next ‘18では、「サーバレス」という単語が頻繁に登場したが、Googleの唱える「サーバレス」とは、運用が必要ない状態を示すものであるので注意が必要である。

 Knativeを採用することにより、今までのKubernetesでは必要だったDeploymentやServiceのyamlファイルは書く必要がなくなり、スケールについても、Horizontal Pod Autoscalerの設定が必要なくなる。

 これは確かに魅力的ではあるが、一方でKnativeを採用する場合に幾つか注意を払うべき点もある。

 まず、Knativeのインストールのためには、小さくてもn1-standard-4のマシンスペック3台でクラスタを構築することが推奨されている。n1-standard-4は、GCPにおいてはvCPUが4つ(物理コアが2つ)、メモリが15GBのマシンであり、決して小さくないコンピューティングリソースが必要である。

 そのため、既存のワークロードが小さい場合には、わざわざKnativeを採用するメリットは薄い。

 一方で、非常に大規模なワークロードを実行していて、サービスメッシュやゼロスケールコンテナ、カナリアリリースが必要な場合には、Knative採用のメリットは十分にある。

 本連載の次回は、機械学習/AI関連の話題をお届けする。

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。