Microservices assessment and readiness

마이크로서비스 아키텍처는 민첩성, 확장성 및 고가용성을 포함하여 애플리케이션에 많은 이점을 제공할 수 있습니다. 이러한 이점과 함께 이 아키텍처는 과제도 제시합니다. 마이크로서비스 기반 애플리케이션을 구축하거나 기존 애플리케이션을 마이크로서비스 아키텍처로 변환할 때 개선이 필요한 영역을 식별하기 위해 현재 상황을 분석하고 평가해야 합니다.

이 가이드는 마이크로서비스 아키텍처로 이동할 때 염두에 두어야 할 몇 가지 고려 사항을 이해하는 데 도움이 될 것입니다. 이 가이드를 사용하여 애플리케이션, 인프라, DevOps, 개발 모델 등의 성숙도를 평가할 수 있습니다.

비즈니스 우선순위 이해(Understand business priorities)

마이크로서비스 아키텍처를 평가하기 시작하려면 먼저 비즈니스의 핵심 우선순위를 이해해야 합니다. 핵심 우선순위는 예를 들어 민첩성, 변화 수용 또는 빠른 개발과 관련될 수 있습니다. 아키텍처가 핵심 우선순위에 적합한지 분석해야 합니다. 비즈니스 우선순위는 시간이 지남에 따라 변할 수 있다는 점을 명심하세요. 예를 들어, 혁신은 스타트업의 최우선 과제이지만 몇 년 후에는 핵심 우선순위가 안정성과 효율성이 될 수 있습니다.

고려해야 할 몇 가지 우선순위는 다음과 같습니다.

• 혁신
• 신뢰성
• 효율성

평가의 지침이 될 수 있는 조직적 약속을 보장하기 위해 애플리케이션의 다양한 부분에 맞춰진 SLA(서비스 수준 계약)를 문서화하세요.

아키텍처 결정 기록(Record architectural decisions)

마이크로서비스 아키텍처는 팀의 자율성을 높여줍니다. 예를 들어, 팀은 기술, 방법론, 인프라 구성 요소에 대해 자체적으로 결정할 수 있습니다. 그러나 이러한 선택은 팀 간의 마이크로서비스 광범위 전략에 대한 합의를 나타내는 공유 거버넌스라는 공식적으로 합의된 원칙을 존중해야 합니다.

다음 요소를 고려하세요.

• 공유 거버넌스가 마련되어 있습니까?
• 아키텍처 저널에서 결정과 그에 따른 장단점을 추적합니까?
• 팀이 아키텍처 저널에 쉽게 액세스할 수 있습니까?
• 도구, 기술 및 프레임워크를 평가하는 프로세스가 있습니까?

팀 구성 평가(Assess team composition)

팀 간 불필요한 커뮤니케이션을 피하려면 적절한 팀 구조가 필요합니다. 마이크로서비스 아키텍처는 작고 집중된 교차 기능 팀 구성을 장려하며 팀 재구성이 선행되어야 하는 사고방식의 변화를 요구합니다.

다음 요소를 고려하세요.

• 팀이 도메인 주도 설계(DDD) 원칙에 따라 하위 도메인을 기반으로 분할되어 있습니까?
• 팀은 관련 마이크로서비스를 독립적으로 구축하고 운영할 수 있는 충분한 역량을 갖춘 교차 기능 팀입니까?
• 프로젝트와 관련 없는 임시 활동 및 작업에 얼마나 많은 시간을 소비합니까?
• 팀 간 협업에 얼마나 많은 시간을 소비합니까?
• 기술 부채를 식별하고 최소화하는 프로세스가 있습니까?
• 팀 간에 학습된 교훈과 경험을 어떻게 전달합니까?

12 요소 방법론 사용(Use the Twelve-Factor methodology)

마이크로서비스 아키텍처를 선택하는 근본적인 목표는 애자일 방식을 따라 더 빠르게 가치를 제공하고 변화에 적응하는 것입니다. Twelve-Factor methodology 앱 방법론은 유지 관리 가능하고 확장 가능한 애플리케이션을 구축하기 위한 지침을 제공합니다. 이러한 지침은 불변성, 임시성, 선언적 구성 및 자동화와 같은 속성을 장려합니다. 이러한 지침을 통합하고 일반적인 함정을 피함으로써 느슨하게 결합되고 자급자족적인 마이크로서비스를 만들 수 있습니다.

분해 접근 방식 이해(Understand the decomposition approach)

모놀리식 애플리케이션을 마이크로서비스 아키텍처로 변환하는 데는 시간이 걸립니다. 엣지 서비스부터 시작하세요. 엣지 서비스는 다른 서비스에 대한 종속성이 적고 독립적인 서비스로 시스템에서 쉽게 분해될 수 있습니다. 모든 서비스가 별도의 마이크로서비스로 분해될 때까지 모놀리식 애플리케이션을 작동 상태로 유지하기 위해 Strangler Fig 및 Anti-corruption Layer와 같은 패턴을 사용하는 것을 적극 권장합니다. 분리하는 동안 DDD 원칙은 팀이 하위 도메인을 기반으로 모놀리식 애플리케이션에서 구성 요소 또는 서비스를 선택하는 데 도움이 될 수 있습니다.

예를 들어 전자 상거래 시스템에는 장바구니, 제품 관리, 주문 관리, 가격 책정, 송장 생성 및 알림과 같은 모듈이 있을 수 있습니다. 다른 모듈에 대한 종속성이 없으므로 알림 모듈로 애플리케이션 변환을 시작하기로 결정합니다. 그러나 다른 모듈은 알림을 보내기 위해 이 모듈에 의존할 수 있습니다. 알림 모듈은 별도의 마이크로서비스로 쉽게 분해될 수 있지만 새 알림 서비스를 호출하기 위해 모놀리식 애플리케이션에서 몇 가지 변경 작업을 수행해야 합니다. 다음으로 송장 생성 모듈을 변환하기로 결정합니다. 이 모듈은 주문이 생성된 후 호출됩니다. Strangler 및 Anti-corruption과 같은 패턴을 사용하여 이 변환을 지원할 수 있습니다.

데이터 동기화, 모놀리식 및 마이크로서비스 인터페이스 모두에 대한 다중 쓰기, 데이터 소유권, 스키마 분해, 조인, 데이터 볼륨 및 데이터 무결성은 데이터 분해 및 마이그레이션을 어렵게 만들 수 있습니다. 마이크로서비스 간에 공유 데이터베이스를 유지하거나, 비즈니스 기능 또는 도메인을 기반으로 서비스 그룹에서 데이터베이스를 분리하거나, 서비스에서 데이터베이스를 격리하는 등 사용할 수 있는 여러 기술이 있습니다. 권장되는 솔루션은 각 서비스로 각 데이터베이스를 분해하는 것입니다. 많은 상황에서 이는 실용적이지 않습니다. 이러한 경우 데이터베이스 뷰 패턴 및 데이터베이스 래핑 서비스 패턴과 같은 패턴을 사용할 수 있습니다.

DevOps 준비 상태 평가(Assess DevOps readiness)

마이크로서비스 아키텍처로 이동할 때 DevOps 역량을 평가하는 것이 중요합니다. 마이크로서비스 아키텍처는 조직의 민첩성을 높이기 위해 애플리케이션의 애자일 개발을 촉진하기 위한 것입니다. DevOps는 이러한 역량을 달성하기 위해 구현해야 하는 주요 방식 중 하나입니다.

마이크로서비스 아키텍처에 대한 DevOps 기능을 평가할 때 다음 사항을 염두에 두세요.

• 조직의 사람들이 DevOps의 기본 방식과 원칙을 알고 있습니까?
• 팀은 소스 제어 도구와 CI/CD 파이프라인과의 통합을 이해합니까?
• DevOps 방식을 제대로 구현하고 있습니까?
• 애자일 방식을 따르고 있습니까?
• 지속적인 통합이 구현되어 있습니까?
• 지속적인 배포가 구현되어 있습니까?
• 지속적인 모니터링이 구현되어 있습니까?
• IaC(Infrastructure as Code)가 마련되어 있습니까?
• CI/CD를 지원하는 올바른 도구를 사용하고 있습니까?
• 애플리케이션의 스테이징 및 프로덕션 환경 구성은 어떻게 관리됩니까?
• 도구 체인에 커뮤니티 지원 및 지원 모델이 있으며 적절한 채널과 문서를 제공합니까?

자주 변경되는 비즈니스 영역 식별(Identify business areas that change frequently)

마이크로서비스 아키텍처는 유연하고 적응력이 뛰어납니다. 평가 중에 동료들이 자주 변경될 것이라고 생각하는 영역을 결정하기 위해 조직에서 토론을 진행하세요. 마이크로서비스를 구축하면 팀이 고객이 요청하는 변경 사항에 신속하게 대응하고 회귀 테스트 노력을 최소화할 수 있습니다. 모놀리식 애플리케이션에서 한 모듈의 변경 사항은 여러 수준의 회귀 테스트를 요구하고 새 버전 릴리스의 민첩성을 저하시킵니다.

다음 요소를 고려하세요.

• 서비스를 독립적으로 배포할 수 있습니까?
• 서비스가 DDD 원칙을 따릅니까?
• 서비스가 SOLID 원칙을 따릅니까?
• 데이터베이스가 서비스에 비공개입니까?
• 지원되는 마이크로서비스 섀시 패턴을 사용하여 서비스를 구축했습니까?

인프라 준비 상태 평가(Assess infrastructure readiness)

마이크로서비스 아키텍처로 전환할 때 인프라 준비 상태는 고려해야 할 중요한 사항입니다. 인프라가 제대로 설정되지 않거나 올바른 서비스 또는 구성 요소가 사용되지 않으면 애플리케이션의 성능, 가용성 및 확장성이 영향을 받습니다. 때로는 모든 권장 방법론 및 절차로 애플리케이션이 생성되지만 인프라가 부적절합니다. 이로 인해 성능 및 유지 관리 문제가 발생합니다.

인프라 준비 상태를 평가할 때 다음 요소를 고려하세요.

• 인프라는 배포된 서비스의 확장성을 보장합니까?
• 인프라는 CI/CD를 통해 자동화할 수 있는 스크립트를 통한 프로비저닝을 지원합니까?
• 배포 인프라는 가용성에 대한 SLA를 제공합니까?
• DR(재해 복구) 계획 및 정기 드릴 일정이 있습니까?
• DR을 위해 데이터가 다른 지역으로 복제됩니까?
• 데이터 백업 계획이 있습니까?
• 배포 옵션이 문서화되어 있습니까?
• 배포 인프라가 모니터링됩니까?
• 배포 인프라는 서비스의 자가 복구를 지원합니까?

릴리스 주기 평가(Assess release cycles)

마이크로서비스는 변화에 적응력이 뛰어나며 애자일 개발을 활용하여 릴리스 주기를 단축하고 고객에게 더 많은 가치를 제공합니다. 릴리스 주기를 평가할 때 다음 요소를 고려하세요.

• 애플리케이션을 얼마나 자주 빌드하고 릴리스하나요?
• 배포 후 릴리스가 얼마나 자주 실패하나요?
• 중단 후 문제를 복구하거나 해결하는 데 얼마나 걸리나요?
• 애플리케이션에 시맨틱 버전 관리를 사용하나요?
• 다양한 환경을 유지 관리하고 동일한 릴리스를 순서대로 전파하나요(예: 먼저 스테이징 후 프로덕션)?
• API에 버전 관리를 사용하나요?
• API에 대한 적절한 버전 관리 지침을 따르고 있나요?
• API 버전을 언제 변경하나요?
• API 버전 관리를 처리하는 접근 방식은 무엇인가요?
  • URI 경로 버전 관리
  • 쿼리 매개변수 버전 관리
  • 콘텐츠 유형 버전 관리
  • 사용자 지정 헤더 버전 관리
• 이벤트 버전 관리를 위한 관행이 마련되어 있나요?

서비스 간 통신 평가(Assess communication across services)

마이크로서비스는 비즈니스 시나리오를 처리하기 위해 프로세스 경계를 넘어 서로 통신하는 자급자족적인 서비스입니다. 안정적이고 신뢰할 수 있는 통신을 얻으려면 적절한 통신 프로토콜을 선택해야 합니다.

다음 요소를 고려하세요.

• API를 최우선으로 취급하는 API 우선 접근 방식을 따르고 있습니까?
• 여러 서비스가 동기 통신 프로토콜을 통해 순차적으로 통신하는 긴 체인 작업이 있습니까?
• 시스템의 어느 곳에서든 비동기 통신을 고려했습니까?
• 메시지 브로커 기술과 해당 기능을 평가했습니까?
• 서비스가 수신하고 처리하는 메시지의 처리량을 이해하고 있습니까?
• 클라이언트-서비스 직접 통신을 사용하고 있습니까?
• 메시지 브로커 수준에서 메시지를 영구적으로 저장해야 합니까?
• 마이크로서비스의 수다스러운 동작을 처리하기 위해 구체화된 뷰 패턴을 사용하고 있습니까?
• 안정적인 통신을 위해 재시도, 회로 차단기, 지수 백오프 및 지터를 구현했습니까? 이를 처리하는 일반적인 방법은 앰배서더 패턴을 사용하는 것입니다.
• 마이크로서비스 간 통신을 용이하게 하기 위해 정의된 도메인 이벤트가 있습니까?

클라이언트에 서비스를 노출하는 방법 평가(Evaluate how services are exposed to clients)

API 게이트웨이는 마이크로서비스 아키텍처의 핵심 구성 요소 중 하나입니다. 클라이언트에 서비스를 직접 노출하면 관리 용이성, 제어 및 신뢰할 수 있는 통신 측면에서 문제가 발생합니다. API 게이트웨이는 프록시 서버 역할을 하며 트래픽을 가로채 백엔드 서비스로 라우팅합니다. IP 주소, 권한 부여, 모의 응답 등으로 트래픽을 필터링해야 하는 경우 서비스를 변경하지 않고 API 게이트웨이 수준에서 수행할 수 있습니다.

다음 요소를 고려하세요.

• 서비스가 클라이언트에서 직접 소비됩니까?
• 모든 서비스의 퍼사드 역할을 하는 API 게이트웨이가 있습니까?
• API 게이트웨이가 할당량 제한, 모의 응답 및 IP 주소 필터링과 같은 정책을 설정할 수 있습니까?
• 모바일 앱, 웹 앱 및 파트너와 같은 다양한 유형의 클라이언트 요구를 해결하기 위해 여러 API 게이트웨이를 사용하고 있습니까?
• API 게이트웨이가 Azure API Management의 개발자 포털과 같이 클라이언트가 서비스를 검색하고 구독할 수 있는 포털을 제공합니까?
• 솔루션이 API 게이트웨이와 함께 L7 로드 밸런싱 또는 웹 애플리케이션 방화벽(WAF) 기능을 제공합니까?

트랜잭션 처리 평가(Assess transaction handling)

분산 트랜잭션은 여러 작업을 단일 작업 단위로 실행하는 것을 용이하게 합니다. 마이크로서비스 아키텍처에서 시스템은 수많은 서비스로 분해됩니다. 단일 비즈니스 사용 사례는 단일 분산 트랜잭션의 일부로 여러 마이크로서비스에서 처리됩니다. 분산 트랜잭션에서 명령은 이벤트가 발생할 때 시작되는 작업입니다. 이벤트는 시스템에서 작업을 트리거합니다. 작업이 성공하면 다른 명령을 트리거하고, 그러면 다른 이벤트를 트리거하는 식으로 트랜잭션이 성공했는지 여부에 따라 모든 트랜잭션이 완료되거나 롤백될 때까지 계속될 수 있습니다.

다음 고려 사항을 고려하세요.

• 시스템에 얼마나 많은 분산 트랜잭션이 있습니까?
• 분산 트랜잭션을 처리하는 접근 방식은 무엇입니까? 오케스트레이션 또는 코레오그래피와 함께 사가 패턴 사용을 평가합니다.
• 여러 서비스에 걸쳐 있는 트랜잭션은 몇 개입니까?
• 데이터 일관성 및 무결성을 달성하기 위해 ACID 또는 BASE 트랜잭션 모델을 따르고 있습니까?
• 여러 서비스에 걸쳐 있는 트랜잭션에 긴 체인 작업을 사용하고 있습니까?

서비스 개발 모델 평가(Assess your service development model)

마이크로서비스 아키텍처의 가장 큰 이점 중 하나는 기술 다양성입니다. 마이크로서비스 기반 시스템을 통해 팀은 선택한 기술을 사용하여 서비스를 개발할 수 있습니다. 기존 애플리케이션 개발에서는 새 구성 요소를 구축할 때 기존 코드를 재사용하거나 개발 노력을 줄이기 위해 내부 개발 프레임워크를 만들 수 있습니다. 여러 기술을 사용하면 코드 재사용을 방지할 수 있습니다.

다음 요소를 고려하세요.

• 새 서비스 개발을 시작하기 위해 서비스 템플릿을 사용합니까?
• 12요소 앱 방법론을 따르고 종속성을 격리하고 구성을 외부화하는 마이크로서비스에 단일 코드베이스를 사용합니까?
• 중요한 구성을 키 저장소에 보관합니까?
• 서비스를 컨테이너화합니까?
• 데이터 일관성 요구 사항을 알고 있습니까?

배포 접근 방식 평가(Assess your deployment approach)

배포 접근 방식은 다양한 배포 환경에서 애플리케이션 버전을 릴리스하는 방법입니다. 마이크로서비스 기반 시스템은 기존 애플리케이션보다 더 빠르게 버전을 릴리스할 수 있는 민첩성을 제공합니다.

배포 계획을 평가할 때 다음 요소를 고려하세요.

• 서비스를 배포하기 위한 전략이 있습니까?
• 서비스를 배포하기 위해 최신 도구 및 기술을 사용하고 있습니까?
• 서비스를 배포할 때 팀 간에 어떤 종류의 협업이 필요합니까?
• IaC(Infrastructure as Code)를 사용하여 인프라를 프로비저닝합니까?
• DevOps 기능을 사용하여 배포를 자동화합니까?
• 12요소 앱 방법론에서 제안하는 대로 여러 환경에 동일한 빌드를 전파합니까?

호스팅 플랫폼 평가(Assess your hosting platform)

확장성은 마이크로서비스 아키텍처의 주요 이점 중 하나입니다. 마이크로서비스는 비즈니스 도메인에 매핑되므로 각 서비스를 독립적으로 확장할 수 있기 때문입니다. 모놀리식 애플리케이션은 호스팅 플랫폼에 단일 단위로 배포되며 전체적으로 확장해야 합니다. 이로 인해 가동 중지 시간, 배포 위험 및 유지 관리 문제가 발생합니다. 모놀리식 애플리케이션은 개별 비즈니스 도메인을 처리하는 구성 요소와 함께 잘 설계될 수 있습니다. 그러나 프로세스 경계가 부족하여 단일 책임 원칙을 위반할 가능성이 더 어려워집니다. 결국 스파게티 코드가 생성됩니다. 애플리케이션이 단일 호스팅 프로세스로 구성되고 배포되기 때문에 확장성이 어렵습니다.

마이크로서비스를 통해 팀은 확장성 요구 사항을 지원하는 올바른 호스팅 플랫폼을 선택할 수 있습니다. 자동 확장, 탄력적 프로비저닝, 고가용성, 빠른 배포 및 쉬운 모니터링과 같은 기능을 제공하여 이러한 문제를 해결할 수 있는 다양한 호스팅 플랫폼을 사용할 수 있습니다.

다음 요소를 고려하세요.

• 서비스를 배포하는 데 어떤 호스팅 플랫폼을 사용합니까(가상 머신, 컨테이너, 서버리스)?
• 호스팅 플랫폼은 확장 가능합니까? 자동 확장을 지원합니까?
• 호스팅 플랫폼을 확장하는 데 얼마나 걸립니까?
• 다양한 호스팅 플랫폼에서 제공하는 SLA를 이해하고 있습니까?
• 호스팅 플랫폼은 재해 복구를 지원합니까?

서비스 모니터링 평가(Assess services monitoring)

모니터링은 마이크로서비스 기반 애플리케이션의 중요한 요소입니다. 애플리케이션이 독립적으로 실행되는 여러 서비스로 나뉘어 있기 때문에 오류 문제 해결이 어려울 수 있습니다. 서비스를 모니터링하기 위해 적절한 의미 체계를 사용하면 팀은 오류를 쉽게 모니터링, 조사 및 대응할 수 있습니다.

다음 요소를 고려하세요.

• 배포된 서비스를 모니터링합니까?
• 로깅 메커니즘이 있습니까? 어떤 도구를 사용합니까?
• 분산 추적 인프라가 마련되어 있습니까?
• 예외를 기록합니까?
• 문제의 빠른 식별을 위해 비즈니스 오류 코드를 유지 관리합니까?
• 서비스에 대한 상태 프로브를 사용합니까?
• 의미 체계 로깅을 사용합니까? 핵심 메트릭, 임계값 및 지표를 구현했습니까?
• 로깅 중에 중요한 데이터를 마스킹합니까?

상관 관계 토큰 할당 평가(Assess correlation token assignment)

마이크로서비스 아키텍처에서 애플리케이션은 다양한 비즈니스 사용 사례를 제공하기 위해 서로 상호 작용하는 독립적으로 호스팅되는 다양한 마이크로서비스로 구성됩니다. 애플리케이션이 작업을 수행하기 위해 백엔드 서비스와 상호 작용할 때 요청에 상관 관계 토큰으로 알려진 고유한 번호를 할당할 수 있습니다. 오류 문제 해결에 도움이 될 수 있으므로 상관 관계 토큰 사용을 고려하는 것이 좋습니다. 이는 문제의 근본 원인을 파악하고 영향을 평가하며 문제를 해결하기 위한 접근 방식을 결정하는 데 도움이 됩니다.

상관 관계 토큰을 사용하여 상관 관계 토큰이 있는 서비스와 없는 서비스를 식별하여 요청 추적을 검색할 수 있습니다. 해당 요청에 대한 상관 관계 토큰이 없는 서비스는 실패했습니다. 오류가 발생하면 나중에 트랜잭션을 다시 시도할 수 있습니다. 멱등성을 적용하기 위해 상관 관계 토큰이 없는 서비스만 요청을 처리합니다.

예를 들어, 많은 서비스를 포함하는 긴 체인 작업이 있는 경우 트랜잭션 중에 서비스 중 하나가 실패하면 상관 관계 토큰을 서비스에 전달하여 문제를 쉽게 조사할 수 있습니다. 각 서비스에는 일반적으로 자체 데이터베이스가 있습니다. 상관 관계 토큰은 데이터베이스 레코드에 보관됩니다. 트랜잭션 재생의 경우 데이터베이스에 특정 상관 관계 토큰이 있는 서비스는 요청을 무시합니다. 토큰이 없는 서비스만 요청을 처리합니다.

다음 요소를 고려하세요.

• 어느 단계에서 상관 관계 토큰을 할당합니까?
• 어떤 구성 요소가 상관 관계 토큰을 할당합니까?
• 서비스의 데이터베이스에 상관 관계 토큰을 저장합니까?
• 상관 관계 토큰의 형식은 무엇입니까?
• 상관 관계 토큰 및 기타 요청 정보를 기록합니까?

마이크로서비스 섀시 프레임워크의 필요성 평가(Evaluate the need for a microservices chassis framework)

마이크로서비스 섀시 프레임워크는 로깅, 예외 처리, 분산 추적, 보안 및 통신과 같은 공통 관심사에 대한 기능을 제공하는 기본 프레임워크입니다. 섀시 프레임워크를 사용하면 인프라 기능과 상호 작용하는 것보다 서비스 경계를 구현하는 데 더 집중할 수 있습니다.

예를 들어 장바구니 관리 서비스를 구축한다고 가정해 보겠습니다. 들어오는 토큰의 유효성을 검사하고 로깅 데이터베이스에 로그를 작성하며 해당 서비스의 엔드포인트를 호출하여 다른 서비스와 통신하려고 합니다. 마이크로서비스 섀시 프레임워크를 사용하면 개발 노력을 줄일 수 있습니다. Dapr은 교차 관심사를 구현하기 위한 다양한 빌딩 블록을 제공하는 시스템 중 하나입니다.

다음 요소를 고려하세요.

• 마이크로서비스 섀시 프레임워크를 사용합니까?
• Dapr을 사용하여 교차 관심사와 상호 작용합니까?
• 섀시 프레임워크는 언어에 구애받지 않습니까?
• 섀시 프레임워크는 모든 종류의 애플리케이션을 지원할 수 있도록 일반적입니까? 섀시 프레임워크에는 애플리케이션별 논리가 포함되어서는 안 됩니다.
• 섀시 프레임워크는 선택한 구성 요소 또는 서비스를 필요에 따라 사용할 수 있는 메커니즘을 제공합니까?

애플리케이션 테스트 접근 방식 평가(Assess your approach to application testing)

전통적으로 테스트는 개발이 완료되고 애플리케이션이 사용자 승인 테스트(UAT) 및 프로덕션 환경에 배포될 준비가 된 후에 수행됩니다. 현재 이 접근 방식에 변화가 있어 애플리케이션 개발 수명 주기에서 테스트를 조기(왼쪽)로 이동하고 있습니다. Shift-left 테스트는 설계, 개발 및 개발 후 단계를 포함하여 애플리케이션 개발 수명 주기의 각 단계에서 테스트가 수행되므로 애플리케이션의 품질을 향상시킵니다.

예를 들어 애플리케이션을 구축할 때 아키텍처를 설계하는 것으로 시작합니다. shift-left 접근 방식을 사용하면 Microsoft 위협 모델링과 같은 도구를 사용하여 취약점에 대한 설계를 테스트합니다. 개발을 시작하면 SAST(정적 애플리케이션 보안 테스트)와 같은 도구를 실행하고 다른 분석기를 사용하여 문제를 발견하여 소스 코드를 스캔할 수 있습니다. 애플리케이션을 배포한 후 DAST(동적 애플리케이션 보안 테스트)와 같은 도구를 사용하여 호스팅되는 동안 테스트할 수 있습니다. 기능 테스트, 혼돈 테스트, 침투 테스트 및 기타 종류의 테스트는 나중에 수행됩니다.

다음 요소를 고려하세요.

• 전체 개발 수명 주기를 다루는 테스트 계획을 작성합니까?
• 요구 사항 회의 및 전체 애플리케이션 개발 수명 주기에 테스터를 포함합니까?
• 테스트 주도 설계 또는 동작 주도 설계를 사용합니까?
• 사용자 스토리를 테스트합니까? 사용자 스토리에 수락 기준을 포함합니까?
• Microsoft 위협 모델링과 같은 도구를 사용하여 설계를 테스트합니까?
• 단위 테스트를 작성합니까?
• 코드 품질을 측정하기 위해 정적 코드 분석기 또는 기타 도구를 사용합니까?
• 애플리케이션을 테스트하기 위해 자동화된 도구를 사용합니까?
• 보안 DevOps 방식을 구현합니까?
• 통합 테스트, 엔드 투 엔드 애플리케이션 테스트, 로드/성능 테스트, 침투 테스트 및 혼돈 테스트를 수행합니까?

마이크로서비스 보안 평가(Assess microservices security)

서비스 보호, 보안 액세스 및 보안 통신은 마이크로서비스 아키텍처에서 가장 중요한 고려 사항 중 하나입니다. 예를 들어 여러 서비스에 걸쳐 있고 각 서비스에 토큰 유효성 검사를 사용하는 마이크로서비스 기반 시스템은 실행 가능한 솔루션이 아닙니다. 이 시스템은 전체 시스템의 민첩성과 서비스 간 구현 드리프트를 발생시킬 가능성에 영향을 미칩니다.

보안 문제는 일반적으로 API 게이트웨이 및 애플리케이션 방화벽에서 처리됩니다. 게이트웨이 및 방화벽은 들어오는 요청을 받고 토큰의 유효성을 검사하며 트래픽을 가로채기 위해 OWASP 상위 10개 원칙을 구현하는 것과 같은 다양한 필터 및 정책을 적용합니다. 마지막으로 백엔드 마이크로서비스에 요청을 보냅니다. 이 구성은 개발자가 보안이라는 교차 관심사보다 비즈니스 요구 사항에 집중하는 데 도움이 됩니다.

다음 요소를 고려하세요.

• 서비스에 인증 및 권한 부여가 필요합니까?
• API 게이트웨이를 사용하여 토큰 및 들어오는 요청의 유효성을 검사합니까?
• 서비스 통신에 대한 보안을 제공하기 위해 SSL 또는 mTLS를 사용합니까?
• 서비스 간 필요한 통신을 허용하기 위한 네트워크 보안 정책이 마련되어 있습니까?
• 내부 및 외부 통신에 대한 보안을 제공하기 위해 해당되는 경우 방화벽(L4, L7)을 사용합니까?
• API 게이트웨이에서 보안 정책을 사용하여 트래픽을 제어합니까?

출처 : https://learn.microsoft.com/en-us/azure/architecture/guide/technology-choices/microservices-assessment