Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

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

YugabyteDB Japan
February 02, 2024
97

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

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

YugabyteDB Japan

February 02, 2024
Tweet

Transcript

  1. 1 自己紹介 藺牟田 佳佑(いむた けいすけ) • 2020年ウルシステムズ株式会社に新卒入社 • 開発案件を担当 • 主にwebアプリケーション •

    フロントエンド: JavaScript(vue.js) • バックエンド: Java(Spring)TypeScript(nest.js)C# • インフラ: AWS、Azure
  2. 5 NewSQLはRDBとNoSQLのいいとこどり! RDB NoSQL NewSQL SQL ◦ × ◦ ACIDトランザクション

    ◦ × ◦ 可用性 × ◦ ◦ スケーラビリティ × ◦ ◦ データベース機能比較 SQL ACIDトランザクション RDB 可用性 スケーラビリティ トレードオフを排除 NewSQL NoSQL
  3. 7 YugabyteDBはさらにこのような特徴があります PostgreSQL/ Cassandra 互換 マルチクラウド/ ハイブリッド クラウド DR対策/ 地理分散

    PostgreSQL、Cassandraと互換 性があるため、移行 コストが低減されます。 また開発担当者の学習コストを 抑えることができます。 複数のクラウドサービスにまた がってデータを配置できます。ま た、オンプレミスとのハイブリッド クラウド構成も可能です。 ノードを異なるリージョンに 配置し、Active-Active構成のDR を実現できます。 事業継続の観点のみならずユー ザーの近い場所にデータを配置 することでUXを高めます。
  4. 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の例
  5. 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
  6. 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台 ずつ配置
  7. 15 AWS Fault Injection Service とは 意図的にAWS環境に障害を発生させ、障害発生時の挙動や回復 性を検証できるサービス 障害を発生させられるサービス例
 -

    Amazon CloudWatch - Amazon EBS - Amazon EC2 - Amazon ECS - Amazon EKS - Amazon RDS - AWS Systems Manager - AZなどその他ネットワーク

  8. 22 検証準備 ②APIを作成(2/2) • GETとPOST、計2本のAPIを作成しました • DB接続するためにJDBC「YugabyteDB smart drivers」を使用しまし た

    • クラスター内の複数ノードに対してリクエストを振り分ける対応を手軽 に実現できます (PostgreSQLの場合、サービス導入や実装変更が必要となり手間とな ります) HTTPメソッド 概要 Get ordersテーブルのレコード件数と先頭10件を返却する Post reviewsテーブルのレコードを1件追加する
  9. 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アドレスにア クセスします
  10. 30 検証の流れ ざっくり以下の手順で検証します ローカルPCにて スクリプトを実行する API経由でYugabyteDBに 1秒間隔でリクエストを 送り続けます(15分間) 数分後、FIS経由で AZ障害を発生させる

    障害AZに配置されている ノードが停止し、 leaderの再選出などが 始まります APIレスポンスや YugabyteDB UIのモ ニタリング結果を確認す る エラーが返却されるか・ レイテンシー/スループット などの性能が悪化するか 確認します
  11. 37 検証結果 わかったこと • 特定のノードに障害発生時、YugabyteDBはエラーを返却しない。 クライアントはLeaderの再選出などが終了するまで待機すること となる • 今回の場合、約10~15秒ほど待機していた様子 •

    YugabyteDBからエラーは返却されないものの、アプリ側でタイムアウ ト値を設けるなど、ハンドリングした方がよさそう • 書き込みだけではなく、読み込みも同様に長時間待機していた 工夫次第で改善可能? Follower Readなどの 工夫で改善可能?