こんにちは、Neco チームの@dulltzです。
オープンデベロッパーズカンファレンス2018にて「ツラくないクラウド運用環境を作る」という発表をしました。
この発表ではインフラ刷新プロジェクト Neco の取り組みについてお話しました。
- インフラ刷新プロジェクト Neco の目的
- 実機構成の話
- 実機のライフサイクル管理の話
- サービス運用の話
- 開発環境の話
せっかくなので本ブログでもかいつまんで説明します。
発表資料はこちら👉 ツラくないクラウド運用環境を作る - Speaker Deck
cybozu.com のインフラ
cybozu.comは弊社が提供するSaaSです。 実機管理からサービス運用まで、自社の運用チームが面倒を見ています。 cybozu.comは2011年にリリースされ、現在ではクラウド契約2.5万社100万ユーザ超のサービスに成長しました。
しかしユーザ数が増えるにつれ、現行インフラにつらい点が見つかってきました。
ひとつ目は機材の運用コストです。 機材を修理に出すオペレーションのために毎週1人日の工数がかかってしまっています。
ふたつ目は性能のスケーラビリティです。 DBに高負荷がかかり障害が起きるケースが発生しています。
インフラ刷新プロジェクト Neco
前述のつらさを解消するため、サイボウズでは Neco というプロジェクトを始動しています。
Neco は運用コストの劇的な削減とスケーラビリティの向上を目標に掲げて、 新たなクラウド基盤を構築するプロジェクトです。
この目標を達成させるため、設計方針を以下の３つに定めました。
- 宣言的なアーキテクチャスタイル
- ソフトウェアで定義する
- 自動テストを徹底する
ここからは 機材構成、機材のライフサイクル管理、サービス運用、開発環境 について具体的な話を見ていきます。
機材構成
まず機材構成について話をします。
現行のインフラでは、 L4ロードバランサ、L7ロードバランサ、キャッシュサーバ、DNSサーバ、サービスデプロイ用のコンピュートサーバ、ストレージサーバなど、 用途ごとに異なる機材構成 をとっています。
この構成には 増設・退役オペレーションが大変 というつらさがあります。
そこでNecoでは 汎用のネットワークスイッチとラックから構成し、 用途はソフトウェアで定義する ことにしました。 これにより増設・退役オペレーションは大幅に楽になります。
機材導入フローをアニメーションにしてみました。 こんな感じで人が機材管理ツールに情報を登録してサーバをToRのスイッチに繋げば、 あとは機材管理ツールがよしなにやってくれます。
Neco ではこの機材管理ツール sabakan を自作しています。
sabakan は各ネットブート用サーバ上に配置されることを想定しており、etcd によって整合性を保ちながら動作します。 sabakan はネットブートサーバとして機能するために以下の機能を持っています。
- UEFI HTTP Bootサーバ機能
- Ignition(CoreOSをプロビジョニングするためのユーティリティ) を組み立てる機能
- Ignition を配信する機能
- ファイル配信機能
ちなみにファイル配信機能を通じてアップロードされたファイルを sabakan の起動しているホスト間で自動分散するように作られています。 この機能の実装にも etcd が利用されています。
機材のライフサイクル管理
現行の機材ライフサイクル管理で困っていることの中に 実際の状態と管理DB記載の状態とが乖離するケース の存在があります。
これについて Neco では 機材管理ツール sabakan に保存した状態をプライマリデータ とし、 残りのシステムはその状態に収束するように動作する、 あるいはモニタリングツールが故障を検知し自動でプライマリデータを更新することにしました。
機材退役フローをアニメーションにしてみました。 こんな感じで 人は四半期に一度修理対応するだけ という運用を目指しています。
サービス運用
次にレイヤーを上げてサービス運用について話をします。
現行インフラのサービス運用におけるつらさは主に２つです。
- 性能面のスケーラビリティ
- デプロイツールの複雑化
まず性能のスケーラビリティについて。今は主にストレージのスループット回りで問題になっています。
Necoでは NVMe SSD のような高速なデバイスを使用することと、計算資源の割り当てを柔軟に設定可能 なアーキテクチャを採用することで解決します。
さらにデプロイツールの複雑化について。 現在のインフラでは、手続きを自動化するスクリプトを書いていった結果、 暗黙的に期待する実行順が生まれ、ツールの取り扱いが難しくなってしまいました。
これについて、Necoではクラウド基盤の管理を宣言的なAPIで行えるようにすることで解決したいと考えています。
このような経緯を元にサービスを載せる環境を考えた結果、Kubernetes の採用を決めました。
ただし Neco の本番環境では AWS などの IaaS を使わないので、 Kubernetes を採用してその上で動くアプリケーションのデプロイがつらくなくなったとしても、 Kubernetes の運用自体がつらいままだとしたらあまり意味がありません。
これをふまえて Neco では Kubernetes のデプロイ・アップデート作業を宣言的に行うツール CKE を開発中です。 CKE はクラスタ状態を常駐監視し、望む状態との差分を埋めるように適用していく挙動をするデプロイツールです。
開発環境
開発環境について話をします。ここでいう開発環境とは開発者の手元のマシンではなく、本番環境と同じようなマシンとネットワーク構成からなる開発用の環境のことです。
現行のクラウド基盤では開発環境を開発者間で共用しています。その結果、環境をゼロから作り直すような操作は基本できない状況があります。
そこでNecoでは各開発者がGCPインスタンス上に仮想データセンターを構築しその上で作業をできるようにしました。
この仮想データセンターはKVMやLinux Bridgeなどから構成されるのですが、 この環境構築を宣言的に行えるツール placemat を開発しました。
実際にNecoではこの環境の上で各ツールの開発を行っています。 また複数ホストを起動するような大規模な自動化テストにも利用しています。
成果物を OSS にしています
ちなみにNecoでは成果物のほとんどを 1コミット目からOSSとして公開 しています。 各ツールの詳細な解説記事もそのうち投稿される予定です。
- sabakan
- cke
- placemat
- placemat-menu
- 他にもいろいろ
最後に
Neco は既存のアーキテクチャを一気に改善する野心的なプロジェクトです。 モダンなインフラを構築したい方、OSS を活用・貢献したい方、分散システムの経験を積みたい方、是非 Neco チームにお声がけください。
