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

こんにちは、菊池です。

本記事は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時間以下に

まとめ

MongoDBを大規模に利用しているSprinklrが、EBSを使ってどのように最適化してきたかの紹介でした。