반응형

1. 서론

이번 포스팅에서는 Clean Code에 대해 공부한 내용을 공유하고자 합니다.

책을 읽으며 제가 느낀 Clean Code는 아래와 같습니다.

 

  • readability가 좋은 Code
  • 성능 & 안전을 고려한 Code
  • 테스트 Code

이번 포스팅에서는 readability가 좋은 Code 부터 포스팅하도록 하겠습니다.

 

2. readability가 좋은 Code

 

readability 는 코드의 성능부분에서 잘짜는것과는 별개입니다.

 

readability를 좋은 코드의 이점은 아래와 같습니다.

 

  1. 반복이 가능한 Code 생성
  2. 중복이 없는 Code 생성
  3. 불필요한 Code 제거

Clean Code 책의 readability 관련부분은 아래와 같습니다.

 

1) 클래스, 메소드, 변수에 대해서 의도있는 이름 사용

 

naming만 잘되어 있어도 어떠한 책임을 가지고 있는 클래스인지 어떠한 일을 수행하는 메소드인지 알게됩니다.

이것은, 남의 코드를 분석 혹은 재빨리 파악해야할 경우 매우 유용하며 잘짠 코드라고 할 수 있습니다.

아래와 같은 예를 들 수 있습니다.

boolean validationResult = validateProduct(product);

위에는 상품의 validation을 수행하는 코드입니다.

validationProduct 메소드에서 무슨일이 일어나는지 보지 않아도,

상품을 받아 validation 수행 후 boolean 타입의 결과값을 주는것을 알 수 있습니다.

 

2) 소문자 L, 대문자 O의 사용 자제

 

소문자 L은 숫자 1과 비슷해 보이며, 대문자 O는 숫자 0과 비슷해보입니다.

이런경우 code convention에 맞지 않더라도 대문자 L, 소문자 o을 쓰시는게 더욱 가독성이 좋습니다.

아래와 같은 예를 들 수 있습니다.

long count = 123456L;

long형의 값 뒤에 소문자 l이 아닌 대문자 L을 붙이는것이 더욱 가독성이 좋은것을 볼 수 있습니다.

 

3) 클래스 - 명사구, 메소드 - 동사구 사용

 

클래스는 행위를 할 수 있는 물체 혹은 사람의 개념을 담아냅니다.

그렇기 때문에 동사구보다는 명사구를 사용하여 명확한 의미를 전달하여야 합니다.

아래와 같은 예를 들 수 있습니다.

Customer, Seller - O
Attack, Send - x

반대로, 메소드는 행위를 의미하기 때문에 동사구를 사용합니다.

customer, seller - X
attack, send - O

 

4) 함수는 작게, if while 문은 한줄로!!

 

개발을 하다보면 한 코드가 방대해질때가 있습니다.

이 경우, 메소드로 분리하여 사용해야 합니다.

예로, 이미지를 다운받아 validation을 거쳐 업로드하는 일련의 과정이 있습니다.

위 일련의 과정이 한 메소드에 있다면, 매우 보기 힘든 코드일 것입니다.

하지만, 아래와 같이 메소드를 나누어 호출하는 형태로 변경하면 어떨까요?

  • download
  • validate
  • upload

일련의 과정이 메소드명만으로도 명확하게 무슨일을 하는지 볼 수 있습니다.

if, while 문과 같은 조건문도 동일합니다.

아래와 같이 if문에서 메소드를 호출하여 boolean을 반환받는다면 깔끔한 코드가 될 것입니다.

if( validate(image) )

 

5) 코드는 위에서 아래로 규칙을 가지게 해야한다.

 

메소드안에서 메소드를 호출하는 경우가 있습니다.

이런경우, 의미적으로 상하 관계를 갖기 때문에 코드 또한 위에서 아래로 하는것이 좋습니다.

아래는 한 예입니다.

public void a() {
    boolean result = b();
    return result;
}

private boolean b() {
    return true;
}

 

 

 

 

 

반응형

 

 

 

 

 

 

6) 함수인수로는 max가 2개!!

 

함수인수는 많으면 많을수록 가독성이 떨어지게 됩니다.

java의 경우 같은 데이터 타입이 있다면 첫번째, 두번째 인수의 의미도 알기 어렵습니다.

이를 100% 막을수는 없습니다.

단, 이러한 함수들을 무분별하게 만드는것을 최소화하기 위해 함수인수로는 max 2개라는 내용이 있습니다.

 

7) 출력인수는 배제

 

출력인수는 함수의 반환 값이 아닌 입력 인수로 결과를 받는 경우입니다.

아래와 같은 예가 될수 있습니다.

appendFooter(report)

아래는 report라는 객체에 값을 추가하는 메소드입니다.

위는 report에 추가하는지 report에 있는 내용을 추가하는지 명시적이지 않습니다.

이런 경우, 아래와 같은 방법으로 바꿀수 있습니다.

report.appendFooter()

report에 footer를 추가하는게 명시적으로 보입니다.

또한, 최근 DDD에 맞는 도메인 메소드 사용으로 봐도 무관합니다.

 

8) 오류 코드보다는 try-catch

 

이 부분은 오류를 회피하기 위해 if-else문으로 늘어진 형태의 코드에서

try-catch 블록으로 코드를 짜는게 더욱 명시적인것을 의미합니다.

이 경우, Exception을 custom하여 더욱 명시적인 Exception을 만들수 도 있습니다.

아래와 같은 Exception이 예시입니다.

FileSizeInvalidException

해당 예외를 내뱉으면 개발자는 바로 '아 파일 사이즈가 유효하지 않구나!' 라고 알 것입니다.

 

9) 한 함수에는 최대한 return이 하나만!!

한 함수에 한개의 출구만을 담으라는 내용입니다.

만약, 한 함수내에서 return이 여러번 일어나는 케이스가 있다면?

함수를 작게 쪼개면 가능합니다!!!

작게 쪼갠 함수들의 조합으로 하나의 return을 만드는 것이죠!!

아래는 한 예입니다.

public boolean validateProduct(Product product) {
    return validateProductName(product.getName()) && validateProductImage(product.getImage())
}

개발하다보면 위의 경우보단, return을 2~3개 쓰는게 더욱 명시적일때가 있습니다.

이런경우에는 과감히 return을 쓰시는게 맞다고 생각합니다.

Clean Code의 본의미는 코드가 간결하며, 유지보수에 좋은 이쁜코드를 짜기 위한 내용이기 때문입니다.
또한, 개발에는 정해진것이 없기 때문에 현재 제가 포스팅하는 Clean Code 책의 내용도 참고로만 보시면 좋습니다.

 

10) 주석

 

Clean Code 책에서는 아래와 같은 경우 주석을 다는것을 추천하고 있습니다.

 

  • 정보를 제공하는 주석
  • 의도를 설명하는 주석
  • 결과를 경고하는 주석
  • TODO
  • 중요성을 강조하는 주석

 

11) 개념은 빈행으로 구분

 

코드의 개념이 다르다고 생각하는 부분은 빈행을 추가하여 코드의 가독성을 높이는게 좋습니다.

 

아래의 예를 볼 수 있습니다.

private String resultVal = "result";
public String a() { 
	return resultVal;
}


private String resultVal = "result";

public String a() { 
	return "A";
}

 

12) 밀접한 코드는 세로로 밀집

 

위 11번과는 반대로 개념이 다른것은 빈행으로 구분하며, 개념상 밀접한것은 세로로 붙여 사용해야 한다는 의미입니다.

 

아래의 예를 들수 있습니다.

 

// good
private String ProductId;
private String ProductName;


// bad
private String ProductId;

private String ProductName;

 

 

 

13) 함수 변수는 사용하는 곳에 가장 가까운거리에 선언

 

클래스 인스턴스 변수의 경우에는 가장 최 상위에 배치합니다.

 

하지만, 특정 함수내에만 사용하는 변수는 함수의 가장 가까운 곳에 배치합니다.

 

이것 역시, 클래스 인스턴스 변수와 혼동을 방지하고 가독성을 증가키게 됩니다.

 

14) 클래스 인스턴스 변수간 세로로 거리를 두지 않는다

 

클래스 인스턴스 변수의 경우 세로로 거리를 두게되면 인스턴스 변수인지 아닌지 혼동이 오게됩니다.

 

이런것을 방지하고자, 세로로 빈행을 두지 않는게 관례적입니다.

 

 

15) 객체는 동작만을 제공하고 자료는 숨겨야한다

 

이것은 모두 알고 계신 캡슐화의 기본 내용입니다.

 

자신의 속성값은 숨기며, 메소드만을 통하여 상호 객체간 데이터를 처리한다는 의미입니다.

 

하지만, 최근 setter 역시 데이터를 변경가능하게 열어주는 동작으로 사용을 자제하고 있습니다.

 

 

16) 클래스의 변수 메소드 순서

 

자바의 code convention에 따르면 메소드 순서는 아래와 같습니다.

 

  1. static public
  2. static private
  3. public 인스턴스 
  4. private 인스턴스 

 

17) 클래스의 큰 메소드 -> 작은 메소드 -> 클래스 분리

 

처음 클래스, 메소드 설계가 어렵다면 먼저 기능우선으로 개발을 시작하자.

저의 경우에도 일단, 개발을 시작 후 기능 테스트가 통과된다면 코드 리팩토링에 들어갑니다.

 

위와 같이 개발을 하게되면, 클래스 내에 큰 메소드가 생성될 케이스가 있습니다.

 

이 경우, 리팩토링 시 메소드를 분리합니다. 분리를 하고 끝나면 안됩니다.

분리 후 개념이 분리되는지도 클래스를 전체적으로 살핍니다.

 

개념이 분리된다면 클래스를 나누어 각 클래스에 맞는 메소드로 분리합니다.

 

저는 예로 신규 상품, 변경 상품, 품절 상품에 대해 처리하는 메소드들이 한 Service 클래스에 있는것을

코드 리팩토링과 동시에 신규, 변경, 품절 클래스로 분리 후 메소드 분리를 동시에 진행하였습니다.

 

추가로 각 클래스를 핸들러 메소드 패턴을 통하여 가독성을 높이는 작업을 진행한 경험이 있습니다.

 

3. 마무리

이번에는 readability가 좋은 Code에 대해서 포스팅하였습니다.

다음에는 성능 & 안전을 고려한 Code에 대해 포스팅하겠습니다.

 

반응형

'Programming > CleanCode' 카테고리의 다른 글

(3) Clean Code - 테스트 Code  (0) 2020.03.01
(2) Clean Code - 성능 & 안전을 고려한 Code  (0) 2020.02.29
반응형

1. 서론

카프카 사용시 고려사항에 대해 포스팅을 진행하겠습니다.

실제로, 카프카를 운영 및 사용하게 된다면 고려할 사항들은 생각보다 많습니다.

그 중, 3가지 정도만을 추려 공유드리고자 합니다.

공유 드릴 내용은 아래와 같습니다.

  1. idempotent (멱등성) 보장
  2. produce 역전 가능성
  3. 카프카 성능

2. idempotent (멱등성) 보장

카프카는 pub-sub 구조입니다.

이 말은, sub 하는 입장에서 동일한 메시지를 한번이 아닌 여러번 처리할 수 있다는 얘기가 됩니다.

결국, consumer를 개발할 시 idempotent (=멱등성)이 보장되어야 합니다.

idempotent란 같은 input에 대해서는 항상 동일한 결과가 나오는 것을 의미합니다.

idempotent가 보장되지 않는다면 데이터가 꼬여버리는 현상을 맞이하게 될 것입니다.

 

 

 

 

 

 

반응형

 

 

 

 

 

 

3. produce 역전 가능성

이전 포스팅에서 partition이 1인 경우 메시지의 순서가 보장된다고 한적이 있습니다.

정확하게 말씀드리면 보장이 되지 않습니다.

그 이유는 아래 그림을 보며 설명해 드리도록 하겠습니다.

카프카는 내부적으로 producer에게 받은 메시지를 buffer에 저장 후, 차례대로 broker 서버의 disk에 write 하게 됩니다.

하지만, 이 buffer에 역전되어 들어가는 상황이라면

위 그림의 2번 메시지가 먼저 write하게 되며 아래그림처럼 저장이 됩니다.

 

2번 메시지가 1번 메시지보다 offset이 작아지게 되고 결국, 개발할 경우 항상 역전에 대해 고려를 해야합니다.

 

저의 경험을 공유드리자면, 저는 메시지를 sub하여 DB CUD를 치는 상황이었습니다.

이슈는 아래와 같은 방법으로 해결하였습니다.

 

  1. 메시지에 timestamp 값 추가.
  2. 메시지를 pollSize 만큼 가져와 sorting 혹은 merge 수행.
  3. DB 테이블에 version 칼럼을 추가하여 timestamp 값 기준으로 optimistic lock CUD 수행.

DB에 칼럼까지 추가한 이유는 poll 과 poll 사이에 역전이 된 메시지가 존재할 수 있기 때문입니다.

 

4. 카프카 성능

 

카프카는 메시지 유입 시, leader에 write 후 follower가 fetch write를 하게됩니다.

 

이때, fetch write시 카프카는 os에서 제공하는 shared page cache를 사용합니다.

 

shared page cache에는 최근 메시지를 저장하게 되고, follower는 이 cache 에 메시지가 없는경우 disk 접근하여 fetch write를 수행합니다.

 

또한, 이 shared page cache는 리눅스의 cgroup의 memory limit에 영향을 받습니다.

 

그러므로, 카프카의 메시지 복제 성능을 향상하고 싶은 경우 cgroup의 memory limit을 늘려주는것도 하나의 방법입니다.

 

5. 마무리

이번 포스팅에서는 실제로 제가 겪은 카프카 사용시 고려사항들에 대해 포스팅 하였습니다.

 

이렇게, 카프카 관련 1~5의 포스팅을 완료 하였습니다.

 

감사합니다.

반응형

'MQ > Kafka' 카테고리의 다른 글

(7) Kafka Trouble Shooting  (0) 2021.11.19
(6) spring kafka + schema registry + gradle plugin 적용  (4) 2020.10.22
(4) 카프카 매니저 & 스키마 레지스트리  (0) 2020.02.26
(3) 카프카 사용 예제  (0) 2020.02.25
(2) 카프카 설치  (0) 2020.02.25
반응형

1. 서론

이번 포스팅에서는 카프카 운영에 도움이 되는 Tool인 

카프카 매니저와 스키마 레지스트리에 대해 소개하려고 합니다.

 

2. 카프카 매니저

 

2-1. 소개

 

카프카 매니저는 야후에서 오픈소스로 제공하는 카프카 관리 GUI 툴입니다.

 

아마 이전 포스팅을 보셨다면, 터미널이 아닌 사진을 보셨을 텐데요.

그 사진이 제 카프카 매니저에서 발췌한 사진입니다.ㅎㅎ

 

카프카 매니저는 아래와 같은 기능을 제공합니다.

 

  • 다수의 카프카 클러스터 상태 확인
  • 클러스터의 브로커 상태 확인
  • 토픽 리스트 조회
  • 토픽 생성, 삭제
  • 토픽 설정 변경
  • 컨슈머 그룹 offset & lag 확인
  • 토픽 상태 확인( isr, leader 등)
  • 파티션의 leader & follower 변경 ( = partition reassign )

 

2-2. 설치

 

1) 파일 다운로드 

 

파일은 아래 주소에서 원하는 버전을 선택하여 다운받을 수 있습니다.

 

저는 현재 최신 버전인 3.0.0.1 release를 다운받도록 하겠습니다.

  • 저는 홈디렉터리에서 다운받아 진행하도록 하겠습니다.
wget https://github.com/yahoo/CMAK/archive/3.0.0.1.tar.gz
tar -zxvf 3.0.0.1.tar.gz
cd CMAK-3.0.0.1

 

위 명령어를 수행하면 ~/CMAK-3.0.0.1 폴더가 생긴것을 확인할수 있습니다.

 

2) sbt 빌드

 

카프카 매니저는 스칼라 언어로 되어있어 빌드 툴인 sbt를 이용하여 빌드를 진행합니다.

sbt는 소스에 들어가있어 별도 설치는 하지않으셔도 됩니다.

 

아래와 같이 sbt 명령어를 수행합니다.

 

  • CMAK 3.0.0.1 버전에서 제공되는 sbt는 1.3.8 버전입니다.
  • dist 명령어는 컴파일 및 빌드하여 어플리케이션이 실행될수 있도록 zip 파일로 제공해주는 명령어입니다.
  • zip 파일은 target/universal 폴더에 만들어집니다.
./sbt clean dist

 

시간이 상당히 걸려 잠시 커피한잔 마시고 오시는것을 추천드립니다.ㅎㅎ

 

 

수행이 모두 끝나면 ~/CMAK-3.0.0.1/target/universal/cmak-3.0.0.1 zip 파일이 생성된것을 확인할 수 있습니다.

 

 

 

 

 

 

반응형

 

 

 

 

 

 

3) 압축 해제 & 설정 파일 수정

 

이제 ~/CMAK-3.0.0.1/target/universal/cmak-3.0.0.1 zip 파일을 압축 해제합니다. 명령어는 아래와 같습니다.

 

unzip ~/CMAK-3.0.0.1/target/universal/CMAK-3.0.0.1.zip

 

해제가 완료되었으면 cmak-3.0.0.1 폴더가 생성된것을 확인할 수 있습니다.

 

이젠 설정 파일을 수정할 차례입니다.

 

설정파일 경로는 ~/CMAK-3.0.0.1/target/universal/cmak-3.0.0.1/conf/application.conf 입니다.

 

수정 내용은 아래 cmak.zkhosts 의 값을 zookeeper 주소를 적어 주시면 됩니다.

  • 주소 기입 양식 = "<zookeeper node1 hostname>:<zookeeper node1 client port>,<zookeeper node2 hostname>:<zookeeper node2 client port>"

 

 

 

4) 실행

 

실행은 ~/CMAK-3.0.0.1/target/universal/cmak-3.0.0.1/bin/cmak 명령어를 실행하여 주시면 됩니다.

 

5) 확인

 

실행한 서버의 9000 포트로 브라우저 접속을 하시면 아래와 같은 결과를 볼 수 있습니다.

 

3. 스키마 레지스트리

 

3-1. 소개

 

카프카는 메시지의 스키마를 관리하지는 않습니다. 단순히, 메시지를 저장하고 제공하는 역할을 할 뿐입니다.

 

결국, 항상 producer와 consumer는 메시지의 스키마 약속을 해야했고,

한쪽이 약속을 어긴다면 정상처리를 못하는 상황이 일어나게 됩니다.

 

스키마 레지스트리는 이와 같은 문제점을 해결하기 위하여

각 토픽에 들어갈 메시지의 스키마를 중앙관리하는 서비스입니다.

 

스키마 레지스트리의 특징은 아래와 같습니다.

 

  • Avro를 사용하여 스키마를 정의합니다.
  • restApi로 스키마 조회/생성/삭제 기능을 제공합니다.
  • 각 스키마는 버저닝이 가능합니다.

 

 

3-2. 설치

 

저의 경우 카프카 설치 에서 소개한 confulent를 이용하여 설치하도록 하겠습니다.

 

카프카 설치 포스팅에서 말씀드린 ~/apps/confluent-5.4.0 에 다운받았다는 가정하에 진행하겠습니다.

(카프카 설치 를 안보신 분은 보고 오시는 것을 추천드립니다.)

 

1) 설정 파일 수정

 

스키마 레지스트리 설정 파일을 수정합니다.

 

  • 경로 = ~/apps/confluent-5.4.0/etc/schema-registry/schema-registry.properties
  • listeners , host.name , kafkastore.bootstrap.servers 설정을 수정합니다.
    • 아래 listeners 설정 = 모든 ip에서 8081 port에 대한 접근을 허용.
    • 아래 host.name 설정 = 현재 서버의 ip 주소.
    • 아래 kafkastore.bootstrap.servers 설정 = 카프카 브로커 주소.
listeners=http://0.0.0.0:8081
host.name=host-ip
kafkastore.bootstrap.servers=PLAINTEXT://broker-1:9092,SSL://broker-2:9092

 

2) 실행

 

스키마 레지스트리 실행은 아래와 같습니다.

 

  • bin 디렉토리에 있는 schema-registry-start 명령어를 수행합니다.
  • 명령어 수행 시 인자로는 위에서 정의한 schema-registry.properties 파일 경로를 제공합니다.
~/apps/confluent-5.4.0/bin/schema-registry-start ~/apps/confluent-5.4.0/etc/schema-registry/schema-registry.properties

 

3) 확인

 

실행한 서버의 8081 port로 request 시 {} response가 오면 정상 실행된것입니다.

 

 

 

4. schema-registry-ui

 

schema-registry-ui는 스키마 레지스트리의 restApi 기능을 GUI로 제공해주는 서비스입니다.

설치는 https://github.com/lensesio/schema-registry-ui 를 참고하시면 됩니다.

 

  • docker image 로도 제공.
  • 스키마 리스트 확인.
  • 스키마 생성, 수정, 삭제.

아래는 schema-registry-ui 의 화면입니다.

 

 

 

5. 마무리

 

이번 포스팅에서는 카프카 운영에 도움이 되는 카프카 매니저 & 스키마 레지스트리 소개를 진행하였습니다.

다음 포스팅은 카프카 사용 시 고려사항들에 대해 포스팅하도록 하겠습니다.

 

반응형

'MQ > Kafka' 카테고리의 다른 글

(6) spring kafka + schema registry + gradle plugin 적용  (4) 2020.10.22
(5) 카프카 사용 시 고려사항  (0) 2020.02.26
(3) 카프카 사용 예제  (0) 2020.02.25
(2) 카프카 설치  (0) 2020.02.25
(1) 카프카란?  (2) 2020.02.25
반응형

1. 서론

이번 포스팅에서는 CLI를 통해 간단한 사용 예제를 포스팅하려고 합니다.

 

예제로는 아래와 같습니다.

 

  1. 토픽 생성
  2. 토픽 리스트 조회
  3. 토픽 상세 조회
  4. message pub
  5. message sub
  6. 컨슈머 그룹의 offset/lag 정보 확인

2. 사용 예제

 

2-1 토픽 생성

 

  • 명령어 경로 = 카프카 설치 에서 진행한 ~/apps/confluent-5.4.0/bin 디렉토리에 있습니다.
  • 아래는 replication이 2이고, partition 갯수는 3개인 test_topic을 생성하는 명령어 입니다.
  • --bootstrap-server 에는 각 브로커 서버의 hostname과 port를 ',' 구분자로 적어주시면 됩니다.
    • 저의 경우 브로커 3대를 기입하였습니다.
    • 브로커의 default port는 9092 입니다.

 

kafka-topics --create --bootstrap-server broker-1:9092,broker-2:9092,broker-3:9092 --replication-factor 2 --partitions 3 --topic test_topic

 

2-2 토픽 조회

 

토픽을 생성하였으니 잘 생성되었는지 확인이 필요합니다.

이런 경우, 아래와 같이 토픽 리스트 조회 명령어를 수행하면 됩니다.

kafka-topics --list --bootstrap-server --bootstrap-server broker-1:9092,broker-2:9092,broker-3:9092

 

아래와 같이 test_topic을 확인할 수 있습니다.

 

 

2-3. 토픽 상세 조회

 

토픽 조회에서는 단순히 카프카에 있는 토픽명만을 리스트로 보여주게 됩니다.

토픽의 상세 내용을 조회하고 싶은 경우는 아래 명령어를 통해 확인할 수 있습니다.

kafka-topics --describe --bootstrap-server broker-1:9092,broker-2:9092,broker-3:9092 --topic test_topic

 

결과로는 아래 정보들을 확인할 수 있습니다.

  • partition 갯수
  • replication 수
  • reader broker id
  • isr

 

 

 

반응형

 

 

 

 

 

 

 

2-4. message pub

 

토픽을 생성하였으니, 이번엔 해당 토픽에 메시지를 pub 하겠습니다.

 

명령어는 아래와 같습니다.

kafka-console-producer --broker-list broker-1:9092,broker-2:9092,broker-3:9092 --topic test_topic

 

CLI의 경우 enter 기반으로 메시지를 구분합니다.

저는 아래와 같이 [hi, my name is, young!!] 이라는 3개의 메시지를 pub하였습니다.

 

 

2-5. message sub

 

이번에는 pub한 메시지를 sub을 해보겠습니다.

sub을 하기 위해서는 consumer를 통해 수행됩니다.

 

아래는 sub하는 명령어 입니다.

 

kafka-console-consumer --bootstrap-server broker-1:9092,broker-2:9092,broker-3:9092 --topic test_topic --group test_consumer_group --from-beginning

 

명령어를 보시면 --group을 하는 것을 볼 수 있습니다.

이것은 카프카란? 에서 설명드린것과 같이 consumer는 consumer group이 있어야 하기 때문입니다.

  • 저의 test_consumer_group 이란 consumer group을 가진 consumer를 통하여 sub을 하였습니다.

 

아래는 sub한 결과 사진입니다.

[hi, my name is, young!!] 순서대로 pub했지만 sub은 순서대로되지 않은것을 확인할 수 있습니다.

 

이는 topic의 partition 갯수가 1이 아니기 때문입니다.

  • 카프카에서는 메시지의 pub 순서를 보장하기 위해서는 파티션 갯수가 1이 아닌이상 보장이 되지 않습니다.

 

아래 사진의 latest Offset을 보시면 3개의 메시지들이 3개의 파티션에 각각 들어간것을 볼 수 있습니다.

따라서, consumer는 각 파티션의 메시지를 sub하였고, 위와 같이 순서가 보장되지 않은 결과를 볼 수 있습니다.

 

 

2-6. 컨슈머 그룹의 offset/lag 정보 확인

 

이번엔 특정 컨슈머 그룹의 offset/lag 정보를 확인하는 명령어 입니다.

 

명령어는 아래와 같습니다.

  • --group에 확인하고 싶은 consumer group을 기입합니다.(저의 경우 위에서 sub한 test_consumer_group을 지정하였습니다.)
kafka-consumer-groups --bootstrap-server broker-1:9092,broker-2:9092,broker-3:9092 --group test_consumer_group --describe

 

 

아래는 결과 사진입니다.

  • 위에서 테스트한 test_topic의 결과를 볼 수 있습니다.
  • pub 메시지를 모두 sub하였으니 각 파티션의 lag는 0입니다.

 

 

3. 마무리

이번 포스팅에서는 간단한 CLI 기반의 카프카 사용예제를 진행하였습니다.

다음 포스팅에서는 카프카 사용시 도움되는 Tool들에 대해 소개하도록 하겠습니다.

 

반응형

'MQ > Kafka' 카테고리의 다른 글

(6) spring kafka + schema registry + gradle plugin 적용  (4) 2020.10.22
(5) 카프카 사용 시 고려사항  (0) 2020.02.26
(4) 카프카 매니저 & 스키마 레지스트리  (0) 2020.02.26
(2) 카프카 설치  (0) 2020.02.25
(1) 카프카란?  (2) 2020.02.25
반응형

1. 서론

이번 포스팅에서는 카프카 설치하는 방법을 튜토리얼처럼 정리하려고 합니다.

중간중간, 용어가 이해가지 않는 분들은 카프카란? 을 보고오시면 좋을거 같습니다.

 

2. 설치

설치는 최근 카프카를 주도적으로 이끌고 있는 confluent를 사용하여 진행하도록 하겠습니다.

 

confluent에서는 설치 방법을 다양하게 제공합니다. 그 중 저는 tar를 이용하여 진행하도록 하겠습니다.

그리고, ~/apps 경로에서 작업하겠습니다.

 

1) confluent-community tar 파일 다운로드

 

  • 카프카, 주키퍼만을 설치할 예정으로 community를 다운받도록 하겠습니다.
  • 현재 기준 최신인 5.4.0 버전을 다운받겠습니다.
curl -O http://packages.confluent.io/archive/5.4/confluent-community-5.4.0-2.12.tar.gz

 

2) 파일 해제

tar -zxvf confluent-community-5.4.0-2.12.tar.gz

 

 

 

 

 

 

반응형

 

 

 

 

 

 

 

3) zookeeper.properties 파일 수정

  • 파일 경로 = ~/apps/confluent-5.4.0/etc/kafka/zookeeper.properties
  • 아래는 confluent에서 가이드 되어있는 부분 중 dataDir, server.* 만 수정한 사진입니다.

  • server.* 에는 앙상블을 이룰 서버의 ip 혹은 hostname을 적습니다.
    • confluent에서는 server.<myid>=<hostname>:<leaderport>:<electionport> 형식으로 가이드 되어있습니다.
  • dataDir에는 zookeeper의 데이터를 담는 경로를 지정합니다.
    • 저의 경우에는 ~/zookeeper 경로를 만들어 지정하였습니다.
    • dataDir 경로에는 server.* 에 지정한 번호값이 myid 파일로 존재해야 합니다.
    • 아래 사진의 경우에는 앙상블 1번 서버의 myid 파일을 cat으로 확인한 사진입니다.

4) server.properties 파일 수정

  • 파일 경로 = ~/apps/confluent-5.4.0/etc/kafka/server.properties
  • broker.id, log.dirs, zookeeper.connect 3개의 값을 변경해줍니다.
    • broker.id는 unique 해야합니다.
    • log.dirs는 카프카관련 로그 경로를 지정해줍니다. (저의 경우 ~에 kafka 디렉토리를 만들어 지정하였습니다.)
    • zookeeper.connect의 경우에는 앙상블 서버들을 ',' 구분자로 이어줍니다. (port는 zookeeper.properties파일에 정의한 clientPort를 지정합니다)
broker.id=1
log.dirs=~/kafka/kafka-logs
zookeeper.connect=zookeeper-server-1:2181,zookeeper-server-2:2181,zookeeper-server-3:2181

 

5) zookeeper 실행

 

주키퍼 실행은 아래와 같습니다.

  • bin 디렉토리에 있는 zookeeper-server-start 명령어를 수행합니다.
  • 명령어 수행 시 인자로는 위에서 정의한 zookeeper.properties 파일 경로를 제공합니다.
~/apps/confluent-5.4.0/bin/zookeeper-server-start ~/apps/confluent-5.4.0/etc/kafka/zookeeper.properties

 

6) broker 실행

 

브로커 실행은 아래와 같습니다.

  • bin 디렉토리에 있는 kafka-server-start 명령어를 수행합니다.
  • 명령어 수행 시 인자로는 위에서 정의한 server.properties 파일 경로를 제공합니다.
~/apps/confluent-5.4.0/bin/kafka-server-start ~/apps/confluent-5.4.0/etc/kafka/server.properties

 

 

3. 마무리

설치는 비교적 간단하게 이루어졌습니다.

다음 포스팅에서는 설치를 하였으니, 간단하게 CLI 기반의 사용예제를 진행하도록 하겠습니다.

 

* 참고

실행 시 에러 로그들이 보일텐데, 이것은 각 노드들이 아직 연결이 안되었기 때문에 나는 로그입니다.

각 노드들을 실행해도 난다면 설정 파일에 잘못된것이 있는지 다시 한번 확인하시기 바랍니다.

반응형
반응형

1. 서론

최근, MQ(=message queue) 중 많은 사용과 관심이 증가하는 카프카에 대해서 소개하려고 합니다.

 

2. 카프카란?

아파치에서 제공하는 pub-sub 기반의 분산형 메시지 큐입니다.

dispatch가 아닌, subscribe 방식으로 기존 RabbitMQ에 비해 고성능입니다.

(단, RabbitMQ에서 제공하는 전체 트랜잭션은 제공되지 않습니다)

 

3. 카프카 용어

아래 그림은 카프카의 기본 컨셉 그림입니다.

그림에 나오는 broker, zookeeper, topic, partition, leader, follower, producer, consumer, (+ consumer group)대해

각 역할을 설명하도록 하겠습니다. 

3-1. broker (브로커)

 

브로커는 실제로 메시지를 저장하는 카프카의 각 노드입니다.

 

브로커의 역할은 아래와 같습니다.

 

  • pub으로 인해 들어온 데이터 저장 (disk 기반)
  • leader, follower 개념 존재

 

3-2. zookeeper (주키퍼)

 

주키퍼는 아파치에서 제공하는 코디네이션 분산 플랫폼입니다.

주키퍼는 hadoop, hbase 연계로도 사용하지만, 카프카와의 연계로도 사용합니다.

 

카프카와의 연계 시 역할은 아래와 같습니다.

 

  • broker health check
  • leader 선출
  • znode(파일 시스템의 폴더 구조)라는 곳에 broker의 meta정보 관리

 

zookeeper 클러스터는 앙상블이라 부르며, 앙상블은 데이터 write시 과반수가 넘으면 성공으로 간주하게 됩니다.

즉, 앙상블은 2N+1인 홀수로 구성이 필요합니다.

 

 

 

 

 

반응형

 

 

 

 

 

 

 

 

3-3. topic (토픽)

 

토픽은 큐들의 집합입니다.

큐들의 집합이라는 용어를 사용한 이유는 토픽은 한개 이상의 파티션이 있어야 하고, 파티션이 한개의 큐이기 때문입니다.

 

토픽의 역할과 특징은 아래와 같습니다.

 

 

3-4. partition (파티션)

 

파티션은 토픽을 이루는 큐입니다.

각 파티션에는 leader, follower, isr 존재합니다.

 

각 용어의 의미는 아래와 같습니다.

  • leader는 메시지를 write, read하는 역할을 수행하며, 토픽의 replication 갯수만큼 follower에게 복제를 명령합니다.
  • follower는 leader의 요청을 받아 메시지를 복제하는 역할을 합니다.
  • isr는 replication group을 의미하며, leader & follwer 선출 시 이 isr 내에서 선출하게 됩니다.

아래는 파티션의 leader, follower, isr에 관련해서 보여드리기 위해 캡처한 사진입니다.

 

위 사진을 보시면 0번 파티션의 정보로는,

leader는 2번 broker, isr(in sync replicas)는 현재 2번, 3번으로 되어 있는것을 보실 수 있습니다.

 

3-5. producer (프로듀서)

 

프로듀서는 카프카에서 메시지를 발행(pub)하는 주최를 의미합니다.

 

프로듀서의 특징은 아래와 같습니다.

  • 메시지 발행 시 직렬화를 제공합니다.(string, json, avro 등)
  • partition에 특정 데이터만을 발행하기 위해 메시지의 key를 지정할 수 있습니다.
  • 메시지 발행 후 broker로 부터 ack를 받을 수 있습니다. (https://kafka.apache.org/23/documentation.html#producerapi)

 

3-6. consumer (컨슈머)

 

컨슈머는 메시지를 subscribe하는 주최입니다.

 

컨슈머의 특징은 아래와 같습니다.

 

  • commit이라는 행위로 어느 offset까지 subscribe했는지 주키퍼에게 알림.
  • 컨슈머는 살아있다면 zookeeper에게 heart beat를 전송.
  • poll이라는 행위로 메시지를 subscribe하며, 이때 시간과 최대 갯수등 설정 가능(https://kafka.apache.org/23/documentation.html#consumerconfigs)

 

여기서 offset은 각 파티션에 메시지가 유입된 순서를 의미합니다.

 

 

3-7. consumer group (컨슈머 그룹)

 

컨슈머 그룹은 컨슈머들의 논리적인 그룹을 의미합니다.

 

컨슈머 그룹은 아래와 같은 특징을 가지고 있습니다.

 

  • 토픽별 컨슈머 그룹 단위로 offset과 lag를 관리.
  • 컨슈머는 컨슈머그룹을 필수로 가져야 함.
  • 토픽의 파티션 갯수만큼 컨슈머들이 동일 컨슈머 그룹에 존재하는것이 Best!!
    • 한 파티션은 하나의 컨슈머만 점유 가능하기 때문.
  • 파티션을 점유중인 컨슈머가 down 되었을 시 컨슈머 그룹내 리밸런싱 동작.
    • down된 컨슈머가 점유한 파티션을 다른 컨슈머에게 위임하는 작업.

 

여기서, lag는 한 토픽의 (총 메시지 갯수 - 컨슈머 그룹이 subscribe한 메시지 갯수) 입니다.

간단히, 한 토픽에서 한 컨슈머 그룹이 소비해야하는 메시지 갯수입니다.

 

 

4. 마무리

이번 포스팅에서는 카프카에 대해 알아보았습니다.

다음 포스팅부터는 카프카 설치 및 cli를 통한 사용예제를 포스팅하도록 하겠습니다.

 

반응형

+ Recent posts