このドキュメントでは、最適化されたアプリケーション レベルとノードレベルの構成を生成して、Google Kubernetes Engine(GKE)で MySQL ワークロードのパフォーマンスを改善する方法について説明します。詳細については、GKE のワークロード向けに最適化するをご覧ください。
MySQL の最適化は、SSL を使用する単一ノードのオンライン トランザクション処理データベース(「読み取り/書き込み OLTP」)として使用される MySQL 8 インスタンス用に決定されました。パフォーマンスは Sysbench 1.1.0 を使用して測定されました。このユースケースと比較して、クラスタで MySQL ワークロードがどのように使用されているかを検討します。ユースケースが異なる場合は、推奨される最適化をコンテキストに合わせて調整する必要があります。
始める前に
作業を始める前に、次のタスクが完了していることを確認してください。
- GKE Recommender API と Google Kubernetes Engine API を有効にします。 API を有効にする
- このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化します。gcloud CLI をインストール済みの場合は、
gcloud components updateコマンドを実行して最新のバージョンを取得します。以前のバージョンの gcloud CLI では、このドキュメントのコマンドを実行できない場合があります。
要件
GKE バージョン 1.31.1-gke.12000 以降を使用します。
MySQL ワークロード用に最適化する
MySQL ワークロードには専用のノードプールを使用することをおすすめします。デフォルトでは、次の手順を完了すると新しいノードプールが作成されます。
MySQL ワークロードのパフォーマンスを最適化するには、次の操作を行います。
MySQL ワークロード用に最適化されたマニフェストを作成します。
次のコマンドを実行して、推奨される最適化を含むマニフェストを生成します。
gcloud container workload profiles manifests create \ --workload=mysql-8-oltp --cluster-version=CLUSTER_VERSION --options=machineType=MACHINE_TYPE \ --output-path=/tmp/manifests.yaml次のように置き換えます。
CLUSTER_VERSION: GKE のバージョン。推奨バージョンは GKE バージョン 1.31.1-gke.12000 以降です。MACHINE_TYPE: 必要なマシンタイプ。
--output-path=/tmp/manifests.yamlフラグは省略可能です。指定されていない場合、マニフェストはターミナルに出力されますが、ファイルには保存されません。このコマンドは、2 つの Kubernetes リソースを含む単一の YAML ファイルを生成します。
default-auth.cnfという名前の MySQL 構成を指定する ConfigMap。- ComputeClass オブジェクト。これは、MySQL が実行されるマシンを指定します。省略可能です。マシンタイプの指定方法の詳細については、カスタム ComputeClass についてをご覧ください。
推奨事項を確認し、マニフェストを変更して、推奨される最適化を含めます。推奨事項を評価するには、次の操作を行います。
- MySQL のドキュメントを確認して、コンテキストに適した推奨構成を評価します。
- 次のユースケースと比較して、クラスタで MySQL ワークロードがどのように使用されているかを検討します。ユースケースが異なる場合は、推奨される最適化をコンテキストに合わせて調整する必要があります。
MySQL の最適化は、SSL を使用した単一ノードのオンライン トランザクション処理データベース(「読み取り/書き込み OLTP」)として使用される MySQL 8 インスタンス用に決定されました。パフォーマンスは Sysbench 1.1.0 を使用して測定されました。
構成を変更したり、構成に追加したりする場合は、マニフェスト ファイルを編集します。
次のコマンドを使用して、マニフェストをクラスタに適用します。
kubectl create -f /tmp/manifests.yaml
最適化を参照する Pod をデプロイします。次に例を示します。
apiVersion: v1 kind: Pod metadata: name: mysql spec: containers: - name: mysql image: mysql:8 volumeMounts: - name: gke-optimized-workload-config subPath: default-auth.cnf mountPath: /etc/mysql/conf.d/gke-optimized.cnf readOnly: true volumes: - name: gke-optimized-workload-config configMap: name: mysql-config nodeSelector: cloud.google.com/compute-class: optimized-gke-mysql-8-oltp-abc123生成された ComputeClass の名前に一致するように変更します。次に、Pod マニフェストをクラスタに適用します。
kubectl apply -f pod.yamlMySQL が最適化された構成を使用していることを確認します。これを行うには、次のコマンドを実行して、MySQL が最適化された構成を使用していることを確認します。
kubectl exec mysql -- mysql -e "SELECT DISTINCT VARIABLE_PATH FROM performance_schema.variables_info WHERE VARIABLE_PATH != '';"出力は次のようになります。
VARIABLE_PATH /etc/mysql/conf.d/gke-optimized.cnf /etc/my.cnfmysqlコマンドを使用して、max_connectionsなど、最適化された構成で設定されている個々のディレクティブをクエリすることもできます。
ワークロードをデプロイすると、クラスタは最適化された構成に準拠する新しいノードプールを作成し、Pod をこれらのノードプールに割り当てます。
すでに存在する Pod は変更されません。最適化された構成を参照する Pod のみが最適化されます。クラスタに MySQL ワークロードを以前にデプロイしたことがある場合は、これらのワークロードを再デプロイして、最適化された構成で実行する必要があります。
次のステップ
- GKE でのワークロードの最適化について学習する。
- ステートフル MySQL クラスタを GKE にデプロイする方法を確認する。
- GKE ComputeClass についての詳細を確認する。
- Redis ワークロードを最適化するには、GKE で Redis ワークロードのパフォーマンスを最適化するをご覧ください。