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

Hyo Kyun Lee님, 안녕하세요!

- 제가 올바르게 강의내용을 이해하지 못하여 질문드리는 것 일 수 있기에, 일단 제가 들었던 의문이 선생님께서 생각하셨을때, 타당한 의문일지 궁금합니다.

타당할 수도 있고, 아닐 수도 있습니다.

트래픽이 얼마나 들어오는지, 데이터 조인을 얼마나 많이 하는지 등 상황마다 달라질 수 있기 때문입니다.

트래픽이 많이 들어오지 않고 응답을 만들어내기 위해 조인하는 데이터도 별로 없다면,

당연히 단건 데이터까지 비싼 저장소에 쿼리 모델을 관리할 필요는 없습니다.

강의에서는 쿼리 모델을 만들기 위해 게시글/댓글수/좋아요수 고작 3개의 데이터만 조인하고 있기 때문에, 간단한 요구사항에서는 크게 와닿지 않으실 수 있을 것 같습니다.

그런데 실제로는 요구사항이 복잡한 경우, 어떠한 단건 데이터를 조회하려면 수십개의 데이터를 조인해야할 수도 있습니다. (게시글이 신고되진 않았는지, 사용자는 탈퇴하지 않았는지, 태그같은 부수적인 데이터, 외에도 클라이언트 영역에서 다른 데이터들을 같이 그려줘야 하는지 등)

각 데이터(도메인)마다 별도의 팀 또는 마이크로서비스로 구축되어 있는 상황이라면,

이러한 조회에 대해 모든 애플리케이션에 동일한 트래픽이 전파되고, 그만큼 서버를 늘리고 가용성을 유지해야 하며, 그만큼 네트워크 및 I/O 비용이 생기고, 그만큼 응답을 만들어내는 데 지연이 생길 수 있습니다.

이러한 상황에는 트래픽 전파 방지나 성능 관점에서 단건에 대한 캐시도 물론 필요합니다.

이미 느끼고 계시겠지만, 당연히 모든 시스템에 적용해야하는 전략은 아닙니다.

애초에 대규모 시스템을 위한 전략들이라, 소규모 시스템에서는 개발 및 운영의 복잡도와 비용만 높일 수 있습니다.

여기서 말하는 소규모 시스템은, 트래픽이 적다 뿐만 아니라 요구사항이 간단하다는 것도 포함됩니다.

또한, 이러한 전략수립의 당위성을 떠나서 각 조회기능별로 전략을 구상하는게(단건/목록 등) 수립은 가능하더라도 관리가 힘들 것 같은데, 실무적으로 관리가 가능할지 의문이 들기도 하였습니다.

질문이 살짝 난해하게 다가오지만, 실제 관리해본 경험이 없으면 충분히 의문이 생길 수 있을 것 같습니다.

당연히 관리는 가능하고요(필요하면 만들 수 밖에 없습니다..!), 실제로도 많이 사용되는 전략입니다.

그리고 사실 실무적으로 관리가 가능한지는, 개발자의 역량 문제가 가장 클 것 같습니다.

더욱 복잡한 요구사항과 대규모 트래픽을 다루는 시스템은 많고,

그러한 시스템에서 위 전략으로 해결할 수 있는 문제가 많기 때문에,

문제 상황을 접하고 있다면 당연히 적용할 수 밖에 없습니다.

조금 더 명쾌하게 답변 드리면, 시스템이 커진다면 이러한 최적화 전략들이 불가피한 상황이 생길 수 있습니다.

- 타당하다면 아래와 같은 "게시글 단건" 조회 전략을 생각할 수 있을 것 같은데, 혹시 바람직한 전략이 될 수 있을지 고견을 요청드려보고자 합니다.

[단건 조회전략 구상 방안] 게시글 조회 전략을 만약 구상한다면(세부적인 전략구현은 생략)
- 지금처럼 단건 데이터 생성마다 articleQueryModel을 구성하는 것이 아니라, 각 카테고리별 보여지는 1000개의 데이터에 대해 articleQueryModel 데이터를 구성한다. (*게시글을 보는 것도 결국 최신 1000개의 데이터에 대해서만 볼 것이기 때문이다.)
- 인기글 데이터 생성 후 해당 인기글에 대한 articleQueryModel 데이터를 구성한다.
(*인기글 데이터에 대해서만 단건 조회 트래픽이 몰릴 것으로 예상할 수 있기 때문이다.)

지금 강의에서 채택한 구현은 1일 단위의 TTL 전략을 취하고 있습니다.

메모리 비용 때문에 모든 단건 데이터를 영구히 저장하지 않습니다.

즉, 언급주신 내용은 articleQueryModel을 시간 단위로 제한할 것인지, 개수 단위로 제한할 것인지에 대한 차이이고, 다른 부분은 동일한 것으로 이해됩니다.

일단, 말씀주신대로 개수 단위로 구현하든, 시간 단위로 구현하든 전혀 문제 없습니다.

게시판 서비스를 다루는 강의에서 어떠한 구현 방식으로 전달 드릴지 고민되던 부분이기는 했지만,

시간 단위의 제한을 정답이라고 전달 드릴 의도는 전혀 없습니다.

몇 가지 관점에 대해서 조금 더 살펴보면 좋을 것 같은데요,

먼저 "최신 1000개 == 인기글"이라는 관점에서 보겠습니다.

정말 최신 1000개의 단건 데이터가 항상 자주 접근될까요?

사실 인기 없는 게시판의 게시글인 경우, 최신의 글이더라도 그다지 접근될 일은 없을 수 있습니다.

먼저 진입되는 목록은 자주 조회될 수 있을지 모르더라도, 각 게시글까지 진입은 안할 수도 있는 것이고요.

그런데 개수 단위 제한만으로 영구히 데이터가 남아있다면, 오히려 이것도 낭비가 될 수 있습니다.

이러한 경우에는 그냥 시간 단위 TTL로 데이터를 정리해주는게 공간 활용 측면에서 유리할 수 있습니다.

또, 현재 단건 데이터가 반드시 1000개가 저장되었다는 사실은 어떻게 보장할까요?

지금은 sorted set에 저장된 목록 데이터가 있기 때문에 카운트에 그대로 활용할 수 있을지도 모릅니다.

하지만 이를 위해서는 처음부터 단건/목록 데이터에 대해 반드시 개수가 일치되어야 한다는 전제가 필요합니다.

만약 이후에 각 전략을 별도로 적용한다면, 마이그레이션이 필요할 수 있는 것이고요. (목록 데이터에 이미 1000개가 있는데, 그 시점부터 해당 카운트로 단건 1000개 제한을 적용한다면, 단건에 대해 저장된 개수와 실제 맞지 않으므로 저장되지 않음. 이러한 경우 일치시켜줘야 한다는 의미.)

또, 개수 확인 용도의 목록 데이터를 지금 구현처럼 관리하지 않는다면,

단건 데이터 개수 제한을 위한 카운트를 별도로 관리해줘야 하므로 구현 복잡도는 더욱 올라갈 수 있습니다.

물론, 시간 단위 제한의 전략만을 취할 때에도 문제는 분명 있습니다.

하루 단위로 작성되는 게시글 수가 무수히 많다면, 이미 뒷페이지로 밀려서 굳이 접근되지 않는 데이터도 만료되는 시점까지 공간을 차지하고 있어야 합니다.

간단한 해결책으로는, 1일이라는 기준 시간을 1시간 or 1분 등으로 더욱 줄이고, 실제 접근될 때 다시 캐시하는 형태로 관리할 수도 있습니다.

적절한 시간 기준에 대해서는 실제 쓰기 패턴을 보며 고민해볼 필요는 있겠지만, 현 구조에서 가장 간단한 해결책이 될 수는 있겠네요.

시간/개수 단위 각 제한의 한계를 해결하면서도 더욱 세밀하게 제어하고 싶다면, 개수 + 시간 제한 모두 포함할 수도 있을 것 같습니다. (예를 들어 ,1일 + 최대 1000개)

하지만 이는 구현의 복잡도를 높이기 때문에, 정말로 필요한 구조인지 먼저 고민해보는게 좋다고 생각됩니다.

제시한 전략은 수많은 구현의 예시일 뿐이고, 다른 전략이 필요하다고 판단되시면, 적용하는게 맞습니다.

절대 한 가지 또는 특정한 방법을 고수할 필요는 없습니다.

- 또한 실무적으로 이러한 다양한 관리전략을 수립하게된 계기가 "성능문제" "사용자 패턴에 따른 문제점 예상" 등, 여러 문제 중 어떠한 부분이 가장 중요하게 작용하는지 궁금하여 질문드립니다.

물론 더욱 중점에 두는 부분은 있겠지만, 절대 단일한 부분만 가지고 고려하진 않습니다.

여러 문제들을 복합적으로 고려해보고, 어떠한 전략을 적용했을 때의 장단점을 명확하게 따져봐야할 것 같습니다.

이미 성능이 충분한 상황이라면, 굳이 비용과 관리 복잡도를 높이면서 시스템을 개선할 필요는 없습니다.

그런데, 성능이 부족하고 사용자 경험에 영향을 끼친다면, 당연히 비용과 관리 복잡도를 높이더라도 시스템 개선은 필요합니다.

결국 모든 시스템들은 사용자를 위해 만들어지고 제공되는 것이므로, 가장 중요한건 사용자의 경험인 것 같네요.

기능적인 부분을 제외한다면, 사용자는 빠르고 무중단으로 항시 운영되는 것을 원할테니까요.

최종 마무리에 한 번 언급하는데요, 사실 구현 전략은 너무나도 다양하고 정답은 없습니다.

현 요구사항과 시스템에 알맞게 적절한 전략을 직접 만들고 찾아나가는 역량 키우는 것도 정말 중요하다고 생각되네요!

그나저나 댓글 챕터에서 질문 주셨던 기억이 나는데, 벌써 완강을 목전에 두고 계시군요.

이렇게 직접 고민하시는 것 보면 능동적으로 정말 열심히 공부하신 게 느껴집니다.

포기하지 않고 달려와주셔서 저도 감사하네요.

충분한 답변이 되었을지는 모르겠습니다만, 혹시 궁금한 점이 있으시면 편히 남겨주셔도 됩니다!

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

먼저, 강의를 열심히 수강하셨고 많은 성장을 이루었다는 말씀을 들으니 정말 기쁩니다. 질문하신 게시글 조회 및 목록 최적화 전략에 대해 자세히 안내드리겠습니다.

게시글/카테고리 최적화 전략에 대한 고찰

1. 전략의 세분화와 관리 비용

   • 게시글 조회 및 목록에 대한 각각의 최적화 전략은 필요에 따라 세분화할 수 있습니다. 이러한 세분화는 일반적으로 성능 최적화와 사용자 경험 향상을 위한 것입니다.
     
   • 하지만, 말씀하신 것처럼 모든 영역을 세부적으로 최적화하려 할 경우 관리 비용이 급격히 증가할 수 있습니다. 이는 특히 팀의 리소스 한계, 운영 비용 등을 고려할 때 중요한 요인이 됩니다.
     

2. 단건 조회 전략 및 관리

   • 단건 조회에 대해선 사용자 요청이 적을 것 같은 데이터만 캐시로 두고, 비교적 자주 요청되는 데이터에 한해서만 캐싱 전략을 적용할 수 있습니다. 예를 들어, 최신 1000개의 데이터 및 인기글에 대해 캐싱을 진행하는 방안이 이를 해결할 수 있습니다.
     

3. 성능 문제와 사용자 패턴 인식의 중요성

   • 분산된 저장소의 이용, 높은 트래픽의 처리 등과 같은 성능 문제는 주로 상위 트래픽 서비스에서 부각됩니다. 정확한 목표가 없다면 불필요한 최적화 노력이 들어갈 수 있기 때문에, 사용자 패턴을 분석하고 이에 맞는 최적화가 필요합니다.
     
   • 이와 관련된 문제의 식견은, 트래픽 분석, 사용자의 활동 패턴 및 주요 성능 지표 등의 자료를 통해 얻게 됩니다.
     

정리 및 추가 의견

• 세밀한 캐시 접근: 게시글에 대한 캐시 접근은 사용자 트래픽 데이터, 서버 부하, 데이터 일관성 요구 사항을 기반으로 판단되어야 합니다.

• 바람직한 전략: 가장 빈번하게 요청되는 데이터만을 대상으로 효율적인 관리 및 전략 수립을 시도하는 것이 효과적일 수 있습니다. 초기 단계에서는 설계 간단성을 유지하고, 이후 개선 사항을 바탕으로 전략을 조정해 나갈 수 있습니다.

관련 질문으로는 아래의 링크도 참고하시는 것을 추천드립니다:

• 인기글 설계에 대하여 질문드립니다.
  

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