Kasten K10 Version 2.5 リリース


クラウド ネイティブ環境でアプリケーションの可用性を実現するデータ/アプリケーション トランスフォーメーション エンジン

緊急事態に備えるコンティンジェンシープランの必要性が、今日ほど明らかになったことがかつてあったでしょうか。アプリケーションの可用性を実現し、業務に支障をきたさないようにすることが、緊急課題になっています。一方で、Kubernetesを用いたアプリケーションが加速度的な勢いで企業の業務環境に取り入れられています。このような情勢の中、Kastenのクラウド ネイティブのデータ管理プラットフォームK10のバージョン2.5のリリースを発表できるのは、とても意義深いことです。

世界ではすでにK10を採用している有力企業が多々存在します。新バージョンには独自のCloud-Native Transformation Frameworkが追加され、Kubernetesアプリケーションのバックアップとモビリティにおいて非常に重要な2つの機能を提供します。データ トランスフォーメーションとアプリケーション トランスフォーメーションです。この2つの機能は、K10の2つの柱、すなわちセキュリティと運用のシンプルさの上に成り立ち、データにクラウド ネイティブなスケールをもたらし、デプロイメントの可搬性と柔軟性を実現します。

データ トランスフォーメーション エンジン(Data Transformation Engine)

企業のアプリケーションをクラウド ネイティブなマイクロサービスに移行することで得られる効果については、すでに各方面で再三にわたって論じられています。Kastenはそれを一歩先に進め、アプリケーションの基盤となるデータ トランスフォーメーション エンジンにおいて、同じ効果を実現したいと考えました。データ トランスフォーメーション エンジンには、データ移管、重複排除、圧縮など、業務上不可欠な重要データを管理するさまざまな機能が含まれます。

アプリケーションのユーザーの視点に立って各種機能を提供する「アプリケーション中心型」のアイデアは、当初からKastenの設計概念の核を成していました。この理念を進化させ、K10バージョン2.5では、すべてのアプリケーションに独自のデータ トランスフォーメーション エンジンを提供します。各アプリケーションに個別対応することで、データ トランスフォーメーション エンジンはより速く、小さく、安全になります。下図は、その設計上のいくつかの重要な原理を表しています。さらに、ハイパーバイザー環境に対するモノリシックな従来の設計アプローチとの比較も付記されています。

では、重複排除のタスクを例にとって見ていきましょう。マイクロサービスを基本とする革新的なアプローチでは、データ トランスフォーメーション エンジンによって以下の効果がもたらされます。

  1. データ取り込みの効率化:個々のアプリケーションが独自のデータ トランスフォーメーション エンジンをインスタンス化するので、データ移転、ハッシュ化、最適化を含め、タスクの並行処理が可能になり、フォールト ドメインもより小さくなります。
  2. サーバーレス、ソース側で重複排除:スケールアップが可能であると同時に、スケールダウンもゼロまで可能でアイドル サイクルが不要です。クライアント側に実装される従来型のアプローチに必要なピーク時に合わせたキャパシティ調整も要りません。

アプリケーション トランスフォーメーション エンジン(Application Transformation Engine)

Kubernetesは、クラウド ネイティブのエコシステムにアプリケーションの可搬性を約束し、大きな効果をもたらしています。可搬性という言葉は意味が広く、たとえば、以下のように対象が広範に及ぶケースが考えられます。

  • ストレージ システムとKubernetesの複数バージョン  ― アプリケーションのリストア時
  • Kubernetesの複数のネームスペースとAZ(Availability Zone)― アプリケーションのクローン時
  • 複数のリージョンやクラウド プロバイダ  ― アプリケーションのマイグレーション時

リストア、クローン、マイグレーションなど、業務上欠かせない重要データ管理のさまざまなユースケースにわたって、真のアプリケーションの可搬性を達成するには、以下を含めたトランスフォーメーションに対応できなければなりません。

  1. インフラストラクチャ
    • 例:リストアまたはクローン時におけるストレージ タイプの変更(たとえば、HDDからSSDへ)
  2. Kubernetes環境
    • 例:業務環境からテスト環境へのクローン(アプリケーション内のDNSネーム変更が必要な場合)
  3. アプリケーションのスペック
    • 例:アプリケーションのスキーマを部分的に変更して、古くなったsecretを削除したり、スキーマ定義の更新を反映するためのスペック更新

これにより、企業はさまざまなインフラストラクチャ、クラウド、Kubernetes環境における選択の自由を手に入れることができます。つまり、アプリケーション トランスフォーメーション エンジンにより、CloudOpsチームがアプリケーションの可用性を巨大スケールで提供できるようになります。K10の豊富なAPIとポリシーを活用した自動化は、極めて効率的なDevOpsアプローチを可能にします。

下図の左側はKubernetesアプリケーションの構成の例です。アプリケーションがさまざまなPodで稼働するマイクロサービスから構成されています。PodのいくつかはPV(永続ボリューム)とPVC(永続ボリューム クレーム)の結束を通じてストレージ ボリュームと関連付けられ、他のPodにはPostgreSQLなどのデータベースを稼働するものもあります。これに加え、通常は、ConfigMap、Secretなどを含む他のKubernetesオブジェクトが数百件ほど存在する場合があります。それらにトランスフォーメーションが必要なアプリケーションのコンストラクトが含まれることになります。K10は、このKubernetesアプリケーション全体をこれ以上分解できない単独ユニットとしてトランスフォーメーションを適用し、インフラストラクチャやKubernetes環境全般を通じての可用性を実現します。

トランスフォーメーションの各種オペレーション(テスト、追加、コピー、移動、置き換えなど)の詳細や、その機能性についてはK10の関連ドキュメンテーションを参照してください。また、K10のダッシュボード画面には、上述の各種オペレーションをすべて含め、高度なリソース選択やニーズに合わせた指定を可能にするトランスフォーメーションの操作機能がわかりやすく表示されます。

実用例

最後にKasten K10のデータ/アプリケーション トランスフォーメーション エンジンの効果を、実際の顧客サイトでの実用例を通じて見ていきましょう。このケースでは、CloudOpsチームがRedHat OpenShiftで稼働する170件以上のアプリケーション(18,000以上のコンポーネントから構成)のマイグレーションをAWSの他のクラスタに対して行うことを希望していました。Kubernetes環境の大きな違いに加え(OCP v3.11からOCP v4.3まで5リリースにまたがるマイグレーション)、コンテナのランタイム(DockerからCRI-O)、コンテナのレジストリ、そして基盤となるストレージもEBSと外部のCephクラスタの組み合わせからEBSとKubernetesネイティブのCephクラスタ(Rookで管理)の構成に変わる非常に大がかりなものでした。

このマイグレーションは、さまざまなアプリケーションが使用される業務に支障をきたさぬよう、週末に行われました。マイグレーションの規模の大きさと時間的な制約のため、クラウド ネイティブ環境におけるスケールアップと、同時にゼロまでスケールダウンできる機能が重要な役割を果たしました。これらの機能はデータ トランスフォーメーション エンジンの設計概念で言及したとおりです。

多様なインフラストラクチャとKubernetes環境もさまざまなアプリケーション トランスフォーメーションを必要としました。上記の表は、このマイグレーションに対する自動化ポリシーで各種リソースに適用されたアプリケーション トランスフォーメーションの一部をリストアップしたものです。K10のアプリケーション トランスフォーメーション エンジンの機能性により、たった二人のスタッフが週末だけでマイグレーションを完了し、アプリケーションの変更や専門サポートを必要とせずに、700名以上の開発者をサポートすることができました。

上記の例はマイグレーションのユースケースですが、ストレージ システム、ネームスペース、AZ、クラスタ、クラウド プロバイダなど多種多様な環境にまたがるリストアやクローンといった他のデータ管理ユースケース全般に当てはまります。Kasten K10バージョン2.5のパワフルな機能性と柔軟性をぜひお試しください。

関連トピックス

コメントを残す

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

 

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