ハイパフォーマンスMySQL 第4版

付録B. Kubernetes上のMySQL

、過去5年間に少しでも技術系の仕事をしていれば、Kubernetesについて聞いたことがあったり、Kubernetesを実行しているチームで仕事をしていたり、Kubernetesについて説明するカンファレンスでの講演をたくさん見たり、ブログ記事をたくさん読んだりしている可能性が非常に高い。もしあなたの組織が独自のKubernetesクラスタを運用しているのであれば、MySQLをKubernetesクラスタ上で運用するのは良いアイデアなのかと質問されることもあるだろう。そして表面的には、それは合理的なパスのように思える。多くのKubernetesクラスタを管理するのは複雑なタスクであり、一般的には専用の人的リソースが必要である。そして、その専門知識をステートレスワークロード以外にも活用したいと考えるのは、組織として妥当なことだ。しかし、Kubernetes上でMySQLを実行することを検討する良い理由もあれば、そうでない理由もある。ここでは、Kubernetes上でのMySQL実行にまつわるFUD（恐怖、不確実性、疑念）のいくつかを解明しよう。

Kubernetesでリソースをプロビジョニングする

Kubernetesの人気がピークに達する前は、多くの企業が仮想マシンやベアメタルサーバのプロビジョニングと管理のために完全にオーダーメイドの技術スタックを構築するか、リソースのライフサイクルの小さな部分を行うオープンソースプロジェクトをつなぎ合わせていた。その後、コンピューティングリソースとストレージリソースの両方を管理するための、より完全なエコシステムとしてKubernetesが登場し、すべてを支配するプロビジョニングスタックとしてKubernetesを使用することがますます魅力的になってきた。しかし、MySQLのようなステートフル・ロードは、"コンテナ上でデータベースを実行することはできない "という常識があったため、その付加価値から取り残されたままだった。

ゴールの範囲を慎重に決める

念頭に置くべき重要なことは、"ここで具体的にどのような価値を取り戻したいのか "ということだ。Kubernetesはステートレスロードにとって強力であり、それはコンピューティングリソースの弾力性と効率性をもたらすからだ。しかし、ユニファイド・プロビジョニング・スタックを検討する際、"データベース・リソースのプロビジョニングとシステム構成にのみKubernetesを使いたい "と、勝利の範囲を狭めるのは合理的だ。つまり、Kubernetesでプロビジョニングされるデータベースワークロードは、ステートレスワークロードとは別に管理され、異なる演算子のスキルセットが必要となり、コンテナ障害の処理も異なることを、前もって明確にしておく必要がある。

コントロールプレーンを選ぶ

現在、さまざまなMySQL演算子が世に出回っているが、どれがベストなのかは、KubernetesでMySQLを管理する範囲をどうするかによって決まる。プロビジョニング、フェイルオーバー、データベースへの接続管理など、すべてを行う演算子が必要なのか。それとも、単にKubernetesをプロビジョニングスタックとして使用し、サービス開始後のデータベース管理には別の手段を使うのか？コントロールプレーンに何を期待するかは、より細かい演算子の詳細の多くを動かすことになるので、早めに決めておくこと。

細かいディテール

Kubernetesを使ってMySQLリソースのプロビジョニングを開始することを決めたら、このソリューションに適したデータサイズについて組織全体の合意を得る必要がある。これは今やリレーショナルデータベースを運用するための新しい演算子であり、この舗装されていない道では、規模が大きくなるにつれてすべてが複雑になっていくことを忘れてはならない。ステートフルなワークロードをサポートする方法について、Kubernetesエンジニアリングチーム（できればこのための専任チームがあるといい）と協業する際に考慮すべき重要な項目をいくつか紹介しよう： ...