AWS MSA 2. 비즈니스 기능 중심으로 구성(Organized Around Business Capabilities)

원문 : Running Containerized Microservices on AWS
https://d1.awsstatic.com/training-and-certification/docs-devops-pro/running-containerized-microservices-on-aws.pdf

 

 마이크로서비스를 구성하는 요소를 정의하는 것은 개발 팀이 동의해야 한다. 그 경계는 무엇일까? 응용 프로그램이 마이크로 서비스인가? 공유 라이브러리는 마이크로서비스인가?

 

 마이크로서비스 이전에는 사용자 인터페이스, 데이터베이스 및 서버 측 로직과 같은 기술 기능을 중심으로 시스템 아키텍처가 구성되었다. 마이크로서비스 기반 접근 방식에서 각 개발 팀은 고객의 서비스 수명 주기를 소유한다. 예를 들어, 모범사례는 개발, 배포, 프로덕션 지원 및 고객 피드백 수집을 소유할 수 있다.

 

 마이크로서비스 중심 조직에서 소규모 팀은 프로덕션 환경에서 코드를 빌드, 배포 및 관리하기 위해 자율적으로 행동한다. 이를 통해, 팀은 각자의 속도에 따라 기능을 제공할 수 있다. 책임은 소유 문화를 조성하여 팀이 조직의 목표에 더 잘 부합하고 생산성을 높일 수 있도록 한다.

 

 마이크로서비스는 기술적인 접근 방식만큼 조직적인 태도이다. 이 원칙을 Conway 's Law라고 한다.

 

"디자인 시스템을 구성하는 조직은 이러한 조직의 커뮤니케이션 구조의 디자인을 생성하도록 제한되어 있다." — M. Conway

 

 비즈니스 기능을 중심으로 아키텍처와 기능이 구성되면, 구성 요소 간의 종속성이 느슨하게 결합된다. 서비스와 팀 간에 커뮤니케이션 계약이 있는 한 각 팀은 각자의 속도로 운영할 수 있다. 즉, 개발자는 구성 요소에 가장 적합한 프로그래밍 언어를 자유롭게 사용할 수 있다. 예를 들어, 사용자 인터페이스는 JavaScript 또는 HTML5로 작성되고, 백엔드는 Java로 작성되며, 데이터 처리는 Python으로 수행될 수 있다.

 

 이는 비즈니스 기능이 개발 결정을 이끌 수 있음을 의미한다. 기능을 구성한다는 것은 각 API 팀이 기능, 데이터 및 성능을 완전히 소유한다는 것을 의미한다. 기능 구성에 중요한 역할을 하는 12 가지 앱 패턴 방법론의 주요 요소는 다음과 같다.

 

• 코드베이스 (추적 된 하나의 코드베이스, 많은 배포) : 각 마이크로서비스는 별도의 리포지토리와 코드 변경 수명주기 동안 고유한 코드베이스를 소유한다.

• 빌드, 릴리스, 실행 (빌드 및 실행 단계) : 각 마이크로서비스에는 고유 한 배포 파이프라인과 배포 빈도가 있다. 이를 통해 개발 팀은 다양한 속도로 마이크로서비스를 운영 할 수 있으므로 고객의 요구에 부응할 수 있다.

• 프로세스 (하나 이상의 상태 비 저장 프로세스로 실행) : 각 마이크로서비스는 하나의 작업을 수행하고 실제로 한 가지 작업을 수행한다. 마이크로서비스는 가능한 최상의 방법으로 문제를 해결하도록 설계된다.

• 관리 프로세스 (일회성 프로세스로 관리 / 관리 작업 실행) : 각 마이크로서비스에는 고유 한 관리 또는 관리 작업이 있으므로 설계된 대로 작동한다.

 

 비즈니스 기능을 중심으로 구성된 마이크로서비스 아키텍처를 달성하려면, 널리 사용되는 디자인 패턴 사용을 고려한다.

 

• Command : 이 패턴은 요청을 객체로 캡슐화하여 다른 요청, 대기열 또는 로그 요청으로 클라이언트를 매개 변수화하고 실행 취소 가능한 작업을 지원할 수 있다.

• Adapter : 이 패턴은 기존 구성 요소의 임피던스를 새로운 시스템에 일치시키는 데 도움이 된다.

• Singleton : 이 패턴은 하나의 개체 인스턴스  필요한 응용 프로그램을위한 것이다.

• Chain of responsibility : 이 패턴은 요청을 처리 할 기회를 여러 개체에 부여하여 요청 발신자를 수신자에게 연결하지 않도록 한다.

• Composite : 이 패턴은 응용 프로그램이 "기본" 및 "복합" 개체의 계층 적 컬렉션을 조작하는 데 도움이 된다. 서비스는 다른 작은 기능의 복합 일 수 있다.

• Products Not Projects : 회사는 고객과 최종 사용자의 경험에 중점을 두면 더 성공할 것이다.

 

 엔지니어링 조직은 운영을 단순화하며 효율성을 높이려면, 소프트웨어 구성 요소를 반복적으로 개선할 수 있고 지속적으로 발전하는 제품으로 취급해야 한다. 이는 소프트웨어를 프로젝트로 취급하는 전략과는 대조적이다. 프로젝트는 엔지니어 팀에 의해 완료된 후, 소프트웨어를 담당하는 운영 팀에게 전달된다. 소프트웨어 아키텍처가 소규모 마이크로서비스로 분리되면, 각 마이크로서비스가 개별 제품이 될 수 있다. 내부 마이크로서비스의 경우, 제품의 최종 사용자는 다른 팀 또는 서비스이다. 외부 마이크로서비스의 경우 최종 사용자가 고객이다.

 

 소프트웨어를 제품으로 취급하는 데 따른 주요 이점은 최종 사용자 경험이 향상된다는 것이다. 조직에서 소프트웨어를 일회성 프로젝트가 아니라, 항상 개선하는 제품으로 취급하면 향후 작업에 보다 적합한 코드를 생성한다. 엔지니어는 향후 문제를 일으킬 수 있는 부분은 사용하지 않고 장기적으로 소프트웨어를 계속 유지할 수 있도록 소프트웨어를 계획한다. 이러한 방식으로 계획된 소프트웨어는 운영, 유지 관리 및 확장이 더 쉽다.

 

 또한 엔지니어가 소프트웨어를 구축, 제공 및 실행해야 하는 경우 실제 시나리오에서 소프트웨어의 성능을 더 잘 파악하여 피드백 루프를 가속화 할 수 있다. 따라서 소프트웨어를 쉽게 개선하거나 문제를 해결한다.

 

 소프트웨어를 전달하기 위해 제품 사고방식을 채택하는 데 중요한 역할을 하는 12가지 앱 패턴 방법론의 주요 요소는 다음과 같다.

 

• 빌드, 릴리스, 실행 – 엔지니어는 세 단계를 모두 최적화할 수 있는 "데스크" 문화를 채택한다.

• 구성 – 엔지니어는 고객이 해당 소프트웨어를 사용하는 방식에 관여하여 소프트웨어의 구성 관리 기능을 향상시킨다.

• 개발 / 제품 패리티 – 제품으로 취급되는 소프트웨어는 장기 실행 프로젝트보다 완료 및 배포에 시간이 덜 걸리는 작은 조각으로 반복적으로 개발할 수 있다. 개발 및 생산이 패리티에 가깝다.

 

 제품 사고방식 채택은 문화와 프로세스, 즉 변화를 유발하는 두 가지 요소에 의해 결정된다. 조직의 엔지니어링 팀의 목표는 코드를 작성하는 엔지니어와 프로덕션에서 코드를 실행하는 엔지니어 사이의 벽을 무너 뜨리는 것이다. 다음 개념이 중요하다.

 

• 자동 프로비저닝 – 수동이 아닌 작업을 자동화해야 한다. 이것은 속도를 높이고 엔지니어링과 운영을 통합한다.

• 셀프서비스 – 엔지니어는 자신의 종속성을 구성하고 프로비저닝 할 수 있어야 한다. 이는 컨테이너화된 환경에서 가능하므로 엔지니어는 필요한 모든 것을 갖춘 자체 컨테이너를 구축할 수 있다.

• 지속적인 통합 – 엔지니어는 코드를 자주 체크인하여 가능한 한 빨리 검토 및 테스트할 수 있도록 점진적인 개선 가능하다.

• 지속적인 빌드 및 전달 – 체크인 된 코드를 작성하여 프로덕션으로 전달하는 프로세스를 자동화하여 엔지니어가 수동 개입 없이 코드를 릴리스할 수 있다.

 

 컨테이너화된 마이크로서비스는 엔지니어링 조직이 소프트웨어 제공을 위한 표준화된 형식을 만든다. 이는 로컬, 품질 보증 및 생산을 포함한 다양한 환경에서 자동화를 쉽게 구축하고 사용할 수 있도록 한다. 이러한 모범 사례 패턴을 구현하도록 도와준다.