인프런 커뮤니티 질문&답변
작성한 질문수 29
조회수를 RDB에만 저장하고 있는 서비스에서 Redis 도입 관련해서 질문입니다.
해결된 질문
작성
·
128
·
수정됨
0
안녕하세요. 쿠케님
강의 너무나 잘 보고 있습니다. 쿠케님 질의응답 게시글 정독하고 있는데 1:1 멘토링 부럽지 않을만큼의 고퀄리티 답변 언제나 감사드립니다. (갬동갬동)
현재 회사에서 조회수를 RDB에만 저장하고 있습니다.
이를 강의 내용처럼 'Redis 이전 & MySql 백업'을 적용 하고 싶은데 아래 흐름대로 적용 하면 될까요?
1⃣ (개발) redis 저장 및 조회, mysql 백업 코드 작성
2⃣ (개발) 기존 MySQL 데이터를 Redis에 저장하는 마이그레이션 코드 작성
=> 이렇게 일회성 마이그레이션 같은 경우 테스트 코드로 한번만 돌리는데 쿠케님은 어떤 방식으로 하시나요?
3⃣ (배포 전) 1번 코드 배포 직전에 2번 로직 실행
4⃣ (배포) 1번 코드 배포
위 방식에서 발생할 수 있는 문제점
1. 3번(마이그레이션)과 4번(배포) 사이에 조회수가 누락될 가능성
- 마이그레이션 실행 후 MySQL에는 새로운 조회수가 계속 업데이트되지만, Redis는 아직 트래픽을 받지 않음.
- 즉, 마이그레이션 실행 이후 MySQL에 새로 기록된 조회수는 Redis에 반영되지 않음 → 데이터 불일치 발생 가능.
2. 처음 Redis로 전환할 때, Redis에 캐싱되지 않은 일부 조회수가 MySQL에 계속 쿼리될 가능성이 있음.
- 처음 Redis로 전환할 때, Redis에 캐싱되지 않은 일부 조회수가 MySQL에 계속 쿼리될 가능성이 있음.
- 특정 조회수가 빠르게 증가하면 Hot Key 이슈 발생 가능.
조회수 누락을 최소화 하는 방법
1⃣ (개발) redis 저장 및 조회, mysql 백업 코드 작성
2⃣ (개발) 기존 MySQL 데이터를 Redis에 저장하는 마이그레이션 코드 작성 및 실행
3⃣ (1번 코드 배포 전) 더블 라이트(Double Write) 모드 개발하여 운영에 적용
4⃣ (배포) 기존 MySQL 기반 조회수 코드 제거, Redis 기반으로 전환
5⃣ (배포 후) MySQL 백업 로직 실행 및 기존 MySQL 조회 로직 완전히 제거
제가 혹여나 놓친게 있거나 더 좋은 방법이 있으면 천천히 답변 부탁드립니닷!
출처: 내 뇌 + GPT 센세
답변 2
1
soap님, 안녕하세요!
열정 있는 수강생 분들이 궁금한 점들 잘 정리해주셔서 저도 재밌게 답변하고 있습니다~! ㅎㅎㅎ
기존 코드 : MySQL 조회수 증가
개선 코드 : Redis 조회수 증가(MySQL 백업도 포함이지만, 단순하게 표현하기 위해 Redis 라고만 칭하겠습니다)
위처럼 전환하면서, 실시간 데이터 유실 없는 전략이 궁금하시군요!
먼저 제가 생각하는 시나리오부터 말씀드려보겠습니다!
기존에 MySQL 조회 수 증가 코드 유지하면서 Redis 조회수 증가 코드를 배포합니다. 이렇게 두 개의 다른 저장소에 쓰기 작업을 수행하는 것을 dual write(이중 쓰기)라고 부릅니다. 이 때에는 "Redis로 조회"는 아직 적용되지 않은 상태입니다. (엄밀히 따지면, 장애 시점에는 두 저장소 간에 트랜잭션 보장이 안되기 때문에, 특정 저장소에만 저장되는 상황이 생길 수 있으나, 조회수 일부 누락은 충분히 감당 가능할 수 있고, 해당 시점에 장애가 발생할 확률은 극히 낮기 때문에 간단한 전략을 취합니다.)
위 내용이 배포가 나갔으면, MySQL에 저장된 조회수를 Redis로 마이그레이션해줍니다. 실시간 조회수는 두 저장소 모두에 증가되고 있고, MySQL은 과거의 조회수도 포함하면서 실시간 데이터도 가지고 있으므로, Redis로 옮겨주면 유실 없이 처리됩니다(Redis는 실시간 데이터도 계속 증가하고 있는 상황). 배치 만들어서 돌려도 좋고, 그냥 테스트코드로 스크립트 짜서 돌려도 좋고, 어차피 일회성 코드라면 유지보수할 필요도 없어서 자유롭게 하시면 됩니다! 저도 이러한 일회성 코드는 각 상황에 따라 가장 편한 방법을 택하네요.
MySQL 데이터를 Redis로 마이그레이션이 끝났으면, Redis 조회를 배포하고, 기존 MySQL에 저장하던 코드는 정리하면 됩니다!
마이그레이션은 두 번 수행해서 데이터가 맞는지 잘 검증해야 할 수도 있습니다.
실시간 dual write + 마이그레이션 과정에서 예를 들어 보면,
실시간 MySQL을 먼저 증가시킬 경우 데이터 중복 : 실시간 MySQL 증가(조회수3) -> 마이그레이션 MySQL 조회(조회수3) 및 Redis 반영(조회수3) -> 실시간 Redis 증가(조회수4)
실시간 Redis를 먼저 증가 시킬 경우 데이터 유실 : 실시간 Redis 증가(조회수3) -> 마이그레이션 MySQL 조회(조회수2) 및 Redis 반영(조회수2) -> 실시간 MySQL 증가(조회수3)
극단적이지만 동시성 상황에서는 이러한 문제들도 나타날 것 같네요.
근데 이런 수준까지 신경써야 할지는 의문이긴 합니다.. ㅋㅋ
조회수에 대해서 딱히 문제 없는 수준이라면, 괜히 머리 아플 일 없이 이 정도는 그냥 감수하고, 간단하게 한번만 처리해도 충분할 것 같긴 하네요.
처음 제안 주신 방식에서는, 말씀하신대로 데이터가 유실될 수 있습니다.
핫키 문제는 웬만한 트래픽이 아니라면 크게 우려될 부분은 아닐 것 같네요!
마지막에 정리해주신 개선 방법도 제가 적어준 시나리오와 맥락은 비슷해보이는데, 크게 세 단계로 다시 정리해봤습니다!
그리고 이미 검토 충분히 하고 전환을 결정하신 것이겠지만, 다음 내용도 잘 검토해보시면 좋을 것 같습니다!
Redis로 전환이 반드시 필요할 만큼 시스템 부하가 부담되는 상황인지?
강의에서 제안한 MySQL 백업 전략 대신 다른 백업 전략이 필요하진 않을지? (Redis 백업 기능 이용 또는 다른 전략) (강의에서 제안한 전략이 간단하고 편할 것 같긴한데, 고민은 해보아도 좋을 것 같네요!)
혹시 더 궁금한 점 있으시면 편히 문의 주세요!
0
안녕하세요, 인프런 AI 인턴입니다. soap님.
조회수 데이터를 Redis로 이전하려는 계획을 공유해 주셔서 감사합니다. 질문하신 방식은 매우 체계적이고 합리적인 접근으로 보입니다. 하지만 몇 가지 체크 포인트를 고려하시면 도움이 될 것 같습니다.
제안된 마이그레이션 방식의 고려사항
Double Write 모드 도입
- Redis 도입 초기에는 Double Write를 사용하여 MySQL과 Redis에 동시에 조회수를 기록하도록 하여 데이터 불일치를 방지할 수 있습니다. 이렇게 하면 Redis로 완전히 전환되기 전 초기 데이터 손실을 피하는 데 도움이 됩니다.
- Redis 도입 초기에는 Double Write를 사용하여 MySQL과 Redis에 동시에 조회수를 기록하도록 하여 데이터 불일치를 방지할 수 있습니다. 이렇게 하면 Redis로 완전히 전환되기 전 초기 데이터 손실을 피하는 데 도움이 됩니다.
마이그레이션 타이밍
- 마이그레이션 작업과 그 이후의 배포는 시스템의 트래픽이 적은 시간대에 수행하는 것이 좋습니다. 가능한 한 서비스에 미치는 영향을 최소화할 수 있습니다.
- 마이그레이션 작업과 그 이후의 배포는 시스템의 트래픽이 적은 시간대에 수행하는 것이 좋습니다. 가능한 한 서비스에 미치는 영향을 최소화할 수 있습니다.
데이터 일관성 체크
- 마이그레이션 후, Redis와 MySQL의 조회수가 일치하는지 확인하는 검증 로직을 마련하는 것이 좋습니다. 이는 데이터 일관성을 보장하는 중요한 단계입니다.
- 마이그레이션 후, Redis와 MySQL의 조회수가 일치하는지 확인하는 검증 로직을 마련하는 것이 좋습니다. 이는 데이터 일관성을 보장하는 중요한 단계입니다.
캐싱 전략 조정
- Redis에 대한 캐싱 전략을 세밀하게 설계하여 Hot Key 이슈를 방지할 수 있도록 설정이 필요합니다. 예를 들어, LRU 정책을 통해 오래된 데이터를 자동으로 정리하도록 구성할 수 있습니다.
- Redis에 대한 캐싱 전략을 세밀하게 설계하여 Hot Key 이슈를 방지할 수 있도록 설정이 필요합니다. 예를 들어, LRU 정책을 통해 오래된 데이터를 자동으로 정리하도록 구성할 수 있습니다.
모니터링 및 롤백 계획
- Redis로 전환 후, 예상치 못한 문제가 발생할 경우를 대비하여 모니터링 시스템을 통해 실시간으로 성능 지표를 확인할 수 있도록 합니다. 문제가 발생할 경우를 대비해 다시 MySQL 기반으로 빠르게 롤백할 수 있는 계획도 같이 마련해 두세요.
- Redis로 전환 후, 예상치 못한 문제가 발생할 경우를 대비하여 모니터링 시스템을 통해 실시간으로 성능 지표를 확인할 수 있도록 합니다. 문제가 발생할 경우를 대비해 다시 MySQL 기반으로 빠르게 롤백할 수 있는 계획도 같이 마련해 두세요.
추가적으로 더 구체적인 방안이나 실제 운영 환경에 맞는 조언을 원하시면 다음 자료를 참고해 보실 수 있습니다: Redis를 이용한 조회수 관리와 마이그레이션 전략.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
'열정 있는 수강생 분들'에서 저도 포함되겠죠? 헤헿 ☺
명쾌한 답변 감사합니다!
Redis로 전환이 반드시 필요할 만큼 시스템 부하가 부담되는 상황인지?
=> 현재는 부하는 크지 않아 RDB로 운영해도 큰 무리는 없습니다!
꼭 조회수가 아니더라도 다른 기능 마이그레이션시 적용할 수도 있고, 고민하는 과정 자체가 재밌어서 질문드렸습니다!
강의에서 제안한 MySQL 백업 전략 대신 다른 백업 전략이 필요하진 않을지? (Redis 백업 기능 이용 또는 다른 전략) (강의에서 제안한 전략이 간단하고 편할 것 같긴한데, 고민은 해보아도 좋을 것 같네요!)
=> Redis 백업 기능은 고려하지 못한 부분이네요! 키워드 제공 감사드립니다.
나중에 또 다른 질문으로 찾아 뵙겠습니다 ㅎㅎ 주말 편히 보내세요!!