본문 바로가기

좋아하는 것_매직IT/10.microservice

23.마이크로서비스, 마이크로서비스를 만들어 갈때, 아키텍처 설계에 대해서 알아보자.

반응형

소프트웨어 프로젝트에서 아키텍트 역할

  • 해결해야 될 문제의 동작 모델을 제공하는 것.
  • 애플리케이션 코드가 서로 들어맞도록 코드를 작성하는 개발자를 위한 발판도 제공해야 됨.

마이크로서비스 아키텍처를 구축 시 집중해야 할 것.

  • 비즈니스 문제의 분해
  • 서비스 세분화의 확정
  • 서비스 인테페이스 정의

비즈니스 문제의 분해

  • 비즈니스 문제를 각 활동영역을 대표하는 영역으로 분해하고, 비즈니스 영역의 특정 부분과 연관된 비즈니스 규칙과 데이터 로직을 영역안에 캡슐화함.
  • 데이터 영역이 서로 어울리지 않는다면 마이크로서비스들의 서비스 경계를 나눠야함.
  • 분해시 참고하면 좋을 지침 3가지
    • 비즈니스 문제를 기술하고 그 문제를 기술하는 데 사용된 명사에 주목
      • 문제에 대한 동일한 명사가 반복사용되는 경우, 대개 핵심 비즈니스 영역과 마이크로서비스로 만들 기회가 들어남.
    • 동사에 주목 
      • 행위를 부각하고 문제가 되는 영역의 윤곽을 자연스럽게 드러내는게 동사임.
    • 데이터 응집성을 찾기
      • 분해할 때 서로 연관석이 높은 데이터 부분들을 찾아야함.

서비스 세분화의 확정

  • 데이터 모델을 단순화하고나서, 그 다음 차례는 애플리케이션이 필요한 마이크로서비스를 정의할 단계.
  • 주요 기능을 가져와 서로 독립적으로 빌드하고 배포할 수 있는 자체 완비형 유닛을 추출하는 것.
  • but, 데이터 모델에서 시비스를 추출하는 일은 단순히 코드를 여러 프로젝트로 패키징하는 것보다 더 많은 작업이 필요하고 요구됨.
  • 실제 데이터베이스 테이블을 서비스에 따라 정리하고, 각 서비스가 특정 도메인의 테이블만 액세스하게 하는 일도 필요하고 중요함.
  • 세분화를 위한 해결책 3가지
    • 큰 마이크로서비스에서 시작해 작게 리팩토링하는 것이 더 좋음.
      • 처음부터 모든 것을 마이크로서비스로 만들게 되면, 너무 일찍 복잡함을 겪을 수도 있음.  
    • 서비스 간 교류하는 방식에 먼저 집중해야함.
      • 큰 단위의 인터페이스를 만드는 데 도움이 됨. 추후에 해당 큰단위에서 작게 리팩토링하길.
    • 문제 영역에 대한 이해가 깊어짐에 따라 서비스 책임도 계속 변화하게 됨.  
      • 마이크로서비스는 단일 서비스에서 시작, 여러 서비스로 분화되며 성장함. 
      • 원래 서비스는 새로운 서비스들을 오케스트레이션하고 애플리케이션의 다른 부분에서 새 서비스들의 기능을 캡슐화함.
  • 나쁜 마이크로서비스의 징후
    • 책임이 너무 많은 서비스
    • 많은 테이블의 데이터를 관리하는 서비스
      • 마이크로서비스는 자기가 관리하는 데이터를 기록하는 시스템임.
    • 과다한 테스트 케이스
      • 시간이 지나면, 서비스 크기와 책임이 늘어날 수 있음. 서비스가 많은 테스트 케이스로 늘어난다면, 리팩토링이 필요함.
    • 한 문제 영역 부분에 속한 마이크로서비스가 토끼처럼 번식함.
      • 모든 것이 마이크로서비스로 되면 작업 수행에 필요한 서비스 개수가 엄청나게 증가해, 서비스에서 비즈니스 로직을 만드는 것이 복잡해짐.
    • 마이크로서비스가 지나치게 상호 의존적 일 경우.
      • 문제영역의 한부분에 있는 마이크로서비스는 하나의 사용자 요청을 완료하기위해 각 서비스가 서로 계속 호출하게됨.
    • 마이크로서비스가 단순한 CRUD(Create, Read, Update, Delete) 집합이 될 경우
      • 마이크로서비스가 CRUD 관련 로직만 수행한다면 너무 잘게 나뉘어 있다는 의미함.

   

서비스의 인터페이스 정의

  • 애플리케이션의 마이크로서비스가 대화하는 방식을 정의하는 것.
  • 서비스 인터페이스 설계시 고려해야할 지침 4가지
    • REST 철학을 수용
      • HTTP 동사를 기반으로 기본 행동 약식을 모델링해야 함.
    • URI를 사용해 의도를 전달하기 
    • 요청과응답에 JSON 사용
      • JSON은 초경량 데이터 직렬화 프로토콜이고, XML보다 훨씬 사용하기 쉬움. - HTTP 상태 코드로 결과를 전달.
    • 상태코드를 익히고, 모든 서비스에 일관되게 사용하는 것이 매우 중요.

  

결론

  •  모든 기본 지침은 서비스 인터페이스를 쉽게 이해하고 소비할 수 있는 게 만드는 것.

  • 금일의 한마디 명언
    • 평범한 기준에 따라 교육받고 살아간다면, 결국 평범한 일생을 보낼 것이고 독창적인 사고는 결코 할 수 없다. -찰스 필모어
728x90
300x250