ツラくないクラウド運用環境を作る

ツラくないクラウド運用環境を作る @オープンデベロッパーズカンファレンス2018
https://www.ospn.jp/odc2018/modules/eguide/event.php?eid=15

-----

関連リポジトリ

https://github.com/cybozu-go/sabakan
https://github.com/cybozu-go/cke
https://github.com/cybozu-go/placemat
https://github.com/cybozu-go/placemat-menu
https://github.com/cybozu-go/etcdpasswd

Transcript

1. ツラくないクラウド運用環境を作る cybozu.com の次世代アーキテクチャが目指すもの サイボウズ株式会社 鶴田 貴大
2. アジェンダ • 弊社サービスcybozu.comのインフラが抱える課題と、 それを解決するための刷新プロジェクトの解説をします • 刷新プロジェクトの成果物の解説をします いろいろあるのですが、 本発表に関連するのは主にこの辺り • https://github.com/cybozu-go/sabakan • https://github.com/cybozu-go/cke • https://github.com/cybozu-go/placemat
3. 目次 • cybozu.comのインフラ刷新プロジェクト概要 • どのように刷新するか • 実機構成 • 実機のライフサイクル管理 • サービス運用 • 開発体制 • OSSにしている成果物の紹介
4. 自己紹介 • 鶴田貴大 (Tsuruda Takahiro) • @dulltz • サイボウズのソフトウェアエンジニア • 新卒入社2年目
5. はじめに
6. cybozu.com とは
7. cybozu.com とは • サイボウズが運営するクラウド型のグループウェア • 2011年リリース • 2018年現在、クラウド契約2.5万社100万ユーザ超 • 国内SaaS上場企業の売上No1らしい • https://note.mu/naberun/n/n9026c6e9eec1
8. cybozu.com のインフラ
9. cybozu.com のインフラ • 実機の管理からサービス運用まで、自社の運用チームが行う • データセンターに1000台規模のサーバがある • dev, production などの環境がある
10. 7年間でユーザ数が増えた サーバ台数も増えた
11. するとインフラに いろいろな問題が 顕在化してきた
12. インフラの課題 • 機材管理コストが実機台数に比例する • 機材を修理に出す為に毎週1人日の工数がかかる • 空きサーバを探すのが人力 • オペレーションを回すだけで大変 • 改善タスクを行う工数が不足
13. インフラの課題 • スケーラビリティに欠ける • DB負荷が障害につながってしまうケースもある • アーキテクチャの設計的に、 サーバ台数を増やしても向上が見込めない
14. つらい
15. 解決するために インフラを刷新しよう
16. というわけで インフラ刷新プロジェクトが 立ち上がりました
17. Neco プロジェクトといいます
18. Neco プロジェクト 目標 • cybozu.com の運用コストの劇的な削減 • 製品のスケーラビリティの向上
19. Neco のアーキテクチャ志向 • Declarative architecture-style • 人は望みの状態を宣言するだけ • Software Defined • 汎用の物理機材をソフトウェアで制御 • Test Everything • データセンター丸ごと仮想化して開発・試験
20. Neco プロジェクト 2018 年 1 月に本格始動しました 3年で本番環境に載せる予定 現在、メンバーは8人 • エンジニア7人(うち1人はPMを兼務) • QA1人
21. 概要説明終わり
22. ここからは 何がつらいのか どう解決するのか 説明していきます
23. 機材構成
24. 現行の機材構成 • 用途に合わせて機材構成が異なる
25. 現行インフラのつらいポイント • セグメントごとに機材構成や導入手順が異なる • DMZ • L7LB, L4LB, DNSサーバ, プロキシサーバが別手順 • コンピュートサーバ • ストレージサーバ • 全体のマネージャ • ...
26. 現行インフラのつらいポイント • 増設・退役オペレーションが大変 • 毎週1~2人日の工数がかかっている
27. Neco ではもっと簡単にしたい
28. Neco の機材構成 • 汎用のネットワークとラック構成にする • 用途はソフトウェアで定義する
29. 図を使って説明します
30. ある機材の導入 • 人が機材情報を機材管理ツールに追加 JSON
31. ある機材の導入 • ラックにサーバを追加 • ToRにつなぐだけ(どの機材も同じ！)
32. ある機材の導入 • ネットブートする(UEFI HTTP Boot)
33. ある機材の導入 • ネットブートする(UEFI HTTP Boot) • アプリケーションデプロイ可能な状態まで初期化
34. ある機材の導入 Necoでは • 人は機材情報を機材管理ツールにセットして サーバをラックにつなぐだけ • あとは機材管理ツールがよしなにしてくれる、という仕組み • これは？
35. 自作しています • sabakan • https://github.com/cybozu-go/sabakan • 各ブートサーバ上に配置する • ネットブートと機材管理を行うツール • バックエンドがetcdで、これにより整合性を保ちながら動作
36. ネットブートのためにsabakanが持っている機能 • DHCPサーバ機能 • リース情報は etcd に保存
37. ネットブートのためにsabakanが持っている機能 Container Linux は Ignition というJSON形式のファイルから プロビジョニングできる sabakan は Ignitionファイルを作成・配信できる
38. 参考 Container Linux • CoreOSが開発する、 コンテナ動作環境として特化された軽量なLinuxディストロ • 無駄なものが入っていない • Dockerが最初から入っている一方で、 Pythonすら入っていない • IgnitionというJSON形式のプロビジョニングの仕組みがある
39. 参考 etcd • CoreOSがつくっているキーバリューストア • 分散環境での高い信頼性が特徴 • 分散ロックがとれる • 値の変更をウォッチできるAPIがある • 一つのアイテムについて複数バージョンを保持できる (Multi-version concurrency control)
40. ネットブートのためにsabakanが持っている機能 • OSイメージや各種アセットを配布するファイルサーバ機能 • インスタンス間で自動分散される
41. sabakanのファイル分散機能 • 人がファイルをsabakanのうちの一つにアップロード オペレータ アップロード
42. sabakanのファイル分散機能 • sabakanは自身のホストにファイルを保存 • etcdにファイルのメタ情報を保存 etcd を更新
43. sabakanのファイル分散機能 • 他のsabakanはetcdの変更を検知 (etcd の Watch API を活用) etcdの変更を検知
44. sabakanのファイル分散機能 • ファイルを持っているホストのsabakanからダウンロード ファイルをDL
45. sabakanのファイル分散機能 • ファイルメタ情報を更新 自身からもファイルをダウンロード可能であることを追記する etcdを更新
46. sabakanのファイル分散機能 • 一か所にファイルをアップロードするだけで全ブートサーバに ファイルが分散共有される
47. 機材のライフサイクル管理 *機材のライフサイクル: 導入から退役までの状態遷移
48. 現行のライフサイクル管理の つらいポイント1 機材の状態定義が 実際の状態を 十分に表現できていない
49. 現行インフラのつらいポイント 例： 機材状態が ”unavailable” であるときに • 修理待ち • 修理済み のどちらもありうる…
50. 現行インフラのつらいポイント 例： 故障からの復帰中(RAIDリビルド中など)を表す状態が無い。
51. では現状どうしているのか？
52. 現状どうしているのか • 人が確認している • “unavailable”な機材が 修理済みかどうかを管理するための台帳アプリが存在し、 そこで手動管理している • RAIDリビルド中かどうか人がチェックしている
53. 現行のライフサイクル管理の つらいポイント2 ユーザが機材管理DBに登録した 機材状態と実際の状態に 乖離が生まれる
54. 管理DBと実際の機材状態の乖離 1. 機材を本番投入する 2. 機材の状態(稼働状態、ストレージ構成など) を管理DBに保存 3. 機材の状態が何らかの理由で変わる(故障など) 4. 人が機材を調査する 5. 人が機材の状態を更新しなおす
55. 現行のライフサイクル管理の つらいポイント3: 安全に状態遷移できない
56. 安全に遷移できない • 状態変更するときは、DBのカラムへ直接書き込んでいる • 現在どういう状態であろうが、 任意の状態に書き換えることができてしまう • ありえない状態遷移を記述してしまっても気づけない • 人が気を遣って遷移を記述している
57. 機材ライフサイクル管理つらいポイントまとめ • 機材の状態を十分に定義できていない • DBに保存してある状態と実際の状態とで乖離が生じる • 安全に状態遷移を行えない
58. 機材ライフサイクル管理つらいポイントまとめ いけてない部分は人の力でなんとかしている 台数が増えた今では大変
59. Necoでは 運用する人が 頑張らなくてもいいようにしたい
60. まず、機材の状態を再定義
61. 安全な状態遷移を行うために 機材管理ツールが可能な遷移を定義 それ以外の遷移は許可しない
62. 実際の状態との乖離を生まないために • 機材管理ツールで保存した状態を プライマリデータとする • 残りのシステムはその状態に追従するように動作させる • あるいはモニタリングツールが故障などを検知し 自動でプライマリデータを更新する
63. 機材退役フローを 図を使って説明
64. 登場人物 • 人 • 機材管理ツール • 退避操作を行うアプリ • モニタリング • サーバ
65. アプリケーション稼働中のサーバがある
66. サーバが故障する
67. モニタリングツールが検知
68. 対象マシンのstatusをUnhealthyに変更
69. 状態変更を検知した退避アプリが動作開始
70. 退避操作が完了次第、機材の電源断
71. 故障機材がたまってきたら人間が最終チェック
72. いつでも業者に引き渡せる状態に
73. 大事なポイント • 人が出てくる機会を極力減らす • システムが自律管理する
74. 機材管理ツールが重要 役割 • 機材情報を管理する • ネットブートする
75. 機材管理ツールが重要 機能要件 • 分散システム上で整合性を担保しながら動作できる • 他のソフトウェアに状態変更を通知できる どちらもetcdで実現
76. サービス運用
77. 現行のソフトウェアアーキテクチャ • 内製のサービスマネジメントシステム • VMを構築し、その上にお客様の環境を用意
78. つらいポイント1 スケーラビリティに欠ける
79. スケーラビリティ不足 • スケールの上限=サーバ1台の性能 • 計算資源の割り当てが柔軟でない • 逆に定常的にリソースが余りすぎているケースも結構ある
80. 計算資源の割り当てが柔軟でない • 機材と動作するアプリケーションのインスタンスが密結合 • 故障機材で動作していたアプリケーションセットの 退避先を探すのが人手
81. つらいポイント2 デプロイツールが複雑
82. デプロイツールが複雑 • 規模の拡大や構成要素の増加に従って、秘伝のたれ化
83. デプロイツールが複雑 • 規模の拡大や構成要素の増加に従って、秘伝のたれ化 • 難しくて訓練された運用メンバーしか使えない • 社内ツールなので社内で訓練するしかない 慢性的な人手不足 • アプリのデプロイまわりをすべて運用チームが引き取ることに なっている原因 • アップデート頻度が増える→運用チームのタスクが増える
84. Necoではどうするか
85. Necoの理想とするサービス運用 • 計算資源割り当て • 実機とアプリケーションを疎結合にしたい • スケール可能にしたい • 故障機材の代替機を人が探し出すような 作業をしなくてすむようにする
86. Necoのサービス運用 • デプロイ • 望みの状態を宣言すれば、ソフトウェアがそうなるように動 作する仕組みを用意したい • 手続き的な記述のオペレーションを管理するのは難しい。
87. Kubernetesを導入します
88. メモ: Kubernetes • Googleが開発するコンテナオーケストレーションツール • 宣言的なリソースを書けばコンテナ群をクラスタ内に良い感じに デプロイしてくれる • ユーザの望む状態へシステムが自律的に移行する仕組み • クラスタは以下のノードから構成される • コントロールプレーン • ワーカーノード
89. Kubernetesを導入します • 計算資源割り当て • Kubernetesが良い感じに面倒を見てくれる • 実機とアプリケーションを疎結合にできる
90. Kubernetesを導入します • デプロイ • 宣言的なKubernetesリソースを定義することでデプロイ可能 • デプロイをアプリケーションチームに移譲することも視野
91. Kubernetesで解決しそうに見え る
92. しかしKubernetes自体の運用は 結構大変？
93. Kubernetes運用で苦しんだら 元の木阿弥
94. Kubernetes運用も楽にした い！！
95. 理想的なKubernetes運用 • 宣言的な操作でKubernetes クラスタを構築したい
96. 理想的なKubernetes運用 ノード1~3が コントロールプレーン、 残りのノードはワーカーで！
97. 理想的なKubernetes運用 Kubernetesクラスタ 構築！
98. 理想的なKubernetes運用 • 一部のノードのサービスが死んでしまったとき
99. 理想的なKubernetes運用 • 一部のノードのサービスが死んでしまったとき 理想状態との差分を 検出
100. 理想的なKubernetes運用 • 一部のノードのサービスが死んでしまったとき 再デプロイ
101. 理想的なKubernetes運用 クラスタ構成を変更したいとき ノード1~6が コントロールプレーン、 残りのノードはワーカーで！
102. 理想的なKubernetes運用 • クラスタ構成を変更したいとき 理想状態になるよう 再構築
103. 前述の機材導入フロー • プロビジョニングが終わったら自動的に Kubernetesクラスタのノードになっててほしい
104. 前述の機材退避フロー • 退避するとき、Podをリスケジュールしてほしい
105. sabakanと連携しながら Kubernetesをデプロイする ツールがほしい
106. Kubernetes デプロイツールを自作しています • https://github.com/cybozu-go/cke • 各ブートサーバにデーモンとして常駐 • 望ましい状態に段階的に近づけるようにクラスタを構築する • クラスタ状態をチェック→etcdクラスタデプロイ→kube- apiserverデプロイ→kube-controller-managerデプロイ→...
107. Kubernetes デプロイツールを自作しています • HAなコントロールプレーンをデプロイしてくれる • 各ノードのリバースプロキシが 各コントロールプレーンのAPIサーバを指している • 残りのコントロールプレーンのコンポーネントも 複数インスタンス立てて待機させておく
108. Kubernetes デプロイツールを自作しています このデプロイツール自体もHAになるよう作られている • リーダー選出には etcd の go クライアントの concurrency パッケージを使用
109. Neco のソフトウェア設計ポリシー 自律的なモニタリングやヒーリング機能を実装する →運用者の日常的な操作をなくすため 分散システムの管理APIは宣言的に実装する →運用者の操作ミスをなくすため
110. 開発体制
111. つらいポイント • 開発環境をみんなで共用している • 一つの環境に各人が自由にVMを作っている • VM管理はふだん各人に任せているので、 無駄なインスタンスが残りがち • 共用のサービス(Hadoopクラスタなど)をうっかり壊すと他の 人の作業の妨げになったりする
112. Neco の開発環境 • 各人が大きめのGCEインスタンス上に 複数のVMを起動し、仮想データセンターを構築
113. Neco の開発環境 • 各人が大きめのGCEインスタンス上に 複数のVMを起動し、仮想データセンターを構築 • 共用にともなう悩みを解決 • 気軽に壊せるので動作テストしやすい • 環境再構築にかかる時間は実機に比べると圧倒的に速い
114. Neco の開発環境 • 仮想DC構築のためのツールを作成 • https://github.com/cybozu-go/placemat • YAMLで定義したリソースから VMやLinux bridgeを作る • 仮想BMC つき(IPMIで電源管理できる) • テストの実行環境としても活用している
115. 作っているものは見れる？ • 開発成果物はほぼすべてMITライセンスで公開してます • 完成したら公開とかではなく、1コミット目から公開 • https://github.com/cybozu-go/ • https://github.com/cybozu/
116. なぜオープンソースにするのか • 自社事情への過度な特化の防止 • 効果：設定が外部化されることで試験がしやすい • 効果：一定の独立性があるのでモノリスを防止 • 品質の担保 • 効果：ドキュメントの充実 • 効果：自動テストの充実 • 効果：積極的なリファクタリング
117. 閑話休題：サイボウズのOSSポリシー • サイボウズでは OSS ポリシー策定が進行中 • 社員が OSS 公開したりパッチを送ることを積極支援する内 容 • 著作物が会社に帰属するケースを大幅に制限 • 弊社エンジニア @uchan_nos が builderscon で発表します • https://builderscon.io/tokyo/2018/session/88adb843- 7d75-4711-b3a1-60ed3aa75dbc
118. 成果物
119. Placemat • https://github.com/cybozu-go/placemat • 仮想データセンター構築ツール • 以下のリソースを YAML で組み合わせて起動・終了できる • L2 ネットワーク by Linux bridge • Pod by rkt • VM by QEMU/KVM • 仮想 BMC (IPMI) • アドホックにDCと同様の環境を構築可能。開発環境として使ったり、CIで E2Eテストを回したり
120. Placemat-menu • https://github.com/cybozu-go/placemat-menu • placemat の補助ツール • 大規模なネットワーク構成を手で書くのが大変なので自動生成 • 以下に必要なファイル群を生成 • Core スイッチ (bird コンテナ) • Spine-Leaf スイッチ（bird コンテナ） • 各ラック内のサーバー（QEMU/KVM） • 仮想DC内部からホスト OS への NAT 通信
121. sabakan • https://github.com/cybozu-go/sabakan • オンプレミスサーバーをネットブートするツール • etcd で排他制御しながら冗長化 • 機能 • DHCP (etcd でリース情報を共有) • UEFI HTTP Boot & iPXE HTTP Boot • Ignition テンプレート for CoreOS Container Linux • OS イメージや各種アセットの分散管理機能 • サーバーライフサイクルの管理 • ストレージ暗号化の補助機能
122. CKE (Cybozu Kubernetes Engine) • https://github.com/cybozu-go/cke • etcd+Kubernetesクラスタのデプロイ＆ライフサイクル管理ツール • sabakan と連携可能 • 特徴 • etcd をバックエンドに冗長構成でリーダー選出して動作 • ネットワークプラグインに非依存
123. etcdpasswd • https://github.com/cybozu-go/etcdpasswd • etcd で Linux ユーザー/グループを集中管理 • エージェントが各サーバーで自律動作 • etcd データベースの内容でシステムを自動更新
124. 他にもいろいろ • https://github.com/cybozu/neco-ubuntu • ブートサーバ用のカスタムISO • https://github.com/cybozu/neco-boot • ブートサーバクラスタ構築スクリプト群 • https://github.com/cybozu/neco-containers • Necoで使う各種コンテナ
125. 現時点の開発状況 • アーキテクチャ検討はほぼ完了 • 物理ラック構成は策定済み • BGP 中心のネットワークは実装済み • 目下の取り組み • Kubernetes の自動デプロイ＆ライフサイクル管理 • 結合試験の自動化と CI/CD
126. まとめ
127. 機材構成 • 機材構成がセグメントごとに異なり、機材導入・修理のために コンスタントに工数がかかっていた →実機構成を汎用化することで、手順を簡略化します
128. 実機のライフサイクル管理 • 機材の状態をあらためて定義しなおしました • 人手が必要になる場面が少なくなるように ライフサイクル管理用のツールを作りました
129. サービス運用 • 複雑かつスケーラビリティに欠ける構成になっていた これまでの基盤を、Kubernetesを中心に設計しなおしました
130. Neco とは何か • cybozu.com のアーキテクチャを刷新するプロジェクト 目標 • 運用コストの劇的な削減 • スケーラビリティの向上
131. Neco のアーキテクチャ志向 • Declarative architecture-style • 人は望みの状態を宣言するだけ • Software Defined • 役割を物理構成ではなくソフトウェアで制御 • Test Everything • データセンター丸ごと仮想化して開発・試験
132. 最後に Necoは新メンバーを募集中です！ 興味のある方はぜひご連絡ください。 ご清聴ありがとうございました！