Go Gradually - Repository

Java - classpath

우리가 특정 데이터를 JVM에 올리고 싶을 때, 이를 안정적으로 업로드할 "마법"이 필요해진다.이 예로는 키 파일과 같은 것들이 있다.만약 키를 평범한 상대경로/절대경로로 가져오고 있다면, 이는 현재 환경에 종속적인 빌드 결과가 된다.이때, 클래스패스라는 용어를 곧잘 접하게 된다. 클래스패스는 자바의 JVM 이 클래스를 로드할 때 사용하는 클래스로더와도 곧잘 얽히는데, 지금부터 이 클래스패스에 대해 빠르게 알아보자.1. 클래스패스란 무엇인가간단히 말하면JVM이나 컴파일러가 .class 파일과 리소스(예: .properties, .json, .xml)를 찾기 위해 검색하는 “경로 목록” 이다.Java 소스: *.java컴파일 결과: *.class실행 시, JVM은 필요한 클래스를 어디에서 읽을지 알아야 함..

개발자에게 가장 중요한 역량은 "이름 짓기"이다. 이름을 잘 지어둬야 나중에 읽을 때 빠르고 헷갈리지 않게 읽을 수 있기 때문인데, RabbitMQ 사용 시에는 이름을 지어야 할 부분이 세 군데나 있다. 생산자 선언ExchangeRouting Key소비자 선언QueueBinding key (routing key에 의존적)나는 딱히 이름 짓기에 재능이 없어서 매번 AI에게 도움을 많이 받는데, 적어도 이름을 짓는데 어느정도 규칙이 있어야 나중에 읽을 때 무리가 없기 때문에, 각각의 수행하는 역할과 책임에 집중해서 이름을 짓는 규칙을 정해본다.과거 scheduleMemberNestedDtoMap 이라는 해괴한 이름을 짓고 팀원에게 쓴소리를 들은적도 있었다... 기본적으로 위 세 요소는 각각 다음과 같은 역할..

주의: 본 내용은 DB 내용에 대한 기초 지식이 어느정도 있음(DB 스캔의 작동 방식)을 가정하고 작성되었습니다.DB는 백엔드에서 가장 중요한 역할을 수행한다.DB 성능은 연동하는 모든 서버 성능에 영향을 주기 때문에, DB에 존재하는 기능을 전문가 수준으로 깊이 이해할 수 있다면 이상적이겠지만 조금만 신경 써도 DB 성능 문제를 충분히 줄이거나 없앨 수 있다.인덱스 설계예상하지 못한 테이블 풀 스캔은 DB 성능에 좋지 않은 영향을 끼친다.이를 피하기 위해서 보통 인덱스를 사용하는데, 이때 인덱스를 제대로 알고 써야 원하는 성능 효율을 얻을 수 있다.인덱스는 조회 패턴을 기준으로 설계해라.단일 인덱스 vs 복합 인덱스의 차이를 고려해라선택도(Selectivity)를 고려해라가능하다면, 커버링 인덱스를 활..

본 내용은 주니어 백엔드 개발자가 반드시 알아야 할 실무 지식 도서를 참고하여 작성되었습니다. 주니어 백엔드 개발자가 반드시 알아야 할 실무 지식 | 최범균 | 한빛미디어 - 예스24실무에서 자주 겪는 다양한 문제를 효과적으로 해결하는 법서비스 환경에서는 커넥션을 닫지 않아 서버가 멈추고 외부 API의 지연이 전체 장애로 번지며 사소한 설정 실수가 사용자 전체에 영향www.yes24.com 성능 문제는 주로 DB나 외부 API를 연동하는 과정에서 발생한다.외부 API 호출에 블로킹/타임아웃이 발생하는가?힙 크기와 GC 방식에 적절한 최적화가 필요한가?OOM이 발생했는가?응답해야 하는 데이터의 양이 많은가?DB 커넥션 풀이 고갈되었는가?문제 예시순간적으로 모든 사용자 요청에 대한 응답 시간이 심각하게 느..

RabbitMQ는 메시지를 수신하고 전달하는 메시지 브로커이다.이 글은 다음 RabbitMQ 튜토리얼을 Java 버전으로 따라가 본 상태라고 가정합니다.따라서, 주요 API의 스프링에서의 사용법을 언급하며,스프링부트의 org.springframework.boot:spring-boot-starter-amqp를 사용하고 있다고 가정합니다.만약 RabbitMQ가 처음이시라면, 다음 글을 순서대로 따라가보며 내부 원리를 이해해보시길 권장드립니다.[RabbitMQ Java] 가장 간단한 프로듀서-컨슈머 사용해보기 [RabbitMQ Java] 가장 간단한 프로듀서-컨슈머 사용해보기원래 RabbitMQ 는 할 생각이 없었고, Kafka를 해보려고 했는데Kafka Definitive Guide의 내용이 너무 방대해서 ..

두 번째 튜토리얼에서 우리는 Work Queue를 사용하여 시간이 오래 걸리는 작업을 여러 워커(worker)에게 분산하는 방법을 배웠다. 하지만 어떤 함수를 원격 컴퓨터에서 실행하고 그 결과를 기다려야 한다면 어떨까?이는 조금 다른 이야기가 된다.이 패턴은 흔히 원격 프로시저 호출(Remote Procedure Call, RPC) 이라고 불린다. 이번 튜토리얼에서는 RabbitMQ를 사용하여 RPC 시스템(클라이언트와 확장 가능한 RPC 서버) 을 만들어보자.분산할 만한 시간이 오래 걸리는 작업은 딱히 없으므로, 임의로 피보나치 수를 반환하는 단순한 RPC 서비스를 예제로 구현할 것이다.클라이언트 인터페이스RPC 서비스 사용 방식을 보여주기 위해 간단한 클라이언트 클래스를 만든다.call이라는 메서드..

이전 튜토리얼에서는 로깅 시스템을 개선했다.단순히 브로드캐스팅만 가능한 fanout exchange 대신 direct exchange를 사용하여 선택적으로 로그를 받을 수 있도록 했었다. direct exchange를 사용함으로써 시스템이 개선되었지만, 여전히 한계가 존재한다.바로 여러 기준을 기반으로 라우팅할 수는 없다는 점이다.우리의 로깅 시스템에서는 심각도(severity)뿐 아니라 로그를 발생시킨 소스(source)에 따라서도 구독하고 싶을 수 있다.이 개념은 Unix의 syslog 도구에서 익숙할 수 있다.syslog는 심각도(info/warn/crit...)와 facility(auth/cron/kern...) 모두를 기준으로 로그를 라우팅한다. 이를 지원하는 기법이 바로 토픽(Topic)이다..

이전 튜토리얼 에서는 간단한 로깅 시스템을 구축했다. [RabbitMQ Java] Pub-Sub 모델, 그리고 Exchange이전 튜토리얼 에서는 Work Queue를 생성했다. [RabbitMQ Java] Work Queue 직접 만들어보기와 메시지의 분배 방식이번 튜토리얼에서는 시간이 많이 걸리는 작업을 여러 작업자 간에 분배하는 데 사용할 Wodev.go-gradually.me이를 통해 로그 메시지를 여러 수신자에게 브로드캐스트할 수 있었다. 이 튜토리얼에서는 여기에 기능을 추가해볼 것이다.바로 메시지의 일부만 구독할 수 있도록 하는 것이다.예를 들어, 디스크 공간을 절약하기 위해 중요한 오류 메시지만 로그 파일에 저장하면서도 모든 로그 메시지를 콘솔에 출력할 수 있다.바인딩이전 예제에서는 이미 바..

이전 튜토리얼 에서는 Work Queue를 생성했다. [RabbitMQ Java] Work Queue 직접 만들어보기와 메시지의 분배 방식이번 튜토리얼에서는 시간이 많이 걸리는 작업을 여러 작업자 간에 분배하는 데 사용할 Work Queue(작업 큐)를 만들어 보자. Work Queue(Task Queue)의 핵심 아이디어는 리소스 소모가 많은 작업을 즉시dev.go-gradually.meWork Queue의 기본 가정은 각 작업이 정확히 하나의 워커에게 전달된다는 것이다.이번 파트에서는 ​​완전히 다른 작업을 수행할 것이다.바로, 하나의 메시지가 이를 구독한 여러 컨슈머에게 메시지를 전달하는 형태이다.이 패턴을 "Pub/Sub"이라고 한다. 즉, 다음과 같다.- 생산자/소비자 모델은 하나의 메시지가 하..

이번 튜토리얼에서는 시간이 많이 걸리는 작업을 여러 작업자 간에 분배하는 데 사용할 Work Queue(작업 큐)를 만들어 보자. Work Queue(Task Queue)의 핵심 아이디어는 리소스 소모가 많은 작업을 즉시 실행하고 완료될 때까지 기다리는 것을 방지하는 것이다.먼저, 우리는 이어질 작업이 나중에 수행되도록 작업을 예약시킨다.또한 우리는 그 작업을 메시지로 캡슐화하여 큐에 보낼 것이다.백그라운드에서 실행되는 worker 프로세스가 각자 작업을 팝(pop)하고 최종적으로 작업을 실행한다.여러 worker를 실행하면 작업이 작업자 간에 공유되도록 만든다.이 개념은 짧은 HTTP 요청 창 동안 복잡한 작업을 처리하는 것이 불가능한 웹 애플리케이션에서 특히 유용하다.준비 작업이 튜토리얼의 이전 부..