전체 글 (145) 썸네일형 리스트형 2024-05-14) 프로젝트 복기 N+1 문제는 데이터베이스 쿼리 성능을 저하시킬 수 있는 일반적인 문제로, 이를 해결하기 위해 여러 가지 방법이 존재한다.Fetch JoinFetch Join은 연관된 엔티티를 한 번의 쿼리로 가져와서 N+1 쿼리를 한 번의 쿼리로 줄여주는 방법이다.@Entitypublic class Author { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; private String name; @OneToMany(mappedBy = "author", fetch = FetchType.LAZY) private List books;}@Entitypublic class Book { @Id @Gen.. 2024-05-12) 동시성 이슈, 락에 대한 고찰 우리 프로젝트는 시간관계상 비관적 락을 통해서 구현을 시작했었고, 비관적 락을 사용하기에, 로드 밸런싱을 사용했을때 서버에 가해지는 부하는 분산됐지만, 처리 총량은 변하지 않았다.대용량 트래픽을 처리해야 하는 환경에서는 비관적 락과 낙관적 락 모두 한계가 있을 수 있다. 대규모 트래픽과 데이터 처리에서는 두 가지 락 기법 모두 성능 저하나 확장성 문제를 초래할 수 있기 때문이다.비관적 락의 한계성능 저하많은 트랜잭션이 동시에 락을 획득하려고 하면 경합이 발생해 성능이 저하될 수 있다.확장성 문제락 관리의 복잡성이 증가하면서 시스템 확장성에 한계가 생긴다.데드락 발생 가능성여러 트랜잭션이 동시에 여러 자원을 락하려고 하면 데드락 가능성이 높아진다.낙관적 락의 한계높은 충돌 발생 가능성트랜잭션 수가 많아지면.. 2024-05-08) MySQL DB Indexing 고찰 6주간의 팀 프로젝트 작성이 마무리되었다. 급했던 나서 조금이나마 숨을 돌리면서 프로젝트를 되돌아보는 시간을 가졌다. 그러고 보니 놓치고 있었던 부분이 보이게 되었는데, 바로 인덱스가 생성될 때 실제 데이터 수와는 다른 인덱스가 생성되는 것을 확인할 수 있었다.프로젝트에 JPA annotation을 적용, 인덱스를 생성하여 약 20%의 성능 향상을 얻을 수 있었다. 그러나 사용 중 데이터 수와 인덱스 수의 불일치 현상이 발생하여 의문이 들었다. 50,000개의 데이터가 있는 데이터베이스에서 show index를 실행했을 때, 인덱스 수가 실제 데이터 수보다 20개 적은 49,980개로 나왔다. 이 문제를 해결하기 위해 데이터베이스를 복제하고 인덱스를 다시 생성했지만 결과는 같았다.이에 ALTER TABL.. 2024-05-05 팀 프로젝트 회고프로젝트 명: PigonAir프로젝트 기간: 3/26 ~ 5/7프로젝트 목표:주요 목표대용량 트래픽에 견딜 수 있는 서버 설계달성 여부60%성과 및 성취성취한 목표:목표 1: redis, webflux를 적용한 대기열 구현목표 2: 결제 후 이메일 발송 기능목표 3: 테스트 과정 자동화실패한 도전 과제 및 문제도전 과제:과제 1: MSA 구현하기과제 2: AutoScaling의 느린 적용과제 3: DB replication, readonly 구현 문제 및 이슈:문제 1: 서버 분리까진 성공했으나 messageque의 learning curve로 인해서 쿠키의 형태로 넘겨주려고 했음쿠키를 직접 넘겨줄 경우, cors 에러가 발생하여 직접 넘어가지 않았음.약식으로 주소로 쿠키를 넘겨주고, i.. 2024-04-29) DB Connection pool 검색 오늘은 DB Connection Pool에 대해 공부했다. 이 개념은 여러 클라이언트가 데이터베이스와 상호 작용할 때 성능을 향상시키고 자원을 효율적으로 사용하는 데 중요한 역할을 한다는 것을 알게 되었다.먼저, DB Connection Pool이 무엇인지부터 이해했다. 데이터베이스 연결은 생성하는 데 많은 시간이 걸리며 자원을 소비한다. 만약 각 클라이언트가 요청할 때마다 새로운 연결을 생성하고 종료한다면 시스템의 성능이 크게 저하될 수 있다. DB Connection Pool은 이러한 문제를 해결하기 위해 미리 일정 수의 데이터베이스 연결을 만들어 두고, 필요할 때 재사용하도록 한다. 공부를 하면서 Connection Pool의 주요 이점에 대해 알게 되었다. 첫째, 성능 향상이다. 연결을 미리 만들.. 2024-04-22) 동시성 이슈 공부 대부분의 서비스들의 경우 동시성 문제가 발생하지 않지만, 한정된 자원에 신청하는 티케팅, 좌석 예약 등의 서비스의 경우 필연적으로 다수의 사람이 하나의 자원을 얻으려고 하게 된다. 그렇기 때문에 db에 같은 부분에 값을 변경하려는 요청이 들어오려고 하게 되고, 이는 곧 데드락과 같은 교착상태를 생성하여 프로그램의 성능을 저하시킨다. 그렇기에 이 부분에 대하여 우선 순위를 정하게 하여 사람들이 접근할 수 있도록 해야되는데, 그 기법을 spring에서는 보통 락 이라고 한다. 전공때 배웠던 지식으로는 이를 해결하기 위한 방법으로 뮤텍스, 세마포어를 제시했었는데, 뮤텍스는 단일 자원에 대하여 접근을 제한하는 것이라면 세마포어는 자원에 여러명이 접근 가능하되, 접근 가능한 수를 제한하는 기법이었다. spring.. 2024-04-19) 멀티스레드 공부 오늘은 멀티스레딩에 대해 깊이 있게 공부하게 되었다. 멀티스레딩은 프로세스 내에서 실행되는 가장 작은 실행 단위인 쓰레드를 이용하여 한 프로세스의 자원을 최대한 활용하는 기술이다. 멀티스레드를 사용하면 동일한 프로세스 내에서 자원을 공유하지만, 여러 작업을 독립적으로 병렬로 처리할 수 있다. 이는 특히 내가 현재 구현하고 있는 서비스에서 유용하게 적용될 수 있다.내가 구현 중인 서비스는 다음과 같은 단계로 구성된다:로그인 -> 메인 페이지 -> 검색 -> 좌석 선택 페이지 -> 좌석 예약(경쟁) -> 결제여기서 동시성 문제가 발생할 수 있는 경쟁 부분을 제외하고, 멀티스레드를 적용하면 성능과 응답성을 향상시킬 수 있을 것이다. 특히 로그인, 메인 페이지, 검색, 좌석 선택 페이지에 멀티스레드를 적용하는 .. 2024-04-18) 로드밸런싱 공부 대용량 트래픽을 처리하기 위해서 결국 로드밸런싱을 적용하게 될 것이라고 생각하게 되었고, 잠시 시간이 남게 되어 공부한 내용을 블로그에 작성하게 되었다. 적용방법 자체는 생각보다 어렵지는 않았는데, 아마도 AWS에 기본 구성이 탄탄해서 그런게 아닐까? 생각된다.하지만 결국 로드밸런싱이 적용된다는 것은 여러개의 인스턴스가 기본적으로 실행된다는 걸 의미하는 것일테고, 매달 사용시간인 750시간을 훌쩍 초과하게 되어 요금이 부과될 것이라고 생각하니 서버 가동 계획을 잘 구성해야겠다고 생각했다.1. 로드 밸런싱 적용 이유:단일 서버의 한계: 단일 서버는 트래픽이 증가할 경우 과부하로 인해 성능 저하나 다운타임이 발생할 수 있다.부하의 분산: 로드 밸런서는 여러 서버에 트래픽을 분산시켜 안정적인 서비스를 제공할 .. 이전 1 2 3 4 5 6 7 ··· 19 다음
