개발자 바곰

DU-IT는 4코어 16GB 미니PC 한 대로 운영 중인 간호 행사 관리 플랫폼입니다. 서비스가 돌아가고 있으니까 특별한 문제는 없었는데, 문득 궁금해졌습니다. 이 서버가 실제로 얼마나 버틸 수 있는지.운영하면서 한 번도 측정해본 적이 없었습니다. 사용자가 늘어날 때 어디서부터 무너질지, 얼마나 버틸 수 있는지 모르는 채로 운영하고 있었습니다. 실서비스에서 성능 최적화를 직접 경험해보고 싶기도 했고, 나중에 사용자가 늘어날 때를 대비해두고 싶기도 했습니다.그래서 부하 테스트를 돌려봤습니다. 요청이 서버에서 어떤 경로를 거치는지 따라가고, 데이터로 병목을 찾고, 설정 튜닝만으로 동시 접속 2,000명까지 끌어올린 과정을 기록했습니다.1. 트래픽이란 무엇인가"대규모 트래픽"이라는 말을 들으면 네이버 실검이나..

프로토타입 이후 행사 목록 조회 V2, 인덱스 추가, 커서 페이지네이션 전환 같은 변경이 생길 때마다 해당 기능 위주로 테스트를 작성했습니다. 그러다 서비스가 커지면서 테스트 레버리지를 본격적으로 올리기로 했고, Kotlin + REST API 환경에서 테스트 인프라를 구축하면서 겪은 시행착오와 배운 것들을 정리합니다.1. 들어가며프로젝트 초반에는 기능 하나 만들면 Swagger 열어서 직접 호출해보고, 응답 잘 오면 다음 기능으로 넘어가는 식이었습니다. 운영을 시작하고 사용자가 늘면서 행사 목록 조회 API를 V2로 새로 만들고, 성능을 위해 인덱스를 추가하고, 오프셋 페이지네이션을 커서 기반으로 전환하는 등 변경이 쌓였는데, 이때부터 변경되는 기능 위주로 테스트를 붙이기 시작했습니다.근데 이렇게 부분..

1. 상황Du It 서비스는 MVP 개발 당시 모든 API를 로그인 필수로 설계했습니다.앱 출시 후 기획이 변경되면서 비로그인 사용자도 행사를 조회할 수 있게 됐는데, 깜빡하고 수정 없이 계속 서비스하여 조회수 증가 API의 인증 정책이 그대로인 상황이었습니다.문제는 웹 랜딩 페이지에서 발생했습니다. 웹에서는 비로그인 상태로 행사 상세를 조회하는데, 조회수 증가 API가 인증을 요구하니 호출이 실패하는 상황이었습니다. 당시 임시방편으로 웹 랜딩 페이지에 어드민 로그인 이후 받은 토큰을 사용해서 조회 증가 API를 호출했습니다. 이번 포스팅은 인증 정책을 변경하고 동시성 이슈를 해결한 경험에 대해 적어보겠습니다.인증 정책 변경 자체는 간단하니 넘어가고, 이번 포스팅에서는 비로그인 허용 시 발생할 수 있는 ..

1. 상황운영중인 서비스에서 간혈적인 522 Connection Timed out 에러가 발생하기 시작했습니다. 그리고 전반적으로 요청 응답 속도가 느려졌으며 특히 서버를 통한 Swagger 접속 시 522에러가 발생하거나 접속에 오랜 시간이 걸리는 이슈가 발생했습니다.이번에는 해당 이슈의 원인을 찾고 해결 방법을 찾아보겠습니다.2. 원인 찾기현재 통신 구조는 위와 같습니다. 클라이언트에서 요청을 보내면 cloudflare dns 서비스를 통해 서버와 통신하며 내부적으로 proxy를 서버로 돌려줍니다. 그러면 iptime 공유기로 요청이 들어오면 이후 내부적으로 설정한 port로 어플리케이션 인스턴스로 접근합니다.먼저 grafana 모니터링 대시보드에서는 특이사항이 발견되지 않았습니다. prometheu..

1. 상황현재 서비스의 일일 사용자가 70 - 100 명 정도를 생기고 새벽 시간대 외에는 사용자가 분포해있어 서버의 가용성이 중요해졌습니다. 하지만 기존의 배포 방식은 단순히 배포 방식을 자동화 시킨 방식이기 때문에 서버에서 새로운 버전으로 갈아끼는 동안 잠깐의 다운 타임이 생깁니다. 따라서 보다 다운 타임을 줄이기 위해 무중단 배포를 적용해보도록 하겠습니다. 2. 무중단 배포란?기존의 배포 방식은 서버에서 가동중인 서비스를 잠시 중단 시키고 새로운 서비스를 가동시키는 방식을 사용하는데 이때 잠깐의 다운 타임이 발생합니다. 이를 없애 사용자가 끊김 없이 서비스를 이용할 수 있도록하는 배포 전략이며 종류는 크게 3가지가 있습니다.2.1 Blue-Green블루를 구버전, 그린을 신버전으로 지칭하여 짧은 ..

1. 상황서비스 개선기 - 1.쿼리개선, 인덱스 추가저번 포스팅에서 주요 API인 행사 목록 조회의 처리 시간을 줄이기 위해 쿼리 최적화와 인덱스 튜닝을 진행했습니다. 복합 인덱스를 추가하고 불필요한 JOIN을 제거하여 조회 성능을 크게 끌어올렸죠.하지만 개선 작업을 진행하면서 근본적인 문제를 발견했습니다.현재 서비스는 Offset 방식의 페이징을 사용하고 있었습니다:// 기존 API 응답 구조{ "content": [...], "pageInfo": { "totalPages": 100, // 전체 페이지 수 "totalElements": 1000, // 전체 아이템 개수 "currentPage": 5 // 현재 페이지 번호}-- Offset 페이징의 쿼리 ..

주요 API인 목록 조회 API가 서버 응답 기준 1.1초가 소요됩니다. 그리고 앱 메인 화면에서 해당 API를 사용하여 데이터를 표시하는데 느린 API 속도 때문에 딜레이가 생겨 사용자 경험에 안좋은 영향을 주고 있습니다. 따라서 응답 시간을 줄여 사용자 경험을 높여보겠습니다.먼저 로컬 테스트를 위해 100만건의 더미 데이터와 함게 개선 작업을 진행하겠습니다. 이번 포스팅에서는 쿼리, 인덱스 튜닝을 통란 성능 개선을 시도하겠습니다. 캐싱을 통해 값을 임시 저장해 응답속도를 줄일 수 있지만 캐싱이 안된 데이터는 여전히 느린 응답을 받게 됩니다. 또 캐시 미스가 발생할 수도 있으니 쿼리와 인덱스를 수정하여 응답속도를 줄여보겠습니다.인덱스를 개선하기 전 현재 어떤 문제점이 있는지 확인해보겠습니다. 1. ..

1. 상황미니 피씨를 구매 후 개인 서버로 사용하있으며 여러 컨테이너를 올려놓고 사용중입니다.MySQL도 도커로 간단하게 올려놓고 사용하던 중 팀원한테 서버 오류가 발생한다는 연락을 받았습니다. Spring 로그를 보니 DB 연결 오류가 발생하길래 의아해하며 DB를 확인하니 테이블들이 싹 날라가있었습니다.... 혹시나 하는 마음으로 데이터 저장 위치로 가니 RECOVER_YOUR_DATA파일이 생겨있고 내용을 보니 복구를 원하면 비트코인을 달라는 내용이었습니다MySQL 컨테이너가 내려가있지는 않고 테이블과 데이터만 날라간 상황이라 서버 자체가 뚫린것보다는 DB가 뚫린 상황이라 생각해 조취를 취해봅시다!DB에 데이터는 복구보다는 다시 기초 데이터를 삽입하는 작업으로 대체했습니다.... 2. 보안 취약점DB..

1. 참가 이유정션 해커톤이 2번째 해커톤입니다. 첫 번째는 무박 2일 해커톤으로(이름은 아이디어톤 이었습니다) 개인 참가 후 추최측에서 팀을 랜덤으로 배정해주는 시스템이었고 해당 해커톤의 경험이 굉장히 별로여서 그 동안 구름 해커톤을 제외한 다른 해커톤에는 관심이 없었습니다.구름 해커톤에 몇 번 떨어지고 부트캠프 기간도 끝나고 지인의 프로젝트에 합류하면 취직 기간을 보내던 중 부트캠프 디스코트방에서 정션 해커톤에 대해 알게됬고 글로벌 해커톤이면서 상금 규모도 굉장해서 관심을 갖게 됬습니다.그렇게 부트캠프 팀원, 전 프로젝트에서 함께한 앱 개발자, 부트캠프 팀원이 데려온 기획자 총 4명의 팀이 완성되었습니다. 2. 참가 신청참가 이유, 해커톤에서 활약할, 간단한 자기소개 등을 적어 제출했습니다. 개인적으..

이유매번 AWS Free Tier를 사용하며 성능이 항상 아쉬웠습니다. 그렇다고 성능을 높이거나 여러 인스턴스를 사용하면 결국 비용 문제가 발생하니 쿠버네티스도 편하게 학습하고 개발중인 서비스의 서버도 담당할 겸 미니 피씨를 사용해서 비용 걱정없이 사용하려고 결정했습니다. https://www.coupang.com/vp/products/7842887355?vendorItemId=89133683172&sourceType=gnb_cart_item_list GMKtec GMK G3 미니 PC 소형 데스크탑 인텔 12세대 코어 N100 WIN11 PRO - 미니PC | 쿠팡현재 별점 4.5점, 리뷰 105개를 가진 GMKtec GMK G3 미니 PC 소형 데스크탑 인텔 12세대 코어 N100 WIN11 PRO!..