EKS上のステートフルアプリケーションをまるごとバックアップ・リストアしてみた【③スナップショット&バックアップ篇】

# はじめに
[前回の記事](https://qiita.com/yshimizu22/items/5b6a77a652b3a0b0ec22)ではAstra Control Service(以下、ACS)にEKS上にデプロイしたWordPressアプリケーションを登録しました。
今回はそのアプリケーションに対してスナップショットならびにバックアップの取得を行なっていきます。

- [Astra Control Service(ACS)の導入](https://qiita.com/yshimizu22/items/11967a351e3b1ddde00f)
- Astra Control Service(ACS)の使い方
    1. [アプリケーションの登録](https://qiita.com/yshimizu22/items/5b6a77a652b3a0b0ec22)
    1. **アプリケーションのスナップショット&バックアップ ←イマココ**
    1. [アプリケーションのリストア&クローニング](https://qiita.com/yshimizu22/items/9fd7935e7d78ba2f51ea)

# 前回までのおさらい
検証環境全体の構成図はこちら
![スクリーンショット 2022-10-14 11.04.25.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/436161/0771a474-5592-9398-5a01-82856bb5d04b.png)

前回記事でEKSクラスタ上にWordPressをデプロイし、テスト用データとしてブログ記事を投稿しました。
このブログ記事などのアプリケーションデータはCSIドライバーである**Astra Trident**を介して、バックエンドストレージである**Amazon FSx for NetApp ONTAP**に格納されています。
![スクリーンショット 2022-10-13 13.14.01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/436161/003a32e4-ae9e-64a5-c2e9-82b0bb9f1070.png)

またACS上ではEKSクラスタならびにアプリケーションの登録が完了し、データ保護を行う準備が整っています。
![スクリーンショット 2022-10-12 13.24.05.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/436161/bf82a7a0-a3a0-7915-cc29-75fb944d80a5.png)


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

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

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

# スナップショット&バックアップしてみた
ここからが本題です。

## アプリケーションのオンデマンドスナップショット
まずはACSにログインし、Applicationsメニューから前回登録したアプリケーションの管理画面を開きます。
![スクリーンショット 2022-10-12 17.16.43.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/436161/629fe3f7-7582-25d3-27a3-2ca9cd273856.png)

**Data protection**のタブから**Create snapshot**をクリックします。
![スクリーンショット 2022-10-12 13.29.02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/436161/ce387cd1-dd1c-1ca6-092a-717a0150b16e.png)

指定する必要があるパラメータは取得するスナップショットの名前だけでした（今回はデフォルト値）
![スクリーンショット 2022-10-12 13.30.37.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/436161/39fbdc9e-3711-61b7-6ccd-7ef23a6a1e2d.png)

スナップショットが取得できるとこんな感じです。スナップショット作成開始から完了まで数十秒くらいでした。
![スクリーンショット 2022-10-12 14.08.46.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/436161/dd3e2da4-d8ea-947f-ccab-c8b6914f6227.png)

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

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

試しにk8sクラスタの中身を覗いてみます。
```sh
# スナップショット機能によって作成された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**をクリックします。
![スクリーンショット 2022-10-12 17.26.48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/436161/fe006006-2f5a-0b6f-35a6-1b26f8958894.png)

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

**Back up from an existing snapshot**にチェックを付けると、現在のアプリケーションの状態でなく過去に取得したスナップショットをもとにバックアップを作成することができます。
また**Backup Destination**ではバックアップデータを保管するS3バケットが選択できます。
前回は説明を省きましたが、バックアップデータ格納用のS3バケットはACSが自動作成するもの以外にも既存のバケットをACSに登録して使うことできます
![スクリーンショット 2022-10-12 17.29.13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/436161/c1b1a5eb-f21c-616c-4be5-237720e6e9f7.png)

**Next**をクリックすると最終確認画面が表示されますので、問題が無ければ**Back up**をクリックします。
バックアップ機能ではS3バケットへ実データのコピーが行われるため、処理時間はデータ量に依存します。
今回は約180MB分のバックアップデータでしたが、数分くらいで処理完了しました。
![スクリーンショット 2022-10-12 17.50.18.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/436161/a810a696-fab9-7992-8491-a351419d02fd.png)


## アプリケーションの保護ポリシーの作成
ここまでは任意の時点でスナップショットやバックアップを作成する方法を試してきましたが、ACSではスケジュールベースでこれらの機能を定期実行することもできます。
具体的にはどれぐらいの周期でバックアップ作成し、どれぐらいの世代数を保管するかという**保護ポリシー**を作成することでこれを実現します。

**Data protection**のタブから**Confifure protection policy**をクリックします。
![スクリーンショット 2022-10-12 18.09.20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/436161/83c33011-1efe-4a32-f129-ec09cf8b7f25.png)

保護ポリシーの作成ウィザード
![スクリーンショット 2022-10-12 18.24.20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/436161/6e66028c-a453-ca1e-edee-d8645611e290.png)

**バックアップ/スナップショットの周期**は以下の粒度で設定できます。
- Hourly: 毎時0分/10分/20分/30分/40分/50分のいずれかを選択して指定
- Daily: 毎日のバックアップ時刻(UTC)を分単位で指定
- Weekly: 曜日(複数指定可)とバックアップ時刻(UTC/分単位)を組み合わせて指定
- Monthly: 日付(複数指定可)とバックアップ時刻(UTC/分単位)を組み合わせて指定

また保管する**データの世代数**はスナップショット/バックアップそれぞれに異なる値を設定できます。
保管できる世代数の上限値はバックアップの方が多くなっています。

- スナップショット: 32世代まで
- バックアップ: 1000世代まで

今回は以下の様に保護ポリシーを設定してみました。
- スナップショットを毎時0分に取得し、1日分(=24世代)保管
- バックアップを毎日0:00に取得し、1週間分(=7世代)保管

![スクリーンショット 2022-10-12 18.27.34.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/436161/fce77430-e297-c3b7-29f4-c4942a5b7875.png)

**Configure**をクリックして保護ポリシーを作成するとアプリのApplication Protectionが**Fully protected**のステータスに遷移しました。
**Fully protected**になる条件は以下の様になっています。
- 直近でバックアップ(≠スナップショット)が取得されていること
- 保護ポリシーが作成されていること

![スクリーンショット 2022-10-12 18.28.59.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/436161/2b90b092-5dd5-6ae5-6a7e-08b7002ab3bb.png)

これでスナップショット&バックアップは完了です。

# まとめ&次回予告
今回の記事ではACSの中核の機能とも言えるアプリケーションのバックアップとリストアを検証してみました。
スナップショットはアプリの更新前後などの日常的なバックアップとしてのユースケースで使えそうですね。
一方でバックアップ機能はDRやアプリのクラスタ間移行などのユースケースで有効そうです。

次回記事では今回取得したバックアップデータをリストアしてみたいと思います。

**次回記事** -> [EKS上のステートフルアプリケーションをまるごとバックアップ・リストアしてみた【④リストア&クローニング篇】](https://qiita.com/yshimizu22/items/9fd7935e7d78ba2f51ea)