まとめ、アンインストール方法

（これは「week-of-datomic」最終日の記事です）

これまで schema 管理、アプリケーションロジック、デプロイ、分析などいろいろな視点から  Datomic Cloud を使ってみましたが、今回は後片付けをしたいと思います。

Datomic Cloud は基本 CloudFormation で管理されていて、CloudFormation Stack を削除することでほぼ消えるのですが、手順と幾つか注意点をご紹介します。

CloudFormation Stack

少なからず依存関係があるので、削除する順番は以下のようになってます。
1. Query Group
2. Primary Compute
3. Storage

もし Query Group や Primary Compute を削除するとき以下のようなエラーが表示された場合は ENI の消し忘れがあったと思うので手動で該当する ENI（三つあるはず）を削除してください。

該当する ENI は「〜LambdaSecurityGroup~」に紐付いていますので手動で削除したら CloudFormation Stack をもう一回削除すると成功するはずです。

バックアップデーターの削除

まず Datomic Cloud の設計上 Query Group、Primary Compute や Storage などの stack はいつでも削除して再構築できるようになっているが、デフォルトではシステムを削除しても蓄積されているデータは残るように設定しています。おそらくシステムのアップグレードや構成を変更しやすいようにこのようになってます。

本番環境ではデータを削除するこはほぼないのですが、今回のように遊び終わった後の後片付けはある程度注意して手作業で残ったリソースを削除する必要があります。

削除する必要があるリソースはこちらです
・S3
・DynamoDB table
・EFS
・CloudWatch log group
・DynamoDB scalable targets
詳しくは公式ドキュメントをご確認ください。
https://docs.datomic.com/cloud/operation/deleting.html#deleting-storage

コスト

12/1 から 12/7 にかけて Datomic Cloud を試してましたがコストは以下のような構成なっております。Access Gateway のスペックを落としたらもう少し安くなってましたが、Analytic が使いたかったのでこのような形になりました。

トータルで 1,300 円前後なので一日約 200 円の計算となります。

まとめ

Datomic は schema の表現力が高く、Query Group によるアプリケーションの分離が可能で、過去の状態の再現や Presto エンジンによる分析機能まで対応されて、今までリレーショナルデータベースでモヤモヤしていたところを解決してくれました。特に Datomic Cloud は AWS を前提としたベストプラクティスが盛り込まれて、自分たちで DevOps を頑張らなくてもスケールしやすいアーキテクチャーが手に入るようになります。

「このご時世にクローズドの商用データベース？」と思われる方もいると思いますが、今回 Datomic Cloud を使ってみて楽しかったし、ポテンシャルも感じたので、いずれは Aurora、Cloud SQL、Spanner、DynamoDB、Firebase これら成功していると言われているクローズドソースの商用データベースの仲間に入れたらと思います。

ちなみに Datomic のモデルを継承したオープンソースプロジェクトもあるので今後の発展を期待しております。

Crux — Open Time Store