Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

はじめに — この層ではコードより先に条件が変わります
1. Redis
2. ElasticsearchとKibana
3. MongoDB
4. KafkaのZooKeeper依存
5. Apache Sqoop
6. Apache Oozie
7. Apache Giraph
8. Apache Tajo
9. RethinkDB
10. PrestoSQL — 名前が変わった例
まとめ — データ層で見るべき三つのシグナル
あわせて読みたい
シリーズ

はじめに — この層ではコードより先に条件が変わります

データストアは置き換えコストが最も大きい層です。だからこそここでは技術的な優劣よりも配布条件の変化が移動を生みます。ライセンスが変わり、フォークが生まれ、財団が変わります。

以下の項目は、公式発表、リポジトリの状態、Apache Atticの記録のように日付の付いた事実だけを根拠にしています。ライセンス変更は誰が何をどこからどこへ変えたかという事実だけを書き、動機は推測しません。

1. Redis

何だったのか — BSD 3-Clauseで配布されていたインメモリデータストアです。
なぜ当時は正しかったのか — いまも正しいままです。これは技術ではなく配布条件が変わった事例です。
何が変わったのか — 2024年3月20日の発表により、Redis 7.4からBSD 3-Clauseに代えてRSALv2とSSPLv1のデュアルライセンスへ移行しました。同じ記事は、この変更によりRedisがOSIの定義するオープンソースではなくなることを明示的に認め、既存リリースには遡及しないと述べています。その後、2025年5月1日の発表でRedis 8からOSI承認ライセンスであるAGPLv3が選択肢として追加されました。
何がその場所に来たのか — Valkeyです。BSDライセンスの高性能なキーバリューストアとして紹介され、Linux Foundationが運営しています。
何を残したのか — Redisのプロトコルとデータ構造モデルが事実上の業界インターフェースになりました。フォークがいずれもこれを維持していることがその証拠です。
いまでも使うのが正しい場合 — ほとんどの利用者です。2025年の発表以降はAGPLv3の選択肢があるため、OSIライセンスを求める組織でも条件を満たせます。

2. ElasticsearchとKibana

何だったのか — Apache 2.0で配布されていた検索・分析エンジンと可視化ツールです。
なぜ当時は正しかったのか — 転置インデックスによる検索を分散で運用する標準的な方法を提供しました。
何が変わったのか — Elasticが2021年1月14日の発表で7.11からSSPLとElastic Licenseのデュアルライセンスへ移行しました。その後2024年8月29日の発表でAGPLを選択肢として追加し、既存のライセンスをなくすのではなく一つ加えるのだと述べました。
何がその場所に来たのか — OpenSearchです。2021年1月にフォークが発表され、同年7月に1.0がApache 2.0で公開され、その後Linux Foundation傘下のOpenSearchソフトウェア財団へ移りました。
何を残したのか — クエリDSLとインデックス運用の慣行が両系統で維持され、事実上の共通インターフェースになりました。
いまでも使うのが正しい場合 — ほとんどです。AGPLの選択肢が加わったのでライセンス要件はおおむね解消します。ベンダー中立性が調達要件の組織はフォーク側が合うこともあります。

3. MongoDB

何だったのか — AGPL v3で配布されていたドキュメントデータベースです。
なぜ当時は正しかったのか — スキーマの柔軟性が実際の要求だった時期があり、その要求を最もよく満たした製品でした。
何が変わったのか — 公式FAQによれば、2018年10月16日以降のリリースからSSPLへ移行しました。SSPLはプログラムをサービスとして第三者に提供する場合にそのサービスを構成するソースの公開を求めますが、内部利用のみにはこの条項は適用されません。
何がその場所に来たのか — この場合は支配的なフォークが形成されませんでした。代わりにリレーショナルデータベースのドキュメント型サポートが代替として定着しました。
何を残したのか — SSPLというライセンスそのものです。その後ほかのプロジェクトが同じライセンスを採用し、一つの流れになりました。
いまでも使うのが正しい場合 — 内部利用ならFAQの基準で問題ありません。マネージドサービスを第三者に提供する場合だけ条項を確認する必要があります。

4. KafkaのZooKeeper依存

何だったのか — Kafkaがブローカー一覧やパーティションのメタデータを保存するために併せて運用していた別の合意システムです。
なぜ当時は正しかったのか — 検証済みの合意実装を新たに作らず借りるのは、初期設計としては合理的な判断でした。
何が変わったのか — Kafka 4.0.0のリリース告知が2025年3月18日付で、4.0がApache ZooKeeperなしで完全に動作する最初のメジャーリリースだと述べています。既定はKRaftモードです。
何がその場所に来たのか — KRaftです。メタデータのクォーラムがKafkaのブローカー内部に入りました。
何を残したのか — ZooKeeperが証明したのは合意ベースの調整サービスというカテゴリそのものです。多くのシステムがこのカテゴリに依存して成長し、その多くが後に自前実装へ移りました。ZooKeeperプロジェクト自体は存続しています。
いまでも使うのが正しい場合 — Kafka 3.xを運用中なら急ぐ必要はありません。ただし4.0へ上げるときに移行が必須経路になります。

5. Apache Sqoop

何だったのか — リレーショナルデータベースとHadoopの間の大量データ転送ツールです。
なぜ当時は正しかったのか — バッチ枠に合わせてテーブルを丸ごと移す作業は実際の業務であり、それを並列化したツールでした。
何が変わったのか — Atticの記録によれば2012年3月にトップレベルプロジェクトとなり、2021年6月に引退、同年7月にAtticへの移管が完了しました。
何がその場所に来たのか — SparkやFlinkベースの取り込みジョブと、変更データキャプチャ方式のパイプラインです。
何を残したのか — スキーマを読んで並列分割を自動決定するというアプローチです。現代の取り込みツールも同じ問題を同じ方法で解いています。
いまでも使うのが正しい場合 — すでに回っているバッチを維持する場合だけです。Atticのプロジェクトは新しいリリースが出ません。

6. Apache Oozie

何だったのか — Hadoopジョブのためのワークフロースケジューラーです。
なぜ当時は正しかったのか — ジョブ間の依存を宣言で表し、リトライと時刻ベースの実行を付けるという発想は、いまのワークフローツールの原型です。
何が変わったのか — Atticの記録によれば2012年8月にトップレベルプロジェクトとなり、2025年2月に引退、2025年4月に移管が完了しました。
何がその場所に来たのか — Airflowをはじめとするコードベースのワークフローオーケストレーターです。
何を残したのか — バッチを有向非巡回グラフで表すモデルです。XMLがPythonに変わっただけで構造は同じです。
いまでも使うのが正しい場合 — 既存ワークフローの維持だけです。

7. Apache Giraph

何だったのか — 大規模な反復グラフ処理システムです。
なぜ当時は正しかったのか — 頂点中心のプログラミングモデルは、ソーシャルグラフの計算を数十億辺の規模まで押し上げました。
何が変わったのか — Atticの記録によれば2012年5月にトップレベルプロジェクトとなり、2023年9月に引退、2024年2月に移管が完了しました。
何がその場所に来たのか — 汎用分散エンジン上のグラフライブラリと、専用のグラフデータベースです。
何を残したのか — 頂点中心の計算モデルとスーパーステップという概念です。後続のフレームワークがそのまま採用しました。
いまでも使うのが正しい場合 — ありません。

8. Apache Tajo

何だったのか — Hadoop上で動作するデータウェアハウスシステムです。
なぜ当時は正しかったのか — バッチエンジンを経由せず分散SQLを直接実行するという方向は、その後の業界全体が進んだ道です。
何が変わったのか — Atticの記録によれば2014年3月にトップレベルプロジェクトとなり、2020年9月に引退、2021年4月に移管が完了しました。
何がその場所に来たのか — TrinoやSpark SQL系、そしてクラウドウェアハウスです。
何を残したのか — 分散SQLエンジンというカテゴリが正しかったという確認と、韓国の開発者コミュニティがApacheのトップレベルプロジェクトを率いた記録です。
いまでも使うのが正しい場合 — ありません。

9. RethinkDB

何だったのか — リアルタイムの変更購読を一級の機能として提供したドキュメントデータベースです。
なぜ当時は正しかったのか — クエリ結果の変化をアプリケーションが購読するという発想は当時としては先を行っていました。
何が変わったのか — 2017年2月6日の告知によれば、会社は閉じたもののCNCFがソースコードの権利を購入してLinux Foundationへ寄贈し、コードは寛容なApache 2.0ライセンスで再配布されました。同じ記事はプロジェクトが健在で開発が途切れずに続けられると述べています。
何がその場所に来たのか — 変更ストリームを提供する主流データベースと、リアルタイム同期を提供するバックエンドサービスです。
何を残したのか — 変更購読という機能カテゴリと、会社が閉じてもコードとコミュニティは財団へ引き継げるという先例です。
いまでも使うのが正しい場合 — すでに運用中のシステムです。新規なら代替はずっと多くあります。

10. PrestoSQL — 名前が変わった例

何だったのか — 分散SQLクエリエンジンの一系統です。
なぜ当時は正しかったのか — いまも正しいままです。これは技術ではなく名前が変わった事例です。
何が変わったのか — 2020年12月27日の告知で、元の開発者たちがプロジェクト名をTrinoに変えると述べました。告知によれば商標の問題がきっかけです。
何がその場所に来たのか — Trinoです。同じ人たちが同じコードベースを継いでいます。
何を残したのか — プロジェクト名と商標がコードとは別の資産であるという事実と、その分離が実際の運用に影響するという事例です。
いまでも使うのが正しい場合 — 名前が変わっただけなのでそのまま使えます。文書を検索すると二つの名前が混ざる点だけ知っておけば十分です。

まとめ — データ層で見るべき三つのシグナル

第一に、ライセンス条項とその変更履歴です。この層ではコードの品質より先にこの条項が移動を生みます。ただしRedisとElasticの事例が示すように、方向は一方通行でもありません。両プロジェクトともその後OSI承認ライセンスを選択肢として戻しました。

第二に、財団への所属です。RethinkDBは会社が消えた後も財団への移管で生き残り、Apache Atticの記録は引退日を公開文書として残します。ガバナンスが文書化されたプロジェクトは、少なくとも状態を確認できます。

第三に、本体が外部依存を吸収する流れです。KafkaがZooKeeperを外したように、運用負担の大きい外部依存は結局本体に取り込まれるか外されます。いま運用中のシステムに別途動かしている調整サービスがあるなら、そのロードマップを確認しておく価値があります。

状態情報は2026-08-12に直接確認しました。プロジェクトは再び活発になることもあるので、最新の状態はご自身で確認してください。