[빗썸테크아카데미] 일곱번째 - Microservice Architecture (MSA)

 

 

 

[빗썸테크아카데미] 일곱번째 - Microservice Architecture (MSA)

 

 

 

 

여섯번째 시간은 교육 이래 처음으로

교육이 끝났는데도 팔팔했던 날이었다.

 

첫 일주일동안은 6시에 퇴근해서 집와서 저녁먹고

7시부터 9시 반까지 수업 들으면

진짜 너무 피곤해서 책이고 뭐고 바로 잤는데

 

어제는 눈이 말똥말똥해서

9시반에 수업 끝나고 부동산 공부좀 하다가 잤고

오늘 아침엔 일어나서 출근전 10분을 이용해 TDD 책 좀 읽다가 출근했다.

 

몸이 익숙해진건지

어제 특히 컨디션이 좋았던건지 ㅎㅎㅎ

매일매일이 어제만 같아라~

 

 

---

 

 

1. SW Architectrue trends

 

빨간색 : 이때까지 갖고 있었던 문제점 

초록색 : 이러한 문제점을 극복하고자 나온 기술들

 

70 - 80s 이전

종이를 뚫어서 프로그래밍을 했는데, 벌레가 좀을 먹어서 에러가 생겨서 문제가 생기곤 했다고 한다.

-> 나는 개발에 발을 들인 이후로, 에러는 왜 버그고 에러를 고치는건 왜 디버그인가에 대한 궁금증이 항상 있었는데, 이번 수업에서 그 해답을 찾아 너무 행복했다.

 

70-80s

Mainframe이 들어오면서 본격적으로 컴퓨터 리소스가 centralized가 됨.

터미널 작업이 가능해지고 유저 인터페이스 발생 초창기

 

90s

Client/Server로 분리

절차적인 과정이 비효율적이라  OOP가 도입되었고, DB와 UI가 분리가 안되어 발생하는 문제도 있었기 때문에 UI와 DB가 분리하는 2Tiered 형태를 갖추게 되었다.

 

2000

인터넷이 보급되기 시작하고 IT 붐이 불면서 UI와 DB의 분리인 2Tiered 형태만으로는 커플링이 너무 타이트해지기 시작. 커플링이 너무 타이트해서 소스가 꼬이기 시작하고, 시스템 구조도 엉망이 됨. 이때부터 스파게티 코드라는 단어가 나옴.

이제는 OOP만으로는 해결이 불가능하다고 해서 나온게 SOA Patterns. 또한 드디어 UI와 웹서버가 분리가 되어 3Tiered의 구조를 띄기 시작. SOA와 함께 DDD가 크게 뜨고 Loosley Coupling이 유행하기 시작.

 

2006

AWS가 Cloud 사업을 시작하면서 Iaas/PasS/SaaS와 같은 개념이 도입되면서 기존의 모놀리틱 문제점을 해결해보고자 MSA의 개념이 나옴. DI의 개념도 이때 도입됨.

 

2014 - 2018

드디어 현대의 Microservices 시대가 도래

 

 

 

역사는... 너무너무 졸리다. 처음에 버그잡기 빼고는 몽롱한 상태로 들었다

 

 

 

 

2. Sevice Oriented Architecture(SOA)

독자적인 서비스들이 통합되어 비즈니스 프로세스를 형성하도록 하는 설계 방법론

분산 컴퓨팅 환경의 소프트웨어 요구 조건을 만족시키기 위해 나온 개념

 

분산 컴퓨팅 환경의 소프트웨어 요구 조건

• 개발 언어에 상관없이 동일한 서비스 동작
• 컴포넌트가 특정 플랫폼에 비종속적
• 서비스 유지보수가 용이해야 함

 

SOA 특징

• 플랫폼 독립적 -> 모듈화, 캡슐화
• 서비스 간 약결합
• 서비스 위치 투명성

 

SOA 단점

• 각각의 서비스는 독립적인데 모든 서비스가 같은 DB를 바라봄

 

 

 

-> SOA는 살아있는 개념이긴 하지만 이제는 살짝 옛날것이 된 개념, SOA가 나올 당시, Cloud가 발달한 시기가 아니었기 때문에 각각의 서비스들을 실물 서버에 올려야 해서 크게 흥하지 못한 모델. SOA가 현대화 된 것이 MSA

 

 

 

 

 

3. Microservice Architecture

3.1 MSA 흥행 배경

업무 조직 성격의 변화

• 역할별 팀 구성 -> 목적별 팀 구성
• 목적팀 당 하나 또는 n개의 독자적인 서비스를 개발
• 타팀에서 관리하는 서비스와 느슨한 연결 필요

 

빠른 개발, 빠른 실험 문화 확산 (Lean)

• 회사가 목적팀 여러개로 구성되어, 거대한 하나의 목표 아래 목적팀 별로는 지방 분권
• 빠르게 서비스를 출시하고 시장에서 실험하는 것이 목표
• 목적팀 별 서비스 목표에 따라 방법론, 도구를 취사 선택

 

개발 생명 주기의 변화

• 하나의 서비스를 개발하고 변경, 폐기하는 것이 쉬워짐
• 기존 Waterfall 개발 방법론 -> Agile

 

 

3.2 Microservices를 위한 작업

3.2.1 Software 모듈화

• 큰 문제를 해결하기 위해 작은 단위로 나누어 개발하는 방법
• 서비스 기능의 확장, 수정, 테스트, 재사용 편리

 

모듈의 설계 조건

• 모듈마다 다른 모듈과 구분되는 독립적인 기능을 가져야함
• 독립적인 컴파일 가능
• 한 모듈에서 다른 모듈을 호출할 수 있음

 

모듈화의 특징

• 캡슐화 : 모듈 내 동작 방식, 데이터 구조를 다른 모듈에게 은폐
• 추상화 : 다른 모듈은 추상화 된 기능으로만 모듈에 접근
• 독립성 : 서로 다른 모듈끼리 낮은 결합도, 한 모듈 내부에서는 높은 응집도
• 모듈 수와 인터페이스 개발/관리 비용은 정비례

 

 

3.3 MSA 특징

• 여러 Service Instance가 하나의 Business App으로 구성
• Service App별 최적화 된 언어 / 저장소(DB) 사용
• Service별 독립적인 기능 / 용량 확장 가능
• Service별 독립적인 배포 가능
• Service는 서로 내부 API를 호출하여 통신

 

 

3.4 MSA 여러 모델들

1. Polyglot Architecture

 

폴리글랏(polyglot)은 여러 언어를 구사하는 것을 말한다. 즉, 폴리글랏 프로그래밍은 '패러다임을 달리 하는 여러 개발 언어를 자유롭게 구사하는 것'이라고 할 수 있다.  - google 검색 -

 

즉, 다른 언어로 구성된 서비스와 각 서비스에 맞는 DB를 서로 다르게 사용할 수 있다. 각각의 DB는 해당 DB에 맞는 서비스만 바라볼수 있고, 한 서비스는 다른 서비스의 DB가 필요할때, 서비스끼리의 내부 통신에 의해 데이터를 가져올 수 있다. 직접 다른 서비스의 DB를 바라보면 안된다.

 

 

2. Netflix OSS

• MSA의 선구자
• Netflix가 MSA를 성공적으로 도입한 이후로 MSA가 확 퍼짐
• Netflix OpenSource Software

 

 

 

3.5 Monoliths VS Microservice

Monoliths 단점

• 2 Tier / 3Tire로 표현되던 거대한 일체형 App
• Service 기능이 한 App에 포함되어 있으므로 작은 변화에도 전체 빌드, 배포 필요
• 새로운 요구사항이 추가될 수록 배포 부담 상승
• 특정 개발 언어, DB에 종속적
• 하나의 Service 기능이 모든 Service 운영에 영향
• Infra의 유연한 확장이 어려움

 

Microservice 단점

• 수많은 내부 service call 발생
• Transaction 관리 난이도 상승
• 데이터 무결성 보장 난이도 상승
• 시스템 복잡도 상승
• Trouble shooting시 숙련된, 비즈니스에 익숙한 개발자 역량 요구

 

 

3.6 MSA 설계 원칙

1. 단일 책임 원칙

• 관심사의 분리
• 명확한 모듈 경계 설정

 

2. Microservice는 자율적

• 독립적 배포
• 독립적 실행
• 독립적 확장/축소

 

 

3.7 MSA 설계 시 고려해야 할 점

• 너무 많은 Service 간 call이 있지는 않는지
• 내부 Service call에 동기적 의존 관계가 있는지
• Service 간 순환 의존 관계가 없는지
• Transaction 범위가 너무 많은 Service에 걸쳐져있지 않는지
• 하나의 Service의 배포 크기가 감당 가능한지
• 분리 시 유의미한 resource 사용량이 발생하는 기능인지

 

 

3.8 MSA 구성 요소

1. API Gateway pattern

• 여러 MS App에서 공통적으로 필요한 기능 분리
• 사용자 정보, 인증, 로깅....
• Routing

 

2. RESTful

• 통신 Interface

 

 

3.9 MSA 통신 패턴

HATEOAS

• REST API의 제약 조건 중 Uniform Interface의 만족 여부
• URI는 Resource를 식별할 수 있어야 함
• Http method를 통해 기능을 구분할 수 있어야 함
• HAL ( Hypertext Application Language)
• 응답에 참조 가능한 정보 포함
• 링크가 있을 경우 링크도 포함

 

 

3.10 MSA를 가능하게 하는 도구들

• Cloud Nativce Architecture -> Public Cloud가 보편화 되면서 MSA가 매우 용이해짐
• Container Runtime : 가벼운 App 생성, 배포, 리소스 격리
• Automation CI/CD -> 개발자의 편의를 위해

 

 

 

---

오늘도 숙제가 나왔다.

 

오늘의 숙제는 서버를 하나 더 만들어서,

어제 만들었던 서버에 request가 오면 그 서버에서

새 서버와 내부 통신을 해서, 데이터를 가져와서 response 하도록

구현하는 과제이다.

 

 

진짜....

빡시다 빡세