AWS Fault Injection ServiceによるYugabyteDBの可用性検証

YugabyteDBは高い可用性や自己回復の機能を持った分散SQLデータベースです。可用性を実際に確かめるために、AWS Fault Injection Serviceを使用して意図的にAZ障害を発生させてYugabyteDBの挙動を確認した検証の内容を紹介します。

Transcript

1. AWS Fault Injection ServiceによるYugabyteDBの可 用性検証 YugabyteDB Japan Meetup #4　2024/01/23（Tue）
2. 1 自己紹介 藺牟田　佳佑（いむた　けいすけ） • 2020年ウルシステムズ株式会社に新卒入社 • 開発案件を担当 • 主にwebアプリケーション • フロントエンド: JavaScript（vue.js） • バックエンド: Java（Spring）TypeScript（nest.js）C# • インフラ: AWS、Azure
3. 2 LTの内容 YugabyteDBは高可用性・高回復性！ DCに障害が発生しても、 短時間のダウンタイムで回復すると謳われています 障害発生した際の実際の挙動を 確認してみました！
4. YugabyteDBのおさらい
5. 4 YugabyteDBはNewSQLの一種です YugabyteDBとはYugabyte社が開発している オープンソースのNewSQLデータベースです RDB NewSQL NoSQL … PostgreSQL MySQL Oracle SQL Server … Cloud Spanner Cockroach DB TiDB Yugabyte DB … Apache Cassandra Dynamo DB Radis Mongo DB
6. 5 NewSQLはRDBとNoSQLのいいとこどり！ RDB NoSQL NewSQL SQL ◦ × ◦ ACIDトランザクション ◦ × ◦ 可用性 × ◦ ◦ スケーラビリティ × ◦ ◦ データベース機能比較 SQL ACIDトランザクション RDB 可用性 スケーラビリティ トレードオフを排除 NewSQL NoSQL
7. 6 YugabyteDBはNewSQLの一種です！
8. 7 YugabyteDBはさらにこのような特徴があります PostgreSQL/ Cassandra 互換 マルチクラウド/ ハイブリッド クラウド DR対策/ 地理分散 PostgreSQL、Cassandraと互換 性があるため、移行 コストが低減されます。 また開発担当者の学習コストを 抑えることができます。 複数のクラウドサービスにまた がってデータを配置できます。ま た、オンプレミスとのハイブリッド クラウド構成も可能です。 ノードを異なるリージョンに 配置し、Active-Active構成のDR を実現できます。 事業継続の観点のみならずユー ザーの近い場所にデータを配置 することでUXを高めます。
9. 8 YugabyteDBのデータ保存の仕組み ノード2 ノード3 ノード4 • YugabyteDBはtabletと言われる単位でデータをパーティションし、他ノード へシャーディングしています。 • 各ノード間のデータ整合性は、RAFTコンセンサスというアルゴリズムを用いて担 保します（RAFTコンセンサスするグループをtablet peerと呼びます） follower follower leader follower follower follower leader update update update update tablet peer tablet ノード1 follower leader tablet数が3の例
10. 9 データをシャーディングしているため可用性が高い ノード2 ノード3（障害発生） ノード4 • 特定AZに障害発生しても、他ノードにデータが残っており、そのノードで処 理継続できるため、高い可用性を維持できます follower follower leader follower follower follower leader update update update update ノード1 follower leader tablet数が3の例 tablet peer tablet
11. 10 障害発生時はこのように回復している ノード2 ノード3（障害発生） ノード4 1. leaderを再選出します • 障害発生tabletが担当していたleaderを他tabletに担当してもらいます 2. データを再配置します • 障害発生tabletで保管していたデータを他ノードに移します follower follower leader follower follower → leader follower leader update update update update ノード1 follower leader tablet数が3の例 ① leaderを再選出 follower follower ② データの再配置 ② データの再配置 tablet peer tablet
12. 11 改めて本日のLTテーマは YugabyteDBの可用性・回復性を実際に AZ障害を発生させつつ確認します！ ダウンタイムは どれくらいなのか？ 回復途中にリクエストが届 いたら、エラーが返却され る？ 回復途中、書き込みはできないけ ど、読み込みはできるって どこかで見たけど本当？
13. 検証内容
14. 13 検証テーマ AZ障害発生後、回復途中にリクエストされた場合、どのような挙動 となるか？ アプリ 【結果の想定】 書き込みはエラーが返ってくる？ ただし、読み込みは200 OKが返っ てくる
15. 14 検証の構成 EC2上にYugabyteDBを構築します。また、AZ障害はAWS Fault Injection Service（以降、FISと記載）で再現します AWS Fault Injection Service VPC クライアント VM（EC2） （onEC2） ap-northeast-1a ap-northeast-1c ap-northeast-1d （onEC2） （onEC2） スクリプトを使用し、 VMに構築したAPIに 1秒間隔でリクエストし続ける 指定したAZに 障害を発生させる Create/Readリクエスト 3ノードを1クラスターにまとめる VM上にAPIを構築 各AZに YugabyteDBを1台 ずつ配置
16. 15 AWS Fault Injection Service とは 意図的にAWS環境に障害を発生させ、障害発生時の挙動や回復 性を検証できるサービス 障害を発生させられるサービス例
 - Amazon CloudWatch - Amazon EBS - Amazon EC2 - Amazon ECS - Amazon EKS - Amazon RDS - AWS Systems Manager - AZなどその他ネットワーク

17. 検証準備
18. 17 検証準備 ① YugabyteDBクラス ターを作成 ③ シェルスクリプトを 作成 ② APIを作 成 ④ FISを設定
19. 18 検証準備 ①YugabyteDBクラスターを作成（1/3） ① YugabyteDBクラス ターを作成 ③ シェルスクリプトを 作成 ② APIを作 成 ④ FISを設定
20. 19 検証準備 ①YugabyteDBクラスターを作成（2/3） オープンソースのYugabyteDBを3台のEC2にそれぞれインストールし、1クラス ターで起動しました YugabyteDBのバージョ ン YugabyteDBのキャパシ ティ 3ノード（1AZに1ノード配置）でクラ スタを構成
21. 20 検証準備 ①YugabyteDBクラスターを作成（3/3） DBに初期データを投入しました（公式サイトのサンプルを参考） 4テーブル作成 18760件投入 200件投入 2500件投入 1112件投入
22. 21 検証準備 ②APIを作成（1/2） ① YugabyteDBクラス ターを作成 ③ シェルスクリプトを 作成 ② APIを作 成 ④ FISを設定
23. 22 検証準備 ②APIを作成（2/2） • GETとPOST、計2本のAPIを作成しました • DB接続するためにJDBC「YugabyteDB smart drivers」を使用しまし た • クラスター内の複数ノードに対してリクエストを振り分ける対応を手軽 に実現できます （PostgreSQLの場合、サービス導入や実装変更が必要となり手間とな ります） HTTPメソッド 概要 Get ordersテーブルのレコード件数と先頭10件を返却する Post reviewsテーブルのレコードを1件追加する
24. 23 YugabyteDB smart driversとは • クライアントサイドでロードバランシングできます • 複数の接続先に対して、クライアント側で負荷分散できる • 接続先がダウンした場合でも生きているノードへ接続できる spring.datasource.url=jdbc:yugabytedb://57.180.54.242:5433,~~,.173:5433/test?load-balance=true spring.datasource.username=yugabyte spring.datasource.password=yugabyte spring.datasource.driver-class-name=com.yugabyte.Driver 指定した複数のIPアドレスにア クセスします
25. 24 検証準備 ③シェルスクリプトを作成（1/2） ① YugabyteDBクラス ターを作成 ③ シェルスクリプトを 作成 ② APIを作 成 ④ FISを設定
26. 25 検証準備 ③シェルスクリプトを作成（2/2） 詳細省略 （GetとPostのAPIに対して1秒間隔でcurlリクエストし続けるスクリプト を作成しました）
27. 26 検証準備 ④AWS FISを作成（1/2） ① YugabyteDBクラス ターを作成 ③ シェルスクリプトを 作成 ② APIを作 成 ④ FISを設定
28. 27 検証準備 ④AWS FISを作成（2/2） 特定のAZを停止するよう設定しました ネットワーク障害を発生さ せる 5分間停止 障害発生させるAZ （サブネット）を選択
29. 28 検証準備 動作確認（1/2） クライアントでシェルスクリプト実行！ シェルスクリプトのログからAPIリクエストが通っていることが確認で きました！ GETリクエストの結果 POSTリクエストの結果 1秒間隔でAPIリクエストし ている
30. 29 検証準備 動作確認（2/2） YugabyteDB UIからモニタリング結果を見ると、、 各ノードにリクエスト到達していることが確認できました！ ノード1のモニタリング ノード2のモニタリング ノード3のモニタリング ノード毎の モニタリング結果 各ノードにリクエストが 到達している
31. 30 検証の流れ ざっくり以下の手順で検証します ローカルPCにて スクリプトを実行する API経由でYugabyteDBに 1秒間隔でリクエストを 送り続けます（15分間） 数分後、FIS経由で AZ障害を発生させる 障害AZに配置されている ノードが停止し、 leaderの再選出などが 始まります APIレスポンスや YugabyteDB UIのモ ニタリング結果を確認す る エラーが返却されるか・ レイテンシー/スループット などの性能が悪化するか 確認します
32. 検証結果
33. 32 検証結果 改めて検証テーマは、、
34. 33 スクリプト実行！ シェルスクリプトが出力したログを見ると、、 APIリクエストが始まったことが確認できました！ curl　GETリクエストのログ curl　POSTリクエストのログ
35. 34 AZ障害開始！ 数秒後Yugabyte UIを確認すると、、、 ノードが死んでいることが確認できました！
36. 35 検証結果 APIリクエストの結果 • エラーレスポンスは返ってこなかった。 • ただし、AZ障害発生（2024/01/23:02:40:09）直後、 約10～15秒間、レイテンシーが悪化していた • 10～15秒後、元のレイテンシーに戻った シェルスクリプト　GETリクエストのログ シェルスクリプト　POSTリクエストのログ
37. 36 検証結果 YugabyteDB UIのモニタリング結果 各ノードの平均レイテンシーのモニタリング結果 ノード1 ノード2 ノード3（障害発生ノード） 障害発生期間 読み込み: 0.75ms、書き込み: 4.59ms 読み込み: 0.74ms、書き込み: 4.49ms （期待どおり）ノード停止している
38. 37 検証結果 わかったこと • 特定のノードに障害発生時、YugabyteDBはエラーを返却しない。 クライアントはLeaderの再選出などが終了するまで待機すること となる • 今回の場合、約10～15秒ほど待機していた様子 • YugabyteDBからエラーは返却されないものの、アプリ側でタイムアウ ト値を設けるなど、ハンドリングした方がよさそう • 書き込みだけではなく、読み込みも同様に長時間待機していた 工夫次第で改善可能？ Follower Readなどの 工夫で改善可能？
39. まとめ
40. 39 実際動かすと分かってくるものがある • 机上でこう動くはず！な事象を実際に検証したことにより、 新たな疑問が生まれるとともに、より具体的な理解を得ることが できました！ • 次は、より本番な環境を想定した検証を実施してみたいと思いま す！ • tablet数やシャーディングの単位など、YugabyteDBの設定周 りをいじる • K8s上に構築してノードをセルフヒーリングしてみる …