紆余曲折ありましてPostgreSQLを卒業することになりました
本題からずれるので詳細は割愛しますが、これまでPostgreSQL管理していたデータを別のストレージで管理する必要が出てきました
管理対象のデータの性質は以下の通り
- サービスが成長すればするほどデータ量が大幅に増加する
- ユーザー操作はReadしか行われない
- データは挿入か削除のみで更新が行われない
移行先
管理対象のデータの性質を考えると、大量のデータを扱うことができるスケーラブルなストレージと強力でスケールする検索エンジンを兼ね備えたDBがほしい。
検討の結果、検索エンジンとしてAthenaを使うこととなりました
PostgreSQL
Amazon AthenaはOSSであるtrinoを利用して実装されている検索エンジンです。検索エンジンでしかないので、これだけではPostgreSQLの代替になりません。
代替探しという意味で、PostgreSQLの内部を分解してみると以下のように書けます（正確にPostgreSQLのアーキテクチャを表現しているわけではありませんが、PostgreSLl => Athenaの移行を理解する上では十分です）
対して、Athenaは同様に分解すると以下のようになります。
つまり、PostgreSQLの代替としてAthenaを利用するためにはデータを貯めておくストレージとスキーマ情報などを保存するカタログの二つを別で用意する必要があります。
それらを補うと以下のような構成になります。
ローカル環境の選択肢
ローカル開発環境を作るにあたって、選択肢は以下の二つがありました。
- LocalStackを使う
- 自作する
LocalStackを利用すればかなり簡単にローカル環境を手に入れられるわけですが、今回はコスト面で自作することとしました
ローカル開発環境作成
AWS謹製のDockerイメージなどが公開されていればいいのですが、残念ながらAthenaもGlue Catalogも、S3ですらそのようなものはありません。（今回は登場しませんが、Glue Jobに関しては謹製のDockerイメージが存在します）
そこで、必要なコンポーネントをOSSで用意するか一から自作する必要があります。
AWSサービスとOSSとの対応は次の通りです。
| AWSサービス | OSS |
|---|---|
| Athena | Trino |
| Glue Catalog | HIVEメタストア |
| S3 | MinIO |
そして、実際に作成したシステムが以下になります。
リポジトリ
client_serviceはとりあえず何か必要だったので作成した、程度です。
全くもってAthenaのインターフェースになっていません。
対応するPRお待ちしております