ツナワタリマイライフ

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

GitHub の Issue の数を prometheus 形式で export する OSS 作った

作った。

github.com

github.com

これのお友達。

なぜ作ったか

Quipper では基本 Issue で仕事をしている。で、適当に Label も活用している。

もともとの Motivation は Open になってる Postmortem Issue が放置されてることだったりする。

結局いまだに放置されていてその問題は解決していないのだけれど....

f:id:take_she12:20210127054456p:plain

こんな風に metric として可視化されると、n 件たまったらアラートとかできる。するかはまだわからない。

そもそも今 Workload の管理というか、Issue 管理全然できてるとは言えない。が、まぁなんにせよ見えるようにして長期トレンドを見て何かアクションする、みたいなことはできる可能性がある。この手の可視化、metric 化はそれによって意味のあるアクションが取れるか、意味のある意思決定がとれるかは、とってみて眺めて味わう、というフェーズがないとなんとも言えんので、しばらくはちょっとでも「あると便利かも？」と思ったものはバンバン送ろうと思っている。

工夫した点

Label Filtering

Issue は多い。開きっぱなしのものも多い。しかも Quipper の場合は quipper/quipper にかなりの割合のメンバーが issue を作成しているので多い。3k とか 5k とかある。ので、取得時点で Label でフィルタリングできるようにしている。

github.com

GITHUB_LABEL という環境変数からとってきて、ListOption にいれる。

で、ないならないで良いようにもした。

github.com

Pagination

工夫というほどでもないけど。GitHub API は default で 30件、max 100件しか取れない。

ちゃんと Pagination 対応した。

github.com

ただ数k になると結構時間かかって、Ticker の Interval 以内に取得できないケースもある。

次回作

Github 編は終わり。次は AWS の RDS Engine Version を Prometheus 形式で Export するやつを作る。これまた役に立つか、Alert つけるにせよどのバージョンがアウトかを管理する必要があるので、そのへんどうできるかは不明だが、とりあえず作る。

GitHub の Repository の Pull Request の数を prometheus 形式で export する OSS 作った

昨日のこれ

blog.chaspy.me

自分の発表では prometheus 形式で export したら Datadog の Kubernetes Autodiscovery で datadog-agent が勝手に取ってくれて便利だよなんて言ったんですが

docs.datadoghq.com

prometheus 形式で export するのに個別にタグつけて export できないと思ってたんですが

godoc.org

In addition to the fundamental metric types Gauge, Counter, Summary, and Histogram, a very important part of the Prometheus data model is the partitioning of samples along dimensions called labels, which results in metric vectors. The fundamental types are GaugeVec, CounterVec, SummaryVec, and HistogramVec.

できる（できる）

ということを8億年前から知っていた @yuya-takeyama に教えてもらったので書き直しました。一応前のは残して別の repository に書きました。

github.com

つぎはぎだらけでだいぶ雑な気がしますがまぁ動いているからいいのだ。

これは何

prometheus 形式で Github の指定した repository の pull request の数を author, reviewer, label をタグとしてつけて export する君です。

f:id:take_she12:20210126035051p:plain

github.com

こっちは push のアプローチで、この中で Datadog に対して metrics を投げつけるんですが、

今回作った github-pr-prometheus-exporter は Datadog 関係ないです。prometheus 形式で、 8080:/metrics で metrics を export するだけ。

で、こういう annotation 書けば datadog-agent が取ってくれるので便利。pull 型のアプローチですね。使ってる manifest そのまま晒しちゃいます。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: github-pr-prometheus-exporter
  namespace: monitor
  labels:
    name: github-pr-prometheus-exporter
    owner: sre
spec:
  replicas: 1
  selector:
    matchLabels:
      app: github-pr-prometheus-exporter
  template:
    metadata:
      labels:
        app: github-pr-prometheus-exporter
      annotations:
        ad.datadoghq.com/github-pr-prometheus-exporter.check_names: |
          ["prometheus"]
        ad.datadoghq.com/github-pr-prometheus-exporter.init_configs: |
          [{}]
        ad.datadoghq.com/github-pr-prometheus-exporter.instances: |
          [
            {
              "prometheus_url": "http://%%host%%:8080/metrics",
              "namespace": "github-pr-prometheus-exporter",
              "metrics": ["*"]
            }
          ]
    spec:
      containers:
      - image: chaspy/github-pr-prometheus-exporter:v0.1.0
        name: github-pr-prometheus-exporter
        ports:
        - name: http
          containerPort: 8080
        livenessProbe:
          initialDelaySeconds: 1
          httpGet:
            path: /metrics
            port: 8080
        resources:
          limits:
            memory: 32Mi
          requests:
            cpu: 10m
            memory: 32Mi
        env:
          - name: GITHUB_TOKEN 
            valueFrom:   
              secretKeyRef:  
                name: "github-secret" 
                key: GITHUB_TOKEN
          - name: GITHUB_REPOSITORIES  
            value: "quipper/kubernetes-clusters,quipper/server-templates,quipper/monorepo,quipper/monorepo-global,quipper/qs-terraform,quipper/aya-terraform,quipper/iam,quipper/aya-iam,quipper/dns,quipper/aya-dns"
        securityContext:
          readOnlyRootFilesystem: true
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
      imagePullSecrets:
        - name: docker-hub
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: quipper/type
                operator: In
                values:
                - system-components

別に push 方式でも全然いいんですが、Datadog 関係の secret を持つ必要がないって点が利点ですかね。

前作と同じく環境変数 GITHUB_REPOSITORIES で対象リポジトリを指定します。

     - name: GITHUB_REPOSITORIES  
       value: "quipper/kubernetes-clusters,quipper/server-templates,quipper/monorepo,quipper/monorepo-global,quipper/qs-terraform,quipper/aya-terraform,quipper/iam,quipper/aya-iam,quipper/dns,quipper/aya-dns"

もはやこれを deployment として浮かせることすらしたくない（どっかのサーバレスな何かに image だけ指定していい感じに動いて欲しい）ぐらいには怠惰になってきた。

まぁ何はともあれ、push 形式の前作を cronjob で定期実行するよりはこっちのアプローチのほうがいいかなと思い書き直したという話でした。

次こそはこれの issue ver を作る。

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 にしたがっていじるんだろうな。