Kubernetes環境への円滑な移行は、遅かれ早かれIT部門が直面する課題。でも、そこには思わぬ落とし穴も・・・
コンテナ環境、特にKubernetesの普及が近い将来一気に進む可能性のあることは、前回のブログ「国内企業のコンテナ普及率が二桁の大台に」で取り上げました。
当然ながら、既存の環境からKubernetes環境への移行をいかに円滑に、効率よく進めるかが、各企業のIT部門が抱える喫緊の課題になってくるはずです。
そこで陥りがちな過ちは、既存の環境に合わせたデータ保護ソリューションを、新しいKubernetes環境にそのまま当て嵌めてしまうことです。これは当事者の立場になって考えたら、致し方ないことです。さんざんお金と時間と労力をかけて築き上げた、すでに機能しているツールを、そのまま使いたくなるのは人間のさがです。
それに、Kubernetes環境に展開されたアプリケーションは、Kubernetes自体の機能で複数のサーバーに分散され、パフォーマンスの最適化と障害耐性が確保されるわけで、アプリケーションのコンポーネントとデータの管理はKubernetesに任せれば良いという考え方も成り立ちます。それを包含する従来のインフラストラクチャに対して、従来のバックアップとリカバリのソリューションを適用すれば、Kubernetesの導入完了、これで我が社もクラウド ネイティブの仲間入り！と言えないこともありません。
でも、ここは慌てず、一歩下がって冷静に戦略を俯瞰してみてください。
まず、Kubernetesによるアプリケーション コンポーネントの分散管理は流動的です。全体のバランスに応じて配置が常に調整しなおされ、IPアドレスもその都度変わる可能性があります。既存のバックアップとリカバリのソリューションがそれに対応できるでしょうか？
まして、Kubernetesがアプリケーションを複数サーバーに分散するとき、別のアプリケーションが部分的に同一のサーバーに共存することが少なくありません。Kubernetesは、個々のアプリケーションの視点から、その全コンポーネントを管理するので、各サーバーに何を任せるかという役割を固定するような従来式の既成概念はありません。インフラストラクチャの視点に立つ従来式のバックアップ ソリューションには手に余るどころか、ほとんど異次元の世界にならないでしょうか？ 「まったく今どきの若いもんは一体何を考えているのか」と、従来式ソリューションのぼやきが聞こえてきそうです。
Kubernetes管理下に置かれたデータベースも含めて、まるごと全部バックアップしちゃえば済む、というアイデアもあるかもしれません。でも、仮にアプリケーションにコーディングのミスがあって、それが誤ってデータを削除してしまうようなミスの場合、データのバックアップが独立していないと、気が付いたらバックアップのデータも欠損していたということになりかねません。Kubernetesが良かれと思ってコンポーネントをレプリケーションして、あちこちのサーバーに再現したら、データ喪失の被害が拡大する危険性も否めません。
結論を言うと、Kubernetes環境のデータ保護は、Kubernetes専用ソリューションに任せたほうが安全です。Kubernetes特有の、柔軟にスケーリングして臨機応変に配置換えする動的な環境構成に対応でき、アプリケーションの視点からデータを管理できるツールが理想的です。
そして、データセット全体の完全コピーを単独で保持できるしくみも重要です。Kubernetes環境のデータサービス オプションはいろいろありますが、この観点から言えば、Kubernetes独自のAPIを通じて、外部ストレージでデータを管理するのが理想的と言えます。
もっと言えば、Kubernetesの導入と同時に、CI/CDパイプラインを実装して、前述のコーディング ミスのような状況を開発プロセスの早い段階で除去できるしくみを確立できたら、なお良いです。欲を言えば、きりがないですが・・・
とりえあず、Kubernetes専用のデータ保護ソリューション（特にKasten K10のようなアプリケーションの視点からデータを管理できるツール）の採用は、ぜひ検討してみてください。
RSSフィードを取得する
