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

Transcript

1. 1.

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

2. 2.

   2 突然ですが、みなさん

3. 3.

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

4. 4.

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

5. 5.

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

6. 6.

   6 何が危険なのか？

7. 7.

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

8. 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.

   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.

    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.

    11 やばい

12. 12.

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

13. 13.

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

14. 14.

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

15. 15.

    15 安心

16. 16.

    16 さっそく置き換えだ！

17. 17.

    17 ちょっと待って！

18. 18.

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

19. 19.

    19 まず確認しよう!

20. 20.

    20 まず確認しよう!

21. 21.

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

22. 22.

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

23. 23.

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

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

    24 それでも必要なら・・・

25. 25.

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

26. 26.

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

27. 27.

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

28. 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.

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

30. 30.

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

31. 31.

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

32. 32.

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

33. 33.

    33 Feature Togglesで安心のリリース

34. 34.

    34 実際のフロー

35. 35.

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

36. 36.

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

37. 37.

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

    Feature Togglesで1%リリース
38. 38.

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

    Feature Togglesで1%リリース 4. 100%!!!(任意の時間を置く)
39. 39.

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

    Feature Togglesで1%リリース 4. 100%!!!(任意の時間を置く) 5. 古いキャッシュ生成をやめる変更をデプロイ
40. 40.

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

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

    41 実際の様子(1キャッシュを置き換えるときのIssue)

42. 42.

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

43. 43.

    43 安心

44. 44.

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

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

    Thank you for your attention!