Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
CNCF公式プロジェクトRookのメンテナになった話 〜これまでとこれから〜
Search
Satoru Takeuchi
PRO
December 19, 2020
Technology
1
2.7k
CNCF公式プロジェクトRookのメンテナになった話 〜これまでとこれから〜
Open Developers Conference 2020 Onlineの発表スライドです
Satoru Takeuchi
PRO
December 19, 2020
Tweet
Share
More Decks by Satoru Takeuchi
See All by Satoru Takeuchi
Linux環境のCPU上で10ミリ秒間に起こること
sat
PRO
3
73
HDDへのアクセス速度は位置によって変わる!??
sat
PRO
4
33
ボリュームマネージャLVM
sat
PRO
2
74
Best Practices of Production-Grade Rook/Ceph Cluster
sat
PRO
1
1.7k
OSSへの貢献をはじめたきっかけ、貢献で得たもの、やりたい人へのアドバイス(改)
sat
PRO
4
120
device mapperによるディスクI/O障害のエミュレーション 既存ターゲット編
sat
PRO
0
99
分散ストレージCephのデータ破壊検知修復機能は本当に動作するのか
sat
PRO
0
42
ディスクI/O障害のエミュレーション カーネルモジュール自作編
sat
PRO
0
38
分散ストレージはすごいぞ
sat
PRO
2
2.5k
Other Decks in Technology
See All in Technology
事業部を超えた 開発生産性向上に挑戦する
kentakozuka
5
930
生成AIサービスPanorama AIご説明資料
sdt
0
300
既存プロセスからの脱却と変化に適応するために必要なこと
cybozuinsideout
PRO
2
170
AWS アーキテクチャクイズ
yuu26
2
700
Elementaryを用いたデータ品質の可視化とデータ基盤の運用改善
10xinc
6
1.4k
ビジネスとコード品質の接合点 そしてコード品質がそこに及ぼす影響 / The Intersections of Business and Engineering, and The Impact of Code Quality There
mtx2s
10
1k
初心者が行く!サーバレスWebアプリ開発の道
nagaharutogawa
0
440
継続的テストモデルを実現するためにスリーアミーゴスを用いた10Xでのシフトレフトの事例
nihonbuson
3
150
技術広報として2023年度に頑張ったこと / What we did well in FY2023 as a DevRel
pauli
5
450
MongoDB Atlas Vectorsearchではじめる生成AIアプリ開発
chie8842
3
500
関数型DDDの理論と実践:「決定を遅らせる」を先につくり、 ビジネスの機動力と価値をあげる
knih
2
150
チーム単位で保守性を高める:独自指標と向上にむけた実践
tarappo
0
300
Featured
See All Featured
Building Flexible Design Systems
yeseniaperezcruz
317
37k
From Idea to $5000 a Month in 5 Months
shpigford
376
45k
StorybookのUI Testing Handbookを読んだ
zakiyama
10
4.5k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
501
140k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
240
1.2M
Building Adaptive Systems
keathley
29
1.8k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
272
12k
BBQ
matthewcrist
78
8.7k
Building Your Own Lightsaber
phodgson
97
5.6k
The Language of Interfaces
destraynor
150
22k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
5
1.4k
Teambox: Starting and Learning
jrom
126
8.4k
Transcript
CNCF公式プロジェクトRookの メンテナになった話 ~ これまでとこれから ~ Open Developers Conference 2020 Online
Dec 19th, 2020 sat@Cybozu 1
自己紹介 ▌2018年サイボウズ入社 ▌国内向け次期インフラ基盤の開発者 ⚫ストレージチーム所属 ▌Rook(後述)のメンテナ ⚫ コミット権限がある開発者
今日知ってもらいたいこと ▌私がRookメンテナになるまでの流れとこれから ⚫なぜ開発に参加したか、どう貢献してきたか、など ▌上記から得られたOSS開発のノウハウ ⚫どういう場合に参加すべきか ⚫どこまで深入りすべきか ⚫会社と個人でどう違うのか 3
目次 1. Rookとは 2. なぜRookを採用したのか 3. なぜRookの開発に参加したのか 4. どのようにメンテナになったのか 5.
まとめ 4
目次 1. Rookとは 2. なぜRookを採用したのか 3. なぜRookの開発に参加したのか 4. どのようにメンテナになったのか 5.
まとめ 5
Rookとは ▌Kubernetes上で動くストレージオーケストレーション ▌Cephなどの様々なストレージソフトウェアをサポート ⚫サイボウズもCephを使っている ▌Cloud Native Computing Foundation(CNCF)公式プロジェクト ▌採用例 ⚫20社以上がすでに業務利用中
⚫Rookベースの商用製品もある 6
目次 1. Rookとは 2. なぜRookを採用したのか 3. なぜRookの開発に参加したのか 4. どのようにメンテナになったのか 5.
まとめ 7
前提 ▌ストレージソフトウェア超重要 ▌理由 ⚫お客様データは何より重要 ⚫データ破壊、消失障害による影響 ⚫お客様もサイボウズも会社が傾く、最悪潰れる ⚫社会的信用も失う ⚫トラブル発生時には可及的速やかな対処が必要
Rookの採用経緯 1. 既存インフラの課題をCephが解決できる ⚫しかしCeph単体では使い方が難しい… 2. RookでCephを管理しよう! ⚫Cephは長年使われてきた実績がある ⚫Rookも将来有望 ⚫CNCF公式プロジェクト、商用製品もある
他の手段をとらなかった理由 ▌非OSSな商用ストレージ製品 ⚫必要な機能の実装、バグ修正をコントロールできない ⚫ベンダが「やらない」といったらそれで終わり ⚫やるとしてもいつやるかはベンダ次第 ▌完全自作のCeph管理ツール ⚫必要な工数が非常に多くなる ⚫当時Cephの知見が無かったのでなおさら ⚫ストレージソフトウェアで初モノは避けたい
目次 1. Rookとは 2. なぜRookを採用したのか 3. なぜRookの開発に参加したのか 4. どのようにメンテナになったのか 5.
まとめ 11
Rookの使い方の基本方針 ▌Rookベースの商用製品ではなくupstream版を使う ▌機能追加、バグ修正が必要になったら? ⚫upstreamを修正後、リリース版を使う ▌緊急修正が必要になったら? ⚫サイボウズ独自版を一時的に使う ⚫修正マージされたら即upstream版に乗り換え ⚫最悪ローカル修正を使い続けることも許容(現状はそうなっていない) 12
Rookベースの商用製品を使わなかった理由 ▌結局機能追加、修正提供の保証がない ⚫Q: RookはOSSだから直せるんでは? ⚫A: ベンダがサポートするのはベンダが提供する バージョンのみ ⚫自前で緊急修正を適用しての運用は普通契約違反 ⚫ 自分でupstream開発してベンダに取り込んでもらう手も
▌自前運用を可能にする技術者が社内にいた
upstream開発に参加する利点 ▌Upstreamからforkした独自版の管理はメンテが辛い ⚫Upstreamのバージョンアップへの追従 ⚫必要な修正のバックポート ▌upstreamが盛り上がると機能、品質強化に繋がる ⚫ユーザや開発者が増える ⚫Issue発行/PR投稿が増える ▌Rook/Cephの知見増加が見込める ⚫使うだけより開発するほうが圧倒的に知見は溜まる
開発へのコミット方針 ▌最初からメンテナになるつもりで参加 ⚫機能不足もバグ修正も自分でPRを送って解決 ▌期待されるメリット ⚫緊急時に他のメンテナと密連携できる ⚫自分の詳しい分野であれば自分でマージもできる ⚫もちろん濫用はしない ⚫プロジェクト全体の方向性がわかりやすくなる
会社向けTIPS: 開発にどれだけ深入りすべきか ▌状況による ⚫トラブル発生時の即時対応が必要ない ⚫メンテナになる意義は薄れる ⚫機能はありものでいい、バグ修正は急がない ⚫開発に参加する意義は薄れる ▌サイボウズも使っている全OSSにメンテナを 出すつもりはない
個人向けTIPS: 開発にどれだけ深入りすべきか ▌ソフトへの愛があればオッケー! ⚫あとは無理のない範囲でできることをやる ⚫愛用しているソフトへの参加がお勧め ▌バッドエンドになりがちなもの ⚫使ってもいない有名なソフトウェアを選ぶ ⚫愛着はないしデカすぎるしで嫌になる
目次 1. Rookとは 2. なぜRookを採用したのか 3. なぜRookの開発に参加したのか 4. どのようにメンテナになったのか 5.
まとめ 18
メンテナになるまでの流れ 1. 検証中に困ったところを片っ端から修正 ⚫ 私一人ではなく他のメンバもたくさん貢献しています 2. 自分が直接困っていないところにも貢献 ⚫ユーザサポート、他のPRのレビュー 3. リソースが足りていないところに貢献
⚫テスト追加 ⚫ドキュメント追加 4.メンテナになりたいと宣言 19
具体的な貢献実績 ▌通算コミット数世界8位 ▌開発に参加し始めたv1.2からでは世界4位 ⚫会社別では世界2位 20
メンテナ就任時の評価ポイント ▌特定分野についての貢献が大きかった ⚫データの分散配置ロジック改善 ⚫テスト強化 ▌継続的なレビュー、ユーザサポート 21
評価ポイントから感じたこと ▌コミュニティ全体への貢献度が重要 ⚫コミット数や技術力が全てではない ▌信頼第一 ⚫自分の意見のゴリ押しではなく議論で解決 ⚫失礼な振る舞いはもってのほか
これまでの活動で得られたもの ▌Rookコミュニティの信頼 ▌Rook/Cephについての大量の知見 ▌自分達が実装した機能の品質強化 ⚫使ってくれる人が多くいた ⚫バグ報告をいくつももらった(全部修正済)
メンテナになってからの活動 ▌以前と変わらないこと ⚫自社システムに必要な機能追加、バグ修正 ▌変わること ⚫テスト強化。他のメンテナ達に自分がやると宣言済 ⚫より一層のユーザサポート ⚫レビュー&マージ ⚫得意分野についてはメンションが飛んでくる 24
会社/個人向けTIPS: お勧めの第一歩 ▌自分が実際に困っていることの解決 ⚫Issue発行 ⚫PR投稿 ▌簡単な既存issueを片付ける ▌ 勇気を出して一歩足を踏み出すと後は楽!
会社/個人向けTIPS: 貢献は徐々に増やす ▌最初から大きな貢献をしようと肩肘貼らない ▌わたしのコミット数も徐々に増えてきた 26 バージョン コミット数 V1.2 2 V1.3
10 V1.4 37 V1.5 22
会社/個人向けTIPS: 貢献は徐々に増やす ▌最初から大きな貢献をしようと肩肘貼らない ▌わたしのコミット数も徐々に増えてきた 27 バージョン コミット数 V1.2 2 V1.3
10 V1.4 37 V1.5 22 軽微な修正のみ 機能追加、バグ修正、CI改善 機能追加、バグ修正、CI改善、ドキュメント改善 なんでも
会社向けTIPS: 開発の意義を理解する ▌私の場合 ⚫会社の方針としてメンテナになるつもりで開発開始 ⚫特殊な勤務形態が提供された ⚫Upstream Rookへの貢献が評価対象になる ▌不幸な例 ⚫「なんでウチに関係ないことしてるの?」 ⚫「メンテナ仕事は成果として評価しない」
目次 1. Rookとは 2. なぜRookを採用したのか 3. なぜRookの開発に参加したのか 4. どのようにメンテナになったのか 5.
まとめ 29
サイボウズのこれまでとこれから 1. Rookは極めて大事なソフトウェアと判断した 2. Rook開発に深くコミットすると決めた 3. プロジェクト全体へ継続的に貢献した 4. 実績が認められてメンテナ輩出した 5.
今後もRookプロジェクト全体に貢献する 30
OSS開発TIPS: 会社向け ▌開発への関わり度合い ⚫会社にとっての重要性によって決めるとよい ▌開発意義とOSS開発の特殊性への理解が必要 31
OSS開発TIPS: 個人向け ▌参加有無、度合い ⚫ソフトウェアへの愛の度合いによって決める ▌燃え尽きない範囲で興味のあるところから 32
OSS開発TIPS: 会社/個人向け ▌小さなことからコツコツと ▌「信頼第一」を念頭に 33
34 Thank you! Any question?