[Spring Cloud로 개발하는 마이크로서비스 애플리케이션]-Introduction to Micro Service-2

12Factors

-Cloud Native Application을 만들 때 고려해야할 12가지

• 코드 통합 : 형상 관리를 위해 코드를 한 곳에서 배포하는 것이 주 목적
• 종속성 배제 : 각 Micro Service는 자체 종속성을 가지고 패키징 되어있음 전체 시스템에 영향을 주지않는 형태에서 변경 되어야 함
• 환경설정의 외부 관리 : 코드의 외부에서 관리 도구를 통해 Micro Service에 필요한 작업들을 구성할 수 있어야함
• 백업 서비스의 분리 : 응용프로그램 자체에서 필요한 백업 서비스를 분리하게 됨으로서 서로 상호가능한 서비스 자체를 종속성 없는 상태에서 작업 가능
• 개발 환경과 테스트 운영 환경의 분리 : 빌드,릴리즈,실행환경을 분리. 개발 서버에서 만들어진 코드 배포 하기위해 실행단계 까지 옮기는 환경을 엄격하게 관리
• 상태관리 : 프로세스 각각의 Micro Service들은 실행되는 서비스와 분리된 채, 프로세스에서 운영가능해야 함(독립성과 일치)
• 포트 바인딩 : 다른 Micro Service와 격리를 위해 각각의 Micro Service는 자체 포트에서 노출되는 인터페이스 및 자체에 포함되는 기능이 있어야 함
• 동시성 : 하나의 서비스가 여러가지 인스턴스에 동일한 형태로 복사되면서 운영됨으로서 부하 분산이 가능
• 서비스의 올바른 상태 유지 : 서비스의 인스턴스 자체가 삭제가 가능 하며 확장성을 높이고 정상적으로 종료 될 수 있는 환경이 되어야 함
• 개발과 production단계 구분 : 환경자체를 최대한 다른 쪽에 있는 작업과 중복되지 않고 종속되지 않는 상태로서 서비스를 유지할 수 있어야
• Log의 분리 : Log를 출력시키는 Logic은 기존에 있었던 Application Logic과 분리 되어서 Application 자체가 실행되지 않는 상태라 해도 Logging만은 정상적으로 작동해야 함
• 관리 프로세스 : 현재 운영되고 있는 모든 Micro Service들이 어떤 상태이며 어떤 리소스로 구성되어있는지 파악하기 위해 관리 도구가 필요. 이러한 작업에는 리포팅할 수 있는 기술이 포함되어 있어야 하고 데이터 정리 및 데이터를 분석하는 기능이 포함될 수 있음
• 최근에는 12Factors에 3개의 항목을 더한 기준도 있음!
  -API First : 모든 Micro Service는 API형태로 서비스 제공. API를 구축함에 있어서 사용자 측에서 어떤 형태로 사용할 것인지는 알아야 함
  -Telemetry : 모든 지표는 수치화 및 시각화 되어야 함
  -Autentication and Authorization : API를 사용함에 있어서 인증 과정 필수

Monolithic vs MSA

• Monolithic
  Application을 개발함에 있어 모든 요소들을 하나의 거대한 Software안에서 전부 포함시켜 개발하는 방법. 따라서 Application을 구성하는 서비스들 간 의존성을 가짐. 이는 즉, 시스템 일부만 수정을 하여도 전체 시스템을 다시 패키징 하고 빌드-테스트-배포 해야하는 과정을 거쳐야함.
• MSA
  Application을 구성하는 구성 요소 및 Service를 분리하여 운영하는 방식.
  유지보수 및 변경사항이 적용이 쉬워짐. 변경이 필요할 때 필요한 부분만 변경하게 되고 다른 Service에 영향을 끼치지 않고 독립적으로 Service 가능. 따라서 Application 자체가 down되는 현상을 없앨 수 있음!
  심지어 각각의 Service들은 최소화된 중앙집중된 관리만 필요하고 서로 다른 언어 및 서로 다른 Database를 사용가능 하기 까지도 함!
  각각의 Sevice들은 제공해야하는 Service를 restAPI를 통해서 제공 가능 및 다른 Micro Service들과 통신 가능.
• Trend
  최근에는 Application 개발 시 Smart Device를 고려해야 함. 이제는 Web Browser 뿐 아니라 스마트 워치,스마트 폰,태블릿,노트북과 같은 Device들도 고려 해야 함 -> 사용자가 요청하는 형태로 응답이 가능 해야 한다는 뜻!
  이를 위해, RestAPI를 사용!

Micro Service Architecture

• 특징
  1. challenges : 개발 방식 및 패러다임을 상당히 바꾸어야 함
  2. small Well chosen Deployable Units : 독립적으로 개발 가능한 형태의 작은 서비스
  3. Bounded Context : 각각의 서비스들은 어플리케이션을 구성하고 있는 전체 도메인의 지식에 따라 서비스 경계를 잘 구분 해야 경계로 인해 하나의 서비스가 여러개, 여러개가 단일화 될 수 있음
  4. Restful : 상태에 대해서 restapi로 통신 json포맷 이용 서버의 리소스 및 상태 표시에 최적화
  5. Configuration management : 마이크로 서비스들이 갖고 있는 설정 및 환경 정보는 코드 내에 갖고 있지 않고 외부에 시스템을 통해 관리
  6. cloud enabled : 클라우드 네이티브 기술을 최대한 활용
  7. dynamic scale up and down
  8. CI/CD
  9. visibility : 마이크로서비스 기술들은 시각화 할 수 있는 관리도구 들을 가지고 있어야 함

이렇게 Micro Service Architecture가 '와! 엄청난 기술이다' 라는 것을 확인 해 봤습니다.

But! 무조건 Micro Service Application만 만들어야 할까요?!
-처한 환경 및 기존 Application에서 MSA로 전환 혹은 Application개발 시,생기는 이익에 대하여 생각을 해야 합니다!
1. 변화로 인해 생기는 이익이 어느 정도 이상이 되어야 Micro Service Application으로 전환을 할 것인지 봐야함.
2. 유지 보수 및 확장성에 대처가 가능한지 확인.
3. 오류를 격리시킬 수 있는지 확인.
4. 외부 종속성과 상호 작용을 단순화 시킬 수 있는지 확인.
5. 여러가지 프로그래밍 언어,스토리지 기술을 지원 할 수 있는지 확인.
위의 환경들이 충분히 고려되어 있다고 하면 전환 및 도입이 가능할 수 있습니다!

이상으로 블로그 포스팅을 마치겠습니다. 감사합니다 :)

이 글은 인프런 이도원님의 'Spring Cloud로 개발하는 마이크로서비스 애플리케이션'을 수강하고 작성합니다.
출처:https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4/dashboard