【レポート】今から理解するNoSQL Databases〜ケーススタディと実践的データモデリング〜 AWS-44 #AWSSummit
2022年5月25日(水)~2022年5月26日(木)開催のAWS Summit Online 2022に参加しています。
今回はオンラインセッション AWS-44 今から理解するNoSQL Databases〜ケーススタディと実践的データモデリング〜 についてレポートします。
セッション概要
NoSQL Databaseは知っているが、実際にどうやって開発していくのかイメージが持てないという開発者の方に向けたセッションです。
前半では、ショッピングサイトをケーススタディとし、サービスの成長と共に起こる問題と、それに対処するデータベースの選択をご説明します。
後半ではNoSQLの開発でも頭を悩ませることが多い、データモデリングのやり方について、DynamoDBを例に取りステップ毎にポイントを解説していきます。
スピーカー
AWS 技術統括本部 ソリューションアーキテクト
上原 友理 氏
AWS 技術統括本部 ソリューションアーキテクト
堤 勇人 氏
資料についてはこちらからダウンロードできます。
※AWS Summit Online 2022の無料登録が必要です。
セッションのテーマ
- 目的別にデータベースを使い分ける具体的なシチュエーション
- DynamoDBを例に、データモデリングの実践的なステップの解説
レポート
NoSQL データベースが求められる背景
- 最新のアプリケーション要件ではより多くのパフォーマンス・拡張性・可用性が必要
- アクセスユーザーは100万+超えることも。アクセス元も世界中からくる
- 電子商取引やソーシャルメディア、オンラインゲーム等用途によって要件が求められる
- システムの成長とともに下記といった課題が発生する
- 読み込み負荷の上昇
- 複雑なクエリの検討
- 大量の同時接続・大量のレコード
- これらをリレーショナルデータベースだけで要求に対応するのは困難になっている
- 世の中の変化・要件に応えて幅広いデータベースサービスから適切なデータベースを選択することが必要
ケーススタディ ショッピングサイトの開発者の話
- ケーススタディを元にどのデータベースサービスを活用したらいいか学ぶ
- パターン1 サイトが表示されないとなった場合
- 読み込み負荷が上昇している
- レイテンシーが上昇していることがわかったのでDBを拡張しようとする
- 本当に拡張したら改善するのか?チューニングの余地はあるのか?
- どうやってレイテンシーを下げるべきか
- インメモリデータベースを活用する
- Amazon ElastiCasheを導入、キャッシュを活用し低レイテンシーを実現
- パターン2 ユーザー数が伸び悩んでいる場合
- 企画部門からユーザーを増やす為にユーザー同士の繋がり機能を追加してほしいと要望あり
- 複数ユーザーの中で、例えばAさんとBさんの共通の人はDさん、といった繋がり機能を設けたい
- フォロー関係を表すテーブルを作成するものの階層が増えて複雑に..
- グラフデータベースサービスを活用する
- Amazon Neptuneを導入、多対多の関係をシンプルにクエリすることを実現
- パターン3 ユーザー数が増えてエラー発生した場合
- ユーザーが増えることで大量の同時接続、大量のレコードが発生、エラーが頻発
- これ以上データベースを分散しても解決が難しい
- キーバリューデータベースで低レイテンシーのままスケールを検討
- アクセスパターンを整理、アプリケーションの改修で吸収できるか、ユーザー視点も考える
- 移行が可能な機能についてはキーバリュー型のAmazon DynamoDBを導入し、低レイテンシーを実現
- ユーザーが増えたらNoSQLを使うのか?
- 最初から全てNoSQLでいくか、使い慣れたRDBでいくか、どちらでも正解
- 要件を明確にしておくことが大事
- ゲームは低レイテンシーが求められるのでNoSQLでいくとか、新規サービスの早期リリースであればRDBでいく等
- 複数のDBの中から適材適所で組み合わせる
NoSQLデータモデリング
- データモデリングのステップは下記
- アプリケーションを理解する
- ER図を作成する
- アクセスパターンを全て書き出す
- データ特性を把握する
- 上を繰り返す、データモデリングは繰り返すことが大事
- アプリケーションを理解する
- 顧客、ユーザーの体験を自分でも理解する
- 担当者、開発者、営業等とミーティングを行う
- ER図を作成する
- RDBと一緒でNoSQLでもER図を作成することは大事
- ショッピングサイトであればUsers - Carts - Products といった流れ
- アクセスパターンを全て書き出す
- 一部ではなく”全て”
- その時の全てを書き出す、初めから完璧でなくてもよい
- データ特性を把握する
- カーディナリティ、サイズ、リクエストレートが重要
- テーブルの作成
- アクセスパターンをそのままテーブルにする
- コストを気にしないのであればそのまま完了でよい。コストが気になればテーブルを減らしていく
- DynamoDBに向いていないテーブル(OLAP等)は別のDBで検討する
- マージできそうなテーブルはマージしていき、書き込みテーブルと読み込みテーブルも一致させる
- GSI(Global Secondary Index)を利用してキー以外の要素でも探索できるようにする
- データモデリングのループ
- 最初から全てを想定できない
- ビジネスやAWSサービスもアップデートもある
- 必要なのはTinkering(データモデリングを繰り返すこと)
NoSQLデータモダナイゼーション With AWS
- データインフラのモダナイゼーションは下記が重要
- マネージドサービスの移行
- レガシーデータベースからの脱却
- 統合されたエコシステムの構築
- データインフラをクラウド化する
- コスト削減と柔軟さを獲得
- マネージドデータベースの利用する
- 運用の重労働を自動化させる
- purpose-build database
- 用途によって様々なデータベースを構築する
- 拡張性・信頼性・安全性に優れたデータ基盤をモダナイズさせよう
感想
NoSQLデータベースサービスについて、ケーススタディを元にどのDBを活用したらいいか学ぶことができました。
触ったことのないNoSQLデータベースサービス(Amazon Neptune等)をハンズオン等を探して触ってみようと思います。
データモデリングの考え方についてあまり知らなかったのですがとても分かりやすく勉強になりました。
最後に、リレーショナルデータベースとNoSQLデータベースの違いや各NoSQLデータベースサービスの説明は下記オンラインセミナーでも見れるとのことでした!ぜひ下記より見てみてください。
開発者のための、NoSQL Databaseの選び方 入門
ではまた!コンサルティング部の洲崎でした。