COUNT 쿼리에 LIMIT

Dev Jeon님, 안녕하세요! "16. 게시글 목록 API - 페이지 번호 - 게시글 개수 - 설계" 부분을 다시 학습해보시면 될 것 같습니다.전체 데이터 수 조회를 위한 것이 아닌, 이동 가능한 페이지 번호를 계산하기 위한 카운트 전략입니다.

게시글 조회 최적화 전략 도입 관련, 조회수 원본 데이터와 비교하였을때 원본과 캐싱 데이터 모두 Redis에서 추출하는 데이터임에도 (별도의 key 운용 등) Redis 캐싱 과정을 원본추출 과정과 따로 간주하는 이유(데이터를 가져오는 과정만 보았을때)

Hyo Kyun Lee님, 안녕하세요! 먼저 캐시가 해결해 주는 문제를 언급 드리면 좋을 것 같은데요,성능 뿐만 아니라 부하 분산 관점에서의 이점을 생각하면 더욱 와닿으실 것 같습니다. article-read sevice에서 조회수를 가져오든, view service에서 조회수를 가져오든,둘다 동일하게 메모리에서 가져온다는 것은 동일합니다.하지만 article-read service에서 조회수를 가져오는건, 즉시 Redis에서 조회하는게 아닙니다.반드시 article-read service -> view service로 요청하는 과정은 네트워크 I/O가 필요합니다.이에 대한 캐시를 적용한 것이고요.article-read service가 view service에서 항상 조회수를 조회할 때의 네트워크 통신에 대해 성능 및 트래픽 전파 방지 이점을 챙기게 됩니다. 혹시 client가 직접 view service에서 호출하여 조회수를 조합하면 되는 것 아닌지 의문이 드신다면, 아래 질문을 참고 부탁드립니다.https://inf.run/oKxuqhttps://inf.run/dzpG4 또, 아마 관련하여 이러한 의문도 드신 것 같습니다.‘어차피 두 마이크로서비스 모두 동일한 Redis를 사용하는데, article-read service도 바로 동일한 Key 데이터에 접근하면 되는 것 아닌가?’이번에는 경계와 격리에 대한 관점에서 고민해보면 좋을 것 같습니다.article-read service와 view service는 데이터베이스가 다를 수 있고(각 마이크로서비스마다 DB를 운용할 수도 있습니다.), 코드 베이스가 별도의 레포지토리로 분리되어 있을 수 있고, 담당자도 다를 수 있고, 운영하는 팀도 아예 다를 수도 있고, 심지어 다른 회사 소속일 수도 있습니다.지금은 단일 프로젝트에서 혼자 개발하고 있다보니, 이러한 관점이 잘 와닿진 않을 수는 있을 것 같습니다.시스템 전체를 혼자 또는 단일 팀에서 모두 개발하기 어려울 수는 있고, 다른 담당자 또는 다른 팀에서는 조회수에 대해 비즈니스 관점에서 활용하는 측면이 전혀 다를 수도 있습니다.이러한 상황에는 경계에 대해 잘 고민해봐야합니다.경계를 넘어서는 영역까지 침범하게 되면 인지 과부하가 생길수도 있고, 몰라도 되는 영역까지 알아야 하는 어려움과 복잡함이 수반될 수 있습니다. Key를 구분한 것도, 강의에서는 인프라 구조의 복잡도를 최소화하기 위해 단일 Redis를 운영한 것이지만, Key에 대한 네임스페이스만큼은 구분하기 위함이었습니다.(실제로도 물리적으로 구분하기보단, 논리적으로만 구분하는 경우도 많습니다.)각 담당한 도메인(또는 마이크로서비스)의 경계는 필요하다는 의미입니다. article-read service와 view service가 독립된 경계를 구성하고 있다고 본다면,article-read service는 view service가 내부적으로 redis를 사용하는지 알 필요도 없고, 알 방법이 없을 수도 있습니다. article-read service는 view service에게 그저 API(I는 Interface)를 통해서 조회수를 가져왔을 뿐입니다.그저 조회수를 가져올 방법을 인터페이스를 통해 공유 받고, 이를 통해 자신의 “게시글 Query” 기능을 구현한 것이고요.view service의 내부 데이터 관리 구조는 article-read service가 몰라도 되는 영역일 수 있습니다.물론, 예시일뿐이고 단일 시스템 및 단일 프로젝트에서 작성된다면 직접 알고 접근해도 문제 없을 수는 있지만, 격리된 상황에서의 전략 중 하나라고 생각하시면 될 것 같습니다.그리고 각각을 격리된 경계로 취급한다면, 처음부터 서로 결합되는 부분 없이 독립적으로 구성하는게 장기적으로 관리 측면에서 유리한 부분은 있습니다. 이것도 결국 큰 시스템을 여러 구성원들과 운영해봐야 와닿을 수 있을 것 같은데요, 당장은 관점에 대해서만 대략적으로 이해하고 넘어가도 충분할 것 같습니다!

게시글 조회 최적화 전략과 게시글 목록 최적화 전략 구분에 따른 정책수립/관리의 비용 관련 문의

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개)하지만 이는 구현의 복잡도를 높이기 때문에, 정말로 필요한 구조인지 먼저 고민해보는게 좋다고 생각됩니다.제시한 전략은 수많은 구현의 예시일 뿐이고, 다른 전략이 필요하다고 판단되시면, 적용하는게 맞습니다.절대 한 가지 또는 특정한 방법을 고수할 필요는 없습니다. - 또한 실무적으로 이러한 다양한 관리전략을 수립하게된 계기가 "성능문제" "사용자 패턴에 따른 문제점 예상" 등, 여러 문제 중 어떠한 부분이 가장 중요하게 작용하는지 궁금하여 질문드립니다.물론 더욱 중점에 두는 부분은 있겠지만, 절대 단일한 부분만 가지고 고려하진 않습니다.여러 문제들을 복합적으로 고려해보고, 어떠한 전략을 적용했을 때의 장단점을 명확하게 따져봐야할 것 같습니다.이미 성능이 충분한 상황이라면, 굳이 비용과 관리 복잡도를 높이면서 시스템을 개선할 필요는 없습니다.그런데, 성능이 부족하고 사용자 경험에 영향을 끼친다면, 당연히 비용과 관리 복잡도를 높이더라도 시스템 개선은 필요합니다.결국 모든 시스템들은 사용자를 위해 만들어지고 제공되는 것이므로, 가장 중요한건 사용자의 경험인 것 같네요.기능적인 부분을 제외한다면, 사용자는 빠르고 무중단으로 항시 운영되는 것을 원할테니까요. 최종 마무리에 한 번 언급하는데요, 사실 구현 전략은 너무나도 다양하고 정답은 없습니다.현 요구사항과 시스템에 알맞게 적절한 전략을 직접 만들고 찾아나가는 역량 키우는 것도 정말 중요하다고 생각되네요! 그나저나 댓글 챕터에서 질문 주셨던 기억이 나는데, 벌써 완강을 목전에 두고 계시군요.이렇게 직접 고민하시는 것 보면 능동적으로 정말 열심히 공부하신 게 느껴집니다.포기하지 않고 달려와주셔서 저도 감사하네요.충분한 답변이 되었을지는 모르겠습니다만, 혹시 궁금한 점이 있으시면 편히 남겨주셔도 됩니다!

물리샤드, 논리샤드 번호 질문입니다!

literate_t님, 안녕하세요! 아주 예리한 질문이고, 혼란을 드려서 죄송하다는 말씀을 먼저 드리고 싶네요.강의 자료의 hash function은 (article_id % 4) 연산으로 되어 있는데, 실제 결과는 그렇지 않게 표기되어 있습니다.이러한 hash function으로 보았을 때, 실제로는 [1, 5], [3, 7], [2, 6], [4, 8]로 묶이는게 맞습니다. (샤드별 순서는 차치하더라도)그래서 인프런 질문에 대한 답변으로 남겼던 것이 정확합니다..!이 부분은 저도 이제서야 인지했네요, 여유될 때 수정해 두도록 하겠습니다!제보 감사 드립니다. 추가적으로 클라이언트는 논리 샤드만 알고 있다고 하셨는데 그럼 물리 샤드 번호는 물리적으로 나뉜 샤드를 구분하는 데만 사용하고 비즈니스 로직에서는 사용되는 일이 없을까요?표현에 대해 조금 더 짚고 넘어가면, DB 시스템이 아니라면 샤드 번호를 할당하는건 "비즈니스 로직"이라기 보단, "기술 구현 사항"으로 표현할 수 있습니다.따라서, DB 자체가 비즈니스를 이루는 도메인이 아니라면, 물리 샤드 번호가 "비즈니스 로직"으로 사용될 일은 없다고 보면 될 것 같습니다. (이러한 관점에서는 논리 샤드 번호도 "비즈니스 로직"이라고 볼 수는 없습니다.) 물론, (DB 시스템이 아닌)클라이언트에서 물리 샤드를 알고, 기술 구현 사항으로 표현될 수는 있습니다.위 관점에서 본다면, 질문에 대한건 "클라이언트 애플리케이션"에서의 사용 여부 질문으로 보이기도 합니다.해당 내용은 구현하는 방법에 따라 달라질 것 같습니다.강의에서는 실제 물리 샤드를 알려주는 장치로 샤드 라우터라는 표현이 있었는데요, 이러한 샤드 라우터가 어디에 구현되어 있는지에 따라 달라질 것 같습니다.이러한 샤드 라우터는 클라이언트 애플리케이션에 구축될 수도 있고,클라이언트 애플리케이션이 의존하는 라이브러리에 구축되어 있을 수도 있고,데이터베이스에 구축되어 있을 수도 있고,클라이언트 애플리케이션과 데이터베이스 사이에 추가적인 시스템(DB에 종속된 또는 범용적인)으로 구축되어 있을 수 있습니다.몇 가지 예시를 들어보면, 레디스는 클라이언트 라이브러리에, mongo db는 별도 프로세스에 이러한 장치들이 포함되어 있습니다.여기서 세부 사항까지 다루기 어렵지만, 구현 방법에 따라 모두 다를 수 있다는 점 언급 드립니다!

댓글 내용 조회 시 어떤 방식을 선택하실까요?

밍트쪼코님, 안녕하세요! 저라면, 2번 방법을 택할 것 같습니다.게시글 조회 서비스에서 댓글 서비스를 호출하여 같이 조합하여 내려주는 것이 아닌,클라이언트가 게시글 서비스와 댓글 서비스를 분리하여 호출하는 것입니다.클라이언트에서 게시글과 댓글은 단일 페이지더라도 분리된 큰 영역일 것이고, 서로 별도로 호출하는건 큰 부담이 없습니다.게시글 + 댓글을 항상 조합해서 보여줘야한다는 것도 클라이언트의 관심사로 볼 수 있어서,만약 댓글만 보여줄 필요성이 있을 때에도 클라이언트의 변경만으로 더욱 유연하게 대응할 수 있을 것이고요.댓글 서비스의 조회 부담이 크다고 판단된다면, 댓글 도메인을 위한 '댓글 조회 서비스'를 만들어주면 되는 것입니다. 클라이언트 요구사항이 모든 데이터를 항상 조합해서 내려줘야 하고, 이러한 단일한 요구사항을 위해 더욱 최적화하고 싶다면, 1번 방법을 조금 더 개선해서 적용할 수도 있을 것 같습니다.다만, 단일 게시글에 대한 모든 댓글 목록을 단건 쿼리 모델에 담는 건 당연히 무리가 있습니다.관련해서 댓글도 Hot Data 관점에서 접근해볼 수 있을 것 같은데요, 댓글 목록도 모든 댓글을 캐시할 필요는 없습니다.결국 댓글이 많으면 댓글에 대해서도 페이징 전략이 들어갈 것이기 때문에, 각 게시글의 댓글 목록도 첫 페이지(또는 상위 N건)만 캐시해둘 수도 있을 것 같습니다. 물론, 구현 방식은 너무나도 다양하기 때문에 몇 가지 예시일 뿐이고 정답도 없는 내용이라, 장단점 따져보시고 크게 문제 없는 방향으로 구현 및 개선해 나가면 충분하다고 생각되네요! 약간 다르긴 하지만, 최근에 비슷한 질문이 들어왔던 게 있어서 참고해보셔도 좋을 것 같습니다.

강의 전에 학습할 내용

gubo_00님, 안녕하세요!스프링부트는 이미 학습하셨고, 다른 부분들을 선행한 뒤에 수강하고 싶으신 것으로 이해했습니다!사실 이론을 먼저 다 공부하고 수강하기엔 내용도 너무 방대하고 끝이 없을 수 있어서, 기본기(CS 이론, 알고리즘)만 탄탄하다면 바로 수강하시는걸 추천드립니다.어차피 Redis, Kafka는 이론 학습을 선행한다고 해도 와닿지 않고, 실무 활용 수준으로는 강의에서도 충분히 설명됩니다.특히 Redis는 이론까지 선행으로 깊게 공부할 필요는 없다고 생각하고, 그냥 활용의 영역이 더욱 큰 것 같아요.Kafka는 구조에 대한 이해도 필요하지만, 활용이 더욱 어렵고요.적어도 데이터베이스 이론만 공부해보시면 많이 수월하게 수강할 수 있을 것 같습니다!나머지는 수강하면서 모르는 개념들 차차 익혀나가는게 더욱 좋다고 생각됩니다.책이나 자료는 단편적으로 콕 집어서 말씀드리긴 어렵네요..!각 분야에 유명한 책 한번 읽어보시고 설계 관련해서는 다방면으로 학습해보시면 좋을 것 같습니다.

카프카 메시지 순서 관련 문의

rlapwl님, 안녕하세요! 순서에 대해서 완벽하게 보장하는 것은 쉬운 문제는 아닙니다.주문 id를 파티션 키로 지정한다고 하더라도, 순서가 변경될 수 있는 상황은 분명 있습니다.말씀하신대로 비동기 상황에서는 producer가 순서를 바꿔서 보낼 수도 있고,컨슈머가 모종의 이유로 실패하여 별도의 재처리 토픽에서 retry를 시도하다가 순서가 바뀔 수도 있고,이벤트 전송을 동시에 처리하는 설정일 수도 있고(max.in.flight.requests.per.connection),파티션 수를 늘리는 과정에는 파티션 키는 동일하더라도 새로운 이벤트가 다른 파티션으로 이벤트가 적재될 수도 있는 등..이러한 상황을 해결하기 위해서는 Producer가 발행하는 이벤트에 대해 넘버링을 할 수도 있을 것 같고요(컨슈머는 반드시 마지막 시퀀스와 최신 시퀀스에 대해 diff=+1인 이벤트만 정상 이벤트로 간주),논리적인 관계(주문 완료 상태가 아닌데, 주문 취소 상태 이벤트가 먼저 수신될 수는 없음)를 이용할 수도 있을 것 같습니다.또는, 이벤트를 컨슈머에서 append-only로 저장하다가 모두 수신 됐을 만한 충분한 시간을 대기한 후에, 순차적으로 처리하는 것도 하나의 방법일 것 같습니다. 논리적인 관계가 복잡하지 않고 명확하고 간단히 정의되어있다면 해당 방법만을 채택할 것 같고,더욱 복잡한 상황이라면 넘버링 정책으로 컨슈머가 순서 변경도 감지하고,평시에는 실시간으로 즉시 처리하다가 문제가 발생한 데이터에 대해서 알람 또는 모니터링 후에 수동 처리 및 관련 원인 개선을 해나갈 것 같습니다.파티션 수를 늘리는 과정에 대한 문제는, 일시적으로 이벤트를 모두 소진한 뒤에 잠시 중단 상태로 만들 수도 있고요.(시스템 점검과 같은 상황에 처리) 파티션 id를 고정으로 지정할 수도 있을 것 같습니다.사실 시스템 장애 상황에는 아키텍처에 따라 순서 변경 여지에 대해서 완벽하게 방지할 수는 없으므로, 여러 가지 방법을 복합적으로 고려해봐야할 것 같습니다!(참고 - 예전에 유사한 질문이 있었네요.)

카프카 학습에 관한 질문

riley님, 안녕하세요! Kafka Cluster에 대해서는 강의에서 20분 정도로 언급 되었고, 분명 부가적인 공부도 필요합니다.하지만 사실.. 직접 클러스터 세팅하고 운영하는게 아니라면, 처음 적용하려는 개발자 관점에서는 이걸로도 (거의) 충분하긴 합니다. 딱 개발자에게 필요한 핵심 부분만 요약을 한 것이었거든요.각 개념에 대해서 조금 더 차분하게 심도 있게 배워보고 싶으시면, 저는 보통 책을 선호하는 편입니다.물론, 공식 문서도 잘 되어있지만 직접 이슈 해결하는 과정 속에 있거나 뭔가 아는게 있어야 읽히더라고요.(영어가 익숙치 않다면 접근성이 떨어질 수 있고, ai한테 궁금한거 물어보는게 더 편하기도 하고요.)카프카 관련 강의는 수강한 적이 없어서 잘 모르겠네요.저도 처음에는 책(카프카인액션, 데이터중심애플리케이션설계 등 카프카에 대한 책 뿐만 아니라 다방면으로 공부는 필요하고, cs 지식이 있으면 수월합니다.)으로 공부했고 이해하는데 많은 도움 되었지만,결국 현업에서 직접 경험하면서, 이슈 하나씩 해결하고 공식 문서 살펴보며 배우는게 더욱 와닿긴 하더라고요.그리고 개발자 관점에서는 카프카 자체가 어렵다기보단, 카프카를 전체적인 시스템에서 어떻게 활용하고 다룰 수 있을지, 프로듀서와 컨슈머가 이벤트를 다룰 때 발생할 수 있는 문제(유실, 중복, 순서 변경, 지연 등)들을 어떻게 해결할 수 있을지 고민하는 것이 더욱 어려운 것 같습니다.카프카 공부도 필요하지만 어디까지 공부를 할지 경계를 잘 설정하는 것도 좋을 것 같고, 결국 개발 실무와 활용 관점에서 학습이 필요한 범위는 다를 수 있다는 점도 인지해 두시면 좋을 것 같네요!

완강 후 학습 방향에 대한 질문

westhan님, 안녕하세요!연휴 기간임에도 열심히 잘 수강해 주셔서 감사합니다! 말씀하신대로 강의에서 제시된 기술들을 한번에 모두 적용하려는 것은 너무 복잡하고 쉬운 작업은 아닙니다.실제로 각자 속한 환경에서는 모든 기술이 다 필요하지 않을 수 있을 것 같고요! 개념과 용어들에 대해서 챕터별로 실무 우선순위를 정해보자면..게시글 챕터(클러스터드/세컨더리/커버링 인덱스 개념 이해 및 최적화)좋아요 챕터(DB 트랜잭션과 락에 대한 이해)조회수 챕터(인메모리 데이터베이스와 캐시에 대한 이해, 레디스 활용)인기글 챕터(카프카에 대한 이해와 활용)게시글 조회 최적화 챕터(CQRS, 캐시 전략 등 적용하면 좋지만, 정말 이 정도까지 최적화가 필요할 때 적용하면 충분. 돈도 들어가고 복잡도도 엄청 높아지고 어렵습니다.)댓글 챕터(대규모 데이터의 계층형 테이블을 다룰 일이 있다면 필요하겠지만, 다룰 일이 없다면 필요할 때 적용하면 충분)이렇게 될 것 같습니다. 분산 DB나 MSA도 알아두고 잘 활용할 수 있으면 좋긴 하겠지만.. 당장에 경험할 수 없는 환경이면 실제 적용하기도 어렵고 시스템 복잡도도 엄청나게 많이 올라갑니다. 4~5번이 이러한 내용들이라서 쉽게 적용하긴 어려우실 수는 있을 것 같습니다.개인적으로 DB가 가장 중요하다고 생각하는게, 실제 병목이나 장애 지점이 되는 것도 보통 DB이고, 리소스도 최대한 절약하며 효율적으로 사용해야하는 것도 DB이기 때문에,대규모 시스템을 당장 다룰 일이 없다면 RDB 내부 동작만 제대로 이해하고 적용할 수 있으면 충분하다고 생각합니다! (분산 DB가 아니라 데이터베이스 이론을 말하는 것입니다.) 아무튼 정리하면, 1~3번 활용할 수 있는 방향을 먼저 중점적으로 살펴보시면 좋을 것 같고요.지금도 충분하다고 생각되신다면, 굳이 꼭 복잡한 기술들을 바로 적용할 필요도 없습니다!인덱스나 쿼리가 잘 최적화되어있는지 점검해보시고, 성능적으로 아쉬운 부분들 하나씩 확인하며 개선해 나가면 충분하다고 생각되네요!

Transactional Outbox 테이블 관련하여 질문드립니다

learnlearn님, 안녕하세요! 질문 주신 내용은 꼭 정답이 있다기 보단, 팀과 시스템에서 어떤 식으로 운영하고 싶은지에 따라서 정책을 달리할 수 있을 것 같습니다.실무에서도 단순하게 삭제 방식을 취해도 되고, 발행 완료 상태로 업데이트 한다거나 별도의 테이블에 한동안 관리할 수도 있습니다.어떠한 방법을 취하든 크게 상관은 없겠지만,발행 완료된 이벤트에 대해서도 저장하고 있다면 추후 이벤트 추적 등에 유리한 측면은 분명 있습니다.문제 상황 발생 시에 특정 기간 동안의 이벤트를 리플레이 할 수도 있고, 어떠한 이벤트가 언제 발행되었는지 추적해볼 수도 있습니다.(이러한 관점에 대해서는 이벤트 소싱이라는 개념이 있습니다.)다만, 이러한 필요성이 딱히 안보인다면, 발행 완료 이벤트에 대해 직접 관리하고 별도 삭제 태스크도 만들어야하는 복잡성이 생기긴 합니다.결국 삭제 여부나 주기도 팀과 시스템에서 정한 정책에 따라서 달리할 수 있는 것이고, 별도 배치나 스케줄러에서 수행될 수 있습니다.