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

leettletree님, 안녕하세요!

말씀하신대로 게시글마다 좋아요 수(뿐만 아니라 조회 수, 댓글 수 등)도 항상 같이 조회하는게 일반적인 조회 패턴입니다.

이 경우 데이터 조인을 위한 작업은 당연히 필요하게 되고요.

아무래도 단일 테이블에서 조회하는 것도 아니고, 심지어 단일 DB에서 조인할 수 있는 것도 아니면서,

네트워크 통신을 통한 마이크로서비스 간에 애플리케이션 조인을 해야하므로 성능에 대한 고민도 당연히 뒤따를 수 밖에 없습니다.

이를 위한 성능 최적화에 대한 부분은 마지막 챕터 "게시글 조회 최적화 전략"에서 학습하게 됩니다.

해당 챕터에서 다루는 해결 전략을 간단히 언급 드리면,

쿼리 요구사항을 만족하기 위한 “쿼리 모델”을 별도로 구성하는겁니다.

(게시글 + 좋아요 수 + 조회 수 + 댓글 수)를 통합된 하나의 단일 모델로 만들고, 통합된 모델을 보여줘야하는 클라이언트 영역에서는 위 쿼리 모델을 응답해주면 됩니다.

강의에서는 Redis(메모리)에 쿼리 모델을 관리하는 방향으로 진행합니다.

이러한 데이터를 만들기 위한 구체적인 방법과 최적화 전략, 고려해야할 부분들은 강의 듣다 보면 학습하시게 될겁니다!

물론, 해결 방법이 위 전략만 있는건 아닙니다. (여기는 강의에서 다루지 않는 부분입니다.)

데이터 조인하는게 많지 않다면 애플리케이션에서 조인하는 것도 그렇게 큰 성능 부담으로 다가오진 않습니다.

물리적으로 가까운 또는 동일한 네트워크에 위치한다면, 네트워크 통신도 빠르게 처리 됩니다.

동기적으로 여러 개의 데이터를 조인하는 작업은 병목이 생길 수도 있는데요, 이에 대한 해결책으로 멀티스레드 또는 리액티브 방식으로 병렬 조회하여 개선할 수도 있습니다.

게시글 조회할 때 마다 좋아요 서버로의 api요청이 불가피

위에 대한 내용도 간단히 설명 드리면, 의존성 순환 참조 문제로 인해 위와 같은 요청 방향은 지양하는게 좋습니다. (의존성에 대한 내용은 마지막 챕터 CQRS에서 언급됩니다.)

의존성 문제는 CQRS를 통해서 해결할 수도 있고, 그냥 하나의 마이크로서비스로 통합하여 패키지/모듈 수준에서 관리할 수도 있고, 클라이언트의 요청부터 각 마이크로서비스로 향하는 흐름 중간에 데이터 조인해주는 레이어를 하나 만들어도 됩니다.

이러한 레이어는 클라이언트 개발자들이 서버를 구성할 수도 있고(BFF), 백엔드에서 클라이언트 개발자를 위한 레이어를 구성해줄 수도 있습니다. 또는, 사용자 기기(브라우저/앱)에서 여러번 호출해서 조인해줘도 됩니다. (어떤 영역은 늦게 뜨고, 어떤 영역은 빠르게 뜨고 등의 사용성도 종종 경험해 보셨을 것 같습니다.)

여기에서 구체적인 내용까지 다루기는 어렵지만,

비용, 생산성, 팀의 상황, 학습 수준, 성능 등 고려하여 적절한 방법과 구조를 찾아서 성능 문제를 개선할 수 있습니다.

안녕하세요, 인프런 AI 인턴입니다. leettletree님.

질문 주신 내용은 게시글 조회 시, 각 게시글의 좋아요 수를 함께 제공하는 것과 관련된 성능 문제입니다. 이와 관련하여 몇 가지 해결책을 제안드리겠습니다.

문제점 및 성능 저하의 원인

현재 게시글 서버와 좋아요 서버가 분리되어 있고, 각 게시글에 대해 좋아요 수를 함께 조회해야 한다면, 게시글 조회 시마다 좋아요 서버로 API 호출이 필요해집니다. 이런 방식은 여러 개의 네트워크 호출을 초래하게 되어 성능 저하의 원인이 될 수 있습니다.

성능 개선 방안

1. 비정규화:

   • 말씀하신 대로 비정규화를 통해 게시글과 좋아요 수를 단일 서버에서 관리하는 방식은 데이터 일관성을 유지하는 데 있어서 어려움이 있을 수 있습니다. 하지만, 적절한 시점에 데이터 동기화를 수행하면 비정규화를 통한 성능 개선이 가능합니다.
     

2. 캐싱 사용:

   • Redis와 같은 캐시 솔루션을 이용하여 자주 조회되는 데이터(인기 게시글 등)를 메모리에 저장함으로써 DB에 대한 부하를 줄일 수 있습니다. Redis를 활용해 자주 조회되는 게시글과 그에 대한 좋아요 수를 캐싱하면 응답 시간을 크게 줄일 수 있습니다.
     

3. 데이터 동기화 주기 조정:

   • 좋아요 수와 같은 비즈니스 데이터는 실시간 일관성을 요구하지 않는다면, 일정 주기로 동기화하거나 늦게 반영될 수 있도록 유도하는 방식이 가능합니다. 조회 빈도가 높은 데이터를 중심으로 캐싱하고, 배치 작업을 통해 DB에 동기화하는 방식을 취할 수 있습니다.
     

4. 결합 데이터 모델:

   • 조회 시점에 대한 응답 성능이 중요하다면, 좋아요 수를 포함한 특정 데이터셋을 결합하여 미리 구성해 놓고 조회하는 방법도 고려 가능합니다. 이는 LikeCount를 게시글 데이터에 주기적으로 합산하여 미리 계산된 데이터셋을 준비해 놓는 방식입니다.
     

위의 방법들을 참고하여 구현하시면 좋겠습니다. 추가적으로 멀티 서버 환경에서의 데이터 동기화 및 캐싱 전략에 관한 질문을 확인해보시면 도움이 될 것입니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.