Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

dulltz
August 25, 2018

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

dulltz

August 25, 2018
Tweet

More Decks by dulltz

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  5. はじめに

    View Slide

  6. cybozu.com とは

    View Slide

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

    View Slide

  8. cybozu.com のインフラ

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  14. つらい

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  21. 概要説明終わり

    View Slide

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

    View Slide

  23. 機材構成

    View Slide

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

    View Slide

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

    View Slide

  26. 現行インフラのつらいポイント
    • 増設・退役オペレーションが大変
    • 毎週1~2人日の工数がかかっている

    View Slide

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

    View Slide

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

    View Slide

  29. 図を使って説明します

    View Slide

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

    View Slide

  31. ある機材の導入
    • ラックにサーバを追加
    • ToRにつなぐだけ(どの機材も同じ!)

    View Slide

  32. ある機材の導入
    • ネットブートする(UEFI HTTP Boot)

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  37. ネットブートのためにsabakanが持っている機能
    Container Linux は Ignition というJSON形式のファイルから
    プロビジョニングできる
    sabakan は Ignitionファイルを作成・配信できる

    View Slide

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

    View Slide

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

    View Slide

  40. ネットブートのためにsabakanが持っている機能
    • OSイメージや各種アセットを配布するファイルサーバ機能
    • インスタンス間で自動分散される

    View Slide

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

    View Slide

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

    View Slide

  43. sabakanのファイル分散機能
    • 他のsabakanはetcdの変更を検知 (etcd の Watch API を活用)
    etcdの変更を検知

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  49. 現行インフラのつらいポイント
    例:
    機材状態が ”unavailable” であるときに
    • 修理待ち
    • 修理済み
    のどちらもありうる…

    View Slide

  50. 現行インフラのつらいポイント
    例:
    故障からの復帰中(RAIDリビルド中など)を表す状態が無い。

    View Slide

  51. では現状どうしているのか?

    View Slide

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

    View Slide

  53. 現行のライフサイクル管理の
    つらいポイント2
    ユーザが機材管理DBに登録した
    機材状態と実際の状態に
    乖離が生まれる

    View Slide

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

    View Slide

  55. 現行のライフサイクル管理の
    つらいポイント3:
    安全に状態遷移できない

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  66. サーバが故障する

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  76. サービス運用

    View Slide

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

    View Slide

  78. つらいポイント1
    スケーラビリティに欠ける

    View Slide

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

    View Slide

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

    View Slide

  81. つらいポイント2
    デプロイツールが複雑

    View Slide

  82. デプロイツールが複雑
    • 規模の拡大や構成要素の増加に従って、秘伝のたれ化

    View Slide

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

    View Slide

  84. Necoではどうするか

    View Slide

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

    View Slide

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

    View Slide

  87. Kubernetesを導入します

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  91. Kubernetesで解決しそうに見え

    View Slide

  92. しかしKubernetes自体の運用は
    結構大変?

    View Slide

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

    View Slide

  94. Kubernetes運用も楽にした
    い!!

    View Slide

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

    View Slide

  96. 理想的なKubernetes運用
    ノード1~3が
    コントロールプレーン、
    残りのノードはワーカーで!

    View Slide

  97. 理想的なKubernetes運用
    Kubernetesクラスタ
    構築!

    View Slide

  98. 理想的なKubernetes運用
    • 一部のノードのサービスが死んでしまったとき

    View Slide

  99. 理想的なKubernetes運用
    • 一部のノードのサービスが死んでしまったとき
    理想状態との差分を
    検出

    View Slide

  100. 理想的なKubernetes運用
    • 一部のノードのサービスが死んでしまったとき
    再デプロイ

    View Slide

  101. 理想的なKubernetes運用
    クラスタ構成を変更したいとき
    ノード1~6が
    コントロールプレーン、
    残りのノードはワーカーで!

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  110. 開発体制

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  114. Neco の開発環境
    • 仮想DC構築のためのツールを作成
    • https://github.com/cybozu-go/placemat
    • YAMLで定義したリソースから
    VMやLinux bridgeを作る
    • 仮想BMC つき(IPMIで電源管理できる)
    • テストの実行環境としても活用している

    View Slide

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

    View Slide

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

    View Slide

  117. 閑話休題:サイボウズのOSSポリシー
    • サイボウズでは OSS ポリシー策定が進行中
    • 社員が OSS 公開したりパッチを送ることを積極支援する内

    • 著作物が会社に帰属するケースを大幅に制限
    • 弊社エンジニア @uchan_nos が builderscon で発表します
    • https://builderscon.io/tokyo/2018/session/88adb843-
    7d75-4711-b3a1-60ed3aa75dbc

    View Slide

  118. 成果物

    View Slide

  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テストを回したり

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  126. まとめ

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide