Google Cloud Next '18でSpinnakerのセッションを聞いてきました!

こんにちは！SREの@ikemonnです。

7/24-26@San Franciscoで行われたGoogle Cloud Next '18に参加してきました。

いくつかのセッションを聞いてきたのですが、今回はKARTEのデプロイでも利用しているSpinnakerのセッション、Large-Scale Continuous Delivery at Netflix and Waze Using Spinnaker (Cloud Next '18) が面白かったのでご紹介します。

概要

• WazeでのSpinnakerの使い方
• Googleがリソースを割いてなぜSpinnakerを開発しているのか
• Spinnakerのroadmap
• まとめ

WazeでのSpinnakerの使い方

Wazeはmulti-cloud(AWS/GCP)でインフラを構成しています。
サービスが成長するにつれ、サーバが何千台にも増えていき次第にデプロイが大変になっていったそうです。
SREチームがデプロイにかかりっきりになり、batchやbug fixのデプロイやrollbackも気軽にできなくなってきた時にSpinnakerを見つけました。

OSS, multi-cloud対応したツールであることからSpinnakerの導入を決定しました。

Spinnakerを導入することで下記のメリットがあったそうです。

• SREチームにデプロイを頼まなくて良くなった
• rollbackやデプロイを部分的に行えるので改善サイクルが早くなった
• VM, k8s, AppEngine等を意識せずに統合的なインターフェースでデプロイできるようになった

しかし、しばらくするとpipeline数が増えすぎて(1000以上!)、UIからの管理が大変になってきました。

pipeline自体は個々で大きく異なっているわけではなく、ちょっとした差分があるだけだったのでtemplateを作り、そこからpipelineを作るようにしたそうです。

まず、bake -> smoke test -> deploy というpipelineのtemplateを作ることからはじめました。

v1ではまだリスクがあったので、canaryステージを追加し、 bake -> smoke test -> canary -> deploy を作ったりと徐々にpipelineを改善していったそうです。

pipelineをテンプレート化していることにより、1000以上pipelineがあっても変更をすぐに反映できて良かったとおっしゃっていました。

Wazeではデプロイ以外にもCassandraのデプロイにもSpinnakerを使っているそうです。

今後Wazeでは、SLO/error budget等のSREのコンセプトを考慮した、下記のようなデプロイを行う予定と言っていました。

• error budgetを超えそうになると自動的にカナリアデプロイの検証時間を長くする
• 普段は自動でデプロイされるけど、デプロイしてよいかを手動で決定しなければならないようにする

Googleがリソースを割いてなぜSpinnakerを開発しているのか

GoogleもSpinnakerの開発にリソースを割いているようで、去年に比べて現在では2倍の人員がいるようです。
Full timeの開発者が13人、PM/TPM/EngMgrが各1人と、かなりリソースを割いているようでした。

GoogleがSpinnaker開発に力を入れているのは、下記のような理由だそうです。

• Spinnakerで実現できることが社内のbest practice にマッチしている
• デプロイ、ロールバック等が抽象化されているので、multi-cloudなインフラでもそれぞれのcloudの詳細な知識なしにデプロイできる

Googleとして早い段階からSpinnakerの開発に関わっており、 2014年に20%プロジェクトとして、とあるエンジニアがSpinnakerに関わりだしたのが始まりだそうです。
そして、GCE, GKE, AppEngine等の機能を追加していったと言っていました。

Spinnakerのroadmap

上記がSpinnakerのroadmapです。
個人的に最も気になったのが Configuration as Codeについてでした。
デプロイ内容について宣言的なconfigを書いて、Codeとして管理できるようにしていくとのことです。
KARTEでは spinnaker/dcd-spec を使ってpipelineを管理しているので、dcd-specとの違いを後で質問しにいきました。
「dcd-specをより良くしたものをCLI経由で反映できるようにするよ」と教えてもらったのですが、まだ開発中なのか、具体的にどのようなものかは教えてもらえませんでした。
Spinnaker CLI Design Docを見ると、spinnaker/spin が上記のCLIのようです。

Spinnakerに関する情報についてはこちら

まとめ

Wazeのような大規模マルチクラウドインフラを運用している会社でもSpinnakerを使っていること、Googleも開発にリソースを割いていることから、Spinnakerを今後も継続して利用しておけばしばらく安心だと思いました。
他のセッションでもSpinnaker活用事例がいくつか発表されていたので、良いデプロイツールを探している方は一度触ってみると良いと思います。
KARTEへのSpinnaker導入時にバグを見つけ、PRを出したのですが、それをマージしてくれた Matt Duftlerに直接質問できたのが個人的に良かったです。

最後に

2018/8/3(金)に開催予定のプレイドオフィス移転パーティー ※エンジニア&デザイナー向けでもGCP Nextについて話す予定なので、お時間が空いている方はぜひぜひご参加ください！

また、KARTEでのSpinnakerの使い方は、2018/9/8(土)に行われるbuildersconのセッション:Multicloud deploy with Spinnakerで発表する予定なので、ご興味のある方はお越しください！

CXプラットフォーム「KARTE」を運営するプレイドでは、尖ったサービス/ツールを使いつつ大規模分散システムの構築/運用をしたいエンジニア（インターンも！）を募集しています。
詳しくは弊社採用ページ
またはWantedly
をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！