인프런 커뮤니티 질문&답변

민우님, 안녕하세요!

열심히 수강해 주셔서 감사합니다.

중요한 정보인데 쓰기가 자주 발생하는 상황에서 In-Memory 저장소를 메인으로 사용하고 RDB를 백업용으로 사용하면 위험하지 않나? 라는 생각이 들었습니다!

이럴 때에는 보통 어떻게 처리하시나요? (이럴 때 NoSQL을 사용하나요?)

정말 100% 유실이 없어야 하는지부터 다시 한번 고민해볼 것 같습니다.

현재 강의에서는 100개 단위의 백업 전략을 취하고 있는데요, 단순하게 50개 또는 10개 단위로 백업 개수를 줄여도 됩니다. 사실 평시에는 유실될 일이 거의 없기도 하고, 정말 큰 문제로 보기 어려울 수도 있고요.

그래도 유실이 없어야 한다면, 좋아요 수처럼 처음부터 안전한 저장소에서 관리해도 됩니다.

쓰기 트래픽의 우려가 다시 나오게 되는데요, 조회수에 대해서도 부가적으로 샤딩해서 저장할 수도 있습니다.

예를 들어, 조회수 테이블을 N개로 분산하고, 랜덤한 테이블만 1 증가, 조회할 때에는 N개의 샤드에 모두 조회해서 더하는 방식입니다. 그러면 쓰기 트래픽은 분산되므로 단일 레코드에 대한 락도 N개로 분산되는 것이고, 읽기 비용은 일부 늘어나게 되겠네요.

정확도가 중요한 영역에서는 안전한 저장소에서 조회하고, 정확도보단 성능이 중요한 영역에서는 지금 전략처럼 여전히 더욱 빠른 저장소에서 이중으로 관리하며 조회해도 됩니다.

또, 고민해볼 수 있는 방법은 append-only 방식으로 저장하고, 카운트 집계는 비동기로 처리하는 방안입니다.

조회가 일어나면 각 이벤트에 대해 오직 삽입만 수행하고, 후처리로 별도의 태스크에서 정확한 카운트를 집계하는 것입니다.

조회수에 대해 약간의 지연은 생길 수 있겠지만, 적재되어 있던 조회 이벤트를 기반으로 정확한 조회수를 계산해낼 수 있습니다.

정리하면, 요구사항이나 특성마다 어디까지 감안할 수 있는지 또는 보여지는 클라이언트 영역마다 어떤 부분을 중점으로 봐야하는지 등에 따라서 모두 다를 수 있을 것 같습니다.

그렇기 때문에 꼭 한가지 방법을 채택한다기 보단, 클라이언트 영역마다 여러 가지 방법을 복합적으로 적용해볼 수도 있을 것 같네요!

빅데이터 실시간 처리에 대해서는 람다 아키텍처나 카파 아키텍처도 한번 참고해보시면 좋을 것 같네요!