책너두 (도메인 주도 설계로 시작하는 마이크로서비스 개발) 2일차 (~10p)

요약

• 기업의 비즈니스 민첩성에 대한 내용을 이해함.
  • 클라우드 환경의 등장으로 유명한 기업의 비즈니스 민첩성이 장점으로 두드러지게 됨.
  • ex) 아마존의 배포속도는 초당 1.5번임.
• 클라우드 인프라의 등장
  • 시스템 인프라 구축에 시간을 단축시키고 손쉽게 구축 가능함.
  • 클라우드 인프라르 사용하는 애플리케이션은 블록이 작으면 작을수록 효율적임.
    • 스케일 아웃, 스케일 업
  • 궁극적으로 클라우드 프렌들리에서 클라우드 네이티브로 전이되야 함.
• 마이크로 서비스란?
  • 모노리스
    • 하나의 단위로 개발되는 일체식 애플리케이션임.
  • SOA
    • 애플리케이션은 모듈별로 분리했지만 데이터 저장소까지 분리하지는 못함.
  • MSA
    • 애플리케이션 모듈별 분리와 함께, 저장소도 분리함.

메모

01. 아마존 비즈니스 민첩성의 비밀

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

• 아마존, 넷플릭스, 우버와 같은 기업들은 자신만의 특화된 서비스를 제공하려는 시도를 누구보다 빨리 실행함.
• 또, 사용자 피드백을 반영해 끊임없이 서비스를 개선함.
  • 이런 기업들의 특출난 장점으로 비즈니스 민첩성(Agility)을 꼽고, 이를 기업 성공의 가장 큰 요인이라 말함.
• 클라우드 환경의 등장과 이를 잘 활용한 위 기업들의 사례에서 비즈니스 성과로 나타나고 있음.

1.1.1 성공 사례: 아마존의 배포 속도

• 2019년 국내 AWS 컨퍼런스 발표에서, 아마존 서비스의 배포 주기가 초당 1.5번으로 향상되었다고 함.
  • 비즈니스는 계쏙 변경되므로 이에 따른 개선된 시스템도 계속 배포돼야 함.
  • 빠른 배포 주기는 비즈니스의 민첩성을 간접적으로 보여주는 지표라 할 수 있음.
• 아마존이 어떻게 이 같은 비즈니스 속도를 갖게 됐는지 살펴보자.

1.1.2 클라우드 인프라의 등장

• 전형적인 시스템 인프라 구축 과정은 다음과 같음.
  1. 서버 도입
  2. 네트워크 구축
  3. 각 서버마다 운영체제 설치
  4. 서비스에 필요한 소프트웨어 설치
     • 이 전 과정을 완료하려면 적게는 며칠에서 몇 주, 길게는 몇 달이 걸림.
• 위 문제는 클라우드 인프라의 등장으로 말끔히 해결됨.
  • 서비스 개발에 필요한 시스템 인프라를 준비하는 데 오랜 시간이 들지 않음.
• 수많은 스타트업이 생겨나고, 참신한 서비스를 빠르게 선보이는 것을 보면 클라우드 인프라가 얼마나 강력하게 비즈니스 개발의 민첩성을 촉진하는지 알 수 있음.

1.1.3 클라우드 인프라에 어울리는 애플리케이션의 조건

• 클라우드 인프라를 사용하면, 사용랴에 따라 비용을 유연하게 조정할 수 있음.
  • 즉, 사용한 만큼만 비용을 지불함.
• 실제로 서비스를 제공하는 애플리케이션 측면에서 바라보면
  • 비즈니스 민첩성을 지원하기 위해 인프라와 마찬가지로 필요한 시점에 필요한 만큼만 애플리케이션을 변경해 배포하고 싶음.
  • 그래야 비용도 아끼고, 개선된 시스템을 꾸준히 배포할 수 있기 때문
    • 이러한 애플리케이션의 구조는 어떤 모양일까?
      • 클라우드는 여러 개의 서버 장비가 모여 논리적으로 하나처럼 관리됨.
      • 이러한 애플리케이션이 탑재되는 클라우드 인프라는 사용한 단위 만큼만 비용을 지불하므로 애플리케이션 블록이 작으면 작을수록 효율적임.

스케일 업과 스케일 아웃

• 사용량 증가에 따른 성능 및 가용성을 높이는 방법으로
  • 스케일 업(Scale-up)
    • 기존 시스템 자체의 물리적 용량을 증가시켜 성능을 높이는 방법.
  • 스케일 아웃(Scale-out)
    • 기존 시스템과 용량이 같은 다수의 장비를 병행 추가해서 가용성을 높이는 방법.

특정 서비스만 탄력성 있게 확장(스케일 아웃)

• ex) 1주일간의 세일 기간 중, 정작 바쁜 업무는 세일 이벤트를 수행하는 부분임.
  • 나머지 부분은 사용자가 몰리지 않아 더 한가해질 수도 있음.
• 세일 기간에 타임세일 이벤트를 수행하는 모듈만 열심히 일할 수 있도록 용량을 증설하고, 트래픽에 반응해 복제되게 설정하면 됨.
  • 즉, 시스템을 작은 단위의 독립적인 서비스 연계로 구성해야 함.

클라우드 프렌들리와 클라우드 네이티브

• 하나의 덩어리로 만들어 클라우드 인프라에 올려도 비즈니스 제공에는 문제가 없음.
  • 하지만 특정 기능만 확장하거나 배포할 수 없는 비효율을 감수해야 함.
• 클라우드 친화 애플리케이션이란?
  • 큰 덩어리로 클라우드 환경에 올라갈 수 있게만 한 애플리케이션
• 클라우드 네이티브 애플리케이션이란?
  • 독립적으로 분리되어 배포될 수 있는 조각으로 구성된 애플리케이션
• 궁극적으로, 클라우드 친화 애플리케이션에서 클라우드 네이티브로 전이해야 한다고 말함.
• 시스템이 비즈니스 민첩성을 잘 지원하기 위해서는 클라우드 인프라를 효율적으로 활용하도록 애플리케이션 조각으로 구성된 클라우드 네이티브 애플리케이션이 가장 효과적임.
  • 아마존의 비즈니스 개선 속도인 0.66초를 만든 것이 바로 이것임.

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

1.2.1 모노리스와 마이크로서비스 비교

• 모노리스는 하나의 단위로 개발되는 일체식 애플리케이션임.
  • 보통 3티어라 불리는 사용자 인터페이스와 데이터베이스, 서버 쪽 애플리케이션의 3개 부분으로 구성됨.
  • 서버 측 애플리케이션이 논리적 단일체로서 아무리 작은 변화에도 새로운 버전으로 전체를 빌드해서 배포해야 함.
  • 또, 일체식 애플리케이션은 단일 프로세스에서 시랳오딤.
    • 따라서, 확장이 필요한 경우, 특정 기능만 확장할 수 없고 반드시 전체 애플리케이션을 동시에 확장해야 함.
    • 이 상황에서, 변경이 발생하면 모노리스 시스템의 단점이 극대화 됨.
      • 여러 개의 모노리스 시스템이 수평 확장되었다면, 시스템 모두를 전부 다시 빌드하고 배포해야 함.
      • 사용량 증가에는 대응할 수 있지만 데이터베이스는 통합된 하나이므로 탄력적으로 대응할 수 없음.
• 마이크로 서비스는 서버 측이 여러 개의 조각으로 구성돼 각 서비스가 별개의 인스턴스로 로딩됨.
  • 즉, 여러 서비스 인스턴스가 모여 하나의 비즈니스 애플리케이션을 구성함.
  • 각기 저장소도 달라서 업무 단위로 모듈 경계가 명확히 구분됨.
  • 기능별 독립 확장 가능함.
    • 다른 언어로 개발 가능.
    • 서비스 소유권을 분리해 서로 다른 팀으로 개발 및 운영할 수 있음.

1.2.2 SOA와 마이크로서비스

• 소프트웨어 공학에서 말하는 모듈화(modularity) 개념의 발전 흐름
  • 구조적(structured) 방법론
  • 객체 단위 모듈화를 위한 객체지향(object-oriented) 방법론
  • 모듈화의 단위가 기능별로 재사용할 수 있는 좀 더 큰 컴포넌트 → CBD(Component Based Development)
  • 컴포넌트를 모아 비즈니스적으로 의미 있고 완결적인 서비스 단위로 모듈화하는 SOA(Service Oriented Architecture)
• 이러한 SOA 와 MSA 는 뭐가 다른가?
  • 넓게 보면 여러 개의 응집된 비즈니스 서비스의 집합으로 시스템을 개발하는 점에서 SOA 와 MSA 는 개념적으로 큰 차이가 없음.
    • 하지만 SOA 는 구체적이지 않고 이론적임.
      • 실제 비즈니스 성공 사례까 많지 않음.
    • MSA는 클라우드 인프라 기술의 발전과 접목되어 있음.
      • 아마존과 넷플릭스에 의해 구체화됨.
• 마틴 파울러가 정의한 마이크로서비스 개념은
  • 각 서비스와 저장소는 다른 서비스 및 저장소와 격리돼 있으며, API를 통해서만 느슨하게 연계됨.
  • 이처럼 특정 서비스를 구축하는 데 사용되는 언어나 저장소를 자율적으로 선택할 수 있는 방식을 폴리글랏(Polyglot)하다고 표현함.
  • 여기서 SOA와 MSA 차이를 발견할 수 있음.
    • SOA 는 애플리케이션은 모듈별로 분리했지만 데이터 저장소까지 분리하지는 못함.
      • 데이터간 강 결합으로 애플리케이션도 독립 사용이 힘듦.
    • MSA는 SOA에 없는 두 가지 개념으로 모듈화 방식을 강화함.
      1. 서비스별 저장소를 분리해서 다른 서비스가 저장소를 직접 호출하지 못하도록 캡슐화함.
      2. REST API 같은 가벼운 개방형 표준을 사용하여 각 서비스가 느슨하게 연계되고 누구나 쉽게 사용할 수 있게 함.