CNCF公式プロジェクトRookのメンテナになった話　〜これまでとこれから〜

Transcript

1. CNCF公式プロジェクトRookの メンテナになった話 ~ これまでとこれから ~ Open Developers Conference 2020 Online

   Dec 19th, 2020 sat@Cybozu 1

2. 自己紹介 ▌2018年サイボウズ入社 ▌国内向け次期インフラ基盤の開発者 ⚫ストレージチーム所属 ▌Rook(後述)のメンテナ ⚫ コミット権限がある開発者

3. 今日知ってもらいたいこと ▌私がRookメンテナになるまでの流れとこれから ⚫なぜ開発に参加したか、どう貢献してきたか、など ▌上記から得られたOSS開発のノウハウ ⚫どういう場合に参加すべきか ⚫どこまで深入りすべきか ⚫会社と個人でどう違うのか 3

4. 目次 1. Rookとは 2. なぜRookを採用したのか 3. なぜRookの開発に参加したのか 4. どのようにメンテナになったのか 5.

   まとめ 4

5. 目次 1. Rookとは 2. なぜRookを採用したのか 3. なぜRookの開発に参加したのか 4. どのようにメンテナになったのか 5.

   まとめ 5

6. Rookとは ▌Kubernetes上で動くストレージオーケストレーション ▌Cephなどの様々なストレージソフトウェアをサポート ⚫サイボウズもCephを使っている ▌Cloud Native Computing Foundation(CNCF)公式プロジェクト ▌採用例 ⚫20社以上がすでに業務利用中

   ⚫Rookベースの商用製品もある 6

7. 目次 1. Rookとは 2. なぜRookを採用したのか 3. なぜRookの開発に参加したのか 4. どのようにメンテナになったのか 5.

   まとめ 7

8. 前提 ▌ストレージソフトウェア超重要 ▌理由 ⚫お客様データは何より重要 ⚫データ破壊、消失障害による影響 ⚫お客様もサイボウズも会社が傾く、最悪潰れる ⚫社会的信用も失う ⚫トラブル発生時には可及的速やかな対処が必要

9. Rookの採用経緯 1. 既存インフラの課題をCephが解決できる ⚫しかしCeph単体では使い方が難しい… 2. RookでCephを管理しよう! ⚫Cephは長年使われてきた実績がある ⚫Rookも将来有望 ⚫CNCF公式プロジェクト、商用製品もある

10. 他の手段をとらなかった理由 ▌非OSSな商用ストレージ製品 ⚫必要な機能の実装、バグ修正をコントロールできない ⚫ベンダが「やらない」といったらそれで終わり ⚫やるとしてもいつやるかはベンダ次第 ▌完全自作のCeph管理ツール ⚫必要な工数が非常に多くなる ⚫当時Cephの知見が無かったのでなおさら ⚫ストレージソフトウェアで初モノは避けたい

11. 目次 1. Rookとは 2. なぜRookを採用したのか 3. なぜRookの開発に参加したのか 4. どのようにメンテナになったのか 5.

    まとめ 11

12. Rookの使い方の基本方針 ▌Rookベースの商用製品ではなくupstream版を使う ▌機能追加、バグ修正が必要になったら? ⚫upstreamを修正後、リリース版を使う ▌緊急修正が必要になったら? ⚫サイボウズ独自版を一時的に使う ⚫修正マージされたら即upstream版に乗り換え ⚫最悪ローカル修正を使い続けることも許容(現状はそうなっていない) 12

13. Rookベースの商用製品を使わなかった理由 ▌結局機能追加、修正提供の保証がない ⚫Q: RookはOSSだから直せるんでは? ⚫A: ベンダがサポートするのはベンダが提供する バージョンのみ ⚫自前で緊急修正を適用しての運用は普通契約違反 ⚫ 自分でupstream開発してベンダに取り込んでもらう手も

    ▌自前運用を可能にする技術者が社内にいた

14. upstream開発に参加する利点 ▌Upstreamからforkした独自版の管理はメンテが辛い ⚫Upstreamのバージョンアップへの追従 ⚫必要な修正のバックポート ▌upstreamが盛り上がると機能、品質強化に繋がる ⚫ユーザや開発者が増える ⚫Issue発行/PR投稿が増える ▌Rook/Cephの知見増加が見込める ⚫使うだけより開発するほうが圧倒的に知見は溜まる

15. 開発へのコミット方針 ▌最初からメンテナになるつもりで参加 ⚫機能不足もバグ修正も自分でPRを送って解決 ▌期待されるメリット ⚫緊急時に他のメンテナと密連携できる ⚫自分の詳しい分野であれば自分でマージもできる ⚫もちろん濫用はしない ⚫プロジェクト全体の方向性がわかりやすくなる

16. 会社向けTIPS: 開発にどれだけ深入りすべきか ▌状況による ⚫トラブル発生時の即時対応が必要ない ⚫メンテナになる意義は薄れる ⚫機能はありものでいい、バグ修正は急がない ⚫開発に参加する意義は薄れる ▌サイボウズも使っている全OSSにメンテナを 出すつもりはない

17. 個人向けTIPS: 開発にどれだけ深入りすべきか ▌ソフトへの愛があればオッケー！ ⚫あとは無理のない範囲でできることをやる ⚫愛用しているソフトへの参加がお勧め ▌バッドエンドになりがちなもの ⚫使ってもいない有名なソフトウェアを選ぶ ⚫愛着はないしデカすぎるしで嫌になる

18. 目次 1. Rookとは 2. なぜRookを採用したのか 3. なぜRookの開発に参加したのか 4. どのようにメンテナになったのか 5.

    まとめ 18

19. メンテナになるまでの流れ 1. 検証中に困ったところを片っ端から修正 ⚫ 私一人ではなく他のメンバもたくさん貢献しています 2. 自分が直接困っていないところにも貢献 ⚫ユーザサポート、他のPRのレビュー 3. リソースが足りていないところに貢献

    ⚫テスト追加 ⚫ドキュメント追加 4.メンテナになりたいと宣言 19

20. 具体的な貢献実績 ▌通算コミット数世界8位 ▌開発に参加し始めたv1.2からでは世界4位 ⚫会社別では世界2位 20

21. メンテナ就任時の評価ポイント ▌特定分野についての貢献が大きかった ⚫データの分散配置ロジック改善 ⚫テスト強化 ▌継続的なレビュー、ユーザサポート 21

22. 評価ポイントから感じたこと ▌コミュニティ全体への貢献度が重要 ⚫コミット数や技術力が全てではない ▌信頼第一 ⚫自分の意見のゴリ押しではなく議論で解決 ⚫失礼な振る舞いはもってのほか

23. これまでの活動で得られたもの ▌Rookコミュニティの信頼 ▌Rook/Cephについての大量の知見 ▌自分達が実装した機能の品質強化 ⚫使ってくれる人が多くいた ⚫バグ報告をいくつももらった(全部修正済)

24. メンテナになってからの活動 ▌以前と変わらないこと ⚫自社システムに必要な機能追加、バグ修正 ▌変わること ⚫テスト強化。他のメンテナ達に自分がやると宣言済 ⚫より一層のユーザサポート ⚫レビュー&マージ ⚫得意分野についてはメンションが飛んでくる 24

25. 会社/個人向けTIPS: お勧めの第一歩 ▌自分が実際に困っていることの解決 ⚫Issue発行 ⚫PR投稿 ▌簡単な既存issueを片付ける ▌ 勇気を出して一歩足を踏み出すと後は楽!

26. 会社/個人向けTIPS: 貢献は徐々に増やす ▌最初から大きな貢献をしようと肩肘貼らない ▌わたしのコミット数も徐々に増えてきた 26 バージョン コミット数 V1.2 2 V1.3

    10 V1.4 37 V1.5 22

27. 会社/個人向けTIPS: 貢献は徐々に増やす ▌最初から大きな貢献をしようと肩肘貼らない ▌わたしのコミット数も徐々に増えてきた 27 バージョン コミット数 V1.2 2 V1.3

    10 V1.4 37 V1.5 22 軽微な修正のみ 機能追加、バグ修正、CI改善 機能追加、バグ修正、CI改善、ドキュメント改善 なんでも

28. 会社向けTIPS: 開発の意義を理解する ▌私の場合 ⚫会社の方針としてメンテナになるつもりで開発開始 ⚫特殊な勤務形態が提供された ⚫Upstream Rookへの貢献が評価対象になる ▌不幸な例 ⚫「なんでウチに関係ないことしてるの？」 ⚫「メンテナ仕事は成果として評価しない」

29. 目次 1. Rookとは 2. なぜRookを採用したのか 3. なぜRookの開発に参加したのか 4. どのようにメンテナになったのか 5.

    まとめ 29

30. サイボウズのこれまでとこれから 1. Rookは極めて大事なソフトウェアと判断した 2. Rook開発に深くコミットすると決めた 3. プロジェクト全体へ継続的に貢献した 4. 実績が認められてメンテナ輩出した 5.

    今後もRookプロジェクト全体に貢献する 30

31. OSS開発TIPS: 会社向け ▌開発への関わり度合い ⚫会社にとっての重要性によって決めるとよい ▌開発意義とOSS開発の特殊性への理解が必要 31

32. OSS開発TIPS: 個人向け ▌参加有無、度合い ⚫ソフトウェアへの愛の度合いによって決める ▌燃え尽きない範囲で興味のあるところから 32

33. OSS開発TIPS: 会社/個人向け ▌小さなことからコツコツと ▌「信頼第一」を念頭に 33

34. 34 Thank you! Any question?