샤딩에 대해서 궁금점있습니다.

hahahl님, 안녕하세요! 일반적으로 샤딩이라 함은 수평 분할에 대한 용어로 사용되지만, 개념적으로 수직 분할이란게 없는건 아닙니다. (공식적인 용어에 대해서 묻는 것이라면, it 분야가 용어와 그에 대한 해석이 다양할 수 있고 비공식적인 용어도 흔히 사용되다보니, 그 부분에 대해선 저도 모르겠습니다.)수평(테이블로 치면 레코드 단위)으로 분산하는게 아닌, 수직(테이블로 치면 컬럼 단위)으로 분산하면 그것이 수직 분할인 것이고요.사실 1:1 테이블 관계로 정규화한다라는 개념과 딱히 다를 것 없다고 생각되기도 하네요. (물론 엄밀히 따지면 다르지만요)특별히 설명 드릴만한게 있는 부분도 아니고 용어에 대해서 깊게 짚고 넘어가야할 부분은 아니라, 크게 신경 안쓰시고 넘어가셔도 괜찮을 것 같네요!

게시글 테스트 데이터 삽입 - @PersistenceContext 에 관하여

jack8226님, 안녕하세요! TransactionTemplate을 사용하여 트랜잭션을 따로 열고 EntityManager를 활용하는 부분은,단순히 건건이 쿼리보단 벌크가 빠르므로 테스트 데이터 삽입을 빠르게 처리하기 위한 작업이었고,그냥 JPA에서 bulk 연산을 하려면 트랜잭션 종료 시점에 한번에 flush 되니까 그렇게 처리할 수 있겠더라고요.이를 위해 TransactionTemplate으로 트랜잭션을 직접 연 것이고(같은 클래스에서 aop는 동작 안하므로), 벌크 용도로 EntityManager를 쓴 것입니다. PersistenceContext 로 em 을 가져온 이유가 있나요? 아니면 선호하시는 방식이라 채택한 방법인가요? 그리고 질문 주신 사항에 대해서도 딱히 의미를 두고 차이를 만든 부분은 아니라, 크게 신경쓰실 필요는 없을 것 같습니다..!어떠한 방향을 선호하는 것도 아니고, 그러한 세부적인 차이를 알 정도로 JPA를 공부하진 않았고 공부할 생각도 딱히 없습니다. (개인적으로 선호하는 방향은 JPA 자체를 아예 안쓰는 것이고, 실제로도 안쓰고 있습니다.)저도 질문 주신 것 보고 무슨 차이가 있었나 궁금해서 지피티한테 물어봤지만,이 답변을 그대로 전달드린다고 해서 딱히 의미가 있을 것 같지도 않고, 작성한 스크립트에서는 딱히 동작 상 차이가 있지도 않네요.그냥 JPA 학습할 때 @PersistenceContext를 썼던 기억과 JPA 관련 애노테이션이라 쓴 것이고, 단순 데이터 초기화 스크립트 용도라 별다른 의미를 두거나 동작 상의 차이를 이해하고 있던 부분은 아닙니다.또 개인적으로 추구하는 방향은, 굳이 몰라도 된다고 판단한 부분은 추상화된 영역까지 굳이 알려고 하진 않기도 합니다. 코드 의도를 파악하시는 것 너무 좋은 자세지만, 해당 부분은 저도 딱히 신경쓰고 만든 부분은 아니라 만족스러운 답변은 아닐듯하여 죄송스러운 마음이 있네요.. ㅎㅎㅎ

댓글 테이블 설계

jjs270402님, 안녕하세요! 실무에서 외래키 제약 조건은 걸지 않는게 일반적입니다.물리적인 제약 조건을 걸면 스키마 변경에도 어려움이 생기고, 데이터 CUD 시에도 제약 조건을 검증해야 하므로 DB 부하는 더욱 커집니다.DB의 리소스는 가장 소중하게 다뤄야할 부분이고요. (결국 모든 병목/장애 지점이 DB가 될 수 있으므로)그렇기 때문에 물리적인 제약 조건은 걸지 않습니다.댓글 테이블은 논외로 보고 애초에 테이블 자체가 물리적으로 분산되어 있는 분산 DB라면, 물리적 제약 조건을 아예 설정하지 못할 수도 있습니다.그렇다고 외래키가 아예 없다는 의미는 아닙니다.논리적인 설계에서는 외래키를 설정한 것이 맞고, 물리적인 제약을 설정하지 않는다는 의미입니다.그리고 논리적인 관계에 대해서는 DB 제약 조건으로 검증하는게 아니라, 애플리케이션에서 직접 제약 조건을 검증할 수 있는 것이고요.강의에서도 이러한 방식을 취하고 있습니다!

lockType 오류 및 카운트 체크 안 됨

안녕하세요! 위 내용만 보고는 원인 파악이 어렵네요, 혹시 스프링부트 버전이 강의와 다를까요?최신 버전에서는 restClient에서 retrieve()까지만 하면 실제 api 호출이 안될 수 있어서, retrieve().toBodilessEntity()까지 호출해보시겠어요?

샤딩의 기준

azosi님, 안녕하세요!강의 잘 수강해 주셔서 감사합니다! 샤딩의 기준이 현재는 article_id로 되어 있는데, 특정 샤드에 댓글 데이터가 엄청 생성되어서 불균형하게 저장이 되는 경우도 있을까요??확률에 대해서 물어보신거라면 당연히 0이 아니므로 불균형하게 저장될 수 있습니다.물론, 서비스 정책적으로 최대 댓글 수를 막는다면 큰 문제는 아니겠지만요.아무튼 샤딩이 불균형하게 되는 상황이 일어날 수 있는지 궁금하신 것으로 이해하였고,게시글-댓글 관계가 아닌 다른 데이터 구조에서도 이러한 상황은 분명 발생할 수 있습니다. 있다면 샤딩의 기준을 다시 정의하는 일도 있는지 궁금합니다.위와 같은 상황이 아무튼 생길 수 있으므로, 샤딩의 기준을 다시 정의하는 일도 분명 생길 수는 있습니다.다만, 이미 운영중인 시스템의 샤드 키를 무중단 시스템에서 변경하는 것은 복잡하고 무거운 작업이 될 수 있습니다.그래서 처음부터 샤드 키를 잘 설정하는 것이 중요합니다.여기에서 자세한 내용을 다룰 수는 없고, 샤딩 환경에서의 모델링 전략 관련하여 강의를 만든 것이 있어서 궁금하시면 수강해보셔도 좋을 것 같습니다. (분산 DB 환경을 직접 접하고 있지 않다면 꼭 들을 필요는 없어서 절대 강요는 아닙니다!)https://inf.run/fXomD다른 방법으로는, 특정 샤드 키에만 데이터가 쏠린다면, 해당 키를 Hot Key로 보고 특별하게 별도 취급하는 방법도 있습니다. (다른 데이터들은 기존 샤딩 전략을 쓰고, 일부 Hot Key만 별도 전용 샤드로 빼는 등의 방법을 취한다는 것) 감사합니다.

강의자료중 github 자료

쭈도리님, 안녕하세요!소스코드를 말씀하시는걸까요? github에 따로 코드를 공개적으로 열어두고 있진 않습니다!

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는 별도 프로세스에 이러한 장치들이 포함되어 있습니다.여기서 세부 사항까지 다루기 어렵지만, 구현 방법에 따라 모두 다를 수 있다는 점 언급 드립니다!