안녕하세요! E-Market 개발팀입니다. 오늘은 E-Market 서비스에서 빈번하게 마주치는 골칫거리, 바로 동시성 문제 해결 과정을 여러분과 공유하려고 합니다. 단순히 문제 해결 방법만 나열하는 것이 아니라, 어떤 고민 끝에 어떤 방식을 선택했는지, 그 과정과 판단 기준까지 꼼꼼하게 설명드릴 테니, 비슷한 고민을 하고 계신 분들께 많은 도움이 될 거라 생각합니다.
특히 이번 글에서는 여러 동시성 처리 방법 중에서 E-Market의 게시글 좋아요 기능을 예시로 들어 설명해 보겠습니다. 물론 E-Market에선 결제, 상품 등록 등 다양한 부분에서 동시성 이슈가 발생하지만, 좋아요 기능은 비교적 이해하기 쉽고 핵심적인 동시성 문제를 잘 보여주기 때문입니다.
먼저, 게시글 좋아요 기능에서 동시성 문제가 발생하는 이유는 간단합니다. 여러 사용자가 동시에 같은 게시글에 좋아요를 누르면 데이터베이스에 저장된 좋아요 수가 정확하게 반영되지 않을 수 있습니다. 예를 들어, 좋아요 수가 10인 게시글에 두 명의 사용자가 동시에 좋아요를 누른다고 가정해 봅시다. 만약 적절한 동시성 처리가 없다면, 좋아요 수가 11이 아닌 10 또는 12로 잘못 업데이트될 가능성이 있습니다. 이는 단순한 오류를 넘어 서비스 신뢰도에 심각한 영향을 미칠 수 있습니다.
그렇다면 이 문제를 해결하기 위한 방법은 무엇일까요? 저희는 몇 가지 방식을 검토했습니다. 첫째, 낙관적 락(Optimistic Locking)을 이용하는 방법입니다. 이는 데이터베이스 레코드에 버전 정보를 추가하고, 업데이트 시 버전 정보를 확인하여 동시성 충돌을 감지하는 방식입니다. 둘째, 비관적 락(Pessimistic Locking)을 활용하는 방법입니다. 이는 데이터베이스 레코드에 락을 걸어 하나의 트랜잭션만 접근하도록 제어하는 방식입니다. 마지막으로, 분산 캐시(Redis 등)를 활용하여 좋아요 수를 관리하고, 주기적으로 데이터베이스와 동기화하는 방법도 고려했습니다.
각 방식은 장단점을 가지고 있습니다. 낙관적 락은 성능이 좋지만, 충돌 발생 시 재시도가 필요하고, 비관적 락은 충돌을 효과적으로 방지하지만 성능 저하를 야기할 수 있습니다. 분산 캐시는 높은 성능을 제공하지만, 캐시와 데이터베이스 간의 일관성을 유지하는데 신경써야 합니다.
결론적으로 저희는 철저한 성능 테스트를 통해 최적의 방식을 선택했습니다. 각 방식에 대해 다양한 사용자 수와 동시 접속 상황을 시뮬레이션하여 응답 시간, 처리량, 오류 발생률 등을 측정했습니다. 그 결과, 저희 서비스의 특성과 요구사항에 가장 적합한 방식은 분산 캐시를 활용하는 방법 이었습니다. 높은 성능과 확장성을 확보하면서, 동시성 문제를 효과적으로 해결할 수 있었기 때문입니다. 물론, 캐시와 데이터베이스 간의 데이터 일관성을 유지하기 위한 추가적인 노력이 필요했지만, 테스트 결과를 바탕으로 안정적인 시스템을 구축할 수 있었습니다.
이번 경험을 통해 동시성 문제 해결은 단순히 기술적인 문제를 넘어, 서비스의 안정성과 성능을 좌우하는 핵심적인 요소임을 다시 한번 확인했습니다. 앞으로도 E-Market은 끊임없는 성능 개선과 안정적인 서비스 운영을 위해 노력할 것입니다. 긴 글 읽어주셔서 감사합니다!