CircleCI 2.0を支えるインフラとSREの役割

Transcript

1. 1 CircleCI 2.0を支えるインフラとSREの 役割 #kimhirokuni #circlecijp

2. 2 1.0からの移行ありがとうございました!! • LXCベースのCI/CD • コンテナを使ったCI/CDのパイオニア • 先日RIPされた

3. 3 CircleCI 2.0について １日120万ビルドのCI/CDプラットフォーム

4. 4 技術編: 2つのクラスター 組織編: SREチームの紹介

5. 5 自己紹介 Kim, Hirokuni (金 洋国) • CircleCI Japan Tech

   Lead • 日本支社の立ち上げ • カンファレンス登壇 • 採用活動 • 記事執筆 • コミュニティー運営 ”この発言は個人の見解ではなく所属する組 織を代表しています” Twitter: https://twitter.com/kimhirokuni

6. 6 おまえSREのこと話せんの？

7. 7 自己紹介 ”この発言は個人の見解ではなく所属する組 織を代表しています” Kim, Hirokuni (金 洋国) • CircleCI

   Japan Tech Lead • 日本支社の立ち上げ • カンファレンス登壇 • 採用活動 • 記事執筆 • コミュニティー運営 • 元プロダクトチーム • 現SREチーム Twitter: https://twitter.com/kimhirokuni

8. 8 宣伝 (会社) • 日本語サポート • ドキュメントの日本語化 • ユーザーコミュニティー CircleCI初の海外支社

   @CircleCIJapan FB Community Group

9. 9 宣伝 (個人) 海外で大流行の電動キックボードを体験できるサービス Hop-on! を運営 • 日本で唯一のサービス(のはず) • みなとみらいで体験できます

   • 続きはhttps://hop-on.jpで！

10. 10 技術編: 2つのクラスター 組織編: SREチームの紹介

11. 11 CircleCI 2.0のアーキテクチャ概要 • マイクロサービス • AWS • Clojure, Go,

    TypeScript • コンテナベース • Kubernetes/Nomad ← 今日はココの話

12. 12 2つのクラスター • Kubernetes ◦ マイクロサービスが動いている • Nomad ◦ ビルド実行のマシン

    二つを分けることでセキュリティーを担保している

13. 13 クラスター間通信

14. 14 Kubernetes • 全てのマイクロサービスが動いている • CoreOS • EC2 • Terraformで管理

15. 15 Nomad 概要 • Servers -> k8s master nodes •

    Clients -> k8s worker nodes • バッチジョブ • ここでビルドが実行される • 1 コンテナ = 1 Nomad Job

16. 16 コンテナ == Nomad Job

17. 17 Nomad ズームイン

18. 18 ビルドが実行されるまで • ビルドリクエスト • Nomad Jobが作られる • Dockerコンテナの起動 •

    Goで書かれたAgent起動 • ビルドのコマンドを逐次実行 • ビルドのログをK8sのサービスへ送信

19. 19 なぜNomadか？ • Nomadはバッチ処理がk8sより得意だった (2016年の時点) • 現時点ではk8sもよくなっている (らしい) • シンプルなアーキテクチャー

    (単一Goバイナリ) • Hashicorp Toolとの親和性 (ConsulやTerraformなど) 詳しくは https://speakerdeck.com/kimh/cdpuratutohuomu

20. 20 技術編: 2つのクラスター 組織編: SREチームの紹介

21. 21 SREチーム構成 • 現在9人のチーム • ４カ国にまたがる • 時差きつい

22. 22 ボーイング方式 • 時差の有効活用 • 継続的なペアリング • 障害時対応

23. 23 コミュニケーション • 基本はSlackを使っている • 情報量が多い話はZoom • 100ワードのSlackより10秒のZoom • １年に一回のAll

    Hands • 半年に一回のチームごとのSmall Hands

24. 24 SREの役割 • 安定したインフラの運用 • プロダクトの開発に集中できるようにサポート • プロダクトエンジニアとのペアリング・コードレビュー • 障害対応

    (日本時間は障害少ない)

25. 25 障害対応フロー #investigation 障害の可能性あり

26. 26 障害対応フロー #investigation #incident 故障かな？と思ったら - ユーザー影響あり - 障害用のZoom開始 -

    @メンションされる

27. 27 障害対応フロー #investigation #incident https://status.circleci.com 故障かな？と思ったら - ユーザー影響あり - 障害用のZoom開始

    - @メンションされる

28. 28 障害対応フロー #investigation #incident https://status.circleci.com Incident Commander Note Taker 任命

    故障かな？と思ったら - ユーザー影響あり - 障害用のZoom開始 - @メンションされる 役割分担 (後述)

29. 29 障害対応フロー #investigation #incident https://status.circleci.com Incident Commander Note Taker 任命

    20分ごとにアップデート 故障かな？と思ったら - ユーザー影響あり - 障害用のZoom開始 - @メンションされる 役割分担 (後述) - できるだけリアルタイム情報 - バナーに表示される

30. 30 障害対応フロー #investigation #incident https://status.circleci.com Incident Commander Note Taker 任命

    20分ごとにアップデート 故障かな？と思ったら - ユーザー影響あり - 障害用のZoom開始 - @メンションされる 役割分担 (後述) - できるだけリアルタイム情報 - バナーに表示される - 30分様子見 - 問題なければクローズ

31. 31 Incident Commander と Note Taker Incident Commander (現場指揮官) •

    障害復旧のために必要なチームを動かす • SREがなることが多いけど、SREとは限らない Note Taker (記録係) • 20分ごとにアップデートを届ける • 時系列をまとめる • zoomのレコーディング

32. 32 Postmortem == 検死解剖 == 反省会 Postmortem準備 • 障害報告書のPRを作成 •

    関係者のミーティングセットアップ Postmortem中 • PRをレビュー • Note Takerの事実ベースの分析 • 障害宣言は適切なタイミングだったか? • どうやれば障害を防げたか？ • PRをマージ

33. 33 おわりに

34. 34 今後の課題: ホスティング型k8sサービスへの移行 メリット • GKEの機能が豊富 • GCP安い デメリット •

    AWSからの移行 メリット • 移行なし • 学習コスト低い デメリット • 機能面でGKEに劣る

35. 35 今後の課題: チームの拡大 • Platform Engineeringの設立 • SREチームの拡大 • プロアクティブなSRE業

36. 36 WE ARE HIRING!

37. 37 SRE Team in Japan こんな人募集 • CircleCIに興味がある • 大規模インフラを面倒みたい

    • コンテナをガチでやりたい • 海外のチームと働きたい

38. Thank you. 38 Optional Name