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

Transcript

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

   View Slide

2. 2
   I love Fukuoka...
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

24. 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・ロードバランス
    

    View Slide

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

    View Slide

26. 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ラウンドロビン
    クライアント・ロードバランス
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

30. 30
    Nomad について
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

65. 65
    今後の課題
    

    View Slide

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

    View Slide

67. 67
    WE ARE HIRING!!
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

72. Thank you.
    72
    Optional Name
    

    View Slide

73. 73
    明後日開催: CircleCI コミュニティミートアップ in 福岡
    

    View Slide