Micro Service를 구현하기 위한 조건

• 조직의 변화 : 업무 기능 중심의 팀
  • 콘웨이 법칙 - 시스템을 개발할 때 항상 시스템의 모양이 팀의 의사소통 구조를 반영하도록 하는 것
  • 다양한 역할 (기획자, 디자이너, Front End 및 Back End 개발자, 설계자 등)로 구성되고 서비스를 처음부터 끝까지 만들기 위한 모든 단계의 역할을 갖추고 있는 팀
    • 같은 공간, 같은 시간을 공유하기 때문에 의사소통도 원할하고 의사 결정도 빠르게 진행

• 관리 체계의 변화 - 자율적인 분권 거버넌스, Polyglot
  • 팀은 빠르게 서비스를 만드는 것을 목적으로 두고 스스로 효율적인 방법론과 도구, 기술을 찾아 적용
  • 자기 서비스에 맞는 기술을 이용하도록 하는 것

• 개발 수명 주기의 변화 - 프로젝트가 아닌 제품 중심
  • 초기에 모든 일정을 계획하고 요구 사항 정의를 통해 개발할 기능을 나열하고 이에 대한 설계를 진행한 후 설계가 완료되어야 개발이 진행되고 각 단계는 완료 데드라인 안에 완료 함으로써 최종 기능을 제공하기 때문에 프로젝트 기간 중에는 아이디어를 포용하지 못하기 때문에 완료 후 기능 개선을 할 때 최악의 경우 프로젝트를 다시 진행해야 하는 경우가 발생할 수 있음
  • 점진 반복적인 모델 제품 중심의 Agile 개발 방식을 채용
    • 2~3주 정도 Sprint를 통해 소프트웨어를 개발 및 배포한 뒤 즉각적 피드백을 소프트웨어에 반영
    • Sprint 마다 회의록이나 문서화 작업을 진행 - JIRA를 많이 사용

• 인프라 자동화
  • Micro Service는 독립적으로 배포하기 때문에 여러 개를 배포할 가능성이 높아 이를 수동으로 배포하는 것은 바람직하지 않음
  • 개발을 하고 이를 배포하는 과정을 전부 자동화하여 사용
    • 개발 과정과 배포 과정을 자동화하는 것이 DevOps의 궁극적인 목적
• 저장소의 변화 - 통합 저장소가 아닌 분권 데이터 관리
  • 스토리지 가격이 저렴하고 네트워크 대역폭이 매우 커졌기 때문에 데이터를 통합 저장소에 넣을 필요가 없음
  • 각 서비스는 저장소를 공유하지 않고 API를 통해 데이터를 주고 받음
  • 데이터 비즈니스 정합성을 맞춰야 하는 데이터 일관성 문제가 발생함
    • 이를 해결하는 방식은 2단계 커밋을 이용하는 방법과 비동기 이벤트 처리르 하는 방식이 있지만 NoSQL은 일반적으로 2단계 커밋을 허용하지 않기 때문에 비동기 이벤트 처리를 권장함.
      • 2단계 커밋 : 여러 애플리케이션의 서비스를 묶어 하나의 트랜잭션을 만드는 방식
• 실패를 고려한 설계
  • 클라이언트 서버 프로그래밍을 할 때 완벽하게 동작하면 좋지만 반드시 동작한다는 보장은 할 수 없기 때문에 서버가 중지되었을 때 클라이언트에서 어떻게 이를 정상적으로 처리할 것인가 하는 문제