DSOC Infrastructure Group の 大澤 です。
GW も明けてしまいましたが、Google Cloud Next 2019 参加レポート後編です。
前編はこちら。 buildersbox.corp-sansan.com
Istio in Production: Day 2 Traffic Routing
Istio がとても気になっていたので聞きに行きました。サービスメッシュの定義、Istio の概要から入り、サイドカープロキシとして使われている Envoyや Istio のアーキテクチャといった、Istio 入門用セッションでした。
Istio 導入のメリットとして、Traffic Management をメインに解説されていました。
Istio がプロキシとして、コンテナ同士の通信の間に入るため、パーセント指定のトラフィック分割やコンテンツベースルーティングができます。デモではヘッダーの有無でリリース成果物（V1, V2）にリクエストを振り分けていました。
Circuit Breaker という、あるマイクロサービスでエラーが多発するようになったら即座にエラーを返して全体システムへの影響を軽減する仕組みや、意図的に障害を発生させることで障害発生時のテストを行い、障害に強いシステムを目指す Chaos Testing があります。極稀にですが、マネージドサービスや自社/他社の API サービスを信頼している前提でシステム設計されているのを目にすると、Netflix ではあえて日常的に障害を発生させていますし、適度に障害を起こすことがシステム全体の健全な運用に必要だと思いますね。
面白いと思ったのがアウトバウンド（Egress）はデフォルトですべてロックダウンされているとのことです。たとえクラスタ内であっても通信先が必ずしも信頼できるわけではない、メッシュ内のサービスであっても、メッシュ外サービスと同じように考える（ゼロトラスト）とのことです。同じネットワーク内だと多種多様な通信をしていると余計な通信まで許可してしまいがちになりますが、最小限に許可するのがベストなんですよね（当たり前）。
Kubernetes では Deployment によるローリングアップデートの場合、1% のトラフィックを新しいバージョンに流して問題が発生した場合にすぐに戻すことは難しいです。Istio ではトラフィックを細かく制御できるため、Canary Release（一部のトラフィックだけ新しいバージョンに流すこと）が可能です。
Istio で採用しているサイドカーによって、アプリケーションとネットワークが分離されているため、開発言語やライブラリに依存することなく、トラフィック制御や通信の暗号化、デプロイなどを実現できるのも大きなメリットです。
Canary Deployments With Istio and Kubernetes Using Spinnaker
DSOCでは Spinnaker を採用しているので個人的にとても楽しみなセッションだったのですが、参加できなくなってしまったので動画を見ました。
前半は Kubernetes の Canary Release を実現するためにビルトインの Deployment を使ったやり方と Istio を使ったやり方について、後半はデモを用いて Spinnaker による Canaery Release 及び分析の自動化の紹介でした。
Canary Release する場合、普通であれば現行バージョン（ここでは V1 とします）に新バージョン（V2 とします）の二つが存在し、V2 に少しずつトラフィックを流していくことを想像すると思います。リリースの準備が整ったかどうかについて分析する場合、ベースラインとなる現行バージョンと比較する必要がありますが、現行バージョンV1は少なくとも新バージョンV2より長時間稼働しているうえに、新バージョンV2とは流れるトラフィック量が異なるため、正確に比較することが難しいです。そのため、新バージョンV2と同じ数のインスタンス数（Kubernetes であれば Pod 数）分だけ、新たにベースライン用V1として作成し、新バージョンV2と同じ量のトラフィックを流すことで正確に比較できるようにします *1。
Kubernetes にビルトインされた、Deployment はラベル付けなど余計な作業なしでデプロイができますが、トラフィック量の分割が難しいです。例えば、三つの Deploymentに分けて Pod 数で調整することである程度トラフィックを分散できますが、本当にトラフィックが意図した量で分散できているかはロードバランサの特性に依存します。Istio によってパーセンテージのトラフィック分割ができますが、サブセットを追加・削除したり Canary の重み付けを変える場合は設定ファイルを都度修正しなければならず、人間の手だとミスが生じやすいため自動化が必要になります。
Spinnaker であれば、Template や Expression（式）によって設定や重み付けをパラメータ化することで、動的に設定を生成することができます。デモでは 10% だけ Canary Release した後に分析しパスできれば、 20% リリース&分析、30%、40% ･･･ と徐々に増やすパイプラインになっていました。規模を拡大すると、潜在的な問題（メモリリークや I/Oが遅いバグなど）が発生する可能性があるため、影響範囲が大きいサービスなどは徐々に拡大していった方が安全ですね。
Day 4
Cloud Next は三日間で終わりましたが、Google 社のご厚意で Mountain View にある Google Cloud Space にて Google 社員といくつかのテーマでセッション&ディスカッションさせていただく機会をいただきました。
Android のコードネームにちなんだ菓子、マスコットが置かれている名物スポットで撮影
最初は Google のイノベーションについて。自由にやらせることで出てくる、とりあえずトライしてみることが大事とのこと。例えば有名な 20% ルールは Google のミッションから外れなければ上司に相談の上、予算も必要最小限の範囲内で、業務時間を充てることができます。プロトタイプを何度も作って改善していくことでプロダクトは成長していき、たとえプロダクトがコケたとしても別プロダクトとなって生まれ変わることもあるそうです。
Google のミッション やコアのカルチャーは創業以来変わっておらず、個人的に最も好きだと思ったのが「自分の仕事に関係なくても助けてくれる」カルチャーです。Google に入社後はいろんな人が毎週一時間程度 OJT をやってくれるのでキャッチアップも問題なくできたとのことで、今度は自分が助ける側として自然にそういうことができる環境になっているとのことです。助けることで大きなインセンティブはないですがピアボーナスはもらえます。ピアボーナスによって、自分のコアを離れてヘルプをしていける、その結果自分の技術度が広がっていくこともあるそうです。弊社も Unipos を導入していますが、お互いに感謝や、称賛し合ったりする流れは感じています。
SRE についてのセッションでは、可用性、信頼性を 100% にする必要がなく、人間の心臓でさえ、可用性が 99.95%、たまに心拍が止まっても支障がないという話があり、とても共感しました。 バックエンドサービスであってもエンドユーザがいるのであれば、SLO は設定すべきで、会社のオペレーション、ビジネス、Devチームの三つ巴で決め、四半期に一度見直すのが理想です。
他にもハイブリッド/マルチクラウド、新サービス（Cloud Run）、BigQuery のアップデート情報の解説など、とてもボリューミーで疲れましたが有意義な時間となりました。
おわりに
海外カンファレンスに参加するのは初めての体験でしたが、とても楽しかったですし、刺激をたくさんもらいました。
英語はCTOの藤倉に頼りきりになってしまったので、また行くことがあるときに備えてもう少し勉強しておきます。
*1:詳細は Netflix のブログを参照
