物理データセンターでも NoOps

NoOps Meetup Tokyo #6 登壇資料
https://noops.connpass.com/event/131553/

Transcript

1. NoOps Meetup Tokyo #6
   物理データセンターでも NoOps
   サイボウズ株式会社
   @ymmt2005
   

   View Slide

2. 自己紹介
   ▌サイボウズ株式会社で20年弱
   ◼ cybozu.com 開発責任者とか
   ◼ メモリ 32 GB おじさんなど
   ◼現在は Neco というプロジェクトの責任者
   

   View Slide

3. 今日の内容
   ▌cybozu.com が抱える課題
   ▌インフラ刷新プロジェクト Neco の紹介
   ◼ アーキテクチャ
   ◼ 方法論
   ▌今後の予定
   

   View Slide

4. サイボウズ & cybozu.com
   ▌グループウェアの開発・販売
   ◼ 「サイボウズ Office」は 20 年以上ベストセラー
   ◼ もともとはパッケージソフトウェア販売
   ▌cybozu.com
   ◼ 自社グループウェアを SaaS で提供
   ◼ 2011年11月からサービス開始
   

   View Slide

5. cybozu.com の規模
   ▌契約社数
   28,000社
   ▌契約ユーザー数
   100万人以上
   ▌リクエスト数
   ２.6億/日
   ▌サーバー台数
   2,000台弱
   

   View Slide

6. 単調に規模が拡大
   -5000
   0
   5000
   10000
   15000
   20000
   25000
   30000
   35000
   40000
   45000
   2011 2012 2013 2014 2015 2016 2017 2018
   契約社数
   契約社数 二次回帰 線形回帰
   需要予測が容易
   強気の投資が可能
   

   View Slide

7. 現在のインフラについて
   

   View Slide

8. 現在のインフラ概要
   国内数か所のデータセンターで稼働
   • いわゆるオンプレミス
   サーバー数十台の頃からアーキテクチャ変わらず
   • 数千台を扱うのに無理を重ねている
   分散システムの基盤は独自開発
   • OpenStack や Kubernetes を使っていない
   • ssh で何とかするアレ
   

   View Slide

9. 抱えている課題
   手作業・Toil が多い
   低いスケーラビリティ
   自作に偏りすぎ
   

   View Slide

10. 辛い例：プログラムの更新作業
    ▌更新手順書を書き起こす
    ▌手順書をレビュー
    ▌複雑な手順はアドホックに自動化
    ▌開発環境でリハーサル
    ▌本番環境でペアで手動適用
    ▌完了まで何時間も端末前で待機することも
    数え役満！
    

    View Slide

11. こうありたい
    ▌撃ちっぱなし可能な宣言的オペレーション
    ▌継続的なデリバリ
    ▌高速な開発・運用のワークフロー（DevOps）
    ▌数千台の規模を活かせるスケーラブルなシステム
    ▌自作からの脱却
    

    View Slide

12. インフラ刷新プロジェクト
    

    View Slide

13. Neco プロジェクト概要
    ▌2018年１月から始動, 3ヶ年計画
    ▌内容
    ◼ Kubernetes 中心のアーキテクチャ
    ◼ オンプレミスデータセンター
    ◼ 成果物はほぼすべて OSS 公開
    ▌体制
    ◼ 私含め、現在 10 名
    

    View Slide

14. なぜ Kubernetes?
    ▌物理サーバーに直接依存させたくない
    ▌コンテナ・マイクロサービス時代の「勝ち馬」
    ◼ 拡大を続けるエコシステム
    ◼ 自作から脱却するのに好都合
    ▌優れた設計
    ◼ 宣言的 API で大規模分散システムの運用を容易に
    ◼ 拡張性が高く、様々な機能をアドオンできる
    

    View Slide

15. データセンター内のシステム論理構成
    ３～５台の管理サーバー群
    数千台のノードで構成される Kubernetes クラスタ
    Elasticsearch や MySQL のマネージドサービス
    テナント テナント テナント …
    Neco
    

    View Slide

16. Neco の設計原則
    １．Be Declarative
    • Kubernetes 以外もすべて、宣言的に操作可能にする
    ２．Define by Software
    • 特定の目的に縛られたサーバー・ネットワークを作らない
    • サーバー・ネットワークの役割をソフトウェアで変更する
    ３．Test Everything
    • 継続的なデリバリーには試験は自動化しないといけない
    • データセンターで動作するすべての機能を自動試験する
    

    View Slide

17. ここまでの成果
    ▌宣言的 Kubernetes 管理ツール「CKE」
    ▌BGP 中心で設計されたネットワーク
    ▌仮想データセンターを活用した CI / CD
    ▌ステージング用物理データセンター
    ▌その他いろいろ
    

    View Slide

18. CKE
    

    View Slide

19. CKE
    ▌Kubernetes クラスタの運用を自動化
    ◼ 望みのクラスタ構成を宣言するだけ
    ◼ CKE が適当な物理サーバーを選んで構築・入れ替え
    ◼ Kubernetes の自動バージョンアップも
    ▌HashiCorp Vault で秘密管理
    ◼ 証明書発行
    ◼ Secret 暗号化
    

    View Slide

20. CKE の詳しい話は #CNDT2019 で！
    

    View Slide

21. BGP 中心のネットワーク
    

    View Slide

22. BGP + BFD + ECMP で経路管理＆冗長化
    ▌Linux / Kubernetes から経路を自在に制御可能
    ◼ BIRD と組み合わせ可能な CNI プラグイン「Coil」を開発
    ◼ MetalLB で LoadBalancer を実装
    ▌ルータもソフトウェアで実装可能
    ▌専門的な話はブログをどうぞ
    

    View Slide

23. ネットワーク概略図
    Spine-Leaf アーキテクチャ
    コンテナ間の East-West 通信に最適
    

    View Slide

24. 仮想データセンター
    

    View Slide

25. なぜ仮想データセンター？
    ▌Neco はデータセンターを管理するソフトウェア群
    ▌Neco の開発・試験にはデータセンターが必要
    ◼ 開発者に自分専用データセンターが欲しい
    ◼ データセンターでの動作も自動試験したい
    ▌そこで placemat というツールを開発
    

    View Slide

26. placemat
    ▌仮想データセンター構築ツール
    ◼ L2 ネットワーク＝Linux ブリッジ
    ◼ ルーター＝BIRDコンテナ
    ◼ サーバー＝QEMU/KVM
    ▌機能
    ◼ YAML で宣言的に環境構築
    ◼ Virtual BMC (IPMI)
    ◼ UEFI HTTP Boot
    kind: Network
    name: ext-net
    type: external
    use-nat: true
    address: 192.168.1.0/24
    ---
    kind: DataFolder
    name: data
    files:
    - name: sabakan
    file: sabakan
    - name: sabactl
    file: sabactl
    ---
    kind: Image
    name: ubuntu
    file: ubuntu-18.04-server-cloudimg-amd64.img
    ---
    kind: Node
    name: host1
    interfaces:
    - ext-net
    cpu: 1
    memory: 1G
    volumes:
    - kind: image
    name: root
    image: ubuntu
    copy-on-write: true
    - kind: vvfat
    name: data
    folder: data
    ---
    …
    

    View Slide

27. データセンターネットワークまるごと仮想化
    

    View Slide

28. 宣言的デリバリ
    

    View Slide

29. 再掲： Neco のシステム論理構成
    ３～５台の管理サーバー群
    数千台のノードで構成される Kubernetes クラスタ
    Elasticsearch や MySQL のマネージドサービス
    テナント テナント テナント …
    Neco
    

    View Slide

30. 管理サーバーの構成
    Ubuntu Ubuntu Ubuntu ………
    手作業管理はしんどい！
    etcd etcd etcd
    Vault
    Serf
    etcdpasswd
    Sabakan
    CKE
    Vault
    Serf
    etcdpasswd
    Sabakan
    CKE
    Vault
    Serf
    etcdpasswd
    Sabakan
    CKE
    データは etcd
    クラスタに保存
    Made by
    

    View Slide

31. Neco のデリバリー戦略
    ▌システムを Kubernetes の上と下で分割する
    ◼ Kubernetes 上のアプリは Argo CD で宣言的にデリバリー
    ◼ Kubernetes の下は自作ツールで宣言的にデリバリー
    ▌システム全体をデリバリー前に試験する
    ◼ デリバリー前の状態を仮想データセンターで構築、
    デリバリー後に壊れないことも試験
    ◼ 全電源停止後の動作回復も試験
    

    View Slide

32. Neco as of June 2019
    GitHub
    Argo CD
    Neco CD
    Ubuntu
    管理サーバー
    Sabakan
    CKE
    3~5台
    管理サーバーを自動更新
    CoreOS
    Coil
    CoreOS
    Coil
    CoreOS
    Coil
    CoreOS
    Coil
    ネット
    ブート
    Kubernetes
    自動管理
    Argo CD Prometheus
    MetalLB Calico
    Contour
    アプリを
    自動管理
    Made by
    push
    …
    

    View Slide

33. 今後の予定
    

    View Slide

34. ストレージ管理
    ▌自社製 CSI プラグイン TopoLVM を開発中
    ◼ LVM でローカルストレージを PVC で利用可能
    ◼ VG 空き容量などを考慮する拡張スケジューラー付き
    ▌Elasticsearch & MySQL オペレーター
    ◼ TopoLVM を活用して自動運用する予定
    ▌Ceph / Rook
    ◼ オブジェクトストレージ用に
    

    View Slide

35. テナント管理
    ▌2019年7月に本番データセンター構築予定
    ▌テナント利用者向けの様々な環境整備
    ◼ 各種ポリシー
    ◼ 利用者向けドキュメント
    ◼ 利用者向け開発環境
    ◼ …
    

    View Slide

36. 以上
    ご清聴ありがとうございました
    

    View Slide

37. Appendix
    

    View Slide

38. Neco OSS レポジトリ
    ▌全て github.com 上
    ▌cybozu-go/neco 継続的デリバリーツール
    ▌cybozu-go/neco-ops Argo CD 用
    ▌cybozu-go/cke Kubernetes 自動運用ツール
    ▌cybozu-go/sabakan ネットワークブートサーバー
    ▌cybozu-go/coil BIRD と組み合わせ可能な CNI プラグイン
    ▌cybozu-go/topolvm LVM を使う CSI プラグイン
    ▌cybozu-go/placemat 仮想データセンター構築ツール
    ▌ cybozu/neco-containers 各種コンテナイメージのビルド
    

    View Slide