O'Reilly Velocity Conference 2018 San Jose参加レポート

Kubernetes

Canary deploys with Kubernetes and Istio

• 資料: Canary deploys with Kubernetes and Istio (PDF)

Istio自体の話に加え、Canary deployにおけるトラフィックの分散手法やモニタリング戦略について触れられたセッションでした。

個人的にはモニタリング戦略における異常検知の話が興味深く感じました。 異常検知の指標としてはLatency, Errors, Traffic, Saturationを用いるのがよいということです。 これは、SRE本の「Chapter 6. Monitoring Distributed Systems」でThe Four Golden Signalsとして挙げられているものです。

また、IstioのRoute Rules v1alpha3において従来のRouteRuleがVirtualServiceに置き換わった点についても触れられていました。 こちらについては以下のblogに詳細がありましたので、参考リンクとして載せておきます。

• Introducing the Istio v1alpha3 routing API

(與島)

Kubernetes security best practices

• 資料: Kubernetes security best practices (Speaker Deck)

Kubernetesの環境において次のリスクを軽減する手法を紹介したセッションでした。

• Runtime Security
• Host Security
• Network Security

登場する概念はRole Based Access Control, Firewall, Network Access Control, Permisiionなどです。基本的な考え方は非コンテナ環境と変わりませんが、具体的な設定方法についてもあわせて紹介されており、とても参考になる資料です。

(與島)

Integrating Vault and Kubernetes

• 資料: Vault Kubernetes Workshop on Google Cloud Platform (GitHub)

Kubernetesクラスターで管理されているアプリケーションやサービスで使用する認証情報などの秘密情報をHashiCorp Vaultで管理する方法についてのワークショップがありました。

このワークショップでは、まず、KubernetesクラスターとしてVaultサーバーのクラスターを作成しました。 このクラスター内にはVaultサーバーとサイドカーとしてVaultの初期設定を行うvault-initサービスが含まれています。なお、VaultのトークンはCloud KMSの鍵を使って暗号化や復号を行います。

次に、別のアプリケーションのKubernetesクラスターを作成し、Vaultサーバーから認証情報を取得して利用するという内容です。

ワークショップの資料が公開されているので、その手順に従ってこのワークショップを追体験できます。

(滝澤)

How we built Contour and what you can learn from our experience

• 資料: なし

KubernetesのIngress ControllerであるContourを開発した際のプラクティスが紹介されていました。 ディレクトリ構成や依存管理方式、Goroutineの管理やConcurrencyのハンドリングなどのコードベースのテクニックがまとまっています。 こういった実際プロダクト開発における具体的なプラクティスはとても参考になるため、何度も見返したくなる内容でした。

現時点で資料は公開されていませんが、KubeCon EU 2018で発表された資料がありましたので、リンクを載せておきます。

• How Heptio Built Contour Any What You Can Learn From Our Experiences (PDF)

(與島)

Containers

Containers: Let's get fancy

• 資料: Containers: Let's get fancy (Speaker Deck)

主にAWS環境におけるコンテナの運用テクニックとしてデプロイ高速化、クリーンアップ、AMIのカスタマイズなどについて紹介されていました。

ECSやEKSはバックエンドでAutoScalingやLoad Balancerが利用されています。これらの設定をチューニングしてコンテナのデプロイを最適化するという話がありました。 他にもイメージのクリーンアップに関するECSのパラメータや、独自AMIをECSのコンテナインスタンスとして利用する際の留意点など、実際の運用上参考になる情報が多くありました。

Monitoring, Observabilityについてもトピックの1つとして登場しました。 セッションの中で具体的な内容には触れられていませんでしたが、このあたりの話は弊社の守備範囲的にしっかり抑えておきたいので、深追いできればと思っています。

(與島)

Distributed Data

Scaling Square's Cash app with Vitess

• 資料: なし

Square社が提供する送金アプリCashのバックエンドは1台のMySQLから始まりました。 運用する中でデータベースにおいてどのような問題に直面して、Vitessを用いて解決してきたか紹介するセッションでした。

Vitessは2015年にYoutube社が公開したデータベースクラスタシステムです。 シャーディングを利用してMySQLを水平スケーリングします。 2018年の2月にはCloud Native Computing Fundation projectへ仲間入りしました。 これから日本でも利用したいと考える企業が増えてくると思い、話を聞きに行きました。

1台のMySQLで運用されていたCashをどのようにVitessに移行したか、また運用する中で発生した分散デッドロックについて話していました。 残念ながら資料が公開されておらず復習できていないため、まだ詳細は掴めておりませんので、これからも引き続き情報を追っていきたいと思います。

(阿部)

Continuous Delivery

Multicloud continuous delivery with Spinnaker

• 資料: Multi-Cloud Continuous Delivery With Spinnaker (Google Docs)

Netflix社がオープンソースソフトウェアとして公開したContinuous DeliveryのプラットフォームであるSpinnakerのチュートリアルでした。 同社のエンジニアに教えてもらいながらSpinnakerの利用方法を学ぶ大変貴重な経験となりました。

内容は、まず上記資料に沿って説明を受けました。 区切りの良いところで別途配布された資料を元にチュートリアルを実施しました。

具体的には以下を学びました。

• クラウドリソースを管理するNetflixのアプリケーション中心のモデルについて
• マルチクラウドとKubernetesへのデプロイについて
• Spinnakerとサードパーティーツールの連携について（Jenkins、Docker Repository）
• パイプライン、トリガー、ステージ、通知機能について
• Spinnakerの特徴を利用して新しいコードを安全にデプロイするためのベストプラクティス

実際に触ってみたことで、すばやく安全にContinuous Deliveryを実現する機能が一通り揃っていることを実感しました。

なお、すでにデプロイされたSpinnakerを利用して検証を行ったため、Spinnakerのデプロイについてはこれから勉強しようと思います。 ひとまず社内の検証環境にSpinnakerを用意してみて、興味のありそうな人と試していくところから始めます。

(阿部)

Authorization

The distributed authorization system: A Netflix case study

• 資料: Distributed Authorization System: A Netflix case study (PDF)

このセッションでは、Netflixがクラウドの分散システム環境において、どのように認可（Authorization, AuthZ）を行っているかを紹介していました。 さらに、認可のポリシー制御に利用しているOpen Policy Agent (OPA)についての紹介も行われました。

Open Policy Agent (OPA)は、オープンソースの汎用ポリシーエンジンです。公式サイトはこちらです。

• Open Policy Agent

OPAの特徴を資料から抜粋してみます。日本語は参考訳および補足として書きました。

• Decisions are decoupled from enforcement. （決定は実施から切り離されている）
  • サービスがOPAにポリシーのクエリーを行い、ポリシーの決定を回答として受け取ったサービスが認可を実施する。
• Evaluate policies locally. （ローカルでポリシーを評価する）
  • Daemon (HTTP API)
  • Library (Go)
  • Service Mesh (Istio)
• Fate Sharing （運命の共有）
  • サービスとOPAを同一ノードで動かすため、次のような特徴を持つ。
    • Low Latency
    • High Availability
• Policy and data are stored in-memory. （ポリシーとデータはインメモリに保管される）
• No external dependencies during enforcement. （実施中の外部依存はない）
• Declarative Language (Rego) （Regoという宣言的言語）

実際に利用するとなったら、各ノードに分散されたOPAのポリシーをどう更新するかという課題もあるかと思いますが、面白そうなのでOPAの動向を追いかけていきたいと思っています。

参考サイト

• Open Policy Agent
• open-policy-agent/opa (GitHub)

(滝澤)

Observability

Achieving observability at Google-scale with OpenCensus

• 資料: なし

このセッションでは、メトリック収集と分散トレーシングのフレームワークであるOpenCensusの紹介が行われました。

OpenCensusの公式サイトは次のサイトです。

• OpenCensus

OpenCensusはGoogle社内で利用しているCensusのオープンソース実装という位置づけです。

セッションの資料は公開されていないのですが、公式サイトに主な情報が記載されているので詳細はそちらを参照してください。

• OVERVIEW (OpenCensus)
• FAQ (OpenCensus)

開発言語毎の実装状況は次のページで確認できます。

• ROADMAP (OpenCensus)

セッションの最後の方で"What's next"として次のことが述べられていました。

• Integrations
• OpenCensus collector service
• Smarter sampling
• Client apps
• New partners

今後の話についてはブログ記事「OpenCensus's journey ahead: platforms and languages」でも言及されています。

"New partners"ということで、Microsoftの人が登場し、MicrosoftがOpenCensusプロジェクトに参加することをアナウンスしてセッションが終了しました。

なお、背景としてある "Observability" についてはTwitter社のブログを参照するとよいでしょう。

• Observability at Twitter
• Observability at Twitter: technical overview, part I
• Observability at Twitter: technical overview, part II

(滝澤)

Go

Go performance analysis in action

• 資料: github.com/campoy/go-tooling-workshop/3-dynamic-analysis

Goのプログラムのデバッグやパフォーマンス分析の方法を、各種ツールの紹介やユースケースの説明を受けながら、実際に手を動かして学ぶチュートリアルでした。

内容はDebugging, Unit Testing, Profiling, Tracingという4つのカテゴリに分かれています。 それぞれサンプルコードを用いながら以下のツールの利用方法を紹介していました。

• go test
• go tool cover
• go tool pprof
• delve
• go-wrk
• go-torch

資料は前述したGitHubで公開されています。チュートリアルもREADMEの内容に沿って進められていましたので、こちらを読み進めることで大体同じ内容が把握できます。

弊社ではhappo-agentやいくつかの社内ツールをGoで開発して、運用しています。 運用している中で、ときおりパフォーマンス問題に直面することもあります。そのため、原因調査や対策を行うために、このようなツールをちゃんと使えるということはとても重要だと感じました。個人的には今年のISUCONはGoで参加したいと思っているため、その意味でもとても有用でした。

(與島)

System Engineering & Archtecture

From dandelion to tree: Scaling Slack

• 資料: From Dandelion to Tree: Scaling Slack (PDF)

Slackが急成長する中でどのように技術的な問題を解決してきたか、というセッションでした。 タイトルの「From dandelion to tree」はたんぽぽほどの大きさであったサービスが木のように大きくなったという意味が込められています。

まずはSlackへの初期接続が遅くなってしまった問題をFlannel（詳細）を利用して解決した事例について解説してもらいました。 また、2017年10月31日に発生した大規模なサービス障害についても触れました。 この障害が再度発生しないように、もしくは発生しても早期に復旧させることができるためにはどうすればよいか現状考えているようです。 このように問題を解決していく中で、登壇者がなにを学んだか紹介して発表が終了となります。 学んだことのひとつに、Learn by doing、がありとにかく手を動かすしかないなと感じました。

このようにサービスが急成長していく中で大きな技術的な問題に直面します。 この発表を通してそんなときに自分はなにができるかふと考えてしまいました。 また、問題解決を通して技術的なこと以外でもなにが得られたか振り返ることが大事だな、と思いました。

(阿部)

Leadership

Scaling yourself during hypergrowth: Lessons learned managing managers

• 資料: Scaling yourself during hypergrowth (PDF)

Slack社のマネージャーを育てている人による優れたチームをマネジメントするためのベストプラクティスを紹介するセッションでした。

発表された10個のプラクティスは当たり前のことだけど、ふとできていないことに気づくようなことや、思わずはっとさせられるようなことが詰まっています。 マネージャーとして部下（マネージャーではなくても人）と接するときに、アクションを起こす前に立ち止まって思い出すと、助けになる金言ばかりだと思います。

Velocityではこのようによいサービスを提供するためのチームビルディングについても発表があります。 良い組織をつくるヒントが見つかるかも知れません。

(阿部)

Keynotes

Keynotesの中で特に興味深かったものを2つ紹介します。 動画を最後まで観るためにはO'Reilly Safari Books Onlineの会員になる必要がありますが、Free Trialがあるので興味がありましたらどうぞ。 （なお、弊社はO'Reilly社とは関係はありません）

• Velocity Conference - San Jose, CA 2018 (O'Reilly Safari Books Online)

(滝澤)

Reliability from the ground up: Designing for five nines

• 資料: なし
• 動画（ハイライト）: Reliability from the ground up: Designing for five nines

このセッションでは、信頼性の高い、弾力性のあるシステムをどのように設計するかという話をしていました。 システムを設計する上でかなり基本的な話ですが、大事な話なのでここで紹介します。

設計方針として5つのルールを紹介しました。

• Rule #1: Every node for itself
  • "Keep doing what you're doing, unless it's actively unsafe"
• Rule #2: Everything runs on more than one machine.
  • Idempotency: Serving components are stateless.
  • Sharding: Data is split across machines and replicated.
  • Multiple clusters provide better redundancy.
• Rule #3: Loosely coupled dependencies
• Rule #4: Design for change
  1. Use tools, not processes
  2. Check in your configs
  3. Canary all changes
  4. Rollbacks should alwayes be safe
• Rule #5: Observe the system, not the components

(滝澤)

Jepsen 9: The center cannot hold

• 資料: Jepsen 9
• 動画（ハイライト）: Jepsen 9: The center cannot hold

このセッションでは、分散システムに対してJepsenテストを行って、得られた結果を紹介していました。

なお、Jepsenは分散システム（特にデータベース、キュー、コンセンサスシステム）において安全性を改善する取り組みです。 分散システムへ障害を注入すること（fault injection）により、分散システムを検証することができます。

それぞれの分散システムに対して、パーティション分断が発生した場合に、スプリットブレインの問題が発生するかなど、興味深い内容でした。

スライドの一枚に次のような言葉が書いてあり、そうだそうだと思いながら話を聴いていました。

DISTRIBUTED LOCKS AREN'T REAL

参考サイト:

• Jepsen
• Jepsen (GitHub)

(滝澤)

最後に

最後に、参加したメンバーからの感想を掲載します。

海外出張ははじめてだったので大変なことがたくさんありましたが、世界のエンジニアたちを目の前にして様々なことを思いました。

ぼくにとってははじめての海外のカンファレンスでした。 内心では、見たこともないようなすごい人がいたりどうなってるのかわからない技術ばかりなのではないかと思っていましたが、それだけではありませんでした。 いろんな発表を通して当たり前のことをちゃんとできることが大切なのだと強く感じました。 発表内容は箇条書きにしてスライドに書いてみると、たしかにそうだと思うことがたくさんありました。 それを実践することが難しいのです。

今回の出張は、興味のある技術を追いながら目の前のことをちゃんとできるように意識しよう、と思わせてくれた良い経験でした。

(阿部)

Kubernetes, Containersがトピックのセッションを選んで参加しました。 セッションの内容は実運用に近い具体的なものが多かったように感じます。このような話をまとめて聞ける機会はあまりないため、とても貴重な時間でした。

アプリケーションコンテナ、コンテナオーケストレーションが普及していく中で、これらをきちんと運用するためには新しい概念に適応することが必要になります。 一方でベースの考え方は今までのシステム運用と大きく変わらない部分もあることに気づきました。 今すでに動いているシステム（非コンテナ環境）の運用に改めて向き合うきっかけにもなりました。

(與島)

滝澤がVelocity Conferenceに参加するのは今回で4回目です。

今年は主にKubernetesのセッションを聴いてきました。 セッション中でもスピーカーがKubernetesをプロダクション環境で利用している人を挙手させて確認していましたが、Kubernetesはもう普通に使われている状況なのを実感しました。

(滝澤)