Azure SQL Database Hyperscale HA レプリカの監視

■ イベント
Azure PaaSを使った大規模BtoBプロダクト開発と運用の舞台裏 -データベースサービス編-
https://sansan.connpass.com/event/325049/

■ 発表者
技術本部 Sansan Engineering Unit Data Hubグループ　木下 賢也

■ Sansan Data Hubエンジニア 採用情報
https://media.sansan-engineering.com/datahub-engineer

■ Sansan Tech Blog
https://buildersbox.corp-sansan.com/

Transcript

1. Azure SQL Database Hyperscale HA レプリカの監視 Sansan株式会社 木下賢也
2. 2 ©Sansan, Inc. 自己紹介 2021年に新卒でSansanに入社。 入社当初からSansan Data Hubの開発メンバーとして従事 している。 ソフトウェアエンジニアリングの中でも特に技術的なアプ ローチが好きで、得意なことはモデリングです。 最近気になっているテーマは可観測性の向上です。 木下 賢也（Kinoshita Kenya）
3. 3 ©Sansan, Inc. 今日のテーマ Azure SQL Database Hyperscale を運用して、 監視の仕組みを工夫してみた話
4. 4 ©Sansan, Inc. ※詳細は省略しています （各マイクロサービスのデータストア等） Sansan Data Hubの全体像 管理用画面 組織データなど データ書き出し先 データ取り込み元 データ連携用API 組織情報作成処理群 書き出し処理群 取り込み処理群 コアデータ群
5. 5 ©Sansan, Inc. ※詳細は省略しています （各マイクロサービスのデータストア等） Sansan Data Hubの全体像 管理用画面 組織データなど データ書き出し先 データ取り込み元 データ連携用API 組織情報作成処理群 書き出し処理群 取り込み処理群 コアデータ群 Azure Cosmos DB での 時系列ログの運用と改善 Azure SQL Database Hyperscale HA レプリカ の監視
6. 6 ©Sansan, Inc. Azure SQL Database SQL Server の PaaS サービスレベル デプロイ vCore コンピューティング、ストレージを 個別にスケール出来る。 - General Purpose - Business Critcal - Hyperscale - Single - Elastic pool DTU コンピューティング、ストレージを DTU という単位に丸めてスケール 出来る。 - Standard - Premium - Single - Elastic pool
7. 7 ©Sansan, Inc. - とあるドメインで DTU モデルを採用したけど、運用辛すぎる - vCore にしたい - 見積もり時点で分かっているデータ量だけでも vCore の他のプラン のストレージ容量上限を超すことが分かり切っていた - Table Storage もどんどんリプレイス出来たらうれしい > 100 TB やっぱ欲しい Why Hyperscale => Hyperscale だな!
8. 8 ©Sansan, Inc. - 2 種類のコンピューティングノードがある - プライマリ - セカンダリ - レプリカの種類 - 高可用性レプリカ (以降 HA レプリカ) - 名前付きレプリカ - GEO 冗長レプリカ Why Hyperscale HA
9. 9 ©Sansan, Inc. Azure SQL Databse Hyperscale レプリカの種類 HA レプリカ - データベース名はプライマリのものと同じ - レプリカ毎のメトリクスを取得できない - レプリカが複数ある場合でも接続文字列は同じで、任意のノー ドに分散してくれる - 接続文字列に ReadOnly を付ける - プライマリのダウンタイムを極限まで抑えたい時に使える - Zone 冗長にするには少なくとも一つの高可用性レプリカが 必要
10. 10 ©Sansan, Inc. Azure SQL Databse Hyperscale レプリカの種類 名前付きレプリカ - データベース名はレプリカ毎に異なる (任意の名前を付けられ る) - レプリカ毎のメトリクスを取得できる - レプリカ毎に接続文字列が異なるので、接続先は開発者が 何とかする - 読み取りワークロード毎に適したリソースを準備できる
11. 11 ©Sansan, Inc. Azure SQL Databse Hyperscale レプリカの種類 GEO 冗長レプリカ - データベース名はプライマリと同じ - プライマリとは異なるリージョンにレプリカを作成できる - 作成できるレプリカは一つのみ - リージョン跨いで冗長化させたい時に使う - プライマリがダウンした時に自動で切り替えてくれる
12. 12 ©Sansan, Inc. Azure SQL Databse Hyperscale レプリカの種類 読み取り負荷分散のために高可用性レプリカを使った理由 - ゾーン冗長にしており、HA レプリカを最低 1 つ持つ必要があ る - これを上手く使って節約したい - とりあえず本番にデプロイしてフィードバックを得たい - 必要な時に追加できればいいよね
13. 13 ©Sansan, Inc. 全体構成 Function Apps Service Bus Function Apps Service Bus Function Apps Service Bus SQL Database Read Write
14. 14 ©Sansan, Inc. Hyperscale HA レプリカの運用のつらみ - Read レプリカに接続している処理系がスローダウンした時 に調査が辛い - レプリカのメトリクスを Azure Monitor 上で確認できない - 都度 SQL Server にログインして～を繰り返す - ログインして監視用の SQL を実行して～ - 接続文字列に `ReadOnly` を指定するの忘れがち - 定常状態が分からないと、ピンポイントの数値を見ても何 をどう評価すればよいのかわからない
15. 15 ©Sansan, Inc. 全体構成 Function Apps DMV の読みとり メトリクスの送信 開発・運用 メンバー Function Apps Service Bus Function Apps Service Bus Function Apps Service Bus SQL Database Read Write
16. 16 ©Sansan, Inc. HA レプリカの状態を監視する 動的管理ビューとは - SQL Server インスタンスの状態などが記録された View - SQL Database のメトリクスで表示されているのも実態 はこれ - インスタンスのヘルス状態の監視、パフォーマンスの チューニングに使える
17. 17 ©Sansan, Inc. HA レプリカの状態を監視する カラム名 説明 avg_cpu_percent Service Tier の制限に対する CPU 使用率の平均値。 avg_data_io_percent Service Tier の制限に対する Data IO 使用率の平均値。 avg_memory_usage_percent Service Tier の制限に対する Memory 使用率の平均値。 avg_log_write_percent Service Tier の制限に対するトランザクションログ (MB/s) の平均 書き込み量の割合。 max_session_percent Service Tier の制限に対する最大同時セッションの割合。 (最大同時ワーカ数が 100 で 50 ワーカ使っていれば 50%) max_worker_percent Service Tier の制限に対する最大同時ワーカの割合。 (最大同時ワーカ数が 100 で 50 ワーカ使っていれば 50%) view 名: dm_db_resource_stats
18. 18 ©Sansan, Inc. カスタムメトリクス用の REST API - REST API で Azure Monitor にメトリクスを送信できる - 参考: https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-store- custom-rest-api?tabs=rest#metric-values - メトリクスを記録したいリソースのリソース ID、リージョン があればとりあえず使える - あと認証
19. 19 ©Sansan, Inc. カスタムメトリクス用の REST API - 送信すべきもの - メトリクスの名前空間 - メトリクスの名前 - メトリクスのタイムスタンプ - ディメンション - メトリクスの値 ▪ sum, min, max, count
20. 20 ©Sansan, Inc. 運用してみて
21. 21 ©Sansan, Inc. 運用してみて - コンピューティングとストレージを分離してスケール出来 るのはやっぱいいよね - 定常状態の確認、スローダウン時の状態を確認し、比較で きるのはやっぱり嬉しい - 手順も減るし - Azure Monitor の UI に乗っかれるので楽 - 運用の認知負荷とか
22. 22 ©Sansan, Inc. 運用してみて - 低レベルのメトリクスなので、もっとユーザーに近いメト リクスが欲しい - HA のままレプリカを増やすとうまくいかないだろうなぁ - 複数レプリカがある場合、それらを見分けることは出来 ない