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

Aa97a6ad2c4c8422f5580f4f9d5b5744?s=47 dulltz
August 25, 2018

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

Aa97a6ad2c4c8422f5580f4f9d5b5744?s=128

dulltz

August 25, 2018
Tweet

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は新メンバーを募集中です! 興味のある方はぜひご連絡ください。 ご清聴ありがとうございました!