분류 전체보기 (161) 썸네일형 리스트형 [230913] Scale-out 환경에서 Scheduler 중복으로 실행되는 문제 Scheduler 중복 실행 💬 Scale-out을 적용하고 보니 경매 시작, 경매 종료, 경매 시작 전 알림을 처리하기 위한 Scheduler가 각 인스턴스마다 실행이 된다는 것을 알았습니다. 이것은 불필요한 실행이 일어나게 했습니다. ✔ 문제 해결 고민 💬 실행되는 서버 Instance가 늘어나더라도 Scheduler는 한 번만 실행할 수 있는 방법이 없는지 고민했습니다. 고민해 본 바로 3가지 방법을 고려해 볼 수 있다고 판단했습니다. ➡ Scheduler를 위한 별도의 서버를 띄우는 것이었습니다. ➡ 일정 주기마다 Scheduler가 들어있는 jar를 실행하는 것이었습니다. ➡ Scheduler에 Lock을 걸어 먼저 실행된 것이 있다면 다른 Scheduler는 실행되지 않게 하는 것이었습니다... [230901] 간단한 화면 구현 간단한 화면 구현 💬 시연 영상을 위해 간단한 화면 구현을 해야했습니다. 별도의 Front 서버를 만들기보다는 기존 서버에 Thymeleaf을 사용해서 화면을 구성하기로 했습니다. HTML, JQuery, CSS, BootStrap5를 사용했습니다. ✔ Controller 추가 💬 제가 맡은 부분은 아이디어 쓰기, 아이디어 업데이트 부분이었습니다. 해당 페이지를 호출하기 위해 Controller를 생성하고 url에 연결 시켜주었습니다. @Controller @RequestMapping("/view") public class ViewController { @GetMapping("/pageWrite") public String ideaWritePage() { return "page/ideaWrite"; } .. [230830] 서버간 통신을 위해 Kafka 적용 Kafka 도입한 배경 💬 메인 서버와 SSE 서버가 분리되면서 서버 간 데이터를 전송하고 받을 수 있는 수단이 필요했습니다. 후보군으로 나왔던 것이 Redis와 Kafka였습니다. ✔ 결정 기준 아래와 같은 이유로 Kafka를 사용하기로 했습니다. 1. 입찰 데이터를 전송이 실패할 경우 재시도가 가능해야 했기에 데이터가 보존되어야 했습니다. ➡ Redis의 경우 데이터 전송 후 사라집니다. 2. 비동기식으로 처리가 되어야 하며, 읽기/쓰기가 빨라야 했습니다. ➡ Redis의 경우 다른 소비자에게 데이터를 보내기 전에 응답을 기다려야 합니다. 3. 이후에 Scale-out을 고려했을 때 병렬적으로 데이터를 가져갈 수 있어야 했습니다. ➡ Redis의 경우 병렬성을 제공하지 않는다고 합니다. Redis와 .. [230829] SSE 서버 분리하기 SSE 서버 분리 💬 기존 서버의 API를 응답 Latency를 낮추기 위해 SSE 서버의 분리가 필요했습니다. 그래서 기존 서버와 동일한 c5.large를 사용하여 SSE 서버를 하나 띄우기로 했습니다. ✔ 서버 분리 순서 1. SSE 코드를 위한 Repository 생성 및 코드 분리 2. AWS EC2 Instance(c5.large) 생성 3. SSE 서버 CI/CD 구축 ✔ SSE 코드를 위한 Repository 생성 및 코드 분리 💬 별도의 SSE 서버를 띄우기 위해 먼저 Repository를 생성하고 코드를 분리하기로 했습니다. 그리고 추가적으로 SSE에 필요한 설정 정보를 idea-rush-security Repository에 추가했습니다. GitHub - final-idea-rush/i.. [230828] 입찰 API 응답 Average Latency 속도 문제 입찰 API 응답 Average Latency 속도가 느림 💬 입찰 API 로직 개선 이후 Jmeter로 테스트를 진행했습니다. 테스트는 SSE 1500명 연결에 입찰 1분에 1만 건을 보내는 것이었습니다. 테스트 결과를 보니 평균적으로 Average Latency가 약 1.6초 정도가 나오는 것을 확인했습니다. Latency가 1초 이내에 왔으면 하기 때문에 문제의 원인을 확인해 보기로 했습니다. ✔ 문제 원인 가정 - 01 💬 SSE에서 이벤트를 클라이언트에게 보낼 때 For문을 돌게 됩니다. 1500명의 유저에게 각 입찰마다 데이터를 보내다 보니 이것으로 인해 속도가 느려진다고 가정을 해보았습니다. 그래서 실제로 맞는지 테스트를 해보았습니다. 1. SSE 1500명 연결, 1분 1만 건 입찰 요청,.. [ 230827 ] 37주차 회고 일주일 간 진행한 내용 1. 입찰 API 성능 테스트 3. 입찰 API 성능 개선 입찰 API 성능 테스트 [진행] 입찰 API 성능 테스트를 진행했다. EC2 Instance t2.micro 서버로 Jmeter를 통해 요청을 보냈다. 먼저 SSE를 연결을 했다. SSE 연결이 완료되는 것을 확인하고 입찰 API를 1,000건씩 늘리며 보냈다. 이후 Jmeter의 결과에 대한 정보와 netdata에 기록되는 CPU, Memory 정보를 저장했다. 그걸 서버에서 에러가 날 때까지 계속해서 진행했다. 그리고 여기에 대한 결과를 가지고 팀원과 이야기를 하며 어떤 방향으로 나아갈지 정했다. [생각] 입찰 API 성능 테스트를 해보는 것은 어렵지 않았다. 하지만 거기에서 만나는 여러 가지 에러들이 나를 힘들게 했.. [230827] 입찰 API 병목 현상 로직 수정 입찰 API 로직 개선 💬 입찰 API 로직에서 95%정도 차지하는 SSE를 통해 이벤트를 클라이언트로 전송하는 로직을 분리를 하기로 했습니다. ✔ 로직 수정 기준 1. SSE 전송은 순서가 보장이 되어야 했습니다. ➡ 입찰된 가격이 순서가 보장이 되지 않는다면 실시간 경매에 정상적으로 진행이 되지 않을 것입니다. ➡ 그동안 트랜잭션에서 걸린 비관적 락 때문에 순서가 보장되고 있었습니다. 2. SSE 전송이 분리가 되거나, 비동기로 이루어지도록 만들어야 했습니다. ➡ 병목을 해결하기 위해 트랜잭션 처리 시간이 줄어들어야 하기 때문입니다. ✔ 로직 수정 후보군 1. Java에서 제공하는 ExecutorService ➡ BlockingQueue를 통해 SSE 전송 순서를 보장해줍니다. ➡ 별도의 스레드를 생.. [230826] 입찰 API 병목 현상 로직 점검 입찰 API 로직 점검 💬 입찰 API에서 생기는 병목 현상을 해결하기 위해 로직을 확인했습니다. 로직의 중요 부분의 수행 시간을 측정하고 로그를 찍어서 확인했습니다. ✔ 로직 수행 시간 측정 로그 💬 Slf4j를 사용해서 로그를 출력했습니다. 하지만 화면에 출력된 로그는 DEBUG, ERROR, INFO 등 모두 찍혔습니다. 수행 시간만 별도로 확인을 하기 위해 INFO로 설정해 출력했으며, logback을 사용해 별도의 파일에 저장을 했습니다. 1. Dependency 추가 implementation ( 'ch.qos.logback:logback-classic:1.4.11', 'ch.qos.logback:logback-core:1.4.11', ) 2. logback.xml 작성 INFO ACCEPT .. 이전 1 2 3 4 5 6 7 ··· 21 다음
