1. Cybozu Meetup #18 SRE/Neco, 2018-10-17
Shin'ya Ueoka
Cybozu Inc.
インフラ刷新プロジェクト
Necoが目指す
最高のクラウドとは

2. サイボウズ株式会社
グローバル開発本部 アプリ基盤チーム・Necoチーム
Shin'ya Ueoka
@ueokande
 2016年4月、エンジニアとして新卒入社
 趣味: インフラからフロントエンドまで
 Vim Vixen というWebExtensions作ってます

3. 目次
 cybozu.comについて
 インフラ刷新プロジェクト「Neco」とは
 まとめ
3

4. cybozu.com
4

5. cybozu.com
 2011年リリースの企業向けクラウドサービス
 サブドメインごとのプライベートクラウド
 国内オンプレミスDCで運用
onsha.cybozu.com
heisha.cybozu.com
5

6. 7年目のcybozu.comの規模
 契約ユーザー数: 100万人以上
 契約社数: 25,000社以上
 ホスト数: 1,500以上 (実機 + VM)
 データ量: 800TiB
 リクエスト数: +2億/day
6

7. 7年目のcybozu.comのビジネス要求
 ユーザー数は今後も順調に伸び続ける
 より多くのユーザー・多くのデータでも安定して運用したい
 サービスの価値を素早くユーザーに届けたい
7

8. サービス拡大の技術的課題
 インフラのスケールが厳しくなってきた
 スケーラビリティに欠けるモノリシックなアーキテクチャ
 cybozu.comの運用コストが大きい
 数百の機材をほぼ手動で管理・修理依頼
8

9. 「Neco」プロジェクト発足「Neco」プロジェクト発足
9

10. インフラ刷新プロジェクト「Neco」
 2018年1月に本格スタート
 Project Manager 1人、PG 6人、QA 2人
 cybozu.comのインフラをゼロベースで作り直す
 プロジェクトのゴール
 cybozu.comの運用コストの劇的な削減
 製品のスケーラビリティ向上
10

11. Necoの計画
2018 物理機材の管理の容易化
機材管理の容易化・コンテナ基盤の構築
2019 データベース・検索エンジン
MySQL・Elasticsearchクラスタの構築
2020 分散オブジェクトストレージクラスタ
Cephクラスタの構築
今から話す内容

12. オープンソース化！
 NecoではほとんどのプロジェクトをGitHubで公開
 自社事情への過度な特化の防止
 継続的な品質向上
 ドキュメント・コードの品質の担保
 CIによるテスト
12

13. 機材管理コストの低減
13

14. 現cybozu.comの機材構成
 用途ごとに異なるネットワーク・機材構成
 機材ごとにセットアップ・メンテナンス手順が異なる
 毎週、機材修理・交換のため業者とコンタクト
14
Storage
ServerDMZ
Proxy
Load Balancer
Misc
Manager
Boot

15. Necoの機材構成
 ラック内構成を統一して汎用的な機材構成に
15
計算機サーバー
ストレージサーバー
Rack Rack Rack

16. sabakan | DC内の機材をセットアップ
 DC内の機材一覧を保持
 機材情報から各種設定（IPアドレスなど）を生成
 管理者は機材のシリアル番号・ラック位置などを入力するのみ
 各機材はsabakanからLinuxをブートして各設定をロード
16
https://github.com/cybozu-go/sabakan

17. sabakanによる機材セットアップ
② 機材情報登録
17
Rack
Server
Storage
Server
Storage
Server
Server
Storage
Storage
① 機材が搬入
saba
kan
シリアル: ABCD3000
IPアドレス: 10.20.30.40
ホスト名: node-120
シリアル: ABCD3001
IPアドレス: 10.20.30.40
ホスト名: node-121
③ 各種設定が生成される
④ 機材がネットブート
Linuxと設定をロードして
OSが起動

18. Necoで変わる機材管理
 機材のセットアップ・メンテナンス方法が異なる
⇒ 管理者は搬入した機材情報の登録のみ
⇒ 用途・ネットワークはソフトウェアで定義
 毎週、機材修理・交換のため業者とコンタクト
⇒ 汎用構成なので機材をDCにプールできるようになった
⇒ 修理頻度を四半期に1回、ラック単位での増設・交換
18

19. アプリケーションデプロイ
19

20. 現cybozu.comのアーキテクチャ
physical
VM VM
physical
VM VM
physical
VM VM
kint
one
Garo
on
kint
one
Garo
on
kint
one
Garo
on
kint
one
Garo
on
Wor
ker
Wor
ker
 VMベースでアプリケーションをサンドボックス化
 VMの構築先はリソースが空いてる機材を探して手動
 構成が複雑で環境構築からリリースまでSRE依存
20

21. Necoのデプロイの方針
 コンテナベースのアプリケーション
 リソース管理は人間がしない
 開発チームもデプロイできる環境
 適切な認証・権限を設定
21

22. 22

23. Kubernetes導入のメリット
 リソース管理はKubernetesがいい感じに
 クラスタ管理者とサービス開発者で責務を分離
 サービス管理者がデプロイ・管理できる
 リリースタイミングをビジネス・開発側で決められる
23

24. Necoのアプリケーションデプロイ
 クラスタ管理者とサービス管理者で役割分担
physical physicalphysical
kint
one
kint
one
Garo
on
Wor
ker
Wor
ker
Kubernetes
Garo
on
Garo
on
Garo
on
kint
one
kint
one
製品リリース
クラスタ管理
サービス管理者
Kubernetes管理者
24

25. Necoで変わるデプロイ
 VMの構築先はリソースが空いてる機材を探して手動
⇒ リソース管理はKubernetesがいい感じに
 構成が複雑で環境構築からリリースまでSRE依存
⇒ サービス管理者がデプロイ・管理できる
25

26. Kubernetesのオンプレ運用…？
 Kubernetesデプロイツールはいくつかある
 kubeadm, kops, bootkube, ......
 これらはデプロイ・スケール時に人が利用することを想定
 いろいろ調べた結果、Necoでは自律的なクラスタ構築・管理
するサービスを開発
コマンドラインツールではなく
継続的にクラスタをメンテナンス
26

27. CKE (Cybozu Kubernetes Engine)
 Kubernetesクラスタを構築・メンテナンス
 クラスタが壊れたらオートヒーリング
 Kubernetesのデプロイ先はsabakanと連携
https://github.com/cybozu-go/cke
27

28. CKEによるKubernetesデプロイ
 sabakanに登録された機材がCKEがロード
 CKEは自律的にKubernetesデプロイやクラスタ修復する
28
CKE
Node A
Node B
saba
kan
Node C
Node D ① 機材登録② デプロイ
先をロード③ Kubernetes
をデプロイ

29. まとめ
29

30. Necoの計画
2018 物理機材の管理の容易化
機材管理の容易化・コンテナ基盤の構築
2019 データベース・検索エンジン
MySQL・Elasticsearchクラスタの構築
2020 分散オブジェクトストレージクラスタ
Cephクラスタの構築

31. まとめ
 Necoはcybozu.comのインフラを刷新するために絶賛開発中
 機材管理システムと素のKubernetes構築まではできた
 これからも最高のクラウドを目指していくぞい
31