완벽한 일관성은 존재하지 않는다.

DB만 사용할 때는 들어오는 데이터와 나가는 데이터가 크게 다르지 않습니다. 하나의 서버가 하나의 상태를 관리하고 있기 때문입니다.
모든 요청은 동일한 저장소를 바라보고, 하나의 진실(Source of Truth)이 존재합니다. 하지만 서비스의 규모가 커지는 순간 상황은 달라집니다. 트래픽을 감당하기 위해 서버를 늘리고, 응답 속도를 개선하기 위해 Redis를 도입하고, 비동기 처리를 위해 Kafka를 붙입니다.
그리고 그 순간부터 우리는 불편한 사실과 마주하게 됩니다. 어떤 곳에는 최신 데이터가 있고, 어떤 곳에는 아직 반영되지 않은 값이 있습니다. 어떤 요청은 성공했는데, 다른 곳에서는 여전히 이전 상태를 반환합니다. 데이터의 불일치는 사라지지 않았습니다. 오히려 더 자주, 더 복잡한 형태로 나타납니다. 그렇다면 우리는 Redis나 Kafka를 잘못 사용하고 있는 걸까요?

Eventual Consistency: The Key Trade-Off Behind Modern Databases

Eventual Consistency에 대한 글에서는 그렇지 않다고 말합니다. 문제는 기술의 사용법이 아니라, 분산이라는 선택 그 자체에 있다고 이야기합니다.

그 전에 데이터 일관성이란 무엇일까요?

인터넷에 데이터 일관성을 검색해보니 다음과 같은 답변이 나왔습니다.

데이터 일관성은 모든 사본 또는 인스턴스가 모든 시스템 및 데이터베이스에서 동일한 데이터 상태를 나타냅니다. 일관성은 다양한 데이터베이스 시스템, 애플리케이션 및 플랫폼에서 데이터가 정확하고 최신이며 일관성이 있는지 확인하는 데 도움이 됩니다.  google search
그렇다는건 데이터가 들어올때와 저장이 되어질때의 데이터가 일치를 해야 한다는 뜻이라는것을 알 수 있습니다.

우리는 무엇을 얻고, 무엇을 포기했는가

우리는 Redis를 사용하면서 속도를 얻었습니다. 하지만 동시에 안전성을 일부 포기했습니다.
Redis는 매우 빠른 시스템입니다. 메모리 기반이며, 조회 성능은 뛰어납니다.
그러나 Redis는 애초에 데이터의 절대적인 정확성을 보장하기 위해 설계된 시스템은 아닙니다.
강한 정합성과 영속성을 최우선으로 하는 전통적인 데이터베이스와는 목적이 다릅니다.
그럼에도 불구하고 우리는 Redis에게 속도도 요구하고, 데이터 유실도 없어야 하며, 항상 최신 상태이기를 기대합니다.
문제는 기술이 아니라 우리의 기대일지도 모릅니다.

모든것은 의도가 있어야 한다.

기술은 특정 문제를 해결하기 위해 등장합니다. 그 기술이 가진 한계를 억지로 덮기 위해
본래 목적과 다른 방식으로 일관성을 강요할 필요는 없다고 생각합니다.
Redis는 속도를 위해 존재합니다. Kafka는 비동기 처리를 위해 설계되었습니다.
각 기술은 명확한 목적과 전제가 있습니다.
그 한계를 인정하지 않은 채 모든 계층에서 완벽한 정합성을 맞추려는 시도는
오히려 설계를 복잡하게 만들 뿐입니다.
중요한 것은 한계를 부정하는 것이 아니라, 그 한계를 이해하고 어떻게 다룰 것인지 고민하는 일입니다.
그리고 그 고민이 구조로 표현되어야 합니다. 재현 가능하고 설명 가능한 형태로 정리되어야 합니다.
우리는 그것을 패턴이라고 부릅니다.
패턴은 한계를 부정한 결과가 아니라, 한계를 인정한 설계의 결과입니다.

결론

중요한 것은 기술을 어떻게 이해하고 표현하느냐라고 생각합니다. 그리고 그 기술이 가진 한계점을 정확히 인지하는 것이 무엇보다 중요합니다. 기술의 한계를 억지로 덮어 문제를 해결하려 하기보다는, 그 한계를 인정하고 설계에 반영하는 태도가 필요합니다. 어떤 기술은 속도를 위해 존재하고, 어떤 기술은 정합성을 위해 존재합니다. 모든 기술이 모든 문제를 해결해주지는 않습니다. 기술이 가진 전제와 한계를 이해한 상태에서 적절한 위치에 배치한다면, 그 기술은 훨씬 효과적으로 사용될 수 있다고 생각합니다. 완벽함을 강요하는 대신, 의도를 분명히 하고 한계를 설계로 다루는 것. 그것이 분산 환경에서 우리가 가져야 할 태도라고 생각합니다.