Bering Note – formerly 流沙河鎮

情報技術系のこと書きます。

OpenSearchCon North America 2025「From Bug to PR: 顧客課題の解決をUpstreamへの貢献に繋げる」- Brian Graf & Alex Bunday, NetApp Instaclustr

OpenSearchCon North America 2025のセッション「From Bug To PR: Turning Customer Pain Points Into Upstream Contributions」をまとめます。

www.youtube.com
資料
https://static.sched.com/hosted_files/opensearchconna2025/ac/OpenSearchCon25_From_Bug_to_PR.pdf

スピーカー

Brian GrafはNetApp InstaclusterでSenior Manager of Developer Relationsを務めています。6人の子供の父親でもあり、趣味人であり冒険家でもあります。仕事をしていないときは、妻と子供たちと過ごしたり、キャンプや狩猟、世界中を旅したりしています。EMC、VMware、AWSでのキャリアを経て現職に至っています。

Alex BundayはNetApp InstaclusterでSenior Product Managerとして、OpenSearchのプロダクトをリードしています。いつもコーヒーを片手に仕事をしている彼は、データドリブンであることを重視し、製品が本当の価値を提供することに情熱を注いでいます。最高の検索体験とは、ユーザーがその存在にほとんど気づかないもの、つまりただシームレスに動作するものだと信じています。製品を最適化していないときは、ジョークを最適化しているそうです。

セッションの流れ


このセッションでは、顧客が課題や要望を抱えた時点から、それがPull Requestとなり上流のオープンソースプロジェクトに貢献されるまでの一連のプロセスを取り上げます。
まず、顧客が抱える問題とは何か、そしてそれらの要望をどのようにトリアージするかについて説明します。次に、実際の変更を行う段階、つまりコーディング、開発作業、修正の適用といった実装フェーズに進みます。その後、完成した修正を顧客のシステムに適用するプロセスを見ていきます。
そして、OpenSearchのリポジトリに対してPull Requestを開始する段階について説明します。最後に、なぜこのような取り組みを行うのか、その主な利点について触れ、他の組織にも同様のアプローチを推奨したいと考えています。

NetApp Instaclusterとは


本題に入る前に、NetApp Instaclusterについて簡単に紹介しておきます。私たちのサービス内容を理解していただくことで、今日の話がより明確になるでしょう。
NetApp Instaclusterは、PostgreSQL、Apache Cassandra、Apache Kafka、Kafka Connect、ClickHouse、OpenSearch、Cadenceといった様々なオープンソーステクノロジーに対してマネージドサービスを提供しています。顧客は使いたいオープンソーステクノロジーと、利用したいクラウドプラットフォームを選択します。私たちは、その顧客のクラウドアカウント内でこれらのテクノロジーを運用します。
ここで特に強調したいのは、私たちが純粋なオープンソースを使用しているという点です。オープンソースの上に独自のレイヤーを構築したり、何か別のものを追加したりすることはありません。提供するものはすべて純粋なオープンソースそのものです。これにより、顧客は完全な柔軟性を保つことができます。もし何らかの理由で別の場所にクラスターを持つことになったり、私たち以外が管理する環境に移行することになったりしても、データへの完全なコントロールを維持できます。データは常に顧客が自由に扱えるものなのです。
マネージドサービスの内容としては、顧客が選択したテクノロジーとクラスターをデプロイした後、私たちのチームがそれを監視し、セキュリティスキャン、パッチ適用、アップグレードを行います。スケールアウトでもスケールアップでも、重い運用作業はすべて私たちが引き受け、顧客はアプリケーションの構築と利用に集中できます。さらに、プロジェクトの実装に関して追加のニーズがある場合は、コンサルティングのプロフェッショナルサービスチームが対応します。
これら全てが今日の話にどう関係するのでしょうか。重要なのは、私たちが純粋なオープンソースを使用し、顧客のために運用しているという点です。つまり、顧客が何か問題や課題に直面した場合、その問題や要望をコミュニティ全体のために持ち帰り、貢献することができるのです。

顧客課題の解決をUpstreamへの貢献に繋げる


私たちは多くの大規模エンタープライズ顧客と取引しており、彼らにとってOpenSearchはミッションクリティカルな存在です。顧客がOpenSearchを構築したりスケールさせたりする過程で、様々な課題や問題に遭遇することがあります。
最近の例を一つ挙げましょう。ある顧客からクラスター間レプリケーションに関する要望がありました。「リーダークラスターでインデックスが削除された場合、フォロワークラスターでもそのインデックスが削除されるようにしたい」というものです。この技術的な詳細について、聴衆の皆さんの中には理解されている方もそうでない方もいるかもしれません。しかし重要なのは、私たちがオープンソースの専門家として、こうした要望の意味を理解しているということです。
このような顧客の要望を受けると、私たちはそれをサポートするために、OpenSearchのアプリケーションで実際に何を変更する必要があるのかを理解する作業に取り組んでいきます。

この時点で、私たちには2つの選択肢があります。一つは、コードをフォークして自分たちで修正し、すべての顧客にとって完璧に機能するOpenSearchの独自バージョンを運用するという道です。しかし、私たちが好むのは、変更を上流に貢献し、誰もがその恩恵を受けられるようにすることです。
私たちには社内のエンジニアリング能力があり、OpenSearchに取り組むチームが存在します。同時に、オープンソース側で働く人々もいます。この両方のリソースを活用しながら、コミュニティ全体にとって価値のある貢献を目指しています。

要求のトリアージ


オペレーションチームがオープンソースプロジェクトで見つけたバグ、顧客が発見したバグ、あるいは顧客からの機能リクエストなど、様々な要求が私たちに届きます。
次のステップは、これらの要求をトリアージすることです。特に複数の要求がある場合、それがバグなのか機能リクエストなのかを適切に判断し、適切に対処する必要があります。バグであろうと機能リクエストであろうと、すべての要求はチームに届きます。私たちはOpenSearchのコードベースを熟知しているオープンソースエンジニアと共に、それぞれの要求を評価していきます。「今すぐこれに取り組むことができるか、コミュニティにどのような影響があるか、顧客にどのように役立つか」といった観点から検討します。それが機能なのかバグなのかを判断することで、どのように対処するかの方向性が見えてきます。
そして、私たちのエンジニアはさらに一歩進んで協力します。「この要望がある。オープンソースプロジェクトに追加する一環として、他にこれに取り組んでいる人はいないか」を確認するのです。最も避けたいのは、他の誰かとまったく同じものを構築してしまうことです。ですから、他の誰かが既にこれを構築しているのか、誰かが協力したいと考えているのかを調べ、コミュニティと協力しながらより多くの要件を収集していきます。

オープンソースコードでの変更の実装


トリアージが完了すると、チームに持ち帰ってソリューションの開発に取り組みます。私たちのオープンソースエンジニアであるMunirをはじめとするチームメンバーが、社内の開発チームと協力しながら実装を進めていきます。
私たちのチームは、トリアージセッションに参加し、変更がオープンソースプロジェクトとして完了し、Pull Requestとして提出できる状態になるようにします。そして、それがプロジェクトの将来のバージョンで優先されるよう取り組むと同時に、顧客に対しても「今これに取り組んでいます」「これを完了しました」「これが現在の進捗です」と定期的に伝え、適切な期待を設定します。
ここで重要なのは、私たちがこれに取り組んでいるだけでなく、それを求めている人々、それを望んでいる人々が、明確な理解と期待を持っていることを確認する必要があるということです。時には、その必要性が非常に緊急であることもありますし、単に「あればいいな」という程度のこともあります。しかし、いずれにしても、これらの期待を設定することは非常に重要です。

顧客システムへの修正の適用


私たちはOpenSearchの内部ブランチを保持しており、修正を顧客に直接デプロイすることができます。これにはいくつかの理由があります。時には非常に緊急性の高い問題であり、コミュニティがリクエストをトリアージして処理するのを待つことができない場合があるのです。そのような状況では、顧客に直接デプロイし、上流にマージされる前に緊急の修正を適用することもできます。もちろん、最終的にはこれらの変更が上流に統合されることを望んでいますが、この仕組みによって必要な柔軟性を確保しています。
修正が適用されたら、顧客に対して「この機能が追加されました」あるいは「修正されました」と通知します。また、顧客が実行しているOpenSearchのバージョンによっては、古いバージョンであれば、それらの変更をバックポートする必要がある場合もあります。繰り返しになりますが、私たちはそれを望んでいるわけではありませんが、それが私たちが持っている選択肢の一つです。
同時に、その変更がオープンソースコードでどのように処理されているかのステータスも顧客に伝え続けます。そして、それがメインプロジェクトにマージされたときには、その旨を通知します。

OpenSearchリポジトリへのPull Request


顧客システムへの修正の適用と並行して、Pull RequestをOpenSearchのリポジトリに提出します。Pull Requestが承認され、次のバージョンがリリースされれば、その変更がメインリポジトリにマージされ、誰もがこの修正の恩恵を受けることができます。これは本当に素晴らしいことです。

なぜUpstreamに貢献するのか


ここで、マネージドサービスプロバイダーとして、なぜこのような取り組みを行うのかという疑問が浮かぶかもしれません。これには多くの理由があります。
まず、顧客の成功は皆の成功につながるということです。顧客の問題を解決することで、製品全体をより良くすることができます。また、コミュニティとのオーナーシップとエンゲージメントも深まります。私たちは貢献することで、自分たちが取り組んでいることに対するエンゲージメントとオーナーシップを持つことができるのです。
オープンソースの本当に良い点は、一つの商業エンティティへの依存を減らす能力があることです。これにより、リスクを軽減し、サードパーティへの依存を減らして対応することができます。OpenSearchのオープンソースとしての性質により、顧客のニーズに合わせてカスタマイズすることが可能になります。
私たちはそれを活用して、必要なことを行うことができます。オープンソースのロードマップになかったり、プロジェクトの優先事項ではなかったりするものでも、顧客にとっては重要である場合があります。そのような場合、私たちはその変更を行い、優先順位を付ける能力を持っています。
これらすべての中で最も素晴らしいことは、現実の顧客の問題がプロジェクトにフィードバックされているということです。つまり、プロジェクト自体が、現実の顧客のユースケースに触れることで恩恵を受けているのです。私たちがこれらの変更を行うことで、プロジェクトが適応し、すべての人にとってより適切なものになっていきます。

プロセス全体の振り返り


ここまで、それぞれのステップを個別に説明してきましたが、ここでプロセス全体を俯瞰してみましょう。すべての会社が少し異なり、すべてのプロジェクトがわずかに異なる部分はありますが、最終的には、最初のバグからオープンソースプロジェクトに貢献するまでのプロセスは比較的同じパターンをたどります。
まず、顧客が問題を抱えていて、それを私たちに知らせてくれます。顧客は問題を抱えているときに私たちに知らせるのが本当に上手です。時にはTwitterでブランドについて不平を言う人もいるように、人々はこうした問題を周知させます。それが顧客によって見つけられたものであろうと、私たちによって見つけられたものであろうと、私たちは変化をもたらしたいと考えています。
その後、それを取り上げてトリアージし、範囲が何であるかを把握することが非常に重要です。特に個人貢献者の立場であれば、どれだけの作業に取り組むのか、どれくらいの時間がかかるかを把握することが重要です。そして実装に着手すると、これらの中には迅速で簡単な修正もあれば、はるかに時間がかかるものもあります。
今日取り上げたケースは、より大きな修正の例ですが、次のスライドではオープンソースプロジェクトに貢献する他の方法についても触れます。Pull Requestが承認されるまでのプロセスを経て、私たちはすぐに顧客にそれを提供します。なぜなら、その問題を迅速に解決したいからです。実際に承認され、実際のプロジェクトに組み込まれるまでには、8週間、16週間、あるいはそれ以上かかるかもしれません。しかし、顧客にはできるだけ早くそれを利用してもらいたいのです。
そして、その過程で、OpenSearchとそのチームと協力して、変更が次のリリースに確実に組み込まれるように取り組んでいます。

どうすればOpenSearchにコントリビューションできるのか


皆さんの中には、私たちがどのように貢献しているかを聞くためにここに来た方もいるでしょう。そして、おそらく皆さん自身も何らかの形で貢献することに興味をお持ちだと思います。では、OpenSearchへの貢献を始めるにはどうすればよいのでしょうか。
まず、OpenSearchのGitHubリポジトリにアクセスしてください。そこには、このプロジェクトが特定のことについてどのように行うかを示す2つの重要なドキュメントがあります。それは、オンボーディングと貢献に関するドキュメントです。これらには貢献方法が記載されており、これが始め方となります。次に、リポジトリをフォークして、作業を開始する必要があります。
しかし、ここで重要なのは、興味のあることについてIssueを開くことです。なぜなら、先ほども述べたように、あなたと同じように、あるいは別の会社や業界の誰かが、似たような考えやアイデアを持っていて、すでに何かを開発している可能性があるからです。すでに90%が完了している可能性もありますし、誰もこれについて考えたことすらない可能性もあります。したがって、これには2つの側面があります。誰かと協力することもできますし、もしすでに進行中のことであれば時間を節約することもできます。あるいは、その機能がたどるべき正しい道かどうかを判断するための対話を生み出すこともできます。ですから、最初からIssueを開くことは、コラボレーションの観点から非常に役立ち、本当に価値のあるものを作成するのに役立ちます。
そして、もう一つの側面は、コミュニティに参加することです。OpenSearchにはSlackチャンネルがあり、コミュニティは素晴らしいです。毎月コミュニティコールがあり、ユーザーグループもあります。参加して、活動し、自分と同じ、あるいは似たような興味を持つ人々を見つけてください。
最後に指摘したいのは、今日は機能について話しましたが、他にも貢献する方法はたくさんあるということです。ドキュメントの変更や追加のためにPull Requestを提出したことがある方もいらっしゃるでしょう。これはすごく簡単です。開発者である必要はありません。スペルミスや句読点の変更でも構いません。最初のPull Requestを提出して承認してもらってください。
サンプルを作成することも有効です。OpenSearchでも見られるように、初期のドキュメントにはまだ少しギャップがあります。これはElasticからのフォークの影響です。ですから、この分野に不慣れな人がそのドキュメントを見つけようとしても、OpenSearch内には存在しません。Elasticのドキュメントにアクセスするか、私たちが新たに書く必要があります。そのドキュメントを作成したり、これがどのように機能するかの例を作成したりすることは、他の人にとって非常に役立ちます。もしあなたが問題を抱えているなら、おそらく他の人も同じ問題を抱えています。そして、関わること自体が大きな違いを生むのです。

QA

質問1：どんな貢献から始めればいいのか
回答：情熱を傾けられることを見つけ、興味のあるトピックについて書くことはとても簡単です。あらゆる分野の専門家である必要はありませんし、人々があなたを知っている必要もありません。IssueとPull Requestのプロセスに従うだけで、それがマージされます。コミュニティも本当に協力的で、反応が非常に速いです。Issueを提起すると、必ず対処されるか、トリアージされるか、少なくともコメントが寄せられます。
質問2：具体的な貢献事例について
回答：網羅的なリストではありませんが、クラスター間レプリケーションに関する例を挙げます。ある顧客は複数リージョンの災害復旧機能が必要でしたが、設定方法が完璧ではありませんでした。フォロワークラスターに切り替えると、リーダークラスターのインデックスを書き戻したり削除したりできなかったのです。当社のオープンソースエンジニアであるMunerが、その問題を提起し、実際にマージされるように取り組みました。確か先週のことです。OpenSearchの次期バージョンで、その変更が反映され、顧客は満足してくれるでしょう。これまでにも多くの貢献をしてきました。
質問3：経営層への説明について
回答：貢献には時間がかかる場合もあるため、役員に「なぜそれが必要なのか、他の人のためだけでなく私たち自身のためにも利益があるのだ」と伝える必要があります。NetApp Instaclusterを愛している理由の一つは、この会社が非常にコミュニティ志向で、オープンソースに非常に力を入れているということです。私たちが純粋なオープンソースをうたっているのは、まさにそのことです。もし私たちがすでに顧客のためにこれを作成しているのであれば、そして私たちがオープンソースを愛しているのであれば、オープンソースを素晴らしいものにしているのはコミュニティの貢献です。それは貪欲にならず、私たちが恩返しすることであり、誠意を示すことでもあります。私たちは多くの友人を作り、多くのパートナーシップを築くことができました。なぜなら、それが信頼を築くからです。信頼もこの大きな要素です。顧客は私たちに耳を傾けてもらっていると感じて幸せになります。業界の他の人々も、もしあなたがテクノロジーやドキュメントのギャップに問題や困難を抱えているなら、他の人々も同じ問題を抱えている可能性が高いのです。一人の人を助けているなら、これはある種の正しいことです。
質問4：バグや機能リクエストが反映されるまでのタイムライン
回答：もちろん何であるかによって大きく異なりますが、小さなものであればはるかに早く完了できます。しかし、先ほど挙げたインデックス削除の例は、プラグインにとってかなり根本的な変更でした。顧客がリクエストしてから承認されるまでの全プロセスは、おそらく4、5ヶ月前だったと思います。OpenSearchの次のバージョンがリリースされるまでには、主要な機能であれば平均して6ヶ月くらいかかるでしょう。だからこそ、必要な場合は自社のブランチを通じて顧客に直接変更を加えることができるのは良いことですが、多くの場合、変更が反映されるのを待ちます。なぜなら、OpenSearchの多くのバージョンを実行したくないからです。それが典型的なタイムラインです。