본문 바로가기

STUDY

 (102)
5장 - 프로듀서의 내부동작 원리와 구현 파티셔너 카프카는 토픽마다 병렬처리를 위한 파티션을 가지고 있고, 이에따라 각 메시지가 어느 파티션에 들어가야 하는지 결정하는 로직이 필요하다. 이때 사용하는 것이 바로 파티셔너이다. 카프카는 별도의 파티셔너를 정의하지 않으면 기본적으로 라운드 로빈 알고리즘을 사용하는 파티셔너를 사용했었다. 그러나 2019년 부터는 이를 개량한 스티키 파티셔닝 알고리즘을 사용한다. 라운드 로빈 알고리즘은 메시지를 각 파티션에 순서대로 하나씩 넣는다. 이렇게 하면 각 파티션에 동일한 수의 메시지가 들어가게 되고, 자연스럽게 각 파티션을 가져가는 컨슈머도 동일한 부하를 가지도록 한다. 하지만 카프카의 기본 특징인 메시지의 배치 전송 때문에 라운드 로빈 전략은 약점이 존재한다. 위 이미지처럼 batch.size가 3으로 설정..
3장 - 카프카 기본 개념과 구조 카프카의 주요 구성 요소 주키퍼(Zookeeper): 카프카의 메타데이터를 관리 하고 브로커의 상태를 점검하는 어플리케이션 카프카(Kafka): 프로듀서와 컨슈머 사이에서 메시지를 중개하는 메시지 브로커 어플리케이션 브로커(Broker): 카프카가 설치되고 동작하는 서버 또는 노드 프로듀서(Producer): 카프카로 메시지를 보내는 클라이언트 컨슈머(Consumer): 카프카에서 메시지를 가져가는 클라이언트 토픽(Topic): 카프카 메시지를 구분하는 카테고리. 카프카 내에서 고유하다. 파티션(Partition): 병렬 처리를 위해 토픽을 나눈 것 세그먼트(Segment): 메시지가 저장된 브로커의 디스크 파일 메시지(Message) 또는 레코드(Record): 프로듀서가 전송하고 컨슈머가 가져가는 데..
카프카 환경 구성, peter 대신 내 이름 쓰기 https://nankisu.tistory.com/73 2장 - 카프카 환경 구성 AWS EC2 인스턴스 생성 총 7개의 Amazon-Linux EC2 인스턴스를 생성한다. 여기서 1개의 인스턴스는 ansible, 3개의 인스턴스는 주키퍼 클러스터, 3개의 인스턴스는 카프카 클러스터에 사용된다. 이때 인스 nankisu.tistory.com 이전에 책에 있는 내용을 실습하기 위한, 카프카 환경 구성에 관한 글을 포스팅 했다. 그런데 해당 실습 예제 peter-ansible, peter-kafka01~03, peter-zk01~03 처럼 peter 닉네임으로 각 인스턴스들의 호스트 네임이 붙어져 있다. 이를 kisu-ansible과 같이 내 닉네임으로 바꾸어서 환경구성하는 법을 찾아보았다. 실습 예제 코드..
2장 - 카프카 환경 구성 AWS EC2 인스턴스 생성 총 7개의 Amazon-Linux EC2 인스턴스를 생성한다. 여기서 1개의 인스턴스는 ansible, 3개의 인스턴스는 주키퍼 클러스터, 3개의 인스턴스는 카프카 클러스터에 사용된다. 이때 인스턴스의 보안규칙은 1. ssh 접속을 위해 22번 포트는 열어두고 2. 클러스터 내부 통신을 위해 VPC에서 오는 모든 포트를 열어두고 3. 이후 실습할 내용을 위해 0 - 65535 포트를 열어둔다. (교육용으로 실환경에서는 사용하는 포트만 열어야 한다.) DNS 설정 > sudo vi /etc/hosts 아래 내용 삽입 ////////////////////////////////////////////////////////////////////// {ec2 private ip} pet..
1장 - 카프카 개요 MSA의 등장 과거에는 하나의 어플리케이션에 모든 기능이 들어가있는 모놀릭 아키텍처가 대부분이었다. 따라서 모든 데이터의 흐름은 어플리케이션 안에서 이루어지고, 다른 어플리케이션과의 데이터 공유는 제한적이었다. 하지만 시대가 변하고, 최근에는 대부분의 어플리케이션이 마이크로서비스 아키텍처를 채택하고 있다. 마이크로서비스 아키텍처는 하나의 어플리케이션을 각각의 기능을 가지는 여러 서비스로 나누고, 이들을 결합하여 운영하는 구조이다. 따라서 서비스간의 활발한 데이터 공유가 이전보다 더욱 많아지고 중요해졌다. 문제발생 서비스간 데이터 공유를 한다는 것은 공통에 저장소에서 데이터를 사용하는 것(Reddis나 Oracle Database 같은 경우)일 수도 있다. 아니면 한 서비스에서 다른 서비스로 데이터를 전송..
교차 출처 리소스 공유 (CORS) : 개발자라면 한번은 보았던 것 동일 출처 정책(Same-Origin Policy) 사이드 프로젝트를 진행하다보면 자주 보는 것이 하나있는데 바로 CORS 에러다. CORS 에러는 브라우저의 동일 출처 정책(Same-Origin Policy)을 위반하면 발생하는 에러인데, 여기서 동일 출처란 프로토콜, 호스트(도메인), 포트가 모두 같은 것을 말한다. 'http://mypage:8080'에서 요청을 보낸다고 했을 때, 동일 출처 정책을 위반한 경우는 아래와 같다. https://mypage:8080/v1/api/product/list로 요청을 보낸 경우 > 프로토콜 불일치 http://yourpage:8080/v1/api/product/list로 요청을 보낸 경우 > 호스트(도메인) 불일치 https//mypage:8090/v1/api..
3. 스프링 배치: Job, JobParameter, JobInstance, JobExecution Job Job이란 개념적으로 스프링 배치가 수행할 하나의 작업 그 차체를 의미한다. "일별 판매 정산" 일괄처리 작업이 있다면 "일별 판매 정산"이 Job으로 만들어지는 것이다. Spring Batch의 객체로써 보면, 위와같은 모습이다. 이름, 재시작 가능여부, JobParametersIncremeter, JobParametersValidator를 가져올 수 있는 메소드. 그리고 Job을 실행할 메소드를 기본적으로 가지고 있다. 하위에는 이를 구현한 여러 종류의 Job들이 있다. JobInstance JobInstance란 Job에 JobParameters가 전달되어 만들어지는 실행가능한 논리적 작업 단위 객체이다. JobInstance에 실제 내부 동작을 위한 필드나 메소드는 존재하지않고, Job의 ..
2. 스프링 배치: 배치 테이블 스키마 배치 테이블 생성 스프링 배치는 실행된 작업마다 여러 요소(Job, JobParameter, Step...)들의 상태, 그리고 성공/실패에 관한 이력을 알아서 저장해준다. 개발자는 스프링 배치가 사용할 배치 테이블을 생성하고, DB 연결정보를 정의해주기만 하면 된다. 배치 테이블을 생성하기위한 DB 스키마는 소스에 포함되어있으니, 사용하는 DB에 맞는 스키마을 찾아서 사용하면 된다. 메타 테이블 종류 batch_job_instance: 실행된 배치의 JobInstance 정보가 저장되는 테이블 JOB_INSTANCE_ID: 실행된 JobInstance의 id VERSION: 배치 테이블의 낙관적 락 전략을 위해 사용되는 데이터 JOB_NAME: 실행된 Job의 이름 JOB_KEY: JobParameter..

티스토리툴바