CircleCI 2.0を支える2つのコンテナクラスターとSRE

by Kim, Hirokuni

Slide 1

Slide 1 text

1 を支えるつのコンテナクラスターと

Slide 2

Slide 2 text

2 について ● クラウド型のCI/CDのリーダー ● 2019年最大規模のCI/CDプラットフォームの一つ ● 日本にもたくさんのお客様にご利用いただいています

Slide 3

Slide 3 text

3 のご紹介 ● 日本語サポート ● ドキュメントの日本語化 ● ユーザーコミュニティー CircleCI初の海外支社 @CircleCIJapan FB Community Group

Slide 4

Slide 4 text

4 日本のコミュニティとマーケットをサポート日本語サポート日本語ドキュメント日本語製品紹介ユーザーコミュニティ

Slide 5

Slide 5 text

5 ただいまチャットサポートトライアル実施中 APIで特定のworkflowを実行したいが、起動しません。 Beta版ですが、API v2を利用するのはいかがでしょうか？こんにちは CircleCIにログインし、右下にチャットボタンが表示されます → 期間限定で平日の14時から17時で実施中！ ⭐最近CircleCIを使い始めた方や最新機能についてもっと知りたい方ご質問大歓迎です ⭐

Slide 6

Slide 6 text

6 自己紹介 Kim, Hirokuni (金洋国) ● CircleCI SRE ● CircleCI Japan Tech Lead ● CircleCI検定2級 (注: 妄想です。実在しません。 ) ● 日本支社の立ち上げ ● カンファレンス登壇 ● 採用活動 ● 記事執筆 ● コミュニティー運営 Twitter: https://twitter.com/kimhirokuni

Slide 7

Slide 7 text

7 宣伝個人電動キックボードを公道で体験できるサービス Hop-on! を運営 ● みなとみらい・渋谷で体験できます ● 続きは https://hop-on.jp で！

Slide 8

Slide 8 text

8 完全コンテナベースの ● Dockerコンテナ上でビルド可能 ● 好きなコンテナイメージを使うことができる ● 複数のサービスコンテナを追加可能 ● 2016年の夏にBeta版運用開始

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

10 について ● 5万ビルド / 1hr ● ~8000ビルド / 1min ● ~130ビルド / 1 sec １日120万どのようにしてこれらのビルドをハンドリングしているか

Slide 11

Slide 11 text

11 技術編つのクラスター組織編チームの紹介

Slide 12

Slide 12 text

12 技術編つのクラスター組織編チームの紹介

Slide 13

Slide 13 text

13 つのコンテナクラスター ● Kubernetes ○ マイクロサービス用のコンテナを管理 ● Nomad ○ ビルド用のコンテナを管理

Slide 14

Slide 14 text

14 つのコンテナクラスター Services - フロントエンド - 課金 - ユーザー管理 - WebHook処理 - etc, Executions - Docker ImageのPull - コードのcheckout - ビルドコマンドの実行 - Artifactsの保存二つを分けることでセキュリティーを担保している

Slide 15

Slide 15 text

15 のマイクロサービスを支えるクラスター

Slide 16

Slide 16 text

16 ● 全てのマイクロサービスが動いている (約60サービス) ● 自前でEC2上で管理 (後述) ● サービス間通信にはgRPCとRabbitMQを使用

Slide 17

Slide 17 text

17 マイクロサービス間の通信非同期 ● RabbitMQを使用 ● 非同期通信が推奨 ● 可能限りこちらを使う ● 分散システムでは非同期のほうがよい ● 毎秒何千ものリクエストを処理

Slide 18

Slide 18 text

18 ● Kubernetes for everything!! ● RabbitMQのスケーラビリティーの向上 ● StatefulSetsの使用 ○ 同じVolume, Pod名などを使える ● 現在テスト中

Slide 19

Slide 19 text

19 マイクロサービス間の通信同期 ● gRPCを使用 ● 元々はビルドログをストリーミングするのに使用 ● 現在、サービス間通信のデフォルト ● スケールするには一工夫必要 (次スライド)

Slide 20

Slide 20 text

20 の問題点 ● Master nodeのマネージメント ○ Etcd ○ OSの管理: CoreOS ● 認証・セキュリティー ○ Public API endpointの安全性 ○ ユーザーの管理 ● アップグレード問題

Slide 21

Slide 21 text

21 今後の課題への移行検討中 ● Master nodeのマネージメント ○ Etcd ✔ ○ 証明書の管理 ✔ ● 認証・セキュリティー ○ Public API endpointの安全性✔ ○ ユーザーの管理 ✔ ● アップグレード問題 △　

Slide 22

Slide 22 text

22 のを支えるクラスター

Slide 23

Slide 23 text

23 について

Slide 24

Slide 24 text

24 アーキテクチャー Servers ● K8sのマスターに相当 ● コーディネーション ● マルチリージョン対応 ● Consulを使用 ● K8s上で運用 (後述) Clients ● K8sのワーカーに相当 ● ジョブを実際に実行

Slide 25

Slide 25 text

25 の使い方 Nomad Client Build 1 Build 2 Build 3 ● Dockerドライバー ● 各クライアントでビルドが実行される ● バッチジョブを使用

Slide 26

Slide 26 text

26 ビルドジョブ Nomad Job1 Nomad Job2 Nomad Job3 CircleCIのビルドは最終的にNomadのジョブの単位で実行される * 実際はもう少し複雑

Slide 27

Slide 27 text

27 人間の手職人の感注：イメージです

Slide 28

Slide 28 text

28 ● Datadogモニタリング ● Autoscalerサービス ● AWS ASG スケーリング AutoScaler 1.0時代に比べてAWSコストの大幅な削減

Slide 29

Slide 29 text

29 なぜか？ ● Nomadはバッチ処理がk8sより得意だった (2016年の時点) ● 現時点ではk8sもよくなっている (らしい) ● シンプルなアーキテクチャー (単一Goバイナリ) ● Hashicorp Toolとの親和性 (ConsulやVaultなど) ● Mesosも検討したが複雑で断念詳しくは https://speakerdeck.com/kimh/cdpuratutohuomu

Slide 30

Slide 30 text

30 運用してわかったこと１シングルバイナリは正義！ ● 簡単に開発環境で使える ● スケールしやすい ● オンプレでも管理が簡単

Slide 31

Slide 31 text

31 運用してわかったこと効率のよいスケジューリング ● 1.0時代よりも少ないマシンでより多くのビルドをできる ● Resource ClassはNomad単体の機能で実装することができた

Slide 32

Slide 32 text

32 運用してわかったこととても安定している ● CircleCIでは0.6くらいから使用 ● Nomad自身のバグが少ない ● 安定版目の前? (現在0.9.3)

Slide 33

Slide 33 text

33 運用してわかったこと Nomad on k8s Works! ● NomadのServer NodeをK8sで運用 ● Nomadとk8sのいいとこどり ● Liveness Probes ● ローリングアップデート詳しくは https://circleci.com/blog/write-less-code-use-more-tools/

Slide 34

Slide 34 text

34 ビルドが実行されるまで GitHub $ Git Push

Slide 35

Slide 35 text

35 ビルドが実行されるまで k8s GitHub $ Git Push webhook Service Service Service Service Service

Slide 36

Slide 36 text

36 ビルドが実行されるまで k8s GitHub Service Service Service Service Service To Nomad $ Git Push webhook

Slide 37

Slide 37 text

37 ビルドが実行されるまで Nomad Server Nomad Server Nomad Server

Slide 38

Slide 38 text

38 ビルドが実行されるまで Nomad Server Nomad Server Nomad Server Nomad Client Nomad Client Nomad Client Nomad Client Nomad Client

Slide 39

Slide 39 text

39 ビルドが実行されるまで Docker Nomad Server Nomad Server Nomad Server Nomad Client Nomad Client Nomad Client Nomad Client Nomad Client

Slide 40

Slide 40 text

40 ビルドが実行されるまで Docker Nomad Server Nomad Server Nomad Server Nomad Client Nomad Client Nomad Client Nomad Client Nomad Client Output processor

Slide 41

Slide 41 text

41 ビルドが実行されるまで Docker Nomad Server Nomad Server Nomad Server Nomad Client Nomad Client Nomad Client Nomad Client Nomad Client Output processor

Slide 42

Slide 42 text

42 コンテナクラスター組織編まとめ ● K8sとnomadの二つを用途により使い分け ● K8sはサービス運用 ● Nomadはビルドインフラに ● もっとみんなNomad使ってくれ！！

Slide 43

Slide 43 text

43 技術編つのクラスター組織編チームの紹介

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

45 分散したエンジニアリングチーム

Slide 46

Slide 46 text

Slide 47

Slide 47 text

47 チーム構成 ● 現在10人弱のチーム ● ４カ国にまたがる

Slide 48

Slide 48 text

48 ボーイング方式 ● ワーキング・トュギャザー ● 時差の有効活用 ● 継続的なペアリング ● 無理のないアラート対応 ● 障害時対応

Slide 49

Slide 49 text

49 障害対応フロー #investigation 故障かな？と思ったら

Slide 50

Slide 50 text

50 障害対応フロー #investigation #incident 故障かな？と思ったら - ユーザー影響あり - 障害用のZoom開始 - @メンションされる

Slide 51

Slide 51 text

51 障害対応フロー #investigation #incident https://status.circleci.com 故障かな？と思ったら - ユーザー影響あり - 障害用のZoom開始 - @メンションされる

Slide 52

Slide 52 text

52 障害対応フロー #investigation #incident https://status.circleci.com Incident Commander Communication Commander Note Taker 故障かな？と思ったら - ユーザー影響あり - 障害用のZoom開始 - @メンションされる役割分担 (後述)

Slide 53

Slide 53 text

53 障害対応フロー #investigation #incident https://status.circleci.com Incident Commander Communication Commander Note Taker 20分ごとにアップデート故障かな？と思ったら - ユーザー影響あり - 障害用のZoom開始 - @メンションされる役割分担 (後述) - できるだけリアルタイム情報 - バナーに表示される

Slide 54

Slide 54 text

54 障害対応フロー #investigation #incident https://status.circleci.com Incident Commander Communication Commander Note Taker 20分ごとにアップデート故障かな？と思ったら - ユーザー影響あり - 障害用のZoom開始 - @メンションされる役割分担 (後述) - できるだけリアルタイム情報 - バナーに表示される - 30分様子見 - 問題なければクローズ

Slide 55

Slide 55 text

55 障害対応チーム構成 Incident Commander Communication Commander Note Taker Incident Response Team 障害復旧の責任者広報係障害復旧チーム書記係

Slide 56

Slide 56 text

56 役割分担 ● 障害復旧の責任者 ● 問題解決に必要なリソースを確保 ● SREである必要はない

Slide 57

Slide 57 text

57 役割分担 ● ユーザーへ現状を伝える ● ユーザーから障害範囲を聞く ● Status Pageをアップデートする ● Customer Success Engineersが担当

Slide 58

Slide 58 text

58 役割分担 ● 時系列をまとめる ● What/Who/When/How を記録する

Slide 59

Slide 59 text

59 役割分担 ● 問題に詳しいエンジニアで構成 ● IC, CCと連携して最善の解決策を探す

Slide 60

Slide 60 text

60 はじめました ● 週ごとのローテーションでToilを集中して潰す ● Toil以外の仕事に集中できるようにする ● Clinic -> 病院や駆け込み寺のイメージ ● 例: アカウントの削除、DNSレコードの追加, etc

Slide 61

Slide 61 text

61 のイメージどうしても今日中に DNSのTXTレコード追加したいんだよ〜 SRE Clinicで対応しますよこれでSEOの設定できる! マーケティング担当A Clinic当番のSRE

Slide 62

Slide 62 text

62 やってどうだったか？ Good: ● 他のエンジニアがタスクに集中できるようになった ● 何がToilかの分類ができるようになった Bad: ● 何がClinicの仕事かの分類があいまい ● タスクからClinicへ移る時のタイミングが難しい ● Toil自体が減るわけではない

Slide 63

Slide 63 text

63 組織編まとめ ● フルリモート ● ボーイング方式で24時間体制 ● SRE Clinicという新しい試み

Slide 64

Slide 64 text

64 ワーキングトュギャザー

Slide 65

Slide 65 text

65 こんな人募集 ● CircleCIに興味がある ● 大規模インフラを面倒みたい ● コンテナをガチでやりたい ● 海外のチームと働きたい

Slide 66

Slide 66 text

66 こんな人募集 ● CircleCIに興味がある ● Clojureを書きたい ● 海外のチームと働きたい