Google Cloud Next '18 レポート

Cloud Services Platform らへんのレポート。
（ML, TPU, G Suite など他のトピックには関わっていない）

まとめ

Hybrid

• Cloud Services Platform
• Istio 1.0
• GKE on prem
• Go Cloud Project

Istio があればアプリケーションの変更無しにサービスの管理ができる。 GCP に持っていけば、それは恐らく Stackdriver などとの統合により便利になり、オンプレで持つならば Grafana, Zipkin などとの統合により似たような恩恵を得られる。加えて GKE on prem により Kubernetes がオンプレで GKE と同様に利用できるようになると、Istio によるサービス管理はクラウドオンプレ問わず一貫した方法で行うことができるようになる。

また Go Cloud Project も Hybrid の流れに沿うものであるため話題が入ったのだと考える。

Serverless

• GCF containers
• GKE serverless add-on
• Knative

Serverless ではコンテナによる Cloud Functions の機能追加があった。そして、そのコンテナは GKE serverless add-on により GKE にデプロイ可能となり、GKE で管理されるということは Hybrid になるということ。

Knative では Eventing により CloudEvents のイベント管理ができるらしい。 他にも Autoscaling を行う Serving やビルドを管理する Build のような、 Kubernetes を利用した modern development pattern の提供を目的としているらしい。

• CI/CD

Serverless の CI/CD に関するセッションがいくつかあった。内容としては聞くだけならば難しいことはないが、実際に組み立てるとすると面倒なものであり、Cloud Build や Knative により解決される。

流れとしては git push にフックしてテストからデプロイまでを実行する必要があり、必要なコンポーネントは提供されている。恐らくこれは Ops Centric な部分までは一般化できていないので、 Spinneker などが入るとどうなるかというところまでは踏み込んでいない。

Telemetry

SLO には Metrics が必要であり、問題の解決には Tracing が有用である。
これらはクラウドでは Stackdriver で解決され、オンプレでは OpenCensus, Prom, Zipkin で解決する。
ログの集約には fluentd（または fluentbit）が適当。

個人の感想

Hybrid について

Hybrid（または Openness）といったことが Next'18 で目立っていた。
GCP 上での実現手段に並べてオンプレではどう実現するのかというのが大抵のセッションで語られていたし、GKE on prem, Istio, Knative について取り上げられていることからも方向性としては Hybrid を推していた。 80% of enterprises are hybrid or multi-cloud であり(* day1 keynote)、 その複雑性を克服するのは顧客にとって必要になるということなのだろう。

Service	GCP	on prem
Kubernetes	GKE	Kubernetes
Serverless	App Engine, GCF, GKE serverless add-on	Knative
Telemetry	Stackdriver	Istio, Grafana, Prom, Zipkin, etc.
Build	Cloud Build	Knative

また、GKE on prem によって GCP の機能をそのままオンプレに持ってくるような（GCF & GKE serverless add-on のように）ことが可能となっているのは、かなりインパクトがあった。ただし、 Cloud Services Platform で語られていることに対してはコンセプトは理解できているように思うが、Knative と Cloud Build や GCF のように同一の領域にあるものが互いにどうなっているのか聞いただけ見ただけでは理解できていない。

Observability と Istio について

Metrics や Tracing は必要だ。Metrics がなければ SLO など測ることはできず、問題の解析として Tracing はかなり有用な情報となるのは実感として同意できる（*Optimizing and Troubleshooting Your Application, the Google Way）。

Metrics, Tracing はカバーされているとして、 Logging について（* Observability 3 ways: Logging, Metrics & Tracing）はどうかと考えると Stackdriver はそれをカバーしているが、fluentd/fluentbit などエージェント部分はあったがその先の部分をオンプレでどう実現するかということに対する一般的な解を示したセッションには当たらなかった。Logging については既に言うまでもないのか、まだ一般的な解がないのかは分からない。

Where Should I Run My Code? について

FaaS, PaaS, Container, VM と選択肢が増えるにつれどこで何を動かすのかという疑問があり、それに対して考え方を示してくれたセッション（* Where Should I Run My Code? Serverless, Containers, VMs and More）だった。結論的には It depends ではあるがコンテナにしてあればシフトは楽であるや、fit and constraint が紹介されており面白かった。

API Management Best Practices について

そこまで目新しいことはなく再確認となったセッション（* API Management Best Practices）だった。

• 価値をどのように測るか
  • to the End User
    • Application/Platform Usage, API Traffic Growth, and API Usage
  • to the Application Developer
    • Number of API Consuming Apps, Number of Developers, and Community Growth
  • Value Chain における KPI
    • API Consumption (Customer/Developer)
      • Time to Hello World and Number of Developers/Applications
    • API Exposure (API Team)
      • Speed/Cost to API
• そのための Management
  • Catalog, Self Service Onboarding, Documentation, Usage Reporting, and Productization/Monetization
• そのための Gateway
  • Access Control, Transformations/Mediation, Throttling/Quotas, Threat Protection, and Caching/Optimization

Istio の導入を考えた時に apigee のような API Gateway がある場合に互いにどう棲み分けられるのかというのが気になる点としてある。全体的な構成が語られたセッションには当たらなかったが、上のベストプラクティスにおいて Istio でカバーしていない主に対外向けの API 管理があることに変わりはないので、そこまで深く考える必要はないのかもしれない。