Kubernetesネイティブなバックアップソリューションを採用すべき7つの理由

投稿日: 2021年3月31日 作成者: クライム
このエントリーをはてなブックマークに追加
LINEで送る

ネイティブ・バックアップがベストな選択 – その理由は？

仮想マシンに使われるようなレガシーなバックアップツールを利用したいと思うかもしれませんが、コンテナ化されたKubernetes環境ではそれが良い発想ではないという重要な理由がいくつかあります。

実際、従来のバックアップソリューションを使ってKubernetesアプリケーションをバックアップすると、データ損失のリスクが高まる可能性があります。これは、コンテナの性質と、コンテナ内のステートフル・コンポーネントとステートレス・コンポーネントの組み合わせによるものです。アプリケーションを復旧するためには、データと状態を保存する必要がありますが、ステートフル・コンポーネントはデータと状態を永続的なストレージボリュームに保持しますが、ステートレス・コンポーネントはそうではありません。ステートレスコンポーネントを別の場所にバックアップせずにアプリケーションを復旧すると、リストアの失敗、設定ミス、データの消失などが発生します。

Kubernetesネイティブのバックアップソリューションは、リスクを低減し、リカバリ時間を短縮するだけでなく、バックアップをより効率的に実行するための重要な利点を提供します。拡大するKubernetes環境を守るために、なぜKubernetesネイティブなバックアップソリューションが最適なのかを検証します。

1.Kubernetesのデプロイメント・パターンに対応
コンテナ化されたアプリケーションでは、いかなるサーバや仮想マシンへのマッピングもありません。アプリケーションのコンポーネントは、フォールトトレランスとパフォーマンスを向上させるために、すべてのサーバに分散されます。そのため、従来のバックアップソリューションでは、他のデータを収集せずに特定のアプリケーションの状態を把握することができず、その結果として設定ミスが発生する可能性があります。従来のソリューションはアプライアンス中心で、VMをバックアップするために設計されていましたが、Kubernetesネイティブのソリューションは、コンテナ化されたアプリケーションの動的な側面に適応し、コンテナのニーズやコンテンツの変化に合わせてロードバランシングを行い、リアルタイムに変更を発見し、すべてのアプリケーションのコンテキストを取得することができます。

2.シフトレフト（Shift-left）：前倒し)の開発に沿ったもの
Kubernetesは迅速な開発サイクルを可能にします。そのユニークなデザインは、アプリケーション中心のバックアップソリューションと、DevOpsの「シフト・レフト」哲学との調和を必要とします。シフトレフト方式では、開発者がアプリケーションやインフラのコンポーネントをコードとして定義し、プログラムの要求に応じて動的にプロビジョニングを行います。シフトレフトはアジャイルな開発環境の要ですが、設定ミスによるデータ消失のリスクがあります。Kubernetesのバックアップと保護のためには、開発者がアプリケーションやパッケージに変更を加えることなく、新しいアプリケーションや変更されたアプリケーションを自動的に検出する必要があります。また、導入の障壁を取り除くために、ソリューションはAPIドリブンでなければなりません。

3.オペレーションが簡単に
スキルギャップは実際にあります。多くの開発者は、LinuxやvSphere環境でしか仕事をしたことがないままKubernetesにやってくるため、バックアップツールがCLIアクセスと使いやすいダッシュボードを提供することが重要です。これにより、ギャップを埋め、根本的な複雑さを隠して、バックアップのワークフローを簡素化することができます。このようにして、オペレータはクラスタ内の何百万ものコンポーネントを保護する方法を理解したり、リストアされたボリュームでアプリケーションを更新するために雑多な手動タスクを実行する必要がなくなります。

4.マルチクラスターのスケーラビリティに対応
Kubernetesクラスター内の何百万もの個別のコンポーネントを扱うには、アプリケーション、データ、Kubernetesの状態の関係を把握し、理解できるソリューションが必要です。また、アプリケーションやクラスタの変更に動的に対応し、使用していないときにはゼロにまでスケールダウンできることが必要です。この要件は、Kubernetesのマルチクラスター構成の使用が増加していることにより、さらに悪化しています。これらの構成は、環境、チームやアプリケーションの境界、地域、クラウド、オンプレミスのデータセンターに分散していることがよくあります。マルチクラスターの拡張性に対応したソリューションは、運用上の大きな負担をなくし、チームの時間とコストを削減します。

5.保護のギャップを埋める
Kubernetesはフォールトトレランスのために設計されていますが、レプリケーションはバックアップではありません。クラウドであっても、レプリケーションはデータの破損や削除に悩まされることがあります。オンプレミスのストレージのスナップショットを考えてみてください。スナップショットはハードウェアの故障に耐えられないことが多く、1つ削除すると関連するスナップショットも失われる可能性があります。さらに、バックアップのためにファイルシステムを静止させるには、高度なセキュリティ権限が必要になることもあります。ネイティブなソリューションは、セキュリティを犠牲にすることなく、バックアップのためにデータを準備することができます。そして、オペレータのワークフローを複雑にすることなく、幅広いアプリケーションスタックや導入方法に対して透過的に動作します。

6.セキュリティを強化
従来のバックアップソリューションでは、クラスタ内のアイソレーション（隔離）ポリシーを弱めなければ、アプリケーションの検出はもちろん、アクセスや静止もできません。対照的に、Kubernetesネイティブのソリューションは、コントロール・プレーンに自身を埋め込み、これらの制限を回避することができます。ロール・ベースド・アクセスコントロール（Role-based access control：RBAC）は重要な要件であり、Kubernetes内で定義された役割に合わせて、セルフサービス機能をサポートし、開発者が追加のロール管理システムを習得する必要性を最小限に抑えることが出来ます。

ネイティブ・バックアップ・システムは、Kubernetesの証明書管理とストレージに統合されたキー管理システム（KMS）を理解し、Kubernetes Secretsインターフェースを通じてCustomer-Managed Encryption Keys（CMEK）をサポートし、プレーンテキストでアプリケーション・データを転送しないようにします。また、マルウェアやランサムウェアから保護するために、独立したバックアップを実行することができ、迅速で自動化されたリストアを可能にするために、難解なプラットフォームの統合が必要となるでしょう。

7.クラウド・ネイティブ・エコシステムとの統合
開発エコシステムは、複数のデータサービス（MongoDB、MySQL、Cassandraなど）を含むように拡大しており、これらが同じアプリケーション内で使用されることもよくあります。Kubernetesネイティブのバックアップ・ソリューションは、サービス内とサービス間の両方で、アプリケーションスタック全体の一貫したコピーをキャプチャすることができます。また、レプリカを識別し、そこからデータを収集することで、アプリケーションへの影響を軽減し、パフォーマンスと効率を向上させることができます。より多くの組織が異なる環境でKubernetesクラスターを実行するようになると、開発者やオペレータが慣れ親しんだクラウド・ネイティブ・ツール（PrometheusやKubernetes APIによるロギングや原因分析など）とバックアップを統合できることが重要になります。

ネイティブバックアッププランでデータ損失を防ぐ

開発チームにとって定期的なバックアップは標準的な手順ですが、Kubernetesの導入が進むにつれ、データの保護とセキュリティ、そして企業アプリケーションの信頼性と可用性を確保するために、従来のバックアップ方法を見直す必要が出てきました。

しかし、Kubernetesは他の開発環境とは異なり、重要なアプリケーションデータとストレージをバックアップするための新しいアプローチを必要とする独自の特性を持っています。従来のアプライアンス・ベースのアプローチでは対応できませんし、レプリケーション・サービスに頼るのもリスクが伴います。Kubernetesネイティブのバックアップ・ソリューションは、開発者のワークフローを中断させたり、イノベーションを阻害するような複雑さを加えることなく、安全で信頼性の高いデータバックアップを確保する唯一の方法です。

関連トピックス:
カテゴリー: クラウド・仮想インフラ タグ: , , パーマリンク

コメントを残す

メールアドレスが公開されることはありません。

 

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。

この記事のトラックバック用URL