프로그래머스 코드 중심의 개발자 채용. 스택 기반의 포지션 매칭. 프로그래머스의 개발자 맞춤형 프로필을 등록하고, 나와 기술 궁합이 잘 맞는 기업들을 매칭 받으세요. programmers.co.kr 기존코드 class Solution { //시작 좌표 private int sx, sy; //이동 변화값 배열 private int[][] dir = {{-1, 0}, {1, 0}, {0, -1}, {0, 1}}; //노드 방문 기록 배열 private boolean[][] vis; //최소 시간 기록 변수 private int answer = Integer.MAX_VALUE; public void init(String[] maps) { for(int i=0; i

개요프로젝트 통합테스트로 상품 구매에 대한 테스트를 진행하던 중 멀티스레드 환경에서 상품 구매 기능에 접근할 시 레이스 컨디션이 발생하는 문제를 확인할 수 있었다. 이러한 이유로 상품 구매 기능에 동시성 제어가 필요할 것이라고 판단했고 동시성 제어에 필요한 기술의 의사결정, 기술 적용, 테스트 코드 작성 및 회고를 진행하고자 한다.  동시성 처리가 필요한 이유동시성 처리가 필요한 이유는 레이스 컨디션 발생에 있다. 레이스 컨디션이란 공유 자원에 대해 스레드가 동시에 접근해 값을 조작할때, 조작 순서가 보장되지 않아 잘못된 값이 저장되는 문제를 말한다. 레이스 컨디션의 가장 많이 알려진 예는 아래 코드라고 생각한다. 두 스레드가 동시에 count의 값을 증가시키려고 접근할때 count는 thread-sa..

성능 개전 전 부하테스트 리포트성능 개선 전 10명의 사용자가 30분간 지속적으로 요청을 보내는 환경에서 TPS가 1.2, MTT가 8000ms로 매우 비정상적인 매트릭을 보여주었다. 개발 단계에서는 데이터량이 많지 않았기 때문에 성능에 문제가 있다는것을 파악할 수 없었지만 데이터가 많아지면서 아래와 같은 비정상적인 매트릭을 측정할 수 있었다.   성능 개선 후 부하테스트 리포트상품 검색 기능에 대한 성능 개선을 완료하고 다시 한 번 부하테스트를 진행했다. 테스트를 진행한 서버의 스펙은 모두 t3.medium으로 동일하며 2vCPU와 4GiB 메모리를 가지는 EC2 환경에서 진행했다. 테스트는 30분 동안 N명의 사용자가 계속해서 요청을 보내는 환경으로 진행했고 사용자수를 10명, 100명, 1000명으..

EC2 내부의 자원 사용률을 보려면 직접 쉘스크립트를 작성해서 log를 찍어볼 수도 있지만, EC2에서 제공하는 CloudWatch를 사용하면 편하다. CloudWatch는 CPU Utilization의 경우 기본적으로 제공하지만 Memory 사용률을 측정하고싶다면 EC2 내부에 CloudWatch Agent를 설치하고 역할을 부여해주면 된다. 비용이 발생하긴 하지만 직접 쉘스크립트를 작성하는것보다 이 방법이 나은 것 같다. [ 참고자료 ] EC2에 CloudWatch Agent 사용하기 EC2에서 CloudWatch Agent를 설치하여 모니터링하는 것을 테스트해보겠습니다. medium.com

개요프로젝트 개발의 마무리 단계로 개발한 서비스에 대한 테스트를 진행하였다. 그동안 개발을 해오면서 JUnit과 Mockito를 이용한 통합 및 단위테스트는 많이 진행했지만 외부 도구를 사용해 실제 서버에 올라간 애플리케이션에 대한 테스트를 진행해본 경험이 없어 이번 기회에 테스트를 진행하고 그 과정을 정리해보고자 한다. 해당 글은 테스트를 위한 문서인 테스트 시나리오 작성에 대한 내용을 정리한 글이다.  테스트 시나리오 작성 관련 참고사항먼저 애플리케이션을 테스트할 수 있는 도구로 아파치에서 제공하는 Jmeter와 네이버에서 제공하는 nGrinder 중 한가지를 선정해야 했다. Jmeter의 경우 nGrinder보다 제공하는 기능이 많았기 때문에 더욱 세부적인 테스트가 가능할 것이라고 판단했지만, 테..

상품 검색 성능 문제 발견 및 테스트최종프로젝트에서 상품 검색 기능을 구현하고 프로젝트를 배포했을때, 아래와 같이 조회 속도가 매우 느린 문제가 발생했다. 포스트맨으로 응답 시간을 확인해 보았을때, 5000~6000ms의 비정상적인 응답시간을 반환하는것을 확인할 수 있었다. 클라이언트의 입장에서 2000ms를 초과하면 서비스를 제공하기 어렵다는 점을 기준으로 봤을때 확실히 개선이 필요한 부분이었다. 또한, 정확한 지표를 통한 성능 차이를 확인하기 위해 nGrinder로 부하테스트를 진행했다. 개선 전 TPS가 1.2, MTT는 8000ms로 매우 비정상적인 매트릭을 확인할 수 있었다. 반면, 메모리와 CPU 사용률은 안정적인 모습을 보여주고 있었는데 이를 통해 서버 외부의 문제일 가능성이 크다고 예측했다..

개요스포츠 경기 일정 및 결과를 제공하는 서비스인 최종프로젝트에서 스포츠 게임별로 사용자들이 실시간으로 소통할 수 있는 채팅 기능을 제공하고자 하였다. 네이버 스포츠, 아프리카TV 등과 같은 플랫폼에서 제공하는 실시간 채팅 기능을 모티브로하여 개발하였고 그 과정에서 기술 의사결정 및 개발 그리고 느낀점에 대한 회고를 기록하고자 글을 작성한다.  실시간 채팅 서비스 개발을 위한 기술 선정: 폴링과 웹소켓✅ Polliing 방식 사용 시 발생하는 서버 부하Polliing 방식은 지정한 인터벌마다 HTTP요청을 보내기 때문에 서버에 많은 부담을 줄 것으로 판단했다. WebScoket도 클라이언트와 연결을 유지하는데 비용이 발생하지만 HTTP도 Keep-Alive로 인해 일정시간 연결을 유지하는 비용이 발생한다..

nGrinder 설치 및 실행 (로컬 환경) nGrinder를 로컬에서 구동하는 이유는 처음 Docker를 이용해 테스트하려고 했으나 M1 환경을 지원하는 nGrinder Docker 이미지가 존재하지 않고 JDK 설정 등 Docker로 할 경우 호환성 문제가 많아 로컬 환경에 controller와 agent를 다운로드 받아 진행했다. 아래 nGrinder 공식 깃헙에서 controller war 파일을 다운받아 실행한다. GitHub - naver/ngrinder: enterprise level performance testing solution enterprise level performance testing solution. Contribute to naver/ngrinder development..

JPA 즉시로딩과 지연로딩 즉시로딩: Entity를 불러올때 연관된 Entity를 즉시 fetch해서 함께 불러온다. 지연로딩: 연관된 Entity가 필요할때 fetch해서 불러온다. //default 로딩 전략은 FetchType.EAGER @ManyToOne(fetch = FetchType.LAZY) @OneToOne(fetch = FetchType.LAZY) Entity 1개 조회할때 @Test @Transactional void findOne() { //fetchType이 EAGER일때: findOne을 호출하면 team도 함께 1차 캐시에 올라온다. -> query 총 1번 //fetchType이 LAZY일때: //findOne을 호출하면 user를 가져오기 위한 query 1번이 실행되고 fe..