数百shardのデータベース運用を最適化する手法【DeNA TechCon 2021 Autumn】/techcon2021autumn_04

DeNAの様々な事業を横断的に見るインフラチームでは、各サービスを統一的に運用できるような仕組みを IaaS で作ってきました。
監視、OSやミドルウエアの設定、クラウドリソース管理、コスト最適化、KPI管理、オーケストレーション、と様々な仕組みの自動化を整備してきましたが、そういった中で今もなお一定の工数がかかっているのがデータベースの運用です。
今回はそのデータベースの運用について、大規模ゲームを題材にしながら、どのように最適化を目指してきたのかについてご紹介します。
また、日々アップデートされるデータベースの新技術を、今後どのように取り入れていきたいかについてもお話していきます。

Transcript

1. 数百shardのデータベース 運用を最適化する手法 天野 知樹
2. 自己紹介 • 天野知樹 ◦ IT基盤部 第四グループ ▪ 全世界向けゲームタイトルの インフラを運用 ▪ AWS と GCP を使用 ▪ 担当しているゲームタイトルは5つ ▪ インスタンス数は、それぞれ数百台
3. DeNA IT 基盤部の特徴 • DeNA の IaaS インフラ全体を運用する組織 ◦ Mobage(モバゲー)基盤 ◦ モバイルゲーム ◦ Pococha ◦ ヘルスケア ◦ 社内サーバ ◦ etc... • このように特性や複雑さが異なるシステムを 良い感じに管理するために、様々な仕組みを作ってきました • 今日ここでは、IT 基盤部のみんなが作ってきたものを紹介していきます
4. これまで便利にしてきた IaaS インフラ運用 • グローバルインフラ (G-I) ◦ 設定ファイルを書くだけで使える700以上のスクリプト ◦ 様々な監視や自動化のツール群 ◦ https://engineer.dena.com/posts/2019.11/gi/ • chef ◦ 50種類以上の各アプリケーション別のcookbook • オーケストレーションツール ◦ https://engineer.dena.com/posts/2019.11/infra-system-overview-from-autoscaling/ ◦ 様々な処理の自動化とエラーハンドリング ▪ 作成: ssh 確認 > chef > deploy > 疎通確認 > s-in • 徹底したコスト削減 ◦ https://engineer.dena.com/posts/2019.08/cloud-qct-management/
5. ここまで運用最適化を進めた状態でも 今だに工数を掛けさせられているのがデータベース 大規模ゲームを例に運用最適化を紹介 　　　　　　
6. 大規模ゲームにおけるデータベースの特徴 • MySQL 互換 • リリース直後の膨大なリクエストを捌くために数百 shard の水平分割 ◦ 台数が増えると故障台数も増えて運用負担 • リリース後の負荷が落ち着いてから、shard 統合とコスト最適化 • IOPS 性能が求められるストレージ • 新機能実装の度に必要なクエリ最適化 • 大型イベントの度に発生するスペック調整
7. データベース運用のために今まで実施してきた事 • 第一世代システム • 第二世代システム
8. 第一世代システム (MySQL を IaaS で運用) • Slave 故障時は自動的に切り離し • Master 故障時は MHA による自動 Failover • Slave はコマンド1つで自動複製 • マルチインスタンスによる shard 統合 • i3/i3en インスタンスの使用
9. Slave 故障時は自動的に切り離し • slave 故障は自動的に DNS から外すことで、即座にサービス影響を収束 ◦ 故障発生から影響収束までは15秒程度 API Server (Spot インスタンス) Master Slave DNS (TTL 3秒) 監視 Server (G-Iスクリプト) ① 死活監視 　　　　　　　(10秒 timeout で発動) ② Roエンドポイントから Slave を外し、 　Master を入れる ③ DNS 更新から TTL 3秒で 生きている MySQL を参照
10. Master 故障時は MHA による自動 Failover • MHA は MySQL の可用性を高めるための OSS (https://github.com/yoshinorim/mha4mysql-manager) ◦ 故障発生から影響収束までは15秒程度 ◦ 手動実行の場合の downtime は2秒程度 API Server (Spot インスタンス) Master DNS (TTL 3秒) Slave 1 新 Master 監視 Server (MHA) ① down を検知 　(10秒 timeout で発動) ② Slave の中で最もポジションが進んでいる 　ものを Master に昇格させ、レプリを張る 　(そのほかにもいろいろするが詳細は割愛) ③ 更新用エンドポイントから旧 Master を外し、 　新 Master を入れる ④ DNS 更新から TTL 3秒で 生きている MySQL を参照 Slave 2
11. Slave はコマンド一つで自動複製 (故障対応やスペック変更に) Master Slave backup 用の Slave ① Backup 用 Slave 上において、 cron で定期的に mysqldump を取得 Master Slave backup 用の Slave 新Slave Master Slave backup 用の Slave 新Slave ② 取得しておいた dump で 新Slave を作り repli を追いつかせる ③ Master の下に repli を張りなおす
12. マルチインスタンスによる shard 統合 • 一つのインスタンス内で複数のプロセスを動かす DeNA 独自の運用手法 • MySQL をインスタンス内で複数個動かし、それぞれに別の IP アドレスとし て認識させる • 前述の Slave 複製と MHA も組み合わせると、無停止で shard 統合が可能 Shard1用IP Shard2用IP Shard1 Shard2 ① Slave 複製 ② MHA で Failover
13. i3/i3en インスタンスの使用 • local SSD は圧倒的な IOPS 性能を得られる • 揮発性であるため、データロストに備えて slave は3台あると安心 • gp3 とのコスト比較 [us-east-1] ◦ i3.2xlarge(1900GB,18万IOPS) ▪ $456 ◦ r5.2xlarge + gp3(1900GB, 3万IOPS, 500MBps) ▪ $368 + ($152 + $135 + $15.16) = $670.16 vCPUs Memory NVMe IOPS r/w Cost i3.2xlarge 8 61GiB 1.9TB 41万/18万 $456/月 r5.2xlarge 8 64GiB - - $368/月 NVMe の IOPS はAWS の公称値を掲載 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/storage-optimized-instances.html
14. 第一世代システムの問題点 • 故障時には手動介入が必要 ◦ 故障の仕方によって状況はいろいろであり、判断を挟む必要がある ◦ そのため、故障対応の完全自動化には至っていない • ゲームイベント毎に DB インスタンスのサイズ変更が面倒 • 運悪く同じホストに載っていて、同時多発的に故障する場合もある
15. 第二世代システム • Aurora MySQL 5.7 ◦ さすがに数百 shard を運用するのはキツかったのでマネージドを導入 • shard 統合は停止メンテ • IaaS 同様に1コマンドでいろいろ可能な便利スクリプト群を整備 • 独自の Aurora 高速 Failover ◦ 元々20秒程度の downtime だったものを 5秒程度に短縮
16. 独自の Aurora 高速 Failover • 自前の DNS サーバを用いて、DNS の更新遅延を改善 • 数秒の downtime で切り替えれるため、スペック変更しやすい • https://engineer.dena.com/posts/2019.10/management-migration-aurora/ API Server (Spot インスタンス) Writer DNS (TTL 3秒) 監視 Server ① innodb_read_only を1秒毎に確認し、 　インスタンスが Writer か Reader かを把握 ② Failover を検知すると、 　DNS のレコードを即座に更新 ③ DNS 更新から TTL 3秒で 　正しいインスタンスを参照 Reader
17. 第二世代の問題点 • コストが高い • ゲームイベント毎にDBインスタンスのサイズ変更は面倒 • shard 統合が気楽にできない • AWS にベンダーロックインされる
18. 現在検討中の次世代システムの候補 • Aurora Serverless v2 • TiDB
19. Aurora Serverless v2 • インスタンスのCPUとメモリが自動でスケールアップ・ダウン • スケーリングは瞬時に行われる • 同じリソースを使う場合は既存の Aurora より割高 • 可用性は既存の Aurora と同程度(らしい) • 故障時は既存の Aurora と同じく Failover もする(らしい) • 既存のAurora MySQL からの移行は簡単(だろう) 利用可能となることを期待
20. TiDB (https://docs.pingcap.com/tidb/stable) • MySQL互換のNewSQL API Server (Spot インスタンス) TiDB TiKV TiKV TiKV TiKV TiKV TiKV TiKV TiKV TiDB TiDB TiDB PD PD PD TiDB cluster Storage cluster PD cluster Metadata TSO/Data location MySQL互換なクエリ KV API
21. TiDB の特徴 • MySQL 5.7と互換性が非常に高い ◦ アプリケーションに手を入れる箇所が少なくて済む • 悲観ロックが可能 • TiKV を増やせば write性能をスケールさせることが可能 • TiDB を増やせばクエリ処理性能をスケールさせることが可能 • Shard 統合が不要 • 故障対応の自動化が可能 • 全 shard を静止面でバックアップが取れる • MySQL とレプリケーションを張れる • 可用性/堅牢性は MySQL と同程度 • 遅延は増加しそう 導入にむけて技術検証中
22. 最後に • 今までもインフラ運用を最適化するために様々な手段を用いてきました • 今後も、最新技術を取り入れつつ、中核事業を支え続けていきます • 引き続き、このようなノウハウを発表していきますので、 皆様も一緒にIT業界を盛り上げていきましょう！