アプリケーションロジック（Ions）

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

前回ではデータベースのテータ構造（Schema）を定義するところまで作りましたが、今回は API を公開して外部からアクセスできるようにしたいと思います。使っているデータセットは「MusicBrainz」、音楽業界のアーティストと曲のデータベースです。

アーキテクチャー

Datomic Cloud は独自の最適化されたアーキテクチャーで構成されています。一つのアプリケーションは複数の Ion（Lambda みたいな関数）によって構成されていて、Query Group（コンピュテーションリソース、キャッシュ、NLB）にデプロイされることによって VPC 内で動きます。

外部から Ion を呼び出すためには AWS Lambda を経由するか、または AWS API Gateway から直接 NLB につなげることで外部公開できるようになります。

サンプルコード

今回作成したコードを公開しております。

hden/mbrainz

よかったらコードを確認しながら読んでみてください。今回はコスト節約のため Solo topology をデプロイしてます。Solo ではコスト節約のため NLB が省略されていて HTTP Direct が使えないので API Gateway はスキップします。

開発環境

今回はフォルダー構造や設定ファイルの書き方などを少し構造化したいので Duct フレームワークを Ion 用に改造しました。なので Ion でありつつも Duct 風の REPL ベース開発フロー、フォルダー構造、及び設定ファイルが存在しますが、Duct 以外のフレームワークも存在しますので好きなものを選べばいいと思います。

pedestal/pedestal.ions

今回はシンプルにアーティストの gid (UUID) から名前などの詳細情報を取得する ion を書きますが、データベースのアクセス層（Boundary）、ハンドラー、ルーティング（duct/module.ataraxy）などをあらかじめ用意しておりますので、ある程度まとまったコードベースも同じ構造で作れると思います。

Revision

Ion のデプロイは git をベースにしているのでまずは手元の集計をコミットします。「git status」コマンドで「nothing to commit, working tree clean」が表示されたら OK です。

そこから push コマンドを使って手元のコードをアップロードしましょう。

clojure -A:ion-dev '{:op :push :creds-profile "datomic" :region "ap-northeast-1"}'

「:creds-profile」キーは AWS CLI のプロファイルをしてできますので複数のプロファイルを使っている場合は指定します。

「:region」キーは Datomic Cloud クラスターの AWS のリージョンを指定します。僕は東京リージョンと使っているので「ap-northeast-1」としてします。

成功すれば長いメッセージの最後に以下のような文字が表示されます

:deploy-command
"clojure -A:ion-dev '{:op :deploy, :group falcon-primary-compute, :rev \"db69cc39a1a2a2d99080291cbb80f45f7130be73\", :creds-profile \"datomic\", :region \"ap-northeast-1\"}'"

これはないを意味しているかというと git の「de8e06e38e10c370b1eacc21c73e01ce5931247a」コミットをクラスターにアップロードしたので同じ ID でデプロイできるということです。

Deployment

先ほど表示されたデプロイコマンドを使って revision を実際のクラスターにデプロイしましょう。

clojure -A:ion-dev '{:op :deploy, :group falcon-primary-compute, :rev "db69cc39a1a2a2d99080291cbb80f45f7130be73" :creds-profile "datomic" :region "ap-northeast-1"}'

成功すれば AWS CodeDeploy の ARN が表示されるので AWS コンソールで進捗を確認するか、または以下のコマンで確認します。

clojure -A:ion-dev '{:op :deploy-status, :execution-arn arn:aws:states:ap-northeast-1:002932404910:execution:datomic-falcon-primary-compute:falcon-primary-compute-db69cc39a1a2a2d99080291cbb80f45f7130be73-1575531446460, :creds-profile "datomic", :region "ap-northeast-1"}'

このようなメッセージが表示されたら成功です。

{:deploy-status "SUCCEEDED", :code-deploy-status "SUCCEEDED"}

ここででプリロイされたコードは Primary Compute または Query Group の中でオートスケールするのでリソースの消費量が変化するタイプのタスクにも対応的ます。しかも Datomic は様々なイベントやログを CloudWatch に書き込むのでモニタリングやログ分析もしやすように設計されております。

Lambda

先ほどデプロイした Lambda を叩いて確認しましょう。適当なアーティストの gid をシードデータからコピーして渡します。

aws --profile datomic --region ap-northeast-1 lambda invoke --function-name falcon-primary-compute-get-artist-by-gid --payload '"d34eef69-c852-4bc6-93aa-69d0a0255ee1"' /dev/stdout

Lambda へのアクセス権限は AWS IAM で管理していますので、案件の内容によってはきめ細かいアクセスコントロールを設定できます。問題なければ以下のようなメッセージが表示されます。

{:db/id 23599917578584520,
:artist/gid #uuid "d34eef69-c852-4bc6-93aa-69d0a0255ee1",
:artist/name "Alan Lee Jazz Quartet",
:artist/sortName "Alan Lee Jazz Quartet"}
{
   "StatusCode": 200,
   "ExecutedVersion": "$LATEST"
}

上半分が今回の Ion の戻り値で下半分が AWS  Lambda のメタデータです。

継続的な開発環境

さて、今回はアプリケーションの構造やデプロイメントを少し触ってみましたが、ある程度規模がある開発案件でしたら CI/CD を回すと思います。今回は Duct の思想に従ってデータベースのアクセス層を Boundary として切り離しているので Unit test は比較的に書きやすいと思います。

現状イメージしているフローですと、ローカルでは REPL を使って開発を進めたら Pull-request を作って CI で確認します。問題なければ何かしらのブランチにマージしてデプロイします。

Datomic の設計上一つの revision は複数の環境（Query Group）にデプロイできるので本番環境とカナリアなどいくつか Query Group を作るといいかもしれません。

（ありがとうございました、次回は Analytics をやってみたいと思います）