도메인 주도 설계로 시작하는 마이크로서비스개발 part 1.

1장 아마존 비지니스 민첩성의 비밀

 

1.1. 성공한 인터넷 기업들과 비지니스 민첩성

성공한 기업들은 자신들의 “비지니스 민첩성”을 기업 성공의 가장 큰 요인으로 꼽는다.
비지니스 민첩성이란 어떤 것이고, 어떻게 실현할 수 있을까?

비지니스 민첩성

책에서 말하는 비지니스 민첩성은 “민첩성”이라는 단어 그대로, 빠르게 대응하는 것을 의미한다.
예시로, 아마존에서는 초 당 약 1.5번의 배포가 발생한다고 한다. 이 말은, 0.66초에 1번씩 비지니스 개선이 발생한다는 것이다. 아주 빠르게 문제점을 개선하고, 기능을 보완하고, 고객에게 휼륭한 서비스를 제공하게 되는 것이다.

비지니스 민첩성을 위해서는 중요한 3가지 요소가 있다고 말한다.

• 프로세스
  • 점진 반복적인 개발 프로세스가 필요.
• 아키텍쳐
  • 유연하고 자동화된 개발 환경이 필요.
• 조직문화
  • 자율적인 업무 기능 팀과 개발 문화가 필요.

다음 3가지 요소를 충족시킬 수 있는 방법은 무엇일까?

• 클라우드 인프라
  • 클라우드 인프라 환경이 발달하며 기업들에서는 이러한 민첩성을 보다 쉽게 이끌어낼 수 있게 되었다. 클라우드 환경이 아닌 물리적인 온프레미스 환경이라면 개발인원이 작업을 시작하기 전에 작업환경을 구성하는 것부터가 긴 시간을 소요하게 될 것이다. 이후 서비스 인프라를 구성하는 작업을 진행 할 때에도 처음부터 차근차근 쌓아올려야하기 때문에 그 또한 긴 시간이 필요할 것이다.
  • 더 이상 물리적인 공간이 필요없을 뿐더러, 이미 클라우드 서비스를 제공하는 기업들에서 인프라 구성에 필요한 것들을 구현해놓았기 때문에 개발인원들은 각자의 환경에 맞는 설정 값만 세팅해주면 전보다 훨씬 간편하고 빠른 시간 내에 서버 인프라를 구성할 수 있다.
  • 클라우드 서비스들에서는 이러한 과정을 생략할 수 있도록 도와준다.게다가 클라우드 서비스는 각각의 인프라 환경을 하나하나 쪼개어 각각의 서비스로 제공하기 때문에 필요한 것들만 골라서 이용할 수도 있다. → 비용 절감의 효과를 볼 수 있다!

• 효율적이고 유연하게 대응하는 서버.
  • 서버를 유연하게 사용하자.
    • 대부분의 서비스들은 24시간 365일 트래픽이 일정하지 않다. 예를 들어, 이커머스 서비스라면 세일기간, 인기 브랜드 상품 출시, 인기 상품 재입고 등등 특정 상황이 벌어졌을 때 트래픽이 상승할 것이다.
      상승하는 트래픽에 서버가 다운되면 안되니, 상상할 수 있는 최고의 트래픽 상황에 맞게 서버를 세팅해야 할까?
      그건 최고의 방법이라고 할 수는 없다. 트래픽이 상승하지 않는 시간이 훨씬 길 것이고, 그렇다면 그 기간만큼의 유휴 리소스가 발생하게 된다. 그것은 즉, 비용을 낭비하게 된다는 것이다.
      비용을 낭비하지 않고, 유연하게 대응할 수 있는 Scale-up & Scale-out 을 사용하자.
  • 효율적이고 유연하게 대응하는 서버.
    • 서버를 scale-up/out 을 할 경우 서버를 통째로 복제하고 확장하게 된다. 리소스를 마냥 키워놓는 것 보단 유연한 방법이 될 수 있겠지만, 이 보다 더 효율적이고 휼륭한 방법이 있다.
      서비스에서 발생하는 기능들을 공통된 부분끼리 묶어, 애플리케이션을 여러 덩어리로 분리하고, scale-up/out 을 각각의 덩어리마다 발생하도록 적용시키는 것이다.
    • 애플리케이션을 분리하지 않은 체로 서버를 스케일 업/아웃 할 경우

애플리케이션을 분리하지 않은 체로 서버를 스케일 업/아웃 할 경우

• • • 애플리케이션을 분리하여 트래픽이 몰리는 노드만 스케일 업/아웃 할 경우

애플리케이션을 분리하여 트래픽이 몰리는 노드만 스케일 업/아웃 할 경우

 

훨씬 더 높은 효율성을 가지고 유연한 서버 대응을 할 수 있을 것이다.
이처럼 민첩성을 끌어올리기 위해서는 클라우드 환경을 도입하고, 클라우드 네이티브 애플리케이션을 구성하는 것이 좋다.

💡 클라우드 네이티브 클라우드 인프라에 효과적으로 어울릴 수 있도록 독립적으로 분리되어 배포될 수 있는 조각으로 구성 된 애플리케이션.
애플리케이션을 조각으로 분리하지 않고 한 덩어리로 클라우드 환경에 올라가는 것은 “클라우드 프렌들리” 라고 한다. (피보탈Pivotal에서 붙인 이름들이라고 한다.)

거의 모든 서비스가 클라우드 환경을 사용하고 있는 요즘, 우리는 하나의 애플리케이션을 조각조각 분리하여 사용하는 클라우드 네이티브 한 구조를 가진 마이크로서비스를 따라 애플리케이션을 제작할 것이다.

 

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

하나의 단위로 개발되는 일체식 애플리케이션인 모노리스(monolith)와 달리 애플리케이션이 여러개의 조각으로 분리되어 각각 조각들이 별개의 인스턴스로 로딩되는 방식이다.

마이크로서비스 아키텍처 스타일은 하나의 애플리케이션을 작은 서비스 스위트로 개발하는 접근 방식으로, 각 서비스는 자체 프로세스에서 실행되며 경량 메커니즘으로 통신하고, 종종 HTTP 리소스 API를 사용합니다. 이러한 서비스는 비즈니스 기능을 중심으로 구축되며 완전 자동화된 배포 도구를 통해 독립적으로 배포될 수 있습니다. 이러한 서비스는 서로 다른 프로그래밍 언어로 작성되고 서로 다른 데이터 저장 기술을 사용할 수 있으며, 중앙 집중식 관리가 최소화됩니다. In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

- James Lewis and Martin Fowler (2014)

https://martinfowler.com/microservices/

 

마이크로서비스 기본 개념도

마이크로서비스 기본 개념도

장점

• 모듈성과 유연성
  • 각각의 마이크로서비스는 특정 기능이나 업무 영역을 담당하므로 모듈성이 높고 독립적으로 개발, 배포, 확장할 수 있습니다. 이는 애플리케이션을 더 유연하고 쉽게 확장할 수 있도록 돕습니다.
• 기술 다양성
  • 각 마이크로서비스는 독립적으로 개발되므로 서로 다른 기술 스택을 사용할 수 있습니다. 이는 팀이 최적의 도구와 기술을 선택하여 특정 요구 사항에 가장 적합한 솔루션을 개발할 수 있도록 합니다.
• 빠른 개발 및 배포
  • 작은 규모의 서비스로 분해되어 있기 때문에 개발 시간이 단축되고 더 빠른 배포가 가능합니다. 또한, 변경 사항이 하나의 서비스에 영향을 미치지 않도록 보장할 수 있어 더 빠른 이터레이션과 릴리스가 가능합니다.
• 확장성
  • 마이크로서비스는 독립적으로 확장할 수 있으므로 특정 서비스에 대한 요구량이 높아지는 경우 해당 서비스만 확장하여 대응할 수 있다.
• 고가용성과 견고성
  • 하나의 서비스가 실패해도 다른 서비스에 영향을 미치지 않고 시스템 전체가 계속 작동할 수 있다. 이는 고가용성과 시스템의 견고성을 향상시킬 수 있다.
• 변경 관리 용이성
  • 마이크로서비스는 작고 단일 책임을 가지고 있기 때문에 변경을 관리하기 쉽다. 하나의 변경이 다른 서비스에 영향을 미치는 경우가 적어 전체 시스템을 변경하는 것보다 훨씬 안정적으로 변경을 수행할 수 있다.

단점

• 복잡성
  • 여러 개의 작은 서비스로 분해되어 있기 때문에 전체 시스템의 복잡성이 증가한다. 서비스 간의 통신, 데이터 일관성 유지, 분산된 로깅 및 모니터링 등을 관리해야 한다.
• 테스트 및 디버깅의 어려움
  • 서비스 간의 상호작용 및 의존성으로 인해 테스트 및 디버깅이 어려울 수 있습니다. 분산된 환경에서의 문제 해결은 더욱 어려울 수 있다.
• 네트워크 부하
  • 마이크로서비스 아키텍처는 여러 서비스 간의 통신이 필요하므로 네트워크 부하가 증가할 수 있다. 특히, 마이크로서비스 간의 통신이 느릴 경우 전체 시스템의 성능에 영향을 미칠 수 있다.
• 데이터 관리의 어려움
  • 서비스 간의 데이터 일관성을 유지하기 위한 데이터 관리가 어려울 수 있다. 데이터의 소유권 및 업데이트, 트랜잭션 경계 등을 관리해야 한다.
• 운영 복잡성
  • 여러 개의 서비스를 운영하고 모니터링하는 것은 복잡할 수 있습니다. 서비스의 확장성, 가용성, 장애 복구 등을 관리하기 위한 운영 팀의 노력이 필요.
• 개발자의 추가적인 책임
  • 각 서비스는 독립적으로 개발되고 운영되기 때문에 개발자는 서비스 간의 상호작용, 데이터 일관성 등을 고려해야 합니다. 이는 추가적인 책임과 학습 곡선을 의미할 수 있다.

1.3 마이크로서비스를 위한 조건은 무엇인가?

책에서는 다음 6가지가 필요하다고 말한다.

1. 직업 분류가 아닌 업무 기능 중심의 팀
2. 자율적인 분권 거버넌스, 폴리글랏을 이용한 관리.
3. 프로젝트가 아닌 제품 중심의 개발 생명주기.
4. 인프라 자동화 개발 환경
5. 통합 저장소가 아닌 분권 데이터 관리
6. 실패를 고려한 설계 (이슈에 대응 할 수 있는 설계)

 

---

한정헌님이 작성하신 서문 내용 중 공감이 가고 동의하는 내용이 많았다

2000년 인터넷 업계의 개발자로 시작한 첫 3년 동안은 내가 무엇인가를 창조하고 있다는 생각에 코딩이 마냥 즐겁기만 했고…중략 ... DB와 UI 중심의 설계에서 개발자의 창의력은 전혀 필요하지 않았고 컨베이어 벨트의 노동자처럼 던져준 테이블 명세와 화면 명세를 보고 그것을 이어주는 비슷비슷한 코드를 찍어내는 역할만 해야 했다. 납기 수준의 압박으로 대부분의 코드는 개선없이 기존 레거시 코드를 새로운 언어로 컨버전한 수준이었다.

- 도메인 주도 설계로 시작하는 마이크로서비스 개발

그 시점에 느낀 소프트웨어에 대한 내 생각은 좋은 소프트웨어란 빠른 비지니스 변화를 지원해야 하지만 그것을 위해 소프트웨어를 만드는 개발자도 힘든 야근이나 장시간 노동을 해서도 안 되며, 그러기 위해서는 복잡성을 제거하고 유연한 설계가 필요하다는 것이었다. 빠른 변경을 포용할 수 있는 쉽고 도메인 응집성이 있고 단순하면서 아름다운 설계. 그런 설계에서 비로소 개발자의 노력도 절감되고 긍지와 보람을 느낄 수 있을 것 이라 생각한다.

- 도메인 주도 설계로 시작하는 마이크로서비스 개발