sqldefとkin-openapiにコントリビュートした話

こんにちは、バックエンド基盤チームの徳森です。

バックエンド基盤チームでは、バックエンドエンジニアの生産性向上やコスト削減を目的に、エンジニア主導で課題の発見や解決を行っています。

今回は、チームでの具体的な業務内容の一部として、二つのOSSにコントリビュートした話を紹介します。

要約

バックエンド基盤チームの定常業務の一つに、依存しているGoライブラリの更新があります。

私たちのプロジェクトではRenovateを導入しているため、更新のためのプルリクエストは自動で作成されます。基本的には変更内容を確認してマージするだけで完了するのですが、破壊的変更や予期せぬリグレッションの発生により、詳細な調査が必要になることもあります。

その調査の結果、依存先に修正が必要だと判断した場合は、積極的にコントリビューションを行っています。

今回ご紹介するのは、そうした日々の更新業務から生まれた二つの貢献事例です。

一つ目は、Go言語でOpenAPI Specificationを扱うためのライブラリ、getkin/kin-openapiです。

このライブラリは、HTTPリクエストがOpenAPI定義に準拠しているかを検証する機能などを提供しており、ミラティブではAPIリクエストやレスポンス、そしてPub/Subメッセージのスキーマ検証に活用しています。

今回のコントリビュートのきっかけは、ライブラリのバージョンアップ（v0.133.0）に伴うリグレッションでした。

このバージョンでは、multipart/form-dataリクエスト内のtext/plainな値の扱いに関する修正が行われたのですが、その内部処理において、入力値が空文字列 ("") の場合に型定義に関わらず一律でnilを返す実装を含んでいました。

その結果、意図した空文字列であっても、nilとして解釈されてしまい、バリデーションエラーとなる事象が発生しました。スキーマ側でnullableを指定することでも回避は可能ですが、OpenAPI 3.0の仕様¹では空文字列とnullは明確に区別されます。

そこで、仕様に準拠するように修正を行いました。

二つ目は、sqldef/sqldefです。

これは複数のデータベースに対応したスキーマ管理ツールで、SQLファイルに記述されたDDLを元に、データベーススキーマをあるべき状態へとマイグレーションします。

sqldefは通常、CLIツールとして提供されるバイナリを使用しますが、ミラティブではGoのライブラリとして組み込んで利用しています。

これは、ミラティブがスキーマ定義を標準のSQLファイルではなく、独自のYAMLフォーマットで行っているためです。 YAML定義から「あるべきスキーマ」を導出し、現在のデータベーススキーマとの差分検出やマイグレーションSQLの生成を行う処理に活用しています。

sqldefに対しては、二つのプルリクエストを提出しました。

KEY_BLOCK_SIZE はyaccの定義上、CREATE INDEX のオプションとしてのみ指定可能でしたが、これをMySQLの挙動に合わせて、テーブル作成時にも使えるよう定義を追記しました。

Goのモジュール規約では、メジャーバージョンが2以上の場合、モジュールパスに /v2 などのバージョンを示すsuffixを付与する必要があります。

sqldefは主にバイナリとして利用されることを想定していたため、この規約に対応していませんでした。ミラティブでライブラリとして安定して利用し続けるため、この修正を提案し、取り入れていただきました。

本記事では、バックエンド基盤チームの定常業務から生まれた、OSSへのコントリビュート事例をご紹介しました。

私たちのチームでは、ライブラリの更新を定常的に行っているため、リグレッションの検知からアップストリームへの還元までを、業務の一環として自然に行える文化があります。過去にはこの文化のもと、別のメンバーがGo本体へのコントリビュートを行った実績もあります。²

自身が利用しているOSSへの貢献は、エンジニアとしてのやりがいはもちろん、コードリーディングを通じて設計思想や内部構造を深く理解する絶好の機会でもあります。

そして何より、日々素晴らしいエコシステムを維持・開発してくださっているメンテナーの方々へ、感謝とリスペクトを伝える一つの手段でもあります。

ミラティブでは、この記事で紹介したバックエンド基盤チームをはじめ、様々なポジションで新しい仲間を募集しています。

もし私たちのチームや取り組みに興味を持っていただけましたら、ぜひ採用ページを覗いてみてください。