$30 off During Our Annual Pro Sale. View Details »

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

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. ヘイ株式会社
    2022/06/29
    STORES におけるセッションストアへの
    Amazon MemoryDB for Redis の活用と、
    移行戦略

    View Slide

  2. 自己紹介
    2
    テクノロジー部門
    リテール本部
    SREグループ
    角田 朋之
    テクノロジー部門
    プロダクト基盤本部
    基盤グループ
    松本 拓也

    View Slide

  3. 会社概要
    3
    会社名 ヘイ株式会社
    設立 2012年3月23日
    代表取締役社長 佐藤裕介
    資本金 1億円
    所在地
    〒150-0011
    東京都渋谷区東3丁目16番3号 エフ・
    ニッセイ恵比寿ビル4階
    事業内容
    インターネットビジネスの企画・開発・
    運営

    View Slide

  4. サービス紹介
    4
    お店のデジタル化をまるっとサポートする
    「STORES プラットフォーム」を展開

    View Slide

  5. サービス紹介
    5
    本日お話するシステム
    お店のデジタル化をまるっとサポートする
    「STORES プラットフォーム」を展開

    View Slide

  6. サービス紹介
    6
    自分でつくれる、
    本格的なネットショップ
    むずかしい知識や技術いらずで
    自分だけのネットショップをかんたんに。

    View Slide

  7. お話すること
    7
    ● セッションストアを移行することになった経緯
    ● セッションストアを移行するための戦略
    ● MemoryDB for Redis を選択した理由
    ● MemoryDB for Redis の導入過程と失敗談

    View Slide

  8. セッションストアを移行することになった経緯

    View Slide

  9. 本発表における「セッションストア」
    9
    ● システムにアクセスしているユーザーに紐づく、ステートフルな情報を保存す
    るところ
    ○ 例
    ■ ユーザーの識別子
    ■ 認証した事実を示すトークン
    ■ CSRF保護用トークン
    ■ 次のリクエスト時に表示する一時的なメッセージ
    ● 今までの STORES では、セッションストアとしてCookieを採用していた

    View Slide

  10. セッションストアとしてのCookie
    10
    Pros.
    ● クライアントに保存するので
    ストレージが不要
    ● 負荷やスケーリングを考えなくて
    良い
    ● ストレージアクセスのI/Oがなく
    高速
    Cons.
    ● 転送量が大きくなる
    ● 扱い方がクライアントの実装に依存
    ● セキュリティ上の懸念がある

    View Slide

  11. セッションストアとしてのCookie
    今までの STORES では
    ● Cookieの内容を暗号化して一定の安全性を確保
    ● 高速で、スケールするセッションストアとして活用
    しかし、サービスの成長につれて、徐々にマッチしない部分が出てきた
    11

    View Slide

  12. セッションストアをCookieから移行する3つの動機
    12
    1. セキュリティの強化策が限られる
    2. 特定のセッションを失効させることが難しい
    3. 将来の複数サービス間でのセッション制御に拡張性を持たせたい

    View Slide

  13. 動機1: セキュリティの強化策が限られる
    13
    ● 暗号化はするものの、情報がクライアント側にあることには変わらない
    ● リプレイ攻撃などの考慮を徹底する必要がある
    例えばnonceの導入といった工夫も考えられるが…
    ● 別のストレージで保存が必要になる
    ● Cookieの利点である高速さや負荷耐性が損なわれる

    View Slide

  14. 動機2: 特定のセッションを失効させることが難しい
    14
    ● 課題1: Cookieそのものの有効期限は書き換え可能
    ○ 暗号化されたCookie内に独自の日時情報を含むことで対応
    ● 課題2: いざというときに即座に失効させられない
    ○ 課題1の日時情報やログインユーザーに紐づく情報でフィルタして対応
    ● 課題3: ログアウトしてもセッションは失効しない
    ○ Cookieの原理上しかたない。必要に応じて課題2と同様に対応
    特に課題2,3では、場当たり的な対応になっており運用コストが増大していた
    Q. フィルタ機能をシステム化すればよいのでは?
    ● 失効させたいセッションを特定する情報を別のストレージで持つ必要性
    ● nonceと同じく、Cookieの利点が損なわれる

    View Slide

  15. 動機3: 将来の複数サービス間でのセッション制御に拡張性を持たせたい
    ● システムAとシステムBがあり、IdPとID連携していたとする
    ● 例えば、AでログアウトしたときBでもログアウトさせたいとき、任意のセッ
    ションを失効させられる必要がある (※)
    まだどのような仕様に落ち着くかは不透明だが、何らかの制御を行える状態にして
    おきたい
    15
    システムB
    (STORES)
    システムA IdP
    ログアウト
    したよ
    ログアウト
    してね
    ログアウト
    するぞ
    だが断る
    ※いわゆるシングルサインアウト。OpenID Connect Back-Channel Logout をイメージ

    View Slide

  16. MemoryDB for Redis に格納するセッションのキーペアは
    (“セッションキー“, “セッションデータ“)
    任意のセッションを特定するのは、これだけでは難しい
    ● 多くの場合は値で検索したいが、Redisではできない
    ● セッションキーはCookieに格納されていて、逆算もできない
    ユーザーIDなどから、セッションキーを特定したい!
    補足: 任意のセッションを失効させるための仕組み
    16

    View Slide

  17. マッピングのイメージ:
    (“ユーザーID:セッションID”, “セッションキー”)
    保存先は?
    ● セッションと同じ耐久性は要求されないかも
    ● MemoryDBにするかどうかは検討の余地がある
    セッションとユーザーのマッピングを作成する
    17
    セッションストア
    引き当て
    (“セッションキー“, “セッションデータ“)

    View Slide

  18. 移行するぞ!
    18
    ● がんばろう
    ● では、どうやって?
    移行プロジェクトメンバー

    View Slide

  19. 大きく、2つの課題
    19
    ● どうやって移行するか、移行戦略
    ○ クライアント側に保存されている既存のセッションはどうするか
    ● どのストレージに移行するか
    ○ MemoryDB for Redis を選ぶに至ったのはなぜか

    View Slide

  20. セッションストアの移行戦略

    View Slide

  21. 既存のセッションはどうする?
    21
    ● 既存のセッションを捨てて、新しいセッションからMemoryDBを使う?
    ○ メンテナンスを設けて、その間に切り替える
    ○ ユーザーは一斉にログアウト🥺
    ● ユーザー体験を考えれば、できればセッションを保ったまま移行したい
    ○ どうやって実現する?🤔

    View Slide

  22. ダブルライト (Step 1)
    22
    アプリケーション
    当代
    Cookie
    次代
    MemoryDB
    Write Read Write

    View Slide

  23. ダブルライト (Step 2)
    23
    アプリケーション
    当代
    Cookie
    次代
    MemoryDB
    Write Read
    Write

    View Slide

  24. ダブルライト (Step 3)
    24
    アプリケーション
    次代
    MemoryDB
    Read
    Write

    View Slide

  25. より安全に移行するには
    25
    移行作業の要求
    ● 問題発生時の影響を小さくしたい
    ● 何かあったときに安全に切り戻したい
    ● 負荷を実績から見積もりながら計画したい
    なるべく段階的に切り替える方法にしよう

    View Slide

  26. STORESのセッションは2系統ある
    26
    ダッシュボード
    ネットショップを運営するオーナーのセッション
    ショップサイト
    ネットショップを利用する顧客のセッション

    View Slide

  27. STORESのセッションは2系統ある
    27
    アクセス数は?
    まずはダッシュボードだけ切り替えてうまく働くことを確認し、サイト全体へと広
    げていく作戦
    ダッシュボード
    ショップサイト
    >>>

    View Slide

  28. Step 0: すべてのセッションはCookieで読み書き
    28
    アプリケーション
    当代
    Cookie
    Write Read
    ダッシュボード
    ショップサイト

    View Slide

  29. Step 1: ダッシュボードのセッションをダブルライト、読み込みはCookieから
    29
    アプリケーション
    当代
    Cookie
    次代
    MemoryDB
    Write Read Write
    ダッシュボード
    ショップサイト

    View Slide

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

    View Slide

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

    View Slide

  32. Step 3: すべてのセッションをダブルライト、読み込みはMemoryDBから
    32
    アプリケーション
    当代
    Cookie
    次代
    MemoryDB
    Write Read
    Write
    ダッシュボード
    ショップサイト 負荷は想定範囲内か、セッションは引き継が
    れるかを確認

    View Slide

  33. Step 4: すべてのセッションはMemoryDBで読み書き
    33
    アプリケーション
    次代
    MemoryDB
    Read
    Write
    ダッシュボード
    ショップサイト 移行完了!

    View Slide

  34. STORES サービスの構成

    View Slide

  35. インフラ構成
    35

    View Slide

  36. MemoryDB for Redis を選択した理由

    View Slide

  37. MemoryDBとは?
    ● Redis互換なインメモリーデータベース
    ○ Redis 6.2+
    ● スケーラブル
    ● フルマネージド
    ● セキュリティー
    ○ VPC
    ○ KMS
    ○ Redis ACL

    View Slide

  38. ElastiCache for Redisとどう違う?
    ● データの高耐久性
    ○ 永続化目的で使える
    ● パフォーマンス
    ○ 書き込みが遅いという噂
    ● セキュリティー
    ○ TLS必須
    ● デフォルトクラスター構成
    ● デフォルトパラメーター

    View Slide

  39. セッションストアの候補

    View Slide

  40. Redis
    ● 既にアプリケーションの他の箇所で使い慣れている
    ● 高速
    ● 機能が必要十分
    ● ダブルライトやクラスターを組むなどしないと可用性が不安
    ○ 逆に言うとクラスターモードやダブルライトで高可用性を実現できる

    View Slide

  41. MongoDB
    ● STORES のメインのDBなのでもちろん使い慣れている
    ● パフォーマンスへの影響が気になる
    ● Redisに比べるとtoo muchか
    ● (定期的にパッチ等のメンテナンスが入る)

    View Slide

  42. DynamoDB
    ● 一部のログを保存するなどで利用はしている
    ● アプリケーションからは利用していないので追加実装が多い
    ○ Gemを増やす
    ○ 使い方を学ぶ
    ● セッションストアなのでHTTPのオーバーヘッドが気になる
    ● Redisに比べるとtoo muchか
    ● ローカル環境の整備をしないと
    ○ DynamoDB Local など

    View Slide

  43. Memcached
    ● 運用が楽
    ● マルチコア使えるので、パフォーマンス良い
    ● 再起動とかも速い
    ● 一切利用していないので追加実装が多い
    ○ Gemを増やす
    ○ 使い方を学ぶ
    ● 耐久性

    View Slide

  44. Redisが良さそう!

    View Slide

  45. Redisのインフラ構成

    View Slide

  46. ElastiCache for Redisで高可用性を実現するには?
    ● クラスターモードでの運用
    ● 自動フェイルオーバーの有効化
    ● Multi AZ
    ● シャーディング
    ● プライマリーで障害が起きるとフラッシュ
    結構意識することは多い...

    View Slide

  47. MemoryDBなら全部あるよ!
    ● デフォルトクラスターモード
    ● 自動フェイルオーバー
    ● Multi AZ
    ● シャーディング
    プライマリーの障害でもデータロストしない!
    新しいサービスが使えて楽しい!

    View Slide

  48. MemoryDB良さそう!

    View Slide

  49. 懸念点
    ● パフォーマンスは?
    ○ 書き込みが遅いという噂
    ● ElastiCacheより料金がお高め
    ○ クラスターモードのみなので細かなサイズ調整が難しい場合も
    ○ 大きめのインスタンスしか選べなかった
    ■ 今はt4gも!
    ○ 今回は許容範囲ということで富豪的解決!

    View Slide

  50. MemoryDB for Redis の導入過程と失敗談

    View Slide

  51. 調査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/
    書き込みが遅いらしい

    View Slide

  52. 調査2 AWSの方からも...
    ● > 書き込みレイテンシーについては、 一桁ミリ秒 となります。これは、高い
    可用性を担保するために、Multi-AZへの書き込みを反映させることによるも
    ので、仕組み上の制約となります。
    > 一桁ミリ秒では要件が満たされない、かつElastiCache (Redis)の可用性が
    許容できるならば、ElastiCache (Redis)を使っていくことが推奨されます。
    > よくある可用性とレイテンシーのトレードオフですね
    ○ 噂通り
    だけどこの性能差は本当に問題になるのか?
    試してみよう!

    View Slide

  53. 検証
    ● 先ずは書き込みだけ有効にしてリリースしてみる
    ○ 元々Cookieとの両書き期間を設ける予定だったし!
    ○ 幸いCloudWatch MetricsやDatadogのAPMなど可視化は万全!
    アプリケーション
    当代
    Cookie
    次代
    MemoryDB
    Write Read Write

    View Slide

  54. 検証結果1 書き込みのみ
    ● 5%程度処理時間
    を使っているもの
    の、平均レイテン
    シーに大きな変化
    は無し!
    ● スペック上書き込
    みが遅くてもセッ
    ションストア用途
    なら問題無さそ
    う!
    リリース
    5%増量

    View Slide

  55. 検証結果2 読み書き両方
    ● 読み書き両方を
    有効にしてもほ
    ぼ影響無し!
    リリース
    変化なし!

    View Slide

  56. 移行成功!...?

    View Slide

  57. Evictionされない! part 1
    ● ある日Redisのメモリー逼迫アラートが!!!
    ● 急いでクラスターをスケールアウト!
    ● 相当余裕をもってサイジングしたんだけど...
    ● どうしてEvictionされないんだろう?
    ● maxmemory-policy: noeviction がデフォルト!
    ○ ElastiCacheだとvolatile-lruだった

    View Slide

  58. Evictionされない! part 2
    ● ある日Redisのメモリー逼迫アラートが!!!
    ● どうしてEvictionされないんだろう?
    ● 分からないのでAWSサポートの方に泣きつくと...
    ● TTL付いてないキーが一杯ありますよ!
    ○ 我々のアプリケーションの問題だったことが判明m(__)m

    View Slide

  59. STORESのセッションはMemoryDBで元気に稼働中!

    View Slide

  60. まとめ
    ● 高耐久で高速なインメモリーデータベースはMemoryDBはあり!
    ○ お手軽に高耐久なRedisクラスターが使えます!
    ○ 書き込みパフォーマンスについては用途次第で問題にはならない!
    ● AWSサポートの方々の優しさで毎日救われています!

    View Slide