이번주 금요일에 정말 장애와 함께 한 날인데요
크고 작은 총 3번의 장애가 날뻔한 것과, 잘못된 데이터가 내려가는 문제가 있었고, 슬랙 채널에서 승건 님을 포함한 거의 가장 높은 3명을 쭈르륵 만났습니다
가장 처음에 승건님을 만난 것은 어드민 페이지에서 특정 필드가 누락되어, 서빙되는 데이터가 잘못된 부분입니다.
이 부분은 그래도 제가 배포한 부분이랑은 관련이 바로 있지 않아 간접적으로 엮여있어서 좀 덜 신경 쓰였지만, 이후에 2번은 제 배포와 직접 연관이 되어있어 회고를 하기 위해서 글을 작성합니다.
제 사수분이 작성한 코드에서 카프카 토픽을 잘못된 곳에 집어 넣어서, 서비스에서 사용하는 카프카에 데이터를 추가한 것이 아니라, 로그 카프카에 데이터를 추가하면서 Unknown Topic 이 발생했었습니다.
정말 다행히도 기존 데이터나 유저들에게 영향이 없었습니다
문제가 없었던 이유는 다음과 같습니다. 기존 카프카 토픽 consume => 기존 로직 => 새롭게 카프카 produce(장애가 난 포인트) 순으로 되어있어서, 기존 로직이 모두 끝난 이후에 작동을 하게 짜져 있어서 문제가 없었습니다
이번 사건을 거치면서 어떻게 하면 기존 유저나 데이터에 흐름에 영향을 주지 않고, 기능을 추가 및 변경을 할 수 있을까에 대해서 생각해보았습니다
일단 가장 큰 포인트는 기존 로직에 영향을 최소한으로 주어야 한다는 것입니다
우리가 생각했던 형태의 데이터만 있는 것이 아니라 다른 형태의 데이터가 들어가 있다면 이 로직은 실패할 텐데, 그러면 무슨 일이 일어나지?
기존 고객은 어떤 화면을 보게 되지? 하는 고민을 하면서 안전장치를 만들어야 한다고 생각합니다.
이 부분을 저희 팀에서 redis 캐시를 도입할 때도 비슷하게 느꼈던 것 같습니다
캐시를 도입은 했지만, 이 캐시가 제대로 동작할지 보장할 수 없다면, 기존 로직을 그대로 다 태우고, 캐시는 단순히 같은지 판정하고,
서로 다르다면 로그만 남겨두는 용도로 사용하고 있습니다
캐시가 다르다는 로그가 일정 기간 이상 올라오지 않는 것을 확인한 이후에 캐시를 진짜 도입하기로 한 것인데요
이런 과정을 통해서 깨지지 않는 캐시라는 것을 보장할 수 있었습니다
요즘 봤던 유튜브 영상 중에서 기억에 남는 내용이 있고, 이 글에도 추가하면 좋을 것 같아서 링크를 추가해 두었습니다
어떻게 하면 이 기능을 망가뜨릴 수 있지? 를 먼저 생각한 이후에, 어떻게 하면 그 망가뜨리는 부분을 막을 수 있지라는 것을 떠올려본다면 좋은 결과가 있을 것 같습니다
https://www.youtube.com/watch?v=vZSzdDOKq4o
'프로젝트' 카테고리의 다른 글
장애 사례로부터 배우는 안전한 db 마이그레이션 방법(dual write) (9) | 2023.09.16 |
---|---|
카페인팀 서버 아키텍처를 설명해드리겠습니다 (7) | 2023.07.14 |
프로젝트 git branch 전략 어떤 것이 있을까? (2) | 2023.06.28 |
쿠키로 Jwt RefreshToken 관리하기! (내 쿠키는 어디갔지?) (2) | 2023.05.15 |
ElasticCache 에 SpringDataRedis 에서 키 동기화 문제 (0) | 2023.04.30 |