Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

ピグパーティにおけるMongoDB CommunityバージョンからAtlasへの移行事例

ピグパーティにおけるMongoDB CommunityバージョンからAtlasへの移行事例

db tech showcase 2024 Tokyo PC14 の登壇内容になります。
https://www.db-tech-showcase.com/2024/

Hotaka Matsuoka

July 16, 2024
Tweet

Other Decks in Programming

Transcript

  1. MongoDBの選定理由 サーバーサイドはNode.jsを採⽤しており、MongoDBとの親和性が⾼い • データ構造がJSONなのでJavaScript/TypeScriptと相性が良い 柔軟なスキーマ設計 • MongoDBはスキーマレスであり、柔軟なデータモデル設計が可能 • 仕様変更が多いゲーム開発にマッチしている ⾼い性能とスケーラビリティ

    • シャーディングによる負荷分散やレプリケーションによる⾼可⽤性 • ⼤量の同時接続ユーザーを持つオンラインゲームでも安⼼したパフォーマンスが提供できる 過去のピグサービスで実績がある • これまでのピグのサービスでもMongoDBを採⽤してきており、知⾒が豊富
  2. MongoDB Atlasへ移⾏するにあたった背景 インフラ運⽤コストの増⼤と属⼈化 • GCPのCompute Engine上にMongoDBをセルフホストしており、管理している • しかし、定期的に開催されるイベントの負荷対策の度にインフラのスペックアップ作業を⼿動で⾏っており、 運⽤コストが増⼤していた OSのサポート終了

    • CentOS 7のサポート終了に伴い、セキュリティリスクやサポートの⽋如の懸念 今後のサービス成⻑を⾒据えた拡張性と安定性の確保 • サービスの利⽤者が増加する中で、より⾼い可⽤性とパフォーマンスを維持する必要があった • 短期間でのリソースのスケーリングが求められるため、柔軟なインフラが必要である
  3. データベース移⾏の流れと移⾏戦略 検討 計画 インフラ構築 負荷試験 データ移⾏ 最適化 • Atlasについて知る •

    ハンズオン • コストの⾒積もり • Atlas移⾏の意思決定 • 移⾏⽅式の設計 • 移⾏後の環境設計 • クラスター構築 • GCP-Atlas間のVPC連携 • 移⾏テスト • リカバリテスト • 負荷試験 • データ移⾏ • サービスメンテナンス • 切り替え作業 • 移⾏終了後の運⽤ • キャパシティの⾒直し • コスト最適化 期間: 2ヶ月
  4. データベース移⾏の流れと移⾏戦略 検討 計画 インフラ構築 負荷試験 データ移⾏ 最適化 • Atlasについて知る •

    ハンズオン • コストの⾒積もり • Atlas移⾏の意思決定 • 移⾏⽅式の設計 • 移⾏後の環境設計 • クラスター構築 • GCP-Atlas間のVPC連携 • 移⾏テスト • リカバリテスト • 負荷試験 • データ移⾏ • サービスメンテナンス • 切り替え作業 • 移⾏終了後の運⽤ • キャパシティの⾒直し • コスト最適化
  5. 1. 検討 MongoDB Atlasに乗り換えるか検討する 検討ポイント 決め⼿のポイント ü 導⼊によって運⽤課題が解決できるか ü Atlasで提供されている機能が活⽤できるか

    ü 安全に移⾏ができるか ü 簡単にDBの設定変更が可能で、運⽤コストを削減できる ü オートスケール・アーカイブなど活⽤できる機能がある ü Professional Servicesを活⽤したサポート体制がある
  6. 1. 検討 簡単にDBの設定変更が可能で、運⽤コストを削減できる • DBの設定変更がAtlas UIから変更可能 • ダウンタイムを最⼩限にしてスペック変更ができる • 今まではデータベースとインスタンスを停⽌して、マシン

    タイプを変更して、再度起動という作業を各インスタンス ごとに⼿動で⾏なっていた... • mongodが12台、mongosが5台あるので全てスペックアッ プをしようとすると半⽇費やすことも
  7. 1. 検討 Professional Servicesを活⽤したサポート体制がある Professional Servicesとは • MongoDBが提供する専⾨的なサポートサービス • MongoDBのデプロイメント、運⽤、パフォーマンスチューニング、マイグレーションなどを⽀援してくれる

    実際に使⽤した例 • MongoDB社のエンジニアと常時質問できる体制の⽤意 • 移⾏⽅法やリカバリ・バックアップ戦略についてのレビューとベストプラクティスの提案
  8. データベース移⾏の流れと移⾏戦略 検討 計画 インフラ構築 負荷試験 データ移⾏ 最適化 • Atlasについて知る •

    ハンズオン • コストの⾒積もり • Atlas移⾏の意思決定 • 移⾏⽅式の設計 • 移⾏後の環境設計 • クラスター構築 • GCP-Atlas間のVPC連携 • 移⾏テスト • リカバリテスト • 負荷試験 • データ移⾏ • サービスメンテナンス • 切り替え作業 • 移⾏終了後の運⽤ • キャパシティの⾒直し • コスト最適化
  9. 2. 計画 Live Migrateとは • 既存のMongoDBのデータを、最⼩限のダウンタイムでAtlasに移⾏するための機能 • この機能を利⽤することで、オンプレミスやクラウドプロバイダのMongoDBをAtlasに迅速かつ効率的に移⾏できる • 内部ではmongosyncというクラスタ間の同期プロセスを⾏なっており、この機能を使⽤することで、サービスを稼働した

    ままでも、新しいクラスタに対し継続的なデータ同期が可能になる • またVPCピアリングとプライベートエンドポイントに対応しており、安全にデータ移⾏ができる (※シャード構成の場合は、プライベートエンドポイントのみ)
  10. Live Migrateの流れ • クラスターの構築・Cloud ManagerとAtlasを連携 • プライベートエンドポイントを使⽤して、AtlasとソースクラスターのVMと接続 1 2 •

    Live Migrateを実⾏し、ソースクラスターからAtlasへデータの初期同期を開始 3 • 両クラスター間のラグが短くなれば、メンテナンスを⼊れて、ソースクラスターへの書き込みを停⽌ 4 • カットオーバーを実⾏し、残りの増分データを同期 5 • Atlasへ接続先を変更 6 • メンテナンスを終了し、サービスを再開
  11. データベース移⾏の流れと移⾏戦略 検討 計画 インフラ構築 負荷試験 データ移⾏ 最適化 • Atlasについて知る •

    ハンズオン • コストの⾒積もり • Atlas移⾏の意思決定 • 移⾏⽅式の設計 • 移⾏後の環境設計 • クラスター構築 • GCP-Atlas間のVPC連携 • 移⾏テスト • リカバリテスト • 負荷試験 • データ移⾏ • サービスメンテナンス • 切り替え作業 • 移⾏終了後の運⽤ • キャパシティの⾒直し • コスト最適化
  12. 3. インフラ構築 移⾏前のアーキテクチャ Shard 1 mongos ユーザー Shard 2 Shard

    3 Shard 4 Compute Engine アプリケーションサーバー Kubernetes Engine mongod
  13. check_24.png 3. インフラ構築 移⾏後のアーキテクチャ Shard 1 Shard 2 Shard 3

    Shard 4 Atlas VPC mongos Kubernetes Engine アプリケーションサーバー ユーザー mongod VPC Peering
  14. データベース移⾏の流れと移⾏戦略 検討 計画 インフラ構築 負荷試験 データ移⾏ 最適化 • Atlasについて知る •

    ハンズオン • コストの⾒積もり • Atlas移⾏の意思決定 • 移⾏⽅式の設計 • 移⾏後の環境設計 • クラスター構築 • GCP-Atlas間のVPC連携 • 移⾏テスト • リカバリテスト • 負荷試験 • データ移⾏ • サービスメンテナンス • 切り替え作業 • 移⾏終了後の運⽤ • キャパシティの⾒直し • コスト最適化
  15. 4. 負荷試験 結果 • 失敗 原因 • ソースクラスタのOplogサイズが⼩さかった • Live

    MigrateはOplogをもとにデータを同期するため、⼗分なOplogサイズを確保する必要がある 解消 • Oplogサイズを拡⼤する → しかし、ディスク容量にも上限があるため限界があった • 書き込みが多いバッチ処理を停⽌させる → Oplogサイズが100GB/HRが10GB/HRに短縮することができた
  16. 旧MongoDB MongoDB Atlas ① mongosync curl -XPOST localhost:27182/api/v1/start --data '

    { "source": "cluster0", "destination":"cluster1" } ' Live Migrateの流れ(切り戻しパターン)
  17. 旧MongoDB MongoDB Atlas ① mongosync curl -XPOST localhost:27182/api/v1/start --data '

    { "source": "cluster0", "destination":"cluster1" } ' Live Migrateの流れ(切り戻しパターン)
  18. 旧MongoDB MongoDB Atlas カットオーバー可能 ① mongosync curl -X GET http://localhost:27182/api/v1/

    { "progress":{ "state":"RUNNING", "canCommit":true, "lagTimeSeconds":3 } } Live Migrateの流れ(切り戻しパターン)
  19. 4. 負荷試験 切り戻しパターンの移⾏テストを通して • 逆移⾏のmongosyncもおよそ3時間半ほどで完了した • つまりRTOは4時間ほどで、これがサービス影響⾯から許容できるかどうか判断する必要がありました • 移⾏前の最新バックアップからデータを復元するという⼿段もあったが、RPO(Recovery Point

    Objective)、 つまり復旧時間よりもデータの⽋損をさせないことの⽅が優先度が⾼いため、切り戻しの際はサービスメンテナンスを⼊れて 再度同期し直すという⽅針に決めた • 幸い本番移⾏後は⼤きな障害がなかったため切り戻すことはなかったが、リカバリ戦略はしっかり計画しておくのが安全
  20. 4. 負荷試験 負荷試験 • ピグパーティには本番同等の構成・スペックを再現した負荷試験環境がある • Atlasに移⾏した後でも、移⾏前の同等のパフォーマンスが満たせるかどうか検証する必要があった • 旧MongoDBとAtlasのスペック・シャード数は同じ条件で⾏う •

    負荷試験ツールはGatlingを使⽤ 負荷試験のパターン 1. 本番のピーク帯想定のスループットを再現したシナリオで負荷をかけて要件を満たすかどうか確認する性能テスト 2. 徐々にスループットを上げて、システムキャパシティを確認する限界テスト
  21. 4. 負荷試験 負荷試験を通してわかったこと l 旧MongoDBとAtlasの性能差 • 以前のDBとほとんど性能差はあまり無かった l コネクション数が枯渇しないようなサーバー台数とmaxPoolSizeの最適な値の確認 •

    MongoDB AtlasはTierごとに最⼤コネクション数が決まっている • Node.jsはシングルスレッドでスペックアップが難しいため、負荷対策は⽔平スケールアウトを⾏う必要がある • そのため、maxPoolSizeで最⼤接続数を調整しつつ、サーバースケールの限界値も確認した
  22. データベース移⾏の流れと移⾏戦略 検討 計画 インフラ構築 負荷試験 データ移⾏ 最適化 • Atlasについて知る •

    ハンズオン • コストの⾒積もり • Atlas移⾏の意思決定 • 移⾏⽅式の設計 • 移⾏後の環境設計 • クラスター構築 • GCP-Atlas間のVPC連携 • 移⾏テスト • リカバリテスト • 負荷試験 • データ移⾏ • サービスメンテナンス • 切り替え作業 • 移⾏終了後の運⽤ • キャパシティの⾒直し • コスト最適化
  23. Live Migrateの流れ • クラスターの構築・Cloud ManagerとAtlasを連携 • プライベートエンドポイントを使⽤して、AtlasとソースクラスターのVMと接続 1 2 •

    Live Migrateを実⾏し、ソースクラスターからAtlasへデータの初期同期を開始 3 • 両クラスター間のラグが短くなれば、メンテナンスを⼊れて、ソースクラスターへの書き込みを停⽌ 4 • カットオーバーを実⾏し、残りの増分データを同期 5 • アプリケーションサーバーのDB接続先をAtlasへ変更 6 • メンテナンスを終了し、サービスを再開
  24. Live Migrateの流れ • クラスターの構築・Cloud ManagerとAtlasを連携 • プライベートエンドポイントを使⽤して、AtlasとソースクラスターのVMと接続 1 2 •

    Live Migrateを実⾏し、ソースクラスターからAtlasへデータの初期同期を開始 3 • 両クラスター間のラグが短くなれば、メンテナンスを⼊れて、ソースクラスターへの書き込みを停⽌ 4 • カットオーバーを実⾏し、残りの増分データを同期 5 • アプリケーションサーバーのDB接続先をAtlasへ変更 6 • メンテナンスを終了し、サービスを再開 メンテナンス前⽇
  25. Live Migrateの流れ • クラスターの構築・Cloud ManagerとAtlasを連携 • プライベートエンドポイントを使⽤して、AtlasとソースクラスターのVMと接続 1 2 •

    Live Migrateを実⾏し、ソースクラスターからAtlasへデータの初期同期を開始 3 • 両クラスター間のラグが短くなれば、メンテナンスを⼊れて、ソースクラスターへの書き込みを停⽌ 4 • カットオーバーを実⾏し、残りの増分データを同期 5 • アプリケーションサーバーのDB接続先をAtlasへ変更 6 • メンテナンスを終了し、サービスを再開 メンテナンス当⽇
  26. 5. データ移⾏ メンテナンス前⽇ • ⾼負荷のバッチ処理は停⽌ • Live Migrateを実施 メンテナンス当⽇ •

    メンテナンスを⼊れてcutoverを実⾏ • Professional Servicesを活⽤し、メンテナンスの前⽇と当⽇でAtlasのエンジニアとのサポート体制も取るようにした 具体的なサポート内容 • メンテナンス⼿順のレビュー • Atlasクラスターのストレージサイズのベストプラクティス(マイグレーションでOplogサイズが増えるため) • バックアップ頻度のベストプラクティス • メトリクスの監視 • 常時、slackとzoomで連携できる環境
  27. データベース移⾏の流れと移⾏戦略 検討 計画 インフラ構築 負荷試験 データ移⾏ 最適化 • Atlasについて知る •

    ハンズオン • コストの⾒積もり • Atlas移⾏の意思決定 • 移⾏⽅式の設計 • 移⾏後の環境設計 • クラスター構築 • GCP-Atlas間のVPC連携 • 移⾏テスト • リカバリテスト • 負荷試験 • データ移⾏ • サービスメンテナンス • 切り替え作業 • 移⾏終了後の運⽤ • キャパシティの⾒直し • コスト最適化
  28. まとめ MongoDB Atlasへ移⾏してみてよかったこと 運⽤管理コストの削減 • ⼿動で⾏なっていた作業によるヒューマンエラーの防⽌ • スケールアップ、バックアップなどをAtlas側が⾃動で⾏なってくれるため、管理に費やす時間とリソースを⼤幅削減 • mongod12台

    + mongos5台のスペックアップに5時間費やしていたのが30分に短縮(操作⾃体は1分) パフォーマンスの最適化 • オートスケーリングが可能なので、パフォーマンス最適化とコスト効率が向上に繋がる • ピグパーティは時間帯によって同接数がかなり変動するサービスであるため、導⼊メリットは ◎ • プロファイル機能を活⽤しスロークエリの特定が可視化しやすくなった