Upgrade to Pro — share decks privately, control downloads, hide ads and more …

STORES におけるセッションストアへの Amazon MemoryDB for Redis...

STORES におけるセッションストアへの Amazon MemoryDB for Redis の活用と、移行戦略 / MemoryDB for STORES Session Store

AWS主催「インメモリデータベースで実現する超高速データベース活用セミナー」での登壇
https://pages.awscloud.com/JAPAN-event-OE-jp-Cat22-Database-20220629-reg-event.html

このスライドは同僚の角田さんとの合作です。

Takuya Matsumoto

June 29, 2022
Tweet

More Decks by Takuya Matsumoto

Other Decks in Technology

Transcript

  1. 会社概要 3 会社名 ヘイ株式会社 設立 2012年3月23日 代表取締役社長 佐藤裕介 資本金 1億円

    所在地 〒150-0011 東京都渋谷区東3丁目16番3号 エフ・ ニッセイ恵比寿ビル4階 事業内容 インターネットビジネスの企画・開発・ 運営
  2. 本発表における「セッションストア」 9 • システムにアクセスしているユーザーに紐づく、ステートフルな情報を保存す るところ ◦ 例 ▪ ユーザーの識別子 ▪

    認証した事実を示すトークン ▪ CSRF保護用トークン ▪ 次のリクエスト時に表示する一時的なメッセージ • 今までの STORES では、セッションストアとしてCookieを採用していた
  3. セッションストアとしてのCookie 10 Pros. • クライアントに保存するので ストレージが不要 • 負荷やスケーリングを考えなくて 良い •

    ストレージアクセスのI/Oがなく 高速 Cons. • 転送量が大きくなる • 扱い方がクライアントの実装に依存 • セキュリティ上の懸念がある
  4. 動機2: 特定のセッションを失効させることが難しい 14 • 課題1: Cookieそのものの有効期限は書き換え可能 ◦ 暗号化されたCookie内に独自の日時情報を含むことで対応 • 課題2:

    いざというときに即座に失効させられない ◦ 課題1の日時情報やログインユーザーに紐づく情報でフィルタして対応 • 課題3: ログアウトしてもセッションは失効しない ◦ Cookieの原理上しかたない。必要に応じて課題2と同様に対応 特に課題2,3では、場当たり的な対応になっており運用コストが増大していた Q. フィルタ機能をシステム化すればよいのでは? • 失効させたいセッションを特定する情報を別のストレージで持つ必要性 • nonceと同じく、Cookieの利点が損なわれる
  5. MemoryDB for Redis に格納するセッションのキーペアは (“セッションキー“, “セッションデータ“) 任意のセッションを特定するのは、これだけでは難しい • 多くの場合は値で検索したいが、Redisではできない •

    セッションキーはCookieに格納されていて、逆算もできない ユーザーIDなどから、セッションキーを特定したい! 補足: 任意のセッションを失効させるための仕組み 16
  6. Step 1: ダッシュボードのセッションをダブルライト、読み込みはCookieから 30 アプリケーション 当代 Cookie 次代 MemoryDB Write

    Read ダッシュボード ショップサイト ダブルライトのロジックの正しさや、 MemoryDBの様子を確認
  7. Step 2: すべてのセッションをダブルライト、読み込みはCookieから 31 アプリケーション 当代 Cookie 次代 MemoryDB Write

    Read Write ダッシュボード ショップサイト • 負荷は想定範囲内か、次のステップでのReadに耐えうるか • セッションの蓄積やスパイクアクセス時の観察のため、しば らく様子見
  8. Step 3: すべてのセッションをダブルライト、読み込みはMemoryDBから 32 アプリケーション 当代 Cookie 次代 MemoryDB Write

    Read Write ダッシュボード ショップサイト 負荷は想定範囲内か、セッションは引き継が れるかを確認
  9. ElastiCache for Redisとどう違う? • データの高耐久性 ◦ 永続化目的で使える • パフォーマンス ◦

    書き込みが遅いという噂 • セキュリティー ◦ TLS必須 • デフォルトクラスター構成 • デフォルトパラメーター
  10. DynamoDB • 一部のログを保存するなどで利用はしている • アプリケーションからは利用していないので追加実装が多い ◦ Gemを増やす ◦ 使い方を学ぶ •

    セッションストアなのでHTTPのオーバーヘッドが気になる • Redisに比べるとtoo muchか • ローカル環境の整備をしないと ◦ DynamoDB Local など
  11. ElastiCache for Redisで高可用性を実現するには? • クラスターモードでの運用 • 自動フェイルオーバーの有効化 • Multi AZ

    • シャーディング • プライマリーで障害が起きるとフラッシュ 結構意識することは多い...
  12. MemoryDBなら全部あるよ! • デフォルトクラスターモード • 自動フェイルオーバー • Multi AZ • シャーディング

    プライマリーの障害でもデータロストしない! 新しいサービスが使えて楽しい!
  13. 調査1 あつめた噂 • 書き込みが遅いらしい ◦ https://aws.amazon.com/jp/blogs/news/introducing-amazon-memorydb-for-redis-a -redis-compatible-durable-in-memory-database-service-jp/ > MemoryDB は、データの耐久性とマイクロ秒の読み取り、および一桁ミリ秒の書き込みレイ

    テンシーを提供 > ElastiCache は読み取りと書き込みの両方にマイクロ秒のレイテンシーを提供 ◦ https://dev.classmethod.jp/articles/aws-release-durable-redis-amazon-memorydb- for-redis/ 書き込みが遅いらしい
  14. 調査2 AWSの方からも... • > 書き込みレイテンシーについては、 一桁ミリ秒 となります。これは、高い 可用性を担保するために、Multi-AZへの書き込みを反映させることによるも ので、仕組み上の制約となります。 >

    一桁ミリ秒では要件が満たされない、かつElastiCache (Redis)の可用性が 許容できるならば、ElastiCache (Redis)を使っていくことが推奨されます。 > よくある可用性とレイテンシーのトレードオフですね ◦ 噂通り だけどこの性能差は本当に問題になるのか? 試してみよう!
  15. Evictionされない! part 1 • ある日Redisのメモリー逼迫アラートが!!! • 急いでクラスターをスケールアウト! • 相当余裕をもってサイジングしたんだけど... •

    どうしてEvictionされないんだろう? • maxmemory-policy: noeviction がデフォルト! ◦ ElastiCacheだとvolatile-lruだった