NoOps を目指して Kubernetes ネイティブな物理データセンターを作る

by ymmt2005

Slide 1

Slide 1 text

NoOps を目指して Kubernetes ネイティブな物理データセンターを作るサイボウズ株式会社山本泰宇 @ymmt2005 CloudNative Days Fukuoka 2019

Slide 2

Slide 2 text

自己紹介 ▌サイボウズ株式会社で20年ほど ⚫ CTO, 開発本部長, 運用本部長など歴任 ⚫ cybozu.com 開発プロジェクトの責任者 ⚫ 現在は Neco というプロジェクトの責任者 ▌きれいなコード、リファクタ、ドキュメントが好き ⚫ Software Entropy Reducer を名乗ってます

Slide 3

Slide 3 text

今日の内容 ▌cybozu.com が抱える課題 ▌インフラ刷新プロジェクト Neco の紹介 ▌方法論とここまでの成果 ▌これからの話

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

パッケージパッケージパッケージ

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

cybozu.com の中身 ▌レガシーなアプリ（Office, メールワイズ） ⚫ C++ の CGI, 組み込みのデータベース(sqlite) ▌独自開発の自社インフラ ⚫ VM, ストレージ, ロードバランサ等 ▌巨大なモノリス ⚫ インフラ＋デプロイ＋モニタリング＋ログ基盤

Slide 9

Slide 9 text

抱えている課題開発体制がクラウドに最適化できてない低いスケーラビリティ手作業・Toil が多い

Slide 10

Slide 10 text

開発体制がクラウドに最適化できてない ▌パッケージ製品開発時代を引きずっている ⚫ 製品開発とサービス運用が別部署 ⚫ 品質保証体制が出荷前試験に偏り ▌問題 ⚫ 自分が作った製品の運用に疎い開発者 ⚫ 中身がわからない製品を運用する SRE ⚫ 簡単な不具合がすぐに修正できないリリース管理

Slide 11

Slide 11 text

低いスケーラビリティ ▌HDD ベースのネットワークストレージのみ ⚫ ミドルウェア・製品単位に最適化できてない ▌少数台のサーバーで顧客をグルーピング ⚫ アプリケーションのスケールアウトが非常に困難 ▌台数に比例するオペレーションが存在 ⚫ OS のインストールやサーバー入れ替え作業

Slide 12

Slide 12 text

手作業・Toil が多い ▌逐次的なオペレーション ⚫ コマンド打って、確認して、次のコマンド打って… ⚫ ときには何時間も端末に張り付いて作業 ▌非継続的なデリバリ ⚫ 典型的なデリバリ作業も毎回手作業 ⚫ 作業時は SRE ２名でペア作業 ⚫ 作業時にエラーが出ることもしばしば

Slide 13

Slide 13 text

こうありたい ▌高速な開発・運用のワークフロー（DevOps） ▌ミドルウェアごとに最適化された構成 ▌数千台の規模を活かせるスケーラブルなシステム ▌撃ちっぱなし可能な宣言的オペレーション ▌継続的なデリバリ

Slide 14

Slide 14 text

NoOps (No “Uncomfortable” Ops)

Slide 15

Slide 15 text

NoOps とは NoOps Definition v1.0 より https://github.com/noopsjapan/community/blob/master/DEFINITION.md NoOpsはNo Uncomfortable Ops（システム運用の嬉しくないことをなくす）を目指すための技術、アーキテクチャ、それを実現するための活動を指します。このアプローチの代表例に、コンテナを活用した高回復性設計、DevOpsの活用、モニタリングと構成設定の自動化、SRE によるToil削減活動、などがあります。 NoOpsを実現するためのシステムが備えるべき代表的な能力には、高い回復性、可観測性、構成可能性、安全性の担保があります。これら NoOpsの能力を活用することで、例えば、Self-Healing、In-flight renewing, Adaptive Scale, Safety Everywhereなどのエクスペリエンスを実現することが可能になります。

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

Neco プロジェクト概要 ▌2018年１月から始動 ▌ゴールとスコープ ⚫ 前述の課題を解消 ⚫ データセンターの刷新まで（現システムからの移行は別プロジェクト） ⚫ 完全 IaaS 化はしない ▌体制 ⚫ 私含め、当初 6 名現在 9 名

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

なぜ物理データセンター？ ▌合理性と、気持ちの両面があります ▌合理性 ⚫ IaaS との比較で億円単位で節約可能と試算 ⚫ 購入機材は使い放題でレガシーアプリに優しい ⚫ 国内でDC運用する十分な人員と経験がある ⚫ cybozu.com の需要は単調増加 ▌気持ちは後で！

Slide 20

Slide 20 text

なぜ Kubernetes? ▌物理サーバーに直接依存させたくない ⚫ 毎年数百台を増強・入れ替えするため → コンテナ or VM でアプリは動作 ▌コンテナ・マイクロサービス時代の「勝ち馬」 ⚫ エコシステムが拡大を続けている ▌優れた設計 ⚫ 宣言的 API で大規模分散システムの運用を容易に ⚫ 拡張性が高く、様々な機能をアドオンできる

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

Neco 流データセンターの作り方

Slide 23

Slide 23 text

こんな順番で作ってきました 1. 仮想データセンターの構築ツールを準備 2. 標準化されたラックを単純増設可能にする 3. BGP で OS から経路制御可能にする 4. 大量のサーバーをネットブートで管理する 5. 機能試験をアップグレードも含め自動化する 6. デリバリ作業を宣言的（GitOps）にする

Slide 24

Slide 24 text

分散システムだって自動試験したい ▌分散システムのテストは一般的に困難 ⚫ 例：複数台の Linux サーバーのユーザーを自動同期するツールの動作確認 ⚫ 従来は全開発者が共有する試験用データセンターで動作確認していた ▌分散動作も事前に（自動）試験したい！ ⚫ github.com/cybozu-go/placemat

Slide 25

Slide 25 text

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 --- …

Slide 26

Slide 26 text

物理ラックの構成設計 ▌毎年数百台を増設・入れ替え ⚫ ラック単位で管理したい ⚫ ToR スイッチ２台で冗長化 ▌構成は標準化 ⚫ Software-defined なので特殊な物理構成が不要にもっとも標準的なラック構成

Slide 27

Slide 27 text

ネットワークの設計と実装 ▌L2 拡張技術を排除してマルチベンダー化 ▌経路の管理と冗長化は BGP + BFD ⚫ Linux サーバーから自由に経路設定が可能 ▌専門的な話はブログをどうぞ

Slide 28

Slide 28 text

ネットワーク概略図これ全部 placemat で仮想化してます

Slide 29

Slide 29 text

サーバー管理＆ネットブート ▌Kubernetes Node には CoreOS を採用 ⚫ ネットワークブートに最適化 ⚫ コンテナを動かす機能しかない → サーバー再起動で OS がバージョンアップ！ ▌サーバーの IP アドレスや状態管理、ネットワークブートのためのソフトウェアを開発 ⚫ github.com/cybozu-go/sabakan

Slide 30

Slide 30 text

Sabakan ▌管理サーバー上で動作 ▌データは etcd に保存 ▌複数台動作させるだけで簡単に冗長化

Slide 31

Slide 31 text

ここまで作るので半年

Slide 32

Slide 32 text

Kubernetes の自動運用 ▌Kubernetes を動かすには以下が必要 ⚫ etcd, 認証局, kubelet など管理プログラム ⚫ Kubernetes 自体の運用はなかなかの手間 ▌自動運用ツールを開発 ⚫ sabakan と同じく、管理サーバー上で動作 ⚫ github.com/cybozu-go/cke

Slide 33

Slide 33 text

CKE ▌Kubernetes クラスタを自動構築 ⚫ sabakan と連携してノードを自動で追加・削除 ⚫ 故障したコントロールプレーンの冗長化回復も ⚫ Kubernetes の自動バージョンアップも ▌Vault で秘密管理 ⚫ 証明書発行 ⚫ Secret 暗号化

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

自動デリバリツール neco ▌管理サーバーの構築・運用を自動化 ⚫ etcd, Vault クラスタのブートストラップ ⚫ 管理サーバーの追加・削除 ⚫ 管理サーバー上のアプリの自動更新（GitOps） ▌プロジェクトと同名のレポジトリで管理 ⚫ github.com/cybozu-go/neco ⚫ placemat の仮想 DC 上で push 毎に CI

Slide 36

Slide 36 text

neco Build Test Neco の CI パイプライン CKE sabakan DC Test neco その他 CKE sabakan その他 push push pull push tag push/ daily placemat すべてを結合して仮想データセンター上でテスト仮想DC上のテスト • ブートストラップ • アップグレード • クラスタ機能テスト • 停電復旧テスト • …

Slide 37

Slide 37 text

GitOps で pull 型デリバリー Boot Server Boot Server neco-updater etcd etcd CKE sabakan CKE sabakan neco-worker neco-worker 最新リリースのチェック neco CKE sabakan その他 push tag deb パッケージをビルド＆リリース download

Slide 38

Slide 38 text

物理サーバーの自動管理 ▌BIOS や BMC をネットブート後に自動設定 ⚫ github.com/cybozu-go/setup-hw ⚫ BMC 経由で故障パーツの監視機能もあり ▌Hashicorp serf で障害検知 ⚫ ネットワーク応答不能ノードを検知 ⚫ sabakan で状態を変えて、CKE が自動で Kubernetes クラスタをメンテナンス

Slide 39

Slide 39 text

ここまで作るので一年

Slide 40

Slide 40 text

仮想データセンターで開発してきましたが

Slide 41

Slide 41 text

物理データセンターでもあっさり動きました＼(^o^)／ placemat の再現度を徹底的に高めるのが肝

Slide 42

Slide 42 text

今年に入ってからの成果 ▌Argo CD で k8s アプリを継続デリバリ ⚫ これも GitOps で pull 型 ▌MetalLB で LoadBalancer を実装 ▌Prometheus でモニタリング ▌PodSecurityPolicy で危険な Pod を防止 ▌Calico で NetworkPolicy を実装 (Coming soon)

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

NoOps？

Slide 45

Slide 45 text

Neco でもできるぜ！

Slide 46

Slide 46 text

気持ちの話

Slide 47

Slide 47 text

なぜ、今あえて物理データセンターか ▌全面 IaaS という選択肢も合理的でありえる ⚫ 実際、U.S. 向けは AWS に移行予定 ▌合理性だけじゃない、気持ち ⚫ 海外企業がデータセンターを総取りでいいのか ⚫ ハードウェアを含めたコンピューターが好きだ ⚫ 俺たちならやれる、自信がある

Slide 48

Slide 48 text

やる以上は、最高の結果を ▌いいデータセンターを作る ⚫ 一年ちょっとでここまで作れた ▌いいデータセンターの作り方を広める ⚫ Neco の成果物は 99.9% OSS で公開 ▌あわよくば、仲間を増やす！ ⚫ いいデータセンターを作るノウハウ、共有しましょう

Slide 49

Slide 49 text

まとめと今後

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Neco 流データセンターの作り方 1. 仮想データセンターの構築ツールを準備する 2. 標準化されたラックを単純増設可能にする 3. BGP で OS から経路制御可能にする 4. 大量のサーバーをネットブートで管理する 5. 機能試験を徹底的に自動化する 6. デリバリ作業を宣言的（GitOps）にする

Slide 53

Slide 53 text

今後の予定 ▌マルチテナント環境の整備 ⚫ 一般開発者の利用に向けて認証やセキュリティを充実 ▌ミドルウェア as a Service の開発 ⚫ YAML ひとつ書けば指定したサイズの Elasticsearch クラスタが準備される仕組み ⚫ MySQL も同様に ▌オブジェクトストレージ ⚫ Ceph 運用を自動化する Rook で実装予定