Kubernetesバックアップ特有の課題の定量化と対応

エグゼクティブサマリー

今後数年間で、ほぼすべての企業が本番環境にKubernetesを導入し、採用することを期待しています。

これらの同じ企業も、Kubernetesを本番環境に移行するには、他の本番アプリケーションと同じ基準を満たす必要があることを認識しています。これらの要件の中で、Kubernetesでホストするコンテナ化されたアプリケーションをバックアップおよびリカバリする手段を持たなければなりません。

良い点として、コンテナ化されたアプリケーションとVMのバックアップには共通点があります。すべてのアプリケーションは仮想であり、バックアップを実行するためのAPIが存在し、バックアップデータは依然としてコアで1と0から構成されています。そのため、コンテナ化されたアプリケーションとVMのバックアップを同じバックアップ保管庫にバックアップして保存することが可能です。

しかし、Kubernetesでコンテナ化されたアプリケーションをバックアップするには、5つの明確な課題があります。これらには以下が含まれます：

1. コンテナ化されたアプリケーションの一時的なデータとストレージを保護すること
2. コンテナ化されたアプリケーションの予測不可能な性質を管理すること
3. 急速に変化するKubernetes環境のダイナミクスに対応すること
4. Kubernetesに必要な幅広いバックアップ機能を提供すること
5. 刻々と変化する本番Kubernetes環境から信頼性の高いリストアを作成すること

Kubernetesバックアップのこれら5つの課題に対応するためには、どのようなバックアップソリューションでも、Kubernetesバックアップの特定の課題に対応する必要があります、バックアップソリューションは、Kubernetesの特定の機能を活用する必要があります。その中でも最も重要なのは、各コンテナ化アプリケーションに関連付けられたメタデータを利用することです。こうすることで、コンテナ化されたアプリケーションをバックアップする必要があるかどうかを定量化し、バックアップする必要がある場合は、どのようにバックアップするのが最適かを決定することができます。

そして、これらのメタデータラベルを複数の目的で使用する必要があります。

そして、これらのメタデータラベルを複数の目的で使用しなければなりません。

最低限、どのバックアップがどのバックアップであるかを一意に識別するために使用しなければなりません。

最後に、企業は変化し続けるKubernetes環境に動的に適応するために、クラウドネイティブなアーキテクチャで提供されるバックアップソリューションが必要になります。理想的には、バックアップソリューションはサービスとして提供され、コンテナ化されたアプリケーションとVMの両方のバックアップを管理することです。

HYCUは、Kubernetesバックアップのこれらの特定の課題に対処します。HYCUは、仮想化環境を保護するという継続的な企業のニーズを満たすと同時に、新しいKubernetes環境をバックアップできるようにします。

未来はKubernetes

コンピューティング史上最大の変革の1つが起ころうとしています。この繰り返しでは、組織は使用する正確なハードウェア、ソフトウェア、ネットワーキング、仮想化、またはクラウド技術にあまり重点を置きません。

このビジョンは現実のものとなりそうです。

クラウドネイティブなプラットフォーム上でホストされたKubernetesによって管理されるコンテナ化されたアプリケーションをデプロイすることで、この理想に手が届くようになります。

これらの次世代テクノロジーを採用することで、組織は次のことが可能になります：

• アプリケーションの開発とデプロイを加速し、短縮する
• クラウドプラットフォーム上のアプリケーションの配置を、ビジネス、コスト、パフォーマンス、リソースのニーズに合わせる
• 、
• 将来のコストとリソース要件をより正確に予測する
• いつでも任意のクラウド プラットフォームでアプリケーションをホストする
• 必要に応じて IT インフラストラクチャをスケールアップまたはスケールダウンする
• アプリケーションを開発およびホストするために使用する IT リソースを減らす
• 利用可能な IT リソースをより効率的かつ効果的に使用および再利用する

これらの利点により、多くの企業が IT の未来としてこれらのテクノロジーを受け入れています。

Cloud Native Computing Foundationによる2020年6月の調査では、メンバーの78パーセントがすでに何らかの形でKubernetesを使用していることがわかりました。

Googleクラウドは、Kubernetesが企業でどの程度普及する可能性があるかについて、おそらく最高の洞察を与えてくれます。Googleはすでに、毎週何十億ものコンテナを起動するクラウド内で、すべてのアプリケーションをコンテナ上で実行しています。

このビジョンを実現するには、企業はこれらのコンテナ化されたアプリケーションとそのデータを保護するインフラストラクチャを導入する必要があります。この新たなインフラの一部として、多くの企業はKubernetesを正式に採用する前に、バックアップソリューションを必要としています。

バックアップ特性の共通点

コンテナと仮想マシン(VM)には複数の特徴があり、企業は両方を保護するために単一のソリューションを使用することを検討することができます。コンテナとVMは、それらをホストするプラットフォームから独立して動作します。適切に設計されたバックアップソフトウェアは、コンテナとVMの両方をオブジェクトとして扱い、保護することができます。

• 利用可能なAPI。コンテナとVMをホストする基礎となるKubernetesとハイパーバイザー・プラットフォームはAPIを提供します。バックアップソフトウェアはこれらのAPIと相互作用し、個々のコンテナやVMのスナップショットを取得するなどのタスクを実行します。
• データはデータです。企業がコンテナやVMでデータをホストしても、データはデータです。

このような類似点などがあるにもかかわらず、バックアップソフトウェアはコンテナのバックアップとリカバリーをVMのバックアップとは異なる方法で管理する必要があります。

5つのKubernetesバックアップの課題

バックアップ ソフトウェアは、Kubernetesでのコンテナのバックアップとリカバリが生み出す5つの特定の課題に対処しなければなりません。

1.エフェメラルストレージ

Kubernetesでコンテナ化されたアプリケーションをデプロイすることは、VM上でアプリケーションをデプロイすることとは重要な点で異なります。アプリケーションまたはそのホスティングVMがシャットダウンしても、アプリケーションのデータとVMのストレージは持続します。

Kubernetesでは、コンテナ化されたアプリケーションとそのポッドに関連するデータとストレージリソースの扱いが異なります。アプリケーションまたはポッドがシャットダウンすると、Kubernetesは割り当てられたリソースを自動的に回収します。

このため、バックアップの観点から2つの課題が生じます。

まず、バックアップソフトウェアがコンテナ化されたアプリケーションの存在を認識する必要があります。

次に、コンテナ化されたアプリケーションは短期間しか存在しない可能性があります。

第二に、コンテナ化されたアプリケーションは短期間しか存在しない可能性があります。したがって、毎日のバックアップをスケジュールして、これらのアプリケーションのデータを保護することを期待することはできません。

2.予測不可能性

Kubernetesが提供する、ほぼすべてのクラウド上でいつでもどこでもコンテナを起動できる柔軟性は、企業に対する魅力を高めています。

バックアップソリューションは、この環境をバックアップするために複数のタスクを実行する必要があります。まず、コンテナ化されたアプリケーションとそのエフェメラルなストレージに関連する課題に対処しなければなりません。

コンテナ化されたアプリケーションをバックアップする必要がある場合、適切なポリシーを使用してバックアップする必要があります。ポリシーは、ソリューションがアプリケーションをバックアップする必要がある頻度を決定します。バックアップは、コンテナ化されたアプリケーションがシャットダウンする直前など、1 回だけ発生することもあります。

3.バックアップソリューションのスケーラビリティ
Kubernetesは、数千、数百万、おそらく数十億のコンテナ化されたアプリケーションの起動とシャットダウンを毎週または毎月行います。

バックアップソリューションは、すべてのコンテナ化されたアプリケーションを検出し、バックアップジョブをスケジュールし、それらを管理するのに十分なリソースを持っている必要があります。

クラウドインフラに展開されたKubernetesは、バックアップの課題をさらに悪化させます。

このような環境に対応し、管理するためには、バックアップソリューションは自動的かつコスト効率よく適応しなければなりません。コンテナ化されたアプリケーションが起動すると、バックアップソリューションは動的にスケールアップしなければなりません。同様に、コンテナがオフラインになると、バックアップソリューションは動的にスケールダウンしなければなりません。

4.Kubernetesバックアップ機能の幅

企業がバックアップソリューションを選択するかどうかは、部分的にはKubernetesデプロイの成熟度によって決まります。安定した、より成熟したKubernetes環境では、企業は多くの場合、Kubernetesのコアコンポーネントのデプロイメントを自動化するスクリプトを記述します。このような環境では、企業はKubernetes環境でホストされているコンテナ化されたアプリケーションだけをバックアップすることができます。

対照的に、Kubernetesを最近採用した企業では、バックアップの課題が異なる可能性があります。まだKubernetes環境の構築を終えていないかもしれません。

どちらの場合でも、企業はまだKubernetesの制御場所を再作成するスクリプトを作成していない可能性が高いです。その結果、より幅広いバックアップ機能を備えたソリューションが必要になります。ソリューションは、Kubernetesコントロールプレーンとコンテナ化されたアプリケーションとデータの両方をバックアップする必要があります。リカバリ

コンテナ化アプリケーションのバックアップには課題がありますが、コンテナ化アプリケーションのリカバリにはさらに大きな課題があります。

リカバリを実行するには、バックアップソフトウェアは最初に各バックアップを特定のアプリケーション、ユーザー、またはその他の環境定数に関連付ける必要があります。

企業がリカバリを実行する必要がある場合、どのバックアップをリカバリするかを識別する何らかの手段が必要です。

リカバリーの一環として、企業はKubernetes環境におけるリカバリーの範囲を決定する必要もあります。ソフトウェアがリカバリする必要があるのは、単一のコンテナ化されたアプリケーションだけかもしれません。しかし、複数のコンテナ間には相互依存関係が存在する可能性があり、実際に存在することもよくあります。

データ損失の幅は、バックアップソフトウェアが復旧しなければならないKubernetesコンポーネントにも影響します。

企業は、コンテナ化されたアプリケーションを他のKubernetesデプロイメントにリカバリするための新たな要件も考慮する必要があります。各クラウドで異なるKubernetesバージョンを実行するハイブリッドクラウドを使用する企業が増えています。

異なるクラウドで使用されるKubernetesデプロイメントには多くの共通点があります。しかし、相違点も存在します。

Kubernetesバックアップの課題に対処する

Kubernetes環境のバックアップに関連するこれら5つの課題に対処するために、企業は異なる方法でバックアップを管理する必要があります。このバックアップ管理の変更は、企業がKubernetesでコンテナ化されたアプリケーションを展開する方法から始まります。

コンテナラベルを効果的に活用する
すべてのコンテナ化されたアプリケーションは、ラベルを含むメタデータをオプションで所有することができます。

コンテナ化されたアプリケーションが起動するたびに、Kubernetesノードサービスに登録する必要があります。

登録すると、3つのイベントが発生します。

• まず、Kubernetesノードサービスがコンテナの既存のメタデータラベルを読み取ります。
• 2つ目に、Kubernetesはコンテナのラベルにキー値のペアを追加します。
• 3つ目に、これらのキー値は、アプリケーションリソースが動作するためにお互いを必要とする可能性があるため、どのアプリケーションリソースが一緒に属するかを識別するのに役立ちます。

コンテナラベルを効果的に活用する

バックアップソリューションは、これらの機能を活用する必要があります。Kubernetesコンテナの起動とそのメタデータの内容を監視します。

バックアップ ソフトウェアは、各コンテナのメタデータを使用して、コンテナ化されたアプリケーションをバックアップおよびリカバリする必要があるかどうか、いつ、どのように必要かを判断します。リカバリ要件に合わせて適切なバックアップポリシーを作成し、割り当てます。バックアップは、本番環境で互いに依存しているコンテナ化されたアプリケーション間で同期的に実行されます。これは一貫したリカバリを保証するために行われます。

この偉業を達成するために、バックアップソリューションはkube-schedulerでバックアップジョブまたはジョブをスケジュールします。バックアップジョブは、コンテナ化されたアプリケーションと関連アプリケーションを適切な間隔でバックアップします。

バックアップに定数を割り当てる

コンテナ化されたアプリケーションを正常にリカバリするためには、バックアップソフトウェアがアプリケーションのバックアップがいつ発生するかを正確に識別する必要があります。そのために、バックアップ ソフトウェアは各バックアップに 1 つ以上の環境定数を割り当てる必要があります。

バックアップに割り当てられる環境定数には、日付とタイムスタンプ、特定のノード、ポッド、およびコンテナの識別子が含まれます。コンテナ化されたアプリケーションはポッド内に存在しなければならず、ポッドはノードとともに存在しなければなりません。この変数の組み合わせは、各アプリケーションのバックアップがいつ、どこで発生したかを一意に分類する手段を提供します。

クラウドネイティブアーキテクチャ

数千、数百万、または数十億のコンテナ化されたアプリケーションのバックアップ要件を満たすためにスケーリングするには、クラウドネイティブアーキテクチャを使用する必要があります。この方法で、バックアップソリューションは効率的かつコスト効率よく、アプリケーションをバックアップするために動的にスケールアップまたはスケールダウンすることができます。

HYCU：KubernetesとVMのバックアップのためのクラウドネイティブなソリューション

Kubernetesは、企業がバックアップソリューションを測定する必要がある新しい基準を作成します。仮想化環境でバックアップを実行するいくつかの原則は、コンテナ化されたアプリケーションを保護する場合にも当てはまりますが、新しいバックアップとリカバリの要件も存在します。

Kubernetes環境では、バックアップソフトウェアは以下のタスクを動的に実行する必要があります：

• コンテナ化されたアプリケーションの作成を検出する
• それぞれに適切なバックアップポリシーを適用する
• さまざまなコンテナ化されたアプリケーション間に存在する可能性のある依存関係を識別する
• 数百万の異なるバックアップ関連アクティビティを潜在的に処理するためにスケールアップまたはスケールダウンする

HYCUは、Kubernetes環境におけるバックアップとリカバリのニーズに対応する能力を企業に提供します。

クラウドネイティブなアーキテクチャに基づいて構築されたHYCUは、変化するKubernetesバックアップワークロードに合わせて、自動的に動的にスケールアップおよびスケールダウンします。

Kubernetesと相互作用することで、Kubernetesのコントロールプレーンとコンテナ化されたアプリケーションの両方を保護します。アプリケーションを保護するために、HYCUは既存のアプリケーションのメタデータラベルを読み取ります。

HYCUはまた、他のクラウドのKubernetesでホストされているアプリケーションの復旧をサポートする復旧検証サービスも提供しています。すでにGoogle Kubernetes Engine (GKE)をサポートしており、他のKubernetesクラウドサービスもまもなくサポートする予定です。HYCUの単一プラットフォームは、Google Compute Engine（GCE）、Google Cloud Storage、およびGKE全体でデータ保護を管理するための統一されたユーザーエクスペリエンスを提供します。

サービスとして提供されるHYCUは、コンテナ化されたアプリケーションと仮想アプリケーションの両方を保護する単一のソリューションを企業に提供します。その管理コンソールは、Kubernetesと仮想環境の両方を管理します。

HYCUを採用することで、企業は既存の仮想化環境の進化するバックアップのニーズを満たし続けることができます

HYCUは同時に、新たなKubernetesバックアップの要件に対応することができます。そうすることで、HYCUは、企業が両方の環境でデータの整合性を確保しながらKubernetesに移行するための優れた選択肢を提供します。
 

DCIGについて

Data Center Intelligence Group (DCIG)は、実用的な分析によってIT業界に力を与えます。DCIGのアナリストは、さまざまなクラウド、データ保護、およびデータストレージ技術について、情報に基づいた第三者による分析を提供しています。
詳細については、www.dcig.com.

をご覧ください。