はじめまして。TIGの藤野です。
私はフューチャー入社前から長年OSS開発者として、ASF（Apache Software Foundation）のメンバ、Tomcatのコミッター／PMCメンバーを務めてきました。
今日は秋のブログ週間連載の第8弾として、私がプロジェクト案件対応を通じて行ったOSSコミュニティへフィードバックについての2つのお話をしたいと思います。
①プロジェクトで出た問題をコミュニティへフィードバックした話
背景
あるプロジェクト案件で以下の要件がありました。
- Tomcatをクラスタリングする
- HTTPセッションをDBに格納する
- 但し、スティッキーセッションは使えない
要件実現の為、開発チームはTomcatのセッション管理にPersistenceManagerを利用していました。
このPersistenceManagerは、定期的実行によるオンメモリの生存期間の長い古いセッションのバックアップや、オンメモリのセッション数が閾値を超えた場合にセッションをDBへ格納する為の機能で、クラスタリングされたTomcatでセッションの情報をDBを介して共有させることができます。
問題
しかし、この案件では諸般の事情によりスティッキーセッションを採用していない為、リクエストの度にリクエストするTomcatが切り替わります。
そのためリクエストの度にDBから最新のセッション情報を取得する必要がありました。
上記の通り、PersistenceManagerは定期実行によってセッションをDBに格納する為、こういったリクエストの度に最新セッションを取得するような要件には対応していません。そこで開発チームは案件の要件を満たす為に、PersistenceManagerの定期実行間隔や、セッションがバックアップされるまでの期間を極端に短くするなど、かなり特異な設定で要件を無理やり実現させ、擬似的にセッションをDBに格納していました。もちろんこれは本来の使い方ではありません。
その結果、タイミングによって正しいセッションが取れなかったりするなどの不具合が発生していました。
対応
そこで、この問題の対応方法についての相談が私に来ました。私が詳細をヒアリングした際、開発チームは問題の原因をTomcatのソースコードレベルで把握しており、その対処方法を相談したいとのことでした。
したがって、私は対処方法として本来の使い方ではない特異な設定で無理やり要件を実現させるのではなく、PersistentValveの利用を提案しました。PersistentValveではスティッキーセッションが無効な状況下において、リクエスト時にセッション情報をDBから取得し、レスポンス時にDBに格納することができます。
このように対処方法は非常にシンプルでした。
開発チームはPersistentValveを利用しなかったか？
ではなぜ開発チームはPersistentValveを利用しなかったのでしょうか？
答えは単純で、PersistentValveはソースコード上は存在するものの、公式のドキュメントに関連するドキュメントが存在しなかった為です。ドキュメントが存在しないのであれば、開発チームは機能の存在を知ることなど到底出来ません。もちろんドキュメントが存在しないことは良い事ではないですが、ボランティアベースのコミュニティ開発では稀に存在するケースです。
私は、プロジェクトがこういったドキュメント化されていない機能を使うと、顧客から何やら秘密の珍しい機能を利用しているのではないかと思われてしまう可能性もあると思い、PersistentValveのドキュメントを作成し、コミュニティへフィードバックを行うことにしました。ドキュメント化することで特定の人のみが知っている秘密の機能ではなく、公式の機能として誰でも利用できるようになります。これでプロジェクトは、ごく一般的にドキュメンテーションされている機能を使っていることになりました。
PersistentValveを利用する上で新たな要件が出てきた
また、PersistentValveを利用する上で新たな要件が出てきました。
それはある特定のリクエストについてはDBからのセッション取得/格納を行いたくないケースが存在するというものでした。PersistentValveはセッションを利用する全てのリクエストに対してセッション取得/格納を行うため、そういった機能は実装していません。議論の後、特定のリクエストに対してはPersistentValveの機能をバイパスする処理を実装することにしました。
しかしその結果、プロジェクトの独自のおれおれパッチが適用されたPersistentValveになってしまい、本家のコミュニティ版のPersistentValveとは別ものになってしまいました。
そこで私は、案件用に実装したパッチをコミュニティにフィードバックすることを検討しました。検討する上で以下を判断材料にしました。
- 追加する機能が、プロジェクト固有要件ではなく一般的に利用可能であるものか？
- アップストリームに取り込んでも問題ない品質か？
今回実装したパッチは両方を満たしていたので、コミュニティにフィードバックしました。
結果として、コミュニティ版とプロジェクト版で機能的に互換性が保たれていることになり、将来のバージョンアップ時にプロジェクト版をコミュニティ版に切り替えることも可能です。これにより、Tomcatの機能をカスタマイズしたおれおれパッチを永久的にメンテナンスする必要もなくなりました。こちらに関しては開発チームから大変喜ばれました。
後日談
テストを進めるとマルチスレッド状況下でプロジェクトで拡張したPersistentValveでエラーが発生することが判明しました。
再び相談を受けた私は問題を調査し、発生しているエラーはプロジェクトが新規に取り込んだものではなく、Tomcatの既存バグであることが判明しました。
もちろん私はコミュニティとプロジェクトの両方に改修パッチをいれ、今でもコミュニティ版とプロジェクト版で互換性が保たれています。
②複数プロジェクトで追加した機能をコミュニティへフィードバックした話
問題
構成は良くあるSpringBootをバックエンドにAPIサーバとする構成です。フロントエンドはバックエンドからのレスポンスはJSONを期待しています。
私は、このバックエンドのAPIサーバにある特定のリクエストを投げると、TomcatのデフォルトのエラーページがHTMLでレスポンスされてしまうという相談を受けました。
原因
調査した結果、エラーになること自体はTomcatの仕様通り、正確には特定のリクエストがRFC違反のリクエストなのでエラーになると回答しました。しかし、エラーになるのは仕方がないが、一部のエラーのみHTMLでレスポンスされるすっきりしない構成になってしまう為、HTMLを返却するのはなんとかしてほしいと追加依頼を受けました。
なお、エラーがHTMLが返却される原因は、通常、SpringBoot/アプリケーションレベルでのエラーは基本的にSpringBootの機能によってハンドリング可能です。つまり、基本的に全てJSONレスポンスで返却可能です。しかし、組込みTomcatのレベル、つまりSpringBootに組み込まれたTomcatでエラーとなってしまった場合には、SpringBootまでリクエストが届かない為、SpringBootの機能でエラーハンドリングできない。その結果、TomcatのデフォルトのエラーページがHTMLとして返却されるというものです。
対応
そこで私は、SpringBootの組込みTomcatのカスタマイズ処理で、エラーHTMLをレスポンスする処理をJSONを返却する処理に置き換えることで対応しました。
また、本ケースと同じような問題が別プロジェクトでもあり、私は同様の仕組みを採用しました。
この二つのプロジェクト案件で対応した機能はコミュニティにあっても良いものだと思ったので、私は、Tomcatコミュニティにフィードバックを行い、TomcatのデフォルトエラーページをJSONレスポンスとして返却する機能を追加することにしました。
その結果、将来的に設定を少し変えれば、プロジェクトのおれおれパッチからコミュニティ版へ切り替えることを可能にしています。
最後に
今回は私が行ったプロジェクト案件からコミュニティへフィードバックを行った話を紹介させていただきました。
- 特異な設定で頑張って機能を実現するのではなく、公開された機能でやりましょう
- ドキュメントがないのであれば作りましょう
- 足りない機能はプロジェクトの独自実装で終わるのでなく、一般利用可能ならコミュニティへフィードバックしましょう。
そうすればコミュニティとプロジェクトで機能的で互換性が保たれるので、おれおれパッチのメンテナンスから解放されます - プロジェクト案件で作成した機能が良いものであれば、コミュニティへフィードバックしましょう
私自身、OSS開発者として10年以上活動していますので、こういったOSS活動は慣れているのもあり行いやすいのかもしれません。ですがこういった活動が出来るITコンサルタントを増やしていくことで、会社としてOSSの貢献につながるのではと思います。会社もコミュニティもWin-Winになります。
これまでの単にOSSを利用し、その恩恵のみを受けるだけではなく、利用するOSSへの貢献することもやっていく。今は一部の人がやっているOSS活動をフューチャの多くのITコンサルタントが当たり前のように出来ているみたいに。フューチャがこれまで以上にOSS企業として成長していけてらよいなぁと思います。
そんなわけで、まだまだ駆け出しではありますが仲間達と社内にOSS活動タスクフォースを立ち上げました。こちらの詳細に関しては近日公開予定です。