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

by Kim, Hirokuni

Slide 1

Slide 1 text

1 CircleCI 2.0を支える2つのコンテナクラスター #CNDF2019 #circlecijp

Slide 2

Slide 2 text

2 I love Fukuoka...

Slide 3

Slide 3 text

3 I love Fukuoka because I can ride 電動キックボード！

Slide 4

Slide 4 text

4 キックボードが好きすぎて、、、電動キックボードを安全に体験できるサービス Hop-on! を運営 ● 日本で唯一のサービス(のはず) ● みなとみらいで体験できます ● 続きは https://hop-on.jp で！

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

モダンソフトウェアデリバリの3つの柱

Slide 7

Slide 7 text

モダンソフトウェアデリバリの3つの柱本番環境

Slide 8

Slide 8 text

モダンソフトウェアデリバリの3つの柱 Continuous Delivery 本番環境

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

13 自己紹介 Kim, Hirokuni (金洋国) ● CircleCI Japan Tech Lead ● 日本支社の立ち上げ ● カンファレンス登壇 ● 採用活動 ● 記事執筆 ● コミュニティー運営 ”この発言は個人の見解ではなく所属する組織を代表しています” Twitter: https://twitter.com/kimhirokuni

Slide 14

Slide 14 text

14 自己紹介 ”この発言は個人の見解ではなく所属する組織を代表しています” Kim, Hirokuni (金洋国) ● CircleCI Japan Tech Lead ● 日本支社の立ち上げ ● カンファレンス登壇 ● 採用活動 ● 記事執筆 ● コミュニティー運営 ● 元プロダクトチーム ● 現SREチーム Twitter: https://twitter.com/kimhirokuni

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

19 Kubernetes CircleCI 2.0のマイクロサービスを支えるクラスター

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

23 問題: k8sでのgRPCロードバランス ● HTTP2を使うgrpc-javaはコネクションを使い回す ● K8s Serviceは複数PODをまとめるVIPを提供 ● 同じPODにつながる ● 結果、サービスをスケールしてもアクセスされない

Slide 24

Slide 24 text

24 K8s Serviceの場合 gRPC Client Service Pod1 10.0.0.1 K8s service foo.svc.cluster.local 10.0.0.100 Service Pod2 10.0.0.2 Cluster IP (VIP) こっちにはいかない L4・ロードバランス

Slide 25

Slide 25 text

25 解決: k8sでのgRPCロードバランス ● K8s Headless Serviceを使う ● HeadlessはPODのIPをDNSラウンドロビンで返す ● 結果、grpc-clientは異なるPODにつながる

Slide 26

Slide 26 text

26 K8s Headless Service の場合 gRPC Client Service Pod1 10.0.0.1 headless service foo.svc.cluster.loc al 10.0.0.1 10.0.0.2 Service Pod2 10.0.0.2 DNSラウンドロビンクライアント・ロードバランス

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

29 Nomad CircleCI 2.0のExecutionを支えるクラスター

Slide 30

Slide 30 text

30 Nomad について

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

32 CircleCIの使い方 Nomad Client Build 1 Build 2 Build 3 ● Dockerドライバー ● 各クライアントでビルドが実行される

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

35 職人の感 + 人の手注：イメージです

Slide 36

Slide 36 text

36 人間の手 + 職人の感 @ CircleCI 1.0 注：イメージです

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

41 運用してわかったこと 3 とても安定している ● CircleCIでは0.6くらいから使用 ● Nomad自身のバグが少ない

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

62 役割分担: Communication Commander ● ユーザーへ現状を伝える ● ユーザーから障害範囲を聞く ● Status Pageをアップデートする

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

65 今後の課題

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

67 WE ARE HIRING!!

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

70 CircleCI Culture ● Remote By Default ● All Hands、Small Hands ● 多様性 ● 柔軟な働き方

Slide 71

Slide 71 text

71 CircleCIでワーキング・トュギャザーしませんか？ ”こうした部品メーカーと航空会社を巻き込んだワーキング・トュギャザーの取り組みは、技術者たちの率直なコミュニケーションを生み出すことに成功しました。利害の壁が取り払われ、情報や喜び、世界観や理解を分かち合いながら238 のチームで最前の飛行機作りが進められていきました。” 出典: 航空機を作る - 世界の知恵が集まったB777のテクノロジー山中俊治著