クラウドネイティブなDBを使ってみよう！Kubernetes で TiDB を構築・運用する際のポイントを紹介 / how to use tidb with kubernetes

DB TECH SHOW 2021 での発表資料です
「クラウドネイティブなDBを使ってみよう！Kubernetes で TiDB を構築・運用する際のポイントを紹介 」

Transcript

1. DB TECH SHOWCASE 2021 クラウドネイティブな DB を使ってみよう！ Kubernetes で TiDB を構築・運用する際のポイントを紹介 @makocchi
2. 2 Makoto Hasegawa Working at // CIU, CyberAgent, Inc Currently // Develop and maintain private OpenStack cloud. Develop and maintain Kubernetes as a Service platform. Kubernetes organization member (sig-docs-ja) CKA / CKAD / CKS Job Title // Technical Lead Infrastructure Engineer WHO am I Twitter // @makocchi Facebook // makocchi0923 Hobby // Playing bass
3. DB TECH SHOWCASE 2021 | @makocchi #dbts2021 3 💪 本日のアジェンダ💪 TiDB について理解しよう Kubernetes で TiDB を構築する際のポイント Kubernetes で TiDB を運用する際のポイント まとめ
4. DB TECH SHOWCASE 2021 | @makocchi TiDB と Kubernetes の組み合わせ方について一緒に学んでいきましょう👌 よろしくお願いします！
5. DB TECH SHOWCASE 2021 | @makocchi 5 TiDB とは TiDB は HTAP ワークロードをサポートするオープンソースの NewSQLデータベースです TiDB は MySQL と互換性があり、水平方向のスケーラビリ ティ、強力な一貫性、および高可用性を備えています 主に PingCAP 社によって開発されています https://github.com/pingcap/tidb ※ TiDB の Ti は Titanium の Ti ※ HTAP は Hybrid Transactional and Analytical Processing
6. DB TECH SHOWCASE 2021 | @makocchi 6 TiDB の特徴 Horizontal Scalability (水平拡張) MySQL Compatible Syntax (MySQL 互換) Distributed Transactions (分散トランザクション) Cloud Native (クラウドネイティブ志向) Minimize ETL (OLTP と OLAP のサポート) High Availability (高可用性)
7. DB TECH SHOWCASE 2021 | @makocchi 7 TiDB の特徴 Horizontal Scalability (水平拡張) MySQL Compatible Syntax (MySQL 互換) Distributed Transactions (分散トランザクション) Cloud Native (クラウドネイティブ志向) Minimize ETL (OLTP と OLAP のサポート) High Availability (高可用性)
8. DB TECH SHOWCASE 2021 | @makocchi 8 TiDB の特徴 (Horizontal Scalability) TiDB はアーキテクチャ上 SQL を処理するコンポーネント とストレージ部分が分離されています それぞれの単位(SQL、ストレージ)で水平に拡張が可能で す (単純に増やすだけ！) 無停止で水平拡張可能 従来のデータベースでは垂直にしか拡張できない(リソース を追加で割り当てる)場合が多いと思いますが、垂直の拡張 は限界があります
9. DB TECH SHOWCASE 2021 | @makocchi TiDB の特徴 (Horizontal Scalability) https://github.com/pingcap/tidb この単位でスケール可能 この単位でスケール可能
10. DB TECH SHOWCASE 2021 | @makocchi 10 TiDB の特徴 Horizontal Scalability (水平拡張) MySQL Compatible Syntax (MySQL 互換) Distributed Transactions (分散トランザクション) Cloud Native (クラウドネイティブ志向) Minimize ETL (OLTP と OLAP のサポート) High Availability (高可用性)
11. DB TECH SHOWCASE 2021 | @makocchi 11 TiDB の特徴 (MySQL Compatible Syntax) MySQL 5.7 と互換があるように作られています 既存の MySQL のクライアントやライブラリはそのまま使 うことが可能 ただし完全に対応しているわけではないので注意が必要 ほとんどの場合はアプリケーションに手を加えることなく データベースを入れ替えることができます https://docs.pingcap.com/tidb/stable/mysql-compatibility
12. DB TECH SHOWCASE 2021 | @makocchi 12 TiDB の特徴 (MySQL Compatible Syntax) MySQL 8.0 互換はもう少し時間がかかりそう・・？
13. DB TECH SHOWCASE 2021 | @makocchi 13 TiDB の特徴 Horizontal Scalability (水平拡張) MySQL Compatible Syntax (MySQL 互換) Distributed Transactions (分散トランザクション) Cloud Native (クラウドネイティブ志向) Minimize ETL (OLTP と OLAP のサポート) High Availability (高可用性)
14. DB TECH SHOWCASE 2021 | @makocchi 14 TiDB の特徴 (Distributed Transactions) TiDB では内部でデータをチャンク(Region)に分割して分散配 置します 一貫性を保つ為に 2PC(2-phase commit) 等、様々な技術が採 用されています 2PC 等の技術については下記の資料に詳しく書いてあります https://www.slideshare.net/akiomitobe/tidb-249788408 「TiDBのトランザクション」
15. DB TECH SHOWCASE 2021 | @makocchi 15 TiDB の特徴 Horizontal Scalability (水平拡張) MySQL Compatible Syntax (MySQL 互換) Distributed Transactions (分散トランザクション) Cloud Native (クラウドネイティブ志向) Minimize ETL (OLTP と OLAP のサポート) High Availability (高可用性)
16. DB TECH SHOWCASE 2021 | @makocchi 16 TiDB の特徴 (Cloud Native) クラウド環境(Public や Private、そして hybrid)に親和性 が良い作りになっています(複数のコンポーネントで構成さ れている点等) それぞれのコンポーネントは自由にスケールさせることが できます TiDB のストレージ部分は TiKV というソフトウェアで実現 されていますが、TiKV は CNCF によって管理されていま す(Guraduated)
17. DB TECH SHOWCASE 2021 | @makocchi 17 TiDB の特徴 Horizontal Scalability (水平拡張) MySQL Compatible Syntax (MySQL 互換) Distributed Transactions (分散トランザクション) Cloud Native (クラウドネイティブ志向) Minimize ETL (OLTP と OLAP のサポート) High Availability (高可用性)
18. DB TECH SHOWCASE 2021 | @makocchi 18 TiDB の特徴 (Minimize ETL) TiDB は OLTP と OLAP を同時にサポート(HTAP)しています ETL に読ませるために、わざわざ分析用のデータに変換する必 要がありません (別途 TiFlash というコンポーネントを動か す必要があります) あと実は MySQL のインターフェイスだけではなくて Spark のインターフェイスも使うことができます (TiSpark) ※ OLTP : On Line Transaction Processing ※ OLAP : On Line Analytical Processing ※ HTAP : Hybrid Transactional Analytical Processing
19. DB TECH SHOWCASE 2021 | @makocchi 19 TiDB の特徴 Horizontal Scalability (水平拡張) MySQL Compatible Syntax (MySQL 互換) Distributed Transactions (分散トランザクション) Cloud Native (クラウドネイティブ志向) Minimize ETL (OLTP と OLAP のサポート) High Availability (高可用性)
20. DB TECH SHOWCASE 2021 | @makocchi 20 TiDB の特徴 (High Availability) TiDB を構成するコンポーネント達はそれぞれ冗長化が可能 です TiDB は内部の TiKV にデータを保存していますが、Raft を使ってチャンクを冗長して配置しています TiKV 側では障害が発生しても Raft によって Leader Election が行われ、自動でアクセス先が切り替わります アクセス頻度が高いノード(ホットスポット)が発生した場合 は自動的にデータが移されて負荷分散されます
21. DB TECH SHOWCASE 2021 | @makocchi 21 TiDB の特徴(再掲) Horizontal Scalability (水平拡張) MySQL Compatible Syntax (MySQL 互換) Distributed Transactions (分散トランザクション) Cloud Native (クラウドネイティブ志向) Minimize ETL (OLTP と OLAP のサポート) High Availability (高可用性)
22. DB TECH SHOWCASE 2021 | @makocchi TiDB に弱点は無いのでしょうか？
23. DB TECH SHOWCASE 2021 | @makocchi 23 個人的に思う TiDB の弱点 TiDB は分散されてデータが配置されており、SQL を処理す るコンポーネントもストレージ部分と切り離されている性質 上、どうしてもトランザクションにネットワーク等の latency が乗ってくることになります つまり数 ms 以内でクエリを返さなければならない要件の システムには不向き💦 また、データは通常 3 つに冗長されて保存されるのでスト レージはそれなりに膨らむでしょう Stored Procedure や Trigger や UDF 等はまだ対応して いないのもちょっと残念なポイント
24. DB TECH SHOWCASE 2021 | @makocchi 24 Kubernetes で TiDB を構築する際のポイント
25. DB TECH SHOWCASE 2021 | @makocchi 25 そもそも TiDB には・・・ 「tiup」という超絶便利な構築ツールがある💪
26. DB TECH SHOWCASE 2021 | @makocchi 26 tiup とは TiDB をインストール、管理するためのツール TiDB の構成情報を yaml で定義し、tiup に読み込ませることで TiDB を自動で構築することが可能 構築するだけではなくて sysctl の設定やチューニング等もやって くれる 構成ノードに対して ssh を行い操作するので ssh ができる環境が 必要 なにげに TPC-C のベンチマークもかけることが可能 https://github.com/pingcap/tiup ちょっと寄り道
27. DB TECH SHOWCASE 2021 | @makocchi 27 構成情報の yaml はこんな感じ 👉 この構成情報を元に TiDB のクラスターを自動で作成してくれる！ tiup とは https://github.com/pingcap/tiup
28. DB TECH SHOWCASE 2021 | @makocchi 28 TiDB には「tiup」という構築ツールがある💪 しかし tiup は対象が vm の場合しか対応していない😥 ※vmだけではなくて物理の場合も同様
29. DB TECH SHOWCASE 2021 | @makocchi 29 TiDB には「tiup」という構築ツールがある💪 しかし tiup は対象が vm の場合しか対応していない😥 Kubernetes での構築に対応していない😭 ※vmだけではなくて物理の場合も同様
30. DB TECH SHOWCASE 2021 | @makocchi 30 そこで登場するのが tidb-operator
31. DB TECH SHOWCASE 2021 | @makocchi 31 tidb-operator は Kubernetes 上で動くコントローラー tiup で使用する topology.yaml と同じような内容を Kubernetes のカスタムリソース TidbCluster で定義してあげる tidb-operator は定義された通りに Kubernetes のクラスター上 に TiDB のクラスターを自動で構築してくれる 構築だけではなく、バックアップやリストアも可能 すごいぞ tidb-operator 💪
32. DB TECH SHOWCASE 2021 | @makocchi 32 https://docs.pingcap.com/tidb-in-kubernetes/stable/architecture Kubernetes のカスタムリソースとオペレーターの関係 すごいぞ tidb-operator
33. DB TECH SHOWCASE 2021 | @makocchi 33 tiup と tidb-operator $ tiup cluster deploy tidb-test v5.2.2 ./topology.yaml tiup $ kubectl apply -f tidb_cluster.yaml tidb-operator tiup cluster deploy 相当のことは kubectl apply 等で TidbCluster のリソースを 定義するだけで OK クラスター名やバージョンも TidbCluster で定義してあげます
34. DB TECH SHOWCASE 2021 | @makocchi 34 TidbCluster の定義の仕方 apiVersion: pingcap.com/v1alpha1 kind: TidbCluster metadata: name: tidb-test spec: version: v5.2.2 pd: baseImage: pingcap/pd replicas: 1 requests: storage: "1Gi" config: {} tikv: baseImage: pingcap/tikv replicas: 1 requests: storage: "1Gi" config: {} tidb: baseImage: pingcap/tidb replicas: 1 config: {} こんな感じで 定義してあげれば OK TidbCluster
35. DB TECH SHOWCASE 2021 | @makocchi 35 TidbCluster の定義の仕方 apiVersion: pingcap.com/v1alpha1 kind: TidbCluster metadata: name: tidb-test spec: version: v5.2.2 pd: baseImage: pingcap/pd replicas: 1 requests: storage: "1Gi" config: {} tikv: baseImage: pingcap/tikv replicas: 1 requests: storage: "1Gi" config: {} tidb: baseImage: pingcap/tidb replicas: 1 config: {} なんとなく書き方は似ている Kubernetes の方は IP アドレスを意識しないで OK TidbCluster topology.yaml
36. DB TECH SHOWCASE 2021 | @makocchi 36 Kubernetes で TiDB を構築する際のポイント
37. DB TECH SHOWCASE 2021 | @makocchi 37 tidb-operator を使って tiup のように TiDB のクラスターを自動で作成しよう💪 Kubernetes で TiDB を構築する際のポイント
38. DB TECH SHOWCASE 2021 | @makocchi 38 tidb-operator の導入方法 tidb-operator は Helm(3) でのインストールが提供されています 公式のドキュメントも Helm の手順が書かれています 現時点では CRD の定義が Helm Chart に含まれていないので、手動で 作成してあげる必要があります Helm で tidb-operator を入れると実体として tidb-controller- manager と tidb-scheduler が稼働することになります ちょっと寄り道
39. DB TECH SHOWCASE 2021 | @makocchi 39 Kubernetes で TiDB を運用する際のポイント 3つ
40. DB TECH SHOWCASE 2021 | @makocchi 40 Affinity/AntiAffinity 各コンポーネント(PD/TiDB/TiKV,etc)がきちんとバラけて配置されるように PodAntiAffinity を設定しましょう 逆に戦略的に同居させたい場合は PodAffinity を使ってもいいかもしれません ... spec: pd: baseImage: pingcap/pd replicas: 3 requests: storage: "1Gi" affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 10 podAffinityTerm: labelSelector: matchLabels: app.kubernetes.io/component: "pd" topologyKey: “region” TidbCluster.yaml
41. DB TECH SHOWCASE 2021 | @makocchi 41 tidb-scheduler を使う Affinity の設定が面倒くさい！そんなアナタには tidb-scheduler に任せま しょう 各コンポーネントをいい感じに分散して配置するように Kubernetes の scheduler を拡張したものになります 例えば PD の場合こんな感じで配置されます PD のreplica数 最大で 1 ノードに PD をいくつ配置するのか 1 1 2 1 3 1 4 1 5 2 ノード障害時に 過半数以上死なないように 配置してくれる
42. DB TECH SHOWCASE 2021 | @makocchi 42 tidb-scheduler を使う TiKV の場合も同じようにいい感じに分散してくれますが、ノードが 3 つ以上 の場合のみ正常に動くようです (3より少ないとスケジューリングしてくれな かった) TiKV のreplica数 各ノードにどのように配置されるのか(3ノードの場合) 3 1,1,1 4 2,1,1 5 2,2,1 6 2,2,2 7 3,2,2 8 3,3,2
43. DB TECH SHOWCASE 2021 | @makocchi 43 tidb-scheduler を使う ちなみに 4 ノードになるとどうなるかというと、こうなります TiKV のreplica数 各ノードにどのように配置されるのか(3ノードの場合) 3 1,1,1,0 4 1,1,1,1 5 2,1,1,1 6 2,2,1,1 7 2,2,2,1 8 2,2,2,2
44. DB TECH SHOWCASE 2021 | @makocchi 44 tidb-scheduler を使う ちなみにちなみに、3 ノードから途中で 4 に増やすとこうなります TiKV のreplica数 各ノードにどのように配置されるのか(3ノードの場合) 3 1,1,1 4 2,1,1 5 2,2,1 6 2,2,2 7 2,2,2,1 8 2,2,2,2 ここで新しいノードを 増やすと 新しいノードで作られる
45. DB TECH SHOWCASE 2021 | @makocchi 45 tidb-scheduler を使う tidb-scheduler を使うためには tidb-operator をインストールする時に Helm で「--set scheduler.create=true」を指定します ただしデフォルトで create=true なので、もし必要なければ create=false で明示的に消してあげる必要があります TidbCluster の定義内の spec.schedulerName を設定してあげることで一括で 設定することができます apiVersion: pingcap.com/v1alpha1 kind: TidbCluster metadata: name: sample spec: version: v5.2.2 schedulerName: tidb-scheduler pd: ... TidbCluster.yaml
46. DB TECH SHOWCASE 2021 | @makocchi apiVersion: pingcap.com/v1alpha1 kind: TidbCluster metadata: name: sample spec: version: v5.2.2 schedulerName: tidb-scheduler pd: ... tidb-scheduler を使うためには tidb-operator をインストールする時に Helm で「--set scheduler.create=true」を指定します ただしデフォルトで create=true なので、もし必要なければ create=false で明示的に消してあげる必要があります TidbCluster の定義内の spec.schedulerName を設定してあげることで一括で 設定することができます 46 tidb-scheduler を使う TidbCluster.yaml apiVersion: pingcap.com/v1alpha1 kind: TidbCluster metadata: name: sample spec: version: v5.2.2 pd: schedulerName: tidb-scheduler ... tikv: schedulerName: default-scheduler ... tidb: schedulerName: tidb-scheduler ... コンポーネントで 個別に変更することも 可能
47. DB TECH SHOWCASE 2021 | @makocchi 47 tidb-scheduler を使う デフォルトでは分散のトポロジーのキーは「kubernetes.io/hostname」のラベ ルによって行われます このキーは TidbCluster の Annotation で任意に変更することが可能です apiVersion: pingcap.com/v1alpha1 kind: TidbCluster metadata: name: sample annotations: pingcap.com/ha-topology-key: topology.kubernetes.io/zone spec: version: v5.2.2 pd: ... TidbCluster.yaml 例えば zone レベルで 分散させたい時
48. DB TECH SHOWCASE 2021 | @makocchi 48 Advanced StatefulSet を使う もともと Kubernetes では StatefulSet という仕組みがあり、tidb- operator も基本的にはこの StatefulSet を使って tidb や tikv のコン ポーネントを作成します StatefulSet は Pod を指定された数だけシーケンシャルに作成します (mypod-0, mypod-1 ,,, mypod-N) Pod が増える時は Pod の名前の末尾の数字が増えていき、Pod が減る時 は末尾の数字が大きいものから減っていきます
49. DB TECH SHOWCASE 2021 | @makocchi 49 Advanced StatefulSet を使う StatefulSet だと、例えばこんな時困ることになります mypod-0 mypod-1 mypod-2 mypod-3 mypod-0 mypod-1 mypod-2 mypod-3 mypod-1 を消したいけど・・・ mypod-0 mypod-1 mypod-2 mypod-3 レプリカの数を単に減らしても消えるのは mypod-3 手動で消しても mypod-1 は再度作成される
50. DB TECH SHOWCASE 2021 | @makocchi 50 Advanced StatefulSet を使う つまり、通常の StatefulSet だとこういう状態にすることはできません mypod-0 mypod-4 mypod-2 mypod-3 特定の番号の Pod (今回の例だと 1 ) だけ欠番にして通常通り運用した い・・・ そんな願いを叶えてくれるのが Advanced StatefulSet になります ...
51. DB TECH SHOWCASE 2021 | @makocchi 51 Advanced StatefulSet を使う Advanced StatefulSet は advanced-statefulset-controller を動かす ことで使用可能になります tidb-operator をインストールする時に Helm の設定を変更することで 追加でインストールすることができます(デフォルトではインストールさ れない) もしくは下記のリポジトリから手動でインストールすることもできます 別途 CRD も必要になりますので、kubectl で作成しておきます https://github.com/pingcap/advanced-statefulset/blob/master/manifests/deployment.yaml $ kubectl apply -f https://raw.githubusercontent.com/pingcap/tidb-operator/master/manifests/advanced-statefulset-crd.v1.yaml
52. DB TECH SHOWCASE 2021 | @makocchi 52 Advanced StatefulSet を使う Advanced StatefulSet は「kind: StatefulSet」はそのままで、 apiVersionを「apps.pingcap.com/v1alpha1」にすることで使うことがで きます それ以外の部分は既存(apps/v1)の StatefulSet と全く同じです apiVersion: apps.pingcap.com/v1alpha1 kind: StatefulSet metadata: name: sample-asts spec: selector: matchLabels: app: nginx serviceName: "nginx" replicas: 4 ... sample-asts.yaml
53. DB TECH SHOWCASE 2021 | @makocchi 53 Advanced StatefulSet を使う Advanced StatefulSet は消したい Pod を annotation で記述します mypod-0 mypod-1 mypod-2 mypod-3 mypod-0 mypod-1 mypod-2 mypod-3 mypod-1 を消したい！ apiVersion: apps.pingcap.com/v1alpha1 kind: StatefulSet metadata: name: sample-asts annotations: delete-slots: '[1]' spec: ... sample-asts.yaml これで mypod-1 は 自動的に消えます
54. DB TECH SHOWCASE 2021 | @makocchi 54 Advanced StatefulSet を使う Advanced StatefulSet は消したい Pod を annotation で記述します mypod-0 mypod-1 mypod-2 mypod-3 mypod-0 mypod-1 mypod-2 mypod-3 mypod-1 を消したい！ 最終的にはこうなります mypod-0 mypod-2 mypod-3 mypod-4 1 を歯抜けの状態にしつつ、合計 Pod の数を合わせる為に 4 が作られます
55. DB TECH SHOWCASE 2021 | @makocchi 55 Advanced StatefulSet を使う tidb-operator は通常は StatefulSet を使ってコンポーネントを作るの で、Advanced StatefulSet を使ってコンポーネントを作成するようにし てあげる必要があります tidb-operator は FeatureGate の機能を持っており、Advanced StatefulSet を使う/使わないを切り替えることができます Advanced StatefulSet を使うようにするには tidb-operator で 「--features=AdvancedStatefulSet=true」を引数に指定してあげる必 要があります FeatureGate で有効にすれば、あとは通常通り TidbCluster のリソース を作るだけ！
56. DB TECH SHOWCASE 2021 | @makocchi 56 Advanced StatefulSet を使う tidb-operator 経由で Advanced StatefulSet を作成した場合は直接 Advanced StatefulSet に対して Annotation を追加するのではなく て、TidbCluster リソースに対して Annotation を付与して制御します Advanced StatefulSet は tidb-operator によって管理されているので 直接操作すると不整合になり、tidb-operator が正常に状態を管理できな くなります apiVersion: pingcap.com/v1alpha1 kind: TidbCluster metadata: name: sample annotations: tikv.tidb.pingcap.com/delete-slots: '[0]' spec: version: v5.2.2 pd: ... TidbCluster.yaml Annotation を 追加するのは TidbClusterの方
57. DB TECH SHOWCASE 2021 | @makocchi 57 Advanced StatefulSet を使う TidbCluster に対して特定の Annotation を付与してあげれば tidb- operator が各 Advanced StatefulSet に対して「delete-slots」の Annotation を付与してくれます 付与する Annotation 対象コンポーネント pd.tidb.pingcap.com/delete-slots PD tidb.tidb.pingcap.com/delete-slots TiDB tikv.tidb.pingcap.com/delete-slots TiKV tiflash.tidb.pingcap.com/delete-slots TiFlash dm-master.tidb.pingcap.com/delete-slots DM Master dm-worker.tidb.pingcap.com/delete-slots DM Worker
58. DB TECH SHOWCASE 2021 | @makocchi 58 Autoscaling したい 負荷に応じて Pod の数を増やしてスケールさせたい場合も多々あると思 います Kubernetes は HorizontalPodAutoscaler (HPA) の仕組みがあり、負荷 に応じて Pod の数を増減させる仕組みが備わっています 作成された StatefulSet(Advanced 含む)に対して HPA を設定すること はできますが、前述の通り tidb-operator によって管理されているので tidb-operator 経由ではない操作によってリソースが書き換えられてしま うことは避けるべきです ではどうすれば？
59. DB TECH SHOWCASE 2021 | @makocchi 59 Autoscaling したい そのために tidb-operator では TidbClusterAutoScaler というリソー スで HPA のような挙動を実現する仕組みが備わっています (まだ成熟度 的には alpha なので使う際は慎重に・・・) こちらの機能は Advanced StatefulSet と同じように FeatureGate に よって有効/無効を切り替えられます(デフォルトは無効) TidbClusterAutoScaler を使うようにするには tidb-operator で 「--features=AutoScaling=true」を引数に指定してあげる必要がありま す また、リソース取得の為に TidbMonitor も同時に作成しておく必要があ ります (prometheus 等が一式自動で投入される)
60. DB TECH SHOWCASE 2021 | @makocchi 60 Autoscaling したい TidbClusterAutoscaler は現時点では CPU のメトリクスを元にスケール する方法しかサポートしていません また TiKV と TiDB のコンポーネントしか対応していないです 下記のように定義してあげます apiVersion: pingcap.com/v1alpha1 kind: TidbClusterAutoScaler metadata: name: auto-scaling-tikv spec: cluster: name: sample tikv: rules: cpu: max_threshold: 0.8 min_threshold: 0.2 tidb: ... TidbClusterAutoScaler.yaml 対象のクラスター名を指定して threshold を設定します 全ての Pod の CPU 使用率が 0.8(80%) 以上なら増えて 0.2(20%) 以下なら減る
61. DB TECH SHOWCASE 2021 | @makocchi 61 Kubernetes で TiDB を運用する際のポイント 3つ
62. DB TECH SHOWCASE 2021 | @makocchi 62 Kubernetes で TiDB を運用する際のポイント Affinity や tidb-scheduler で賢く Pod をスケ ジューリングしよう💪 Advanced StatefulSet を使ってより柔軟に StatefulSet を管理しよう TidbClusterAutoScaler で Autoscaling も忘れずに！
63. DB TECH SHOWCASE 2021 | @makocchi 63 本日のまとめ
64. DB TECH SHOWCASE 2021 | @makocchi #dbts2021 64 まとめ TiDB は MySQL 互換の NewSQL で HTAP もサポートしているオー プンソースのソフトウェア TiDB はクラウドネイティブな志向で作成されているので Kubernetes との相性がとても良い SQL とストレージが分離されているので、それぞれのコンポーネント毎 にスケールすることが可能で効率がよい スケールは無停止で可能、手動シャーディングも必要なし 便利な tiup は Kubernetes に対して利用することができないが、 tidb-operator を使えば様々な自動化の恩恵を受けることができる (ク ラスター構築、メトリクス環境、オートスケール、全て 1 発)
65. DB TECH SHOWCASE 2021 | @makocchi #dbts2021 65 最後の最後に注意点！ tidb-operator は現時点では最新の Kubernetes(1.22.x) の環境ではう まく動きません ワークアラウンドはいくつかあります issue を見る限りそのうち対応されそう 本日紹介した機能はまだ成熟してない場合がありますので、導入する場 合には十分に動作確認してから導入してください
66. DB TECH SHOWCASE 2021 | @makocchi Kubernetes で TiDB を動かしてみたくなりましたか？ 是非触ってみてください！💪 やってみよう！
67. DB TECH SHOWCASE 2021 クラウドネイティブな DB を使ってみよう！ Kubernetes で TiDB を構築・運用する際のポイントを紹介 @makocchi ご清聴ありがとうございました！