はじめに

CosmosDBのバックアップに関しては「Azure Cosmos DB でのオンラインバックアップとオンデマンドのデータ復元」にある通り自動で取得されたものをサポートを使って戻す方法がありますがこれに頼りきるのは現実的ではありません。

手動で任意のタイミングに戻すには5/20に発表されたPITR（ポイントインタイムリストア）を利用したいわけですがいつ来るかわかりません・・・。

ということで今回はCosmosDBのバックアップをDataFactoryを使って取っていこうと思います。

DataFactoryとは？

フルマネージド型のETLツールで、バックエンドはSparkで動いておりFunctionsやBatch,Webhook,Databricksなど様々なサービスにイベントを起こすことも可能です。
AWSでいうとGlueですね。
イベントのソースにAWSのS3などがあったりとなかなか面白いですね。

これを1日に1回実行し、失敗した場合はメールでアラートメールが送信されるようにしてみたいと思います。

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」をクリックします。

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日前のデータを作成せずにパイプランを動かしてみましょう。

以下のようなメールが来ていれば成功です。