はじめに

前回の記事ではAstra Control Service(以下、ACS)にEKS上にデプロイしたWordPressアプリケーションを登録しました。
今回はそのアプリケーションに対してスナップショットならびにバックアップの取得を行なっていきます。

Astra Control Service(ACS)の導入
Astra Control Service(ACS)の使い方
1. アプリケーションの登録
2. アプリケーションのスナップショット&バックアップ ←イマココ
3. アプリケーションのリストア&クローニング

前回までのおさらい

検証環境全体の構成図はこちら

前回記事でEKSクラスタ上にWordPressをデプロイし、テスト用データとしてブログ記事を投稿しました。
このブログ記事などのアプリケーションデータはCSIドライバーであるAstra Tridentを介して、バックエンドストレージであるAmazon FSx for NetApp ONTAPに格納されています。

またACS上ではEKSクラスタならびにアプリケーションの登録が完了し、データ保護を行う準備が整っています。

スナップショットとバックアップの違い

実際に機能を使う前にACSにおけるスナップショットとバックアップの違いをまとめておきます。

比較項目	スナップショット	バックアップ
保護されるデータ	アプリ構成情報＋ PV内のデータ	アプリ構成情報＋ PV内のデータ
取得にかかる時間	短い	(スナップショットと比較すると)長い
データ格納先	クラスタローカル	外部のS3ストレージ
リストア先	同一k8sクラスタ内の別のnamespace	同一k8sクラスタ内の別のnamespace または別のk8sクラスタ
PV削除時の復旧可否	不可	可

ポイントになりそうなのはバックアップ対象のPV自体が破損または削除されてしまった場合にはスナップショットからの復旧はできないという点でしょうか。
DRやクラスタ間のアプリケーション移行などのユースケースではバックアップを選択する必要があります。

スナップショット&バックアップしてみた

ここからが本題です。

アプリケーションのオンデマンドスナップショット

まずはACSにログインし、Applicationsメニューから前回登録したアプリケーションの管理画面を開きます。

Data protectionのタブからCreate snapshotをクリックします。

指定する必要があるパラメータは取得するスナップショットの名前だけでした（今回はデフォルト値）

スナップショットが取得できるとこんな感じです。スナップショット作成開始から完了まで数十秒くらいでした。

スナップショット機能の仕様について少し掘り下げると、PVのデータのバックアップにはk8sのvolumeSnapshotの仕組みが使われています。
上記でお伝えした「元PVが削除されるとデータ復旧できない」というのはこの仕様によるものですね。

ちなみにvolumeSnapshot作成時に使用しているvolumeSnapshotClassですが、こちらは私自ら作成したものではなくACSにクラスタを登録した時点で自動作成されていたものです。
CSIスナップショッターとしてAstra Trident(csi.trident.netapp.io)が指定されています。

試しにk8sクラスタの中身を覗いてみます。

# スナップショット機能によって作成されたvolumeSnapshotの一覧を確認
$ kubectl get volumesnapshot -n prod
NAME                                                                                 READYTOUSE   SOURCEPVC                   SOURCESNAPSHOTCONTENT   RESTORESIZE   SNAPSHOTCLASS                            SNAPSHOTCONTENT                                    CREATIONTIME   AGE
pvc-2bc478fc-9bea-4374-bc18-506810c579aa-snap-18d88514-12fc-4667-9123-f92ab1819292   true         my-release-wordpress                                202512Ki      astra-netapp-csi-trident-netapp-io-vsc   snapcontent-fe7d0de8-1465-4bab-b24a-597ddcc01bdd   4m10s          4m10s
pvc-4c2ea6b2-1f97-42fd-b342-3100db04907c-snap-18d88514-12fc-4667-9123-f92ab1819292   true         data-my-release-mariadb-0                           38316Ki       astra-netapp-csi-trident-netapp-io-vsc   snapcontent-87efbb36-d61b-4baf-a281-d2c7347a44b8   4m10s          4m10s

# ACSが自動作成したvolumeSnapshotClassの中身を確認
$ kubectl get volumesnapshotclass astra-netapp-csi-trident-netapp-io-vsc -o yaml
apiVersion: snapshot.storage.k8s.io/v1
deletionPolicy: Delete
driver: csi.trident.netapp.io
kind: VolumeSnapshotClass
metadata:
  creationTimestamp: "2022-10-11T13:43:01Z"
  generation: 1
  labels:
    app.netapp.io/managed-by: astra.netapp.io
  name: astra-netapp-csi-trident-netapp-io-vsc
  resourceVersion: "47518"
  uid: 7a7ee9ec-baa3-4779-ad86-0329dc2f76cb

なおアプリの構成情報データ(Deployment,Secretなど)の格納先についてはACSのサービス側に保管されています。

アプリケーションのオンデマンドバックアップ

次にバックアップ機能を使ってみたいと思います。

スナップショット同様、アプリの管理画面を開きます。
Data protectionのタブから画面右端のBackupsを選択した上で、Create backupをクリックします。

バックアップの名称以外に、いくつかオプションが選択できます。

Back up from an existing snapshotにチェックを付けると、現在のアプリケーションの状態でなく過去に取得したスナップショットをもとにバックアップを作成することができます。
またBackup Destinationではバックアップデータを保管するS3バケットが選択できます。
前回は説明を省きましたが、バックアップデータ格納用のS3バケットはACSが自動作成するもの以外にも既存のバケットをACSに登録して使うことできます

Nextをクリックすると最終確認画面が表示されますので、問題が無ければBack upをクリックします。
バックアップ機能ではS3バケットへ実データのコピーが行われるため、処理時間はデータ量に依存します。
今回は約180MB分のバックアップデータでしたが、数分くらいで処理完了しました。