はじめに
CosmosDBのバックアップに関しては「Azure Cosmos DB でのオンライン バックアップとオンデマンドのデータ復元」にある通り自動で取得されたものをサポートを使って戻す方法がありますがこれに頼りきるのは現実的ではありません。
手動で任意のタイミングに戻すには5/20に発表されたPITR（ポイントインタイムリストア）を利用したいわけですがいつ来るかわかりません・・・。
ということで今回はCosmosDBのバックアップをDataFactoryを使って取っていこうと思います。
DataFactoryとは？
フルマネージド型のETLツールで、バックエンドはSparkで動いておりFunctionsやBatch,Webhook,Databricksなど様々なサービスにイベントを起こすことも可能です。
AWSでいうとGlueですね。
イベントのソースにAWSのS3などがあったりとなかなか面白いですね。
バックアップ編
今回やろうとしていること
- CosmosDBの中身をコンテナ毎にjson.gzの形でエクスポートし、BlobStorageのYYYY-MM-DD仮想ディレクトリに配置します。
- 古い世代のバックアップファイルを削除します。
これを1日に1回実行し、失敗した場合はメールでアラートメールが送信されるようにしてみたいと思います。
前提事項
CosmosDBとバックアップ先のBlobStorageは準備できていることとします。
CosmosDBからのエクスポート＆BlobStorageへの格納の設定
DataFactoryをつくります。数分待つとデプロイできます。
「Author & Monitor」をクリックする
エディタが起動するので鉛筆マークをクリックします
CopyDataをクリックします。
名前を適当に付けて、1日1回起動するようにします。
「＋Create new connection」→「Azure CosmosDB(SQL API)」をクリックして、データソースを設定します。
バックアップするテーブルを選択します。何も考えず次へ次へ・・・
出力先のBlobStorageを設定します。同じように「＋Create new connection」→「Azure Blob Storage」を選択して出力先のデータソースを設定します。
output fileについての定義を行います
フォルダパスには以下のように記載してください。（ディレクトリ書いたんですけどなぜかうまく反映されないので後で設定します）
cosmosdb/@dataset().cw_fileName
jsonで圧縮形式(gzip)で保存する旨設定します。
マッピングの設定を行います。エラーがあれば解消します。
ログの設定を行います。
あとはサマリを確認して完了してください。
YYYY-MM-DDのディレクトリに出力したいので、DestinationDataset_xxxを選択し、FilePathを設定して「Publish all」をクリックします。
CosmosDBのエクスポートの動作確認
1日待つわけにはいかないのでパイプラインを選択して「Trigger now」を選択します。
少し待つとBlobにデータができています。
古いデータを削除してみます。
パイプラインを選択し、「Delete Activities」を選択します。
「Delete Activities」を選択して新しくSourceを設定します。
FilePathのディレクトリは以下のように指定します。今回は-1と指定していますが2日前のデータを削除したければ-2と指定してください
@adddays(utcnow(), -1, 'yyyy-MM-dd')
FilePathにWildCardで*を指定しておきます。
最後にパイプラインを繋げます
動作確認
BlobStorageに一日前のディレクトリを作成して実行してみましょう。
実行後に1日前のBlobデータが消えていることを確認しましょう
アラートを作成する
パイプラインが失敗したらアラートをあげるようにします。
パイプラインの失敗のカウントが1以上だったらアラートをあげるように設定します。
アラートグループの設定も必要に応じて行います。
失敗させてみる
先ほどのDeleteActivityですが、対象のBlobがなかった場合はエラーになりますので、1日前のデータを作成せずにパイプランを動かしてみましょう。
以下のようなメールが来ていれば成功です。
