미로

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가

Broker, Zookeeper

1. Broker

Kafka Broker 는 Partition에 대한 Read 및 Write 를 관리하는 소프트웨어 

• kafka Broker는  Kafka Server 라고 부르기도함
• Topic 내의 Partition 들을 분산, 유지 및 관리 
• 각각의 Broker 들은 아이디로 식별됨 (단, ID는 숫자)
• Topic의 일부 Partition들을 포함(multi broker로 흩어져 있기때문에  전체가 아닌 일부만 갖고 있음)
• Kafka Cluster는 여러개의 Broker 로 구성
• Client는 특정 Broker에 연결하면 전체 클러스터에 연결됨
• 최소3대이상의 Broker를 하나의 Cluster 로 구성 (1cluster 안에  4개 Broker 권장) 

Broker ID와 Partition 아이디의 관계

Client

• Kafka Boker는 Bootstrap(부투스트랩) 서버라고 부름
• Client -> Broker 연결 시 Cluster 전체 열결되어 전체 Broker 리스트를 알 수 있다 
• 특정 Broker의 장애를 대비해 전체 Broker List(IP, PORT)를 파라미터로 입력 권장
• 각각의 Broker 는 모든 Broker, Topic, Partition에 대해 알고 있음(Metadata)

2. ZooKeeper

• ZooKeeper는 Broker들을 관리(Broker들의 목록 설정) 하는 소프트웨어이다.
• Zookeeper를 통해  변경사항을 감지하여 Kafka에 알림  -> Topic 생성 제거 , Broker 추가 제거
• Zookeeper 없이 Kafka 동작 불가 했음(4.0 이전 버전)  현재는 없이도 동작 가능
• Zookeeper는 홀수의 서버로 작동하도록 설계되어 최소 3개, 권장5개 이다
• Zookeeper는 Leader(Writes)와 나머지 Follower (reads)로 구성

• Zookeeper는 분산형 Configuration 정보 유지, 분산 동기화 서비스를 제공하고 대용량 분산 시스템을 위한 네이밍 레지스트리를 제공하는 소프트웨어 
• 분산 작업을  제어하기 위해Tree 형태의 데이터 저장소로 이용 -> 멀티 Kafka Broker들 간의 정보(변경 사항 포함) 공유 , 동기화 등을 수행
• Ensemble(앙상블)은 Zookeeper의 서버 클러스터 이다.
• Zookeeper는 Quorum(쿼럼) 알고리즘기반이며, Quorum은 정족수라는 뜻이면 합의체가 의사를 진행시키거나의결을 하는데 필요한 최소한도의 인원수를 뜻함 
• 분산코디네이션 환경에서 예상치 못한 장애가 발생해도 분산 시스템의 ㅇ리관성을 유지시키기 위해서 사용
•  
• Ensemble이 3대로 구성되었다면 Quorum은 2, 즉 Zookeeper 1대가 장애가 발생하더라도 정상 동작
• Ensemble이 5대로 구성되었다면 Quorum은 3, 즉 Zookeeper 2대가 장애가 발생하더라도 정상 동작
• 과반수 합의체를 위해 꼭 홀수로 구성

Cloudfront ALB 연동

테스트용 이라 도메인을 따로 사지 않아 연동하는 방법만 알아보는걸로

1. CloudFront 란

클라우드 프론트(CloudFront)**는 아마존 웹 서비스(AWS)에서 
제공하는 콘텐츠 전송 네트워크(CDN) 서비스입니다. 쉽게 말해
, 웹 사이트나 웹 애플리케이션의 콘텐츠를 전 세계에 분산된 서버에 미리 저장해두고, 사용자에게 가장 가까운 서버에서 
콘텐츠를 제공하는 기술입니다.

1-1. 장점

빠른 콘텐츠 전송: 사용자와 물리적으로 가까운 서버에서 콘텐츠를 제공하기 때문에 웹 페이지 로딩 속도가 빨라집니다.
높은 가용성: 전 세계에 분산된 서버를 사용하기 때문에 특정 지역의 서버에 문제가 발생하더라도 서비스가 중단되지 않고 계속 제공됩니다.
낮은 지연 시간: 콘텐츠를 사용자에게 빠르게 전달하여 사용자 경험을 향상시킵니다.
비용 절감: 자체적으로 CDN 인프라를 구축하는 것보다 비용 효율적입니다.

1-2. 주요 기능

캐싱: 자주 요청되는 콘텐츠를 서버에 미리 저장하여 빠른 응답을 제공합니다.
원본 서버 오프로드: 사용자의 요청을 원본 서버로 전달하지 않고 캐시된 콘텐츠로 응답하여 원본 서버의 부하를 줄입니다.
SSL/TLS 지원: 안전한 데이터 전송을 위한 SSL/TLS 프로토콜을 지원합니다.
웹 보안: DDoS 공격 방어, 웹 애플리케이션 방화벽 등 다양한 보안 기능을 제공합니다.
실시간 모니터링: 서비스 상태를 실시간으로 모니터링하고 문제 발생 시 빠르게 대응할 수 있습니다.

1-3. 활용

정적 콘텐츠 전송: 이미지, CSS, JavaScript 파일 등 정적 콘텐츠를 빠르게 전송합니다.
동적 콘텐츠 전송: 웹 애플리케이션의 동적 콘텐츠도 캐싱하여 빠르게 전송합니다.
비디오 스트리밍: 고품질의 비디오 스트리밍 서비스를 제공합니다.
API 게이트웨이: API 요청을 처리하고 결과를 캐싱하여 응답 시간을 단축합니다.

2. 인증서 요청

ACM 도메인 및 서브 도메인  추가 하여 요청

3. ALB  수정

80 -> 443  리다이렉트 해제 후 

생성이후 

규칙추가(만든 도메인 )

4. cloud front 설정 

alb 선택 이후 http -> https redirect 변경

이후 설정에 

대체 도메인 설정 

인정서도 추가

이후 route 53 에 내 도메인 레코드 편집으로 cloud fornt 설정 

backEnd 배포 테스트 

1. DB 생성 

- 특별한것 없이   aws rds 프리티이 mysql 생성 

backend 배포용 ec2 들어가(앞전에 생성한 front test 에 같이 작업 

DB 해당 엔드포인트로접속 

mysql -u admin -p -h {endPoit}

*mysql client 필수 설치 

2. db  생성 및 권한 설정 등 

mysql> create database DB이름;

mysql> show databases;

권한 설정
mysql> GRANT ALL PRIVILEGES ON employee.* TO admin@'%';

설정적용


mysql> flush privileges;

현재 사용중인 MySQL의 캐시를 지우고 새로운 설정을 적용하기 위해 사용합니다. 이 명령어를 사용하려는 사용자는 reload권한을 가지고 있어야 합니다.

3. 메이븐 프로젝트 설정 작업(앞전 작업 참조)

mvn clean

4. 생성된 jar 파일 확인 

5.실행 

nohup java -jar employee-management-backend-0.0.1-SNAPSHOT.jar &

6. 최종 결과 확인

아래에서 port 8080

테스트 코드 호출을 확인 할 수 있다.