SREの視点で挑む Redis Stream 無停止移行

GO TechTalk #32 タクシーアプリ『GO』の最強SREチーム で発表した資料です。

■ YouTube
https://www.youtube.com/watch?v=JKqmWhSqusg
■ connpass
https://jtx.connpass.com/event/379672/

Transcript

1. © GO Inc. SREの視点で挑む Redis Stream 無停止移行 可用性を損なわないための「二重系」設計 1
2. © GO Inc. GO株式会社 技術戦略部 SRE / 前田 恭男 タクシーアプリ『MOV』および『GO』の開発に 従事。 iOSアプリからバックエンドへと専門性を広 げ、現在はSREとして『GO』のシステム信頼 性向上や基盤整備を担当。 自己紹介 2
3. © GO Inc. あるサービスでGKE上に構築されたRedisが利用されており 運用観点からマネージドなRedisに移行する事になった 該当サービスはリアルタイムなイベント配信基盤として Redisを利用しており以下の機能を持つ • 配信されたイベントは即時に配信できること • 複数人が同じイベントを受信できること • 受信者ごとに既読管理ができること 上記の機能をRedis Streamを使って実現しており 通常のKVSとは異なるRedisの移行方法を考える必要がある きっかけ 3
4. © GO Inc. Redisのデータ構造の1つ 書き込み側(Producer)と読み取り(Consumer)が独立して管理されており、読み取り側では未読 /既読と いった状態管理が行われる Redis Pub/Subも近い機能を持つが、最も大きな違いはデータの永続性にあります。 • Redis Pub/Sub: Publishした瞬間にSubscribeしている接続先のみが取得できる • Redis Stream: Stream側で永続化されており、Consumer Group経由で後から取得することが可 能 Redis Streamとは 4
5. © GO Inc. 以下の要素を持つ • Entry ◦ 登録したメッセージ、発行毎にID(デフォルトは時刻ベース)を持つ • Stream ◦ Producer側のEntry格納先、追記型のデータ構造 • Consumer Group ◦ Consumer側がStreamからどこまでEntryを読み込んだのか何を既読にしたかを管理 ◦ 特徴として複数のConsumerが並列、かつ非同期にStreamからデータを取得可能 • PEL(Pending Entries List) ◦ Consumer Group内で読み出されたが既読になっていない Entryのリスト • ACK ◦ EntryのIDを指定してConsumer Group内のPELから除外し、既読扱いにする Redis Streamとは 5
6. © GO Inc. Redis Streamとは 6
7. © GO Inc. Redis Streamとは 7
8. © GO Inc. Redis Streamとは 8
9. © GO Inc. Redis Streamの移行が難しいところ 9
10. © GO Inc. 移行要件 前提として移行要件は以下の3つ • 無欠損：メッセージは欠損/重複配信してはいけない。(MUST) • 可逆性：いつでも旧Redisへ切り戻せる状態を維持しなくてはいけない。 (MUST) • 無停止：ダウンタイムを作らないで移行できること (WANT) 10
11. © GO Inc. 一般的な以下の3つの手法が使えない • アプリケーション側でダブルライト • SLAVEOFコマンドでデータを移行先Redisインスタンスにレプリケーションさせる • サービス自体をメンテナンスモードにして旧 Redisデータを新Redisにコピーする Redis Streamの移行が難しいところ 11
12. © GO Inc. 一般的な以下の3つの手法が使えない • アプリケーション側でダブルライト • SLAVEOFコマンドでデータを移行先Redisインスタンスにレプリケーションさせる • サービス自体をメンテナンスモードにして旧 Redisデータを新Redisにコピーする Redis Streamの移行が難しいところ Entry IDは {ミリ秒}-{index}で自動採番 登録タイミングによっては、新旧 Redisで同一 IDではなくなる → ACKする際に、ダブルライトしたデータを 特定できなくなるため手法としては難しい 12
13. © GO Inc. 一般的な以下の3つの手法が使えない • アプリケーション側でダブルライト • SLAVEOFコマンドでデータを移行先Redisインスタンスにレプリケーションさせる • サービス自体をメンテナンスモードにして旧 Redisデータを新Redisにコピーする Redis Streamの移行が難しいところ マネージド側の制約でSLAVEOF 系が利用 できないため、そもそもこの手法ではできない 13
14. © GO Inc. 一般的な以下の3つの手法が使えない • アプリケーション側でダブルライト • SLAVEOFコマンドでデータを移行先Redisインスタンスにレプリケーションさせる • サービス自体をメンテナンスモードにして旧 Redisデータを新Redisにコピーする Redis Streamの移行が難しいところ 切り戻し手順が複雑になる 「新→旧へ戻す」際にそのまま旧Redisに向 き先を変えると新Redisで配信されたEntryが 欠損してしまうため、手法としては難しい 14
15. © GO Inc. 移行オペレーション 15
16. © GO Inc. 方針： 常に新旧のどちらか一方のRedisのみに書き込む。 理由： 書き込み先を一つに絞ることで、同一データの管理が不要になり構造上シンプルになる 方針：書き込み(Producer) 16
17. © GO Inc. 方針１：移行完了までは新旧両方のRedisから同時に読み取り、移行が完了すると新Redisのみの読み 取りに切り替える 理由１： 切り替え前にStreamに登録された旧Redisのデータ自体も配信可能にするため 方針２：ACKも同様に移行完了までは新旧両方の Redisに対して実施する 理由２：ACKに対してはIDのみだと新旧どちらに対して実施すべきか区別がつかないためどちらにも実 施する 方針：読み取り/ACK (Consumer) 17
18. © GO Inc. ACKについて存在しないIDに対して実施しても問題ないのか？ ACKを行うRedisのXACKコマンドのドキュメントを見ると複数の IDが指定でき、レスポンスはACKが成 功した件数(integer)となっている。そのため存在しない IDでもエラーにはならない 方針：ACKについて 18
19. © GO Inc. 移行オペレーション：移行前 書き込みは旧Redisのみ 読み取りは新旧Redisどちら からも行っておく 19
20. © GO Inc. 移行オペレーション：移行開始 書き込みを新Redisに変更す る 読み取りは特に変更無し 移行中はConsumerから非 同期での読み取りが発生す るため一定期間この状態を 維持しておく 20
21. © GO Inc. 移行オペレーション：ACK 移行中は新旧どちらにも ACKを実施 21
22. © GO Inc. 移行オペレーション：移行完了 読み取りを新Redisのみに変 更する これにより旧Redisを使うこと がなくなるため移行完了とな る 22
23. © GO Inc. 移行オペレーション：切り戻し時 移行中に問題が発生して切 り戻しが必要になった場合は 書き込み側を旧Redisに戻す 読み取り側は新旧どちらから も読み取ってるために特に変 わらず欠損も発生しない 23
24. © GO Inc. 移行オペレーション 新たにRedisを用意して、段階的に書き込み先、読み取り先、 ACK先を変えることで実施 移行完了までは書き込み先は1つのみ読み込み先/ACKは新旧どちらに対しても実施 状態 書き込み先 読み取り先 ACK先 移行前 旧 新旧 新旧 移行開始 新 新旧 新旧 移行完了 新 新 新 切り戻し 旧 新旧 新旧 書き込み先は1つのみ 新旧2重に読み取り 新旧2重にACK 24
25. © GO Inc. 今回の割り切り（設計判断） 要件として落としたこと • 順序保証 ◦ 本来は重要だが、イベント数がそこまで多くないので不要と判断 • 旧RedisにConsumerによってACKされないまま残り続けるイベントをどうするか ◦ 今回のイベント配信は一定時間受信されなかったものは不要になるため、移行期間を一定時 間設けて旧Redisに残り続けるイベントを無視して移行を進めることにした • 移行中に全Consumer GroupのPEL件数を監視する ◦ 一括で取得できるコマンドがなく Consumer Group毎にRedisコマンド叩いて確認する必要が あり、今回はConsumerの数が多くRedis負荷が高くなる危険性があるため実施せず 25
26. © GO Inc. インフラだけでこれを実現するのは結構面倒 以下の2点を工夫した • アプリケーションコード側で書き込み /読み込み先を変えるよう修正 • 監視強化 どうやって実現する? 26
27. © GO Inc. ビジネスロジック側でRedis構造体に直接 参照されており、抽象化されていなかった このままだと移行ロジックを直接 Redis構 造体に書く羽目に。。。 アプリケーションコード側で修正 // ビジネスロジック type EventLogic struct { redis *Redis // Redis構造体を直接参照 } func NewEventLogic(redis *Redis) *EventLogic { return &EventLogic{ redis: redis, } } type (el *EventLogic) Add(ctx context.Context, key string, value string) error { return el.redis.XAdd(ctx, key, value) } type (el *EventLogic) Read(ctx context.Context, key string, id string) (string, error) { return el.redis.ReadMessage(ctx, key, id) } type (el *EventLogic) Acknowledge(ctx context.Context, key string) error { return el.redis.Ack(ctx, key) } 27 既存のコード
28. © GO Inc. 辛いので interfaceにして処理の抽象化 logic側でもinterfaceを利用することで、 移行ロジックを既存ロジックに混ぜる必 要がなくなり、移行ロジックにフォーカス した構造体を作れるようになった アプリケーションコード側で修正 // RedisStreamでイベントを管理するためのインターフェース type EventStreamer interface { XAdd(ctx context.Context, key string, value string) error ReadMessage(ctx context.Context, key string, id string) (string, error) Ack(ctx context.Context, key string) error } // ビジネスロジック type EventLogic struct { streamer *EventStreamer // interfaceにして処理の抽象化 } func NewEventLogic(streamer *EventStreamer) *EventLogic { return &EventLogic{ streamer: streamer, } } 28 移行のために変えたコード
29. © GO Inc. 監視強化 全Consumer Groupの監視はインフラ負荷観点で効率が悪いため 代替としてアプリケーション側で受信イベントベースのメトリクスを送るようにして効率的に新旧の処理推 移を可視化 以下は、当日の移行開始して、新 RedisのEntry受信が開始されるのを監視していたスクショ 29
30. © GO Inc. 特に大きな障害もなく、切り替えは問題なく移行できた 結果的にダウンタイムなく完了し、欠損もなかったためすべての要件を満たした移行ができた やってみて 30
31. © GO Inc. まとめ 31
32. © GO Inc. まとめ Redis Streamは通常のKVSとは異なり非同期な読み取りや未読既読があるため一般的な移行方法だ と難しい そのため、読み取り側は新旧Redisを2重に扱う設計にすることで問題なく移行できた また、移行に関してインフラだけで難しい場合はアプリケーション側も変更するという多角的なアプローチ をとることで可用性を維持した移行ができた 32
33. © GO Inc. ただし、 すべてこの手法でRedis Stream移行ができるとは限らない 今回はイベント配信というリアルタイム性が重要なものだったため いくつかの要件を落としていたが、実際に要件上落とせるかは議論して実施するのがよい まとめ 33
34. 文章・画像等の内容の無断転載及び複製等の行為はご遠慮ください。 © GO Inc. 34