https を envoy で受ける方法。
いまのところそれを使う予定はないが、いいチュートリアルになっている。http できたら https にリダイレクトする方法ものっている。
ROUTING WITH A CONTROL PLANE
とあるのでやはり Control Plane のことを考えねばならんのか。
やっぱり Control Plane を扱ったことがないとイマイチつかみきれない展開が続いてつらい。
現地でスマホからいくつか Twitter にはあげていたが、持っていった一眼でもいくつか撮っていて、見返すと美しかったので載せておく。
— 🤔 (@chaspy_) January 16, 2020
Life is Good pic.twitter.com/GhmlqUhE3Q
— 🤔 (@chaspy_) January 17, 2020
— 🤔 (@chaspy_) January 17, 2020
— 🤔 (@chaspy_) January 17, 2020
Life is Good pic.twitter.com/dH4KuVQv9O
— 🤔 (@chaspy_) January 17, 2020
年に1回は南の島のプールつきのホテルに泊まってビーチで「何もしない」をしないとダメだと強く思った。
してきた。
SRE Lounge の運営メンバーで、やろーぜ、と手探りではじめた、日本ではじめての SRE のカンファレンスが無事開催された。
やろーぜ、日本でいちばんのSREのカンファレンス、と雑に言い始めたのが去年の4月頃だったかナァ
— 🤔 (@chaspy_) 2020年1月25日
主にコンテンツという点で、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 さんに一方的にファンコールをしたりしてとても楽しかった。
最高のチームでした。最高のチームでした。
このチームだからこそできました。
参加した方で、いいカンファレンスと思ったら、運営スタッフに会ったときに、「ありがとう」「最高だった」と伝えてあげてください。
理由はいろいろあるんですが、卒業しました。あとはまかせました。
卒業ed
— 🤔 (@chaspy_) January 26, 2020
👋Bye Bye SRE Lounge https://t.co/KnGT6bS1rX
— 🤔 (@chaspy_) January 27, 2020
帰りの電車から翌朝にかけてコアスタッフにメッセージを書いて、いきなり挨拶して、スッっと抜けました。解散ライブをせずに解散発表するタイプのミュージシャンなんで、ごめんなさい!
12月の頭に抜けることを決めてから、本当に過ごす時間1つ1つが愛おしく、寂しく思いながらスタッフの仕事をやってました。みんな本当に、こんな適当で雑な僕を仲間に受け入れてくれてありがとうね。
ぼくは #srenext 大成功だったとおもうよ
— 🤔 (@chaspy_) January 25, 2020
僕の SRE としてのキャリアは SRE Lounge / SRE NEXT とともにありました。きっとこれからもそうだと思います。
また何かの形でコミュニティに恩返しができるといいな。
そのために、追いかけたい背中を追いかけていこうね。
願わくば誰かにとっての追いかけたい背中になれますように。
とりあえず継続することができるようになってきたので、質と量を少しずつ伸ばしたい。
アメリカ人がなぜ英語喋れるかって1日中英語使ってるからやで理論に従うと、1日25分じゃ死んでも追いつけない。いや追いつけないんだろうけど、成長のスピードは遅い。3時間ぐらいにどうにか持っていきたい。
これ毎日捻出するの結構キツいな。
abceed は隙間時間と通勤電車といっても60分は行かないので、もっと隙間時間作るか、意図してやらないといけない。
シャドーイングに関しては、散歩しながらやる。痩せる気はしないけど一応健康意識が 1mm ぐらいはある。
最後技術学習と合わせてやらないとなので、まぁこれは英語というよりは普通に勉強と思えばできなくはない。
とにかく歩きと隙間時間を使って1時間ぐらい今まで浮いていた時間を活用しつつも、家で向き合ってやる時間はどうしても必要になってくる。たった3時間確保でもこれだけ難しいの厳しいな。
でも abceed すごい楽しいので TOEIC 受けるの楽しみになってきた。
シャドーイングの課題が、やっぱりいきなり聞くだけだとなかなか理解できないので、最初に script を読んでだいたい中身を理解してから聴くというのをやりたいが、それをやる前に移動してしまいできてないという状態になっていてよくない。なんとかしたい。
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 的なものは以下
最初に上記のようなトピックの Abstruct を説明するセッションを 1h とった。その後の Q/A をもとに、より詳細なセッションを別途持った。
基本的な思想として、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 だ!写真とるぞ!」って言って写真とったのすごいよかった。
たった3日間だったが、ふだんの仕事もしつつ(いろいろやむなしで Production の Operation もあった :sweat_smile: )多くの meeting を持ち(せっかくきてるからね!)非常に密度の濃い時間を過ごせたと思う。
こういう、「必要性を定量的に示すことは難しいが、やってみると確実に効果がある」類のことに、出張としていける組織でよかったと思う。
普段は Slack の向こう側で、slack id でしか認識していなかった彼らと直接話せて本当によかった。Lunch や Dinner にも連れ出してくれて本当にいいやつらだ。たくさん彼ら彼女らのことが好きになりました。
さてさて熱の冷めぬうちにやりたいなと思ったことを書いておく。
このへんのことは前期(2019/3Q)で立てた目標にも入っていたりするんだけど、その Motivation があらためて強化された機会だったということで、今Q も目標にしてやっていこうかな。
あとはこの旅で robbie が彼にしか出せない Value を出しまくってるわけで、自分はどうしていくかなぁと彼と最終日バーで飲みながら考えたりもした。もちろん今の SRE Team は全得意領域をそれぞれ持っていてそれぞれ Value を出している。「で、お前はどうなん?Value 出してるん?」ってもう1人の僕に聞かれている。
role 的な点で他のメンバーと比べて unique なのは global 担当でありながら日本人であるということで、その両者のシナジーを作るだとか、うまいこと応用を聞かせるとか、輸入したり輸出したりできるようにするとか、そういうところなのかなぁ、とぼんやり思ったりするところで終わっている。いや、Technical に突き抜けいよと言われる気もするが、いい意味でも悪い意味でも技術(の内容)にこだわりがないので半ば諦めている。Production Reliability に関する Culture Making の部分はこれからも引き続きやっていく。
やりたいことはたくさんあるので、いかにやらないことを決めるのが目下の課題かなぁなんてことも思ったりした。
とりとめない話でした。Manila もいい時間が過ごせるといいな。
(ちゃんとした翻訳・要約ではなく、読みながらのメモです)
まずは control plane が service discovery に接続できる必要があり、それは以下の 3 step に分けられる
Decide on a control plane implementation
いうても control plane まだないぞ、みたいな気持ちで続きを読んでいく。
いかなる control plane も Envoy v2 xDS APIs を実装する必要がある。
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 の話出てきたし順番間違ったかな。まぁこのまま進むけど。