sjo200 - CS 대학원 수업 정리 블로그

ogg 설치 가이드에는 example도 없고 블로그 글들은 버전 명시도 잘 안되있고 오타도 많아서 기록한다.

binary 설치 후 진행되는 과정이며, ogg home의 ./ggsci 를 실행하면 인터페이스 실행이 가능하다.

- source

GGSCI > CREATE SUBDIRS
SQL > ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
SQL > ALTER SYSTEM SWITCH LOGFILE;
GGSCI > edit params mgr

PORT 7809

GGSCI > add trandata test.t1
GGSCI > ADD EXTRACT EXT01, TRANLOG, BEGIN NOW
GGSCI > edit params extcdc01

extract extcdc01
userid test, password test
exttrail ./dirdat/01
BR BROFF
DISCARDFILE ./dirout/extcdc10.dsc, append
rmthost 192.1.2.75, mgrport 7809
table test.t1;

GGSCI > ADD EXTTRAIL ./dirdat/01, EXTRACT EXT01, MEGABYTES 10
GGSCI > add extract pmp01, exttrailsource ./dirdat/01, begin now
GGSCI > edit params pmp01   

extract pmp01
passthru
rmthost 192.1.2.75, mgrport 7809
rmttrail ./dirtest/11
table test.t1;GGSCI > ADD RMTTRAIL ./dirtest/11, EXTRACT PMP01

ogg_home$touch ./dirdef/tbdef.def

GGSCI > EDIT PARAMS DEFGEN   

defsfile ./dirdef/tbdef.def
userid test password test
table test.t1;

- target

GGSCI > EDIT PARAMS ./GLOBALS (대문자 주의)

checkpointtable test.chkpt

GGSCI > dblogin test@orcl, PASSWORD test
GGSCI > add checkpointtable
GGSCI > add replicat rep01, exttrail ./dirdat/01
GGSCI > edit params rep01   

replicat rep01
setenv (ORACLE_SID="orcl")
userid test, password test
sourcedefs ./dirdef/tbdef.def
discardfile ./dirrpt/rep01.dsc, append
map test.t1, target test.t2, keycols (c1);

- tip
vim ogg_home/ggserr.log (기동 중 로그 확인)

GGSCI > delete [ext01|pmp01|rep01] (프로세스 삭제)

GGSCI > info all (전체 확인)
GGSCI > info [ext01|pmp01|rep01] detail (프로세스 상세 확인)

트랜잭션의 격리 수준에는 4 가지가 있다. 두 tx A, B가 함께 begin해서 동시에 진행된다고 생각하고 낮은 수준부터 차례대로 문제점을 짚어본다. 당연히 낮은 레벨은 상위 레벨의 문제점을 포함하며, 간략한 설명을 위해 나만의 pseudo 쿼리로 설명한다.

 1. dirty read

A - insert x (not committed)

B - select * -> x가 보임

dirty read

 2. read commited

A - insert x, commit

A - update x set a

B - select * -> commit 전이므로 a가 보인다.

A - commit

B - select * -> commit 이후이므로 x가 보인다. tx B는 조회할때마다 다른 결과를 볼 수 있는 문제가 있다.

non-repeatable reads

 3. repeatable read (MySQL을 제외한 대부분 DB는 기본적으로 read committed이고, for update 구문을 쓰면 repeatable read가 된다.)

B - select count(*) -> 3이 나왔다면,

A - insert x, commit

B - select count(*) -> 4가 나온다. (A의 commit 이후 새 row가 보인다. 조회할때마다 추가된 row가 보일 수 있는 문제가 있다.)

phantom reads

 4. serializable

없음

아래는 예제를 이해하기 쉽게 그림으로 잘 나타낸 글이다.

https://nesoy.github.io/articles/2019-05/Database-Transaction-isolation

undo segment 사용법에 따라 레벨이 나눠지는데, read committed라고 해서 undo segment에 txid를 저장하지 않을리는 없다. 다만 repeatable read를 하게되면 특정 xid 이전까지 undo record chain을 쭉 따라가야 하는 overhead가 있고, undo retention이 끝나서 실패할 위험도 있다. 그래서 다들 read committed를 쓰는 듯 하다.

 - 개념

Kafka는 Kafka cluster로 운영되고, cluster는 브로커의 집합이다.

브로커는 프로듀서에게 메세지를 받아서 저장하고, 컨슈머는 메세지를 차례대로 꺼내간다. 

브로커가 여럿일 경우, 일련의 메세지를 파티션으로 나누어 분산 처리할 수 있다.

k개의 브로커에 대해 파티션 x번은 x%k번째 브로커가 리더로서 저장한다.(모든 브로커가 저장하긴 한다.)

그러나 파티션 별로 ordering이 보장이 될 뿐이라, 일련의 메세지를 순서대로 재구성하려면 파티션을 사용하면 안된다.

 - exactly-once

메세지를 주고받을때, at least once / at most once / exactly once라는 semantic 종류가 있다.

Kafka 초기 버전은 at least once를 보장하여 네트워크 장애로 인해 중복되는 메세지를 막을 방법이 없었다.

그러나 1.0.0 부터인가 enable.idempotence 기능이 추가되면서 exactly once가 보장되기 시작한다.

또한, 0.11.0 부터 transactional messaging 기능이 추가되었기에, 이를 사용하면 producer 측에서도 exactly once를 보장할 수 있을 것이다. 이는 아래에서 자세히 설명한다.

enable.idempotence는 정확히 말하면 Kafka에서 exactly-once를 보장한다는 의미인데, producer와 consumer는 알아서 application에서 잘 처리해서 exactly-once를 만들어야 된다. 해당 기능은 연결되는 producer마다 PID(producer ID, 32bit)를 부여하고 메세지마다 serial number(64bit)를 붙여서 네트워크 장애로 인해 여러번 메세지가 와도 broker가 중복을 막을 수 있다는 말이다. producer는 죽었다가 재연결하면 PID가 새로 발급되기 때문에, producer가 죽었다가 재연결한 뒤 같은 메세지를 보내면 이는 중복을 막을 수 없다. 만약 PID와 serial number를 producer application이 설정할 수 있다면 그나마 쉽게 producer측 exactly-once를 구현할 수 있을텐데, 약간 아쉬운 기능이다.

 ※ 참고로 ogg-bd의 kafka handler는 자기네 옵션 중 blocking send(ack=all), tx mode(=tx)를 켜면 exactly-once를 지원한다고 한다. 즉, 아마 ogg-bd 또한 idempotence 기능과 transactional messaging을 사용해서 구현할 것이다.

 - producer / consumer의 exactly-once 구현

producer는 메세지를 보내는 동시에(atomic하게) 자신의 디스크에 워터마크를 쓸 수 없기 때문에 producer application의 exactly-once는 만들기 어려운 감이 있다. consumer는 읽어서 처리한 후에 워터마크를 찍어놓고 죽었다가 다시 켜면 확인하도록 해서 (producer보단 쉽게?)exactly-once가 된다.

producer의 exactly-once는 다음과 같이 구현할 수 있다. 메세지 하나에 오라클의 scn같은 serial number를 붙이면서, 같은 tx에 serial number 값을 producer만 보는 토픽 t로 보내서 저장하면 producer가 죽었다가 다시 깨어나도 kafka가 어디까지 받았는지 토픽 t를 통해 알 수 있기 때문이다.(producer application이 토픽 t를 consume한다는 가정이다.)

추가적인 방법으로는, 메세지가 멱등 연산만을 보내도록 제한하는 방법이다. 메세지가 중복되어 수신자가 두 개의 같은 메세지를 보고 똑같이 어떤 함수를 실행해도, 멱등 연산이라면 최종적인 결과에는 영향이 없기 때문이다. 다만 보내려는 메세지를 멱등 연산으로 만들려면 추가적인 정보(ex 연산에 대한 UUID)가 필요하기도 하는 등 섬세한 설계가 필요하다.

참고자료:

idempotence producer features: https://www.cloudkarafka.com/blog/2019-04-10-apache-kafka-idempotent-producer-avoiding-message-duplication.html

tx msg 한글 설명: https://gunju-ko.github.io/kafka/2018/03/31/Kafka-Transaction.html

kafka 공식 producer API: https://kafka.apache.org/20/javadoc/org/apache/kafka/clients/producer/KafkaProducer.html

 - CAP 이론

생략

 - PACELC 이론

CAP 이론을 대체하기 위해 나온 이론이다. CAP 이론은 정상 상황일때를 서술하지 못한다.

Partition(네트워크 장애 상황)되면 A(availability) or C(consistency)를 골라야하고, E(else - 아니면) L(latency) or C를 골라야한다는 말에서 PACELC가 되었다. 분산 DB에서 파티션일때 C를 포기하고 A를 선택해서 모든 DB에 반영하기보다는 접근 가능한 노드에만 반영하면 PA, 반대로 기다려서 C를 선택하면 PC 이며, 정상상황일때 빠르게 처리하기 위해 몇몇 DB에만 반영하면 L를 선택하므로 EL, 모든 DB에 반영하기 위해 기다리면 EC이다.

http://eincs.com/2013/07/misleading-and-truth-of-cap-theorem/

https://ohjongsung.io/2019/05/01/cap-%EC%9D%B4%EB%A1%A0%EA%B3%BC-pacelc-%EC%9D%B4%EB%A1%A0

1. 클라이언트에서 서버로 접속할 때, 부하가 많을 경우 백엔드 서버를 여러개 구성하고 로드 밸런서를 쓰면 각 머신 별 부하를 줄일 수 있다. 현재 사용되는 방법은 Sidecar Proxy라고 한다.

자세한 설명(비추): http://aosabook.org/en/distsys.html

참고 원본: https://blog.envoyproxy.io/introduction-to-modern-network-load-balancing-and-proxying-a57f6ff80236

잘 정리된 번역본: https://ziwon.dev/post/modern-network-load-balancing-and-proxying/

2. 네이버 d2의 L4 스위치 대체를 위한 HAProxy 소개에서는, HAProxy를 고가용성 standby 구성을 위한 소프트웨어 로드 밸런서로 소개하고 L4 스위치를 하드웨어 로드 밸런서로 소개한다.

링크: https://d2.naver.com/helloworld/284659