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

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

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

Kim, Hirokuni

April 16, 2019
Tweet

More Decks by Kim, Hirokuni

Other Decks in Technology

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について
    1日120万ビルドのCI/CDプラットフォーム

    View Slide

  11. 11
    CircleCI 2.0について

    5万ビルド / 1hr

    ~8000ビルド / 1min

    ~130ビルド / 1 sec
    1日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
    運用してわかったこと1
    シングルバイナリは正義!
    ● 簡単に開発環境で使える
    ● スケールしやすい
    ● オンプレでも管理が簡単

    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人弱のチーム
    ● 4カ国にまたがる

    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