【レポート】Sprinklr事例：EBSを活用したNoSQLデプロイの最適化 #reinvent #dat330

MongoDB on AWS Cloud

#セッションレポート

#レポート

#AWS

菊池修治

2017.12.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、菊池です。

本記事はAWS re:Invent 2017のセッション「DAT330 - Case Study: Sprinklr Uses Amazon EBS to Maximize Its NoSQL Deployment」のレポートです。

セッション概要

Sprinklr delivers a complete social media management system for the enterprise. It also helps the world’s largest brands do marketing, advertising, care, sales, research, and commerce on Facebook, Twitter, LinkedIn, and 21 other channels on a global level. This is all done on a single integrated platform. In this session, you learn about Sprinklr’s journey to the cloud and discover how to optimize your NoSQL database on AWS for cost, efficiency, and scale. We also do dive deep into best practices and architectural considerations for designing and managing NoSQL databases, such as Apache Cassandra, MongoDB, Apache CouchDB, and Aerospike on Amazon EC2 and Amazon EBS. We share best practices for instance and volume selection, provide performance tuning hints, and describe cost optimization techniques throughout.

スピーカーは以下の3名でした。

Andrey Zaychikov - Solutions Architect, AWS
GOPALA KRISHNA PADIDADAKALA - Platform Architect, sprinklr
Jamal Mazhar - Head of Infrastructure and DevOps, Sprinklr

レポート

イントロダクション：なぜNoSQLか
- データスキーマの拡大
- データボリューム
- 時間とレイテンシ
たくさんのNoSQLエコシステム
AWSにおけるNoSQLの選択肢
- DynamoDB：NoSQLサービス
- S3 + Athena：S3データへのSQLクエリの実行
- EC2 + EBS：EC2の利用
本当に分散型NoSQLクラスタを必要としているか？
- 正しいケース：
  - 完全な一貫性を必要としない
  - 依存関係のないシンプルなデータ構造
  - データ全体に対する素早いレポートが不要
  - レイテンシがもっとも重要でユーザが地理的に分散している
- 適さないケース：
  - 100%の一貫したデータが必須
  - 厳密に定義されたデータ構造
  - レイテンシの揺らぎが許容される
  - SQLを使用したレポートが必要
NoSQL技術の選択

MongoDBの概要・構成要素について説明がありました

Sprinklrについて

Sprinklrのアーキテクチャです

Sprinklrのデプロイメント

利用している主なプラットフォーム・プロダクトです

バックエンドアーキテクチャの変遷
- MySQLからスタートし、現在はElasticとMongoDBを主に使用しているようです

使用しているDBのノード数
- ElasticとMongoDBが大半ですね

SprinklrにおけるMongoDB

グローバルに展開されています

複数リージョンへのデプロイ
- EBSスナップショットを利用した展開

MongoDBを使用したアプリケーションインフラ

MongoDBの利用規模
- 900以上のノードとEBSボリューム
- 200TB以上のプライマリデータ
- 250レプリカセット、20クラスタ
- 2,000,000オペレーション/秒
- DRのため30TBのリージョン間データ同期
HAとDRプラン
- フェールオーバ
- ルーティング
- リクエストのハンドリング
- バックアップからのレストア
- 複数ロケーションへの保存
レプリカセット戦略
- Multi-AZに3ノード+Hiddenの構成です。

バックアップ
- Mongo Dump
  - 増分バックアップ不可
  - 50GB/時間
- rsyncでファイルコピー
  - 所要時間2時間以上
  - Lock/Stopが必要
  - 1つのバックアップのみ
- EBSスナップショット
  - 一貫した増分バックアップ
  - 所要時間10分以下
  - Lock/Stopは1分以下
  - コスト効果
データノードリカバリ
- Mongo Syncの場合
  - プライマリからのデータコピー
  - インデックス再作成
  - 差分データの同期
  - 所要時間：4日間
EBSの変遷
- IO1（PIOPS）からGP2に
  - データノードリカバリが4日間から1、2時間に
  - ボリュームサイズ
  - インスタンスタイプのスケール
  - Oplogサイズがボリュームの40%から10%に
DRプロセス
- 取得していたスナップショットを自動で展開

起動時の最適化
- Oplogボリュームをスナップショットコピーし、他リージョンで復元

復元直後はWriteレイテンシが増加する

セキュリティの考慮

KMSを利用して暗号化してリージョン間でコピー

ストレージタイプの選択
- 容量と性能の増加に合わせて、コスト効果の高い選択が変遷したようです

まとめ：EBSのよさ
- デイリーバックアアップ：250以上のボリューム、200TBのデータを30分で取得
- 信頼性：HAとSLA
- コスト：66%削減
- RPO/RTOが許容できるレベルに
  - 帯域幅の拡張
  - スナップショット同時取得数上昇
  - クロスリージョンの同期が30時間から8時間以下に