마이크로 서비스 개요

 

마이크로 서비스 개요

마이크로 서비스란?

하나의 sw 에 대해 개별적으로 배포 일정을 가지고 업데이트 운영이 가능한 작고 독립적인 소프트웨어 프로세스 즉, 프로젝트의 주요 기능을 위해 서로 협업하는 작은 서비스들로 구성된 분산 프로그램을 말한다.

 

*다른 마이크로서비스와 별개로 업데이트 가능 ( 독립적 개발 )

*필요에 따라 외부에 노출하거나 외부 접근 불허

*하나의 마이크로서비스가 많은 기능을 가지지 않음

*각각의 서비스는 격리된 독립적인 프로세스다.

*단위 서비스는 서로 느슨하게 연결되며 하나의 서비스가 다른 서비스에 영향을 미치지 않는다.

*단위 서비스는 자신만의 데이터베이스를 갖는다.

 

 

모놀리스의 문제점

전체적인 앱이 단일 프로세스로 동작한다.

작은 규모의 실험적 모델에 적합하지만 규모가 커지다 보면 실험적 기능 추가가 어려워지고 스파게티 코드가 되기도 하는 등 여러가지 문제점을 안고 있다.

배포 또한 단일 배포과정으로 배포하며 코드 한 줄만 바꿔도 새롭게 배포 해야 한다. 해당 과정에서 서비스 장애를 초례 할 수 있으며 이에 배포에 대한 두려움이 증가할 수 있다.

 

반면 마이크로 서비스 에서는 작은 단위로 독립적 배포 일정을 가지며 단위별로 배포하기 때문에 유연한 배포 작업을 자주 할 수 있음으로 덜 위험하다.

 

마이크로 서비스의 장점

세밀한 확장성 : 앱 확장성을 세밀하게 조절 가능, 각 서비스 필요에 따라 독립적 확장 가능

배포 위험 감소 : 새로운 코드를 배포할 때의 위험을 최소화 (마이크로 서비스 단위로 영향)

기술적 유연성 : 개발자들이 하나의 기술 스택에 구속되지 않고 각 서비스에 가장 적합한 기술 스택을 선택할수 있음 ex) 어떤 서비스는 node.js, 어떤 서비스는 spring boot 로 개발 가능

 

마이크로 서비스의 최신 도구 사용

도커: 패키지 만들거나 서비스 배포

도커 컴포즈 : 개발환경에서 마이크로서비스 앱을 테스트 (로컬환경)

쿠버네티스 : 클라우드에 앱을 호스트

 

마이크로 서비스의 앱의 설계

설계규칙

1. 지나치게 미리 설계하지 말자

2. 최대한 단순하게 유지하기 위해 지속적인 리팩토링을 하자.

3. 좋은 설계가 자연스럽게 완성되도록 ( 단정적 설계 x )

4. 단일책임원칙 : 하나의 서비스는 개념적으로 하나의 업무를 책임져야

5. 느슨한 연결 : 서비스간 연결을 최소화하고 , 필요한 정보가 아니면 공유지 않음

6. 강한 응집력 : 하나의 마이크로서비스 안에서는 코드가 서로 기능적으로 연계, 맡은 서비스 영역에 대한 문제를 풀 수 있도록 동작해야

 

도메인 기반 설계 (Domain Driven Design, DDD)

비지니스 도메인을 중심으로 설계

-       개발자는 같은일을 반복하지 않는다는 원칙을 공격하는 것처럼 보임

-       But 마이크로서비스 분야에서는 반복되는 코드에 대해 관대함

 

 

 

 

독립적인 마이크로서비스

단일 레포와 cd 파이프라인으로 동작 : 모든 마이크로서비스를 같은 속도로 출시해야함 ( 배포 할때마다 전체 앱이 망가질 수 있는 위험 ) 즉 한번 고칠때마다 전체 마이크로서비스를 빌드해야 한다.

 

분리된 코드 레포와 여러 cd 파이프라인으로 동작 : 세밀하게 배포 제어 가능, 전체 앱 관리는 더 복잡해지지만 한나의 마이크로서비스 관점에서는 더 단순 ! but 너무 일찍 바꾸면 장점을 누리기전 비용 up ( 충분히 복잡해졌을때 전환해야 )

 

코드 레포 분리

마이크로 서비스마다 구분되도록 레포 구성, 새로운 레포는 하나의 마이크로서비스 코드와 그 코드를 배포하는 코드 포함

 

*메타리포 : 분리된 레포 코드를 하나의 코드레포로 묶어주는 가상의 코드레포 .meta 설정 파일을 만들어 구성

 

Cd 파이프라인 분리

마이크로서비스마다 구분된 배포 파이프라인 필요

 

다중환경 만들기

개발자가 각자 test 하기에는 한계가 있음 실환경은 아니지만 운영에 가까운 환경에서 test 할 수 있어야

Development workstation -> development environment -> test environment -> production environment 순으로 test 및 배포한다.

 

운영 워크플로

코드레포 안에서 배포 환경에 맞게 브렌치로 구분해서 사용 (development , test , production ) 각 브랜치에 push 시 적절한 환경으로 배포 트리거

 

성능 확장성

마이크로 서비스는 성능에 대한 섬세한 제어가 가능하다 , 성능이 떨어지는 부분, 사용이 최대일때, 과부화 걸린 위치 등을 모니터링하기가 쉽다.

 

클러스터 수직확장

앱 확장시 클러스트가 앱을 실행하는데 충분한 연상능력, 메모리 등을 보유하지 못할 경우 자원 증가시켜야 이때 수직확장은 vm 용량 증가

 

 

클러스터 수평확장

같은 크기로 vm 의 개수를 늘리는 방식

수직확장보다 비용이 덜 소요된다.

 

 

 

개별 마이크로 서비스의 수평확장

 

클러스터의 규모는 충분하지만 개별 마이크로서비스에 부하가 걸리는 경우

부하를 여러 인스턴스로 분해할 수 있도록 수평확장

 

 

데이터베이스의 확장

하나의 마이크로서비스는 자신만의 데이터베이스 하나를 가져야함

 

 

앱이 커지면 하나의 db 서버 외에 여러 db 서버를 둘 수도 있음

 

 

 

샤딩이라는 방법도 있다. 나중에 살펴보자

 

 

인프라 변경 관리

블루-그린 배포 : 두개의 운영환경을 통해 하나의 환경에서는 서버 운영 나머지 환경에서는 test 후 완료되면 dns 가 다른 도메인을 가리키도록 수정한다.

 

 

 

모놀리스를 마이크로서비스로 전환

마이크로서비스 플랫폼 구성 ( 쿠버네티스 클러스터 생성 ) -> 모놀리스에서 기능 추출 -> 쿠버네티스 클러스터에 마이크로서비스로 구현

 

* 자연스러운 경계로 분할하기 = 도메인에 맞춰서 분할하기

* 가장 자주 변경하는 부분을 추출하자