Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Kohei Ota
November 09, 2021

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

Kohei Ota

November 09, 2021
Tweet

More Decks by Kohei Ota

Other Decks in Technology

Transcript

  1. 自己紹介 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. ミートアップでの取り組み • ZOOMの配信機能がかなり便利だった ◦ ほぼゼロコンフィグでYouTube Liveとの連携が終わる ◦ ただし細かいことはいじれないのでレールに乗っかるしかない • 配信機材調達や環境の準備が面倒

    ◦ 家で配信することになるので人によって音質・画質・回線品質がまちまち • 懇親会や質問による人間のやりとりがやりづらい ◦ Sli.doやTwitterなどのみでは質問内容や回答できる範囲に限界が・・・ → 大変になった部分もあったけど、やればやれないことはないレベル
  3. カンファレンスとミートアップの違い • 単にconnpassを用意して配信環境を用意するでもいいけど・・・ ◦ カンファレンスたるもの、提供できる形をもっと練るべき ◦ 月1とかじゃなくて年に数回のお祭りの体験が損なわれるのはコミュニティとしても損失 • 既存のプラットフォームを検討するも ◦

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

    やりたい形に沿わないプラットフォームのSaaS ◦ 高い利用料 ◦ そもそも品質に疑問があることも → スポンサーやバックの企業ともつながりのあるカンファレンスでは   そう簡単にはいかなかった... 自分たちでプラットフォームを作ってこそ エンジニアじゃないか! →つくった
  5. 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
  6. CNDT2021 実行委員会メンバー Co-Chair Operation Platform Promotion Contents Broadcast Co-Chair SREなことを

    やってる2人 プラットフォームとしての改善の話はこの スライドを見てください
  7. これまでの変遷 • v1はHerokuで作って公開した ◦ 便利だし楽、使い慣れてもいる ◦ レイテンシが大きい+開発体制としても今後どんどん大きくなっていった時に取り回しが 効かなくなってくる ◦ ECSかEKSか迷ってEKSにした(使い慣れてるし)

    • まともにAWSで大きなものを作ると高い ◦ RedisにElastiCache最初は使ってたけどやめた ▪ 高い上にそこまで使いきれなかった→自前でRedisを動かすことに ◦ 全部Spotインスタンスで動かす強気の運用 ▪ めちゃめちゃ安い ◦ 仕事じゃないので使えるものは使う ▪ マネージドノードグループ、Cluster Autoscaler、Bottlerocket(最近入れた)
  8. 改善してきたこと • 運用のために使っているKubernetesマニフェストとCloudFormationの YAMLファイルはかなり成長してきた ◦ それなりの規模で動かしても大丈夫なくらいにはまともなコードになりつつあると思う • 相方のSREがPull requestベースでステージング上に検証用のPodが立ち上 がってLBに登録されるみたいなやつをオペレーター実装してくれた

    • AWS自体で取り組まれている改善は極力リアルタイムに入れている ◦ 運用周りのオペレーターとか、新機能の追加検証とか、好きに実験してる ◦ さっきのページの「仕事じゃないので使えるものは使う」に同じ ◦ Fargateは最初入れたけどスケールが遅いのでやめた
  9. 今後直したい課題 • アプリケーションログの整理と集約、整備 ◦ Loki入れてるには入れてるけど活用できてない & CloudWatchのContainer Insightsはずっ と動かしてるとカネがかかる •

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

    Railsアプリの分散トレーシング ◦ Jaeger検証中だけどRuby(Rails) + Open Telemetryもうちょっと枯れてほしい ◦ X-rayは検証した限り使い物にならなくてやめた • 運用ドキュメントもうちょっと整備したい • 入れたHelmとかオペレーターのメンテナンスどうするか ◦ バージョンアップ手動おじさんの限界 いろんなポイントで改善が必要 アプリの可観測性 Day 2 operationの改善
  11. まとめ • 1からSREを実践できる環境は少ない ◦ スケールしながら育てていくもの • サービスのフェーズに合わせてできることから取り組む • 多様性を大事にする ◦

    メンバーごとに得意なことが違って良い。それが大きなSREになってゆく • SREチームを作って満足しない ◦ 本質はサービスが重要なタイミングで正しく動き続けること ◦ 対話によって数字を決めましょう