기술 블로그

안녕하세요, 매쓰랭 서비스의 백엔드 전반 개발중인 주니어 개발자입니다. 오늘은 네이버 oAuth Token Revocation 과정중에 생겼던 문제와 해결과정에 대해 얘기해보도록 하겠습니다. 문제 네이버는 Token Revocation에 세가지 API를 활용하도록

어느새 회사를 다니기 시작한지 3개월차에 접어들었습니다. 적응할새도 없이 주어지는 업무를 닥치는대로 해결해나가다 보니 어느새 시간이 이렇게 흘렀네요... 시간이 정말 빨리 지나가는 것 같습니다 ㅎㅎ; 짧은 기간이지만, 생각보다 많은 일을 했더라구요! 그냥 잊어버리기엔

G1 GC에 대해서 개력적으로 알아보도록 하겠습니다. G1GC G1 GC Grabage First Garbage Collector의 약자로써, Garbage가 많은 것부터 회수하는 Garbage Collector 라고 합니다. 왜이리 불리는진 천천히 알아가보도록 하겠

선박 데이터 사용량 집계 API 응답 속도 개선기 선박 데이터 사용량을 집계하는 API를 조회 기간을 한 달로 설정해 호출하면 응답에 약 4초가 걸려서 사용자 경험이 저하되는 문제가 있었습니다. 최적화 1. Backend Compression 원인 파악 응답의 병목점을 확인하기 위해 브라우저의 Timing 지표와 Grafana를 통해 응답 소요 시간을 ...

사내 관제 시스템에선 선박의 불안정한 위성 네트워크 환경 위에서도 작업의 안정적 전달을 위해 FSM을 활용하고 있습니다. 각 작업의 실행 상태에 따라 READY, RUNNING, SUCCESS, FAILED 4가지 상태로 나뉘며, 실행 중 발생한 예외에 따라 이후에 재

API 응답속도가 약 12초까지 지연되는 현상 영업지원팀 매니저님으로부터 시스템 화면 로딩속도가 너무 느리다는 문의를 받았다. 선박에 직접 호출하는 데이터라, 선박이 사용중인 위성 인터넷에 따라 느린게 당연한 현상이라 설명을 드렸지만, 이후 레거시 관제시스템이 2초

부하 테스트 중, 동일한 테스트임에도 실행 횟수가 많아질수록 TPS가 증가하는 현상을 확인할 수 있었습니다. 이번 글에선 JVM 내부의 어떤일로 이런 성능 차이가 생기는지 알아보겠습니다. 인터프리터와 JIT 1. Java로 작성된 언어는 런타임에 최적화 자바로 작성된

ngrinder 테스트 문제 증상 nGrinder로 API 부하 테스트를 진행하던 중, 총 요청 수가 약 28,000개를 넘는 테스트부터 에러가 발생했다. 테스트별 총 요청 수는 Vusers × Run Count(100)다. A 그룹은 총 요청 수가 28,000개

대용량 읽기 트래픽에서 성능 개선하기 이번 포스팅에선 대용량 트래픽을 점진적으로 가하여, 서버에서 발생하는 병목을 진단 및 분석, 개선한 과정을 기록합니다. 환경 세팅 리소스 격리 백엔드 서버는 Docker를 활용해 2 CPU, 2 GB 로 리소스를 제한해 측정했습니

이전 글에서 캐싱과 스레드 풀 튜닝을 통해 기존 TPS 대비 10배의 성능향상을 이뤄냈습니다. 글에선 다루지 않았지만, 동시 사용자가 늘어나며 몇가지 문제가 발생했습니다. 이번 글에선 어떤 문제가 발생했고, 어떻게 해결했는지 작성해보도록 하겠습니다. 1. 문제 파악

이번 글에서는 스케일 아웃을 통해 TPS 성능 향상을 이뤄낸 과정과 이 과정에서 발생한 문제들을 해결해낸 과정에 대해 작성하겠습니다. 문제 1. CPU 리소스 제한 이전 글에서 캐시 구조를 바꿔 동시 사용자가 늘어나도 메모리는 안정적으로 유지할 수 있게 되었습니다.