Kubernetes上でデータを実行する方法：使用開始にあたり注意したい6つの原則【テッククランチ】

コンテナ管理プラットフォームのKubernetesは急速に業界標準になりつつある。Cockroach Labs と Red Hatの調査によると、最大94%の組織がサービスやアプリケーションをKubernetesでデプロイしているという。企業がKubernetesでデプロイする主な理由の1つは標準化で、これにより上級のユーザーは生産性を倍に高めることができる。
Kubernetesで標準化することで、組織はあらゆるワークロードをどこでもデプロイできるようになる。しかし、欠点もあった。Kubernetesはワークロードが一時的なものであることを前提としているのだ。つまり、ステートレスな（状態を保持しない）ワークロードのみがKubernetes上で安全に実行できる。ところが最近コミュニティは枠組みを変更し、「StatefulSet」や「Storage Classes」といった、Kubernetes上でのデータ利用を可能にする機能を追加した。

Kubernetes上でステートフルワークロードを実行することは可能だが、まだ難しい。この記事ではそれを実現する方法と、その価値を説明する。

• keyboard_arrow_down 第1の原則：段階的に行う
• keyboard_arrow_down 第2の原則：制限と特異性を理解する
• keyboard_arrow_down 第3の原則：計画を立てる
• keyboard_arrow_down 第4の原則：オペレーターを用意する
• keyboard_arrow_down 第5の原則：適切な能力レベルのオペレーターを選択する
• keyboard_arrow_down 第6の原則：オペレーターを理解する
• keyboard_arrow_down 取り組む価値あり

KubernetesはLinuxと同じくらい一般的で、そして実際にはあらゆるアプリケーションをどこでも分散して実行できる方法になりつつある。Kubernetesを使用することは多くの技術的な概念と用語を学ぶということだ。たとえば、初心者はコンテナ、ポッド、ノード、クラスタといった多くのKubernetes特有の用語に手を焼くかもしれない。

まだ実際にKubernetesを使用していない場合は、データワークロードにすぐさま手をつけてはいけない。その代わり、事態が思わぬ方向にいったときにデータを失わないよう、ステートレスなアプリケーションの移動から始めるといい。

ニーズに合ったオペレーターが見つけられなくても、それらのほとんどはオープンソースなので心配は無用だ。

一般的なKubernetesの概念に慣れたら、「ステートフル」という概念の詳細に取り掛かろう。例えば、パフォーマンスや容量の要件など、ストレージに関してアプリケーションのニーズは異なる可能性があるため、正しい基礎ストレージシステムを用意しなければならない。

業界では一般的にストレージプロファイル（storage “profiles”）と呼ばれているものをKubernetesでは「Storage Classes」と呼んでいる。Kubernetesクラスタがアクセスできるさまざまなタイプのクラスを表す方法だ。Storage Classesは、GiB/秒あたりのI/O操作、バックアップポリシー、または結合モードや許可されたトポロジーといった任意のポリシーなど、異なるサービス品質レベルを有することができる。

理解すべきもう1つの重要な構成要素はStatefulSetだ。これはステートフルなアプリケーションを管理するために使用されるKubernetes APIオブジェクトであり、以下のような重要な機能を持つ。

• ・ボリュームを追跡し、好きなようにデタッチ、再アタッチできるようにする安定したユニークネットワーク識別子
• ・データの安全性を確保できる安定した永続的なストレージ
• ・多くのDay2オペレーションで必要とされる、秩序ある段階を踏んだデプロイとスケーリング

StatefulSetは廃止される可能性が囁かれているPetSetの代わりとして成功しているが、まだ不完全であり、限界もある。

例えば、StatefulSetコントローラには、ボリューム（PVC）のサイズ変更をサポートする機能が組み込まれていない。これは、アプリケーションデータセットのサイズが現在割り当てられているストレージ容量を超えそうな場合、大きな問題となる。回避策はあるが、エンジニアリングチームがその対処法を用意しておけるよう、このような制限を事前によく理解しておく必要がある。

Kubernetesの「ステートフル」の概念に慣れたら、特定の順序でデータワークロードを徐々に移行することができる。すべてのデータテクノロジーがKubernetes上で同じように実行しやすいわけではないため、徐々に移行することで失敗から学び、頭を抱えるような事態を避けられる。

データベースやストレージなど確立された技術は最初に移行し、人工知能（AI）や機械学習（ML）といった最先端技術の移行は最後に行うべきだ。最近のレポートでも指摘されているが、データベースと永続的ストレージがKubernetes上で最も実行されるデータワークロードだという。その主な理由は、Day 2オペレーションのためのツールの不足だ。これについては、次のセクションで掘り下げる。

ステートフルワークロードのKubernetesへの移行は仕事の半分に過ぎない。これはDay 1としても知られている。その次は、Day 2のオペレーションに対処する必要がある（前回のKubeConカンファレンスで最も議論されたトピックの1つだ）。ここが厄介なところだ。パッチ適用やアップグレード、バックアップや復旧、ログ処理、モニタリング、スケーリング、チューニングなど、Kubernetesがネイティブに処理できないDay 2オペレーションが大量にある。

これらの操作はすべてアプリケーションによって異なる。例えば、PostgreSQLとMySQLのクラスタは、HAクラスタ構成で新しいプライマリサーバを選ぶときに全く異なる2つのアプローチを要する。Kubernetesはアプリケーション特有のDay2オペレーションをすべて把握することはできない。そこで登場するのがオペレーターだ。

オペレーターは、Kubernetesがネイティブに処理できないオペレーションを実行するプログラム可能な拡張機能だ。Kubernetes APIの機能を拡張することで、オペレーターはインテリジェントでダイナミックな管理機能を展開する。最も一般的な用途の1つは、これらのDay 2オペレーションの実施だ。オペレーターはKubernetes維持管理者ではなくサードパーティの開発者や組織が開発したものだ。

データワークロードをKubernetesに移行する前に、そのためのオペレーターを用意しておく必要がある。OperatorHubはそうしたオペレーターを素早く探し出せるようにしている。利用可能な282のオペレーターが紹介されており、ディストリビューションは先に説明したものと同じだ。サポートツールがあるワークロードもあれば、ないものもある。例えば、データベースカテゴリには38のオペレーターがあり、PostgreSQLだけでも8つあるのに対して、ML/AIカテゴリには7つしかない。

オペレーターの能力はそれぞれ異なり、成熟度もさまざまであるため、オペレーターを用意するだけでは不十分だ。OperatorFrameworkはオペレーターを機能に応じて分類する能力モデルを提案している。

• ・レベル1：自動化されたアプリケーションのプロビジョニングや構成管理など基本的なインストール
• ・レベル2：シームレスなアップグレード、パッチ適用、マイナーなバージョンアップグレードのサポート
• ・レベル3：アプリケーションとストレージのライフサイクル（バックアップ、障害復旧など）全般に対応
• ・レベル4：深い洞察、メトリクス、アラート、ログ処理、ワークロード分析の提供
• ・レベル5：自動の水平/垂直スケーリング、自動設定チューニング、異常検知、スケジューリングチューニングの提供

オペレーターを選択する際には、能力がニーズに合っていることを確認する必要がある。どのレベルが適切かわからない場合もあるだろう。「Data on Kubernetes Report 2022」によると、ほとんどの組織が少なくともレベル3以上のオペレーターを求めているという。ステートフルワークロードのバックアップを持つとよい。

もしニーズに合うオペレーターが見つからなくても、そのほとんどがオープンソースであるため、既存のオペレーターの機能を社内開発で自主的に拡張することができ、一歩進んでオープンソースのプロジェクトに貢献することもできる。

オペレーターの拡張性は強みだが、弱みでもある。標準がないため、オペレーターのプログラムはそれぞれ異なっている。したがって、最も気に入る形式を選択するのにオペレーターの設定ファイルを見る必要がある。

さらにオペレーターは同じ目標を達成するために異なる技術手法を使用することがある。例えば、8つのPostgreSQLオペレーターの1つであるCloudNativePGはStatefulSetsを使用せず、その代わり独自のカスタムコントローラを使用している。StatefulSetsがKubernetes上のステートフルワークロードの基盤であることを考えると、これはかなり意外だ。

StatefulSetが（先に説明したように）PVCのサイズを変更できないことから、CloudNativePGの開発者はカスタムコントローラを採用することにした。CloudNativePGの資料で説明されているように「異なるもの（設計指示）を選ぶと、他の妥協につながる」。そのため、オペレーターを選ぶときは実行できること、そしてそれと引き換えに実行できないことを必ず理解し、最も使いやすいものを選ぶ必要がある。

このように、Kubernetes上でのデータ運用は必ずしも簡単ではないが、良いニュースとしては、真摯に取り組む価値があるということだ。調査対象の組織の54%は、Kubernetes上でのデータ実行が売上高の10%以上に貢献していると回答した。さらに33%が生産性に変革的な影響を与えると回答し、51%が多大な好ましい影響があったと回答した。

コストとインフラのパフォーマンスを最適化するためにマルチクラウドインフラを採用する組織が増える中、Kubernetesは選ばれるツールとなっている。推定66%の国々が何らかのデータプライバシーおよび消費者の権利に関する法律を制定しており、多くの場合、データ主権を強制する必要があるため、企業はますますユーザーデータを事業展開している国でホストしなければならなくなっている。Kubernetesは定着するだろう。

From TechCrunch. © 2022 Verizon Media. All rights reserved. Used under license.

元記事：How to run data on Kubernetes: 6 starting principles
By：Sylvain Kalache
翻訳：Nariko