ツナワタリマイライフ

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

GitHub の Repository の Pull Request の数を Datadog に送る OSS 作った

作った。

github.com

そういえば今日は July Tech Festa で、@songmu さんの OSS を細く長く続ける技術を聞いて、OSS 活動するぞ〜〜〜〜〜となって作った。

junkyard.song.mu

自分も Datadog に関する発表をして、custom metrics はいいぞという話をしたというのもあり、やるぞ〜〜〜〜となって作った。

これはなに

特定の Repository の Pull Request の数を Datadog に送る君です。

custom metrics の label には repository, author, label, reviewer がついてます。

f:id:take_she12:20210125035101p:plain

対象の Repository は環境変数で指定しています。

$ cat .envrc
export DATADOG_API_KEY="secret"
export DATADOG_APP_KEY="secret"
export GITHUB_TOKEN="secret"
export GITHUB_REPOSITORIES="quipper/kubernetes-clusters,quipper/server-templates"

どう使うのか

ちゃんと使えるかはまだわかんないんですが、PR 溜まりすぎたときにアラート発砲とかできると思います。あと個人的にも自分が Reviewer になってる PR が n個以上になったらアラートとかもできる気がします。まぁ別に Jasper で通知受けてるからそうそう貯まらないんですけども。

あと renovate が PR バンバン出してくるので、それも一定数たまったらみんなで見ましょうねみたいなムーブもできるかもしれません。

まだデプロイしてませんが、Kubernetes cronjob として Deploy して5分なり30分なりの間隔で定期実行させるつもりです。

何をしたのか

main logic に語るところはあんまりない。

まだ結構雑で、普通にチームメンバーにレビュー投げたらボロクソレビューが入るレベルだと思う。

GitHub から対象の Repository の PR 持ってきて、必要な情報だけ抜き出して（label, author, reviewer, number）それから datadog metric を作る材料をこねこねして custom metrics を送っているだけである。

github actions を使って goreleaser でリリースしたりタグ打ったら Docker push したり CI で lint 流すようにしたりしているがほぼ検索結果のコピペなのであんまり深く理解はしていない。actions 作られているの簡単に使えるので便利だな。近々 github-actions のこのモジュールっていうのかな。なんていうのかわからんが、も作ってみたい。

今後

Issue version も作ろうかなと思う。

思うところ

Datadog のタグの仕様がイケてない。

renovate の PR とか、renovate/datadog と renovate/datadog/2.6.11 って2つ label がついてるんだけど、datadog に同じ key の label を送ると renovate/datadog, renovate/datadog/2.6.11 とカンマ句切りのタグとなる。イケてない。やむなしか。Reviewer も複数人指定するとそうなっちゃんだよなあ。

おわりに

カンファレンスってさ、参加してなんかわかった気になるじゃん、でもそのあと行動しないと意味ないじゃん、で発表したし聴講して、ちゃんとアクションを起こしたので俺は勝ち。みんなも行動していこうな。JTF ラブ！

入社してから2年半

12/20 で2年半経った。

前回

blog.chaspy.me

なんかもうまた全然違うところまで来てしまった感があるし、はるか昔に感じるな。成長しているとも言う。

相変わらず挑戦と失敗をさせてくれる組織とマネージャーの @yuya-takeyama に感謝している。

振り返り

Platform Development の Lead

Application Platform, つまり Kubernetes のことだが、それの重要度は非常に高いし、SRE Team はこれをビジネス要求や開発者のため、もしくはサービスの信頼性のために適切に進化させていく必要がある。

特に詳しい @d-kuro に力を借りながら、Kubernetes 関連のことを話す Weekly Meeting をはじめて、Roadmap を引き、自分自身で今後の進化の重要な一歩と言える EKS への移行を実現しきった。

quipper.hatenablog.com

また、この延長でこのとき感じた課題を解決するために Cluster の Canary Switch も実現。総じてクラスタ切り替えはかなり楽になった。

quipper.hatenablog.com

この分野に強い知見を持つ @int128 が入社するまでには移行をやりきるぞ！という気持ちで、（実際は入社前には間に合わなかったけど）やりきった。影響範囲も大きく、技術的な不確実性も高かったプロジェクトだった。特に自分は kube-aws で管理していた自体の Kubernetes Cluster 切り替えを1度もやったことなかったので時間かかったり失敗したことも多くあったが、学習しながら完遂できたのはよかった。

Global Cluster の切り替えを行ったあと、Japan の分は @int128 にやってもらい、オンボーディングが終わったあとは彼にこの分野の Lead をおまかせした。

その後は System Component の GitOps 化、それに伴う renovate による component upgrade の簡易化、Nginx Ingress の部分導入など凄まじい進化を遂げている。

quipper.hatenablog.com

EKS は本当に"第一歩"だったんだなぁ、と終わってみてようやく思う。当時は kube-aws のサポートが追いつかず Kubernetes が EOL になってしまうから、と後ろ向きなモチベーションだったが、やはりやってみてわかることはたくさんあるね。

Infrastructure / Service Cost Management の Lead

あんまり大きな声では言えないが、Infrastructure / Service Cost に関してこれまであまり"ちゃんと"やれてなかった。

夏頃に @motobrew からこの Cost に関してヤバいのではと警笛をもらってから、できることから少しずつ実現している。

quipper.hatenablog.com

まだ道半ばで、適切な目標を持ち、分析をし、定量的に振り返る体制作りはこれからではあるが、Monthly で振り返り、着実に前に進めていると思う。

Global Development Team との関係強化

これはもう本当に悔しいし悲しいしつらいが、Global で大きい障害を起こしてしまった。何がつらいって「わかっていた」のに何もできなかったことだ。まぁそれは僕個人が悪いわけではないが、数日は落ち込んだ。

それをきっかけに、Global Developer との Meeting の機会がとても増えた。

また、それとは別に、当時は「やることが多すぎて優先度がつけられない」ということに悩んでいた。そこで彼ら彼女らが何が課題かを吸い上げるために、あるいは情報が流れてきやすくなるための関係構築のために、Global Developer との 1on1 を行った。

「定期試験」によるスパイクアクセスに対応するためにコンポーネントを開発し、Engineering で解決できたのも、そもそもお互いで会話して、関係性ができていたからこそだと思うので、ずいぶん前に進んだし、自分としても良い経験になった。そもそものきっかけが Business Owner の @naotori と話したことだったりもするので、コミュニケーションによって問題を解決できた。

quipper.hatenablog.com

ブログ記事化はしてないが、12月には Android Developer と一緒に Locust による Loadtest を実施した。望んだ結果が手に入ったわけでもないし、コミュニケーションの課題は依然残るものの、問題の質が変化したというか、前だったらお願いすらされなかっただろうし、頼ってもらえるようになっただけ進歩かなぁなんて呑気に考えている。

いずれにせよ着実に前には進んでいる実感はある。まだまだ道半ばなので継続して関係作りはしていきたい。

Team / Project Lead

まぁ上でいろいろ Lead したと書いてはいるんだが、5月に Lead Software Engineer のジョブタイトルがつき、Team / Project の Lead をしている。主にコミュニケーションのデザインやファシリテーションをしたり、Retrospective であがってきた Problem に対する Try を積極的に取ったりなんたりで貢献できていると思う。

次の半年

ちょっと今回は"意識"/"心意気"みたいなことを宣言してみる。

レバレッジの効く仕事をする

ちょっと抽象的ではあるが、やる仕事をしっかり見極めたい。というのも、本当にやること、やれることは無限にあるし、仕事の難易度もかなり難しくなってきている。Team や Project を Lead しながら Individual Contributor としても貢献し続けるためには、そのインパクトを最大化するためにどういった投資をするかという意識を常に持たないと、（自分が）疲弊したりチームに混乱を招きかねない。

本当にやるのか、なぜやるのか、どうやるのか、こういったことを今まで以上に見極めたい。

また、自分が得意としているコミュニケーションによる問題解決能力を特に存分に活かして、Japan / Global 両方の組織に貢献したい。

成果にこだわる

これはこれまでも意識をしていたことだけど、とにかく成果を出すこと。話はそれからだということ。1つ前のことにも関連するが、それで世界がどう変わったのか、ということを常に意識すること。かけた投資に対してインパクトを最大化すること。そのためにエンジニアリングの力を存分に活かすこと。これに今まで以上にこだわり続けたい。

クオリティにこだわる

自分に明確に足りてないことでいえば Software Engineering ... Programming による課題解決の部分である。お前それが仕事だろと毎年ずっと突っ込んでいるが、事実そうだから仕方がない。

やった仕事を「終わらせる」ことも大事だが、Delivery と Quarity を両立してこそ Professional だと思う。ちゃんとクオリティを出すことを目指したい。このあたりは模範的な同僚が多くいる幸せな環境なので、見習いながら食らいついていきたい。

Global Product Team に貢献する

引き続き SRE としては Global も担当範囲である。また、Global Product Development において Site Relaiblity の重要性は相対的にも増してきている。Site Reliability Engineering の実現のためにはコミュニケーション能力が必要不可欠である。引き続き関係性を構築するとともに、英語でガンガンコミュニケーションを取って、チームと、世界を変えていく。"世界の果てまで学びを届ける”ために、貢献できるポジションにいるのでしっかりやる。

ビジネスを理解し、エンジニアリングでビジネスに貢献する

成果にこだわることにも関係するが、それがどのようにビジネス価値を生むのかを常に考える。そしてそのためにはビジネスを理解する必要がある。もちろんコストも関係する。インフラコスト、ビジネスインパクトを考え、ビジネスを前に進められるエンジニアリングを行いたい。そのためにステークホルダーとのコミュニケーションは引き続きやっていきたい。

おわりに

^の心意気を実現するためには英語とか技術とかあれこれいるので、それについていけるようにやっていく。

おしまい。

オンラインイベントについて思うこと

こうなった。nari さんと飲んでて酔っ払って北野さんに 1on1 しよう！！！！！とウザ絡みして 1on1 してもらって SRE Lounge やらないの〜〜〜みたいな話でオンラインイベントについて思うところを話して今に至る。

で、かめねこさんと草間さんとそのへん雑談することになったのでそのための事前インプットを書いておく枠。

この文章を書いているひとについて

コロナ前のイベントの醍醐味

  • 懇親会
  • これにつきる
  • あとカンファレンスの廊下

もちろんトーク内容に興味があるからいくのは大前提だし、学びはいろいろあるが、どうしても 1:多 で発信される発表は"そこそこに刺さる"内容にならざるを得ず、自分自身の課題を解決できるようなピンポイントなものが得られることはめったにないだろう。

そこで質疑応答だとか、そのあとの交流で踏み込んだこと、発表では言えないであろうこととかを聴けるのが一番良いところだと思う。あとたのしい。知り合いも増えるし。

コロナ時代のオンラインイベントについて思うこと

参加者として

  • 圧倒的に便利になった
  • たいていは録画されていて、あとで見れるし、倍速で聴けるし、必要な物だけ見るつまみ食いだってできる
  • 「いつでも見れる」は「見ない」と同義だったりする、人間だものね
    • なので僕に関して言えば参加数・時間は減ったように思う
  • もちろんひとによっては、家庭の都合等で"全然行けなかった"ひとだとかは参加数が増えたひともいるように思う
  • あとは地域格差がなくなったのはもう本当に良いこと
  • 懇親会がないのさみしい
    • なのでイベント後、録画・配信切ったあとに数人で喋るのが最高に楽しい
  • "没入感" みたいなのは家では得られにくいように思う

発表者として

  • 反応が見えないのがつまらない
  • 単に家で画面の前で喋るのも"楽しく"ない
    • 楽しさってなんなんだろうねえ
    • "人前で喋る"ことの良い意味の緊張とか高揚とか含めなんだろうね
  • 質問は sli.do などで非同期に、かつ多く受け取ることができるようになったことは良いこと
    • ただし、質問の意図をその文章から受け取ることは難しい
    • 通常の質問でも2,3往復はやりとりするよね
  • かといってオフラインと同様リアルタイムに挙手して質問が受けられるかというと難しいのもわかる
    • 質問する側としてもハードルが上がるのかも？
    • あと参加者はそもそもリアルタイムに見ている層だけじゃないし
  • あと来年も登壇予定決まっているのに言うのもなんだけど、プレゼン形式の発表はコスパが悪いと感じている
    • 情報伝達という意味ならブログのほうが良い
    • 発表資料作り、練習、時間調整とかかる時間が多いわりにインパクトが出るか、という意味でのコスパ
  • 録画の制約
    • 言っちゃ言えないことがますます言えない
    • その場での"Live"な講演がしづらい
      • 反応次第でしゃべること変えるとか
      • これは技術的にカバーできるかもだが。
    • オフライン時代は「せっかく足を運んできてるんだから」と、"スライドには載っていない" "中の情報" をチラ見せしたりする、見れるのが良いと思っていた
      • Sakabe さんスタイル

      • sakabe さんのセッション、結構がっつりスライドと内部の実際のissueいったりきたりしていて、生Live感がよかったし、そのやり方自体をぼくも直後の自分のセッションで真似できたのでいい体験ができた。

      • July Tech Festa 2019 で登壇した - ツナワタリマイライフ

運営者として

  • それなりに技術要件がある、まぁ慣れればすぐですが
    • 最低限、Zoom + Youtube Live なら楽だしね
    • OBS とかは僕はわかってません
    • オフライン時代の会場調整とかに比べると楽か。。。
  • "リアルタイム"参加者数が読みづらい
    • 録画が前提だとなおさら
    • 参加率もオフライン時代はなんとなし見えてたけどオンラインで参加ハードルが下がった今またまったく読めなくなっていると思う
    • 実際 Youtube Live の場合、connpass の"参加ボタン"を押すことに実質的な意味はないしね
      • でもみんな押すよね、好き、僕も押す
  • 運営目線でも「やってよかった」と実感が得られづらい
    • フィードバックを能動的に得に行く必要がある、まぁこれはオフラインでも同じと言えば同じだが
    • イベント後の懇親会とかで運営しつつ参加者・発表者と話したりしてて感じる部分も結構あったんだなーと思う
  • 前で述べた、参加者、発表者にとってに負の部分を解消するソリューションを考えていく必要がある
    • そこまでやれるか？難しい
    • そもそもイベント運営というだけで大変
    • そこであらたな技術要件、課題に直面している状態が今

まとめや仮説や話したいトピック

録画に関するトレードオフ

利便性と制約にトレードオフがある。参加者にとっては利便性が高いが、発表者にとっては制約が大きくなる。ここにモチベーションの解離が出てくる。ここは絶妙なバランス感覚が求められていると思っていて、"録画をしない"だとか、"クローズド"(配信しない)みたいな挑戦をしていく必要があるのではないか。

インタラクティブ性の演出の難しさ

これには"録画でも見れる"利便性によるリアルタイム参加者数が読めない点、単に技術的な要件（sli.do などはすごい。あとカンファレンスによっては ask the speaker を作ってたりするよね）、そしてオンラインだから、見えないからこその参加者の"没入感"が得られない点などが原因になっている気がする。

これは発表者、運営者のモチベーション、インセンティブに関わると思うが、やっぱり「ただ発表するだけ」では「やってよかった」と得づらいと思っていて、フィードバックや質問疑問などがあってこそ思えることだと思う。そういう意味でも双方向性は不可欠だと思う。

発表者・運営者のモチベーション・インセンティブ設計の再考

上のトピックと関係するが、やっぱりそれが得られづらくなってるのではないか。

地理的・物理的制約がなくなって、圧倒的に可能性は広がっている。ただし、広がったからこそ需要が見つけづらいだとか、フィードバックが得られづらいとかで、あらたな運営スタイル・発表スタイル、あるいはそれを支える新たなプラットフォームが求められているように思う。

2021年挑戦したいと思っていること

  • 新たなオンラインカンファレンスのスタイルの確立
    • いろいろ実験したり話したりして仮説検証したい
    • 例えば8人とかの人数制限、内容を限定してクローズドなイベントを多数開催することで利便性と没入感やフィードバックの両立ができないか？
    • インタラクティブメインのイベントをオンラインで実現する
      • Terraform-jp でやっていた ワールドカフェスタイル
      • EM meetup でやっていた オープンスペース方式
      • Datadog jp でやった Live・ペア/モブプロ形式での発表
    • 現状ある様々な問題を技術的に解決できないか？
    • より"コンサルティング"みたいなのはしやすくなっているはず。やはりクローズドでは？
    • 逆側に発想を振ったりゼロベースで考えて、コミュニティ全体でオンラインイベントを考えていければ楽しいと思っている

参考

このエントリに大きく影響を受けており、かなり示唆に富んでいると思っています。

yasuhisa.com

おわりに

楽しいことしたいね。31日の雑談会よろしくおねがいしまーす。

育ってから対処する問題と、育つ前に対処したいかもしれない問題

問題には2種類あることに気づいた。

育ってから対処する問題

1つは、実際に何か困っていることがあって、解決したい課題があるという問題。そしてそれはあるひとにとって関心が高く、かつ他のひとからもある程度理解できるような問題。

たいていの問題はこれに分類される。これは時間をかければかけるほど、勝手に問題の問題度があがってくるので、それがあがった適当なタイミングで対処すれば良い。

明らかに困っているので、やる理由も明確だし、困っている度合いによって優先度も勝手につくので楽だ。見積もりをする必要もない。

こちらを仮に育ってから対処する問題と呼ぼう。別に育って「困って」も取り返しのつかないというほどでもないので、ちょっとは大変な思いはするだろうが、適切なタイミングで摘み取れば良いのでシンプルだ。

育つ前に対処したいかもしれない問題

もう1つは、現在は実際に困っているわけではないし、それが本当に問題かどうかは確証は得られないが、いつか大きな問題になるかもしれない種類のものだ。

こちらを育つ前に対処したいかもしれない問題と呼ぼう。

なぜ育つ前に対処したいかというと、もしそれが訪れたときのダメージが非常に大きいからである。

People Management の範囲でいえば、メンバーのモチベーションの低下、精神疾患を引き起こす、コミュニケーションが困難になる、チーム内外の関係性が悪化し修復困難になる、ハードワークにより身体を壊す、など。

あるいはこれはソフトウェアアーキテクチャにも言えるかもしれない。アクセスが10倍になったときに現在のボトルネックが限界に達するとカスケード障害を起こす可能性の高いアーキテクチャ。メンバーが3人から10人になったときに保守が困難なコードベース。複雑度があがりすぎてトレーシングができずに本番障害で検知からの復旧に時間がかかってしまうかもしれないマイクロサービスたち。

みんな見えてる世界が違う

このような問題がなぜ難しいかの前に、全員が見えてる世界が違うという前提の話をしたい。

当たり前だが、全員見えてる世界が違う。興味も違う。業務内容も違うかもしれない。バックグラウンドも違う。そういった多様なメンバーの中では、ある問題を問題と思うかどうか、あるいはその問題度、深刻度の見え方も全然違う。

そのため、あるメンバーがこういった将来的には深刻な問題を引き起こすかもしれない（引き起こさないかもしれない）問題の芽に気づいても、それを組織でやっていくことを推し進めることは非常に難しい。だって他のひとにとってはおそらくそれは問題として認識されていないから。

例えば Lead や Management はチームのことをみているので、そのひとしか見えない問題もあるし、専門性をもって特定の分野に長けているメンバーはその分野に関する問題度も高いだろう。

後者の問題にどう向き合うか

この後者の問題に対してどう対処すればいいのか、今自分の中で正解が見つけられていない。

いずれにせよ、起きるかもしれない、起きないかもしれない、そもそも問題かどうかもわからない問題は、たいてい難しく、範囲が広いものだ。自分1人でやりきるのはきっと難しい。

現実的には、Retrospective といった機会を通して、各メンバーが問題と思っていることを共有して、そのうち優先度の高いもの、（今回でいう前者の問題）に対処しつつも、少しずつ視界に共有されているものを増やすしかない。

そしてその問題に思っているひとは、少しずつでもその問題を言葉にする必要がある。アカウンタビリティは必要。

やりますか、となるためには、アカウンタビリティを果たすことと、周囲になるべく近い立場でその問題を見てもらうその両方が必要である。

他者をコントロールすることは基本的にできないので、"時"を待ちながら、状況を見ながら、言葉を尽くしながら、対話によって視界を共有していくという地道なことをしないといけない。

僕は前者の問題はもちろんのこと、後者のタイプの問題もちゃんと取り組めるようなチームでありたい。

と、こうやって問題を問題として言葉にできた時点で、半分解決したようなものかもしれない。わからない。

でも、この2種類の問題があるということ、そしてそれはみんな見えてる世界が違うという前提に立つと難しいのは当たり前であること、そしてそれに対する打ち手は地道な言語化と忍耐が必要だということがわかったのでよかった。

Nginx Ingress Controller で Progressive Delivery したい

現在運用中の Kubernetes Cluster は、Multi Cluster を Support するためにALB で受けたのち、Nord Port に流されたトラフィックはセレクタによって Service Router という、各 Kubernetes Service へ Proxy するための Nginx がいる。

この Config が中央集権的な管理になっており、server directive ごとに区切られるとはいえ、かなりデカい Config になっており、なかなか心理的にもいじりづらくなってきている。

これはもともとさらに前段のインターネットフェイシングなトラフィックを受ける Reverse Proxy(Nginx) の中にあった Config のうち、Service 固有の Routing をいじりやすくするように移したという背景がある。これはこれで、Reverse Proxy よりはいじりやすくなったが、今度は次のステップとして各 Service ごとに Config や Deploy を分離したいと考えている。

加えて、Traffic を Percentage-Based で Canary Release(Progressive Delivery) をやりたいと考えており、そのためにも必ず Traffic を受ける　Service Router がいては邪魔なのだ。

そこで選択肢として、慣れている Nginx であり、かつ現在導入中の Rollouts との相性、あるいは将来の選択肢としての　Flagger との相性を考えて Nginx Ingress Controller を検討している。

というわけでドキュメントを読んでいく。

kubernetes.github.io

AWS の場合。

kubernetes.github.io

NLB が Ingress Resource としてできるようだ。

しかしこれだと External ALB から NLB に Weighted Load Balancing できないので困ったな。

kubernetes.github.io

で、まぁこのドキュメントだと正直 NLB で受けたあとどういうルーティングで各サービスにいくのかがよーわからんので、Nginx 公式のこっちをみてみた。

www.nginx.com

なるほど Nginx の設定に対応する Virtual Service と Virtual Server Route があるんだね。

docs.nginx.com

つまり、この yaml で表現されるような単純な Routing は代替できて、生の Nginx を書かないといけないような場合は、各サービスごとに Nginx なりを持って好きにしてくれ、という感じになるわけだ。

user -> NLB(Ingress) -> nginx -> service

こういう流れで、Nginx Ingress Controller は与えられた yaml にしたがって各サービスごとの Nginx Deployment を生成して、Configmap の設定を読み込ませるということだ。

Argo Rollout と連携して、canary=weight の値を nginx ingress に持たせておけば、rollout controller が nginx の config をいじって routing 先の service を weighted でいじるのだろうか。ちょっといまだにピンときてない。や、多分特定の割合で特別な Header を NLB でつけるようにして、それをみて Nginx が振り分けるようにする気がする。

ただこの場合、Ingress を通る全部のトラフィックが対象になる気がする。Service ごとにできるんだろうか。やっぱ動かさないとなんともだな。

おわりに

というわけでシンプルに routing するだけなら Nginx Ingress Controller で実現できそうだが、Progressive Delivery をやる上で Flagger なり Argo Rollout なりと連携していく部分はちょっとまだ見えてないので動かして学んでいきたい。

あと、Cluster 自体も Canary Switching したいので AWS で Nginx Ingress をいれた状態でどう実現するかの案も考えていきたい。

追記

split っていう設定があるので、これで Stable と Canary のService へ Canary できそう。

docs.nginx.com

Rollout Controller は多分これを Strategy にしたがっていじるんだろうな。

Argo Rollouts の Traffic Management

読んでいく。

argoproj.github.io

Quipper では日本サイドにおいて Progressive Delivery の方法として Deployment から Rollout への移行が進んでいる。

これにより Pod 単位での Traffic Splitting / Canary Releasing が可能になるが、Front Proxy 部分と連携することでより柔軟な Traffic Splitting ができる。（たぶん）

Overview

できること

  • Percentage-based は Traffic Splitting
  • Header-based routing
  • Traffic Mirroring

夢がひろがりんぐですね。

基本的に、Kubernetes Native の機能では上記のようなサポートは提供されないため、Service Mesh をサポートする以下の外部ツールを使う必要がある。

  • Istio
  • Nginx Ingress Controller
  • AWS ALB Ingress Controller
  • Service Mesh Interface(SMI)

Argo Rollout Controller はこれらの外部 Service に対して変更を行うことで Traffic Routing を行う。

1つずつみていく。

Istio

最終的に本格的に Controll Plane を入れる場合にIstio は強力な選択肢の1つであるが、まだベネフィットに対して運用負荷のほうが高そうなので、来年4月に再検討する、ぐらいの温度感である。

Argo Rollouts Controller は Istio の virtualService を指定する。

virtualService では route として destination を定義し、stable-svc と canary-svc を宛先として指定する。

Argo Rollouts Controller はこの Weight を Rollout の設定にしたがって変更することになる。

ところで Canary Service と Stable Service の2つを用意しないといけないと思うんだけど、これのセレクターはこの Rollout でいいんだろうか？このへんがよくわかってない。

それとも Service + Rollout で2セット用意するんだろうか？だとすると Kind Rollout の Resource も2種類必要になってきてよくわからなくなるから多分違う。

なお GitOps と連携する場合、Controller が Weight を変えてもすぐに戻ってしまうが、ArgoCD では Annotation をつけることで Argo Rollout Controller の変更のほうを優先するとのこと。便利。

Nginx

次のステップとして Nginx Ingress Controller を導入しようと考えている。現在 Application が Rollout に移行していることを考えると、この組み合わせでやることになると思っている。

ちょっと Nginx Ingress Controller 自体がどういう動きをするのかまだ理解できてないが、Nginx の Deployment に対応する Ingress Resource が存在して、それぞれが Annotation を持つ。Canary 用の Ingress の canary-weight field を Argo Rollouts Controller が変更する。

うーん、雰囲気はわかったけど雰囲気しかわからない。

Traffic が Front -> Nginx(Stable) -> Service -> Rollout だったとして、Nginx(Canary) があらたに存在するとして、何を持ってトラフィックを Canary 経由にするのだろうか？さらにその前段に Traffic Splitting をする Layer が必要な気がする。

AWS ALB

一度 ALB Ingress 導入したが、今は Multi Cluster を Canary Switching するために Ingress をはがしたのでもうこの選択肢は使わない。

Ingress で ALB の Weight Target Groups の機能を使い、行き先の Service を指定するようだ。とはいえ、結局宛先は Node Port が受けるような Target Groups になると思うんだが、何を持って後続で区別されるのかが謎。ALB 的には Kubernetes の Service って見えないと思うので、"ServiceName":"stable-service", が ALB 上でどんな設定になるのか気になる。

SMI

SMI も雰囲気でしか理解していない。Service Mesh のための CRD が標準的にあって、それを使おうぜって感じなのかなという雑な理解。

で、Argo Rollouts Controller は TrafficSplit CRD を操作して、Weight を変更する。

あーで、ようやくわかりやすい図が出てきた。

なるほど、Canary Service と Stable Service はそれぞれ App の Selector 以外に、Rollout の Replicaset の hash を持たせておいて、そっちに転送させるみたいなことができるのか。すごい。で、Rollouts Controller はそのそれぞれの Service がもってる hash を replicaset が変わるたびに指定すると。なるほどがってん。

おわりに

いずれの手法も、Front Proxy の層で Traffic Splitting する部分の Weight を Argo Rollout Controller が変更する。その部分の宛先はそれぞれ Canary と Stable のService を事前に作成しておき、それらの Service は Rollout 管理の Replicaset へ Routing することで、Rollout による2世代の Replicaset 管理に対して Canary Releasing を実現している。

次回は実際に使っていくであろう Nginx Ingress Controler 自体の理解を深めていく。

Private English Lesson #2

2020/06/16 にやった分を今更復習。

Pronunciation

  • Vincent vowed vengeance very vehemently
  • She sells seashells by the seashore

v と sh の練習。sh はイーの口で息を吐く感じ。

これ、意外と残るんだよな。すごい。

Expressions

  • I can‘t agree more
    • I totally agree
  • I‘m with you
    • I’m in your side
    • I agree with you
  • I’m in.
    • Ok, let’s go
    • Casual expression

同意するときの別の言い回しが2つと、カジュアルな承諾。I'm in ははじめて聞いた。

Writing

留学先の担当者に、質問をメールでする課題。

で、いろいろツッコミがあったんだが、疑問文をちゃんと作れてないことがわかった。

以下を聞くとして

  • How many students there will be in the school and each class
    • How many students will be there in the school and each class?
  • What qualifications the teachers have
    • What qualifications do the teachers have?
  • What resources the school has
    • What resources does the school have?
  • What is included in the price
    • What is included in the price?
  • What amenities there are in the area
    • What amenities are there in the area?

What なんちゃら系の疑問文を全然普段書いてないことに気づいた。 Do you? Did you? とかか、肯定文 + right? とかで済ませることが多いっぽい。

なんかその事実にめっちゃショックを受けてしまったのと、そのときめっちゃなんか疲れてたっぽくて、その次のレッスンでがっつりこの辺話して、うわーまじかーってなって、それからちゃんと復習してからやるぞーっていって、予約できてなくて2ヶ月経ってしまった。

DMM 英会話がマンネっててやめてしまったので、質の改善という意味で Private Lesson に切り替えて、収穫もあったが、継続しなければ意味がないので、DMM 英会話を再開すると同時に、Private Lesson も来週から再開予定。

普段細かく指摘されることのない Pronunciation, あと事前にリクエストしておいて、仕事で使えそうな Expression を教えてもらったり、英語の勉強やりかたとか、まぁ英語における「不自然な表現」みたいなのを指摘してもらえるのはありがたい。今年は Writing もちゃんとやっていきたいので別料金でそれの添削もしてもらえたらと思ってる。

英語学習をはじめて1年経った

そういえば英語学習を気合入れてはじめてちょうど1年経った。

見える世界はだいぶ変わったと思う。9ヶ月ほど DMM 英会話をほぼ毎日続け、仕事で英語を使う機会が増えて。

そのときは同僚に時々 1on1 でコーチングをしてもらっていたんだけど、当時のメモがこれで。

どこに行きたいの？目的地

  • 国際カンファレンスで聴講者として英語で質疑応答ができる
  • 国際カンファレンスで発表者として英語で質疑応答ができる
  • 社内の英語話者と仕事に関する議論を電話会議でできる

自分は今どこにいる？スタート地点

  • 英語のほとんどが1回では聞き取れない
  • 語彙も少なく、図を使わないとチームメイトと意思疎通ができない
  • 発音が見についておらず、自分の発言が相手に伝わらない
  • TOEIC院試前595がベスト
  • 読むとき、技術文章は1度じゃ理解できない
  • 書くのも1度調べる、長いものは

目的地に達せたかというと、そうとはいえない。ただ、部分的に、手加減してもらっている範囲内で言えば仕事に関して電話会議をする機会は増えた。国際カンファレンスも、質問できるかはおいといて、一年前は全然さっぱりわからなかったのが、今は普通に聞こえるようになっていることを KubeCon で感じたのは大きな進歩を感じた。

上記のスタート地点に比べると、聴き取れる量はだいぶ増えてきたし、喋るのも、ブロークンながらなんとか伝えることもできるようになってきた。読むときの理解のスピードはまだちょっと遅い。Writing も昔よりはスピードとか分量書けるようになってきたけどまだまだって感じ。

5月に一度振り返ったんだが、このタイミングでまた次の1年どこを目指して、何がギャップで、そのために何をするのかというのをあらためて整理する。方向が定まれば、やるだけなので。

おしまい。