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

CloudNative Days Fukuoka 2019 講演資料

Transcript

1. NoOps を目指して Kubernetes ネイティブな物理データセンターを作る サイボウズ株式会社 山本泰宇 @ymmt2005 CloudNative Days Fukuoka 2019
2. 自己紹介 ▌サイボウズ株式会社で20年ほど ⚫ CTO, 開発本部長, 運用本部長など歴任 ⚫ cybozu.com 開発プロジェクトの責任者 ⚫ 現在は Neco というプロジェクトの責任者 ▌きれいなコード、リファクタ、ドキュメントが好き ⚫ Software Entropy Reducer を名乗ってます
3. 今日の内容 ▌cybozu.com が抱える課題 ▌インフラ刷新プロジェクト Neco の紹介 ▌方法論とここまでの成果 ▌これからの話
4. サイボウズ & cybozu.com ▌グループウェアの開発・販売 ⚫ 「サイボウズ Office」は 20 年以上ベストセラー ⚫ もともとはパッケージソフトウェア販売 ▌cybozu.com ⚫ 自社グループウェアを SaaS で提供 ⚫ 2011年11月からサービス開始
5. パッケージ パッケージ パッケージ
6. cybozu.com の規模 ▌契約社数 28,000社 ▌契約ユーザー数 100万人以上 ▌リクエスト数 ２.6億/日 ▌サーバー台数 2,000台弱
7. 単調に規模が拡大してきた -5000 0 5000 10000 15000 20000 25000 30000 35000 40000 45000 2011 2012 2013 2014 2015 2016 2017 2018 契約社数 契約社数 二次回帰 線形回帰 需要予測が容易 強気の投資が可能
8. cybozu.com の中身 ▌レガシーなアプリ（Office, メールワイズ） ⚫ C++ の CGI, 組み込みのデータベース(sqlite) ▌独自開発の自社インフラ ⚫ VM, ストレージ, ロードバランサ等 ▌巨大なモノリス ⚫ インフラ＋デプロイ＋モニタリング＋ログ基盤
9. 抱えている課題 開発体制がクラウドに最適化できてない 低いスケーラビリティ 手作業・Toil が多い
10. 開発体制がクラウドに最適化できてない ▌パッケージ製品開発時代を引きずっている ⚫ 製品開発とサービス運用が別部署 ⚫ 品質保証体制が出荷前試験に偏り ▌問題 ⚫ 自分が作った製品の運用に疎い開発者 ⚫ 中身がわからない製品を運用する SRE ⚫ 簡単な不具合がすぐに修正できないリリース管理
11. 低いスケーラビリティ ▌HDD ベースのネットワークストレージのみ ⚫ ミドルウェア・製品単位に最適化できてない ▌少数台のサーバーで顧客をグルーピング ⚫ アプリケーションのスケールアウトが非常に困難 ▌台数に比例するオペレーションが存在 ⚫ OS のインストールやサーバー入れ替え作業
12. 手作業・Toil が多い ▌逐次的なオペレーション ⚫ コマンド打って、確認して、次のコマンド打って… ⚫ ときには何時間も端末に張り付いて作業 ▌非継続的なデリバリ ⚫ 典型的なデリバリ作業も毎回手作業 ⚫ 作業時は SRE ２名でペア作業 ⚫ 作業時にエラーが出ることもしばしば
13. こうありたい ▌高速な開発・運用のワークフロー（DevOps） ▌ミドルウェアごとに最適化された構成 ▌数千台の規模を活かせるスケーラブルなシステム ▌撃ちっぱなし可能な宣言的オペレーション ▌継続的なデリバリ
14. NoOps (No “Uncomfortable” Ops)
15. 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などのエクス ペリエンスを実現することが可能になります。
16. インフラ刷新プロジェクト Neco
17. Neco プロジェクト概要 ▌2018年１月から始動 ▌ゴールとスコープ ⚫ 前述の課題を解消 ⚫ データセンターの刷新まで（現システムからの移行は別プロジェクト） ⚫ 完全 IaaS 化はしない ▌体制 ⚫ 私含め、当初 6 名現在 9 名
18. データセンター内のシステム論理構成 ３～５台の管理サーバー群 数千台のノードで構成される Kubernetes クラスタ Elasticsearch や MySQL のマネージドサービス テナント テナント テナント … Neco
19. なぜ物理データセンター？ ▌合理性と、気持ちの両面があります ▌合理性 ⚫ IaaS との比較で億円単位で節約可能と試算 ⚫ 購入機材は使い放題でレガシーアプリに優しい ⚫ 国内でDC運用する十分な人員と経験がある ⚫ cybozu.com の需要は単調増加 ▌気持ちは後で！
20. なぜ Kubernetes? ▌物理サーバーに直接依存させたくない ⚫ 毎年数百台を増強・入れ替えするため → コンテナ or VM でアプリは動作 ▌コンテナ・マイクロサービス時代の「勝ち馬」 ⚫ エコシステムが拡大を続けている ▌優れた設計 ⚫ 宣言的 API で大規模分散システムの運用を容易に ⚫ 拡張性が高く、様々な機能をアドオンできる
21. Neco の設計原則 ▌Be Declarative ⚫ Kubernetes 以外もすべて、宣言的に操作可能にする ▌Define by Software ⚫ 特定の目的に縛られたサーバー・ネットワークを作らない ⚫ サーバー・ネットワークの役割をソフトウェアで変更する ▌Test Everything ⚫ 継続的なデリバリーには試験は自動化しないといけない ⚫ データセンターで動作するすべての機能を自動試験する
22. Neco 流データセンターの作り方
23. こんな順番で作ってきました 1. 仮想データセンターの構築ツールを準備 2. 標準化されたラックを単純増設可能にする 3. BGP で OS から経路制御可能にする 4. 大量のサーバーをネットブートで管理する 5. 機能試験をアップグレードも含め自動化する 6. デリバリ作業を宣言的（GitOps）にする
24. 分散システムだって自動試験したい ▌分散システムのテストは一般的に困難 ⚫ 例：複数台の Linux サーバーのユーザーを自動 同期するツールの動作確認 ⚫ 従来は全開発者が共有する試験用データセン ターで動作確認していた ▌分散動作も事前に（自動）試験したい！ ⚫ github.com/cybozu-go/placemat
25. 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 --- …
26. 物理ラックの構成設計 ▌毎年数百台を増設・入れ替え ⚫ ラック単位で管理したい ⚫ ToR スイッチ２台で冗長化 ▌構成は標準化 ⚫ Software-defined なので 特殊な物理構成が不要に もっとも標準的な ラック構成
27. ネットワークの設計と実装 ▌L2 拡張技術を排除してマルチベンダー化 ▌経路の管理と冗長化は BGP + BFD ⚫ Linux サーバーから自由に経路設定が可能 ▌専門的な話は ブログをどうぞ
28. ネットワーク概略図 これ全部 placemat で仮想化してます
29. サーバー管理＆ネットブート ▌Kubernetes Node には CoreOS を採用 ⚫ ネットワークブートに最適化 ⚫ コンテナを動かす機能しかない → サーバー再起動で OS がバージョンアップ！ ▌サーバーの IP アドレスや状態管理、ネット ワークブートのためのソフトウェアを開発 ⚫ github.com/cybozu-go/sabakan
30. Sabakan ▌管理サーバー上で動作 ▌データは etcd に保存 ▌複数台動作させるだけで簡単に冗長化
31. ここまで作るので半年
32. Kubernetes の自動運用 ▌Kubernetes を動かすには以下が必要 ⚫ etcd, 認証局, kubelet など管理プログラム ⚫ Kubernetes 自体の運用はなかなかの手間 ▌自動運用ツールを開発 ⚫ sabakan と同じく、管理サーバー上で動作 ⚫ github.com/cybozu-go/cke
33. CKE ▌Kubernetes クラスタを自動構築 ⚫ sabakan と連携してノードを自動で追加・削除 ⚫ 故障したコントロールプレーンの冗長化回復も ⚫ Kubernetes の自動バージョンアップも ▌Vault で秘密管理 ⚫ 証明書発行 ⚫ Secret 暗号化
34. 管理サーバーの構成 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
35. 自動デリバリツール neco ▌管理サーバーの構築・運用を自動化 ⚫ etcd, Vault クラスタのブートストラップ ⚫ 管理サーバーの追加・削除 ⚫ 管理サーバー上のアプリの自動更新（GitOps） ▌プロジェクトと同名のレポジトリで管理 ⚫ github.com/cybozu-go/neco ⚫ placemat の仮想 DC 上で push 毎に CI
36. neco Build Test Neco の CI パイプライン CKE sabakan DC Test neco その他 CKE sabakan その他 push push pull push tag push/ daily placemat すべてを結合して 仮想データセンター 上でテスト 仮想DC上のテスト • ブートストラップ • アップグレード • クラスタ機能テスト • 停電復旧テスト • …
37. 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
38. 物理サーバーの自動管理 ▌BIOS や BMC をネットブート後に自動設定 ⚫ github.com/cybozu-go/setup-hw ⚫ BMC 経由で故障パーツの監視機能もあり ▌Hashicorp serf で障害検知 ⚫ ネットワーク応答不能ノードを検知 ⚫ sabakan で状態を変えて、CKE が自動で Kubernetes クラスタをメンテナンス
39. ここまで作るので一年
40. 仮想データセンターで 開発してきましたが
41. 物理データセンターでも あっさり動きました＼(^o^)／ placemat の再現度を 徹底的に高めるのが肝
42. 今年に入ってからの成果 ▌Argo CD で k8s アプリを継続デリバリ ⚫ これも GitOps で pull 型 ▌MetalLB で LoadBalancer を実装 ▌Prometheus でモニタリング ▌PodSecurityPolicy で危険な Pod を防止 ▌Calico で NetworkPolicy を実装 (Coming soon)
43. 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 … アプリを 自動管理
44. NoOps？
45. Neco でもできるぜ！
46. 気持ちの話
47. なぜ、今あえて物理データセンターか ▌全面 IaaS という選択肢も合理的でありえる ⚫ 実際、U.S. 向けは AWS に移行予定 ▌合理性だけじゃない、気持ち ⚫ 海外企業がデータセンターを総取りでいいのか ⚫ ハードウェアを含めたコンピューターが好きだ ⚫ 俺たちならやれる、自信がある
48. やる以上は、最高の結果を ▌いいデータセンターを作る ⚫ 一年ちょっとでここまで作れた ▌いいデータセンターの作り方を広める ⚫ Neco の成果物は 99.9% OSS で公開 ▌あわよくば、仲間を増やす！ ⚫ いいデータセンターを作るノウハウ、共有しましょう
49. まとめと今後
50. Neco プロジェクト概要 ▌2018年１月から始動 ▌ゴールとスコープ ⚫ 前述の課題を解消 ⚫ データセンターの刷新まで（現システムからの移行は別プロジェクト） ⚫ 完全 IaaS 化はしない ▌体制 ⚫ 私含め、当初 6 名現在 9 名
51. Neco の設計原則 ▌Be Declarative ⚫ Kubernetes 以外もすべて、宣言的に操作可能にする ▌Define by Software ⚫ 特定の目的に縛られたサーバー・ネットワークを作らない ⚫ サーバー・ネットワークの役割をソフトウェアで変更する ▌Test Everything ⚫ 継続的なデリバリーには試験は自動化しないといけない ⚫ データセンターで動作するすべての機能を自動試験する
52. Neco 流データセンターの作り方 1. 仮想データセンターの構築ツールを準備する 2. 標準化されたラックを単純増設可能にする 3. BGP で OS から経路制御可能にする 4. 大量のサーバーをネットブートで管理する 5. 機能試験を徹底的に自動化する 6. デリバリ作業を宣言的（GitOps）にする
53. 今後の予定 ▌マルチテナント環境の整備 ⚫ 一般開発者の利用に向けて認証やセキュリティを充実 ▌ミドルウェア as a Service の開発 ⚫ YAML ひとつ書けば指定したサイズの Elasticsearch クラスタが準備される仕組み ⚫ MySQL も同様に ▌オブジェクトストレージ ⚫ Ceph 運用を自動化する Rook で実装予定
54. 年内に本番環境稼働予定！
55. おしまい ご清聴ありがとうございました