미로

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

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

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

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

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

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

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

1.topic 이란?

Topic이란 논리적인 표현이며 메시지 저장소이다.

왼쪽의 producer가 토픽을 발행하면 우측의 consumer가 소비하는 형식이다.

토픽은 데이터베이스의 테이블 혹은 파일시스템의 폴더와 유사한 성질을 갖고 있따. 

또 목적에 따라 각각의 이름을 가질 수 있는데 무슨 데이터를 담는지에 따라 명확하게 명명하는 것을 권장한다. 

2. partition이란?

데이터 처리를 효율적으로 하기위한 핵심 요서. 파티션은 큐를 나눠서 병렬처리를 가능하게 하는 기본 단위, kafka의 토픽은 하나 이상의 파티션으로 나눠져 있다. 이를 통해 메시지가 병렬로 처리될 수 있게 된다.

파티션 개수는 지정 가능 하며 0번부터 오름차순으로 생성된다. 또 topic 내의 파티션들은 서로 독립적이다.

offset 이란 이벤트 메세지의 위치를 나타내는 값. 

이 partition 안에 offset 이 존재하는데 다른 partition 의 offset 과는 다르다.

ex) partion0 offset 1 != partion1 offset 1

같은 partion 안에서는  순서가 보장 되며 데이터는 변경이 불가능(immutable) 하다.

하나의 토픽은 하나이상의 Partition으로 구성

병렬처리(Throughput - 처리율  향상)을 위해서 다수의  Partiotion사용

*CommitLog(추가만 가능하고 변경 불가능한 데이터 스트럭처, 데이터 이벤트는 항상 로그 끝에 추가되고 변경되지 않음)

3. Segment란?

발행된 메시지 데이터가 저장되는 실제 물리 File 

segment file 은 지정된 크기보다 크거나 지정된 기간보다 오래되면 새 파일이 열리고 메시지는 새파일에 추가된다.

파티션당 오직 하나의 Segment가 활성화된다.

segment 들은 Rolling 정책을 쓴다.

log.segment.bytes(default 1 GB), log.roll.hours(default 168 hours)