2025年振り返り - Bering Note – formerly 流沙河鎮 の抱負のひとつとして、OSS活動を頑張ることを挙げた。今年も半分弱が過ぎようとしているので、途中経過を書き留めておく。
サマリ
OSS開発
| PR作成 | 49 |
| うちマージ済 | 37 |
| Issue作成 | 42 |
| うちクローズ済 | 20 |
月別推移
| 月 | PR作成 | Issue作成 |
|---|---|---|
| 1月 | 3 | 3 |
| 2月 | 14 | 12 |
| 3月 | 10 | 8 |
| 4月 | 10 | 9 |
| 5月 (18日まで) | 12 | 5 |
プロジェクト別 PR (作成 / マージ済)
*2025年に作成して2026年にマージされた PR を含む
OSSその他
OpenSearchブログ執筆
- Introducing the OpenSearch Hadoop connector 2.0: Spark 4 support, OpenSearch Serverless, and more - OpenSearch
- Data Prepper 2.15 brings Apache Iceberg ingestion and Prometheus metrics support - OpenSearch
- Personalizing your contact center agent using OpenSearch agentic memory - OpenSearch
代表的な活動、思い入れのある活動
OpenSearch Hadoop復興活動
opensearch-hadoopはSpark, Hive, MapReduceからOpenSearchを読み書きするためのクライアントライブラリで、巨大なデータを操作する用途でニッチながらも根強い需要がある。このリポジトリの難儀なところとして、Hadoop系の仕組みとOpenSearchの両方がわかる人間が世の中にあまりいない問題があり、色々な改善余地を残しつつも今ひとつ停滞気味な状況があった。
昨年ちょっとしたきっかけでこのライブラリのOpenSearch Serverless対応に取り組むようになり、その過程でバグ修正や改善をあれこれ入れていたら、気づけば自分が一番コントリビュートしている人になっており、なんやかんやあってメンテナに任命された。
Spark 4系対応やv2のリリースなどが完了して一旦落ち着いた感もあるが、Spark data source v2対応やgRPC対応などなどまだやるべきことが山積みなので、引き続き頑張りたい。
コードを書くだけでなく、ドキュメント整備やブログ執筆、メジャーバージョンリリースまでひと通りやれたのは良い経験になった。
github.com
Data Prepper Iceberg Source/Sinkほか
Data PrepperはOpenSearchプロジェクトの一部で、オブジェクトストレージやデータベース、ストリームソースなどからOpenSearchなどへのデータの抽出、変換、書き込みをストリーム的に処理する。
そのSource元 / Sink先としてIcebergを使えるようにする機能を提案し、受け入れられ、開発している。特にIceberg Sourceは世の中にありそうでない「Icebergからの」CDCを実現する仕組みで、なかなかユニークだと思う。
github.com
github.com
これらを作ることは、事実上Icebergの分散クエリエンジンを自作することを意味していて、開発を通じてIcebergへの理解を一層深められたように感じる。また、開発の過程では、SparkやFlink、Trinoなど既存のクエリエンジンの実装が参考になる部分も多々あり、巨人の肩に乗っている感覚が持てた。
Data Prepperに関しては他にもちょっとした改善やバグの修正などあれこれやっている。特に力を入れているのはマルチプラットフォーム対応で、現状のdata prepperは一部の機能がAWSでしか使えない。ごく一部にDynamoDBに依存しているコンポーネントがあるからだ。せっかくLinux Foundationのプロジェクトとして全体としてはオープンなスタックで開発していて、OpenSearch自体もプラットフォームに依存せず動かせるのに、Data Prepperが特定のクラウドでしか動かないのではつまらない。そこで、DynamoDB以外のデータストアで代替できるようにする機能を作っている。
github.com
OpenSearch Pull Based IngestionへのHive Table Source追加
ある日OpenSearchのコミュニティSlackでコアメンテナーのMichael Frohと議論する機会があった。OpenSearchはPull Based IngestionというOpenSearch自身がデータソースにアクセスして自律的にindexingする仕組みを持っていて、これはリソース効率の観点などで色々と都合がいいのだが、今のところKafkaとKinesisのみがソースである。しかし、Michaelの組織ではHiveテーブルからOpenSearchへindexしたい需要があり、そのためにいちいちKafkaを経由して書き込むのが面倒なのだという。そこで、Pull Based IngestionのソースとしてHiveテーブルを扱えるようにする仕組みを作ってくれんかと言われたので、作っている。
ここではdata prepperのiceberg sink/sourceの開発で覚えた、分散クエリエンジン的な仕組みの作り方が参考になっている。一方で、PBIの思想的にDriverノード的な仕組みを持たせられないのが難しいところで、その制約の中でどこまでのことができるか模索している感じだ。
また、この開発はHive ThriftやKerberos認証に向き合う良い機会にもなっている。
github.com
OpenSearch ISMへのSearch Only Action追加
reader/writer分離環境下で、ISMでローリングした過去のindexをsearch onlyに変更することで、リソース効率を最適化するActionを開発した。これは元々OpenSearchCon Japanで「こういうのできたらいいよね」と言ってたものを実現できたもので、登壇をきっかけに思いついた機能を実現して、コミュニティに届けることができとても嬉しい。
github.com
https://sched.co/2BLQ9
PyIcebergの同時実行制御最適化
PyIcebergのコミット競合時のハンドリングと、その前提となる整合性チェックの仕組みがSparkに比べて未熟な問題に取り組んだ。
github.com
PyIcebergでは、カタログへのコミットで競合が発生すると、データ競合の有無に関わらず無条件にabortする。ユーザ側でリトライを実装しても、データファイル作成を含むトランザクション全体をやり直す形になるので遅いし二次的な競合も起きやすい。また、更新内容の競合有無をユーザーの実装側で検出するのが困難なので、安全なリトライ処理を実装するのが難しいという問題もある。
そこで、コミット競合時の透過的なリトライと、リトライの前提となるデータ競合バリデーションをコミットフローに組み込むPRを作っている。リトライ時にはストレージ上のデータファイルを再利用してマニフェストだけ再生成するので、ユーザ側でトランザクション全体をやり直すより速い。バリデーション関数自体はコミュニティの人たちが実装してくれていたもので、自分はそれらをリトライループに統合する最後のピースを埋めた形になる。
競合が起きなくなるわけではないので、これで全部解決というわけではないが、少なくともユーザー目線では透過的にリトライができるようになるし、データファイルを使い回すことなどから、全体としてのスループットが上がりやすくなる。また、安全にリトライできるケースとデータが本当に矛盾しているケースの区別がつくようになるといったメリットもある。
Icebergの同時実行制御は以前いくつかブログを書いたり登壇したテーマでもあり、こうして実装面で貢献できるのは感慨深い。
speakerdeck.com
aws.amazon.com
aws.amazon.com
ほか、Data Prepperの開発中にテストデータをPyIcebergで作っていたらテストが通らなくて、調べたらPyIceberg側にバグがあったので直した。DELETEDマニフェストエントリのsnapshot_idが正しく設定されておらず、下流のIncrementalChangelogScanがファイルを見落としてCDCが壊れるというものだった。自分がData Prepperで作っているIceberg CDCの仕組みがなければ気づかなかったバグで、複数のプロジェクトを跨いで開発しているからこそ見つけられる問題というのがあるのだなと思った。 github.com
雑感
気になることにアレコレ手を出すうちに、opensearch-hadoopに始まり、Data Prepper、PyIceberg、OpenSearchコアと手を広げる形になった。ただ、こうして並べてみると「OpenSearchとIcebergの接点」みたいな共通項がなんとなく見えてくる気もする。意識していたわけではないが、結果的にその辺りを掘り続けていたらしい。
今気になっているのは、OpenSearchを「cloud-native」にしていく構想 ([RFC] Cloud-native OpenSearch · Issue #17957 · opensearch-project/OpenSearch · GitHub) と、Lucene以外のストレージフォーマットをプラガブルに扱えるようにする構想 ([RFC] OpenSearch Engine: Pluggable Component Bundling · Issue #20644 · opensearch-project/OpenSearch · GitHub) だ。どちらも自分がこれまで触ってきたpull-based ingestionやIceberg周りとの接点が多い。この辺りに関わっていけるといいなと思っている。
開発にはAIの力を借りていて、調査や実装の下地作りなどを手伝ってもらうことで、仕事の合間でもこれだけの量をこなせている。ただ、複雑な仕組みを作る場面ではAIは必ずしも万能とは言えない部分もある。ハイレベルな設計とミクロな実装の両面でツッコミどころがある場面も多く、手動で直している部分も多い。もっとも人間はAI以上に万能ではので、不完全な者同士、なんとか補い合いながら歩んでいる感じだ。
一方で、AIは新しい切り口やデザインを考えるのがまだあまり得意ではないとも感じる。たとえばData PrepperのIceberg sourceを作るにあたって、incremental changelog scanを使い、Data Prepperの分散処理機構に載せてCDCエンジンを組み立てるみたいな発想は、多分一定の指向性を与えなければAIからは自然に出てこない。上に挙げた他の取り組みについても、なかなかAIポン出しで実現するのは難しいと思う。各分野に詳しい人間が、その知識を使ってAIを操りながら何かを作る役割は、もうしばらく必要そうだ。
ちなみにこの記事自体を書くのにも一部AIの力を借りているが、イマイチしっくりくる文章が生成できず、結局8割以上を手動で書き直している。
OSS開発はAIの力を借りた上でも大変だ。作業するのは深夜や土日で、命を削ってやっている。大きなプロジェクトに深く関わるほど責任は重くなっているようにも感じていて、特にopensearch hadoopに関してはメンテナとしてソフトウェアを育て、広め、安全に使ってもらえるようにする巨大な責任を負っている。最近はサプライチェーン攻撃などもあり、気が抜けない。こんなに大変なのに、直接的には一銭にもならない。
では何故やっているのかと言われると、月並ながらやはり技術的なアイデアを提案し、形にして、ユーザーの課題を解くこと、コミュニティと共にソフトウェアを育てることへのやり甲斐ではないかと思う。世界に名だたる企業の人々からissueを通じて機能改善リクエストを受け取り、日々対応していく中で「オレの作ったソフトウェアが世界を支えているのだ」という幾らかの悦もないわけではない。
とはいえ、今のところOSS開発が仕事にほぼ関係がないので、これは何とかせねばならないと感じている。仕事でOSS開発がしたいとまでは言わないが、もう少しそれが活きやすい仕事はできないものか。今のところ完全に趣味でやっているとしか言いようがなく、この辺りはなんとかしたい。
色々と課題はあるが、去年の9件からここまで来られたのは素直に嬉しい。後半もこの調子でやっていきたい。
