ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

LEARN ENVOY - Routing Configuration — RDS

www.envoyproxy.io

ROUTING WITH A CONTROL PLANE

とあるのでやはり Control Plane のことを考えねばならんのか。


  • Large Scale に Envoy を Production で展開するには Control Plane が便利
  • Single Source of Truth として Configuration を管理できるので便利
  • Serving Routes via RDS
    • RDS は何かというと Route discovery service
    • Control Plane が API として RDS を実装して、それを Envoy から呼んで Routing Configuration を Dynamic に設定するんだろう
  • Best Practices for Routing Definitions
    • In order to scale out a single system for routing definitions, there are three key principles to follow:
      • Treat routes as data, not config
      • Distribute control to teams with ACLs
      • Design for changes with audit logs and rollbacks
  • 1: Treat routes as data

    • 言いたいことがイマイチわからないなー
    • バージョンコントロールとかにのせて Routing を 1つの yaml でみんなで管理しようとするのがよくないと言っている?
    • 何かしらの api 経由で更新するようにして、正しく動くことを保証して整合性を保つようにしろと言っている?
  • 2: Distribute control to teams

    • トラフィックのルーティングをサービスチームができるようにする
    • その場合、権限も一緒に渡す
    • それはそう
  • 3: Design for change

    • route の変更履歴は残そう
    • 誰がいつやったのか
    • ロールバックもできるようにしよう
    • それはそう

やっぱり Control Plane を扱ったことがないとイマイチつかみきれない展開が続いてつらい。

Boracay Island

現地でスマホからいくつか Twitter にはあげていたが、持っていった一眼でもいくつか撮っていて、見返すと美しかったので載せておく。

f:id:take_she12:20200201160737j:plainf:id:take_she12:20200201160807j:plainf:id:take_she12:20200201160811j:plainf:id:take_she12:20200201160820j:plainf:id:take_she12:20200201160829j:plainf:id:take_she12:20200201160921j:plainf:id:take_she12:20200201160930j:plainf:id:take_she12:20200201160928j:plain

年に1回は南の島のプールつきのホテルに泊まってビーチで「何もしない」をしないとダメだと強く思った。

SRE NEXT 2020 の運営と登壇をしてきた

してきた。

sre-next.dev

SRE Lounge の運営メンバーで、やろーぜ、と手探りではじめた、日本ではじめての SRE のカンファレンスが無事開催された。

運営のコアスタッフとして

主にコンテンツという点で、CFP の選定のリードを行いました。

外から見ると非常に楽しそうには見えますが、やってみるとかなりしんどかったです。

選定に関わった7人のコアスタッフのそれぞれの意見を。正解も基準もない中で、基準を作りながら、有限の枠数に納めなければなりません。

SRE Lounge への信頼もあったおかげで、たくさんの Proposal が集まり、非常にレベルの高い選定となり、嬉しい悲鳴でした。

ちなみに自分も Proposal を出したんですが、「自分の Proposal には一切意見ができない」という制約でやりましたので、フェアであることは一応書いておきます。ネガティブな意見に対してのコメント・言い訳もなしです。(だって他のひとは Proposal だけで判断されてるからね!)

最終的にはいい経験ができたし、自分も出すことでレベルの底上げができたと思うので出してよかったと思います。

当日の役割

RoomA のリーダーをやっていました。

これだけは後世に伝えておきたいんですが、「インカムをつけた状態で発表を聴くのは不可能」です。まじで。

Room のリーダーは「なんかあったときに・なんもないようにいい感じによろしく」みたいなポジションなので、基本的には RoomA にいるんですが、司会の @muziyoshiz さんが完璧な司会をし、当日スタッフのみなさんが自律的に動いてくれたことで用無しで無事に終わりました。

登壇

登壇もしました。登壇の時間と前後30分は時間をもらい、持ち場を離れてスピーカーとしての役割に集中しました。

なおここで運営スタッフである水色のTシャツからスピーカーの黒のTシャツに着替えました。

20分では全然足りず、早口になってしまい聴きにきたひとには認知負荷の高い発表になってしまったことは反省しています。

来たひとが追体験できる、あるいは来れなかったひとが話した内容を学べるよう、補足する記事を会社のブログで書く予定です。

嬉しいことに満員御礼(立ち見も出てました)でして、何か1つでも持って帰るものがあれば幸いです。

「SLOっていう言葉は知ってる。でもそれどうやって使うの?」って思うひとはきっと多かったんだろうと思います。そういうひとたちに向けて、僕が地道にやってきた半年間を語りました。

懇親会

@EGMC さんとメンテモードのときの 503 出た時の SLO の扱いどうする?って話をしたり、repro の @exxyan さんにちょうどこれから SLO 策定しようとしてるところだったので今度ゆっくり話しましょうって言ってもらえたり(Quipper と Repro は Shared Channel があるので優勝)、@hokkai7go さんに連れられてはてなの若者に「やればいいじゃん!やれるよ!」と雑ながらもきっと意味があったであろう言葉をかけたり、追いかけたい背中の1人である @rrraaayyy さんに「よかったよ」って背中叩かれて感激したり、@deeeet さんに「疲れたときは犬を飼え。そのときは相談しろ」と人生のアドバイスをもらったり、終了間際に@toshanan さんに一方的にファンコールをしたりしてとても楽しかった。

運営チーム

最高のチームでした。最高のチームでした。

このチームだからこそできました。

参加した方で、いいカンファレンスと思ったら、運営スタッフに会ったときに、「ありがとう」「最高だった」と伝えてあげてください。

スタッフ卒業

理由はいろいろあるんですが、卒業しました。あとはまかせました。

帰りの電車から翌朝にかけてコアスタッフにメッセージを書いて、いきなり挨拶して、スッっと抜けました。解散ライブをせずに解散発表するタイプのミュージシャンなんで、ごめんなさい!

12月の頭に抜けることを決めてから、本当に過ごす時間1つ1つが愛おしく、寂しく思いながらスタッフの仕事をやってました。みんな本当に、こんな適当で雑な僕を仲間に受け入れてくれてありがとうね。

おわりに

僕の SRE としてのキャリアは SRE Lounge / SRE NEXT とともにありました。きっとこれからもそうだと思います。

また何かの形でコミュニティに恩返しができるといいな。

そのために、追いかけたい背中を追いかけていこうね。

願わくば誰かにとっての追いかけたい背中になれますように。

英語進捗 2020 Jan.

とりあえず継続することができるようになってきたので、質と量を少しずつ伸ばしたい。

アメリカ人がなぜ英語喋れるかって1日中英語使ってるからやで理論に従うと、1日25分じゃ死んでも追いつけない。いや追いつけないんだろうけど、成長のスピードは遅い。3時間ぐらいにどうにか持っていきたい。

これ毎日捻出するの結構キツいな。

abceed は隙間時間と通勤電車といっても60分は行かないので、もっと隙間時間作るか、意図してやらないといけない。

シャドーイングに関しては、散歩しながらやる。痩せる気はしないけど一応健康意識が 1mm ぐらいはある。

最後技術学習と合わせてやらないとなので、まぁこれは英語というよりは普通に勉強と思えばできなくはない。

とにかく歩きと隙間時間を使って1時間ぐらい今まで浮いていた時間を活用しつつも、家で向き合ってやる時間はどうしても必要になってくる。たった3時間確保でもこれだけ難しいの厳しいな。

でも abceed すごい楽しいので TOEIC 受けるの楽しみになってきた。

シャドーイングの課題が、やっぱりいきなり聞くだけだとなかなか理解できないので、最初に script を読んでだいたい中身を理解してから聴くというのをやりたいが、それをやる前に移動してしまいできてないという状態になっていてよくない。なんとかしたい。

Business Trip 2020 Jan For Jakarta

Business Trip で Quipper の Jakarta Office に行ってきた。

10月に @yuya-takeyama が Enginering Manager になって、僕と rbmrclo が @sre-global という担当になって、yuya が「行ってみるのもありなんでは?」と言ってくれたのち robbie がいい感じの proposal を書いてくれて実現した。僕1人じゃこの提案はできなかったと思うので本当に2人に感謝している。

旅の前半の Jakarta 編が終わったので、次の Manila へ向かう飛行機の中で書き留めておく。

この旅の目的は SRE と Developer の関係性の再構築・強化だ。これだとざっくりしているが、より詳しく言うと、SREs は全員 Tokyo にいて、現状 PH/ID/MX Branch には SRE が存在しない。Developer と SRE は密接に Communication が求められるのに関わらず、おもな Communication 手段は Slack / GitHub Issue のみであり、頻繁に Communication を取れてるとはいいづらい。(関係が悪いとも思っていないが)

実施した Program 的なものは以下

  • Global SRE Missions for 2020
    • SRE Concepts (from robbie)
      • Emergency Response
      • Capacity Planning
      • Observability
    • Future of Global SRE (from robbie)
    • SLIs/SLOs (from me)
    • Delegation Infrastructure Management(Terraform) to Devs (from me)

最初に上記のようなトピックの Abstruct を説明するセッションを 1h とった。その後の Q/A をもとに、より詳細なセッションを別途持った。

  • SLO/SLI Engineering OKR alignment
  • How to handle too much request by online try-out
  • 1 on 2 / sre-global vs Engineering Managers
    • Explain Mission Control Program
    • What is your expectation for sre-global?
  • Sharing On-boarding processes

基本的な思想として、SREs は必要悪で、全員で Site Reliability Enginering ができるのが理想だと思っている。もちろん SREs の仕事は Platform 開発や OnCall(うちは OnCall Rotation を持っていないが)、Architect, Performance のような Production に関わることを含むので、すぐにはゼロにはできないが、SRE の思想や、やってる内容は少しずつ Product Team に委譲し、Product Team が Market に対して爆速で仮説検証をできるように(しかも信頼性も Keep しながら!Reliability is a feature である)していきたいと思っている。

そういった話をもとに、いままさに導入して試行錯誤の最中である SLI/SLO の導入説明や、robbie が提案する Mission Control Program - Google が提唱した、Developer が短期的に SRE Team に移動して知見を得て元の Team に戻っていく Program - の提案や実現性のヒアリングを行なった。また、 @suzuki-shunsuke が爆速で進めてきた Terrraform を state 分割して各チームにオーナーシップを持たせる話も説明した。

これらの説明を建設的に、前向きに彼らは受け取ってくれた。僕が1番驚いたのは Indonesia Team の Product Management だ。Product Manager の rofiqi が本当にしっかりしていて、Indonesia Branch の Product / Area ごとに、さらに細分化された Team ごとに 達成度合いを OKR を運用しており、その説明もとてもわかりやすかった。

SLI/SLO の導入の部分で、OKR にどう Align していけば良いか?という質問が行われたので、追加のセッションで Indonesia Team の OKR System をそもそもどのように運用しているのかを説明してもらったあと、基本的な SLI/SLO の話や原則、ポイントを簡単に説明したのち、最終的には「君らにまかせる」という回答をした。

彼らが OKR として採用している Key Result は Product Team であれば獲得した Paid User 数だったり、学習時間だったりするし、Enginering Team であれば 開発速度や、バグの数などがあった。Product によってはそこで SLI として採用している Availability(uptime) があったりした。

もちろん信頼性目標を組み込むのは悪くはないが、守れないと必ずしも"悪い"というものではないので、僕としては若干疑問は残るが、運用するのは彼らなので、彼らのやりやすい方法でやれるならそれが一番いい。

彼らが優秀であることと、これまでも試行錯誤を Indonesia の一部のチームではじめていたこともあり、わりと共通認識は取れていたと思う。SLI/SLO に関しての重要なポイントも説明し、理解してくれたようだったので、Indonesia に関してもまた SLI/SLO を「当たり前」のものとして運用できる未来は見えたのでよかった。

SLI/SLO に関しては僕が Lead しているのでそれもまた直接説明できてよかった。あと Coursera のコースとってるおかげがわりとぶつけで説明したけどうまく話せたのもよかった。

robbie が導入した Mission Control Program に関しても Enginering Manager のほぼ全員が(実際にそれをやれるかの How の部分には疑問が残るとはいえ、)方向性には同意してくれたようでよかった。

また、Enginering Manager との 1 on 2 をやる際に、せっかくのチャンスなので SRE(Global) に対する期待値を聞いてみた。

これは近々 Developer に向けて、SRE がやってきているいろいろの Feedback をもらうための Survey をやるつもりだが、その先駆けに Simple な質問を1つだけした。

目指す姿としては全 Product Team の全員が Site Reliability Enginering をできる、あるいは Team 内に mini-SRE がいてそれを Lead してくれるような形だが、少なくとも半年以上は先の話であり、現状は remote で Tokyo の SRE-global と各地の Developer で協力してやっていく必要がある。

それをもっとうまくやるためにも、期待値調整をしてみた。みんないろいろ思うところがあったみたいで、聞いてよかった。

例えば、あまり普段関わりのない Android Team の Enginering Manager と話したが、Staging 環境の安定性を1番にあげていた。あまり使ってない Endpoint があるからそれを調べられないか、みたいな話とか。話してみれば今すぐできることが出てくるので会話は大事だ。

またある Enginering Manager は Infrustructure / Platform の Interface をもっと多く開発してくれると嬉しいということだった。Learning Curve を下げつつ、かつ Secure にいろんなものを、SRE に頼まずに調達できる世界は目指している世界なので、そのあたりの認識が一致していることがわかってよかった。

これも思いつきだが、Global Team でも OnBoarding はちゃんと行われていて、日本での OnBoarding の状況を紹介できたのもよかった。たくさん質問がでてみんな興味を持ってくれたようだった。

半分冗談だが、初日の Dinner は「ここにいる全員 SRE だ!写真とるぞ!」って言って写真とったのすごいよかった。

f:id:take_she12:20200112112503j:plain
Global SRE class picture of 2020, we grew from 2 members to 17 members in 1 night. 🥰

たった3日間だったが、ふだんの仕事もしつつ(いろいろやむなしで Production の Operation もあった :sweat_smile: )多くの meeting を持ち(せっかくきてるからね!)非常に密度の濃い時間を過ごせたと思う。

こういう、「必要性を定量的に示すことは難しいが、やってみると確実に効果がある」類のことに、出張としていける組織でよかったと思う。

普段は Slack の向こう側で、slack id でしか認識していなかった彼らと直接話せて本当によかった。Lunch や Dinner にも連れ出してくれて本当にいいやつらだ。たくさん彼ら彼女らのことが好きになりました。


さてさて熱の冷めぬうちにやりたいなと思ったことを書いておく。

  • robbie との 1on1 を weekly か byweekly でもつ。彼とは行きで同じ便だったこともあって、わりと長い時間2人で仕事のことに関わらずいろんなことを話して、普段から隣に座ってはいるものの、もっと多くのことを話したほうがいいと感じた。(彼が東京にきてもう半年以上経ってるのにこのザマである!:sweat_smile:)
  • Devs との StudySession や Introduction の類を Global でも Zoom / Hangout を使ってやる。日本側ではカジュアルにやってるので同じことをできないわけがない。(いや、わけは英語力というものがあるんだけどね。まさに言い訳である。)
  • 今後は(現在議論中に事情により)仕事で日本と Global の Devs が関わる機会は徐々に減ってくる。しかし技術的な Knowledge Share が重要なことは変わりがない(むしろ相対的に重要度は増す)以前やっていた Technical な Study Session をもう一度復活させるもありかもなぁ、みたいな話をした。でもそれを僕が Lead するにはあと少し勇気が足りない。機運待ち。
  • Global の Blog ちゃんと書いていきたい。と3ヶ月前から言ってるんだができてない!

このへんのことは前期(2019/3Q)で立てた目標にも入っていたりするんだけど、その Motivation があらためて強化された機会だったということで、今Q も目標にしてやっていこうかな。


あとはこの旅で robbie が彼にしか出せない Value を出しまくってるわけで、自分はどうしていくかなぁと彼と最終日バーで飲みながら考えたりもした。もちろん今の SRE Team は全得意領域をそれぞれ持っていてそれぞれ Value を出している。「で、お前はどうなん?Value 出してるん?」ってもう1人の僕に聞かれている。

role 的な点で他のメンバーと比べて unique なのは global 担当でありながら日本人であるということで、その両者のシナジーを作るだとか、うまいこと応用を聞かせるとか、輸入したり輸出したりできるようにするとか、そういうところなのかなぁ、とぼんやり思ったりするところで終わっている。いや、Technical に突き抜けいよと言われる気もするが、いい意味でも悪い意味でも技術(の内容)にこだわりがないので半ば諦めている。Production Reliability に関する Culture Making の部分はこれからも引き続きやっていく。

やりたいことはたくさんあるので、いかにやらないことを決めるのが目下の課題かなぁなんてことも思ったりした。

とりとめない話でした。Manila もいい時間が過ごせるといいな。

LEARN ENVOY - Dynamic Configuration / Service Discovery Integration

www.envoyproxy.io

(ちゃんとした翻訳・要約ではなく、読みながらのメモです)

  • envoy は様々な Service Discovery Software と Integrate できる
  • envoy の core concept は data plane を controll plane から分離し、control plane から source of truth となる configuration を 変更できることである
  • まずは control plane が service discovery に接続できる必要があり、それは以下の 3 step に分けられる

  • Decide on a control plane implementation

  • Publish service definitions to Envoy clusters
  • Publish hosts/containers/instances to Envoy endpoints

いうても control plane まだないぞ、みたいな気持ちで続きを読んでいく。

いかなる control plane も Envoy v2 xDS APIs を実装する必要がある。

www.envoyproxy.io

istio の場合 pilot がそれに該当する。

その後の CDS / EDS の話ははいという感じ。

最後に、Service Discovery はめちゃくちゃたくさんの問い合わせがくるのでどう分割するかという話。データセンター、地域で分割したり、サービスのニーズによって分割したり。


さて、まだ Control Plane を持っていないのだが、現状 Kubernetes 上で Service Discovery は誰が担っているかというと、k8s service になる。

k8s service が 実際に転送先の pod の IP の list を持っていて、pod 生き死にすると、新しい endpoint を service が知るので、envoy cluster 側は 転送したい cluster IP だけ知っていればよく、かつそれは kube-dns で引ける。

そう考えるとこのパターンだと service discovery という感じではなく、load balancing は service が行うことになるので、envoy としては cluster が単一の宛先を覚えてるだけですね。

istio が入るとこのへんどう変わってくるんだろうか。なんか envoy だけまずは知ろうとしてるけど早くも control plane の話出てきたし順番間違ったかな。まぁこのまま進むけど。