CNDT 2022、サイボウズのストレージアーキテクトが企業からOSSへの貢献を継続する仕組みを解説

CNDT 2022から、自社利用からオープンソースコミュニティへの貢献の仕方を実際の経験を踏まえて解説するセッションを紹介する。セッションを担当したのはサイボウズ株式会社のストレージアーキテクトであるSatoru Takeuchi氏だ。

●動画：Rook/Cephストレージシステムを開発しながらupstream OSSに成果を還元してきた取り組み

セッションを行ったサイボウズのSatoru Takeuchi氏

タイトルは「Rook/Cephストレージシステムを開発しながらupstream OSSに成果を還元してきた取り組み」というものだ。前半ではサイボウズが利用する分散ストレージCephとCephをKubernetesから利用するためのオーケストレーターRookを紹介しつつ、後半で実際に遭遇したバグの紹介とその対処方法などを示し、企業内でユーザーという立場ながら、コミュニティの中での泳ぎ方を解説するという内容だ。

サイボウズのインフラとストレージの概要

すべてオープンソースソフトウェアを使って構築されているというインフラストラクチャー選択の理由は、バグや障害時にベンダーに任せずに自社で解決するためにはソースコードが公開され、コミュニティが機能していることが必須であると説明。ここで言う「自社で解決」とは自社で修正を行ったコードを提供することも含まれており、オープンソースソフトウェアをベンダー側でディストリビューションとしてまとめたパッケージを使わない理由が示されている。

そして特に今回のフォーカスであるストレージについて、分散ストレージのCephそしてCephをKubernetes上で実行するためのオーケストレーターであるRookを紹介した。

ここからCephとRookの紹介に続いて使われたスライドには、サイボウズが目指すストレージの完成型が紹介された。この図はこの後で再度、現在の姿との比較にも使われるため、理想の姿であると語った。

サイボウズが目指すKubernetesストレージの完成型

次に説明されたのは、オープンソースソフトウェアを使った自社システム開発のフローだ。

オープンソースソフトウェアを使った基本的な開発の流れを説明

大量の仮想マシンの上で仮想のデータセンターを構築して、その上で開発環境、本番環境などが用意され、デベロッパーはそれぞれのステージにアプリケーションをデプロイしてテスト、最終的に統合テストを経て本番環境に移行するという流れだ。それに加えてオープンソースソフトウェアで問題が見つかった場合は、自社のデータセンターのコードだけを直すのではなく、コミュニティが日夜開発を続けるアップストリームにも還元することを解説された。その理由として自社でメインブランチからフォークしたコードツリーを維持し続けることが、メンテナンスに大きな負荷がかかることなどを挙げた。

サイボウズが使うコンテナイメージなどについても、最新のアップストリームをベースに独自にビルドしたものであると説明。ただ独自にパッチを適用したイメージを使うこともあると説明したが、アップストリームにパッチがマージされていない、マージされても最新版としてリリースされていない場合に限るとして、ここでもアップストリームファーストの方針が示されている。

そしてここからRook/Cephを使う中で遭遇したバグについて解説。特にCephのストレージの実体であえるOSD（Object Storage Daemon）が壊れる、OSDが作れない、オブジェクトストレージが反応しないなどのトラブルを、例を使って解説した。それぞれアップストリームのCeph、Rookに対して修正パッチを作成して解決したというが、まだCephのコードを自身で修正、テストできない段階ではIssue Trackerを使ってコアデベロッパーに修正を依頼したことから、自社のインフラストラクチャーを使ってパッチを作成、テストしてコミュニティに提供するところまでが解説されている。自社で解決できない場合は依頼して修正を行うという辺りから、自社で解決するまでにどれくらいの労力と時間が必要だったのかについても言及して欲しい内容だ。

OSDを増やそうとすると作成に失敗するバグに遭遇

これらの貢献が認められてRookのメンテナーに昇格したことを説明。ただしメンテナーの仕事自体は非常に地味であると語った。

Rookのメンテナーの利点と地味な仕事を紹介

ここでサイボウズに直接関係のないバグ修正についても工数が発生していることについて、どのように折り合いをつけているのかを説明。特にサイボウズがOSSポリシーを策定していることが役に立っていることを強調した。

OSSポリシーによってメンテナーの仕事が可能になっている

そしてこれらのバグに遭遇する中で、Cephのテストについての疑問と改善点が浮かんできたことを説明し、ここからその経緯を解説した。

どうしてサイボウズはこんなに頻繁にCephのバグに遭遇するのか？を追及

ここからアップストリームのテストでバグが見過ごされる理由を分析。その結果、サイボウズの環境ではOSDが稼働する仮想マシンの再起動がコミュニティの環境よりも5倍程度多いこと、ほとんどの問題がHDDを使った環境で起こっていることなどを突き止め、アップストリームに問題提起を行い、今も議論を続けていることなどを説明した。サイボウズのOSSポリシーには、オープンソースソフトウェアにおいてバグを見つけたら修正する努力義務があると書かれているとコメントした。

障害がサイボウズでだけ頻発する原因を分析

最後のトピックとして、サイボウズがどうやってオープンソースソフトウェアの最新情報をチェックしているのかを解説。ここでは2名が毎日RookとCephに関する最新情報をチェックしているとして、深刻なバグの早期発見、問題に遭遇しないための対処の実施などが目的であると説明した。

毎日2名のエンジニアがRookとCephの動向をチェック

ここでオブジェクトストレージの性能劣化という問題とそれに対応するパッチを適用して性能劣化を回避したものの、データが一部壊れるという新しいバグが発生し、その対処に1ヶ月程度かかってしまったという例を紹介。これは性能改善を行うパッチの中に新たなバグが潜んでいたことが原因であったという。その結果、アップストリームのテストに漏れがあることが判明し、自社でアップストリームのテストを実行するようになったというエピソードを紹介した。これは新パッチの適用が新たなバグを産むということを実体験してしまった例であろう。これによってサイボウズのCephのアップグレードポリシーが変更されたという。

Cephコンテナのアップグレードに対する追加のテストを実施

アップストリームのチェック等については1名で行っていたが、リスクを減らす意味で2名に増員し、今後も慣れているエンジニアとそうでないエンジニアをペアにすることでノウハウを伝達できるようにする予定だという。

また自社の環境とは直接関係のない仕事を、オープンソースソフトウェアに対して行うことへの基本的な考え方も提示した。

オープンソースソフトウェアへの貢献に関する考え方を解説

オープンソースソフトウェアへの貢献を自然に行えるようにするためには自社の課題を見つけ、それをコミュニティに提案し、コミュニティ全体の利益に繋がるように行動しようと説明した。

最初はバグの報告から始め、ドキュメントの修正やテストの追加などもコミュニティとの関わりの良い始め方であると説明。公式ドキュメントを参照する、GitHubでの活動を真似する、経験のある社内のエンジニアを見つけて助けてもらうなどの具体的なステップを説明した。

貢献の「はじめの一歩」を説明

またバグの報告や修正提案などについても「最初から肯定的な反応は期待しない」「否定は注目されているサインだと思うべき」「無視されるのを防ぐためのコツ」などを解説した。

はじめの一歩から次のステップに進むための心構えと方法

そして無視されない秘訣として、どのチャネルを使ってコミュニケーションを行うのか、マージが実施される時の条件やリリースのサイクル、誰がキーパーソンなのか見つけることなどを説明した。

コミュニティを上手く泳ぐための秘訣を紹介

総論として自社内でオープンソースコミュニティに対して貢献を行うためには企業からのサポートがあるほうが良いとして、自社の利益とは関係ない仕事をサポートするポリシーがあること、Open Source Program Officeについても言及してセッションを終えた。

Ceph/Rookというサイボウズのシステムの中核となるストレージを、単なるユーザーという立場から一歩踏み込んでバグの報告から修正、さらにアップストリームのテスト改善までコミットしながら、会社からのサポートを受けているサイボウズの例は、事業会社でオープンソースソフトウェアを使いながらも業務の一貫としてコミュニティにコミットできないでいるエンジニアにとっては明るい未来に見えるだろう。しかしながらOSSポリシーの策定と遵守は一人のエンジニアが行えるものではなく、経営部門のコミットが必要だ。何よりも情報システム部門のトップがそれにコミットして持続させる姿勢が必要だろう。サイボウズがOSSポリシーを作った背景についても知りたくなる内容となった。

●参考：サイボウズのOSSポリシー