MSA 교육 정리(3)

[1], [2]

- 서비스 분리에 따른 통합인증을 어떻게 할까? 

1. OAuth2.0

1) Authorization Code(권한부여 승인 코드 방식)
2) Implicit(암묵적 승인 방식)
3) ROPC(자원소유자 자격증명 방식) - 실습(1)
4) Client Credentials(클라이언트 자격증명 승인 방식)

2. JWT(Json Web Token) 

3parts -> header / payload / signature 
(ex>         aaaaaa.bbbbbb.cccccc)


***  Keycloak ***

[3] 
- monolithic <=> micro service 반대되는 개념이다.

1. API를 어떻게 통합 시킬 것인가?

- API Gateway
-> 진입점 통일
-> URI Path-based Routing (기존에 REST 로 된경우 가능)

- Service Registry
-> API Gateway 가 클러스터 내의 인스턴스를 찾아가는 맵

2. 어떻게 (다시) 상호 연동시킬 것인가?

- Find the seams and replace with proxy
-> 기존 연계되던 이음매 객체 (interface) 를 찾아, 그에 상응하는 Façade, Proxy 로 대체

@FeignClient(name-"delivery", url="http://localhost:8080")
@RequestMapping(Method=RquestMethod.POST, value="/deliveries", consumes="application/json")

- Event Shunting
-> 레거시에서 이벤트를 퍼블리시하도록 전환, 신규 서비스가 주요 비즈니스 이벤트에 대하여 반응하도록 처리

Aggregate 내 코드 주입
CDC(Change Data Capturing)기능 사용

[4], [5], [6] ,[7], [8]

***
mvn spring-boot:run  >>> 서비스 기동
fuser -k 8080/tcp   >>> 해당 포트 서비스 종료
***

 
<!-- feign client -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>


* 서킷브레이커 패턴을 사용하여 장애전파를 차단해보자!

1. application.yaml 파일에 하단 설정 추가 

feign:
 hystrix:
   enabled: true

hystrix:
 command:
   # 전역설정
   default:
 execution.isolation.thread.timeoutInMilliseconds: 610

2. Delivery.java 에 강제 딜레이 발생 코드를 넣는다.

try {
Thread.currentThread().sleep((long) (400 + Math.random() * 220));
} catch (InterruptedException e) {
e.printStackTrace();
}
3. monolith 서비스의 DeliveryService.java 의 FeignClient에 fallback 옵션을 준다.

@FeignClient(name ="delivery", url="${api.url.delivery}", fallback = DeliveryServiceImpl.class)

첫번째는, 오류가 전파되지 않도록 공유하고 있는 리소스를 분리하는 방법이고,
두번째는, 오류 발생시 오랫동안 리소스를 잡아두지 못하게 하는 방법입니다.
Circuit Breaker는 여기서 두번째 방법에 해당됩니다.

- 500 떨어질때 fallback으로 유연한 대처
@FeignClient(name ="delivery", url="${api.url.delivery}", fallback = DeliveryServiceImpl.class)
5xx --> 배송이 지연중입니다~~

지금은 이렇게 처리하지만 나중에 로컬이 아닌 상황에서는 특정 상황(과부하 등)에 자동으로 서버 용량을 늘려줄 수 있다.

* Apache-Kafka
구성요소:  Broker, Zookeeper
관리객체:  Topic, Partition, Producer, Consumer
Scaling Kafka

1> 카프카 용도

메세징 시스템
Activity Tracking
모니터링 데이터 수집 ( Gather metrics )
로그 수집 ( Log Aggregation )
Stream Processing 
시스템간의 종속성 분리 ( De-coupling of System Dependencies )
Spark, Storm, Flink, Hadoop 등 많은 빅데이터 기술과 통합하여 사용

2>  관리객체 Topic, Partition, Offsets

- 토픽(Topic)
특정 데이터 스트림, 즉 메세지를 구분 하는 통로
하나의 카프카에 여러 메세지가 뒤섞여서 오가는데, 거기서 토픽으로 구분하여 원하는 메세지를 찾는 방식
데이터베이스의 테이블, 카톡의 단톡방 과 비슷한 개념
토픽은 여러개 만들수 있고, 이름으로 구분됨

토픽 이름을 어떻게 만들어야 하나?
https://riccomini.name/how-paint-bike-shed-kafka-topic-naming-conventions
https://devshawn.com/blog/apache-kafka-topic-naming-conventions/
<project>.<product>.<event-name> 
services, consumers, or producers 등과 연결하여 만들지 않기를 추천함

- 파티션(Partition)
토픽은 파티션을 나눌수 있음
토픽당 데이터를 분산 처리하는 단위
병렬 처리와 많은 양의 데이터 처리를 위해서 파티션을 늘리수 있음
* 늘리기만 하고 줄이는 것은 안됨 (아파치는 그렇지만 컨플루언트(상업용)는 가능)*
각각의 파티션은 0부터 1, 2, … 의 Index를 가짐
파티션 별로 증가되는 아이디 , 즉 Offset 라는 값을 가지게 됨

- 옵셋(Offsets)
Offset 은 파티션에서만 의미가 있음
파티션 3개가 있다면 각각의 파티션의 offset 0번은 다른 데이터를 가지게됨 
파티션 안에서는 데이터의 순서가 보장
파티션이 복수개 일때, 1번과 2번 파티션에 적재되는 데이터의 순서성 보장이 안됨 
파티션에 데이터가 한번 쓰여지면 변경이 안됨
key 를 주지 않으면 어느 파티션에 데이터가 들어갈지 모름


3> 구성요소 Broker, Zookeeper

- Broker
카프카를 클러스터로 구성하였을 때, 각각의 서버를 Broker 라고 부름
각각의 브로커는 토픽 파티션을 가짐
어떤 브로커에 접속해도 전체 카프카 클러스터에 접속 가능
브로커는 3개로 시작하여 100개까지 늘어날 수 있음

- Zookeeper
분산 애플리케이션 코디네이터
주키퍼는 브로커를 관리한다.
파티션의 리더 선출을 도와준다.
카프카의 변경에 대하여 알림을 준다 ( 토픽생성, 브로커 die, 브로커 up, 토픽 삭제 )
카프카는 주키퍼 없이 동작 못함
주키퍼 클러스터는 홀수로 동작함 ( Leader/Follower 선출때문에 짝수로 동작 못함)
주키퍼 Leader 는 write, Follower 는 read 작업을 함


4>  Producer / Consumer

- Producer 

메세지를 생산(produce) 하여 토픽으로 메세지를 보내는 애플리케이션, 서버등을 Producer 라고 부른다.
메세지를 전송할때 Key 옵션을 줄 수있는데, Key 값을 설정하여 특정 파티션에 메세지를 보낼수 있다.
Key 옵션을 주지 않을때는 파티션에 라운드로빈 방식으로 균등하게 메세지를 보낸다.

메세지 손실 가능성이 높지만 빠른 전송이 필요한 경우
acks=0  프로듀서는 응답을 기다리지 않는다.

메세지 손실 가능성이 적고, 적당한 속도의 전송이 필요한 경우
acks=1  프로듀서는 리더의 응답만 체크 한다. (default)

전송 속도는 느리지만 메세지 손실이 없어야 하는 경우
acks=all 프로듀서는 리더와 ISR 의 모든 응답을 체크한다.
Replication 이 없는 경우라면 acks=1 과 동일하다

- Consumer

토픽 이름으로 저장된 메세지를 가져가는 앱, 서버등을 Consumer 라고 부른다.
Consumer 들의 집합을 Consumer Group 이라고 부르며, 카프카는 Consumer Group 단위로 데이터를 처리한다.
Consumer Group 안의 각각의 Consumer 는 파티션의 데이터를 읽는다.

- Consumer Offset

카프카는 컨슈머 그룹이 어디까지 메세지를 가져갔는지 Offset 을 체크한다.
컨슈머 그룹은 메세지를 가져간 후에 offset 을 Commit 한다.
카프카는 내부적으로 별도의 토픽으로 커밋된 정보를 저장한다. __consumer_offset 형식으로 저장됨
만약 컨슈머가 죽었을때, 해당 offset 정보를 읽어서 어디부터 데이터를 읽을지 파악하고, offset 다음부터 메세지를 수신한다.

5> kafka Connect

Producer, Consumer를 사용해서 데이터 파이프라인 생성
카프카 동기화 지원 
Connect와 Source Connector를 사용해 Kafka Broker로 데이터를 보내고, 
Connect와 Sink Connector를 사용해 Kafka에 담긴 데이터를 타겟 DB에 저장한다. 


- 멀티 파티션 or 멀티 컨슈머 환경에서는 어떠한 상황에서도
메시지 유실 X!
메시지 순서성 보장!

ex > 계주 경기 느낌

pub할때 key(계주경기의 바톤)를 주면 된다(-> Pub(key1,msg))