Developers.IO 2017 MongoDB on AWS Advance
1 like954 views
Developers.IO 2017 で発表したスライドです
Developers.IO 2017 MongoDB on AWS Advance
- 2. 2⾃⼰紹介 菊池 修治 - クラスメソッド AWS事業部 - Solutions Architect - AWS認定 5冠 - SIer → 製造業 → クラスメソッド - 好きなAWSサービス - S3、SystemsManager、DMS - 好きなデータストア - MongoDB
- 3. 3Agenda Introduction MongoDB on AWS - レプリカセット - バックアップとリストア - パフォーマンス - マネージドサービス連携 まとめ
- 4. Introducton
- 6. 6Introduction AWSでは多くのフルマネージドなDBを提供 MongoDBを使うならMongoDBが得意な領域に使う • JSONドキュメントへのリッチなクエリ • スキーマレスを活かせるか DynamoDB ElastiCache RDS Redshift EMR
- 9. レプリカセット
- 10. 10レプリカセット • 3台以上のノードで構成しデータをレプリケーション • WriteはPrimaryへ • Readは負荷分散可能
- 11. 11レプリカセットのパラメータ • レプリケーションを設計する上で考慮すべきパラメータ 項⽬ 設定値 説明 priority 0 - 100 • プライマリ選出の優先度 • 値が⼤きいノードが優先でプライマリに選出 • 0の場合はプライマリには昇格しない votes 0 or 1 • プライマリ選出における投票権 • 0の場合にはプライマリ選出に参加しない • レプリカセットの合計を奇数にする arbiterOnly true | false • データを保持せずプライマリ選出にのみ参加するノー ドに指定する hidden true | false • 指定することでクライアントから隠された状態になる • hiddenノードはプライオリティを必ず0にする tags string • ノードにKey:Valueのタグを付与する
- 12. 12レプリカセット構成パターン • AWSではMulti-AZが基本 • 障害時のスプリットブレイン回避を考慮し配置する • 構成パターン • Multi-AZ（3 AZリージョン） • Multi-AZ（2 AZリージョン） • Multi-AZ + 別拠点 • Multi-AZ + Arbiter • Hiddenノードを含む構成 • 4ノード構成
- 13. 13レプリカセット構成パターン Multi-AZ（3 AZリージョン） • ベーシックな構成 • AZレベルでの障害でもサービス継続
- 14. 14レプリカセット構成パターン Multi-AZ（2 AZリージョン） • AZが2つのリージョンでの基本構成 • ⾼プライオリティのノードを⽚AZに集約
- 15. 15レプリカセット構成パターン Multi-AZ + 別拠点 • 遠隔レプリケーション構成 • 他拠点のノードはプライオリティ を0にしてプライマリ昇格を抑⽌
- 16. 16レプリカセット構成パターン Multi-AZ + Arbiter • データレプリカが2つで ⼗分な場合 • Arbiterは最⼩スペックで 問題ない
- 19. 19Write Concern • 書き込むデータの⼀貫性レベルを指定 • 何台のノードに書き込まれた時点で応答を返すか • 書き込みパフォーマンスとのトレードオフ • デフォルトはw=1 • w=2以上にする場合は障害時の影響を考慮する w値 動作 w = 0 応答を待たない w = n n台のノードに書き込みが完了したら応答 w = majority 過半数のノードに書き込みが完了したら応答 w = <tag set> 指定のタグのノードに書き込みが完了したら応答
- 20. バックアップとリストア
- 21. 21バックアップ⼿段 • Dumpの取得 • スナップショット • CloudManager/OpsManager
- 22. 22Dump取得 • mongodumpで取得 • データベース/コレクションを指定して取得可能 • 注意点 • ポイントインタイムリカバリは不可 • 取得するノードにI/Oが発⽣ • 取得したダンプファイルは安全な場所に保存する
- 23. 23スナップショット • EBSスナップショットを取得 • 取得時に負荷はかからない • 差分バックアップなのでこまめに取得しても費⽤は 抑えられる • 注意点 • ポイントインタイムリカバリは不可 • スナップショットからリストア時にはEBSのパフォーマ ンスに注意
- 24. 24EBSのプレウォーミング • スナップショットから復元したEBSは初期化が必要 • EBS各ブロックの初回アクセス時にはレイテンシが増⼤ • dd/fioで全ブロックにアクセスすることで本来のパフォーマンスが 発揮可能に • 新規に作成したEBSは初期化不要
- 25. 25CloudManager/OpsManager • OplogをCloudManager/OpsManagerで取得 • ポイントインタイムリカバリが可能 • 注意点 • CloudManagerは有償のクラウドサービス • OpsManagerはサブスクリプション契約が必要
- 26. 26バックアップからのリストア いずれの⽅法もリストアに時間がかかることに注意 リストア⽅法 必要な作業 Dumpからのリストア • ダンプデータの転送 • ノードへのインポート スナップショット復元 • EBSのプレウォーミング CloudManager/ OpsManager • データの出⼒/転送 • ノードへのインポート
- 27. 27データ保護⼿段 レプリケーションを⼯夫しておくことも有効 • 災害対策： • 他リージョンへの遠隔レプリケーション • オペレーションミス対策： • 遅延レプリケーション
- 28. パフォーマンス
- 30. 30MongoDBのパフォーマンスチューニング 基本はRDBと同じアプローチ • I/Oの最⼩化 • ホットデータをメモリに乗せる • Indexを使う • I/Oの⾼速化 • ネットワークの最適化 • ストレージの最適化
- 31. 31AWSでパフォーマンスを向上させるTips • ストレージの最適化 • EBS • インスタンスストレージ • EC2パフォーマンス向上のオプション • EBS最適化 • プレイスメントグループ • 拡張ネットワーキング
- 32. 32AWSでパフォーマンスを向上させるTips • ストレージの最適化 • EBS • インスタンスストレージ • EC2パフォーマンス向上のオプション • EBS最適化 • プレイスメントグループ • 拡張ネットワーキング
- 33. 33ストレージの最適化 GP2（汎⽤SSD） • 1GBあたり 3 IOPSのIO性能が割り当て（ベースライン） • 1TB未満ではクレジットを消費して3000 IOPSまでバースト • クレジットが枯渇するとベースラインまで低下 • 1ボリューム最⼤10,000 IOPS • 1インスタンス最⼤75,000 IOPS MongoDBでは • ホットデータに対し⼗分なメモリがある場合には問題ない • フルスキャン時のクレジット枯渇に注意 • データのインポート/エクスポート、インデックス追加
- 34. 34ストレージの最適化 IO1（プロビジョンドIOPS） • $0.073/IOPSで必要性能を割り当て • 50 IOPS/GBまでプロビジョニング可能 • 1ボリューム最⼤20,000 IOPS • 1インスタンス最⼤75,000 IOPS MongoDBでは • 安定したIO性能が必要な場合の選択肢
- 35. 35EBSの変更 • 2017年2⽉のアップデートでEBSのタイプ変更と容量追加が可能に • GP2からIO1、IO1からGP2など • 追加分の容量を利⽤するためにはファイルシステムの拡張が必要 • GP2では.. • 容量追加に伴うIO性能向上は⾃動で反映 • クレジット枯渇時に容量変更すると、クレジットが完全に回復 • ただし、1度変更すると次の変更は6時間後まで不可能
- 36. 36ストレージ最適化インスタンス • 2017年2⽉にI3インスタンスがGA • NVMe SSDを搭載 • PCI Express直結のSSD • 最⼤ 3,300,000 IOPS • インスタンスストア（再起動でデータが失われる）
- 37. 37ストレージ最適化インスタンス インスタンス サイズ vCPU メモリ I3インスタンス ストレージ I2インスタンス ストレージ I3料⾦ I2料⾦ large 2 15.25 1 x 475 NVMe SSD - $0.18 - xlarge 4 30.5 1 x 950 NVMe SSD 1 x 800 SSD $0.37 $1.00 2xlarge 8 61 1 x 1900 NVMe SSD 2 x 800 SSD $0.73 $2.00 4xlarge 16 122 2 x 1900 NVMe SSD 4 x 800 SSD $1.46 $4.00 8xlarge 32 244 4 x 1900 NVMe SSD 8 x 800 SSD $2.93 $8.00 16xlarge 64 488 8 x 1900 NVMe SSD - $5.86 - • I3が登場しストレージ最適化インスタンスが⼿頃に
- 38. 38I3インスタンスを利⽤したMongoDB構成 役割によってインスタンスタイプ、 ストレージを使い分ける • アクセスされるノードにI3/NVMe SSDを使⽤ • HiddenノードはEBSを使いデータを 永続化 EBS NVMe SSD NVMe SSD Primary Secondary Secondary Hidden App Write/Read Read
- 39. 39AWSでパフォーマンスを向上させるTips • ストレージの最適化 • EBS • インスタンスストレージ • EC2パフォーマンス向上のオプション • EBS最適化 • プレイスメントグループ • 拡張ネットワーキング
- 40. 40EBS最適化 • 通常のNWトラフィックと分離したEBS専⽤の帯域が確保される • T2を除く現⾏の主要インスタンスタイプ（M4/C4/R4/I3）では デフォルトで有効化 Network EBS Network EBS EBS最適化⾮対応インスタンス EBS最適化インスタンス
- 41. 41EBS最適化 • インスタンスタイプによりIO性能の限界があることに注意 インスタンス タイプ 最⼤スルー プット 最⼤IOPS （16KB） c4.large 62.5 4,000 c4.xlarge 93.75 6,000 c4.2xlarge 125 8,000 c4.4xlarge 250 16,000 c4.8xlarge 500 32,000 i3.large 50 3,000 i3.xlarge 100 6,000 i3.2xlarge 200 12,000 i3.4xlarge 400 16,000 i3.8xlarge 850 32,500 i3.16xlarge 1,750 65,000 インスタンス タイプ 最⼤スルー プット 最⼤IOPS （16KB） m4.large 56.25 3,600 m4.xlarge 93.75 6,000 m4.2xlarge 125 8,000 m4.4xlarge 250 16,000 m4.10xlarge 500 32,000 m4.16xlarge 1,250 65,000 r4.large 54 3,000 r4.xlarge 109 6,000 r4.2xlarge 218 12,000 r4.4xlarge 437 18,750 r4.8xlarge 875 37,500 http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/EBSOptimized.html
- 42. 42拡張ネットワーキングとプレイスメントグループ 拡張ネットワーキング • 有効化することでPPS、レイテンシが最適化 • 対応インスタンスタイプ • VF：C3、C4、D2、I2、R3、M4 (m4.16xlarge を除く) • ENA：F1、I3、P2、R4、X1 および m4.16xlarge • Amazon Linuxで対応インスタンスタイプの場合はデフォルトで有効 プレイスメントグループ • インスタンスを論理グループ化しインスタンス間通信を最適化 • 同⼀AZに限る http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/enhanced-networking.html http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/placement-groups.html
- 43. 43拡張ネットワーキングとプレイスメントグループ 効果 • 同⼀AZ内のインスタンス間のPing 100回の結果 • インスタンスタイプ：c3.large • OS：CentOS6 条件 最⼩（ms） 平均（ms） 最⼤（ms） 標準偏差 デフォルト 0.318 0.385 0.814 0.075 拡張ネットワーキング有効化 0.202 0.220 0.389 0.023 プレイスメントグループ有効化 0.239 0.301 0.410 0.034 拡張ネットワーキング + プレイスメントグループ 0.130 0.157 0.172 0.018 http://dev.classmethod.jp/cloud/aws/ec2-placement-group/
- 44. マネージドサービス連携
- 45. 45AWS Database Migration Service データベースの移⾏を⽀援するサービス • 異なるデータベースエンジン間の移⾏に対応 • AWS/オンプレのDBに対応 • フルロードとChange Data Captur（CDC） • フルロード：⼀括で全データを移⾏ • CDC：変更差分を反映
- 46. 46DMSを利⽤したレプリケーション • SourceとしてMongoDBをサポート （2017/4 Update!） • CDCサポート • Oplogを使⽤するためレプリカセット必須 • モデルの異なるデータストアに対し2つの モードを⽤意 • テーブルモード • ドキュメントモード
- 52. 52S3ターゲットの活⽤ • S3ターゲットにCSV出⼒ • 他のAWSサービスと柔軟に連携 • DynamoDB • EMR • Redshift/Redshift Spectrum • Athena
- 53. 53MongoDB Atlas MongoDB の Database as a Service • 従量課⾦でフルマネージドなMongoDBを利⽤可能 • AWSの全リージョンに対応 • AWSとの機能統合 • ⾃分のAWSアカウントのVPCとピアリング • セキュリティグループ参照 • MongoDBのエコシステムと連携 • CloudManagerと統合 • 移⾏ツールmongomirror
- 54. まとめ
- 55. 55まとめ AWSでMongoDBを最適に使う • AZを考慮したレプリカセット配置 • バックアップはリストア⽅法を考慮する • EC2/EBSの特性を理解したチューニング • マネージドサービスを利⽤して活⽤の幅を広げる
- 56. おまけ
- 58. 58MongoDB World 2017 • 6⽉20、21⽇にシカゴで開催 • 主な発表 • MongoDB AtlasがGCP/Azureでもサポート（すでに利⽤可能） • モバイル向けBaaS、MongoDB Stitch（ベータ提供） • BIツール、Mongo Charts（MongoDB 3.6と共に年内提供予定）