[IT갈피] 마이크로서비스 도입, 이렇게 한다 - 1장 : 더도 덜도 아닌 딱 마이크로서비스

안녕하세요.

 

요즈음 개인적으로 시간내서 IT공부를 하고 있지 않았고,

최근들어 다시 공부의 필요성을 느꼈습니다.

 

회사의 도움으로 교재를 구매하여 따로 공부하며 잊지않고 기록하기 위해 갈피를 잡아보려합니다.

비단 교재 뿐 아니라 IT와 관련된 내용이라면 여기 IT갈피 에 잡으려고요.

 

저의 IT갈피를 보러 와주신 분들께 감사인사 드리면서,

시작하겠습니다!

---

마이크로서비스 도입, 이렇게 한다

샘 뉴먼 지음 | 박재호 옮김

 

https://search.shopping.naver.com/book/catalog/32485088006

마이크로서비스 도입, 이렇게 한다 : 네이버 도서

---

1장 - 더도 덜도 아닌 딱 마이크로서비스

글쎄, 그건 빠르게 확대되어서, 그야말로 금세 통제불능이 되어버렸지!

- 론 버건디, 영화 <앵커맨> 에서

 

1장에서는

 

1. 마이크로서비스 아키텍쳐에 대해 설명
2. 마이크로서비스 개발 방법
3. 마이크로서비스를 도입할 경우의 장단점

순서대로 작성되어있다.

 

 

 

마이크로서비스란 무엇인가?

마이크로서비스(Microservice) - 비즈니스 도메인을 중심으로 모델링된 독립적으로 배포 가능한 서비스.

- 마이크로서비스도 SOA(서비스 지향 아키텍쳐. Service-Oriented Architecture) 의 한 유형.

- 기술에 중립적.

 

 

 

독립적인 배포 가능성

독립적인 배포 가능성 - 다른 서비스를 활용하지 않고서 마이크로서비스에 변경을 가하는 방식으로, 서비스 환경에 배포할 수 있다는 개념.

(다른 서비스는 배포하지 않으면서 단일 마이크로서비스에 대한 변경사항만 운영 환경에 릴리스하는 습관 들이기)

 

독립적인 배포 = 서비스가 느슨하게 결합되어 있음(loosely coupled)

- 응집도와 결합력.

- 특히, 데이터베이스 공유가 문제..

 

 

비즈니스 도메인을 중심으로 하는 모델링

➡ 모놀리스 웹 기반 아키텍쳐.

- 기존에는 전통적인 친밀도를 중심으로 하는 조직의 집합에 최적화되어있기 때문에, 나쁘지 않았다.

- 하지만, 최근에는 다재다능한 여러 팀으로 묶어 업무 이관과 사일로 현상을 줄이는 추세.

    - 또한, 빠르게 소프트웨어를  출시하는 기대감도 생김.

 

사일로 현상이란?

➡ 사일로(silo)는 원래 곡물을 외부와 격리시켜 저장하는 높은 굴뚝 같은 형태의 건물을 의미하는데 경영분야에서는 조직 내 부서 간 장벽이나 부서 이기주의를 의미한다.
곡물 저장을 위한 사일로에 빗대어 조직원이 주위와 협력하지 않은 채 자기 틀에 갇히는 것에 비유한 것이다.

 

 

3계층 아키텍쳐

- 기술 관점 : 응집력이 높다 ↔️ 비즈니스 기능 관점 : 응집력이 낮다.

 

그래서, 비즈니스 도메인을 중심으로 팀을 쉽게 조직화할 수 있으면 좋을 것이다.

 

 

 

데이터 소유권 문제

(정말로 필요한 경우가 아니라면 데이터베이스는 공유하지 말자.)

 

 

 

마이크로서비스의 장점

• 배포의 독립적인 특성으로 인해 시스템의 확장성과 견고성을 개선
• 다양한 기술을 짜맞출 수 있음
• 서비스의 병렬 개발 작업이 가능 ➡ 개발자들은 서로 방해받지 않고 각자 문제 해결에 몰입할 수 있음 ㅎㅎ
• 유연성 제공

하지만, 이러한 장점을 공짜로 얻을 수는 없다. 마이크로서비스 아키텍쳐에서 추구하려는 목표가 무엇인지부터 파악해야 한다. 

 

 

 

마이크로서비스가 야기하는 문제점

• 로컬 프로세스 내 작업에서 볼 수 있는 대기 시간과 비교해 훨씬 더 긴 대기 시간
• 네트워크 문제(패킷 손실, 시스템 동작 예측 불가능 등)
• 트랜잭션 같은 걸로 해결 불가능 ➡ 트랜잭션 처리가 힘듬

특히, 신기술을 무턱대고 적용했다가 잘못하면 높은 비용을 부과함. (시간적이든 물적이든, 자본이든)

 

 

 

기술

마이크로서비스는 기본적으로 기술에 중립적 ➡ 목적에 맞춰 원하는 기술 스택을 짜맞출 수 있다. 는 장점

- 마이크로서비스 아키텍쳐에서 프로그래밍 언어 선택은 그다지 중요하지 않다.

    - 특정 도구를 사용하는 사람들에게는 경멸에 가까울 수 있는, 일부 기술 스택에 대한 우월의식이 너무 팽배해 있다.

    - 각자 알맞은 접근 방식을 선택하자.

 

 

 

규모

규모라는 정의에 가장 가까운 문장

마이크로서비스의 목표는 '가능한 한 작은 인터페이스를 유지' 하는 것

- 크리스 리처드슨

 

그래서 저자는 '마이크로서비스 아키텍쳐로 가는 점진적인 마이그레이션' 을 강력히 옹호함.

 

 

 

---

모놀리스

모놀리스 = 배포 단위. 시스템의 모든 기능을 함께 배포해야 할 때, 모놀리스로 간주.

 

• 단일 프로세스 시스템
• 분산 모놀리스 시스템
• 외부 블랙박스 시스템

 

 

 

단일 프로세스 모놀리스

단일 프로세스 모놀리스 - 모든 코드가 단일 프로세스로 배포되는 시스템.

 

 

모듈식 모놀리스 - 단일 프로세스(프로젝트)는 별도 모듈로 구성되어 있으며 각 모듈은 독립적으로 동작할 수 있지만, 배포를 위해서는 여전히 결합이 필요함.

 

 

 

분산 모놀리스

분산 모놀리스 - 여러 서비스로 구성되는 시스템이지만 어떤 이유로든 전체 시스템을 함께 배포해야 함.

- 분산 모놀리스는 분산 시스템의 모든 단점 + 단일 프로세스 모놀리스의 단점

 

 

 

외부 블랙박스 시스템

외부 블랙박스 시스템 - 외부 소프트웨어. (ex. 급여 / CRM / HR 시스템 등)

- 외부업체가 만들어서 코드 변경이 불가능 (그럼 왜 이 책에 넣은거지..)

 

 

 

모놀리스의 문제점

가장 큰 문제점은 배포 경합이다.

- 배포 경합 : 누가 무엇을 소유하며 누가 의사결정을 하는지에 대한 소유권의 경계선이 혼란스러운 상황.

 

 

 

모놀리스의 장점

• 훨씬 간단한 배포 토폴로지 = 훨씬 더 간단한 개발자 워크플로우
• 모니터링, 테스트, 문제 해결 및 트레이싱 같은 활동 단순화
• 코드 재사용 단순화

모놀리스 != 레거시

 

 

 

---

결합도와 응집력

결합도 - 한 가지를 바꾸면 다른 것도 바꿀 필요가 있는 방식

응집력 - 관련된 코드를 그룹으로 묶는 방식

 

구조는 응집력이 높고 결합도가 낮을 때 안정적이다.

- 래리 콘스탄틴 (콘스탄틴의 법칙)

 

모놀리스의 문제점은 결합도와 응집력이 너무나 자주 반대로 움직이는 것.

 

 

 

응집력

응집력(의 또 다른 정의) - 함께 바뀌고 함께 머무는 코드

- 그래서, 가능한 한 적은 장소에서 변경할 수 있는 방식으로 기능을 그룹으로 묶어야 함.

    - 즉, 하나의 repository(또는 프로젝트) 내에 포함된 기능들의 개수를 줄이는 것.

    - 그래야 가능한 한 변경의 범위를 줄이고, 이에 따라 변경하는 수고와 비용을 줄일 수 있어서. 

    - 변경해야하는 최소의 서비스만 확실하게 수정하기 위해.

 

 

 

결합도

결합도가 높은 항목이 많을수록 함께 변경해야하는 내용도 더 많아진다.

 

정보 은닉 - 자주 변경되는 코드부를 정적인 코드부와 분리하는 것.

- 더 자주 변경될 것으로 예상되는 모듈 구현 부분을 숨겨야 함.

- 음.. 비유하자면, 더 자주 변경되는 핵심 로직이 담긴 함수는 private으로 노출시키지 말고, 변경이 작은 범위의 코드는 public하게 공개하기?

- 하나 더 비유하자면, DB 접근하는 DAO를 직접 사용하지 않고, DAO를 통해 값을 전달해주는 함수를 사용하기?

- 마지막으로, 특정 서비스 범위의 DB Table에 직접 접근하지 않고, 서비스가 제공하는 API 사용해서 데이터 받기?

- 이렇게 정보 은닉은 단순히 객체 캡슐화 뿐 아니라 넓고 다양한 범위도 포함한다.

 

 

구현 결합도 - A가 B에 결합한 것으로, B의 변경 시 A도 변경되는 것,.

ex) 하나의 DB를 공유하는 두 개(A, B) 의 서비스

 

 

시간적 결합도 - 동기식 호출에서 실행 시간에 발생하는 문제.

- 이를 해소하기 위해 '캐싱' 이란 방법 존재. ➡ 중간에 필요한 정보를 캐싱해두면, 다음 서비스를 호출하고 기다리지 않고 바로 캐싱된 정보를 전달할 수 있어 시간적 결합도를 줄일 수 있다.

 

 

배포 결합도 - (정적으로 링크된 여러 모듈로 구성된 단일 프로세스인 경우 = 모듈식 모놀리스인 경우) 모듈 중 한 곳에서 코드 변경이 발생하고, 배포하려하면 변경되지 않은 다른 모듈을 포함한 전체 모놀리스를 배포해야하는 결합의 정도. ➡  모놀리스여서 모든 모듈이 함께 배포되어야 함.

배포에는 위험이 따른다. (다른 모듈까지 배포되었다가, 무슨 일 발생하면 우리 잘못일까..? 와 같은 위험)

 

도메인 결합도 - 하나의 기능이 얼마나 여러 도메인을 필요로 하는지 결합되어있는 정도.

 

 

 

---

더도 덜도 아닌 딱 도메인 주도 설계

도메인 주도 설계(DDD, Domain-Driven Design) 는 마이크로서비스 아키텍쳐에 엄청난 장점(비즈니스 도메인을 중심으로 서비스를 모델링하니까) 이 생긴다.

 

 

... 기타 생략(집계 / 경계 컨텍스트. 큰 연관이 없는 내용이라 판단) ...

 

 

 

---

 

정리

마이크로서비스

- 비즈니스 도메인을 중심으로 모델링한 독자적으로 배포가 가능한 서비스.

- 네트워크를 통해 서로 통신.

- 도메인 주도 설계(DDD) 와 함께 정보 은닉 원칙을 사용해 독립적으로 작업하기 쉽도록 서비스를 만든다.

- 다양한 형태의 결합도를 줄이기 위해 최선을 다한다.