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

ツラくないクラウド運用環境を作る
cybozu.com の次世代アーキテクチャが目指すもの
サイボウズ株式会社
鶴田貴大

View Slide

アジェンダ
• 弊社サービスcybozu.comのインフラが抱える課題と、
それを解決するための刷新プロジェクトの解説をします
• 刷新プロジェクトの成果物の解説をします
いろいろあるのですが、
本発表に関連するのは主にこの辺り
• https://github.com/cybozu-go/sabakan
• https://github.com/cybozu-go/cke
• https://github.com/cybozu-go/placemat

View Slide

目次
• cybozu.comのインフラ刷新プロジェクト概要
• どのように刷新するか
• 実機構成
• 実機のライフサイクル管理
• サービス運用
• 開発体制
• OSSにしている成果物の紹介

View Slide

自己紹介
• 鶴田貴大 (Tsuruda Takahiro)
• @dulltz
• サイボウズのソフトウェアエンジニア
• 新卒入社2年目

View Slide

はじめに

View Slide

cybozu.com とは

View Slide

cybozu.com とは
• サイボウズが運営するクラウド型のグループウェア
• 2011年リリース
• 2018年現在、クラウド契約2.5万社100万ユーザ超
• 国内SaaS上場企業の売上No1らしい
• https://note.mu/naberun/n/n9026c6e9eec1

View Slide

cybozu.com のインフラ

View Slide

cybozu.com のインフラ
• 実機の管理からサービス運用まで、自社の運用チームが行う
• データセンターに1000台規模のサーバがある
• dev, production などの環境がある

View Slide

7年間でユーザ数が増えた
サーバ台数も増えた

View Slide

するとインフラに
いろいろな問題が
顕在化してきた

View Slide

インフラの課題
• 機材管理コストが実機台数に比例する
• 機材を修理に出す為に毎週1人日の工数がかかる
• 空きサーバを探すのが人力
• オペレーションを回すだけで大変
• 改善タスクを行う工数が不足

View Slide

インフラの課題
• スケーラビリティに欠ける
• DB負荷が障害につながってしまうケースもある
• アーキテクチャの設計的に、
サーバ台数を増やしても向上が見込めない

View Slide

つらい

View Slide

解決するために
インフラを刷新しよう

View Slide

というわけで
インフラ刷新プロジェクトが
立ち上がりました

View Slide

Neco プロジェクトといいます

View Slide

Neco プロジェクト
目標
• cybozu.com の運用コストの劇的な削減
• 製品のスケーラビリティの向上

View Slide

Neco のアーキテクチャ志向
• Declarative architecture-style
• 人は望みの状態を宣言するだけ
• Software Defined
• 汎用の物理機材をソフトウェアで制御
• Test Everything
• データセンター丸ごと仮想化して開発・試験

View Slide

Neco プロジェクト
2018 年 1 月に本格始動しました
3年で本番環境に載せる予定
現在、メンバーは8人
• エンジニア7人(うち1人はPMを兼務)
• QA1人

View Slide

概要説明終わり

View Slide

ここからは
何がつらいのか
どう解決するのか
説明していきます

View Slide

機材構成

View Slide

現行の機材構成
• 用途に合わせて機材構成が異なる

View Slide

現行インフラのつらいポイント
• セグメントごとに機材構成や導入手順が異なる
• DMZ
• L7LB, L4LB, DNSサーバ, プロキシサーバが別手順
• コンピュートサーバ
• ストレージサーバ
• 全体のマネージャ
• ...

View Slide

• 増設・退役オペレーションが大変
• 毎週1~2人日の工数がかかっている

View Slide

Neco ではもっと簡単にしたい

View Slide

Neco の機材構成
• 汎用のネットワークとラック構成にする
• 用途はソフトウェアで定義する

View Slide

図を使って説明します

View Slide

ある機材の導入
• 人が機材情報を機材管理ツールに追加
JSON

View Slide

• ラックにサーバを追加
• ToRにつなぐだけ(どの機材も同じ！)

View Slide

• ネットブートする(UEFI HTTP Boot)

View Slide

• ネットブートする(UEFI HTTP Boot)
• アプリケーションデプロイ可能な状態まで初期化

View Slide

Necoでは
• 人は機材情報を機材管理ツールにセットして
サーバをラックにつなぐだけ
• あとは機材管理ツールがよしなにしてくれる、という仕組み
• これは？

View Slide

自作しています
• sabakan
• 各ブートサーバ上に配置する
• ネットブートと機材管理を行うツール
• バックエンドがetcdで、これにより整合性を保ちながら動作

View Slide

ネットブートのためにsabakanが持っている機能
• DHCPサーバ機能
• リース情報は etcd に保存

View Slide

Container Linux は Ignition というJSON形式のファイルから
プロビジョニングできる
sabakan は Ignitionファイルを作成・配信できる

View Slide

参考 Container Linux
• CoreOSが開発する、
コンテナ動作環境として特化された軽量なLinuxディストロ
• 無駄なものが入っていない
• Dockerが最初から入っている一方で、
Pythonすら入っていない
• IgnitionというJSON形式のプロビジョニングの仕組みがある

View Slide

参考 etcd
• CoreOSがつくっているキーバリューストア
• 分散環境での高い信頼性が特徴
• 分散ロックがとれる
• 値の変更をウォッチできるAPIがある
• 一つのアイテムについて複数バージョンを保持できる
(Multi-version concurrency control)

View Slide

• OSイメージや各種アセットを配布するファイルサーバ機能
• インスタンス間で自動分散される

View Slide

sabakanのファイル分散機能
• 人がファイルをsabakanのうちの一つにアップロード
オペレータ
アップロード

View Slide

• sabakanは自身のホストにファイルを保存
• etcdにファイルのメタ情報を保存
etcd を更新

View Slide

• 他のsabakanはetcdの変更を検知 (etcd の Watch API を活用)
etcdの変更を検知

View Slide

• ファイルを持っているホストのsabakanからダウンロード
ファイルをDL

View Slide

• ファイルメタ情報を更新
自身からもファイルをダウンロード可能であることを追記する
etcdを更新

View Slide

• 一か所にファイルをアップロードするだけで全ブートサーバに
ファイルが分散共有される

View Slide

機材のライフサイクル管理
*機材のライフサイクル:
導入から退役までの状態遷移

View Slide

現行のライフサイクル管理の
つらいポイント1
機材の状態定義が
実際の状態を
十分に表現できていない

View Slide

例：
機材状態が ”unavailable” であるときに
• 修理待ち
• 修理済み
のどちらもありうる…

View Slide

例：
故障からの復帰中(RAIDリビルド中など)を表す状態が無い。

View Slide

では現状どうしているのか？

View Slide

現状どうしているのか
• 人が確認している
• “unavailable”な機材が
修理済みかどうかを管理するための台帳アプリが存在し、
そこで手動管理している
• RAIDリビルド中かどうか人がチェックしている

View Slide

ユーザが機材管理DBに登録した
機材状態と実際の状態に
乖離が生まれる

View Slide

管理DBと実際の機材状態の乖離
1. 機材を本番投入する
2. 機材の状態(稼働状態、ストレージ構成など) を管理DBに保存
3. 機材の状態が何らかの理由で変わる(故障など)
4. 人が機材を調査する
5. 人が機材の状態を更新しなおす

View Slide

つらいポイント3:
安全に状態遷移できない

View Slide

安全に遷移できない
• 状態変更するときは、DBのカラムへ直接書き込んでいる
• 現在どういう状態であろうが、
任意の状態に書き換えることができてしまう
• ありえない状態遷移を記述してしまっても気づけない
• 人が気を遣って遷移を記述している

View Slide

機材ライフサイクル管理つらいポイントまとめ
• 機材の状態を十分に定義できていない
• DBに保存してある状態と実際の状態とで乖離が生じる
• 安全に状態遷移を行えない

View Slide

機材ライフサイクル管理つらいポイントまとめ
いけてない部分は人の力でなんとかしている
台数が増えた今では大変

View Slide

Necoでは
運用する人が
頑張らなくてもいいようにしたい

View Slide

まず、機材の状態を再定義

View Slide

安全な状態遷移を行うために
機材管理ツールが可能な遷移を定義
それ以外の遷移は許可しない

View Slide

実際の状態との乖離を生まないために
• 機材管理ツールで保存した状態を
プライマリデータとする
• 残りのシステムはその状態に追従するように動作させる
• あるいはモニタリングツールが故障などを検知し
自動でプライマリデータを更新する

View Slide

機材退役フローを
図を使って説明

View Slide

登場人物
• 人
• 機材管理ツール
• 退避操作を行うアプリ
• モニタリング
• サーバ

View Slide

アプリケーション稼働中のサーバがある

View Slide

サーバが故障する

View Slide

モニタリングツールが検知

View Slide

対象マシンのstatusをUnhealthyに変更

View Slide

状態変更を検知した退避アプリが動作開始

View Slide

退避操作が完了次第、機材の電源断

View Slide

故障機材がたまってきたら人間が最終チェック

View Slide

いつでも業者に引き渡せる状態に

View Slide

大事なポイント
• 人が出てくる機会を極力減らす
• システムが自律管理する

View Slide

機材管理ツールが重要
役割
• 機材情報を管理する
• ネットブートする

View Slide

機材管理ツールが重要
機能要件
• 分散システム上で整合性を担保しながら動作できる
• 他のソフトウェアに状態変更を通知できる
どちらもetcdで実現

View Slide

サービス運用

View Slide

現行のソフトウェアアーキテクチャ
• 内製のサービスマネジメントシステム
• VMを構築し、その上にお客様の環境を用意

View Slide

スケーラビリティに欠ける

View Slide

スケーラビリティ不足
• スケールの上限=サーバ1台の性能
• 計算資源の割り当てが柔軟でない
• 逆に定常的にリソースが余りすぎているケースも結構ある

View Slide

計算資源の割り当てが柔軟でない
• 機材と動作するアプリケーションのインスタンスが密結合
• 故障機材で動作していたアプリケーションセットの
退避先を探すのが人手

View Slide

デプロイツールが複雑

View Slide

• 規模の拡大や構成要素の増加に従って、秘伝のたれ化

View Slide

• 規模の拡大や構成要素の増加に従って、秘伝のたれ化
• 難しくて訓練された運用メンバーしか使えない
• 社内ツールなので社内で訓練するしかない
慢性的な人手不足
• アプリのデプロイまわりをすべて運用チームが引き取ることに
なっている原因
• アップデート頻度が増える→運用チームのタスクが増える

View Slide

Necoではどうするか

View Slide

Necoの理想とするサービス運用
• 計算資源割り当て
• 実機とアプリケーションを疎結合にしたい
• スケール可能にしたい
• 故障機材の代替機を人が探し出すような
作業をしなくてすむようにする

View Slide

Necoのサービス運用
• デプロイ
• 望みの状態を宣言すれば、ソフトウェアがそうなるように動
作する仕組みを用意したい
• 手続き的な記述のオペレーションを管理するのは難しい。

View Slide

Kubernetesを導入します

View Slide

メモ: Kubernetes
• Googleが開発するコンテナオーケストレーションツール
• 宣言的なリソースを書けばコンテナ群をクラスタ内に良い感じに
デプロイしてくれる
• ユーザの望む状態へシステムが自律的に移行する仕組み
• クラスタは以下のノードから構成される
• コントロールプレーン
• ワーカーノード

View Slide

• 計算資源割り当て
• Kubernetesが良い感じに面倒を見てくれる
• 実機とアプリケーションを疎結合にできる

View Slide

• デプロイ
• 宣言的なKubernetesリソースを定義することでデプロイ可能
• デプロイをアプリケーションチームに移譲することも視野

View Slide

Kubernetesで解決しそうに見え
る

View Slide

しかしKubernetes自体の運用は
結構大変？

View Slide

Kubernetes運用で苦しんだら
元の木阿弥

View Slide

Kubernetes運用も楽にした
い！！

View Slide

理想的なKubernetes運用
• 宣言的な操作でKubernetes クラスタを構築したい

View Slide

ノード1~3が
コントロールプレーン、
残りのノードはワーカーで！

View Slide

Kubernetesクラスタ
構築！

View Slide

• 一部のノードのサービスが死んでしまったとき

View Slide

理想状態との差分を
検出

View Slide

再デプロイ

View Slide

クラスタ構成を変更したいとき
ノード1~6が
コントロールプレーン、
残りのノードはワーカーで！

View Slide

• クラスタ構成を変更したいとき
理想状態になるよう
再構築

View Slide

前述の機材導入フロー
• プロビジョニングが終わったら自動的に
Kubernetesクラスタのノードになっててほしい

View Slide

前述の機材退避フロー
• 退避するとき、Podをリスケジュールしてほしい

View Slide

sabakanと連携しながら
Kubernetesをデプロイする
ツールがほしい

View Slide

Kubernetes デプロイツールを自作しています
• 各ブートサーバにデーモンとして常駐
• 望ましい状態に段階的に近づけるようにクラスタを構築する
• クラスタ状態をチェック→etcdクラスタデプロイ→kube-
apiserverデプロイ→kube-controller-managerデプロイ→...

View Slide

• HAなコントロールプレーンをデプロイしてくれる
• 各ノードのリバースプロキシが
各コントロールプレーンのAPIサーバを指している
• 残りのコントロールプレーンのコンポーネントも
複数インスタンス立てて待機させておく

View Slide

このデプロイツール自体もHAになるよう作られている
• リーダー選出には etcd の
go クライアントの concurrency パッケージを使用

View Slide

Neco のソフトウェア設計ポリシー
自律的なモニタリングやヒーリング機能を実装する
→運用者の日常的な操作をなくすため
分散システムの管理APIは宣言的に実装する
→運用者の操作ミスをなくすため

View Slide

開発体制

View Slide

つらいポイント
• 開発環境をみんなで共用している
• 一つの環境に各人が自由にVMを作っている
• VM管理はふだん各人に任せているので、
無駄なインスタンスが残りがち
• 共用のサービス(Hadoopクラスタなど)をうっかり壊すと他の
人の作業の妨げになったりする

View Slide

Neco の開発環境
• 各人が大きめのGCEインスタンス上に
複数のVMを起動し、仮想データセンターを構築

View Slide

• 各人が大きめのGCEインスタンス上に
複数のVMを起動し、仮想データセンターを構築
• 共用にともなう悩みを解決
• 気軽に壊せるので動作テストしやすい
• 環境再構築にかかる時間は実機に比べると圧倒的に速い

View Slide

• 仮想DC構築のためのツールを作成
• YAMLで定義したリソースから
VMやLinux bridgeを作る
• 仮想BMC つき(IPMIで電源管理できる)
• テストの実行環境としても活用している

View Slide

作っているものは見れる？
• 開発成果物はほぼすべてMITライセンスで公開してます
• 完成したら公開とかではなく、1コミット目から公開
• https://github.com/cybozu-go/
• https://github.com/cybozu/

View Slide

なぜオープンソースにするのか
• 自社事情への過度な特化の防止
• 効果：設定が外部化されることで試験がしやすい
• 効果：一定の独立性があるのでモノリスを防止
• 品質の担保
• 効果：ドキュメントの充実
• 効果：自動テストの充実
• 効果：積極的なリファクタリング

View Slide

閑話休題：サイボウズのOSSポリシー
• サイボウズでは OSS ポリシー策定が進行中
• 社員が OSS 公開したりパッチを送ることを積極支援する内
容
• 著作物が会社に帰属するケースを大幅に制限
• 弊社エンジニア @uchan_nos が builderscon で発表します
• https://builderscon.io/tokyo/2018/session/88adb843-
7d75-4711-b3a1-60ed3aa75dbc

View Slide

成果物

View Slide

Placemat
• 仮想データセンター構築ツール
• 以下のリソースを YAML で組み合わせて起動・終了できる
• L2 ネットワーク by Linux bridge
• Pod by rkt
• VM by QEMU/KVM
• 仮想 BMC (IPMI)
• アドホックにDCと同様の環境を構築可能。開発環境として使ったり、CIで
E2Eテストを回したり

View Slide

Placemat-menu
• https://github.com/cybozu-go/placemat-menu
• placemat の補助ツール
• 大規模なネットワーク構成を手で書くのが大変なので自動生成
• 以下に必要なファイル群を生成
• Core スイッチ (bird コンテナ)
• Spine-Leaf スイッチ（bird コンテナ）
• 各ラック内のサーバー（QEMU/KVM）
• 仮想DC内部からホスト OS への NAT 通信

View Slide

sabakan
• オンプレミスサーバーをネットブートするツール
• etcd で排他制御しながら冗長化
• 機能
• DHCP (etcd でリース情報を共有)
• UEFI HTTP Boot & iPXE HTTP Boot
• Ignition テンプレート for CoreOS Container Linux
• OS イメージや各種アセットの分散管理機能
• サーバーライフサイクルの管理
• ストレージ暗号化の補助機能

View Slide

CKE (Cybozu Kubernetes Engine)
• etcd+Kubernetesクラスタのデプロイ＆ライフサイクル管理ツール
• sabakan と連携可能
• 特徴
• etcd をバックエンドに冗長構成でリーダー選出して動作
• ネットワークプラグインに非依存

View Slide

etcdpasswd
• https://github.com/cybozu-go/etcdpasswd
• etcd で Linux ユーザー/グループを集中管理
• エージェントが各サーバーで自律動作
• etcd データベースの内容でシステムを自動更新

View Slide

他にもいろいろ
• https://github.com/cybozu/neco-ubuntu
• ブートサーバ用のカスタムISO
• https://github.com/cybozu/neco-boot
• ブートサーバクラスタ構築スクリプト群
• https://github.com/cybozu/neco-containers
• Necoで使う各種コンテナ

View Slide

現時点の開発状況
• アーキテクチャ検討はほぼ完了
• 物理ラック構成は策定済み
• BGP 中心のネットワークは実装済み
• 目下の取り組み
• Kubernetes の自動デプロイ＆ライフサイクル管理
• 結合試験の自動化と CI/CD

View Slide

まとめ

View Slide

機材構成
• 機材構成がセグメントごとに異なり、機材導入・修理のために
コンスタントに工数がかかっていた
→実機構成を汎用化することで、手順を簡略化します

View Slide

実機のライフサイクル管理
• 機材の状態をあらためて定義しなおしました
• 人手が必要になる場面が少なくなるように
ライフサイクル管理用のツールを作りました

View Slide

サービス運用
• 複雑かつスケーラビリティに欠ける構成になっていた
これまでの基盤を、Kubernetesを中心に設計しなおしました

View Slide

Neco とは何か
• cybozu.com のアーキテクチャを刷新するプロジェクト
目標
• 運用コストの劇的な削減
• スケーラビリティの向上

View Slide

Neco のアーキテクチャ志向
• Declarative architecture-style
• 人は望みの状態を宣言するだけ
• Software Defined
• 役割を物理構成ではなくソフトウェアで制御
• Test Everything
• データセンター丸ごと仮想化して開発・試験

View Slide

最後に
Necoは新メンバーを募集中です！
興味のある方はぜひご連絡ください。
ご清聴ありがとうございました！

View Slide

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

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

dulltz

More Decks by dulltz

Other Decks in Technology

Featured

Transcript