MSA (MicroService Architecture) 마이크로 서비스 아키텍쳐

채용공고를 보다가 MSA에 대한 키워드가 종종 보여서 학습해보았다.

• Monolithic (단일체의) : 모든 서비스를 하나의 동일한 서버로 구축
  
  
  • 특징
    • 전체 애플리케이션 단위 (개발, 테스트, 배포)
    • 동일한 개발툴 사용
      
      
  • 장점
    • 하나의 애플리케이션만 수행 → 환경설정이 간단한 편
    • 각 컴포넌트들이 함수로 호출 → 성능 제약이 덜하고, 운영 관리가 용이
    • 서비스간 호출이 하나의 프로세스 내에서 이루어져서 속도가 빠름
    • 작은 볼륨의 개발에 유용
      
      
  • 단점
    • 작은 수정에도 전체를 빌드 → CI/CD 에 불리
    • 이벤트로 인해 서비스 접속량이 폭증할 경우 선택적 확장 불가능
    • 이벤트 서비스에 트래픽이 몰려 해당 서버가 죽으면 모든 서비스 마비
    • 기술 스택을 한 번 정하면 바꾸기 어려움

• Micro Service : 비즈니스 기능별로 각 서비스를 독립된 서버로 분리해 구축

"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."


- Martin Fowler

• 등장 배경

  • 프로젝트 규모가 커질수록 효율을 위해 다양한 파트별로의 분업이 필요한데, MSA는 이를 가능하게 한다. 예를 들어, 실시간으로 요구사항을 반영해서 시스템의 전체 중단 없이 필요한 부분만 배포가 가능한데, 급성장한 기업들이 MSA의 유연한 대응 가능성을 보고 많이 선택하는 편이다. Netflix, Tesla 등 유명 테크 기업들의 성공 비결로 알려졌다.
    
    

• 특징

  • 데이터 분리 : 하나의 DB에 중앙 집중화 x
  • API Gateway를 사용 : 각 서비스가 다른 서버를 사용해서 서버 url이 다른데,
    서버의 End-point를 단일화하고 거미줄처럼 복잡한 서비스간의 api 호출 구조도 단순화 시킴.
  • 팀의 구조 변화: 업무 별보다는 서비스별로 팀이 나뉨 (기획+UX+개발)
    
    

• 장점

  • 독립된 배포 가능 → 빠른 배포 → 개발주기 단축 (+고객만족도 증대)
  • 트래픽 증가한 해당 서버만 확장
  • 업무 별로 팀이 나뉘는게 아니라 서비스별로 팀이 묶임 : 서로 피드백이 빠름, 유연하고 지속적인 운영-개발
  • 장애의 전파성이 모놀리식보다 적고 유지보수 용이
  • 신기술의 적용이 유연하고, 서비스를 polyglot (다국어) 하게 개발 가능
    
    

• 단점

  • 개발의 복잡성

    • 서비스간 호출을 API 통신을 사용 : 통신비용, 지연시간 발생
      통신에 사용하기 위해 값을 데이터 모델로 변환시켜주는 오버헤드가 발생하기도 하거나, 개별 서비스간 충돌이 있을 수 있음

  • 관리의 복잡성

    • 데이터, DB 트랜잭션, 테스트 등이 분리되어 관리 어려움

  • 인프라 부족

    • 개발자들 개개인의 인프라 핸들링 (AWS 등), 숙련도 필요

    
    
    

• 모놀리식 vs MSA 판단 기준

  • 초반은 모놀리식 아키텍쳐로 사용하다가
  • 비용상 절감효과, 시스템 복잡도 / 개발 생산성 비교, 운영 인프라, 개발팀력의 역량, 배포 환경에 따라 판단
    
    
    
    

• 프론트엔드에서의 적용 (마이크로 프론트엔드)
  
  

  • 서로 다른 어플리케이션을 조합해 하나의 통합된 어플리케이션을 만드는 설계 방법
  • 공통 부분을 제외하고 각 기능을 팀 특화에 맞는 각기 다른 어플리케이션으로 개발
    
    
    • 장점
      • 충돌 염려가 적고, 팀별 자율성이 높다
      • 독립 배포가 가능
      • 각각 개별 서비스를 작업해서 개발시간 절감
        
        
    • 단점
      • 여러 프레임워크 결합 -> 브라우저 호환 문제가 있을 수 있다. 브라우저에서 지원되는 기능 적극 활용 + 커스텀 API사용을 지양
      • 기능, 스타일 중첩 위험도가 높으니 컨벤션, 로컬 스토리지, 쿠키 사용 등 가이드라인 명확하게 설정해야 함
      • 어플리케이션 별로 중복된 dependencies가 여러벌 로드되거나 네트워크 트래픽 증가로 성능 저하 우려
      • 컴포넌트간의 복잡한 통신

• 오늘의 집에서 MSA 진행 방법
  
  
  • 오늘의 집 개발문화에서 배운 협업의 흐름 (Architecture)
    • 브레인스토밍 (when, how)
    • flow-chart 그리기
    • 기술스터디 : 멤버간의 경험, 지식 차이를 줄이기 위해
      (독서 + 논의 → 필요한 전략, 구조 완성)
    • 목표의 우선순위 + 컨벤션 정하기
      (컨트롤타워 역할이 있으면 더 좋음)
      (시간 안에 효율적으로 끝내기 위해 금지 사항 지정하는 것도 중요한 듯!)
    • 일정 관리 (마일스톤) + 기간 단위의 스프린트, 데일리 스크럼 진행
      → 매일의 이슈를 빨리 해결하고 해결이 어려운 부분은 팀에 공유
    • 모두의 개발 시간을 단축할 만한 부분은 빠른 공유
    • 코드 리뷰
      
      

우리에겐 지금 우리가 가는 길이 정답입니다.

경험해 보지 못한 문제를 해결하기 위해 빠르게 PoC 하고 실패하고 배워갑니다.
(Proof of Concept, 실현성 검증)

• 참조
  https://steady-coding.tistory.com/595
  https://www.opsnow.com/%EC%9A%94%EC%A6%98-%EB%8C%80%EC%84%B8-msa/
  https://blog.nextinnovation.kr/tech/microfrontend/