서론로그 모니터링에 이어, 매트릭 모니터링을 구축하면서 그 과정에 대해 공유한다.로그 모니터링과 마찬가지로, 스프링 서버가 "HikariCP Shutdown"만을 남기고 죽는 일이 빈번했다. 그런데 서버가 죽어도 백엔드는 모르다가, 개발하는 프론트가 확인을 하고 문의하는 일이 여러번 발생하면서 매트릭 모니터링에 대한 필요성을 느끼고 이를 구축하기로 결정했다. 🤔 매트릭 모니터링 필요 이유 1. 서버가 다운되었을 때 즉각 대응할 수 있다.왜 필요해?클라우드 서버 메모리 부족 문제와 스키마 변경 시 운영, 개발 환경에 변경된 DDL 을 작성하지 않아 서버가 자주 다운되는 일이 있었다.이런 상황에서 백엔드 크루들은 모르고 즉각 대응을 해주지 못했다.뭐가 개선되지?이런 상황에서 매트릭 모니터링을 구축한다면 해..
서론LMS 3차 요구사항으로 모니터링 대시보드 구성이 주어졌다.우리는 CloudWatch를 통해 EC2 인스턴스에 대해 모니터링 대시보드를 구성했었는데, 처음에는 이것만으로도 충분하다고 생각했었기 때문이다. 그런데 개발 서버에서 500 에러가 계속해서 발생하고 프론트엔드 팀원에게 문의를 받아야 대응할 수 있는 상황이 빈번하게 발생했다.따라서 로그 모니터링에 대한 필요성을 느끼고 이를 구축하기로 결정했다. 🤔 로그 모니터링 필요 이유 1. 직접 EC2 서버에 접속하지 않고도 로그를 확인할 수 있다.왜 필요해?일단 모니터링을 구축하기 전, 로그 프레임워크을 적용하면서 스프링 서버의 로그를 파일로 저장하고 있었다.해당 로그 파일은 EC2 인스턴스 내의 파일 시스템에 저장이 되는데, 이를 확인하기 위해서는 E..
애플리케이션 개발을 하다보면 데이터베이스 스키마 변경은 매우 빈번하게 일어납니다.새로운 기능 추가, 성능 최적화, 또는 데이터 모델 개선 등 다양한 이유로 데이터베이스 구조를 수정해야 하는 상황이 발생합니다. 마이그레이션 도구를 사용하지 않았을 경우우리는 개발, 운영 환경에서 ddl-auto: none 또는 validate 로 옵션을 지정하곤 하는데요.이는 애플리케이션 실행 시 Hibernate가 자동으로 데이터베이스 스키마를 변경하지 않도록 하기 위함입니다. 이러한 접근 방식은 데이터의 안정성을 보장하지만, 동시에 몇 가지 불편한 점이 있습니다. 수동 DDL 실행: 테이블 추가, 컬럼 변경 등이 필요할 때마다 개발자가 직접 해당 환경의 데이터베이스에 접속하여 DDL 문을 실행해야 합니다.버전 관리의 ..
우리는 로그를 통해 사용자의 요청을 추적하고 디버깅합니다.만약, 수많은 동시 요청이 발생하는 환경에서는 각 요청에 대한 로그를 추적하고 구분하는 것이 어려울 수 있습니다.Tomcat을 비롯한 대부분의 서블릿 컨테이너는 Thread를 요청마다 생성하는 것이 아니라, Thread Pool을 만들어두고 요청이 들어올 경우 Thread를 재사용하기 때문입니다.쓰레드풀 재사용, 무엇이 문제냐?때문에 단순히 Thread 이름으로 로그를 찍게 되면 Thread 이름이 중복된 요청이 발생할 수 있습니다.만약 에러가 발생했고 상황을 파악하기 위해 로그를 추적할 때, Thread 이름으로 동일한 요청인줄 알고 디버깅하면,,, 헤매는 시간에 더해서 빠른 시간 안에 적절한 대응 이 어려워지는 사태로 이어질 수 있습니다. 때문..
발단현재 저희 프로젝트 코드잽에서는 500대 에러가 5분 동안 10번 이상 발생할 경우 그라파나의 알림 기능을 통해 다음과 같이 문제 노티를 받습니다. 로그 모니터링을 구축하면서 생각보다 500대 에러가 자주 발생되는 것을 파악할 수 있었습니다. 500대 에러가 자주 클라이언트 또는 사용자에게 노출될 경우, 서버에 대한 신뢰가 떨어질 수 있다고 생각되기 때문에 빠른 처리가 필요하다고 생각합니다. 따라서 지속적으로 발생하는 에러의 원인이 무엇인지 확인했는데요. 그렇게 확인한 모든 에러가 NoResourceFoundException였습니다. 사실 처리한 줄 알았던 NoResourceFoundException사실 모니터링을 구축하기 전부터, NoResourceFoundException 가 자주 발생된다는 사..
코드잽에서 3차 스프린트 요구사항에 맞게 로그 프레임워크를 사용하기로 했다.또한 로깅 전략에 대해 고민하였는데, 그 과정에 대해 기록하고자 한다.백엔드 로깅 전략로깅 고려한 사항먼저 로깅에 대해 고려한 사항은 아래와 같다.로깅 프레임워크 중 어떤 것을 사용할 것인가어떤 로그를 남길 것인가환경별 로깅 레벨 정하기어떻게 로그를 관리할 것인가1. 로깅 프레임워크 중 어떤 것을 사용할 것인가로깅 프레임워크에는 주로 사용되는 Log4j, Logback, log4j2 이 3가지에 대해 조사하였고, 결과적으로는 로그백을 채택하기로 하였다.Log4j고려하지 않음지원 중단보안 취약점에 대해 이슈가 있었음성능적으로도 가장 좋지 않음Logbackspring에서 디폴트 로깅 시스템인 로깅 프레임워크별도의 추가 의존성 없이도 ..
프로그램 개발 시, 우리는 우리의 예상대로 동작하지 않는 수많은 상황을 마주치게 됩니다.그중에서도 예외 발생 시, StackTrace를 통해 디버깅을 하곤 하는데요. StackTrace를 더 잘보기 위해 StackTrace에 대해 알아봅시다!Java 예외는 어떻게 터질까?JVM은 예외가 발생했을 경우, 예외를 처리할 수 있는 try-catch 블록을 찾습니다.try-catch 블록을 사용하여 코드 내에서 명시적으로 처리되지 않을 경우, 예외는 전파되는데요. 쓰레드 내에서 처리시킬 try-catch 블록가 없어 끝까지 처리되지 않은 예외는 결국 스레드의 실행을 중단시키는 예외를 말합니다.해당 처리되지 않은 예외를 처리하기 위해 JVM은 아래의 Thread 클래스의 dispatchUncaughtExcep..
이 글을 통해 기본적인 인텔리제이의 디버깅 기능들을 알아볼 수 있었습니다. 이제까지의 내용으로 아마 어느정도는 자주 보았던 또는 예상했던 기능들을 사용하는 데에는 무리가 없습니다.하지만 흥미로운 기능들이 있어, 소개하고자 글을 작성하게 되었습니다. (맛있는 거 많다 ~) 이 글은 인텔리제이 기본 디버깅 기능들을 알고 계시다면 이전 편을 보지 않았어도 이해하기 충분하지만, 이전 편을 보았다고 가정하고 글을 작성하겠습니다. 프로그램에 끼어들어버리기다음 기능들은 말 그대로 실행 중인 프로그램에 흐름에 내가 끼어들어 영향을 주는 것들인데요.코드 상의 변경을 하지 않고도 메서드 실행 결과 등등을 변경해버리는 기능입니다.다시 Reset Frame사실 이전 글의 Reset Frame 부분을 보면서 궁금하셨을 지점이..
자바로 개발을 하게 되면 필수인 IDE가 있습니다. 바로 인텔리제이인데요.그 중에서도 인텔리제이의 Debugger Mode를 다 한번쯤 사용해본 경험이 있으실 겁니다. Debugger Mode를 쓸 때 저는 Breaking Point와 Step Over 버튼만 무지성으로 사용하곤 했었습니다.테코톡에서 디버그 라는 주제를 준비를 하면서 인텔리제이 디버거에 대해서도 잘 사용하고자 글을 작성하게 되었습니다! 기본적인 개념들은 알고 있다! 흥미로운 디버깅 기능을 알고 싶어!라는 분들은 여기로 이동해주세요 !디버깅 툴을 알아보기 전에 알아두어야 할 Run/debug configurations디버깅을 시작하기 전에 알아두어야 할 인텔리제이의 기능이 있습니다.바로 Run/debug configurations 인데요...
레벨 3 해커톤 중 에러를 마주쳤습니다.잘만 동작하던 코드였는데, 갑자기 컴파일에 실패했습니다.@Getter를 사용한 코드들에서 메서드를 찾을 수 없다는 에러였는데요. 사실 해당 에러는 이전에도 프로젝트를 했었을 때 몇번 봤었던 에러였습니다.항상 Annotation Processor라는 의존성을 추가하고 그저 넘어갔었는데, 이번 기회를 통해 정확하게 해당 Lombok Annotation Processor가 의미하는 바를 파악하기 위해 작성하게 되었습니다.Syntax tree 란먼저 Annotation Processor를 알아보기 전에 알아두어야 할 개념이 있습니다.Syntax tree에 대해서 먼저 알아두면 좋을 것 같은데요. Syntax tree는 Parse Tree라고도 불리는데요.Parse Tre..
