hwasowl.log

문제스프링 배치 환경에서 프롬프트 AI를 활용해 row을 가져오면 파싱 후 저장하는 job을 수행하고 있다.하지만 외부 API 특성상 서버 환경이 불안정해 요청에 실패하거나 프롬프트 AI 특성상 도메인 형식에 맞지 않는 정보를 가져올 확률이 있다. 위 경우 만약 5번의 외부호출이 발생하는 배치 잡이라고 상황을 가정해보자.극단적인 예시로는 25번을 성공헀는데 마지막 1번의 호출or파싱에 실패해 예외가 발생하는 경우 + 전체 트랜잭션 옵션이 걸려있다면 모두 롤백된다. 그 말은 즉슨 24번의 외부호출에 성공했어도 1번의 실패 때문에 다시 24 * n번의 호출이 발생할 수 있다는 것이다. 이와 같은 문제를 해결하기 위해 트랜잭션 전파 옵션을 활용한다면 훨신 효과적으로 처리할 수 있다. 개별 트랜잭션으로 묶기기 ..

https://github.com/Hwasowl/high-traffic-board GitHub - Hwasowl/high-traffic-board: 대규모 데이터와 트래픽을 대응하는 게시판 시스템대규모 데이터와 트래픽을 대응하는 게시판 시스템. Contribute to Hwasowl/high-traffic-board development by creating an account on GitHub.github.com 실시간으로 게시글이 작성될 때 마다 데이터가 변하는 게시글 목록 데이터는, 어떻게 캐시를 적용할 수 있을까? 가장 일반적으로 적용할 수 있는 캐싱 기법이다.1. 캐시에서 key를 기반으로 데이터 조회2. 캐시 데이터 유무에 따라, 데이터가 있으면, 캐시의 데이터를 응답 데이터가 없으면, 원..

https://github.com/Hwasowl/high-traffic-board GitHub - Hwasowl/high-traffic-board: 대규모 데이터와 트래픽을 대응하는 게시판 시스템대규모 데이터와 트래픽을 대응하는 게시판 시스템. Contribute to Hwasowl/high-traffic-board development by creating an account on GitHub.github.com 게시글 서비스 특성 상, 읽기 트래픽이 쓰기 트래픽보다 압도적으로 많다. 그리고 사용자에게 게시글만 보여주는 것이 아닌 좋아요 수, 댓글 수, 조회 수, 작성자 정보를 언제나 함께 보여줄 수 있어야 한다. 그렇다면 각 데이터가 분산되어 있는 환경에서 클라이언트는 어떻게 조회될 수 있을까? C..

프로듀서가 카프카에게 이벤트 발행 도중 장애가 발생한다면 어떤 일이 발생할까? 카프카의 모든 브로커 장애가 발생했을 수도, 네트워크 순단일 수도 있다. Producer는 Kafka로의 데이터 전송과 무관하게 정상 동작해야 한다. Kafka로 데이터 전송이 실패한다고 해서, Producer에 장애가 전파되면 안되는 것이다. 이로 인해 위와 같은 상황에서는, 게시글은 정상 생성되었더라도, 이러한 이벤트를 Kafka에 전달할 수 없는 상황이다. 신뢰할 수 있는 시스템인 Kafka로 아직 데이터가 전송되지 못했기 때문에, Producer가 생산 및 전파해야 하는 이벤트 데이터는 유실될 수 밖에 없다. 이로 인해 각 서비스마다 데이터의 일관성이 깨지게 된다. Producer에서 게시글이 생성되었는데, Consum..

- 좋아요 기능을 구현한다. 동시 하나에 게시글에 대한 수천, 수만 개의 좋아요 요청이 들어와도 대응할 수 있는 설계 방법이 필요하다. 방법 고민 대규모 데이터에서 좋아요 수를 계산하기 위한 count 쿼리를 사용하면 성능 이슈가 발생하고, 게시글과 달리 일부 카운트만 보여줄 수 없다. 또한 좋아요 수에서는 전체 개수를 실시간으로 빠르게 보여줘야 한다. (좋아요를 눌러도 느리게 반영되면 어색하다.) 만약 조회 시점에 실시간 조회에 큰 비용이 든다면 좋아요가 생성/삭제될 때 마다 미리 좋아요 수를 갱신하는 방법이 있을 것 같다. 좋아요 테이블의 게시글 별 데이터 개수를 미리 하나의 데이터로 비정규화 해두면 된다. 만약 쓰기 트래픽이 비교적 크지 않고 일관성이 중요하다면 관계형 DB의 트랜잭션을 활용할..

https://github.com/Hwasowl/large-scale-design/tree/main/service/articlemysql> create table article ( -> article_id bigint not null primary key, // 샤드키 -> title varchar(100) not null, -> content varchar(3000) not null, -> board_id bigint not null, -> writer_id bigint not null, -> created_at datetime not null, -> modified_at datetime not null -> );mysql> select count(*) fro..

전 글에서는 fetch join 시 생길 수 있는 페이지네이션 문제에 대해서 다뤄보았다.짧게 상기해보면 fetch join은 배치 사이즈에서 얘기한대로 하나의 collection fetch join에 대해서 인메모리에서 모든 값을 가져오기 때문에 페이지네이션이 의도한대로 작동하지 않았다. fetch join을 할 때 ToMany의 경우 한번에 fetch join을 가져오기 때문에 collection join이 2개 이상이 될 경우 너무 많은 값이 메모리에 들어와 exception이 추가로 걸린다. 그 exception이 MultipleBagFetchException인데, 아래 사진에서 볼 수 있듯이 2개 이상의 bags, 즉 collection join이 두개 이상일 때 exception이 발생한다. ..

전 글에서는 JPA N+1 문제 해결방안에 대해서 다뤄보았다. fetch join으로 N+1 문제를 모두 해결할 수 있어 보이지만 사용 시 유의점이 있는 케이스들이 크게 두 가지가 있다. 그 중 하나인 Pagination 문제에 대해서 알아보도록 하자. 예제는 전 글과 동일한 연관관계를 사용하겠다. Pagination 이슈페이징 처리를 JPA에서 할 때 가장 많이 겪는 이슈이다. fetch join을 통해 N+1을 개선한다고는 하지만 막상 Page를 반환하는 쿼리를 작성해보면 다음과 같은 에러가 발생하기 때문이다.@EntityGraph(attributePaths = {"articles"}, type = EntityGraphType.FETCH)@Query("select distinct u from Use..