オンラインの技術カンファレンスを 安定稼働させるための取り組み Presented by @inductor

自己紹介 Kohei Ota (@inductor) •アーキテクト@HPE •CNCF Ambassador •Google Developer Expert (GCP) •CloudNative Days Tokyo 運営 •Container Runtime Meetup 運営 •Kubernetes SIG-Docs Japanese owner •Docker Meetup Tokyo 運営

人類がコロナ時代に入ってからもうすぐ2年...

人類がコロナ時代に入ってからもうすぐ2年... 2020年頭に最後のほうに参加した オフライン勉強会 中止になるイベントも多数 そのあとはずっとオンライン

ミートアップでの取り組み ● ZOOMの配信機能がかなり便利だった ○ ほぼゼロコンフィグでYouTube Liveとの連携が終わる ○ ただし細かいことはいじれないのでレールに乗っかるしかない ● 配信機材調達や環境の準備が面倒 ○ 家で配信することになるので人によって音質・画質・回線品質がまちまち ● 懇親会や質問による人間のやりとりがやりづらい ○ Sli.doやTwitterなどのみでは質問内容や回答できる範囲に限界が・・・ → 大変になった部分もあったけど、やればやれないことはないレベル

カンファレンスとミートアップの違い ● 単にconnpassを用意して配信環境を用意するでもいいけど・・・ ○ カンファレンスたるもの、提供できる形をもっと練るべき ○ 月１とかじゃなくて年に数回のお祭りの体験が損なわれるのはコミュニティとしても損失 ● 既存のプラットフォームを検討するも ○ やりたい形に沿わないプラットフォームのSaaS ○ 高い利用料 ○ そもそも品質に疑問があることも → スポンサーやバックの企業ともつながりのあるカンファレンスでは 　 そう簡単にはいかなかった...

カンファレンスとミートアップの違い ● 単にconnpassを用意して配信環境を用意するでもいいけど・・・ ○ カンファレンスたるもの、提供できる形をもっと練るべき ○ 月１とかじゃなくて年に数回のお祭りの体験が損なわれるのはコミュニティとしても損失 ● 既存のプラットフォームを検討するも ○ やりたい形に沿わないプラットフォームのSaaS ○ 高い利用料 ○ そもそも品質に疑問があることも → スポンサーやバックの企業ともつながりのあるカンファレンスでは 　 そう簡単にはいかなかった... 自分たちでプラットフォームを作ってこそ エンジニアじゃないか！ →つくった

No content

CloudNative Days Tokyo 2021 ● 日付 2021年11月4日（木）-5日（金） ● 会場 オンライン開催 ● 主催 CloudNative Days Tokyo Committee ● 参加費 無料（事前登録制） ● 想定人数 2,000名〜3,000名 ● 想定来場者インフラエンジニア SRE, アプリエンジニアなど8割以上が開発者、その他 CTO/CIO, システムインテグレーターなど ● キーワードCloudNative, Kubernetes, Container, Microservices, CI/CD, DevOps, Edge/NFV, AI/Machine Learning, GPU/HPC ● URL https://event.cloudnativedays.jp/cndt2021 Overview 9

CNDT2021 実行委員会メンバー Co-Chair Operation Platform Promotion Contents Broadcast Co-Chair

CNDT2021 実行委員会メンバー Co-Chair Operation Platform Promotion Contents Broadcast Co-Chair SREなことを やってる2人

Dreamkast: オンライン配信プラットフォーム ● https://github.com/cloudnativedaysjp/dreamkast ● https://github.com/cloudnativedaysjp/dreamkast-infra ● RailsのWebアプリ + Next.jsの配信ダッシュボード(視聴者画面) ● EKS + IVS + MediaLive で組まれたインフラ ○ EKSでRailsを動かしてIVSとMediaLiveで配信を受ける構成

CNDT2021 実行委員会メンバー Co-Chair Operation Platform Promotion Contents Broadcast Co-Chair SREなことを やってる2人 プラットフォームとしての改善の話はこの スライドを見てください

No content

自前配信の仕組み

これまでの変遷 ● v1はHerokuで作って公開した ○ 便利だし楽、使い慣れてもいる ○ レイテンシが大きい＋開発体制としても今後どんどん大きくなっていった時に取り回しが 効かなくなってくる ○ ECSかEKSか迷ってEKSにした（使い慣れてるし） ● まともにAWSで大きなものを作ると高い ○ RedisにElastiCache最初は使ってたけどやめた ■ 高い上にそこまで使いきれなかった→自前でRedisを動かすことに ○ 全部Spotインスタンスで動かす強気の運用 ■ めちゃめちゃ安い ○ 仕事じゃないので使えるものは使う ■ マネージドノードグループ、Cluster Autoscaler、Bottlerocket(最近入れた)

改善してきたこと ● 運用のために使っているKubernetesマニフェストとCloudFormationの YAMLファイルはかなり成長してきた ○ それなりの規模で動かしても大丈夫なくらいにはまともなコードになりつつあると思う ● 相方のSREがPull requestベースでステージング上に検証用のPodが立ち上 がってLBに登録されるみたいなやつをオペレーター実装してくれた ● AWS自体で取り組まれている改善は極力リアルタイムに入れている ○ 運用周りのオペレーターとか、新機能の追加検証とか、好きに実験してる ○ さっきのページの「仕事じゃないので使えるものは使う」に同じ ○ Fargateは最初入れたけどスケールが遅いのでやめた

今まで起こったプラットフォーム周りのあれこれ ● イベント開始直後に500エラーが頻発(EKSにしてから最初のイベント) ○ アクセス過多でスケールが間に合わなくて捌ききれなかった ○ 手動でスケールしてどうにかしたけど次からはちゃんと負荷試験かけるようにした ○ 本番ではなくプレイベントでよかった・・・(これ以外にもプレイベントでは本番で困らない ようにたくさんのことを実験しています） ● ArgoCDが重くて動かなくなった ○ リポジトリ登録数が増えて負荷が高くなった ○ デフォルトで設定されていたCPU Limitsを引き上げて解決 ● 激アツ！Redis再起動 ○ ログインセッションがブチッと切れる→こまる ○ 実はまだ改善しないといけないポイント

今後直したい課題 ● アプリケーションログの整理と集約、整備 ○ Loki入れてるには入れてるけど活用できてない & CloudWatchのContainer Insightsはずっ と動かしてるとカネがかかる ● Railsアプリの分散トレーシング ○ Jaeger検証中だけどRuby(Rails) + Open Telemetryもうちょっと枯れてほしい ○ X-rayは検証した限り使い物にならなくてやめた ● 運用ドキュメントもうちょっと整備したい ● 入れたHelmとかオペレーターのメンテナンスどうするか ○ バージョンアップ手動おじさんの限界

今後直したい課題 ● アプリケーションログの整理と集約、整備 ○ Loki入れてるには入れてるけど活用できてない & CloudWatchのContainer Insightsはずっ と動かしてるとカネがかかる ● Railsアプリの分散トレーシング ○ Jaeger検証中だけどRuby(Rails) + Open Telemetryもうちょっと枯れてほしい ○ X-rayは検証した限り使い物にならなくてやめた ● 運用ドキュメントもうちょっと整備したい ● 入れたHelmとかオペレーターのメンテナンスどうするか ○ バージョンアップ手動おじさんの限界 いろんなポイントで改善が必要 アプリの可観測性 Day 2 operationの改善

まとめ ● 1からSREを実践できる環境は少ない ○ スケールしながら育てていくもの ● サービスのフェーズに合わせてできることから取り組む ● 多様性を大事にする ○ メンバーごとに得意なことが違って良い。それが大きなSREになってゆく ● SREチームを作って満足しない ○ 本質はサービスが重要なタイミングで正しく動き続けること ○ 対話によって数字を決めましょう

We are hiring!! (運営メンバー)