데일리디벨롭

메트릭 (metric) 애플리케이션에서 발생한 메트릭을 그 순간만 확인하는 것이 아니라 과거 이력까지 함께 확인하려면 메트릭을 보관하는 DB가 필요하다. 이렇게 하려면 어디선가 메트릭을 지속해서 수집하고 DB에 저장해야 한다. 프로메테우스가 바로 이런 역할을 담당한다. 전체 구조 스프링 부트 액츄에이터와 마이크로미터를 사용하면 수 많은 메트릭을 자동으로 생성한다. 1.1 마이크로미터 프로메테우스 구현체는 프로메테우스가 읽을 수 있는 포멧으로 메트릭을 생성한다. 프로메테우스는 이렇게 만들어진 메트릭을 지속해서 수집한다. 프로메테우스는 수집한 메트릭을 내부 DB에 저장한다. 사용자는 그라파나 대시보드 툴을 통해 그래프로 편리하게 메트릭을 조회한다. 이때 필요한 데이터는 프로메테우스를 통해서 조회한다. 프로메..

서비스를 운영할 때는 애플리케이션의 CPU, 메모리, 커넥션 사용, 고객 요청수 같은 수 많은 지표들을 확인하는 것이 필요하다. 그래야 어디에 어떤 문제가 발생했는지 사전에 대응도 할 수 있고, 실제 문제가 발생해도 원인을 빠르게 파악해서 대처할 수 있다. 예를 들어서 메모리 사용량이 가득 찼다면 메모리 문제와 관련있는 곳을 빠르게 찾아서 대응할 수 있을 것이다. 세상엔 수 많은 모니터링 툴이 존재하며, 시스템의 다양한 정보를 이 모니터링 툴에 전달해서 사용하게 된다. 하지만 모니터링 툴이 작동하려면 시스템의 다양한 지표들을 각각의 모니터링 툴에 맞도록 만들어서 보내주어야 한다. 모니터링 툴에 지표 전달 예를 들어서 CPU, JVM, 커넥션 정보 등을 JMX 툴에 전달해야 한다면, 각각의 정보를 JMX ..

토픽 & 파티션 토픽은 카프카에서 데이터를 구분하기 위해 사용하는 단위이다. 파티션에는 프로듀서가 보낸 데이터들이 들어가 저장되는데 이 데이터를 레코드라고 부르며, 1개 이상의 파티션을 소유하고 있다. FIFO 구조와 같이 먼저 들어간 레코드를 컨슈머가 먼저 가져가게 된다. 일반적인 자료구조의 큐는 데이터를 가져가면 삭제 되지만 카프카에서는 삭제되지 않고, 파티션의 레코드는 컨슈머가 가져가는 것과 별개로 관리된다. 이런 특징때문에 토픽의 레코드는 다양한 목적을 가진 여러 컨슈머 그룹들이 토픽의 데이터를 여러번 가져갈 수 있다. 토픽 생성시 파티션이 배치되는 방법 파티션이 5개인 토픽을 생성했을 경우, 첫 번째 그림과 같이 0번 브로커부터 시작하여 round-robin 방식으로 리더 파티션들이 생성된다. ..

카프카 생태계 프로듀서: 토픽으로 데이터(메세지)를 발행한다. 컨슈머: 토픽에서 데이터(메세지)를 소비한다. 토픽: 목적에 따라서 생성된 데이터(메세지)이다. 스트림즈: 프로세싱을 통해서 토픽에 존재하는 데이터를 처리하고, 다시 토픽에 넣는 역할을 수행한다. 커넥트: 데이터 파이프라인을 운영하는 가장 핵심적인 툴이다. 소스 커넥트: 특정 DB나 AWS S3와 같은곳에서 데이터(메세지)를 가져와서 토픽으로 발행한다. 싱크 커넥트: 타켓 애플리케이션으로 데이터(메시지)를 소비한다. 주키퍼 카프카 클러스터를 운영하기 위해서 반드시 필요한 애플리케이션이다. 카프카 2.x 버전까지는 반드시 주키퍼가 필요하고, 3.x 버전부터는 주키퍼가 없더라도 운영이 가능하지만, 아직까지는 완벽하게 주키퍼를 대체하지 못하는 부분..

개발자가 애플리케이션을 개발할 때 기능 요구사항만 개발하는 것은 아니다. 서비스를 실제 운영 단계에 올리게 되면 개발자들이 해야하는 또 다른 중요한 업무가 있다. 바로 서비스에 문제가 없는지 모니터링하고 지표들을 심어서 감시하는 활동들이다. 운영 환경에서 서비스할 때 필요한 이런 기능들을 프로덕션 준비 기능이라 한다. 쉽게 이야기해서 프로덕션을 운영에 배포할 때 준비해야 하는 비 기능적 요소들을 뜻한다. 지표(metric), 추적(trace), 감사(auditing) 모니터링 좀 더 구체적으로 설명하자면, 애플리케이션이 현재 살아있는지, 로그 정보는 정상 설정 되었는지, 커넥션 풀은 얼마나 사용되고 있는지 등을 확인할 수 있어야 한다. 스프링 부트가 제공하는 액추에이터는 이런 프로덕션 준비 기능을 매우 ..

YAML 스프링은 설정 데이터를 사용할 때 application.properties 뿐만 아니라 application.yml이라는 형식도 지원한다. YAML(YAML Ain't Markup Language)은 사람이 읽기 좋은 데이터 구조를 목표로 한다. 확장자는 yaml, yml이다. 주로 yml을 사용한다. application.properties my.datasource.url=local.db.com my.datasource.username=hyuuny my.datasource.password=password my.datasource.etc.max-connection=1 my.datasource.etc.timeout=3500ms my.datasource.etc.options=CACHE,ADM..

외부 설정 사용 - Environment 스프링은 Environment를 활용해서 더 편리하게 외부 설정을 읽는 방법들을 제공한다. Environment @Value - 값 주입 @ConfigurationProperties - 타입 안전한 설정 속성 아래 예제를 통해 외부 설정을 읽는 방법을 알아볼텐데, 예제 코드는 이해를 돕기 위함이므로 실제 DB에 접근하지는 않는다. MyDataSource @Slf4j public class MyDataSource { private String url; private String username; private String password; private int maxConnection; private Duration timeout; private List optio..

[Spring] 외부설정과 프로필 1 외부 설정 - 커맨드 라인 옵션 인수와 스프링 부트 스프링 부트는 커맨드 라인을 포함해서 커맨드 라인 옵션 인수를 활용할 수 있는 ApplicationArguments를 스프링 빈으로 등록해둔다. 그리고 그 안에 입력한 커맨드 라인을 저장해둔다. 그래서 해당 빈을 주입 받으면 커맨드 라인으로 입력한 값을 어디서든 사용할 수 있다. CommandLineBean @Slf4j @RequiredArgsConstructor @Component public class CommandLineBean { private final ApplicationArguments arguments; @PostConstruct public void init() { log.info("source {}..

하나의 애플리케이션을 여러 다른 환경에서 사용해야 할 때가 있다. 대표적으로 개발이 잘 진행되고 있는지 내부에서 확인하는 용도의 개발 환경, 그리고 실제 고객에게 서비스하는 운영 환경이 있다. 개발 환경: 개발 서버, 개발 DB 사용 운영 환경: 운영 서버, 운영 DB 사용 문제는 각각의 환경에 따라서 서로 다른 설정값이 존재한다는 점이다. 예를 들어서 애플리케이션이 개발 DB에 접근하려면 dev.db.com이라는 url 정보가 필요한데, 운영 DB에 접근하려면 prod.db.com이라는 서로 다른 url을 사용해야 한다. 이 문제를 해결하기 위한 방법으로는 각 환경에 맞추어 실행 시점에 외부 설정값을 주입하는 방법이 있다. 배포 환경과 무관하게 하나의 빌드(여기서는 app.jar를 빌드) 결과물을 만든..

프로젝트를 처음 시작하면 어떤 라이브러리들을 사용할지 고민하고 선택해야 하는데, 여기에 버전까지 고민해야 한다. 더 심각한 문제는 각 라이브러리들끼리 호환이 잘 되는 버전도 있지만 잘 안되는 버전들도 있다는 점이다. 과거에는 이런 문제들 때문에 처음 프로젝트를 세팅하는데 상당히 많은 시간을 소비해야 했다. 스프링 부트는 라이브러리들을 편리하게 사용할 수 있는 다양한 기능들을 제공한다. 외부 라이브러리 버전 관리 스프링 부트 스타터 제공 라이브러리 직접 관리 스프링 부트가 편리한 라이브러리 관리 기능을 제공하기 전에는 직접 라이브러리를 하나하나 고르고 설정했었다. 웹 프로젝트를 하나 설정하기 위해서는 수 많은 라이브러리를 알아야 하고, 추가로 각각의 라이브러리의 버전까지 골라서 선택해야 한다. 여기서 눈에..