꿩이야기

# [Bash] 스크립트 #! 의미

#!는 스크립트 제일 앞에서

어떤 명령어 해석기를 이용하여 파일을 실행할 것인지를 명시하는 것이다.

리눅스에서는 기본적으로 파일을 실행할때 bash 쉘로 설정되어 있어서

따로 명시를 하지 않아도

#!/bin/bash
#!/bin/sh

위의 bash 쉘로 자동 실행되게 한다.

다음의 예시를 통해 눈으로 확인해보자.

[root@chuchu test]# cat test1.sh 
#!/bin/bash

echo "Hello World!"
[root@chuchu test]# cat test2.sh 
#!/bin/cat

echo "Hello World!"
[root@chuchu test]# 
[root@chuchu test]# ./test1.sh 
Hello World!
[root@chuchu test]# ./test2.sh 
#!/bin/cat

echo "Hello World!"

참고: https://hahoital.tistory.com/145

To be continued.........

Made by 꿩

# [Bash] 터미널 jar 파일 생성

1. java 파일 생성

# cat Hello.java 
public class Hello {
  public static void main(String args[]){
    System.out.println("hello world");
  }
}

2. 컴파일

# javac Hello.java

3. manifest.txt 파일 생성

# cat manifest.txt 
Main-class: Hello

※ manifest.txt 파일이란? jar로 패키지된 파일 구성요소의 메타 정보를 가지고 있는 파일이다.

4. jar 파일 생성

# jar -cvmf manifest.txt hello.jar Hello.class 
Manifest를 추가함
추가하는 중: Hello.class(입력 = 415) (출력 = 286)(31%를 감소함)

5. jar 파일 실행

# java -jar hello.jar 
hello world

To be continued.........

Made by 꿩

# [centos] java openjdk 설치 및 삭제

1. java 설치현황 파악

# rpm -qa | grep jdk
java-11-openjdk-11.0.12.0.7-0.el7_9.x86_64
java-1.8.0-openjdk-headless-1.8.0.302.b08-0.el7_9.x86_64
copy-jdk-configs-3.3-10.el7_5.noarch
java-11-openjdk-devel-11.0.12.0.7-0.el7_9.x86_64
java-11-openjdk-headless-11.0.12.0.7-0.el7_9.x86_64
java-1.7.0-openjdk-headless-1.7.0.261-2.6.22.2.el7_8.x86_64

2. java 삭제

yum remove java-11-openjdk-devel.x86_64 -y

3. java 설치

yum install java-11-openjdk-devel.x86_64 -y

echo 'export JAVA_HOME=/usr/lib/jvm/jre-openjdk' > /etc/profile.d/java.sh
echo 'setenv JAVA_HOME "/usr/lib/jvm/jre-openjdk"' > /etc/profile.d/java.csh

4. java 설치 확인

# java -version
openjdk version "11.0.12" 2021-07-20 LTS
OpenJDK Runtime Environment 18.9 (build 11.0.12+7-LTS)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.12+7-LTS, mixed mode, sharing)

# javac -version
javac 11.0.12

To be continued.........

Made by 꿩

# Redis 메모리 & 시간 측정 스크립트

Python으로 redis 테스트 시 메모리와 시간 측정을 위한 스크립트

#!/bin/sh
 
### help message
function help() {
/bin/cat << EOF
Usage :
    redis_test.sh [-n/--filename] filename [-f/--flushall] [-h/--help]
EOF
}
    
### flag
INPUT_FILE=False
  
### check parameter
while (("$#")); do
    case "$1" in
        -n|--filename)
            if [ -n "$2" ] && [ ${2:0:1} != "-" ]; then
                INPUT_FILE=$2
                shift 2
            else
                echo "[Error] Argument for $1 is missing" >&2
                exit 1
            fi
            ;;
        -f|--flushall)
            FLUSHALL=True
            shift
            ;;
        -h|--help)
            help
            exit 1
            ;;
        -*|--*) # unsupported flags
            echo "[Error] Unsupported flag: $1" >&2
            echo "$0 -h for help message" >&2
            exit 1
            ;;
        *)
            echo "[Error]: Arguments with not proper flag: $1" >&2
            echo "$0 -h for help message" >&2
            exit 1
            ;;
    esac
done
   
  
### check if input filename
if [ $# -eq 0 ] && [ "$INPUT_FILE" == "False" ]
  then
    echo "[Error] Please give me test file"
    help;
    exit 1;
fi
   
 
### flushall execution
if [[ "$FLUSHALL" == True ]]
then
    ok=`redis-cli FLUSHALL`
    echo "[Info] redis memory flush all : ${ok}"
fi
 
  
### check memory and time before test
before=`redis-cli INFO memory | grep 'used_memory:' | awk -F: '{print $2}'`
b=`echo "${before//[$'\t\r\n ']}"`
StartTime=$(date +%s)
  
### test execution
echo "[Info] test start"
################################################ 테스트 실행 파일
python3 $INPUT_FILE
echo "[Info] test end"
  
### check memory and time after test
after=`redis-cli INFO memory | grep 'used_memory:' | awk -F: '{print $2}'`
a=`echo "${after//[$'\t\r\n ']}"`
EndTime=$(date +%s)
  
used=$(expr $a - $b)
  
echo ""
echo ""
echo "####################################[result]################################################"
echo "[result] redis used memory ${used}"
echo "[result] It takes $(($EndTime - $StartTime)) seconds to complete this task."

[참고문서]
https://tyanjournal.com/tips/bash-command-line-option-parsing%ED%95%98%EA%B8%B0-%EC%98%B5%EC%85%98-%EB%B0%9B%EA%B8%B0/
https://knight76.tistory.com/entry/Redis-%EB%A0%88%EB%94%94%EC%8A%A4-%ED%85%8C%EC%8A%A4%ED%8A%B8%ED%9B%84-%EB%A9%94%EB%AA%A8%EB%A6%AC-%EC%B8%A1%EC%A0%95%ED%95%98%EA%B8%B0-redis-used-memory

To be continued.........

Made by 꿩

# Transaction과 Isolation Level

Transaction(트랜잭션)이란? 논리적인 작업의 최소 단위이다.

트랜잭션이 왜 필요할까?

하나의 작업이 있는데 여러번 연산을 해야하는 상황이 있다.

예를 들어, 친구에게 계좌이체를 한다고 해보자.

계좌이체라는 하나의 작업은 2가지 연산으로 구성된다.

1. 내 계좌에서 돈을 출금하는 UPDATE하는 연산

2. 친구 계좌에 돈을 입금하는 UPDATE하는 연산

만약 1번 작업은 수행됐는데 2번 작업에서 에러가 나면

내 계좌에서 돈이 빠져나갔는데

친구는 돈을 못받은 상황이 되는 것이다.

즉, 트랜잭션은 하나의 작업을 수행하는데

여러 개의 연산을 하나로 묶어서

전부 실행되야지 일부만 실행되면 안된다. "All or Nothing - 원자성"

트랜잭션이 성공적으로 수행이 되면

내 계좌에서 빠져나간 돈만큼의 돈이

친구 계좌에 들어온다. 즉, 일관성을 만족해야 하는 것이다.

내가 돈을 송금하는 동안 다른 친구도 그 친구에게 돈을 송금할 수 있다.

계좌이체 트랜잭션이 동시에 들어오는 경우

다른 트랜잭션이 영향을 줄 수 없게

트랜잭션의 격리성이 보장되야 한다.

트랜잭션이 반영된 후에도 시스템 장애가 발생하더라도

트랜잭션 작업 결과는 손실되지 않고 영구적으로 반영되야한다.

이를 지속성이라 한다.

정리하자면
트랜잭션은 ACID라는 4가지 특성을 만족해야 한다.
(Atomicity-원자성, Consistency-일관성, Isolation-격리성, Durability-지속성)

이 중에서 Isolation에 대해 더

자세히 알아보려고 한다.

DB에는 Isolation Level(트랜잭션 격리 수준)이라는 게 있다.

이는 하나의 트랜잭션이 조회 또는 변경 작업 중인데

다른 트랜잭션이 들어온 경우

어느 수준까지 데이터를 조회를 허용할지에 대해서 설정하는 것이다.

SQL 표준 Transaction Isolation Level에는 4가지가 있다.

1. Read Uncommitted

2. Read Committed

3. Repeatable Read

4. Serializable

1. Read Uncommitted는 커밋되지 않은 데이터도 읽을 수 있는 수준이다.

Select를 수행하는 경우 트랜잭션이 COMMIT 되지 않은 데이터를 읽을 수 있다(dirty read)

업데이트되지 않은 데이터를 읽는 것은 무결성을 깨뜨릴 위험성이 높다.

하지만 동시성이 향상되는 효과가 있기도 하다.

Oracle, PostgreSQL에서는 지원하지 않는다.

2. Read Committed는 커밋된 데이터만 읽을 수 있다.

Select문은 이전에 커밋된 데이터만 읽을 수 있고

Write 작업은 해당 트랜잭션이 끝날 때까지 waiting하게 된다.

트랜잭션에서 select가 여러번 있을때, 다른 트랜잭션에서 커밋을 하면

커밋 후의 select는 커밋된 데이터를 참조하게 된다.(non-repeatable read)

3. Repeatable Read는 트랜잭션 시작 시점 데이터만 읽을 수 있다.

동일 데이터 Write 작업은 Read Committed처럼 Waiting이 되고

이미 트랜잭션이 시작됐는데 다른 트랜잭션에서 데이터가 변경된 경우

해당 데이터를 Select할 때 변경이전의 트랜잭션 시작 지점의 데이터를 읽게 된다.

4. Serializable은 모든 읽기 작업은 shared lock을 가진다.

즉, 다른 트랜잭션은 해당 데이터를 변경하지 못한다.

만약 트랜잭션마다 consistency level이 다르면 어떻게 동작할까?

각 트랜잭션 특성을 생각하면 된다.

Repeatable Read 트랜잭션과 Serializable 트랜잭션이 있다고 가정하면

Serializable은 기본적으로 select만으로도 shared lock이 걸리므로

Repeatable Read 트랜잭션은 해당 데이터를 읽을 수 없다.

DB는 동시에 여러 client가 사용하게 되므로

성능면에서 동시성이 중요하고

데이터를 생각한다면 안정성이 중요하다.

그러나 이 두개를 모두 만족할 수는 없다.

서비스의 특성을 잘 파악하고

최적의 isolation level를 선택해서 잘 활용해야 할 것이다.

참고로 테스트는 MariaDB 10.2.11버전을 사용하였다.

[참고문서]
데이터베이스 개론(김연희 지음)
jupiny.com/2018/11/30/mysql-transaction-isolation-levels/
hyunki1019.tistory.com/111
blogs.oracle.com/oraclemagazine/on-transaction-isolation-levels
effectivesquid.tistory.com/entry/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-Isolation-Level

To be continued.........

Made by 꿩

# MVCC 동시성 제어

데이터베이스에는 많은 사용자들이 동시에 접근할 수 있다.

여러 사용자가 데이터를 변경할 수 있고

그와 동시에 데이터를 읽을 수도 있다.

그렇다면 데이터베이스는 어떻게 동시 접근을 처리할까?

MVCC는 Multi Version Concurreny Control의 약자로

Lock을 사용하지 않고 데이터 읽기의 일관성을 보장해주는 방법이다.

데이터에 접근하는 사용자는 접근한 시점의 데이터베이스의 스냅샷을 읽는다.

한 사용자가 데이터를 변경을 할 경우

데이터 변경이 완료(트랜잭션 commit)되기 전까지 변경사항을 볼 수 없다.

MVCC는 2가지의 구현방식이 있다.

1. MGA(Multi Generation Architecture)

MGA는 PostgreSQL에서 사용하는 방식이다.

어떤 데이터에 업데이트가 일어나면

기존 데이터는 그대로 두고 새로운 데이터가 추가된다.

그리고 기존 데이터에 표시가 된다.

MGA방식은 기존 데이터가 지워지지 않는다는 특징을 갖고 있다.

그래서 PostgreSQL는 주기적으로 VACUUM을 해줘야 하며

VACUUM을 하지 않을 경우, 실제 데이터보다 데이터 용량이 훨씬 큰 것을 발견할 수 있다.

또한 업데이트가 발생한 데이터의 물리적 위치가 변경이 되므로

업데이트를 할때마다 인덱스 수정작업이 항상 일어날 수 밖에 없다.

2. Rollback Segment 

Rollback Segment는 Oracle에서 사용하는 방식이다.

업데이트가 실행되면 기존 데이터 블록을 새로운 데이터로 변경하고

이전 데이터는 Rollback Segment에 보관된다.

데이터 변경 중, Select가 수행되면

Select쿼리는 SCN(System Commit Number)라는 고유한 번호를 가지고

데이터파일의 SCN을 비교한다.

이때, Select 쿼리의 SCN 번호보다 작은 데이터 파일의 SCN만 읽는다.

데이터가 변경되면 SCN이 변경되기 때문에

해당 데이터 파일은 변경 중 혹은 변경된 파일로 인식하고

Rollback Segment에서 이전 버전의 데이터 파일을 찾아 읽게 된다.

MGA와의 차이점은 업데이트 시 데이터의 물리적인 위치가 변경되지 않는다는 것이다.

즉, 업데이트 할때마다 인덱스 파일을 수정할 필요가 없고

Replication을 수행할 때 PK를 필수로 걸어 데이터를 판단할 필요가 없다.

물리적 위치를 사용하면 되기 때문이다.

게다가 이전 데이터가 보관되는 Rollback Segment에서 주기적으로 이전 데이터들을 지우기 때문에

PostgreSQL와 달리 VACCUM 작업을 할 필요가 없다.

[참고문서]
www.datanet.co.kr/news/articleView.html?idxno=116534
mysqldba.tistory.com/335
mangkyu.tistory.com/53

To be continued.........

Made by 꿩

# Kafka Connect 설정

필자가 설정하는 Kafka Connect 설정파일은 2개이다.
하나는 connect-distributed.properties 이고,
다른 하나는 connect-log4j.properties 이다.

connect-distributed.properties는 kafka connect 기본 설정 파일로 다음과 같다.

bootstrap.servers={kafka-ip1}:9092,{kafka-ip2}:9092,{kafka-ip3}:9092
 
producer.max.request.size=105000000
 
group.id=source-connect-cluster
 
#key.converter=org.apache.kafka.connect.json.JsonConverter
#value.converter=org.apache.kafka.connect.json.JsonConverter
#key.converter.schemas.enable=true
#value.converter.schemas.enable=true

key.converter=io.confluent.connect.avro.AvroConverter
key.converter.schema.registry.url=http://{schema-registry-ip1}:8081
value.converter=io.confluent.connect.avro.AvroConverter
value.converter.schema.registry.url=http://{schema-registry-ip2}:8081

offset.storage.topic=source-connect-offsets
offset.storage.replication.factor=3
offset.storage.partitions=25
 
config.storage.topic=source-connect-configs
config.storage.replication.factor=3
 
status.storage.topic=source-connect-status
status.storage.replication.factor=3
status.storage.partitions=5
 
offset.flush.interval.ms=10000
 
rest.host.name={kafka-connect-ip1}
rest.port=8083
 
rest.advertised.host.name={kafka-connect-ip1}
rest.advertised.port=8083
 
plugin.path=/home/kafka/plugins 

1. bootstrap.servers

Kafka 서버 ip와 port를 명시하면 된다.

2. producer.max.request.size

producer(kafka connector)가 메세지를 생산할때 최대 메세지 크기를 설정한다.

디폴트 최대 데이터 크기는 약 1MB 정도이다. 이 크기를 더 증가할 필요가 있을 경우 설정한다.

buffer memory 디폴트 최대 크기(buffer.memory)는 약 33MB이며

max.request.size를 33MB이상 설정하면 buffer memory 제한이 걸린다.

buffer memory 제한을 더 높이면 되지만 그럴 경우는 없고 있으면 문제가 있다는 것이다.

3. group.id

Kafka connect도 kafka처럼 클러스터를 형성할 수 있다.

Kafka connect 클러스터의 그룹을 구별하는 id로 같은 클러스터는 동일하게 설정한다.

4. key.converter / value.converter

메세지의 key와 value의 변환 클래스를 입력한다.

JsonConverter가 디폴트이며, AvroConverter를 사용하는 경우도 많은 것 같다.

Json보다 Avro 형식이 압축률이 더 좋다고 한다.

5. key.converter.schema.registry.url / value.converter.schema.registry.url

schema registry를 사용할 경우 설정한다.

6. offset.storage.*

Kafka Connector offset과 관련된 설정이다.

7. config.storage.*

Kafka Connector config와 관련된 설정이다.

8. status.storage.*

Kafka Connector status과 관련된 설정이다.

9. offset.flush.interval.ms

task들의 Kafka Connector offset을 커밋하는 interval 값이다.

10. rest.host.name / rest.port

REST API의 hostname과 port를 설정한다.

11. rest.advertised.host.name / rest.advertised.port

다른 worker들이 연결하는데 사용될 hostname과 port를 설정한다.

12. plugin.path

connector plugin이 들어있는 디렉토리 경로를 설정한다.

connect-log4j.properties 파일은 kafka connect에서 생성되는 로그설정에 관한 파일이다.

log4j.rootLogger=INFO, stdout, connectAppender
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
 
log4j.appender.connectAppender=org.apache.log4j.RollingFileAppender
log4j.appender.connectAppender.File=${kafka.logs.dir}/connect.log
log4j.appender.connectAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.connectAppender.MaxFileSize=100MB
log4j.appender.connectAppender.MaxBackupIndex=50
log4j.appender.connectAppender.append=true
 
connect.log.pattern=[%d] %p %X{connector.context}%m (%c:%L)%n
 
log4j.appender.stdout.layout.ConversionPattern=${connect.log.pattern}
log4j.appender.connectAppender.layout.ConversionPattern=${connect.log.pattern}
 
log4j.logger.org.apache.zookeeper=ERROR
log4j.logger.org.reflections=ERROR

1. log4j.appender.connectAppender

첫 설치시 DailyRollingFileAppender로 설정이 되어있을 것이다.

DailyRollingFileAppender는 매시간 또는 매일 마다 로그파일이 새로 생기지만

파일 최대크기와 파일 최대개수를 지정할 수 없다는 단점이 있다.

개인적으로는 DailyRollingFileAppender을 추천한다.

2. log4j.appender.connectAppender.File

로그 파일이 생성되는 경로와 로그파일 이름을 설정한다.

3. log4j.appender.connectAppender.MaxFileSize

로그 파일의 최대 크기를 설정한다.

4. log4j.appender.connectAppender.MaxBackupIndex

로그 파일의 최대 개수를 설정한다.

5. log4j.appender.connectAppender.append

kafka connect가 restart시 로그파일에 append할 것인지에 대한 설정이다.

5. connect.log.pattern

로그 출력시 어떤 형식으로 나올지에 대한 설정이다.

중간에 {connector.context}를 넣으면 해당 로그가 어떤 커넥터에서 나온건지 알 수 있다.

To be continued.........

Made by 꿩

# Kafka Connect란?

Kafka의 구성은 Producer, Consumer, broker로 되어있다.

Producer는 카프카 메세지를 생산하는 주체이고,
Consumer는 카프카 메세지를 소비하는 주체이며,
Broker는 카프카 메세지를 저장하는 서버이다.

각 Broker는 여러개 topic을 가지고 있으며 이 topic에 메세지가 저장된다.

Kafka Connect는 데이터소스와 Kafka를 연결해주는 매개체이다.
Kafka Connect에는 Connector를 이용하여 데이터소스와 연결한다.
다시말해서, Kafka Connector가 Producer와 Consumer 역할을 한다고 보면 된다.

Producer 역할을 하는 Kafka Connector를 Source Connector라 하고,
Consumer 역할을 하는 Kafka Connector를 Sink Connector라 한다.

위의 그림은 kafka Source Connector 오픈소스인 Debezium 공식문서에서 가져온 그림이다.
그림을 보면, MySQL과 PostgreSQL의 데이터 소스에서 데이터가 Debezium Source Connector에 의해 Kafka에 저장이 된다. 그리고 메세지들은 Sink Connector에 의해 다양한 데이터 소스로 전달할 수 있다.

다음은 Kafka Connector가 만들어 내는 메세지의 구조이다.

Message는 Key와 Value로 구성되어 있으며,
각 Key와 Value는 Schema와 Payload로 구성되어 있다.

여기서 Key는 PK와 같이 데이터를 식별할 수 있는 정보가 들어있고
Value는 데이터의 전체 값이 들어있다.

Payload는 데이터 값이 저장이 되며, 이 데이터 값의 데이터 타입이 Schema에 명시되어 있다.

동일한 메세지가 계속 들어오는 경우 Schema가 중복이 되어 불필요하게 데이터 용량을 잡아먹게 된다.
이를 위해 Kafka Connect는 Schema Registry를 활용한다.

Schema Registry는 Key와 Value에 명시된 Schema를 따로 저장하며,
Kafka Connector는 Schema 대신 Schema Registry의 Schema 번호를 명시하여 메세지 크기를 줄인다.

Kafka Connect는 REST API를 이용하여 Connector를 설정할 수 있다.

# kafka connect 실행
./bin/connect-distributed.sh -daemon ./config/connect-distributed.properties

# kafka connect 실행확인
curl -s "http://{ip}:8083"           
{"version":"2.4.1","commit":"c57222ae8cd7866b","kafka_cluster_id":"nZrPY3j5SKOUwqeGk68dsg"}

# 사용할 수 있는 플러그인
curl -X GET -s "http://{ip}:8083/connector-plugins"
[{"class":"io.confluent.connect.elasticsearch.ElasticsearchSinkConnector","type":"sink","version":"5.5.1"},{"class":"io.confluent.connect.jdbc.JdbcSinkConnector","type":"sink","version":"5.5.1"},{"class":"io.confluent.connect.jdbc.JdbcSourceConnector","type":"source","version":"5.5.1"},{"class":"io.confluent.connect.s3.S3SinkConnector","type":"sink","version":"5.5.1"},{"class":"io.confluent.connect.storage.tools.SchemaSourceConnector","type":"source","version":"2.4.1"},{"class":"io.debezium.connector.mysql.MySqlConnector","type":"source","version":"1.3.1.Final"},{"class":"io.debezium.connector.postgresql.PostgresConnector","type":"source","version":"1.2.1.Final"},{"class":"org.apache.kafka.connect.file.FileStreamSinkConnector","type":"sink","version":"2.4.1"},{"class":"org.apache.kafka.connect.file.FileStreamSourceConnector","type":"source","version":"2.4.1"},{"class":"org.apache.kafka.connect.mirror.MirrorCheckpointConnector","type":"source","version":"1"},{"class":"org.apache.kafka.connect.mirror.MirrorHeartbeatConnector","type":"source","version":"1"},{"class":"org.apache.kafka.connect.mirror.MirrorSourceConnector","type":"source","version":"1"}]

# kafka connector 확인
curl -X GET -s "http://{ip}:8083/connectors"
["test-connector"]

# kafka connector 설정확인
curl -X GET -s "http://{ip}:8083/connectors/test-connector/config"

# kafka connector 상태확인
curl -X GET -s "http://{ip}:8083/connectors/test-connector/status"

# kafka connector 삭제
curl -X DELETE -s "http://{ip}:8083/connectors/test-connector"

Kafka Connect를 사용해보고자 한다면,

Source Connector 오픈소스인 Debezium을 추천한다.
Sink Connector는 Confluent사에서 개발한 Connector를 이용하자.

Confluent hub(https://www.confluent.io/hub/)에는 Confluent에서 개발한 다양한 Connector를 다운받을 수 있다.
각 Connector가 Source인지 Sink인지 명시가 되어 있으며 무료 라이센스일 것이다.

참고자료
debezium.io/documentation/reference/1.3/architecture.html
mongsil-jeong.tistory.com/35

To be continued.........

Made by 꿩