情報科学若手の会 2018 飛び入りLT枠 自作クラウド基盤 n0stack を開発した時に直面した問題点と、それに対する解決案のまとめです

1. 自作クラウド基盤 n0stack と
ソフトウェア開発の気持ち
wakate2018 LT
h-otter

2. 自己紹介
● h-otter です
● 電気通信大学 B4
● トラコンという大会を運営しています
● 自宅のラックは多分 PUE 0.5 くらい
○ コツは親をだまくらかすこと

3. n0stack とは
● 趣味で有志が集まって開発しているクラウド基盤
● ICTSCで OpenStack と CloudStack に疲弊し、
Kubernetesにまあまあ疲れたメンバーが開始
● かなり迷走した

4. 自分の満足の行くまで、好き放題やってる

5. メンバーも知らない最新版！！！
(みんなごめん)

6. とりあえず過去を振り返る

7. 時代1: Controller で集中管理
● OpenStack はコンポーネントの粗結
合は嘘なので、各コンポーネントを
粗結合にして Controller (API
Gateway)で集中管理してみた
● 結論: 粗結合はムリ！！
○ VM はストレージをマウント

8. 時代2: コントローラをMQで分散
● MQを使うことで各ノードにコントロール
プレーンを持たせて、
クラスタ管理を分散させることで
完全にコントローラレスを目指す
○ Scheduler -> Agent -> Conductor
-> Scheduler
みたいな
● 結論: MQの信頼性は低かった
● グラフDBでリソース管理できない
かなとかもやってみていた

9. 現在: リソース志向の gRPC API
● オブジェクトを役割に応じてレイヤー分割
○ レイヤー内では実装に関する依存を許す (詳細後述)
● シンプルにして、管理者がソースコードを読めるように

10. しんどかったポイントの整理と
n0stackにおける解決策を話していきます

11. 改善策、欲しい機能、意見などください！！
(あるあるの連続だと思うので...)

12. 依存を考えるのがしんどい
● 後回しにできないほどの負債になりうる
● 特に仕様が固まりきらない初期開発ではひとつの変更が全体に伝播し、繰り
返されるので心が折れる
○ (みんなの心を折った)
● 依存を集めるとそこだけライフサイクルが長くなる
○ 逆にライフサイクルが長いものに依存を集める
● 開発したいオブジェクトの通りに開発するのがやっぱり確実
(DDD的な)

13. 依存を考えるのがしんどい (オブジェクト内部)
pkg/datastore
(データベースに保存など )
pkg/driver
(QEMUなど)
Agent
(データプレーン)
API
(コントロールプレーン )
lower API
安定依存の原則
API < lower API <<< [大量展開の壁] <<< Agent <<< [ライブラリの壁]
<<< pkg/driver <<< [永続化の壁] <<< pkg/datastore

14. 依存を考えるのがしんどい (オブジェクト単位)
● オブジェクトのAPIは安定度が低いと定義しているので何かに依存が集ま
らないようにする

15. 分散コントローラがしんどい
● 分散されたデータプレーンは動くが、
分散されたコントローラは信用できないと思っている (今は)
○ 正しくはコントローラは無限に分散しない
○ なにも信用できない
■ 経路(MQ)、人、復帰するのかしないのか
● BGPが割と一般的に普及していてちゃんと動いているが、
あれは結局人がさんざん折衝しているものなので…NOGとか…
● Agent も薄いコントローラなので、妥協できるポイントを見つける

16. 分散コントローラがしんどい
コントローラの分散はやめて集中管理
Agentは可能な限り薄く

17. モデリングがしんどい
● インフラの正しいモデリングとは…
○ 利用者の 実装 / 思想 / ビジネスロジック によって変わる
■ ネットワーク: VLANかVXLANかで必要なパラメータは変わる
■ ストレージ: そもそも block device なのか filesystem なのか
● 抽象化したモデルが依存していなくても、
実装が依存してしまうことがある
○ ストレージとVM: VMがストレージに接続するときのプロトコルは？

18. モデリングがしんどい
抽象的なオブジェクトのみprotobuf定義
実装に関する依存をレイヤーの中に限り許容
※ k8s を参考に実装に関するパラメータは Annotations で頑張ってもらう

19. モデリングがしんどい
● 管理に必要なmetadataとNetworkを使う上で最低限必要なものを記述
● フィールドはすべて required

20. 多様性がしんどい
開発者: メンテナンスコスト向上
管理者: 変わったことをしようとすると、
非常に抽象化されたコードを読み、書
き換える必要がある
利用者: 使い方がわかりにくい
OpenStack Glance
非常に多数のformatも対応

21. 多様性がしんどい
実装からは汎用性を削除
管理者各々が必要なgRPC APIを
実装することを期待 (YAGNI, KISS)

22. 多様性がしんどい
現在の実装: 7725 行
少ないかはわからないが私が夏休み中に実装できたくらいの量

23. テストがしんどい
もともと API が多いのに、 Agent は network など設定するのでsudoが必要
● test sizeを導入 (http://akito0107.hatenablog.com/entry/2018/08/27/190333)
○ small: 早い、外部への依存がない
○ medium: sudo, localhostの他プロセスへの通信可
○ golangはいい感じにできるので “make test-medium” みたいな
● Mock の Agent を作ることで API のテスト
○ Agent の実装は薄い
○ API の Mock を作るコストはでかい

24. 非同期がしんどい
● よめない
● 本当にイベントを回収できているかわからない
○ MQ の Exactly once は難しい
● 昨日の発表にもあったかんじ
● しかし、VMのステート管理など必要なので今後の課題

25. まとめ
● 分散・非同期は私 (一般人) には難しいのであきらめた
● 依存は実際のオブジェクト同士の依存をトレースする
○ なくすことはできないし、下手なことをすると後々辛い
● 自由気ままに開発するの楽しい
○ 夏休みが全部溶けた