신비한 개발사전

시스템을 설계할 때 "high throughput, low latency"라는 표현을 자주 보게 된다. 모든 시스템은 높은 처리량과 낮은 지연 시간을 달성하기 위해 많은 노력을 기울이는데, 처음에는 이게 왜 어렵다는건지 이해하지 못했다. 짧은 시간 안에 더 많은 데이터를 처리할 수 있으면 그만큼 지연 시간이 줄었다는 뜻일 텐데, 뭐가 문제지? 여기서 내가 잘못 생각한 부분은 시간에 대한 해석이다. 처리량에서 표현하는 시간과 지연 시간을 같은 기준으로 생각한 것이다.처리량(throughput): 주어진 시간 단위(unit of time)에 처리할 수 있는 요청의 수 → TPS(transactions per second, 초당 트랜잭션 수)로 많이 표현한다지연 시간(latency): 요청 하나의 시작부터 끝..

간단한 콘솔 기반 자바 애플리케이션을 빌드해서 java -jar로 실행하려고 했을 때 일어난 일이다. "./build/libs/java-janggi-1.0-SNAPSHOT.jar에 기본 Manifest 속성이 없습니다." 오류 메세지가 뜨면서 애플리케이션이 실행되지 않았다. 이 한 줄 외에 다른 정보는 없었다. 무엇이 문제였나?우리가 코딩한 자바 애플리케이션은 JVM이 실행해준다. 이때 JVM은 애플리케이션의 entrypoint, 즉 진입점을 알아야 한다. 어느 클래스에 구현된 main() 함수를 실행시켜야 이 애플리케이션이 우리가 설계한 대로 동작할지 JVM은 알 수 없기 때문에, 우리가 명시적으로 알려줘야 한다. 그리고 그 방법은 이정표 역할을 하는 manifest 파일(MANIFEST.MF)에 Ma..

개요사용자의 출발지점에 따라 만날 장소를 추천해주는 모잇지 서비스는 다양한 외부 API를 사용하고 있다. 공공데이터포털의 OpenAPI로부터 철도 정보를 받아오고, LLM 모델에 장소 추천을 받기 위해 Gemini와 Perplexity의 API를 쓴다. 거기에 더불어 사용자들이 방문해볼 만한 장소를 보여주기 위한 Naver API까지.. 외부 API 호출로 시작해 또다른 외부 API 호출로 끝나는 로직이 구현돼있다. 외부 API는 우리가 제어하는 영역 밖이며, 응답하는 포맷 또한 제각각이다. 사용자 입장에서 예측하기 어려운 정책 변경도 무시할 수 없을 것이다. 외부와 통신하는 부분을 코어 비즈니스 로직에서 최대한 선명하게 분리해두고, 변동사항이나 응답 실패에 최대한 방어하거나 쉽게 갈아끼울 수 있도록 설..

어느날 같이 팀 프로젝트를 하는 프론트엔드 멤버로부터 서버가 504 에러를 응답한다는 얘기를 들었다. 504 Gateway Timeout 에러코드는 프록시나 게이트웨이 역할을 하는 서버가 자신의 upstream 서버(우리 프로젝트로 보면 스프링 앱 서버)로부터 응답을 받지 않을 때 발생할 수 있다. 최근데 배포한게 없었어서 서버 인스턴스가 잘 돌아가고 있어야 할 텐데, 갑자기 504가 뜨기 시작했다. 로그를 확인해보니 DB를 돌리는 인스턴스로부터 응답이 없었다. 그동안 스프링, DB 구분 없이 우리가 구축한 모든 EC2 인스턴스의 상태가 자주 다운되곤 했었는데, 개선점을 찾아보기 위해 재부팅 후에 htop으로 인스턴스의 상태를 더 신경써서 확인해봤다. 메모리 사용 현황에 이상한 점이 보였다. DB 인스..

1편: https://dydk1215.tistory.com/266 지난번, 서버 애플리케이션이 돌아가고 있는 EC2 인스턴스에서 로그 파일이 없어지는 현상을 보고 auditd를 설치했었다. auditd는 디렉토리나 파일에 대한 변경사항을 감지해 어떤 이벤트가 발생했는지 파악할 수 있는 툴이다. auditd 설치 후 드디어 로그 파일 삭제 이력이 기록으로 남아서 그 결과를 정리해봤다. 이벤트 분석auditd 로그에 아래와 같은 이벤트가 여러번 발생했다. /usr/bin/git clean -ffdx 명령어가 실행됐고, 그 결과 backend 디렉토리는 물론 frontend 디렉토리까지 파일 삭제 작업이 진행됐던 것이다. 삭제된 파일마다 동일한 이벤트 메타 데이터가 로깅됐다. 아쉽게도 해당 명령어를 실행시킨..

CloudWatch에 한동안 잘 뜨고 있던 로그가 어느 순간을 기점으로 뚝 끊겨있었다. EC2에 접속해 확인해보니, 백엔드 디렉토리 안에 뒀던 logs 폴더가 사라져있었다. 로그 디렉토리가 어쩌다 사라졌을까? 당연하게도 팀원 중 누구도 디렉토리를 지우지 않았을 뿐더러, 지울 이유도 없었다. logs 외에 build 폴더도 없어졌길래 처음엔 빌드 실패 때문일지 의심했다. 우리 CI/CD 파이프라인은 ./gradlew clean build 명령어를 호출하고 있었기 때문에, clean으로 인해 build 폴더를 삭제한 상태로 빌드를 시작한다. 다만 빌드 과정에서 logs 폴더는 건드릴 일이 없으니, clean build가 원인일 리 없었다. 문제를 어디서부터 해결하면 좋을지 고민하다가, 파일이나 디렉토리에 대..

우여곡절 끝에 팀 프로젝트에 적용한 CloudWatch 지표와 로그 모니터링이 잘 돌아가고 있음을 확인하고, 더이상 인프라를 건드릴 일은 없을 거라며 뿌듯해하고 있을 때쯤이었다. 어느날 CloudWatch에서 운영환경 서버에 찍힌 로그들을 살펴보니 이상한 요청들이 기록돼있는 것을 알게 됐다. 당연히 우리가 구현한 API 중에 "/schar-papushak"이란 것은 없다. 팀원이나 일반 사용자 중 그 누구도 저런 엔드포인트에 접근하려고 하지 않았을 텐데, 접근 기록이 남아있다. 뿐만 아니라 "/assets" 나 "/v3" 등, 실제로 구현하진 않았지만 충분히 있을 법한 URL에도 접근하려 한 흔적이 있었는데, 요청한 URI와 호출 timestamp를 보고 누군가 자동화 프로그램으로 보낸 스팸 요청이라는 ..

자바 빌드 파일에 JUnit Jupiter와 JUnit Platform 의존성을 잘못 추가하면 생길 수 있는 문제와, 그런 문제를 해결한 과정을 통해 알게 된 것들을 정리해보려고 한다. 버전 불일치클론해온 모 프로젝트의 테스트 코드를 실행하자 콘솔창이 빨간 텍스트로 채워지면서 테스트가 시작도 못해보고 강제 종료되었다. 테스트 자체를 실행할 수 없는 문제는 지금까지 한 번도 겪어보지 못했는데, 심지어 콘솔창에 남는 오류 관련 정보가 없어서 따로 생성된 Test Summary 리포트 파일에 직접 들어가서 이슈를 파악해야 했다. Stack trace에는 아래와 같은 내용이 있었다.The following conflicting versions were detected:- org.junit.jupiter.api:..