Keepalive를 이용한 linux 로드밸런싱 고가용성 구현

개요

keepalive 참조
keepalive는 Linux 시스템 혹은 Linux 기반 인프라에서의 로드밸런싱 및 고가용성을 위한 기능을 제공한다.
단순하게 설명하면, 두 개 이상의 Linux 시스템이 존재할 경우, virtual IP 를 생성하고 시스템의 상태에 따라 해당 virtual IP를 할당해주는 기능을 한다.

설치

# CentOS (Redhat 계열)
$ sudo isntall -y keepalived

# Ubuntu (Devian 계열)
$ sudo apt-get install -y keepalived

설정

/etc/keepalived/keepalived.conf 를 환경에 맞도록 수정한다.

Master server

! Configuration File for keepalived Master

global_defs {
   router_id rtr_0           # Master와 Backup 구분
}

vrrp_instance VI_0 {          # Master와 Backup과 구분
    state MASTER              # 또는 BACKUP
    interface eth0            # 노드에서 실제 사용할 인터페이스 지정
    virtual_router_id 10      # Master와 Backup 모두 같은 값으로 설정.
    priority 200              # 우선순위, 값이 높은 쪽인 Master가 된다.
    advert_int 1
    authentication {
        auth_type PASS        # Master와 Backup 모두 같은 값으로 설정.
        auth_pass P@ssW0rd    # Master와 Backup 모두 같은 값으로 설정.
    }

    virtual_ipaddress {
        192.168.0.100      # Master와 Backup 동일하게 설정한 VIP
    }
}
# #으로 시작하는 내용은 모두 삭제한다.

Backuo(slave)

! Configuration File for keepalived

global_defs {
   router_id rtr_1           
}

vrrp_instance VI_1 { 
    state BACKUP                    # MASTER가 아니므로 수정              
    interface eth0            
    virtual_router_id 10      
    priority 100                    # 낮은 우선순위를 위해 수정
    advert_int 1
    authentication {
        auth_type PASS        
        auth_pass P@ssW0rd        
    }

    virtual_ipaddress {
        192.168.0.100      
    }
}

구동

각각의 서버에서 서비스를 구동한다.

 sudo systemctl enable keepalived --now
# BACKUP 서버들에서도 동일하게 서비스를 구동해준다. 

확인

ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 4e:be:1a:32:52:04 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.41/24 brd 192.168.1.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet 192.168.1.40/32 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::4cbe:1aff:fe32:5204/64 scope link
       valid_lft forever preferred_lft forever

192.168.1.40/32가 virtual IP. backup 노드로 설정된 서버에는 해당 ip가 보이지 않는다.

다른 시스템에서 가상아이피를 이용하여 ssh 접속, 혹은 ping 명령등을 수행해서 확인하면 된다.

MS 파워포인트 한/영 자동전환 기능 끄기

마이크로소프트 파워포인트(Microsoft Power Point)를 사용하다 보면 자동으로 한글이 영어로 영어에서 한글로 바뀌는 경우를 볼 수 있다.
아주 아주 편리한 기능으로 ‘database’라는 단어를 입력하고 싶을 때 한글이 선택된 상태로 ‘ㅇㅁㅅ뮴ㄴㄷ’를 입력하면 자동으로 제대로 된 영문으로 고쳐주는 기능이다.

정상적인 동작. 아주 편하다

 

하지만 종종 내가 원하지 않는 경우에도 변환이 되는 경우가 있는데 이런 경우라면 [파일][옵션] [언어교정][자동 고침 옵션(A)…] 메뉴에서 [한/영 자동 고침(K)] 항목을 비활성화 해주면 된다

 

 

하.지.만

사실 위 기능은 구글에 ‘파워포인트 한영전환’ 9자만 검색하면 어떻게 바꾸는지 엄청 많이 나오므로 굳이 이렇게 포스팅할 필요가 없지만…

이런 어처구니 없는 동작을 하는 경우엔?

분명히 [한/영 자동 고침(K)] 항목을 비활성화 했음에도 제 멋대로 변경되는 것을 확인할 수 있다. “spark”의 경우는 아무런 문제가 없는 영단어인데 제 멋대로 자꾸 ‘rk ‘만 ‘가’로 치환하는데다 “repository”의 경우는 ‘sitory’ㅇ를 ‘냐새교’로 있지도 않은 단어로 자꾸 치환 해대니 미쳐버릴 노릇.

사실 이 문제는 파워포인트의 한영 전환 기능이 아니라 윈도우즈에 설치된 한글 입력기가 개입 하는 것으로 비단 파워포인트 뿐 아니라 다른 모든 어플리케이션에서 제 멋대로 문자를 치환해버리는 경우이다. 그러니까 파워포인트 문서를 작성하다가 문자가 변경된다고 옵션을 백번 바꿔봐야 소용이 없고, 엑셀에서도 제 멋대로 문자를 치환하고, 크롬의 경우는 제 멋대로 주소표시줄에서 자동완성을 시전하는 아주 전방위에서 사용자를 괴롭히는 그런 문제가 되겠다.

원인은 ‘한글과 컴퓨터 아래아한글’. 정확히 말하면 한컴 오피스를 설치 할 때 함께 설치되는 “한컴입력기”.

두 번째 동영상과 같은 증상이 나타나면 “한컴 입력기”를 제거함으로써 증상을 고칠 수 있다.
방법은 다음과 같다

  1. 윈도우즈 [설정] [시간 및 언어][언어] 메뉴 진입
  2. 기본 설정 언어“의 “한국어” 메뉴 선택
  3. 한국얼 아래 나타나는 [옵션]에서 “키보드” 항목 선택
  4. [한컴 입력기] 선택
  5. [제거] 버튼 클릭

렌즈필터의 품질에 따른 결과물의 차이 (필터가 사진의 품질에 주는 영향)

기본적으로 렌즈 필터라 함은 렌즈의 앞에 장착하여 부가적인 효과를 더해주는 도구를 말한다. 요즘에야 디지털 카메라로 촬영한 디지털 결과물을 포토샵 등의 프로그램으로 수정을 하니까 필터로 얻는 효과가 무엇이 있을까 싶기도 하지만 과거 필름을 주로 사용하던 시절은 촬영한 이후 결과물을 수정하는 것이 쉽지 않았기 때문에 필터를 장착함으로써 다양한 효과를 추가하였다.

필터의 종류와 세세한 역할은 이후에 포스팅 하기로 하고 이번 포스트에서는 몇 가지 종류와 개념만 소개한다.

  • PL 필터 또는 CPL 필터 : Polarizing Filter 또는 Circular Polarizing Filter. 빛을 굴절시켜서 유리면이나, 수면의 반사광을 제거하는 역할을 한다.
  • ND 필터 : Neutral-density filter. 아주 밝은 날 혹은 밝은 공간에서 빛이 너무 강해 아무리 조리개를 조이고 셔터스피드를 짧게 해도 밝게 나오는 경우 혹은, 밝은 렌즈에서 오는 배경 흐림 효과 등을 사용하고 싶은데 빛이 강한 경우 등에 사용한다. ND100, 200 등의 숫자를 붙여서 빛의 차단 정도를 표기한다.
  • 크로스 필터: Cross filter. 렌즈에 규칙적인 금이 가있는 필터로 금이간 모양대로 빛이 갈라지는 효과를 얻기 위한 필터이다. 광원이 십자가 모양 등으로 명확히 갈라지는 사진 등을 떠올리면 된다.
  • UV 필터 또는 MCUV 필터 등: Ultra-Violet Filter 또는 Multi-Coated Ultra-Violet Filter. 필터 유리면에 자외선 등의 특정 빛을 차단하는 코팅이 되어있는 필터를 말한다. 일반적으로는 자외선 차단의 효과보다는 렌즈 보호의 목적으로 사용한다.

이번 포스트에서는 렌즈의 보호를 위한 목적으로 필터를 사용하는 경우 (말그대로 렌즈 보호가 목적이므로 가격이 상대적으로 저렴한 필터를 사용하는 경우가 많다) 필터의 품질에 따라 사진이 어떻게 변하는가를 비교해보고자 한다.
어쩌면 당여한 얘기일 수 있지만 과거 초기의 디지털 카메라의 경우 센서의 부족한 성능으로 화질이 상대적으로 좋지 않았고 화소수도 적다보니 세밀한 차이는 도드라지지 않는 경우도 있었지만 근래 고화소 카메라의 경우는 필터의 품질에 따라 차이가 있을 수 있음을 이해하는 것이 그 목적이다.

실제 비교

실험에 사용한 장비는 다음과 같다.
– 바디 : 소니 a7M4 (모델명 :ILCE-7M4)
– 렌즈 : 소니 FE 200-600 F5.3-6.3 G OSS (모델명 : SEL200600G)
– 필터 : ALLDA UV 렌즈필터 95mm (온라인 가격비교 최저가 약 5000원)
SIGMA Protector 95mm (온라인 가격비교 최저가 약 11만원)
1상기 장비 선정 사유 : 200-600 렌즈 구입 후 부담되는 필터 가격에 (95mm 필터는 비싸다..) 1만원도 안하는 필터를 장착하고 촬영한 사진의 품질이 너무 좋지 않아 과연 이 품질 저하가 필터 탓인가 하는 의문에서 시작했기 때문이다.

리사이징 된 사진은 크게 차이가 나지 않는다.

sigma Protector : 특이사항은 없다.
자세히 보면 Allda UV filter #1.의 경우 품질이 떨어짐을 알 수 있고, (굵은 선의 경계을 자세히 보자)
Allda filter #2. 의 경우는 초점이 맞는 영역의 앞과 뒤 그러니까 0에서 멀어지는 선들이 두 개 씩 보이는 것을 확인할 수 있다.
(처음에는 핀이 안맞는 것이라 생각했다.)

해당 부분만 좀 더 확대 해보면

우측 사진은 +2, -2 부터 상이 이중으로 맺히는 것이 확연히 보인다.

2종의 필터임에도 세 장의 결과를 비교한 이유는
필터의 비교를 위해 필터를 교체해야 하니 필터를 헐겁게 체결하였는데 필터를 헐겁게 체결 했을 때와 그렇지 안을 때의 차이가 있었음을 발견했기 때문이었는데, 실제 동일한 필터임에도 약 90도 회전시켜 촬영을 해보니 상이 이중으로 촬영 되는 정도의 차이가 있음을 쉽게 확인할수 있었다.

여기서 왜 이와 같은 차이가 나는가에 대한 원인을 짐작해 볼 수 있었다. 2당연한 이야기지만 진짜 원인은 알 수 없다. 전문가도 아니고, 촬영을 통해 결과물의 비교 외에 다른 측정 (표면 굴곡 등)은 불가능 했기 때문이다.
증상이 난시와 비슷한 것으로 미루어 보아 첫 번째 의심 사유는 필터의 표면이 울퉁 불퉁 한것이 아닌가 하는 것. 불규칙적인 것은 아니고 아마도 물결처럼 일정한 방향의 패턴을 가지지 않을까 하는 것이다.
두 번째는 고른 연마가 되지 않았기에 연삭의 흔적이 있고 3필터를 뚫어져라 처다본다고 확인할 수 있는 정도로 보이는 흔적은 아니다. 4첫 번째 원인가 비슷한데 이 경우는 울퉁불퉁이 아니라 거친 사포로 표면을 문질렀을때 깎여 나가는 형태의 모양이다. 이 흔적에 따라 빛이 꺾이면서 상이 두개로 찍히는 것이 아닐까 한다.

결국 각도를 조절했을 때 결과물이 달라지는 것으로 보아 일정한 패턴의 굴절을 일으키는 무언가가 필터에 있다는 이야기가 아닐까 한다.

 

결론

필자의 경우 항상 비주류 카메라에 저가의 렌즈만 사용하는 데다 실력도 워낙에 개차반인지라 애진작에 결과물의 해상도도 낮고 품질 자체도 낮다 보니 렌즈 필터는 제조사 등에 따라 딱히 결과물에 영향을 주지 않는 다고 생각했었다.
하지만 이번 실험 결과 렌즈 보호 용으로 사용하는 필터라 할지라도 제조사 혹은 가격 등에 따라 엄연히 품질의 차이가 존재하며, 기준 이하의 필터는 결과물에 아주 많은 영향을 미친다는 것이다.

결론의 결론
필터 구매 시 너무 싼건 사지 말자.

 


dockerfile 예시 및 이미지 빌드 – ssh 서버 및 편의 패키지 포함

일반적으로 개발사 등에서 제공되는 docker image 들은 운영에 필요한 최소한의 바이너리들만 담는 경우가 많기 때문에 컨테이너에 문제가 생기거나, 컨테이너 내부의 프로세스를 확인하고자 하는 경우에 ps 명령이 없어서 프로세스 확인이 불가능하거나, ping 명령이 없어서 연결 여부 확인이 안된다거나 하는 경우가 있을 수 있다. 또 docker 명령을 이용해 컨테이너에 진입하여 작업을 하는 것이 이래저래 불편해서 ssh의 아쉬움을 느끼는 경우도 왕왕 있을 것이다.

이 포스트에서는 특정한 도커 이미지에 운영에 편의를 위한 패키지들을 설치하고 SSH 서버도 추가하여 이미지를 새로 만들 것이다.

dockerfile 예제

실제 docker image build를 위한 예제이다.
세부 내용은 주석을 참고하면된다.

# base가 될 이미지 
# bitnami/jupyter-base-notebook
# 최신의 이미지에 append 하는 형태로 빌드하고자 한다면 latest tag 를 붙여준다.
# FROM haedongg.net/library/jupyter/pyspark-notebook:latest
FROM haedongg.net/library/jupyter/pyspark-notebook:spark-3.2.0

# 레이블. 없어도 된다. 
LABEL comment "essential tools & configuration"

# 아래 작업들을 수행할 계정 
# USER ACCOUNT 다음 라인은 별도로 USER를 변경하는 작업이 없다면 모두 ACCOUNT 계정으로 작업이 수행된다.
USER root

ENV DEBIAN_FRONTEND=noninteractive \
    TZ=Asia/Seoul


# 편의를 위해 기본적으로 필요한 것들
# 프록시를 사용하는 경우 apt-get 앞에 다음을 추가한다.
# RUN sudo https_proxy=PROXY_SERVER_HOST:PORT http_proxy=PROXY_SERVER_HOST:PORT
RUN apt-get update
RUN apt-get install -y openssh-server sudo procps curl vim git openssh-client telnet net-tools tcpdump htop --no-install-recommends 
# 컨테이너 이미지 파일의 크기를 줄이기 위해 apt 수행 중 생성된 임시 파일들을 삭제해준다.
RUN apt-get clean && \
    rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*


#### 여기부터 SSH 
RUN mkdir /var/run/sshd

# root password 변경, $PASSWORD를 변경한다.
RUN echo 'root:$PASSWORD' |  chpasswd

# ssh 설정 변경
# root 계정으로의 로그인을 허용한다. 아래 명령을 추가하지 않으면 root 계정으로 로그인이 불가능하다. 
RUN sed -ri 's/^#?PermitRootLogin\s+.*/PermitRootLogin yes/' /etc/ssh/sshd_config
# 응용 프로그램이 password 파일을 읽어 오는 대신 PAM이 직접 인증을 수행 하도록 하는 PAM 인증을 활성화
RUN sed -ri 's/UsePAM yes/#UsePAM yes/g' /etc/ssh/sshd_config

RUN mkdir /root/.ssh
EXPOSE 22
CMD ["/usr/sbin/sshd", "-D"]
####여기까지 SSH

# sudo 설정
# 사용자 추가, $USER 가 사용자 명, $PASSWORD 가 패스워드이다.
RUN adduser --disabled-password --gecos "" $USER &&\ 
    echo '$USER:$PASSWORD' | chpasswd  &&\ 
    adduser $USER sudo &&\ 
    echo 'USER ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers


# user 변경
USER $USER

# alias를 추가하고 싶은 경우
RUN echo "alias ll='ls -lha'"  >>  /home/$USER/.bashrc


# pip 패키지 인스톨
# 프록시를 사용한다면 RUN https_proxy=http://PROXY_SERVER_HOST:PORT http_proxy=PROXY_SERVER_HOST:PORT
RUN  pip --trusted-host pypi.org --trusted-host files.pythonhosted.org install --no-cache-dir s3fs py4j pytz toml xgboost==1.5.1 lightgbm==3.3.1 scikit-learn==1.0.1 mlflow mlflow-skinny sqlalchemy alembic sqlparse  tqdm boto3

# 설정된 home directory의 권한 부여
RUN chown -R $USER /home/$USER

 

Build

#  docker  image    build     -t       $TARGET_DOCKER_IMAGE_NAME:tag           $dockerfile_location
docker image build -t haedongg.net/library/new_haedong_image:v0.1   .
docker image tag haedongg.net/library/new_haedong_image:v0.1  haedongg.net/library/new_haedong_image:latest

_-t 옵션 및 tag 옵션으로 지정하는 이미지 이름은 build에 사용한 원래 이미지의 이름, 경로와는 상관이 없다. 내가 사용하고자 하는 이름을 지정하면 된다.
단, local 이미지가 아닌 harbor나 docker hub 등의 외부 리포지터리에 업로드 하고자 한다면 정확한 이름을 지정해줘야 push가 가능하다._

Kafka #2. 설치

Zookeeper #1. 개요
Zookeeper #2. 설치와 설정
Zookeeper #3. 구동과 확인

Kafka #1. 개요
Kafka #2. 설치

Kafka 클러스터 구축을 위해서는 zookeeper 가 필요하다. 일반적으로 kafka 클러스터 구축은 3개 이상의 broker를 가지는데 이 ‘세 개 이상의 broker가 하나처럼 동작하기 위한 정보는 zookeeper가 관리’하기 때문에다.

기본적으로 프로듀서 혹은 컨슈머는 카프카에 연결할 때 직접 카프카 브로커에 연결하는 것이 아니라 주키퍼에 연결하여 카프카 브로커, 토픽, 파티션 등의 정보를 취득한 뒤 브로커에 연결하게 된다.1실제 카프카 연결 시 연결 옵션으로 브로커의 정보만 입력하더라도 주키퍼에 연결한 뒤 다시 브로커에 연결된다.

Zookeeper 설치

zoookeeper 설치는 zookeeper #1. 개요, #2. 설치와 설정, #3. 구동과 확인 포스트를 참고하면 된다.

다운로드 및 압축 해제

  • Apache kafka 공식 페이지에서 바이너리를 다운로드 한다.
  • 다운로드한 파일을 FTP 또는 SFTP등을 이용하여 서버에 업로드한다.
  • 또는 wget 명령을 이용하여 서버에서 다운로드 한다

설정

카프카 클러스터의 설정을 위해서는 ‘zookeeper’ 클러스터가 존재하는 상태에서 $KAFKA_HOME/config/server.config 파일에 기재된 설정만 잘 조절해주면 된다.

############################# Server Basics #############################
# 브로커 고유 ID. 각각의 브로커는 중복되지 않은 고유한 숫자 값을 가진다. 
broker.id=1

############################# Socket Server Settings #############################
# Broker 가 사용하는 호스트와 포트
listeners=PLAINTEXT://dist01.haedongg.net:9092

# Producer와 Consumer가 접근하는 호스트와 포트
# 다음의 연결 옵션을 제공한다 -PLAINTEXT:PLAINTEXT,SSL:SSL,SASL_PLAINTEXT:SASL_PLAINTEXT,SASL_SSL:SASL_SSL
advertised.listeners=PLAINTEXT://dist01.haedongg.net:9092

# 네트워크 요청 처리 스레드
num.network.threads=3

# IO 발생 시 생기는 스레드 수
num.io.threads=8

# 소켓 서버가 사용하는 송수신 버퍼
socket.send.buffer.bytes=1024000
socket.receive.buffer.bytes=1024000

# The maximum size of a request that the socket server will accept (protection against OOM)
socket.request.max.bytes=104857600

############################# Log Basics #############################
# Broker가 받은 데이터 관리를 위한 저장 공간
log.dirs=/home/kafka/data

# 여러 개의 디스크, 여러 개의 디렉토리를 사용하는 경우 콤마로 구분하여 추가한다.
# log.dirs=/home/kafka/data,/mnt/sdb1/kafka/data,/third_disk/mq-data

# 토픽 당 파티션의 수. 값 만큼 병렬 처리 가능하고, 파일 수도 늘어난다.
# 기본 값으로써 토픽을 생성할 때 파티션 숫자를 지정할 수 있고, 변경도 가능하다.
num.partitions=1

# The number of threads per data directory to be used for log recovery at startup and flushing at shutdown.
# This value is recommended to be increased for installations with data dirs located in RAID array.
num.recovery.threads.per.data.dir=1

############################# Internal Topic Settings #############################
# The replication factor for the group metadata internal topics "__consumer_offsets" and "__transaction_state" 
# For anything other than development testing, a value greater than 1 is recommended to ensure availability such as 3.

# 토픽에 설정된 replication의 인수가 지정한 값보다 크면 새로운 토픽을 생성하고 작을 경우 브로커의 숫자와 같게 된다.
offsets.topic.replication.factor=1
transaction.state.log.replication.factor=1
transaction.state.log.min.isr=1

############################# Log Flush Policy #############################
# The number of messages to accept before forcing a flush of data to disk
#log.flush.interval.messages=10000

# The maximum amount of time a message can sit in a log before we force a flush
#log.flush.interval.ms=1000

############################# Log Retention Policy #############################
# 수집 데이터 파일 삭제 주기. (시간, 168h=7days)
# 실제 수신된 메시지의 보존 기간을 의미한다. 
log.retention.hours=168

# A size-based retention policy for logs. Segments are pruned from the log unless the remaining
# segments drop below log.retention.bytes. Functions independently of log.retention.hours.
#log.retention.bytes=1073741824

# 토픽별 수집 데이터 보관 파일의 크기. 파일 크기를 초과하면 새로운 파일이 생성 된다. 
log.segment.bytes=1073741824

# 수집 데이터 파일 삭제 여부 확인 주기 (밀리초, 300000ms=5min)
log.retention.check.interval.ms=300000

# 삭제 대상 수집 데이터 파일의 처리 방법. (delete=삭제, compact=불필요 내용만 제거)
log.cleanup.policy=delete

# 수집 데이터 파일 삭제를 위한 스레드 수
log.cleaner.threads=1

############################# Zookeeper #############################
# zookeeper 정보.
# zookeeper 클러스터 모두 콤마(,)로 구분해서 기재한다.
zookeeper.connect=dist01.haedongg.net:2181,dist02.haedongg.net:2181,dist03.haedongg.net:2181

# Timeout in ms for connecting to zookeeper
zookeeper.connection.timeout.ms=6000

############################# Group Coordinator Settings #############################
# 초기 GroupCoordinator 재조정 지연 시간 (밀리초) 
# 운영환경에서는 3초를 권장 
group.initial.rebalance.delay.ms=3000

############################# 기타 ################################
# 최대 메시지 크기 (byte) 
# 예시는 15MB 까지의 메시지를 수신할 수 있다.
message.max.bytes=15728640

구동 및 확인

Kafka broker 구동을 위해서는 JAVA가 필요하다. JDK가 설치되어있고 환경변수($JAVA_HOME 및 $PATH)가 설정되어 있다면 별도의 설정 없이 카프카 브로커를 구동할 수 있다. 만약 JDK가 설치되어있지 않거나, 별도의 JAVA를 사용하고자 한다면 export 명령을 이용하여 변수를 선언하거나, $KAFKA_HOME/bin/kafka-run-class.sh 파일에 JAVA관련 변수를 넣어주도록 한다.

# Memory options
# 다음 $JAVA_HOME 관련 옵션을 적절히 수정한다.
# JAVA_HOME=/WHERE/YOU/INSTALLED/JAVA 이렇게 JAVA_HOME 변수를 지정하면 된다. 
# 만약 JAVA_HOME 변수가 선언되지 않았다면  PATH에 등록된 경로에서 java 명령을 찾게 된다. 
if [ -z "$JAVA_HOME" ]; then
  JAVA="java"
else
  JAVA="$JAVA_HOME/bin/java"
fi

# Memory options
# 카프카 구동을 위한 java heap memory 옵션
if [ -z "$KAFKA_HEAP_OPTS" ]; then
#  KAFKA_HEAP_OPTS="-Xmx256M"   이 값이 기본
  KAFKA_HEAP_OPTS="-Xms256M -Xmx1G"
fi

broker 실행

  • broker로 구동할 모든 Kafka 서버에서 수행한다.
$KAFKA_HOME/kafka-server-start.sh -daemon $KAFKA_HOME/config/server.properties
ex) /home/apps/kafka/bin/kafka-server-start.sh -daemon /home/apps/kafka/config/server.properties
# 만약 -daemon 옵션을 추가하지 않으면 브로커가 background가 아닌 foreground에서 구동된다.
  • 프로세스 및 리슨 포트 확인
jps -l

18320 kafka.Kafka
18403 sun.tools.jps.Jps
17899 org.apache.zookeeper.server.quorum.QuorumPeerMain

netstat -nltp

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      973/sshd
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      1286/master
tcp6       0      0 :::8080                 :::*                    LISTEN      17899/java
tcp6       0      0 :::40434                :::*                    LISTEN      17899/java
tcp6       0      0 :::22                   :::*                    LISTEN      973/sshd
tcp6       0      0 ::1:25                  :::*                    LISTEN      1286/master
tcp6       0      0 :::34880                :::*                    LISTEN      18320/java
tcp6       0      0 :::9092                 :::*                    LISTEN      18320/java
tcp6       0      0 :::2181                 :::*                    LISTEN      17899/java
  • 종료
$KAFKA_HOME/bin/kafka-server-stop.sh

 

 

 

Kafka #1. 개요

Zookeeper #1. 개요
Zookeeper #2. 설치와 설정
Zookeeper #3. 구동과 확인

Kafka #1. 개요
Kafka #2. 설치

아파치 카프카(Apache Kafka)는 아파치 소프트웨어 재단이 스칼라로 개발한 오픈 소스 메시지 브로커 프로젝트이다. 이 프로젝트는 실시간 데이터 피드를 관리하기 위해 통일된, 높은 처리량, 낮은 지연시간을 지닌 플랫폼을 제공하는 것이 목표이다. 요컨대 분산 트랜잭션 로그로 구성된, 상당히 확장 가능한 pub/sub 메시지 큐로 정의할 수 있으며, 스트리밍 데이터를 처리하기 위한 기업 인프라를 위한 고부가 가치 기능이다.

큐 (Queue)

먼저 큐에 대한 이해가 필요한데, 말 그대로 ‘기다리는 줄(열)’, ‘대기 열’을 생각하면 된다. 전공자라면 자료구조, 알고리즘 과목 등에서 접하게 되는데 Stack 과 함께 배운다.
FIFO1First In First Out 구멍이 두 개인 파이프의 한쪽에 동전을 넣는다고 생각하면 된다. 계속 동전을 밀어 넣다 보면 가장 먼저 넣었던 동전부터 동전이 밀려나오는 구조가 된다.
이와 반되 되는 것이 Stack. 쌓는다는 의미의 stack으로 FILO2First In Last Out 컵에 동전을 쌓는 것을 상상하면 된다. 컵에 동전을 쌓아 넣다다가 동전을 꺼내면 나중에 넣었던 동전을 먼저 꺼내야 한다.

 

Message Queue

이렇게 먼저 넣은 값이 먼저 출력되는 구조를 이용해 메시지3여기서 말하는 메시지는 특별한 개념이 아니다. 송/수신되는 데이터를 종류, 형태와 상관 없이 통틀어 메시지라고 칭하는 것이다. 이 메시지는 단순한 텍스트일 수도 있고, 파일일 수도 있고 다양하다.를 전송하는 것이 Message Queue이다. Rabbit MQ, IBM MQ, Apache active MQ , Rocket MQ 등 다양한 종류의 Message Queue가 존재한다.
기본적인 개념은 모두 같지만 메시지를 주고 받는 방식에 따라 크게 두 종류로 구분할 수 있다.
– Push : 서버가 메시지를 클라이언트에 보내주는 방식
– Pull : 클라이언트가 메시지를 서버에서 가져오는 방식

별것 아닌 것 같지만 Pull 과 Push는 큰 차이를 가진다.

종류PushPull
장점· 메시지 발생 즉시 클라이언트에 전달· 필요한 클라이언트만 메시지를 가져가므로 서버 부하 감소
· 네트워크 부하 감소
단점· 서버가 모든 클라이언트에 연결해야 하므로 서버 부하 증가· 메시지를 전달한 클라이언트 확인 불가
주 용도카카오톡 등 메시지, 알림 전달분석용 서버 로그 데이터 등
Push 방식과 Pull 방식 비교

 

Apache Kafka

Apache Kafka는 Pull 방식의 Message Queue이다.
중요한 개념으로 메시지를 발생 시키는 (또는 서버의 Queue에 메시지를 보내는) Producer(또는 Publisher)와 메시지를 가져가는 Consumer(또는 subscriber)가 있다.4실제 이 프로듀서와 컨슈머는 추상적인 개념으로만 존재하며 Kafka 자체를 칭하지는 않고 Kafka를 구성하는 구성요소는 아니다!!

일반적인 개념에서 Kafka는 Broker를 의미한다.

즉, 누군가 메시지를 보내는 곳, 누군가 메시지를 꺼내갈 곳이 Kafka 이다. 5물론 kafka connect, mirror-maker 등 카프카가 직접 메시지를 읽어오는 개념이 존재하긴 하다. 하지만, 어쨌거나 프로듀서, 컨슈머 등을 이야기하는 개념에서의 kafka는 broker 를 떠올리면 된다.

이 Kafka Broker가 하는 일과 핵심적인 개념은 다음과 같다.

  • Queue : 가장 핵심적인 기능이다. 수신된 메시지를 저장한다. kafka가 인지하는 형식으로 디스크에 저장된다.
  • Offset 관리 : 프로듀서가 보낸 메시지와 컨슈머가 가져간 메시지의 offset, 즉, 몇 개의 메시지가 수신되었고 어떤 클라이언트가 어디서부터 어디까지의 메시지를 가져갔는지 기억하고 관리한다.
  • Topic : Topic은 앞서 설명한 메시지를 담는 파이프 하나를 떠올리면 된다. 메시지를 넣을 파이프를 만들고 이름을 붙여서 관리한다. 이 Topic은 여러개의 Pratition으로 나뉠 수 있다.
  • Replica : 데이터의 복제, Broker나 디스크의 장애 등에 대비해 데이터를 복제하는 기능이다.

 

Public cloud에서

AWS : MKS(Managed Kafka Service)
GCP : Pub/Sub (Publisher와 Subscriber)
AZURE: HDInsight Kafka

 

 

 

 

 

Kubernetes #4-3. Kubernetes 클러스터 구축 – worker node join (offline, 폐쇄망)

[Kubernetes #1. 사전작업 (offline, 폐쇄망)]
[Kubernetes #2-2. 사전작업 – 컨테이너 런타임 (offline, 폐쇄망)]
[Kubernetes #2-2. 사전작업 – docker 설정 (offline, 폐쇄망)]
[Kubernetes #3. Kubernetes 바이너리 설치 (offline, 폐쇄망)]
[Kubernetes #4. Kubernetes 클러스터 구축 – image pull (offline, 폐쇄망)]
[Kubernetes #4-2. Kubernetes 클러스터 구축 – 단일 마스터노드 생성 (offline, 폐쇄망)]
[Kubernetes #4-3. Kubernetes 클러스터 구축 – worker node join (offline, 폐쇄망)]

Worker node cluster join

Dockerkubernetes 구성 요소를 설치한 뒤 이전 포스트에서 cluster 초기화 시 생성된 스크립트를 실행하면 worker node로써 설정이 된다.

kubeadm join 192.168.4.78:6443 --token abcdefg.8rpr4mfmetbabcde --discovery-token-ca-cert-hash sha256:3a12345caaef12334567890cd3953d1234c3904ab70a8b949f32d6df12345

[preflight] Running pre-flight checks
[preflight] Reading configuration from the cluster...
[preflight] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Starting the kubelet
[kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap...

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the control-plane to see this node join the cluster.

worker 노드에서도 kubernetes config 관련 명령을 수행해주면 kubectl 명령을 이용할 수 있다.

kubectl get nodes

NAME       STATUS     ROLES                  AGE    VERSION
centos7    NotReady   control-plane,master   104s   v1.23.5
centos71   NotReady   <none>                 36s    v1.23.5

master node 설정 후 확인한 것과 같이 STAUS는 NotReady 상태로 표시된다. 이는 kubernetes 네트워크 관련 배포가 필요한 것으로 이후 관련 인스턴스를 배포하면 Ready 상태로 표시된다.

 

cluster 생성 후 24시간 경과 시

kubeadm init 수행 시 생성된 join 스크립트의 token은 24시간의 만료 시간을 가진다. 즉 24시간이 지나면 생성된 join script, 정확히 말하자면 token이 만료되어 사용이 불가능하다.

따라서 24시간 이후에는 갱신된 token을 확인하고 새 token을 이용한 join 스크립트를 사용해야 한다.

  • token 확인: TTL(Time To Live) 값을 보면 22h시간 사용가능함을 알 수 있다.
kubeadm token list
TOKEN                     TTL         EXPIRES                USAGES                   DESCRIPTION                                                EXTRA GROUPS
abcdef.2zha2oqwp12abcd1   22h         2022-04-08T00:46:45Z   authentication,signing   The default bootstrap token generated by 'kubeadm init'.   system:bootstrappers:kubeadm:default-node-token
  • 해당 token에 해당하는 sha256 값 확인
openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'
871c73bfcb0d0421f029faa7ba07201abf4f00abcdefghijklmnopqrstuvwxyz
  • 확인된 token, 과 sha256 값을 이용하여 join 명령을 수행한다.
kubeadm join 192.168.4.78:6443 --token abcdef.2zha2oqwp12abcd1 --discovery-token-ca-cert-hash sha256:871c73bfcb0d0421f029faa7ba07201abf4f00abcdefghijklmnopqrstuvwxyz