オンラインの技術カンファレンスを安定稼働させるための取り組み / SRE activity for online conference platform

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

8. View Slide

9. 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
   

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

14. View Slide

15. 自前配信の仕組み
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide