はじめに
リテール本部 SREグループの角田です。
この記事は STORES におけるセッションストアへの MemoryDB の活用と移行戦略について話してきました（前編） - hey Product Blog の後編です。
先日6月29日(水)にAWS主催の「インメモリデータベースで実現する超高速データベース活用セミナー」が開催されました。 私と松本さんの2人で、STORESのセッションストアをCookie からAmazon MemoryDB for Redisに移行した事例をお話してきました。
こちらの記事で予告したイベントです。
私は後半でセッションストアの選定理由や導入経緯についてお話しました。
資料はこちらです。
STORESサービスの構成
今回はSTORESのECサイトのお話なので、前提としてインフラ構成を紹介しておきます。
ポイントは以下の2点です。
- メインのDBがMongoDBである
- アプリケーションでRedisを既に利用している
関係する部分は STORES EC のインフラ構成 - hey Product Blog と大きく変わっていませんので、よかったらこちらの記事もどうぞ。
MemoryDBとは？
もう1つ前提としてMemoryDBについても紹介しておきます。
MemoryDBはRedis6.2+互換のインメモリデータベースです。 AWSの他のサービスよろしく、スケーラブル、フルマネージドなサービスになっています。
AWSには既にElastiCache for Redisが存在していますが、何が違うのでしょうか？
最大の違いはデータが高耐久で永続化目的でも使用できるという点です。 その他にもパフォーマンスやデフォルト設定など色々と違う点があります。
MemoryDBを採用するまで
セッションストアの候補
最終的に私達はMemoryDBを採用することになったのですが、それまでに挙がった候補が以下の4つになります。
- Redis
- MongoDB
- DynamoDB
- Memcached
前半で松本さんに説明頂いた中から選定基準として重要なポイントがいくつか挙げられます。
- 十分に高い耐久性や整合性が必要
- サーバーサイドのタイミングでデータを削除したい
- 十分に高いパフォーマンスが必要
また、この導入に伴って私達SREはもちろん開発者の手間が増えては困るので、以下のポイントも重要です。
- 運用が楽
- ダウンタイムやメンテナンスなどが少ない
- 開発が楽
- 新たなライブラリの導入が不要
- 開発環境への追加整備が不要
- 必要以上に高機能では無い
こうした観点で、それぞれの私達にとってのメリット・デメリットを表にまとめてみました。
| Redis | MongoDB Atlas | DynamoDB | Memcached | |
|---|---|---|---|---|
| 耐久性、可用性 | 低〜中 | 高 | 高 | 低 |
| パフォーマンス | 高 | 高 | 低(HTTP通信によるオーバーヘッド) | 高 |
| 運用の手間 | 低(但し高可用性を担保するには中) | 中(メンテナンスが多い) | 低 | 低 |
| ライブラリの追加 | なし | なし | 必要 | 必要 |
| 開発環境への追加整備 | なし | なし | 必要 | 必要 |
| 機能が必要十分か | ○ | too much | too much | ○ |
こうしてみるとRedisかMongoDBが有力候補です。 MongoDBは高機能過ぎ、且つコスパが悪いので、今回はRedisを選択することになりました。
Redisのインフラ構成
私達が検討を始めた段階ではまだMemoryDBは発表されていなかったので、ElastiCache for Redisの利用を考えていました。
ですが考えないといけないことは多く、どこまで冗長で堅牢な構成にしても永続化というレベルまではいきません。
仕方ないかと思っていたところにMemoryDBのニュースが入ってきました。
データの永続化に使える新しいマネージドサービスということだったのでMemoryDBを採用することに決まりました。
MemoryDBの導入
MemoryDBの懸念点
MemoryDBを採用することになったのですが、調査段階でいくつかの懸念点が出てきました。
特にパフォーマンスについては不安だったので、元々の移行プランの中で可能な検証をしてみることにしました。
パフォーマンス検証結果
先ずはMemoryDBへの書き込みだけを入れてみました。 結論としてはパフォーマンスに大きな影響は見られませんでした。
次に読み書き両方を入れてみましたが、こちらも問題有りませんでした。
※ちなみにこのグラフはDatadogで作成しました。ECサービスではDatadogのAPMを利用してパフォーマンスの可視化をしています。とても便利です。
失敗したこと
冒頭のMemoryDBについてのスライドでサラッと書きましたが、ElastiCache for RedisとMemoryDBではデフォルトの設定値がいくつか違っています。 気をつけましょう。
思わぬバグに遭遇しました。 AWSサポートの方には本当に感謝です。
まとめ
失敗は有りつつもセッションストアのMemoryDB移行に成功しました。 AWSのフルマネージドならではの監視、運用の楽さも享受できています。 サービス毎に要求されるパフォーマンスやデータの耐久性などのスペックは変わりますが、用途に合えばMemoryDBは有力な選択肢になると思います。
