[24.09.06] Spring Cloud MSA

현재 진행중인 프로젝트가 Monolithic 에서 MSA(Micro Service Architecture)로 분리하고 발표하고 마무리 하였다. 근데 분리하고 나서부터는 프로그램을 돌려서 테스트하는 방법을 알지 못했다. 그래서 리팩토링을 하고 싶지만, 하지 못하여 내가 MSA 지식이 부족한건가 라는 생각이 들어 MSA를 제대로 한번 파고 들었다. 

그래서 여러 블로그도 찾아보고 유튜브도 몇 개 봤지만, 내 수준에서 이해가 안됐다. 그래서 하.. 그냥 어쩔수 없다. 이거 생각해낸 Netflix 관련된 사람이 MSA 발표하는 Conference 영상을 보자. 하고 (https://www.youtube.com/watch?v=VPdPR5DxhaI)봤다.

영상을 듣고 이해한대로 이해하려 노력하였지만 100%는 이해하지 못하고 그 분이 여러 예시를 들면서 배경(만들게된 생각의 흐름)에 대해 알려주셔서 배경정도는 확실히 알게 되었다.

 

영상 정리

Monolithic codes(90년대 ~ 2000년대 초반)

Load Balancer : 하드웨어 기반의 로드 밸런서
리눅스 서버들 : 고가의 하드웨어를 사용
    - Apache(Tomcat  & JavaWeb)
Oracle 

 

---

중간 용어 정리

"Edge"
ELB(Elastic Load Balancing, 웹 서버 로드 밸런싱) : 부하 분산 서비스
Proxy Layer
Zuul : 동적인 라우팅 수행
Lagacy Tier
NCCP : 옛날 장치로 기본 영화 재생

API(API GateWay) : 고객이 발생시키는 요청에 대한 응답을 처리하기 위해 다른 많은 서비스들과 통신
DRM도 있다.

Middle Tier & Platform

Product
- Bucket testing : A, B test 인프라가 있고, 유입된 고객이 할당될 테스트용 A, B 서비스가 동작할 것이다.
- Subscriber : 넷플릭스 고객에 대한 거의 모든 정보를 가지고 있는 서비스
- Recommandations : 각 고객에 맞는 적절한 영화를 제안하기 위한 기능을 수행


Platform : 기초적인 기능을 제공하기 위해 존재
- Routing : 마이크로 서비스들이 서로 찾아 연결하는데 도움
- Configuration : 동적으로 설정 변경하는 서비스
- Crypto : 암호화 관련 서비스

Persistence : 데이터를 영구 보존하기 위한 서비스들
- Cache
- Database

 

 

---

Dependency(의존성)
    Intra-service requests : A 서비스이 B 서비스에 의존관계가 있는데 
                                    한쪽에서 문제가 터져버리면 문제가 터진 쪽에서 해결해야한다.(HYSTRIX)
    Client Libraries : 클라이언트 라이브러리 논쟁중~
                            아직 결론 x, 현재 나온 방법 라이브러리를 더 간단한 규모로 만들기
    Data Persistence : 데이터 저장 구간
                                CAP 이론 : 네트워크가 분리된 환경에서는 consistency(일관성)과 availability(가용성) 중에 반드시 하나를 선택해야한다.
    Infrastructure

Scale
    Stateless service(ex. 복제) : Auto Scaling Groups
        - Not a cache or a database
        - Frequently accessed metadata : 매우 자주 요청되는 메모리에 캐시된 메타데이터
        - No instance affinity
        - Loss a node is a non-event
    Stateful service : stateless와 반대되는 개념
        - Database & caches
        - Custom apps which hold large amounts of data
    Hybrid service : 걍 짱! 다 해결해줌 근데 얘가 다운되면 서비스 전체 다운
        - 30 million requests/sec
        - 2 trillion requests per day globally

        - Hundreds of billions of objects
        - Tens of thousands of memcashed instances

        - Milliseconds of latency per request

 

 

 

Variance : 다양한 아키텍처가 서비스 내에 존재하는 것을 의미
    Operational drift
        - Over time 설정 변경을 해야하는 경우가 생긴다.
            Alert thresholds
            Timeouts, retries, fallbacks
            Throughout(RPS)

        - Across microservies
            Reliability best practices
    Polyglot & containers
Change

 

결론

 

---

Back to Lecture

다시 내가 들은 수업 내용으로 돌아와서 보자.

Gateway(라우팅 기능 담당) : Eureka Server를 제외한 서비스 서버들 & 경로 application.yml 파일에 있음
Load Balancer : 고객의 요청이 많아져 트래픽이 몰릴 때 이를 해결해주는 부하 분산하는 곳
                    (이를 해결해주는 방법 : 같은 서비스를 담당하고 있는 다른 곳으로 RoundRobin 등 여러 방식으로 분산 시켜준다.)

Eureka Server : Service Discovery(Registry) 역할 (ex. 스타 커맨더 역할)

 

순서

1. 모든 서버 start
    이때, Gateway 설정을 통해 여러 서비스들 인지
2. 고객이 요청 하면
    Gateway가 요청을 처리하여 해당 서비스에 라우팅(연결) 시켜준다.
2-1. 요청이 몰릴 때 Load Balancer가 Gateway에서 요청을 받아 RoundRobin 방식 등 여러 방식을 통해 부하를 분산 시켜준다.
3. 서비스 서버가 받은 요청을 처리한 후 응답을 Load Balancer -> API Gateway -> Client 로 간다.

 

---

Reference

Mastering Chaos - A Netflix Guide to Microservices(넷플릭스의 엔지니어링 리드였던 조쉬 에반스의 2016년 InfoQ 발표)
https://www.youtube.com/watch?v=VPdPR5DxhaI