「コンテナ化」でより難しくなったアプリケーションのバックアップ、どうやって実現する？

こんにちは、ネットアップでコンサルタントを務めている清水です。今回のブログでは、近年活用が広がっているコンテナアプリケーションのバックアップを検討する上での課題やポイントについて解説をしていきます。

コンテナはサーバ仮想化技術の一種であり、仮想マシン(以下、”VM”と表記)と比較すると主に以下の様な利点があります。

• 軽量であるため、アプリケーションが短時間で起動できる
• ホストOSとLinuxカーネルを共有するため、リソース効率に優れる
• アプリケーションの実行環境をコンテナイメージとしてまとめてパッケージ化することができ、開発から本番環境までの一貫性を確保しやすい
• 特定のプラットフォームに依存せず、オンプレでもクラウドでも実行できる

コンテナをホストするプラットフォームとしてはDockerやKubernetesが代表的です。またマイクロサービスアーキテクチャやDevOpsなどとの親和性も高く、アプリケーションのモダナイズの一環としてコンテナを推進している企業も多くなっています。

仮想マシンとコンテナのもう一つの違いとして、コンテナはデータを保持しない(ステートレス)という性質を持っています。例えばVMでは仮想ディスク内に書き込まれたデータはVMの再起動後も引き続き利用できますが、コンテナが再起動された場合、コンテナ内部に書き込まれたデータは毎回削除されてしまいます。従ってコンテナプラットフォーム上でデータベースなどのステートフルアプリケーション(データを保持するアプリケーション)を構成する場合は、コンテナの外にデータを永続化する必要があります。

例としてKubernetesではデータの格納先である外部ストレージをPersistent Volume(以下、”PV”と表記)というオブジェクトによって管理し、データの永続化を行います。またこのPVを使用するために一般的にはアプリケーション開発者がPersistent Volume Claim(以下、”PVC”と表記)というKubernetesオブジェクトを作成することでPVの払い出しを要求します。更にCSIプロビジョナーと呼ばれるコンテナプラットフォーム向けのストレージプラグインを導入することで、アプリケーションの要求仕様に合致するストレージボリュームを自動的に払い出す事も可能となります。これらの仕組みによりアプリケーション開発者は、データを格納するストレージ装置の仕様などを意識せずともアプリケーションに適したストレージをすぐさま利用することができるため、開発作業により注力することができます。またインフラ管理者にとっても一度ストレージプロビジョナーを導入してしまえば、ストレージボリュームの作成・削除などの管理が自動化されるため、運用負荷の低減に繋がります。以下はご参考までに弊社ネットアップが提供するストレージプロビジョナーである、Astra Tridentを用いたPVの払い出しフローです。Astra Tridentの詳細に関しては、公式ドキュメントや技術ブログをご覧ください。

上記の様に複雑なストレージインフラを抽象化するPVCやPVといったコンテナプラットフォームとAstra Tridentをはじめとするストレージプラグインを組み合わせることで、開発効率が飛躍的に向上し、ビジネスニーズに素早く応えることができるようになるという点はアプリケーションをコンテナへ移行する大きなメリットと言えるでしょう。しかし一方で「コンテナ化」によって新たに生まれる課題もあります。

コンテナ型アプリケーションにおけるバックアップの考え方は従来のモノリシックなアプリケーションと大きく異なります。

例えばKubernetesでは、アプリケーションはマニフェストと呼ばれるファイルの集合体によって管理されます。マニフェストは各種Kubernetesオブジェクト(Pod, Service, Secret, PVC, etc.)のあるべき姿を記述したYAMLファイルとなっており、1つのアプリケーションを構成するために数十ファイルにも渡るマニフェストが必要になることさえあります。つまりコンテナアプリケーションの保護(バックアップや別クラスタへの複製・移行など)を行うためには、アプリケーションを構成する多数のマニフェストを漏れなく管理・保管する必要があります。このように膨大な数のマニフェスト群を適切に管理することは、コンテナ環境の運用においてよくある課題のひとつです。

また特にデータを保持するステートフルアプリケーションではアプリケーションデータ(PV内のデータ)の保護も特に重要な課題です。PV内のデータは一般的にKubernetes外部のストレージに保管されており、データそのものはマニフェストにより管理されません。つまり膨大なKubernetesマニフェスト群を正しくバックアップできたとしても、それだけではPVの中身のデータまでは保護できないということを意味します。従ってステートフルアプリケーションでは上記で挙げたKubernetesマニフェスト群のバックアップに加えて、外部ストレージに保管されたアプリケーションデータに関しても何らかの手段でバックアップを行い、かつバックアップしたマニフェスト群とアプリケーションデータの整合性を保つ必要があります。

従来ではVMのシステムバックアップだけで済んでいたアプリケーションバックアップの運用が、「コンテナ化」によって複雑化してしまいかねません。

では具体的にどのようにして、PV内のデータを含めたアプリケーションバックアップを実現できるのでしょうか？今回は以下の3つのバックアップ方式を比較してみます。①、②は一般的にKubernetesのバックアップ運用で広く用いられている手法です。一方で③は弊社のAstra Controlいうソリューションを用いた手法になっています。

まず①はKubernetesクラスタの構成情報データベース(etcd)をまるごとバックアップするといった方式です。これはクラスタの構成情報を格納するデータベース全体をバックアップ・リストアする方式であり、サイト障害などに備えた定期バックアップとして広く用いられています。一方でデータベースの一部のみをリストアすることは困難であるため、特定のアプリケーションを対象としたリストアや、別クラスタへの移行といったユースケースには適しません。続いて②はGitなどのバージョン管理システムを用いてKubernetesのマニフェストを管理するという手法です。この手法ではバージョン管理システムを介してマニフェスト単位にきめ細かくバックアップ・リストアができるため、①のetcdバックアップとは異なり、特定のアプリケーションのみを対象としたバックアップ運用に適しています。一方で、バージョン管理システム内に保管されたマニフェストと実態であるクラスタの構成情報との整合性を常に保つ必要があり、バージョン管理システムそのものに対する成熟度が求められる方式とも言えるでしょう。また①、②に共通していることは、これらはあくまでアプリケーション構成情報(マニフェスト群)だけを保護するものであり、対象のアプリケーションがステートフルである場合は、Kubernetes外部に保管されているアプリケーションデータ(PV)のバックアップは別途必要であるということです。

そこで最後にAstra Controlを活用してアプリケーションの保護を行う方法を紹介します。Astra Controlは弊社ネットアップのコンテナワークロードの向けデータ保護ソリューションであり、Namespaceまたは特定のLabelが付与されたKubernetesオブジェクト群とKubernetes外部のアプリケーションデータ(PV内のデータ)を一括でバックアップ・リストアすることができます。これにより複雑になりがちなステートフルアプリケーションのバックアップ運用においても、シンプルな操作でアプリケーションの保護を行うことができます。下記はAstra Controlを用いてKubernetes上のアプリケーションをバックアップする際の実行フローです。

また、バックアップデータを外部のオブジェクトストレージに格納する機能、定期的なバックアップや取得したバックアップの世代管理を行う機能(保護ポリシー)、REST APIやPython SDKなどによるサードパーティとのインテグレーションなど、多種多様な機能を備えており、DRやDevOpsなど幅広いユースケースに適しています。

なお弊社ネットアップでは今回ご紹介したAstra Controlの基本的な使い方やDevOpsにおける応用的な活用例など、様々な技術情報をQiitaで発信しております。ぜひ併せてご覧ください！