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

キャッシュ安心戦略 with Feature Toggles

キャッシュ安心戦略 with Feature Toggles

D400e6d92f9a69b60d9cfdff1dc9a98e?s=128

Kazushige Tominaga

October 31, 2018
Tweet

More Decks by Kazushige Tominaga

Other Decks in Programming

Transcript

  1. キャッシュ安心戦略 with Feature Toggles Oct 31, 2018 @tooooooooomy ebisurb

  2. 2 突然ですが、みなさん

  3. 3 こんなキャッシュ見たことないですか?

  4. 4 こんなキャッシュ見たことないですか?

  5. 5 こんなキャッシュ見たことないですか?

  6. 6 何が危険なのか?

  7. 7 何が危険なのか? • オブジェクトがキャッシュされている

  8. 8 何が危険なのか? • オブジェクトがキャッシュされている ◦ 暗黙のSerialize/Deserializeが発生 ◦ Rails公式でもキャッシュにはrawデータ(a string or

    number)を用いることがmustとされている ▪ https://guides.rubyonrails.org/v4.2.8/caching_with_rails.html#activesupport-cache-memcachestore
  9. 9 何が危険なのか? • オブジェクトがキャッシュされている ◦ 暗黙のSerialize/Deserializeが発生 ◦ Rails公式でもキャッシュにはrawデータ(a string or

    number)を用いることがmustとされている ▪ https://guides.rubyonrails.org/v4.2.8/caching_with_rails.html#activesupport-cache-memcachestore • なぜ危険なのか?
  10. 10 何が危険なのか? • オブジェクトがキャッシュされている ◦ 暗黙のSerialize/Deserializeが発生 ◦ Rails公式でもキャッシュにはrawデータ(a string or

    number)を用いることがmustとされている ▪ https://guides.rubyonrails.org/v4.2.8/caching_with_rails.html#activesupport-cache-memcachestore • なぜ危険なのか? ◦ 異なるサービス間・同じサービスの過去の実装と現在の実装間で共有される ▪ データ(キャッシュ)自体が実装に強く依存している状態 ▪ Ruby(Rails)以外の実装のアプリケーションとは共有できない • もしくは明示的な実装が必要 ▪ 不具合があってロールバックすると整合性が取れないという状況が起こりうる • 例) キャッシュ対象のオブジェクトのクラス名が変わる
  11. 11 やばい

  12. 12 安心のために • 外部データの保存形式を、後方互換性を担保したものに変更する

  13. 13 安心のために • 外部データの保存形式を、後方互換性を担保したものに変更する ◦ 例) JSON

  14. 14 安心のために • 外部データの保存形式を、後方互換性を担保したものに変更する ◦ 例) JSON

  15. 15 安心

  16. 16 さっそく置き換えだ!

  17. 17 ちょっと待って!

  18. 18 そのキャッシュ、本当に必要?

  19. 19 まず確認しよう!

  20. 20 まず確認しよう!

  21. 21 まず確認しよう! • 何回呼ばれたか

  22. 22 まず確認しよう! • 何回呼ばれたか • うち何回キャッシュが新たに作られたか ◦ キャッシュ使用率

  23. 23 まず確認しよう! • 何回呼ばれたか • うち何回キャッシュが新たに作られたか ◦ キャッシュ使用率 • 複数のプロセスから呼ばれることが想定さ

    れる場合、Redisのincrが便利 ◦ そもそもRedisがバックエンドの場合はそれを利 用するとよさげ ◦ 整合性を持ってカウントアップ
  24. 24 それでも必要なら・・・

  25. 25 新キャッシュを導入しよう!

  26. 26 Q. いきなり新しいキャッシュに置き換えてうまく動くのか不安です

  27. 27 Q. いきなり新しいキャッシュに置き換えてうまく動くのか不安です A. Feature Toggles を使おう

  28. 28 Feature Toggles? • Feature Toggles (aka Feature Flags) •

    "Feature Toggling" is a set of patterns which can help a team to deliver new functionality to users rapidly but safely. • 「1%の確率でtrueを返す」のような設定を可能にするもの
  29. 29 Feature Toggles使用例(実装は省きます)

  30. 30 Feature Toggles使用例(実装は省きます)

  31. 31 Feature Toggles使用例(実装は省きます) • シンプルにif文にするだけ

  32. 32 Feature Toggles使用例(実装は省きます) • シンプルにif文にするだけ • 簡単安心 ◦ どんな場合にtrueを返すかは実装によります

  33. 33 Feature Togglesで安心のリリース

  34. 34 実際のフロー

  35. 35 実際のフロー 1. 追加で新キャッシュ作るだけの変更をデプロイ • 古いキャッシュは作り続ける

  36. 36 実際のフロー 1. 追加で新キャッシュ作るだけの変更をデプロイ • 古いキャッシュは作り続ける 2. 実際にキャッシュ作る箇所をFeature Toggles入りでデプロイ

  37. 37 実際のフロー 1. 追加で新キャッシュ作るだけの変更をデプロイ • 古いキャッシュは作り続ける 2. 実際にキャッシュ作る箇所をFeature Toggles入りでデプロイ 3.

    Feature Togglesで1%リリース
  38. 38 実際のフロー 1. 追加で新キャッシュ作るだけの変更をデプロイ • 古いキャッシュは作り続ける 2. 実際にキャッシュ作る箇所をFeature Toggles入りでデプロイ 3.

    Feature Togglesで1%リリース 4. 100%!!!(任意の時間を置く)
  39. 39 実際のフロー 1. 追加で新キャッシュ作るだけの変更をデプロイ • 古いキャッシュは作り続ける 2. 実際にキャッシュ作る箇所をFeature Toggles入りでデプロイ 3.

    Feature Togglesで1%リリース 4. 100%!!!(任意の時間を置く) 5. 古いキャッシュ生成をやめる変更をデプロイ
  40. 40 実際のフロー 1. 追加で新キャッシュ作るだけの変更をデプロイ • 古いキャッシュは作り続ける 2. 実際にキャッシュ作る箇所をFeature Toggles入りでデプロイ 3.

    Feature Togglesで1%リリース 4. 100%!!!(任意の時間を置く) 5. 古いキャッシュ生成をやめる変更をデプロイ レビュワーも流れに沿って変更を追えて安心 特に変更が多い場合には少しずつリリースすると安心
  41. 41 実際の様子(1キャッシュを置き換えるときのIssue)

  42. 42 実際の様子(1キャッシュを置き換えるときのIssue) • 最小限の変更を細かく重ねる • 安心な置き換え

  43. 43 安心

  44. 44 Who am I? twitter: @toooooooomy github: @kazu9su Software Engineer

    楽天株式会社ラクマ事業部 ラクマでは安心好きな仲間を募集中です
  45. Thank you for your attention!