Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à [MongoDB勉強会 in 2017] MongoDB on AWS
Similaire à [MongoDB勉強会 in 2017] MongoDB on AWS (20)
Plus de Shuji Kikuchi
Plus de Shuji Kikuchi (20)
[MongoDB勉強会 in 2017] MongoDB on AWS
- 1. MongoDB on AWS 2017年9⽉12⽇ 菊池修治 MongoDB勉強会 in 2017
- 2. 2⾃⼰紹介 菊池 修治 - クラスメソッド株式会社 - AWS事業部 - Solutions Architect - AWS認定 5冠 - SIer → 製造業 → クラスメソッド - 好きなデータストア - MongoDB
- 3. 3 クラスメソッドメンバーズ カスタマーストーリー モバイル アプリケーション開発 ビッグデータ 分析基盤構築 クラウド、モバイル、ビッグデータ に特化したコンサルティングやシステムの 設計・開発サービスを提供しています。 AWSクラウド環境を総合⽀援する サービスです。AWS導⼊⽀援や円建 て請求書の発⾏、構築後の運⽤保守 などをワンストップでサポートしま す。 BtoC や BtoBtoCの⼤⼿企業のオム ニチャネル戦略実施を数多く⽀援し てきたクラスメソッドのノウハウを 集約したマーケティングプラット フォームです。 iOS / Androidアプリケーションを オーダーメイドで開発いたします。 多数の実績により蓄積された豊富な ノウハウによって、品質の⾼いアプ リケーションをご⽤意します。 多様なニーズに沿ったデータマネジ メントシステムをオーダーメイドで 開発いたします。お客様の保有する ⼤規模なデータの収集と蓄積、分析 を⾏う仕組みをご提案し、データ活 ⽤全体をご⽀援いたします。 クラスメソッド 事業内容
- 4. 4ブログの会社です！
- 5. 5Agenda Introduction MongoDB on AWS - バックアップとリストア - パフォーマンス - マネージドサービス連携 まとめ
- 6. Introducton
- 7. 7Introduction AWSでは多くのフルマネージドなDBを提供 MongoDBを使うならMongoDBが得意な領域に使う • JSONドキュメントへのリッチなクエリ • スキーマレスを活かせるか DynamoDB ElastiCache RDS Redshift EMR
- 10. バックアップとリストア
- 11. 11バックアップ⼿段 • Dumpの取得 • スナップショット • CloudManager/OpsManager
- 12. 12Dump取得 • mongodumpで取得 • データベース/コレクションを指定して取得可能 • 注意点 • ポイントインタイムリカバリは不可 • 取得するノードにI/Oが発⽣ • 取得したダンプファイルは安全な場所に保存する
- 13. 13スナップショット • EBSスナップショットを取得 • 取得時に負荷はかからない • 差分バックアップなのでこまめに取得しても費⽤は 抑えられる • 注意点 • ポイントインタイムリカバリは不可 • スナップショットからリストア時にはEBSのパフォーマ ンスに注意
- 14. 14EBSのプレウォーミング • スナップショットから復元したEBSは初期化が必要 • EBS各ブロックの初回アクセス時にはレイテンシが増⼤ • dd/fioで全ブロックにアクセスすることで本来のパフォーマンスが 発揮可能に • 新規に作成したEBSは初期化不要
- 15. 15CloudManager/OpsManager • OplogをCloudManager/OpsManagerで取得 • ポイントインタイムリカバリが可能 • 注意点 • CloudManagerは有償のクラウドサービス • OpsManagerはサブスクリプション契約が必要
- 16. 16バックアップからのリストア いずれの⽅法もリストアに時間がかかることに注意 リストア⽅法 必要な作業 Dumpからのリストア • ダンプデータの転送 • ノードへのインポート スナップショット復元 • EBSのプレウォーミング CloudManager/OpsManager • データの出⼒/転送 • ノードへのインポート
- 17. 17データ保護⼿段 レプリケーションを⼯夫しておくことも有効 • 災害対策： • 他リージョンへの遠隔レプリケーション • オペレーションミス対策： • 遅延レプリケーション
- 18. パフォーマンス
- 19. 19MongoDBのパフォーマンスチューニング 基本はRDBと同じアプローチ • I/Oの最⼩化 • ホットデータをメモリに乗せる • Indexを使う • I/Oの⾼速化 • ネットワークの最適化 • ストレージの最適化
- 20. 20AWSでパフォーマンスを向上させるTips • ストレージの最適化 • EBS • インスタンスストレージ • EC2パフォーマンス向上のオプション • EBS最適化 • プレイスメントグループ • 拡張ネットワーキング
- 21. 21AWSでパフォーマンスを向上させるTips • ストレージの最適化 • EBS • インスタンスストレージ • EC2パフォーマンス向上のオプション • EBS最適化 • プレイスメントグループ • 拡張ネットワーキング
- 22. 22ストレージの最適化 GP2（汎⽤SSD） • 1GBあたり 3 IOPSのIO性能が割り当て（ベースライン） • 1TB未満ではクレジットを消費して3000 IOPSまでバースト • クレジットが枯渇するとベースラインまで低下 • 1ボリューム最⼤10,000 IOPS • 1インスタンス最⼤75,000 IOPS • インスタンスタイプによって制限あり MongoDBでは • ホットデータに対し⼗分なメモリがある場合には問題ない • フルスキャン時のクレジット枯渇に注意 • データのインポート/エクスポート、インデックス追加
- 23. 23ストレージの最適化 IO1（プロビジョンドIOPS） • $0.073/IOPSで必要性能を割り当て • 50 IOPS/GBまでプロビジョニング可能 • 1ボリューム最⼤20,000 IOPS • 1インスタンス最⼤75,000 IOPS • インスタンスタイプによって制限あり MongoDBでは • 安定したIO性能が必要な場合の選択肢
- 24. 24EBSの変更 • 2017年2⽉のアップデートでEBSのタイプ変更と容量追加が可能に • GP2からIO1、IO1からGP2など • 追加分の容量を利⽤するためにはファイルシステムの拡張が必要 • GP2では.. • 容量追加に伴うIO性能向上は⾃動で反映 • クレジット枯渇時に容量変更すると、クレジットが完全に回復 • ただし、1度変更すると次の変更は6時間後まで不可能
- 25. 25ストレージ最適化インスタンスの利⽤ • I3インスタンス（2017年2⽉にGA） • NVMe SSDを搭載 • PCI Express直結のSSD • 最⼤ 3,300,000 IOPS • インスタンスストア（再起動でデータが失われる） インスタンスタイプ vCPU メモリ I3インスタンスストレージ I3料⾦（時間単価） i3.large 2 15.25 1 x 475 NVMe SSD $0.18 i3.xlarge 4 30.5 1 x 950 NVMe SSD $0.37 i3.2xlarge 8 61 1 x 1900 NVMe SSD $0.73 i3.4xlarge 16 122 2 x 1900 NVMe SSD $1.46 i3.8xlarge 32 244 4 x 1900 NVMe SSD $2.93 i3.16xlarge 64 488 8 x 1900 NVMe SSD $5.86
- 26. 26I3インスタンスを利⽤したMongoDB構成 役割によってインスタンスタイプ、 ストレージを使い分ける • アクセスされるノードにI3/NVMe SSDを使⽤ • HiddenノードはEBSを使いデータを 永続化 EBS NVMe SSD NVMe SSD Primary Secondary Secondary Hidden App Write/Read Read
- 27. 27AWSでパフォーマンスを向上させるTips • ストレージの最適化 • EBS • インスタンスストレージ • EC2パフォーマンス向上のオプション • EBS最適化 • プレイスメントグループ • 拡張ネットワーキング
- 28. 28EBS最適化 • 通常のNWトラフィックと分離したEBS専⽤の帯域が確保される • T2を除く現⾏の主要インスタンスタイプ（M4/C4/R4/I3）では デフォルトで有効化 Network EBS Network EBS EBS最適化⾮対応インスタンス EBS最適化インスタンス
- 29. 29EBS最適化 • インスタンスタイプにより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
- 30. 30拡張ネットワーキングとプレイスメントグループ 拡張ネットワーキング • 有効化することで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
- 31. 31拡張ネットワーキングとプレイスメントグループ 効果 • 同⼀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/
- 32. マネージドサービス連携
- 33. 33AWS Database Migration Service データベースの移⾏を⽀援するサービス • 異なるデータベースエンジン間の移⾏に対応 • AWS/オンプレのDBに対応 • フルロードとChange Data Captur（CDC） • フルロード：⼀括で全データを移⾏（ワンタイム） • CDC：変更差分を反映
- 34. 34DMSを利⽤したレプリケーション • SourceとしてMongoDBをサポート • CDCサポート • oplogを使⽤するためレプリカセット必須 • モデルの異なるデータストアに対し2つの モードを⽤意 • テーブルモード • ドキュメントモード
- 40. 40S3ターゲットの活⽤ • S3ターゲットにCSV出⼒ • 他のAWSサービスと柔軟に連携 • DynamoDB • EMR • Redshift/Redshift Spectrum • Athena
- 41. まとめ
- 42. 42まとめ AWSでMongoDBを最適に使う • バックアップはリストア⽅法を考慮する • EC2/EBSの特性を理解したチューニング • マネージドサービスを利⽤して活⽤の幅を広げる