【レポート】RDBMS だけで本当にいいの？ NoSQL on AWS の勘所 #AWSSummit

登壇者

アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト 桑野 章弘

アジェンダ

• 本セッションの目的
• よくある話
• NoSQL
• AWSのNoSQLサービス
• NoSQLユースケース
• NoSQLのデザインパターンの考え方

本セッションの目的

NoSQLの活用方法を知り、より良いシステムを目指す！

よくある話

よくある話としてNoSQLを使うにあたり、以下のような話が出てくる

• 「特にRDBMSで困ってないし使う必要がないのでは？」
• 「使ってみたけど運用大変だし、逆に性能悪くなったよ。」
• 「そもそもNoSQLってどういうときに使うの？」

NoSQLとは

• キーバリューストア
  • KeyとValueの単純構造
  • メモリにすべて入るのでパフォーマンスが高い
• カラム指向データベース
  • カラム指向データ
  • ログなどの大量データ解析向き
• ドキュメント思考DB
  • JSONなどのデータ構造に対応して複雑なデータモデリングを容易に実現化
• グラフ指向データベース
  • ノード同士の関係性を使用するDB

NoSQLで実現したいこと

• NoSQLを使うことは目的ではない
• 実現したことがあるからNoSQLを使う
• ユースケースとしては以下のイメージ
  • どこまでスケールするかわからない基盤
  • 低レイテンシ・高スループットが必要な基盤
  • スケールするWebセッション管理
  • Publish/Subscriptionモデル
  • イベント処理
  • JSONデータ格納
  • ...etc
• これらをどう実現するのかをNoSQLを選択される

AWSのNoSQLサービス

AWSのデータベースサービス

• DynamoDB
• ElastiCache
• Neptune
• RDS
• Redshift

NoSQLが採用されているデータベースは？

Amazon ElastiCache

• インメモリキーバリューストア
• フルマネージド
  • バックアップ等の運用はAWSが対応
• ハイパフォーマンス
• 高いスケーラビリティ
  • クラスタリングに対応している
• Redis,Memcached
• Amazonによる拡張(Amazon Redis)
  • バックアップ改善
  • FailOverの起動が早い
• 高可用性と堅牢性
  • SecurityGroup
  • VPC対応
  • 暗号化
• ElastiCache機能追加
  • セキュリティ気機能の強化
    • Encryption-Intransit
    • Encryption-at-rest
    • Redis-AUTH
• RedisClusterの対応
  • Redis3.2でRedisClusterのサポート
  • データを最大15シャードが使えて6TiB使える
  • 最大2000万Read,450万Write
• RedisClusterOnlineClusterResizing
  • シャード数を変更するときにダウンタイムが発生していたが、本機能を使うことで動的にダウンタイムなしで増減できるようになった
  • 構成例として下記の構成が可能になった
    • CWにてパフォーマンス劣化を検知
    • AWS SNS経由でLambdaを実行
    • ダウンタイム0でシャード変更

Amazon DynamoDB

• フルマネージド
• 高速かつ一貫したパフォーマンス
• 高いスケーラビリティ
• 柔軟性
• イベント指向のプログラミングも可能
• 高いセキュリティ
• 特徴
  • 信頼性が硬い(管理が不要)
    • SPOFが存在しない構成
    • データは3箇所のAZに保存される
    • ストレージは必要に応じて自動的にパーティショニングされる
  • プロビジョンドスループット
    • テーブルごとのReadやWriteに対して必要なスループットキャパシティを割り当てられる
    • RCU、WCUが存在し割り当てれれば料金がかかる
    • 別途金額が発生する
    • オンラインで対応が可能
  • ストレージの容量制限がない
  • 使った分だけ従量課金
  • ディスクやノード増設作業は一切不要
• 機能追加
  • バックアップ・リストア
    • ネイティブ対応している
    • 数百TBでもパフォーマンス影響無しで可能
    • PITRや継続的バックアップを実現
  • DynamoDB Global Tables
    • 複数リージョンでデータを供したテーブルを作成可能
    • グローバルアプリケーションやDR対応に利用出来る
    • 東京は未提供
    • すべてのローカルにあるリージョンのテーブルに読み書きした物が非同期レプリケーションされる
  • AutoSaling
    • キャパシティ設定(WCU,RCUなど)を動的管理
    • ターケゲット使用率と上限下限を設定することで必要なリソースに設定できる
  • Amazon DynamoDB Accelerator(DAX)
    • DynamoDB全面に配置
    • マネージドかつAPI互換のキャッシュクラスタを配置して使えるサービス
  • 読み込みの低レイテンシを実現
  • TTL(Time To Live)
    • テーブルのItem有効期限を設定可能
    • ログを取得し続けたときにその分スループットが発生するので課金が発生する
    • TTLを設定することでログ保存期間を設定できる

Amazon Neptune

• 高速
  • 高レベルのリレーションシップをミリ秒のレイテンシで問い合わせを実施できる
  • 高信頼性
    • 3つのAZに跨る6つのレプリカをフルバックアップリストアを提供
  • 簡単
    • GremlinとSPARQLによる簡単でパワフルなクエリを実行可能
  • Apache TinkerPop&W3CrDFグラフモデルをサポート
• グラフDBの得意分野
  • 高度に連結された以下のデータが得意分野として挙げられる
    • ソーシャルネットワーク
    • レストランのレコメンデーション
    • 不正取引の検出

NoSQLのユースケース

• キャッシング
  • セッション情報などの頻繁アクセスしないものをオフロード
  • DBへのクエリ結果をキャッシュしておく
  • Amazon DynamoDB Acceleratorを使う
• IoTソリューション
  • IoTデバイスからIoTを吸い上げる
  • ルールエンジンを利用してLambdaを実行してElastiCacheやDynamoDBへ保存する
    • 大量データはDynamoDBに保存
    • 低レイテンシはElastiCacheに保存
• Pub/Subアプリ
  • ElastiCacheはPub/Subとしても動作可能
  • チャットメッセージサービスでPub/Subを実行
  • リアルタイムリーダーボードなどで利用が可能
• 非同期アプリ - リアルタイム性の高いゲームにも使用が可能 - ElastiCacheのRedisSortedSetsを活用することで簡単に実現できる
• グローバルアプリ
  • GlobalTablesを活用することで世界中で同じテーブルにアクセスをかける
  • 独自で持てば良いものは各リージョンで通常テーブルに持つ
• 非同期処理
  • DynamoDBStreamsを使ってDBの変更内容を他サービスへ連携
  • Lambdaが受け取ったデータをLambdaで他サービスへ処理を行う
• 時系列が必要なアプリ
  • ホットデータとコールドデータをテーブルで分ける
  • DynamoDBStreamsとGSIを活用して、非同期でホットデータをコールドデータに移行する
  • TTLを活用することで使用しないデータを無効にする
• デザインパターンの考え方
  • RDBMSでのデータモデリング手法をNoSQLに当てはめても最適化出来ない場合がある
  • 例えば正規化が該当する(RDBを上手く動かすベストプラクティスは全く別)
  • データ連携にこだわらず実現したいこと(目的)にこだわる

まとめ

• NoSQLを利用するにあたって明確な実現をしたいゴールが必要
• RDBMSと同じ方法論でNoSQLを扱おうとすると失敗する
• 各データストアのアーキテクチャを留意することが大事
• NoSQLを適切に使うことでRDBMSできないことを実現できる

最後に

全体を通してNoSQLの大事な考慮点が盛り込まれていたセッションと感じました。
それぞれの製品に合わせて、適切なアーキテクチャを選択する点は非常に共感を覚えました！