2024年現在、私はプラットフォーム事業者が「Kubernetesはステートレスワークロード専用である」、あるいは「当社のアプリはすべてステートレスなので、データ保護は必要ない」などと話しているのをよく耳にすると、驚きを隠しきれません（冗談ですが）。今回の記事では、アプリケーションのどこに「ステート」が存在するかについての背景情報、「Kubernetes = ステートレス」とする俗説の台頭、そしてすべてのKubernetes環境におけるデータ保護のニーズについて説明します。
ステートフルとステートレス — 基礎
「ステートレス」とはステートフルな永続性を必要としないワークロードを指し、そうしたワークロードの再起動または再導入の際には、収集または変更した設定がすべて失われます。ステートフルな仮想マシン（VM）の先行製品と比較すると、コンテナは本質的にステートレスです。ユーザーは、コンテナを再起動することで、そのコンテナイメージを最初に作成したときと同じワークロードが実行されることをわかっています。
ロジックに従えば、ステートフル ワークロードとは、再起動後もアクセスできるようにデータを保持するワークロードです。一般的なステートフルなワークロードには、PostgreSQL、MySQL、MongoDBなどのデータベースが含まれます。
では、ステートレス アプリケーションとは何でしょうか。
アプリケーションは通常、複数のワークロードで構成されています。モノリシックなVMベースのアプリケーションであっても、全般的には個別のフロントエンド、ビジネスロジック、データベースのワークロードで構成されています。通常、クラウドネイティブのマイクロサービスベースのアプリケーションは、組織が新しい機能やサービスを今まで以上のスピードでリリースできるようにすることを目標として、さらに多くの個別のワークロードで構成されており、それぞれが固有の機能を備えています。
これはつまり、ステートレスなアプリケーションは存在しないことを意味しています。
お気に入りの食品注文アプリ、携帯電話の「To Do」アプリ、診察予約のための入力フォームなどは、どれもそれぞれのユースケースに関連する重要なデータを保持するステートフルなワークロードがなければ、実際には役に立ちません。
Kubernetesでは、アプリケーションのデータ（状態）がクラスターの内部または外部のどこにあるかを把握することが重要です。
「Kubernetes = ステートレス」の俗説が生まれた経緯
2010年代初頭から半ばにかけて、Dockerがソフトウェアをパッケージ化するための事実上のコンテナプラットフォームとなったため、コンテナのグループを大規模にオーケストレーションするソリューションを持つことは、マイクロサービスへの移行から運用上の価値を最大限に引き出すために不可欠であり、Kubernetesはそれを実現しました。宣言型の導入、ハイアベイラビリティ、自動スケーリングは、簡単に停止、再起動、クローン作成できるステートレスワークロードにとって大きなメリットでした。多くの場合、これらのワークロードは、より多くのフロントエンドまたはアプリケーションサーバーのコンピューティングを提供し、クラスターの外部で実行されているデータサービスに接続することも可能でした。このソリューションは、多くの人から成功として歓迎されました Kubernetesは明らかにステートレスなワークロード向けに設計されたソリューションですよね？
ただし、Kubernetes v1.0には、ステートレスなワークロード向けのこうした優れた機能と並んで、永続ストレージを一時的なポッドにアタッチするためのKubernetesネイティブのメカニズムである永続ボリュームがありました。ステートフルなワークロードをサポートする意図は当初から検討されていたことは明らかであり、その過程でいくつかの注目すべき機能拡張が行われました。
- 2017年12月（v1.9）、StatefulSetの一般提供開始 — ポッドのアイデンティティ特性と順序付けされた操作の永続性を提供
- 2018年12月（v1.13）、コンテナストレージインターフェイス（CSI）の一般提供開始 — すべてのストレージ製造メーカーが、Kubernetesワークロードにストレージを提供するための独自のプラグインを作成できるようにするための標準規格
- 2018年5月、Operator Frameworkの登場 — Kubernetes上でデータベースなどの高度なワークロードの導入と管理を簡素化するソフトウェア開発キット（SDK）
- 2020年12月（v1.20）、CSI仕様におけるボリュームスナップショットの一般提供開始 — Kubernetes内でストレージスナップショット操作を実行するための、標準化されたインターフェイスを提供
これらの改善と、さまざまなベンダーやプロジェクトコントリビューターの努力が組み合わさり、アプリケーションの状態を提供するデータサービスとそれらのワークロードを実行する場所をユーザーが自由に選択できる、充実したエコシステムが形成されました。
GitOpsの台頭
この間、Kubernetesコミュニティでは、コンテナオーケストレーションを向上するための新たなアイデアである「GitOps」が話題になりました。その概念はシンプルなものであり、ソース管理を信頼できる情報源として使用し、コードやKubernetesリソースなど、アプリケーションの導入に必要なものをそれにすべて格納します。コードがリポジトリに統合されて変更が加えられるたびに、コントローラーによって導入が更新され、Gitで記述された希望のステートが反映されます。GitOpsの実装により、変更制御のメカニズム、ワンクリックで環境全体を再導入する機能、不適切な変更を元に戻す方法が提供されます（常にではない）。
Kubernetesでステートフルなワークロードの実行が可能であるというだけで、それを実行すべきなのでしょうか？
概念実証アプリケーションの構築を任された開発者は、多くの場合、クラウドホスト型マネージドデータベース（DBaaS）を選択して、Kubernetesクラスタの外部で永続データをホストします。DBaaSソリューションは、データベース管理の専門知識のレベルに関係なく、開発者にとって使いやすいAPIと価値実現までの時間を短縮します。しかし、よくあることですが、最も簡単なことが必ずしも最善であるとは限りません。ステートフルワークロードの実行をクラスターの内部と外部で検討すべき理由を探ってみましょう。
- レイテンシ — データサービスを他のコンテナ化されたワークロードと同じ場所に配置することで、低レイテンシのデータ接続を確保して、一貫したユーザーエクスペリエンスを提供できます。
- モビリティ — Kubernetesは強力な抽象化レイヤーを備えているため、同じワークロードを異なるクラウド間で移行できます。これにより、組織はデータの主権性に関するニーズに対応したり、有利な価格条件のメリットを単に得たりすることができます。ただし、お使いのデータサービスがクラウド固有のDBaaSに関連付けられている場合、環境間の移行は大幅に複雑になります。特定のDBaaSに対して作成された自動化とポリシーは、目的のクラウド内に同等のマネージドデータベースが存在し、要件を満たしていることを前提に、そのデータベースに向けて再作成する必要があります。Kubernetesワークロードを外部データサービスから再導入するには、別途ツールと処理が必要になります。
- コピーデータ管理 — 開発者は関連性の高い最新のデータを使ってアプリケーションをテストする必要があり、クラスター外で実行する場合は、これらのデータサービスを管理して接続するための個別のプロセスが必要になります。クラスター内でステートレスとステートフルの両方のワークロードを実行する完全に宣言型のソリューションの一部として、「kubectl」などのKubernetesネイティブのインターフェイスを使用して、アプリケーション全体のバックアップをクローンとしてリストアするだけで済みます。
- ポリグロットパーシステンス — 「適切なユースケースのための適切なデータサービス」を表す技術的な表現です。従来のアプリケーションはマイクロサービスアーキテクチャを使って再構築されるため、開発者はKubernetes上でそれぞれのニーズに最適なデータサービスを実装することができ、導入は簡素化され、継続的な管理は担当のオペレーターが対応します。Kubernetes以外でデータサービスを運用している組織は、開発者が選択した理想的なデータサービスに対応していくという複雑な運用要件を満たすようにスケーリングできない可能性があります。
- コスト — DBaaSソリューションでは、その利便性に対して料金を支払います。ただし、EnterpriseDBのようなパートナーは、Kubernetes上で独自のデータサービスをホストすることで、ユーザーエクスペリエンスを大幅に犠牲にすることなく、総所有コスト（TCO）を削減できることを実証しています。
ステートレスなワークロードとステートフルなワークロードをKubernetes上で統合することで、アプリケーションを実行する場所に関して柔軟性を高めることができます。また、DevOpsのための追加のセルフサービスが提供され、コストを削減してツールとプロセスを合理化することも可能です。これにより、アプリケーションのすべての部分にGitOps手法を適用できるようになります。実際のコンテナ使用に関するDatadogの最新レポートによると、データベースは引き続き、コンテナ化されたワークロードの最も一般的なカテゴリであるとのことですが、これは驚くべきことではありません。
Kubernetesデータの継続的な保護
「ステートフル」チーム
Kubernetesのステートフルなワークロードが今後の進むべき道であるとすでに確信しているなら、これらのアプリケーションのバックアップとディザスタリカバリを提供するには専用ツールが必要であることをすでに理解している可能性があります。各アプリケーションは、多数の異なるKubernetesリソース（ConfigMap、Secret、Deploymentなど）と永続ボリュームデータで構成されています。さらに、これらすべてを適切に検出してスナップショットを作成し、クラスター外の安全な場所にエクスポートする必要があります。
そこで、Kubernetesネイティブのデータ保護およびアプリケーションモビリティのソリューションであるVeeam Kasten for Kubernetesの出番です。Kastenでは、使いやすく、拡張性と安全性に優れた方法でイミュータブルなバックアップを作成し、アプリケーション全体を迅速かつ確実に復元することができます。
Kastenでは、ポリシーの定義やアクションの実行などを行うための宣言型のKubernetesネイティブAPIが提供されるため、あらゆるGitOps環境にデータ保護を緊密に統合することができます。これは、新しいクラスターでのKastenの導入と設定から、コード更新を展開する前にバックアップを自動化してGitOpsを強化することまで、あらゆるユースケースに当てはまります。GitOps自体は、設定の変更をKubernetesリソースにまでロールバックする機能を提供します。ただし、不適切な変更によって永続ボリューム上のデータが変更された場合（スキーマの誤った変更やテーブルの削除など）は、迅速に復元可能な最新のバックアップが必要になります。
チーム ステートレス
お気に入りのDBaaSを、Kubernetesでホストされ、オペレーターによって管理される真新しいデータベースに切り替える気持ちはまだ整っていませんか？Kastenがお客様の支えとなります。Kubernetesネイティブのデータ保護が依然として必要な理由をご紹介します。
- ステートはどこかに存在する必要がある — データはクラスター外のどこにでも保存できますが、通常はDRまたはコンプライアンス上の理由から、アプリケーションのポイントインタイム導入を再現できることが依然として重要になります。Kastenは、基本的にはデータ保護運用のために設計されたオーケストレーションエンジンです。Kastenのブループリント機能ならクラスター上のデータサービスを静止させる堅牢な制御が可能ですが、外部データサービスのスナップショットやバックアップのオーケストレーションにも活用できます。これには、データベースの論理ダンプのオーケストレーションや、DBaaS APIとの直接統合が含まれます。
- GitOpsは絶対確実ではない — 多くの管理者やエンジニアは、何らかの形で「本番でのテスト済み」を経験しています。これは、<insert important reason here>のために、変更管理プロセスを迂回して、変更が本番のインスタンスに加えられたことを意味します。したがって、デプロイされた内容の唯一の信頼できる情報源は、実行時にクラスター自体から得られます。デプロイされた各アプリケーションに関連付けられたマニフェストの定期的なバックアップを作成することで、これらの不一致が確実にキャプチャされ、元の環境を忠実に再現してDRや規制要件をサポートできます。
- コンテナイメージの保護 — Kastenは、ImageStreamコンテナイメージの保護やリストアのサポートなど、 Red Hat OpenShiftが提供する高度な機能の多くと統合されています。イメージストリームは、アップストリームのKubernetesと比較して、コンテナイメージを構築およびデプロイするための豊富な機能を追加します。クラスターステートの見逃されがちなソースとは、デフォルトでクラスターの内部コンテナレジストリにプッシュされるImageStreamのコンテナイメージです。ソースから再構築しても、結果のイメージが同じであるという保証はありません。繰り返しになりますが、環境を完全に再現したり、クラスターの損失から復元したりするには、信頼性の高いバックアップが必要になります。
- Kubernetes上の仮想マシン — KubeVirtプロジェクトとそのコントリビューターのおかげで、Kubernetes上のコンテナ化されたワークロードとVMを並行して実行できるようになりました。これにより、組織はKubernetes関連のツールやプロセスを合理化できると同時に、完全なクラウドネイティブアプリ化されていない、あるいは変換されないワークロードへのシンプルな入口を提供することができます。VMはKubernetes上でも本質的にステートフルですが、従来のVMバックアップツールでそれらを保護することはできません。Kasten V7.0なら、OpenShift Virtualizationを実行するKubernetes上のVMのバックアップとリストアに関して、クラス最高のサポートを提供します。
「Kubernetesのデータ保護」チーム
Kubernetesは、「ステートレスなワークロードにのみ適している」という固定観念にかかわらず、あらゆるタイプのワークロードをサポートするように進化してきました。組織がクラウドネイティブへの投資から最大限の価値を引き出そうとしている現状では、ステートフルなワークロード実行への継続的な移行は避けられません。パフォーマンスとモビリティの向上、コピーデータ管理の簡素化、ポリグロットパーシステンス、コスト削減などの潜在的なメリットを実現しましょう。
実行するワークロードがステートフルかステートレスかにかかわらず、データ保護が重要であることに変わりはありません。Veeam Kasten for KubernetesはKubernetesネイティブのソリューションを提供し、アプリケーションとデータのバックアップ、ディザスタリカバリ、アプリケーションモビリティ、ランサムウェア対策を可能にします。さらに、データ保護をアプリケーションの導入に統合することで、GitOpsを使ったアプローチが強化されます。最終的に、Kubernetesにステートフルなワークロードを導入することで、収益機会が広がるだけでなく、柔軟性やセルフサービス、投資対効果の向上、そして運用の合理化が組織にもたらされます。
Veeamが提供するVeeam Kasten Freeソリューション、またはEnterprise評価版をお試しください。今すぐ開始しましょう。