CloudNative Days を支える CI/CD ワークフローの変遷 かなた / @kanatakita
 1

$ whoami 北澤 祥太 / かなた
 @kanatakita
 ShotaKitazawa
 本業:
 パブリッククラウドサービス開発のための共通基盤の構築・運用
 SRE の導入・推進
 趣味:
 ラーメン、スノボ、自宅鯖構築 最近できてない、イベント裏方
 最近:
 ISUCON11 予選作問担当、reviewapp-operator 開発
 2 よく使う アイコン

本日のお話 3

CloudNative Days の運営体制 4 Operation Promotion Contents Dreamkast Broadcast SNS等への
 プロモーション
 配信周りの
 エンジニアリング
 配信基盤の開発・運用 
 イベント当日オペレーション担当 
 イベントコンテンツの 
 考案・準備


Dreamkast チームの取り組み > 配信プラットフォームの開発
 ● Ruby on Rails (dreamkast) / 
 React (dreamkast-ui) にて開発
 ● オンラインカンファレンスに
 必要な機能を Web サービスとして提供
 (ストリーム配信/チャット/QA機能/...)
 
 > アプリケーション動作基盤の構築・運用
 ● AWS / EKS を利用
 ● アプリケーションに対する
 CI/CD やモニタリングも実施
 5

本日のお話 6 Dreamkast の


TL;DR この発表を3行でまとめると
 ● 従来の Dreamkast のリリースフローをいい感じに作ったけど
 ● 運用してくうちに痒いところが何個か出てきたから
 ● kubernetes operator を自作してもっといい感じにしたよ
 7

従来の話 ~ CloudNative Days Spring 2021 Online (Mar 11-12, 2021) 8

Dreamkast v2 Infra Architcture 9 more information... Kubernetesなんて知りたくなかった。ただ楽してアプリを作りたかっただけなんだ。 
 @jacopen ー CloudNative Days Spring 2021 Online 
 dreamkast
 dreamkast-ui
 cert-manager
 redis
 Argo CD
 Prometheus
 Grafana
 Loki
 2 環境
 dev/prod
 リソース管理
 ドメイン管理
 external-
 secrets


アプリケーションリポジトリ (app-repo) とマニフェストリポジトリ (infra-repo) を分割
 infra-repo app-repo Dreamkast v2 のリポジトリ構成 10 dreamkast
 dreamkast-ui
 dreamkast-infra
 Argo CD polling

Dreamkast v2 のリリースフロー要件 Dreamkast v1 (on Heroku) の開発体験を損なわないために、以下は必須要件
 ● ステージング環境 (stg) と本番環境 (prd) があり、
 本番環境は必ずステージング環境から promote される必要がある
 ● app-repo に PR を出す毎に検証用環境 (dev) が立ち上がる (Review Apps)
 11 dev
 stg
 prd
 merge
 promote


Dreamkast のリリースフローの実現 ● 「dev = PullRequest」「stg = main ブランチ」「prd = Latest tag」
 ● GitHub Actions を利用して infra-repo を操作
 ● タグ打ちオペレーションを ChatOps で実施
 12

Dreamkast のリリースフローの実現 ● 「PullRequest = dev」「main ブランチ = stg」「Latest tag = prd」
 ● GitHub Actions を利用して infra-repo を操作
 ● タグ打ちオペレーションを ChatOps で実施
 13

Dreamkast のリリースフローの実現 14 manifest/app ├── argocd-apps │ ├── development │ │ └── (dev-cluster 用 ArgoCD Application manifest) │ └── production │ └── (prod-cluster 用 ArgoCD Application manifest) └── dreamkast ├── base │ └── (base manifests) └── overlays ├── development │ ├── dk-${PR_NUM} │ │ ├── kustomization.yaml │ │ └── other manifests │ └── … ├── staging │ └── main │ ├── kustomization.yaml │ └── other manifests └── production └── main dreamkast-infra 
 一部抜粋
 dev/prod cluster で Argo CD Application 
 マニフェストを配置するディレクトリを分け、 
 そこから dreamkast 用マニフェストを watch 


Dreamkast のリリースフローの実現 15 manifest/app ├── argocd-apps │ ├── development │ │ └── (dev-cluster 用 ArgoCD Application manifest) │ └── production │ └── (prod-cluster 用 ArgoCD Application manifest) └── dreamkast ├── base │ └── (base manifests) └── overlays ├── development │ ├── dk-${PR_NUM} │ │ ├── kustomization.yaml │ │ └── other manifests │ └── … ├── staging │ └── main │ ├── kustomization.yaml │ └── other manifests └── production └── main dreamkast-infra 
 一部抜粋
 staging/production
 更新時
 GitHub Actions にてマニフェストの imageTag を更新
 app-repo の main HEAD が更新されると 
 (production の場合は Latest tag) 
 左記の imageTag も更新される 
 


Dreamkast のリリースフローの実現 16 manifest/app ├── argocd-apps │ ├── development │ │ └── (dev-cluster 用 ArgoCD Application manifest) │ └── production │ └── (prod-cluster 用 ArgoCD Application manifest) └── dreamkast ├── base │ └── (base manifests) └── overlays ├── development │ ├── dk-${PR_NUM} │ │ ├── kustomization.yaml │ │ └── other manifests │ └── … ├── staging │ └── main │ ├── kustomization.yaml │ └── other manifests └── production └── main dreamkast-infra 
 一部抜粋
 Argo CD Application 用 
 マニフェストも push
 manifest/app/argocd-apps/development 以下を dev-cluster の Argo CD が watch 
 することで Review Apps を実現 
 development
 更新時
 ディレクトリごとテンプレートから新規作 成


Dreamkast のリリースフローの実現 17 New!
 Other Manifests Argo CD Application

Dreamkast のリリースフローの実現 ● 「PullRequest = dev」「main ブランチ = stg」「Latest tag = prd」
 ● GitHub Actions を利用して infra-repo を操作
 ● タグ打ちオペレーションを ChatOps で実施
 18

Dreamkast のリリースフローの実現 ● 「PullRequest = dev」「main ブランチ = stg」「Latest tag = prd」
 ● GitHub Actions を利用して infra-repo を操作
 ● タグ打ちオペレーションを ChatOps で実施
 ○ actions-ecosystem の各種アクションを利用
 ■ PR の label (patch/minor/major) を元に semver なタグの自動インクリメント 
 ○ dreamkast-releasebot の実装
 ■ main に対して更新差分が empty commits のみである PR を 
 作成するだけの Slack Bot
 19

いい感じに dreamkast の CI/CD が整備できた！ 20

CloudNative Days Spring 2021 Online (Mar 11-12, 2021) ~ Now 21

新メンバー加入！ → リリースフロー周りを説明...
 ☞ 説明してても結構複雑...
 
 
 22 ある日の会話①

「たまに動かない時があるんですが」
 　「それは原因が分かってるんですが解決が面倒なので運用でカバーしてます」
 
 
 23 ある日の会話②

ある日の会話③ 「app の新コンポーネント実装しました！」
 「infra-repo のマニフェストを更新したいんですけど、何やれば Review Apps で反映され ます？？」
 　「これとこれのマニフェストは今更新が必要で、マージ後にはこっちのファイルを更新す る必要があって...」
 24

リリースフローの課題感 ● app と infra の境界線が曖昧
 ○ infra のドメイン知識を加味した gitops-xxx.yaml を app リポジトリに配置する必要がある 
 ○ infra 管理者が manifest-repo だけを見て「どの app-repo からマニフェストの更新が来る か」といった全容を把握できない 
 ● (特に Review Apps の仕組みが) まれによくバグる
 ○ 例. PR を Open してすぐ Close したとき、GC action が gitops-dev action 
 より早く manifest-repo を更新しようとすると不整合が発生 
 ● Review Apps として展開されるマニフェストのテンプレートを更新したいときの操作 が煩雑
 ○ gitops-dev action により自動生成されるマニフェストを手動更新する必要性 
 ○ テンプレートの更新タイミングが難しい 
 25

リリースフローの課題感 ● app と infra の境界線が曖昧
 ○ infra のドメイン知識を加味した gitops-xxx.yaml を app リポジトリに配置する必要がある 
 ○ infra 管理者が manifest-repo だけを見て「どの app-repo からマニフェストの更新が来る か」といった全容を把握できない 
 ● (特に Review Apps の仕組みが) まれによくバグる
 ○ 例. PR を Open してすぐ Close したとき、GC action が gitops-dev action 
 より早く manifest-repo を更新しようとすると不整合が発生 
 ● Review Apps として展開されるマニフェストのテンプレートを更新したいときの操作 が煩雑
 ○ gitops-dev action により自動生成されるマニフェストを手動更新する必要性 
 ○ テンプレートの更新タイミングが難しい 
 26 
 GitOps をしてるはずなのに CIOps になってる...？


GitOps? CIOps? CIOps
 ● CI 内で CD もやってしまう構成 
 ● 世の中の CI ツールはだいたい push 型 
 pros
 ● CI に全てのフローが集中するので、 単純
 cons
 ● ビルドとデプロイが不可分 
 ○ app-repo 管理者がデプロイ先の知識を
 持つ必要がある
 GitOps
 ● Git をベースに CI と CD を分離した構成 
 ● SSoT を実現するために基本的に pull 型 
 pros
 ● SSoT の実現
 ● 責任分界点の明確化 
 ○ CI: app team / CD: infra team
 cons
 ● CI/CD が分離するのでその分複雑 
 27 push hook deploy push pull CI & CD config CI config CD config ref

Dreamkast のリリースフロー 「app-repo で GitHub Actions を用いた CI と infra-repo で Argo CD を
 用いた CD とで分離してるし infra-repo は SSoT にもなってるから GitOps だね」
 28 infra-repo
 管理者


ちょっとまって？ 「gitops GitHub Action に複雑なロジックがあり、
 しかもそれがバグると app-repo 管理者が調査する必要があり辛い」
 ○ 「infra-repo をデプロイ先とみなした場合の CIOps 」とも言える
 29 app-repo
 管理者


リリースフローの課題感 ● app と infra の境界線が曖昧
 ○ infra のドメイン知識を加味した gitops-xxx.yaml を app リポジトリに配置する必要がある 
 ○ infra 管理者が manifest-repo だけを見て「どの app-repo からマニフェストの更新が来る か」といった全容を把握できない 
 ● (特に Review Apps の仕組みが) まれによくバグる
 ○ 例. PR を Open してすぐ Close したとき、GC action が gitops-dev action 
 より早く manifest-repo を更新しようとすると不整合が発生 
 ● Review Apps として展開されるマニフェストのテンプレートを更新したいときの操作 が煩雑
 ○ gitops-dev action により自動生成されるマニフェストを手動更新する必要性 
 ○ テンプレートの更新タイミングが難しい 
 30 バグった際に app-repo を触る開発者が これを調査しなければならず辛い
 (CIOps の欠点)


リリースフローの課題感 ● app と infra の境界線が曖昧
 ○ infra のドメイン知識を加味した gitops-xxx.yaml を app リポジトリに配置する必要がある 
 ○ infra 管理者が manifest-repo だけを見て「どの app-repo からマニフェストの更新が来る か」といった全容を把握できない 
 ● (特に Review Apps の仕組みが) まれによくバグる
 ○ 例. PR を Open してすぐ Close したとき、GC action が gitops-dev action 
 より早く manifest-repo を更新しようとすると不整合が発生 
 ● Review Apps として展開されるマニフェストのテンプレートを更新したいときの操作 が煩雑
 ○ gitops-dev action により自動生成されるマニフェストを手動更新する必要性 
 ○ テンプレートの更新タイミングが難しい 
 31 イベントをトリガーに infra-repo の更新処 理が手続き的に実行される
 ⇒ 宣言的に管理したい


リリースフローの課題感 ● app と infra の境界線が曖昧
 ○ infra のドメイン知識を加味した gitops-xxx.yaml を app リポジトリに配置する必要がある 
 ○ infra 管理者が manifest-repo だけを見て「どの app-repo からマニフェストの更新が来る か」といった全容を把握できない 
 ● (特に Review Apps の仕組みが) まれによくバグる
 ○ 例. PR を Open してすぐ Close したとき、GC action が gitops-dev action 
 より早く manifest-repo を更新しようとすると不整合が発生 
 ● Review Apps として展開されるマニフェストのテンプレートを更新したいときの操作 が煩雑
 ○ gitops-dev action により自動生成されるマニフェストを手動更新する必要性 
 ○ テンプレートの更新タイミングが難しい 
 32 自前実装 gitops Action に
 このあたりの機能が足りてない
 ⇒ 要実装


やりたいこと ● Review Apps の知識を app-repo に置きたくなくて ● 宣言的に Review Apps 環境の管理をしたくて ● 運用に困ったら機能拡張していきたい
 33

既存の OSS にないか？ Argo CD Image Updater
 ● Argo CD Application オブジェクトを読んで以下を実施
 ○ コンテナレジストリのイメージタグをポーリング監視 
 ○ 更新を検知すると infra-repo のマニフェストを自動更新 
 ● infra-repo のマニフェストをクラスタに適用するのは Argo CD が実施
 ➢ app-repo に infra-repo の知識を一切置く必要がない
 34 参考: 類似ソフトウェア
 ● Flux - Automate image updates to Git
 ● PipeCD - Event watcher


既存の OSS にないか？ Argo CD Image Updater
 ● Argo CD Application オブジェクトを読んで以下を実施
 ○ コンテナレジストリのイメージタグをポーリング監視 
 ○ 更新を検知すると infra-repo のマニフェストを自動更新 
 ● infra-repo のマニフェストをクラスタに適用するのは Argo CD が実施
 ➢ app-repo に infra-repo の知識を一切置く必要がない
 35 参考: 類似ソフトウェア
 ● Flux - Automate image updates to Git
 ● PipeCD - Event watcher
 apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: example namespace: argocd annotations: argocd-image-updater.argoproj.io/image-list: > example01=docker.io/kanatakita/example01, example02=docker.io/kanatakita/example02 argocd-image-updater.argoproj.io/example01.update-strategy: latest argocd-image-updater.argoproj.io/example01.allow-tags: regexp:^main-.*$ argocd-image-updater.argoproj.io/example02.update-strategy: latest argocd-image-updater.argoproj.io/example02.allow-tags: regexp:^main-.*$ argocd-image-updater.argoproj.io/write-back-method: git:secret:argocd/git-creds argocd-image-updater.argoproj.io/git-branch: main spec: ...

既存の OSS にないか？ Argo CD Image Updater
 ● Argo CD Application オブジェクトを読んで以下を実施
 ○ コンテナレジストリのイメージタグをポーリング監視 
 ○ 更新を検知すると infra-repo のマニフェストを自動更新 
 ● infra-repo のマニフェストをクラスタに適用するのは Argo CD が実施
 ➢ app-repo に infra-repo の知識を一切置く必要がない
 36 参考: 類似ソフトウェア
 ● Flux - Automate image updates to Git
 ● PipeCD - Event watcher
 apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: example namespace: argocd annotations: argocd-image-updater.argoproj.io/image-list: > example01=docker.io/kanatakita/example01, example02=docker.io/kanatakita/example02 argocd-image-updater.argoproj.io/example01.update-strategy: latest argocd-image-updater.argoproj.io/example01.allow-tags: regexp:^main-.*$ argocd-image-updater.argoproj.io/example02.update-strategy: latest argocd-image-updater.argoproj.io/example02.allow-tags: regexp:^main-.*$ argocd-image-updater.argoproj.io/write-back-method: git:secret:argocd/git-creds argocd-image-updater.argoproj.io/git-branch: main spec: ... コンテナレジストリを監視対象に設定 
 infra-repo へ
 アクセスするための設 定
 この条件を満たすタグが push さ れた際、 infra-repo 内のマニフェ スト内のタグを更新する


既存の OSS にないか？ Argo CD Image Updater
 ● Argo CD Application オブジェクトを読んで以下を実施
 ○ コンテナレジストリのイメージタグをポーリング監視 
 ○ 更新を検知すると infra-repo のマニフェストを自動更新 
 ● infra-repo のマニフェストをクラスタに適用するのは Argo CD が実施
 ➢ app-repo に infra-repo の知識を一切置く必要がない
 37 参考: 類似ソフトウェア
 ● Flux - Automate image updates to Git
 ● PipeCD - Event watcher
 apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: example namespace: argocd annotations: argocd-image-updater.argoproj.io/image-list: > example01=docker.io/kanatakita/example01, example02=docker.io/kanatakita/example02 argocd-image-updater.argoproj.io/example01.update-strategy: latest argocd-image-updater.argoproj.io/example01.allow-tags: regexp:^main-.*$ argocd-image-updater.argoproj.io/example02.update-strategy: latest argocd-image-updater.argoproj.io/example02.allow-tags: regexp:^main-.*$ argocd-image-updater.argoproj.io/write-back-method: git:secret:argocd/git-creds argocd-image-updater.argoproj.io/git-branch: main spec: ... ➢ Review Apps を実現することが不可能 この条件を満たすタグが push さ れた際、 infra-repo 内のマニフェ スト内のタグを更新する
 infra-repo へ
 アクセスするための設 定
 コンテナレジストリを監視対象に設定 


やりたいこと (再掲) ● Review Apps の知識を app-repo に置きたくなくて ● 宣言的に Review Apps 環境の管理をしたくて ● 運用に困ったら機能拡張していきたい
 38

💡 39

Kubernetes Operator pattern !!! 40 ⇒ https://kubernetes.io/docs/concepts/extend-kubernetes/operator/

リリースフローにおける課題の解決 従来の gitops GitHub Actions の代わりに以下を実装・導入
 ● stg, prd: Argo CD Imager Updater の導入 (※未実施)
 ● dev: reviewapp-operator の新規実装と導入
 41

reviewapp-operator ● Argo CD と協調し Review Apps 環境を構築
 42

reviewapp-operator ● Argo CD と協調し Review Apps 環境を構築
 43 app-repo の open な PR を List し、新規 作成 / closed された PR を検知 


reviewapp-operator ● Argo CD と協調し Review Apps 環境を構築
 44 infra-repo に対し、検知した PR に 
 対応するマニフェストの作成 / 削除 
 Argo CD がマニフェストの
 更新を検知し K8s cluster に適用
 (※reviewapp-operator 責務外)


reviewapp-operator ● Argo CD と協調し Review Apps 環境を構築
 45 app-repo の該当 PR にコメント 
 Argo CD Application 
 オブジェクトの更新を検知 


reviewapp-operator ● Argo CD と協調し Review Apps 環境を構築
 46 app-repo の該当 PR 
 Argo CD Application Object の 
 更新を検知


reviewapp-operator: Custom Resources (v0.0.3) 4つの Custom Resources
 ● ReviewApp
 ○ app-repo の PR 1 つに対し ReviewApp オブジェクト 1 つが対応 
 ○ ReviewAppManager リソースの子リソースとして作成される 
 ○ 外部に及ぼす処理は ReviewApp Reconciler が担当 
 ● ReviewAppManager
 ○ app-repo, infra-repo へのアクセス用設定や、infra-repo の path の指定等を行う 
 ○ ReviewAppManager Reconciler から PR 毎に ReviewApp リソースが作成される 
 ● ManifestsTemplate
 ○ Review Apps 環境を構築するためのマニフェストを定義 
 ● ApplicationTemplate
 ○ 上記マニフェストをデプロイするための Argo CD Application マニフェストを定義 
 ※ 利用者が適用するリソースは下3つ
 47

reviewapp-operator: Custom Resources (v0.0.3) 48

reviewapp-operator: Custom Resources (v0.0.3) 49 ReviewAppManager リソースから、 
 app-repo の PR 毎に ReviewApp リソースが 
 子リソースとして生成される 


reviewapp-operator: Custom Resources (v0.0.3) 50 app-repo の PR を検知し、 
 ApplicationTemplate, ManifestsTemplate リソースを 
 参照して infra-repo にマニフェストを push 


reviewapp-operator のその他の機能 51 ● ApplicationTemplate / ManifestsTemplate のバージョン管理
 ○ app-repo の PR に特定のラベルを付与すると template リソースの spec.candidate 以下のマニフェ ストを参照
 labels: candidate-template watch
 👍 app 開発に合わせてマニフェストファイルを更新したい場合に対応
 reviewapp-o perator
 infra-repo
 ReviewApp
 Manifests
 Template
 Application
 Template
 push manifests


reviewapp-operator のその他の機能 52 ● ApplicationTemplate / ManifestsTemplate のバージョン管理
 ○ app-repo の PR に特定のラベルを付与すると template リソースの spec.candidate 以下のマニフェ ストを参照
 labels: candidate-template watch
 👍 app 開発に合わせてマニフェストファイルを更新したい場合に対応
 reviewapp-o perator
 infra-repo
 ReviewApp
 Application
 Template
 Manifests
 Template
 push manifests
 apiVersion: dreamkast.cloudnativedays.jp/v1alpha1 kind: ApplicationTemplate metadata: name: applicationtemplate-sample spec: stable: | apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: app-”{{.AppRepo.PrNumber}}” spec: ... candidate: | apiVersion: rgoproj.io/v1alpha1 kind: Application metadata: name: app-”{{.AppRepo.PrNumber}}” spec: ...

reviewapp-operator のその他の機能 53 ● ApplicationTemplate / ManifestsTemplate のバージョン管理
 ○ app-repo の PR に特定のラベルを付与すると template リソースの spec.candidate 以下のマニフェ ストを参照
 labels: candidate-template watch
 👍 app 開発に合わせてマニフェストファイルを更新したい場合に対応
 reviewapp-o perator
 infra-repo
 ReviewApp
 Application
 Template
 Manifests
 Template
 push manifests
 apiVersion: dreamkast.cloudnativedays.jp/v1alpha1 kind: ApplicationTemplate metadata: name: applicationtemplate-sample spec: stable: &application | apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: app-{{.AppRepo.PrNumber}}" spec: ... candidate: *application 余談: 同じものを登録したい場合は yaml のアンカーを利用すれば良い 


リリースフローの課題感 (再掲) ● app と infra の境界線が曖昧
 ○ infra のドメイン知識を加味した gitops-xxx.yaml を app リポジトリに配置する必要がある 
 ○ infra 管理者が manifest-repo だけを見て「どの app-repo からマニフェストの更新が来る か」といった全容を把握できない 
 ● (特に Review Apps の仕組みが) まれによくバグる
 ○ 例. PR を Open してすぐ Close したとき、GC action が gitops-dev action 
 より早く manifest-repo を更新しようとすると不整合が発生 
 ● Review Apps として展開されるマニフェストのテンプレートを更新したいときの操作 が煩雑
 ○ gitops-dev action により自動生成されるマニフェストを手動更新する必要性 
 ○ テンプレートの更新タイミングが難しい 
 54 reviewapp-operator 用マニフェストを用い、 
 全て infra-repo で設定を管理 
 operator pattern による宣言的な動作の実現 
 テンプレートを2世代定義可能なインタフェースとした 


やりたいこと (再掲) ● Review Apps の知識を app-repo に置きたくなくて ● 宣言的に Review Apps 環境の管理をしたくて ● 運用に困ったら機能拡張していきたい
 55 ✅
 ✅
 ✅


振り返り ● ここ半年の dreamkast の CI/CD フローを話した
 ○ GitHub Actions (test / build / update infra-repo in dev,stg,prd) + Argo CD 
 → GitHub Actions (test / build) + reviewapp-operator (Review Apps) + 
 Argo CD Image Updater (update infra-repo in stg,prd) + Argo CD 
 ● reviewapp-operator で app-repo と infra-repo の責任分界点が明確化
 ○ CI 側で実現していた Review Apps の仕組みを CD 側に寄せられた 
 ○ ReviewApp 周りの作り込みがしたくなった際も Go + kubebuilder で開発可能 
 ● 正直 reviewapp-operator の導入で CI/CD システム自体の複雑度は上がった
 ○ どうなるかはこれから次第 (ドキュメンテーション / BugFix / operator 開発文化の醸成 / ...) 
 56

Dreamkast チーム 今後のタスク ● 実装
 ○ dreamkast の機能拡充・front/backend 分離 
 ○ dreamkast-ui で利用するストリーミングサービスの変更 (Vimeo → Amazon IVS) 
 ○ dreamkast-archive (by AWS Amplify) 実装 
 ● CI/CD 
 ○ Argo CD Image Updater の導入 
 ○ reviewapp-operator 機能拡張・BugFix 
 ● ...
 
 57

他の取り組み ● Observability チームの発足？ (dreamkast チームからの分離？)
 ○ プロファイラ・分散トレーサの導入 
 ■ メトリクスの充実
 ○ イベント中の dreamkast のメトリクスを一般公開 
 ■ Grafana Dashboard の Dreamkast 埋め込み or Dashboard の新規実装 
 ○ SRE 的な取り組み
 ■ Twitter の FB 等を元にしたイベント時の SLO の策定と SLI の取得 
 ■ 上記 SLI/SLO を元にした開発タスクの優先度決め 
 ○ ...
 58

他の取り組み ● Observability チームの発足？ (dreamkast チームからの分離？)
 ○ 分散トレーシングの導入 
 ■ API を通した っｆdreamkast のが進むことが予想されるため 
 ○ イベント中の dreamkast のメトリクスを公開したい！ 
 ■ Grafana Dashboard の Dreamkast 埋め込み or Dashboard の新規実装 
 ○ SRE 的な取り組み (just idea) 
 ■ Twitter の FB 等を元にしたイベント時の SLO の策定と SLI の取得 
 ■ 上記 SLI/SLO を元にした開発タスクの優先度決め 
 59 興味があれば
 お声掛けください！


参考: リポジトリのリンク ● アプリケーションリポジトリ (app-repo)
 ○ https://github.com/cloudnativedaysjp/dreamkast 
 ○ https://github.com/cloudnativedaysjp/dreamkast-ui 
 ● マニフェストリポジトリ (infra-repo)
 ○ https://github.com/cloudnativedaysjp/dreamkast-infra 
 ● [旧方式] GitOps 用 GitHub Action
 ○ https://github.com/cloudnativedaysjp/action-dreamkast-gitops 
 ● ChatOps による app-repo タグインクリメントの実現
 ○ https://github.com/cloudnativedaysjp/dreamkast-releasebot 
 ○ https://github.com/actions-ecosystem 
 ● reviewapp-operator
 ○ https://github.com/cloudnativedaysjp/reviewapp-operator 
 ● アーカイブサイト (AWS Amplify)
 ○ https://github.com/cloudnativedaysjp/website 
 60