미로

1. ec2 - jenkins 설치 

jenkins 설치를 위해 사이즈를 기존 default 사이즈가 아닌 t2 large 로 

*보안그룹은 jenkins 가 들어올 포트와 alb 포트 가 필요 하다. 프리티어 계정이라 패스 

접속 이후 에는  

관리자 권한으로 변경 이후  yum update 진행 

jenkins 설치
sudo wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo
sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key
sudo yum install -y jenkins


jenkins 설치 확인 
rpm -qa | grep jenkins

node js 설치 
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.34.0/install.sh | bash
. ~/.nvm/nvm.sh
nvm install 16  실습 code 는  node 16

java maven 설치 
yum install -y java java-devel maven

## git
yum install -y git

## ansible
yum install ansible
(amazon-linux-extras X)sudo amazon-linux-extras install -y ansible2 



# 배포 서버에 nginx
yum install nginx -y
(amazon-linux-extras X)sudo amazon-linux-extras install -y nginx1

# 젠킨스시작

systemctl start Jenkins
* 실패 시 yum update

* systemctl enable jenkins
* systemctl start jenkins
* journalctl -u jenkins


** java version 수정
wget https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/download/jdk8u292-b10/OpenJDK8U-jdk_x64_linux_8u292b10.tar.gz




#젠킨스 실행확인
ps-ef | grep jenkins

아래 자바 버전 변경 참조 ( javac 도 동일한 방법으로 변경 가능)

https://velog.io/@mcyoo/AWS-EC2-JAVA-%EB%B2%84%EC%A0%84-%EB%B0%94%EA%BE%B8%EA%B8%B0

최종 실행 시  아래와 같은 화면 확인 가능

이미지 안에 경로 복사하여 
cat 명령어로 패스워드 확인가능

권장설치 선택 

계정 생성 이후  우리가 알던 그 젠킨스 확인 가능

jenkins node 설치아후 툴 설정에서 nodejs 추가

jenkins 파이프라인 설정

스크립트 작성 

ec2 key jenkins 서버 업로드

프로그램 사용 혹은 아래 명령어 통해서 업로드 

scp -i ~/Downloads/my-ec2-keypair.pem ~/Downloads/my-ec2-keypair.pem ec2-user@my-ip:/home/ec2-user

이후  jenkins 사용 할 수 있도록 파일 이동 및 권한 소유주 변경 

이후 젠킨스 빌드

1.Replication

DB에서도 많이 쓰는 개념

Partition을 복제(Replication)하여 다른 Broker상에서 복제물(Replicas)을 만들어서 장애를 미리 대비함

Replicas - Leader Partition, Follower Partition

broker에서 장애 발생시  메세지(데이터) 유실을 방지하기 위해서 쓰는 개념

위 이미지 와 같이  리더와 follower로 이루어짐

producner consumer 모두 리더 broker 에서 IO 발생

Follower는 Broker 장애시 안정성을 제공하기 위해서만 존재

Follower는 Leader의 Commit Log에서 데이터를 가져오기 요청(Fetch Request)으로 복제

아래는 리더 broker 장애시 동작 이다

kafak 클러스터는 리더 broker 장애 발 생시 새로운 leader broker 선출 이후 clinet는 자동으로 새로leader 로 전환

또 partition 리더는 하나의 broker에 몰려 있지 않고 분산되어야함 아래는  kafka 옵션 값 과 예시 이미지

마지막으로 rack 간에도 분산이 필요하다 

2. In-Sync Replicas(ISR)

리더 파티션과 동일한 데이터를 가지고 있는 레플리카를 의미함.

즉, 리더 파티션에 쓰여진 모든 데이터가 인-싱크 레플리카에 정확하게 복제되어 있어야 한다.

In-Sync Replicas(ISR)는 High Water Mark라고 하는 지점까지 동일한 Replicas (Leader와

Follower 모두)의 목록

Leader에 장애가 발생하면, ISR 중에서 새 Leader를 선출

max.messages =4 인 경우 

replica.lag.max.messages 옵션은 Kafka 클러스터에서 리더 복제본(leader replica)과 팔로워 복제본(follower replica) 간의 복제 지연(replication lag)을 제어하는 데 사용됩니다. 이 옵션은 팔로워 복제본이 리더 복제본으로부터 얼마나 많은 메시지 뒤처질 수 있는지를 최대 메시지 수로 지정합니다.

replica.lag.max.messages 로 ISR 판단 시 나타날 수 있는 문제

메시지가 항상 일정한 비율(초당 유입되는 메시지, 3 msg/sec 이하 )로 Kafka로 들어올때, replica.lag.max.messages=5로 하면 5 개 이상으로 지연되는 경우가 없으므로 ISR들이 정상적으로 동작

메시지 유입량이 갑자기 늘어날 경우(예, 초당 10 msg/sec), 지연으로 판단하고 OSR(Out-of-Sync Replica)로 상태를 변경시킴

실제 Follower는 정상적으로 동작하고 단지 잠깐 지연만 발생했을 뿐인데,
replica.lag.max.messages 옵션을 이용하면 OSR로 판단하게 되는 문제가 발생 (운영중에불필요한 error 발생 및 그로 인한 불필요한 retry 유발)

실제로는 위 메세지 수가아닌 ms 로 판단(replica.lag.time.max.ms)이 적합

Follower가 Leader로 Fetch 요청을 보내는 Interval을 체크

예) replica.lag.time.max.ms = 10000 이라면 Follower가 Leader로 Fetch 요청을 10000 ms 내에만 요청하면 정상으로 판단

Confluent 에서는 replica.lag.time.max.ms 옵션만 제공(복잡성 제거)

Follower가 너무 느리면 Leader는 ISR에서 Follower를 제거하고 Zookeeper에 ISR을 유지

Controller는 Partition Metadata에 대한 변경 사항에 대해서 Zookeeper로 수신

2-1 Controller 

Kafka Cluster 내의 Broker중 하나가 Controller가 됨

Controller는 ZooKeeper를 통해 Broker Liveness를 모니터링

Controller는 Leader와 Replica 정보를 Cluster내의 다른 Broker들에게 전달

Controller는 ZooKeeper에 Replicas 정보의 복사본을 유지한 다음 더 빠른 액세스를 위해 클러스터의 모든 Broker들에게 동일한 정보를 캐시함

Controller가 Leader 장애시 Leader Election을 수행

Controller가 장애가 나면 다른 Active Broker들 중에서 재선출됨

2-2 Consumer관련 Position 

Last Committed Offset(Current Offset) : Consumer가 최종 Commit한 Offset

Current Position : Consumer가 읽어간 위치(처리 중, Commit 전)

High Water Mark(Committed) : ISR(Leader-Follower)간에 복제된 Offset

Log End Offset : Producer가 메시지를 보내서 저장된, 로그의 맨 끝 Offset

ISR Fully Committed 의미

2-3High Water Mark

• 가장 최근에 Committed 메시지의 Offset 추적

• replication-offset-checkpoint 파일에 체크포인트를 기록

2-4Leader Epoch

• 새 Leader가 선출된 시점을 Offset으로 표시

• Broker 복구 중에 메시지를 체크포인트로 자른 다음 현재 Leader를 따르기 위해 사용됨

• Controller가 새 Leader를 선택하면 Leader Epoch를 업데이트하고 해당 정보를 ISR 목록의 모든 구성원에게 보냄

• leader-epoch-checkpoint 파일에 체크포인트를 기록

요약 하면 

In-Sync Replicas(ISR)는 High Water Mark라고 하는 지점까지 동일한 Replicas (Leader와 Follower 모두)의 목록

High Water Mark(Committed) : ISR(Leader-Follower)간에 복제된 Offset

Consumer는 Committed 메시지만 읽을 수 있음

Kafka Cluster 내의 Broker중 하나가 Controller가 됨

Controller는 ZooKeeper를 통해 Broker Liveness를 모니터링

배열과 제네릭에는 매우 다른 타입 규칙이 적용된다. 배열은 공변이고 실체화되는 반면, 제네릭은 불공변이고 타입 정보가 소거된다. 그 결과 배열은 런타임에는 타입 안전하지만 컴파일타임에는 그렇지 않다. 제네릭은 반대다. 그래서 둘은 섞어 쓰기란 쉽지 않다. 둘을 섞어 쓰다가 컴파일 오류나 경고를 만나면, 가장 먼저 배열을 리스트로 대체하는 방법을 적용해보자.

1.Producer

Producer - 메시지를 생상(Produce)해서 Kafka의 Topic으로 메시지를 보내는 애플리케이션

* Producer와 Cosumer는  서로 알지 못 하며, Producer와 Consumer는 가각 고유의 속도로 Commit Log 에 Write 및 Read 수행

*다른 ConsumerGroup에 속한 Consumer들은 서로 관련이 없으며, Commit Log에 있는 Event(Message)를 동시에 다른 위치에서Read할 수 있음

1-1 메세지 구조 

Message 는 Record 혹은 Event 혹은 Data 로 불림

Kafka는 Record(데이터)를 Byte Array로 저장(Producer는 Serializer, Consumer는 Deserializer)

아래 이미지에서 실제로 내가 할것은 send() 호출  호출전에는 옵션 여부 ? 정보 만 하면 이후는 카프카에서 알아서 처리된다.

1-2 Partitioner 

메세지를 Topic의 어떤 Partition으로 보낼지 결정( 지정 가능!)

아래는 default Partiotiner  역할 (Key가Null이 아닐때만 성립되기 때문에 key를 꼭 보내야 한다.)

아래는 key 가 null 일때 Default Partitiner 동작 

2.4 이전은 Round Robin 형식 , 2.4 이후에는 Sticky 형식 으로 

Partitiner는 개발 및 Custom하여 개발해서 교체가 가능하다.

2.Consumer

Consumer - Topic의 메시지를 가져와서 소비(Consume)하는 애플리케이션

ConsumerGroup

Consumer Group - Topic의 메시지를 사용하기 위해 협력하는 Consumer들의 집합

*하나의 Consumer는 하나의 Consumer Group에 포함되며, Consumer Group내의 Consuemr들은 협력하여 Topic의 메시지를 병렬처리

*Consumer 는 각각 고유의 속도로 Commit Log 로부터 순서대로 Read(Poll)을 수행

* 다른 Conumser Group에 속한 Consumer들은 서로 관련이 없으며, CommitLog에 있는 Event(Message)를 동시에 다른 위치에서Read할 수 있음

2-1. Cousmer Group이 없는 경우 

2-2. Cousmer Group이 있는 경우

동일한 GroupId지정 시  Conusmer들은 하나의 Consumer Group을 형성

4개의 Partition이 있는 Topic을  Conme 하는 4개의 Consumer가 하나의 Consumer Group에 있다면 각 Consumer는 정확히 하나의 Partition에서 Record를 Consumer함

Partition은 항상 Consumer Group내의 하나의 Consumer에 의해서만 사용

Consumer는 주어진 Topic에서 0개 이상의 많은 Partition을 사용할 수 있다.

키가 지정된 메세지 의 경우  partition별로 동일한 key를 가지는 메시지 저장

2-3 Message Ordering (메세지 순서) 

Partition 2개 이상ㅇ인 경우 모든 메세지에 대한 전체 순서 보장 불가

Partition 1개로 구성하면 모든 메세지 전체 순서 보장 가능(처리량은 떨어짐)

이때 아래예시 처럼 Key 를 통해  동일 Partition의 순서를 보장하여 처리 가능

* 운영중에는 Partiton 개수를 변경하면 안된다.( 변경 시 순서 보장 불가) 

2-4.Cardinality(특정 데이터 집합의 유니크(Unique)한 값의 개수)

위 내용 처럼 파티션 전체 데이터를 배포하기위해 키를 만들어  고르게 배포하는게 중요함.

2-5 Consumer Failure (Consumer Rebalancing )

Consumer Group에 4개의 Consumer 가 있고  4개의 파티션이 있다면 각 Consumer 가 각각 하나의 파티션 에서 record를 consume함 

Conusmer는 주어진 Topic 에서 0개 이상의 많은 Partiton 사용 가능

Consumer Group내의 다른 Consumer가 실패한 Consumer 를 대신하여 Partition에서 데이터를 가져와서 처리 

Partition은 항상 Consumer Group내의 하나의 Consumer에 의해서만 사용

총정리

Consumer가 자동이나 수동으로 데이터를 읽은 위치를 commit하여 다시 읽음을 방지

_ _consumer_offsets 라는 Internal Topic에서 Consumer Offset을 저장하여 관리

동일한 group.id 로 구성된 모든 Consumer들은 하나의 Consumer Group을 형성

다른 Consumer Group의 Consumer들은 분리되어 독립적으로 작동

동일한 Key를 가진 메시지는 동일한 Partition에만 전달되어 Key 레벨의 순서 보장 가능

Key 선택이 잘 못되면 작업 부하가 고르지 않을 수 있음

Consumer Group 내의 다른 Consumer가

비검사 경고는 중요하니 무시하지말자. 모든 비검사 경고는 런타임에 ClassCastException을 일으킬 수 있는 잠재적 가능성을 뜻하니 최선을 다해 제거하라. 경고를 없앨 방법을 찾지 못하겠다면, 그 코드가 타입 안전함을 증명하고 가능한  한 범위를 좁혀  @SuppressWarnings("unchecked") 어노테이션으로 경고를 숨겨라. 그런 다음 경고를 숨기기로 한 근거를 주석으로 남겨라.

제네릭 클래스와 제네릭 인텊에스를 통틀어 제네릭 타입이라 한다. 

가각의 제네릭 타입은 일련의 매개변수화 티입(Parameterized type)을 정의한다.

로 타입을 사용하면 런타임에 예외가 일어날 수 있으니 사용하면 안된다. 

로 타입이란 제네릭 타입에서 타입 매개변수를 전혀 사용하지 않을때를 말한다. 

로 타입은 제네릭이 도입되기 이전 코드와의 호환성을 위해 제공될 뿐이다. 빠르게 훑어보자면, Set<Object>는 어떤 타입의 객체도 저장할 수 있는 매개변수화 타입이고, Set<?>는 모종의 타입 객체만 저장할 수 있는 와일드카드 타입이다. 그리고 이들의 로 타입인 Set은 제네릭 타입시스템에 속하지 않는다. Set<Object>와 Set<?> 안전하지만, 로 타입인 Set은 안전하지 않다.