마이크로 서비스 평가 및 준비 상태
마이크로 서비스 아키텍처는 민첩성, 확장성 및 고가용성을 포함하여 많은 이점을 애플리케이션에 제공할 수 있습니다. 이러한 이점과 함께 이 아키텍처는 도전 과제를 제시합니다. 마이크로 서비스 기반 애플리케이션을 구축하거나 기존 애플리케이션을 마이크로 서비스 아키텍처로 변환하는 경우 현재 상황을 분석하고 평가하여 개선할 필요가 있는 영역을 식별해야 합니다.
이 가이드는 마이크로 서비스 아키텍처로 이동할 때 명심해야 할 몇 가지 고려 사항을 이해하는 데 도움이 됩니다. 이 가이드를 사용하여 애플리케이션, 인프라, DevOps, 개발 모델 등의 완성도를 평가할 수 있습니다.
비즈니스 우선 순위 이해
마이크로 서비스 아키텍처 평가를 시작하려면 먼저 비즈니스의 핵심 우선 순위를 이해해야 합니다. 예를 들어 핵심 우선 순위는 민첩성, 변경 채택 또는 빠른 개발과 관련이 있을 수 있습니다. 아키텍처가 핵심 우선 순위에 적합한지를 분석해야 합니다. 시간이 지남에 따라 비즈니스 우선 순위가 변경될 수 있습니다. 예를 들어 혁신은 스타트업의 최우선 과제이지만, 몇 년 후에는 핵심 우선 순위가 안정성과 효율성이 될 수 있습니다.
고려해야 할 몇 가지 우선 순위는 다음과 같습니다.
- 혁신
- 안정성
- 효율성
평가 가이드로 사용할 수 있는 조직의 약속을 보장하기 위해 애플리케이션의 다양한 부분에 맞춰진 SLA를 문서화합니다.
아키텍처 결정 기록
마이크로 서비스 아키텍처는 팀이 자율적 상태가 되는 데 도움이 됩니다. 예를 들어 팀에서 기술, 방법론 및 인프라 구성 요소에 대해 자체적으로 결정할 수 있습니다. 그러나 이러한 선택은 공유 거버넌스라고 하는 공식적으로 합의된 원칙을 따라야 합니다. 이러한 원칙은 마이크로 서비스에 대한 광범위한 전략을 처리하는 방법에 대한 팀 간의 합의를 나타냅니다.
다음 항목을 고려합니다.
- 공유 거버넌스가 갖추어져 있나요?
- 아키텍처 저널에서 의사 결정 및 그 절충점을 추적하나요?
- 팀에서 아키텍처 저널에 쉽게 액세스할 수 있나요?
- 도구, 기술 및 프레임워크를 평가하는 프로세스가 있나요?
팀 구성 평가
팀 간의 불필요한 통신을 방지할 수 있는 적절한 팀 구조가 있어야 합니다. 마이크로 서비스 아키텍처는 작고 집중적인 복합 기능 팀을 구성하도록 장려하며, 팀 구조 조정을 선행해야 하는 사고 방식의 변화가 필요합니다.
다음 항목을 고려합니다.
- 팀이 DDD(도메인 기반 설계) 원칙에 따라 하위 도메인을 기준으로 분할되나요?
- 관련 마이크로 서비스를 독립적으로 구축하고 운영할 수 있는 충분한 능력을 갖춘 복합 기능 팀인가요?
- 프로젝트와 관련이 없는 임시 활동 및 작업에 얼마나 많은 시간이 걸리나요?
- 팀 간 협업에 얼마나 많은 시간이 걸리나요?
- 기술적인 문제를 식별하고 최소화하는 프로세스가 있나요?
- 팀 간에 학습된 교훈과 경험은 어떻게 전달되나요?
12단계 방법론 사용
마이크로 서비스 아키텍처를 선택하는 기본 목표는 민첩한 사례를 따라 가치를 더 빠르게 제공하고 변화에 적응하는 것입니다. 12단계 앱 방법론은 유지 관리 및 확장 가능한 애플리케이션을 구축하기 위한 지침을 제공합니다. 이러한 지침은 불변성, 임시성, 선언적 구성 및 자동화와 같은 특성을 권장합니다. 이러한 지침을 통합하고 일반적인 문제를 방지하면 느슨하게 결합된 자체 포함 마이크로 서비스를 만들 수 있습니다.
분해 방법 이해
모놀리식 애플리케이션을 마이크로 서비스 아키텍처로 변환하는 데는 시간이 걸립니다. 에지 서비스로 시작합니다. 에지 서비스는 다른 서비스에 대한 종속성이 적고 시스템에서 독립 서비스로 쉽게 분해할 수 있습니다. 모든 서비스가 별도의 마이크로 서비스로 분해될 때까지 모놀리식 애플리케이션을 작동 상태로 유지하려면 스트랭글러 그림 및 손상 방지 계층과 같은 패턴을 사용하는 것이 좋습니다. 분리하는 동안 DDD 원칙은 팀에서 하위 도메인을 기반으로 하는 모놀리식 애플리케이션에서 구성 요소 또는 서비스를 선택하는 데 도움이 될 수 있습니다.
예를 들어 전자 상거래 시스템에는 카트, 제품 관리, 주문 관리, 가격 책정, 청구서 생성 및 알림과 같은 모듈이 있을 수 있습니다. 다른 모듈에 대한 종속성이 없으므로 알림 모듈을 사용하여 애플리케이션 변환을 시작하도록 결정합니다. 그러나 다른 모듈에서는 이 모듈을 통해 알림을 보낼 수 있습니다. 알림 모듈은 별도의 마이크로 서비스로 쉽게 분해할 수 있지만, 새 알림 서비스를 호출하려면 모놀리식 애플리케이션에서 일부를 변경해야 합니다. 다음으로 청구서 생성 모듈을 변환하도록 결정합니다. 주문이 생성되면 이 모듈이 호출됩니다. 스트랭글러 및 손상 방지와 같은 패턴을 사용하여 이 변환을 지원할 수 있습니다.
데이터 동기화, 모놀리식 및 마이크로 서비스 인터페이스 모두에 대한 다중 쓰기, 데이터 소유권, 스키마 분해, 조인, 데이터 볼륨 및 데이터 무결성으로 인해 데이터 분석 및 마이그레이션이 어려울 수 있습니다. 마이크로 서비스 간 공유 데이터베이스 유지, 비즈니스 기능 또는 도메인에 따라 서비스 그룹에서 데이터베이스 분리 및 서비스에서 데이터베이스 격리와 같이 사용할 수 있는 몇 가지 기술이 있습니다. 권장되는 솔루션은 각 서비스를 사용하여 각 데이터베이스를 분해하는 것입니다. 많은 상황에서 이 솔루션은 실용적이지 않습니다. 이러한 경우 데이터베이스 보기 패턴 및 데이터베이스 래핑 서비스 패턴과 같은 패턴을 사용할 수 있습니다.
DevOps 준비 상태 평가
마이크로 서비스 아키텍처로 이동하는 경우 DevOps 역량을 평가하는 것이 중요합니다. 마이크로 서비스 아키텍처는 조직의 민첩성을 높이기 위해 애플리케이션에서 민첩한 개발을 용이하게 하기 위한 것입니다. DevOps는 이 역량을 달성하기 위해 구현해야 하는 주요 사례 중 하나입니다.
마이크로 서비스 아키텍처에 대한 DevOps 기능을 평가하는 경우 다음 사항에 유의하세요.
- 조직의 사용자가 DevOps의 기본 사례와 원칙을 알고 있나요?
- 팀에서 원본 제어 도구와 CI/CD 파이프라인과의 통합을 이해하고 있나요?
- DevOps 사례를 제대로 구현하나요?
- 민첩한 사례를 따르나요?
- 연속 통합이 구현되나요?
- 지속적인 업데이트가 구현되나요?
- 지속적인 배포가 구현되나요?
- 연속 모니터링이 구현되나요?
- IaC(Infrastructure as Code)가 갖추어져 있나요?
- CI/CD를 지원하는 데 적합한 도구를 사용하고 있나요?
- 애플리케이션에 대한 준비 및 프로덕션 환경 구성은 어떻게 관리되나요?
- 도구 체인에 커뮤니티 지원 및 지원 모델이 있으며 적절한 채널과 문서를 제공하나요?
자주 변경되는 비즈니스 영역 식별
마이크로 서비스 아키텍처는 유연하고 적응성이 뛰어납니다. 평가 중에 동료들이 조직에서 토론을 주도하여 자주 변경될 것이라고 생각하는 영역을 결정합니다. 마이크로 서비스를 구축하면 팀에서 고객이 요청하는 변경에 빠르게 대응하고 회귀 테스트 작업을 최소화할 수 있습니다. 모놀리식 애플리케이션에서 한 모듈을 변경하는 경우 다양한 수준의 회귀 테스트가 필요하고 새 버전을 릴리스할 때 민첩성이 줄어듭니다.
다음 항목을 고려합니다.
- 서비스를 독립적으로 배포할 수 있나요?
- 서비스에서 DDD 원칙을 따르나요?
- 서비스에서 SOLID 원칙을 따르나요?
- 데이터베이스가 서비스 전용인가요?
- 지원되는 마이크로 서비스 섀시 패턴을 사용하여 서비스를 구축했나요?
인프라 준비 상태 평가
마이크로 서비스 아키텍처로 전환하는 경우 인프라 준비는 고려해야 할 중요한 사항입니다. 인프라가 제대로 설정되지 않았거나 올바른 서비스 또는 구성 요소가 사용되지 않으면 애플리케이션의 성능, 가용성 및 확장성에 영향을 줍니다. 제안된 모든 방법론과 절차를 사용하여 애플리케이션을 만드는 경우도 있지만 인프라가 적절하지 않습니다. 이로 인해 성능과 유지 관리가 저하됩니다.
인프라 준비 상태를 평가하는 경우 다음 요소를 고려합니다.
- 인프라에서 배포된 서비스의 확장성을 보장하나요?
- 인프라에서 CI/CD를 통해 자동화할 수 있는 스크립트를 통한 프로비전을 지원하나요?
- 배포 인프라에서 가용성 SLA를 제공하나요?
- DR(재해 복구) 계획과 일상적인 훈련 일정이 있나요?
- DR을 위해 데이터가 다른 지역에 복제되나요?
- 데이터 백업 계획이 있나요?
- 배포 옵션이 문서화되어 있나요?
- 배포 인프라가 모니터링되나요?
- 배포 인프라에서 서비스의 자동 복구를 지원하나요?
릴리스 주기 평가
마이크로 서비스는 변화에 적응하고 민첩한 개발을 활용하여 릴리스 주기를 단축하고 고객에게 더 많은 가치를 제공합니다. 릴리스 주기를 평가하는 경우 다음 요소를 고려합니다.
- 애플리케이션을 얼마나 자주 빌드하고 릴리스하나요?
- 배포 후 릴리스가 얼마나 자주 실패하나요?
- 중단 후 문제를 복구하거나 수정하는 데 얼마나 걸리나요?
- 의미 체계 버전 관리를 애플리케이션에 사용하나요?
- 다른 환경을 유지 관리하고 동일한 릴리스를 순서대로 전파하나요(예: 먼저 준비에, 다음으로 프로덕션에 전파)?
- 버전 관리를 API에 사용하나요?
- API에 대한 적절한 버전 관리 지침을 따르나요?
- API 버전을 언제 변경하나요?
- API 버전 관리를 처리하는 방법은 무엇인가요?
- URI 경로 버전 관리
- 쿼리 매개 변수 버전 관리
- 콘텐츠 형식 버전 관리
- 사용자 지정 헤더 버전 관리
- 이벤트 버전 관리에 적합한 사례가 있나요?
서비스 간 통신 평가
마이크로 서비스는 비즈니스 시나리오를 처리하기 위해 프로세스 경계를 넘어 서로 통신하는 자체 포함 서비스입니다. 안정적이고 신뢰할 수 있는 통신을 달성하려면 적절한 통신 프로토콜을 선택해야 합니다.
다음 요소를 고려합니다.
- API에서 일류 시민으로 취급되는 API 우선 접근 방식을 따르고 있나요?
- 여러 서비스에서 동기 통신 프로토콜을 통해 순서대로 통신하는 긴 체인 작업이 있나요?
- 비동기 통신을 시스템의 어딘가에 고려한 적이 있나요?
- 메시지 broker 기술과 해당 기능을 평가했나요?
- 서비스에서 받고 처리하는 메시지의 처리량을 이해하고 있나요?
- 직접 클라이언트-서비스 통신을 사용하나요?
- 메시지를 메시지 broker 수준에서 유지해야 하나요?
- 구체화된 뷰 패턴을 사용하여 마이크로 서비스의 수다스러운 동작을 처리하고 있나요?
- 안정적인 통신을 위해 다시 시도, 회로 차단기, 지수 백오프 및 지터를 구현했나요? 이를 처리하는 일반적인 방법은 특사 패턴을 사용하는 것입니다.
- 마이크로 서비스 간의 통신을 용이하게 하기 위해 도메인 이벤트를 정의했나요?
서비스가 클라이언트에 공개되는 방법 평가
API 게이트웨이는 마이크로 서비스 아키텍처의 핵심 구성 요소 중 하나입니다. 서비스를 클라이언트에 직접 공개하면 관리 효율성, 제어 및 신뢰할 수 있는 통신 측면에서 문제가 발생합니다. API 게이트웨이는 트래픽을 가로채 백 엔드 서비스로 라우팅하는 프록시 서버 역할을 합니다. IP 주소, 권한 부여, 모의 응답 등을 기준으로 트래픽을 필터링해야 하는 경우 서비스를 변경하지 않고 API 게이트웨이 수준에서 수행할 수 있습니다.
다음 요소를 고려합니다.
- 클라이언트에서 직접 서비스를 사용하나요?
- 모든 서비스에 대한 외관 역할을 하는 API 게이트웨이가 있나요?
- API 게이트웨이가 할당량 제한, 모의 응답 및 IP 주소 필터링과 같은 정책을 설정할 수 있나요?
- 여러 API 게이트웨이를 사용하여 모바일 앱, 웹앱 및 파트너와 같은 다양한 유형의 클라이언트 요구 사항을 처리하고 있나요?
- API 게이트웨이가 Azure API Management의 개발자 포털과 같이 클라이언트에서 서비스를 검색하고 구독할 수 있는 포털을 제공하나요?
- 솔루션에서 API 게이트웨이와 함께 L7 부하 분산 또는 WAF(웹 애플리케이션 방화벽) 기능을 제공하나요?
트랜잭션 처리 평가
분산 트랜잭션을 사용하면 여러 작업을 단일 작업 단위로 쉽게 실행할 수 있습니다. 마이크로 서비스 아키텍처에서 시스템은 다양한 서비스로 분해됩니다. 단일 비즈니스 사용 사례는 여러 마이크로 서비스에서 단일 분산 트랜잭션의 일부로 처리됩니다. 분산 트랜잭션에서 명령은 이벤트가 발생할 때 시작되는 작업입니다. 이 이벤트는 시스템에서 작업을 트리거합니다. 작업이 성공하면 트랜잭션의 성공 여부에 따라 모든 트랜잭션이 완료되거나 롤백될 때까지 다른 명령을 트리거할 수 있는 다른 명령을 트리거할 수 있습니다.
다음 사항을 고려합니다.
- 시스템에 얼마나 많은 분산 트랜잭션이 있나요?
- 분산 트랜잭션을 처리하는 방법은 무엇인가요? 오케스트레이션 또는 연출 구성을 통해 Saga 패턴의 사용을 평가합니다.
- 얼마나 많은 트랜잭션이 여러 서비스에 걸쳐 있나요?
- 데이터 일관성 및 무결성을 달성하기 위해 ACID 또는 BASE 트랜잭션 모델을 따르고 있나요?
- 긴 연결 작업을 여러 서비스에 걸쳐 있는 트랜잭션에 사용하고 있나요?
서비스 개발 모델 평가
마이크로 서비스 아키텍처의 가장 큰 이점 중 하나는 기술 다양성입니다. 마이크로 서비스 기반 시스템을 사용하면 팀에서 선택한 기술을 사용하여 서비스를 개발할 수 있습니다. 기존 애플리케이션 개발에서는 새 구성 요소를 빌드할 때 기존 코드를 다시 사용하거나, 내부 개발 프레임워크를 만들어 개발 작업을 줄일 수 있습니다. 여러 기술을 사용하면 코드 재사용을 방지할 수 있습니다.
다음 항목을 고려합니다.
- 서비스 템플릿을 사용하여 새 서비스 개발을 시작하나요?
- 12단계 앱 방법론을 따르고 마이크로 서비스에 단일 코드베이스를 사용하여 종속성을 격리하고 구성을 외부화하나요?
- 중요한 구성을 키 자격 증명 모음에서 유지하나요?
- 서비스를 컨테이너화하나요?
- 데이터 일관성 요구 사항을 알고 있나요?
배포 방법 평가
배포 방법은 다양한 배포 환경에서 애플리케이션 버전을 릴리스하는 방법입니다. 마이크로 서비스 기반 시스템은 기존 애플리케이션보다 더 빠르게 버전을 릴리스할 수 있는 민첩성을 제공합니다.
배포 계획을 평가하는 경우 다음 요소를 고려합니다.
- 서비스를 배포하기 위한 전략이 있나요?
- 최신 도구와 기술을 사용하여 서비스를 배포하고 있나요?
- 서비스를 배포할 때 팀 간에 어떤 종류의 협업이 필요하나요?
- IaC(Infrastructure as Code)를 사용하여 인프라를 프로비전하나요?
- DevOps 기능을 사용하여 배포를 자동화하나요?
- 12단계 앱 방법론에서 제안한 대로 동일한 빌드를 여러 환경에 전파하나요?
호스팅 플랫폼 평가
확장성은 마이크로 서비스 아키텍처의 주요 이점 중 하나입니다. 마이크로 서비스가 비즈니스 도메인에 매핑되어 각 서비스의 크기를 독립적으로 조정할 수 있기 때문입니다. 모놀리식 애플리케이션은 호스팅 플랫폼에서 단일 단위로 배포되며 전체적으로 크기 조정해야 합니다. 이로 인해 가동 중지 시간, 배포 위험 및 유지 관리가 발생합니다. 모놀리식 애플리케이션은 개별 비즈니스 도메인을 처리하는 구성 요소를 사용하여 잘 설계될 수 있습니다. 그러나 프로세스 경계가 없으므로 단일 책임 원칙을 위반할 가능성이 더 어려워집니다. 이로 인해 결국에는 스파게티 코드가 생성됩니다. 애플리케이션이 단일 호스팅 프로세스로 구성되고 배포되므로 확장성이 어렵습니다.
마이크로 서비스를 사용하면 팀에서 확장성 요구 사항을 지원하는 데 적합한 호스팅 플랫폼을 선택할 수 있습니다. 자동 크기 조정, 탄력적 프로비전, 고가용성, 더 빠른 배포 및 간편한 모니터링과 같은 기능을 제공하여 이러한 문제를 해결하는 데 다양한 호스팅 플랫폼을 사용할 수 있습니다.
다음 항목을 고려합니다.
- 서비스(가상 머신, 컨테이너, 서버리스)를 배포하는 데 사용하는 호스팅 플랫폼은 무엇인가요?
- 호스팅 플랫폼의 크기를 조정할 수 있나요? 자동 크기 조정을 지원하나요?
- 호스팅 플랫폼의 크기를 조정하는 데 얼마나 걸리나요?
- 다양한 호스팅 플랫폼에서 제공하는 SLA를 이해하고 있나요?
- 호스팅 플랫폼에서 재해 복구를 지원하나요?
서비스 모니터링 평가
모니터링은 마이크로 서비스 기반 애플리케이션의 중요한 요소입니다. 애플리케이션이 독립적으로 실행되는 여러 서비스로 나뉘므로 오류 문제 해결이 어려울 수 있습니다. 적절한 의미 체계를 사용하여 서비스를 모니터링하면 팀에서 오류를 쉽게 모니터링, 조사 및 대응할 수 있습니다.
다음 항목을 고려합니다.
- 배포된 서비스를 모니터링하나요?
- 로깅 메커니즘이 있나요? 어떤 도구를 사용하나요?
- 분산 추적 인프라가 갖추어져 있나요?
- 예외를 기록하나요?
- 문제를 빠르게 식별하기 위해 비즈니스 오류 코드를 유지 관리하나요?
- 상태 프로브를 서비스에 사용하나요?
- 의미 체계 로깅을 사용하나요? 주요 메트릭, 임계값 및 지표를 구현했나요?
- 로깅하는 동안 중요한 데이터를 마스킹하나요?
상관 관계 토큰 할당 평가
마이크로 서비스 아키텍처에서 애플리케이션은 독립적으로 호스트되는 다양한 마이크로 서비스로 구성되며, 서로 상호 작용하여 다양한 비즈니스 사용 사례를 제공합니다. 애플리케이션에서 백 엔드 서비스와 상호 작용하여 작업을 수행하는 경우 상관 관계 토큰이라고 하는 고유 번호를 요청에 할당할 수 있습니다. 상관 관계 토큰은 오류 문제를 해결하는 데 도움이 될 수 있으므로 사용하는 것이 좋습니다. 문제의 근본 원인을 파악하고, 영향을 평가하고, 문제를 해결하는 방법을 결정하는 데 도움이 됩니다.
상관 관계 토큰을 사용하여 상관 관계 토큰이 포함된 서비스와 그렇지 않은 서비스를 식별하여 요청 내역을 검색할 수 있습니다. 해당 요청에 대한 상관 관계 토큰이 없는 서비스는 실패했습니다. 실패가 발생하면 나중에 트랜잭션을 다시 시도할 수 있습니다. 멱등성을 적용하기 위해 상관 관계 토큰이 없는 서비스만 요청을 처리합니다.
예를 들어 많은 서비스를 포함한 긴 작업 체인이 있는 경우 상관 관계 토큰을 서비스에 전달하면 트랜잭션 중에 서비스가 실패하는 경우 문제를 쉽게 조사할 수 있습니다. 각 서비스에는 일반적으로 자체 데이터베이스가 있습니다. 상관 관계 토큰은 데이터베이스 레코드에 유지됩니다. 트랜잭션 재생의 경우 특정 상관 관계 토큰이 데이터베이스에 있는 서비스는 요청을 무시합니다. 토큰이 없는 서비스만 요청을 처리합니다.
다음 항목을 고려합니다.
- 어떤 단계에서 상관 관계 토큰을 할당하나요?
- 어떤 구성 요소에서 상관 관계 토큰을 할당하나요?
- 상관 관계 토큰을 서비스의 데이터베이스에 저장하나요?
- 상관 관계 토큰의 형식은 무엇인가요?
- 상관 관계 토큰 및 기타 요청 정보를 기록하나요?
마이크로 서비스 섀시 프레임워크에 대한 요구 사항 평가
마이크로 서비스 섀시 프레임워크는 로깅, 예외 처리, 분산 추적, 보안 및 통신과 같은 교차 절단 문제에 대한 기능을 제공하는 기본 프레임워크입니다. 섀시 프레임워크를 사용하는 경우 인프라 기능과 상호 작용하는 것보다 서비스 경계를 구현하는 데 더 집중합니다.
예를 들어 카트 관리 서비스를 구축한다고 가정해 보겠습니다. 들어오는 토큰의 유효성을 검사하고, 로그를 로깅 데이터베이스에 쓰고, 해당 서비스의 엔드포인트를 호출하여 다른 서비스와 통신하려고 합니다. 마이크로 서비스 섀시 프레임워크를 사용하면 개발 작업을 줄일 수 있습니다. Dapr은 교차 절단 문제를 구현하기 위한 다양한 구성 요소를 제공하는 하나의 시스템입니다.
다음 항목을 고려합니다.
- 마이크로 서비스 섀시 프레임워크를 사용하나요?
- Dapr을 사용하여 교차 절단 문제와 상호 작용하나요?
- 섀시 프레임워크 언어가 독립적인가요?
- 섀시 프레임워크가 일반적이므로 모든 종류의 애플리케이션을 지원하나요? 섀시 프레임워크에는 애플리케이션별 논리가 포함되지 않아야 합니다.
- 섀시 프레임워크에서 필요에 따라 선택한 구성 요소 또는 서비스를 사용하는 메커니즘을 제공하나요?
애플리케이션을 테스트하는 방법 평가
일반적으로 개발이 완료되면 테스트가 수행되며 애플리케이션이 UAT(사용자 승인 테스트) 및 프로덕션 환경에 롤아웃할 준비가 됩니다. 현재 이 방법은 테스트를 애플리케이션 개발 수명 주기의 초기(왼쪽)로 이동하도록 변하고 있습니다. 설계, 개발 및 개발 후 단계를 포함하여 애플리케이션 개발 수명 주기의 각 단계에서 테스트가 수행되므로 왼쪽 시프트 테스트는 애플리케이션의 품질을 향상시킵니다.
예를 들어 애플리케이션을 빌드하는 경우 아키텍처를 설계하는 것으로 시작합니다. 왼쪽 시프트 방법을 사용하는 경우 Microsoft 위협 모델링과 같은 도구를 사용하여 취약성에 대한 설계를 테스트합니다. 개발을 시작할 때 SAST(정적 애플리케이션 보안 테스트)와 같은 도구를 실행하고 다른 분석기를 통해 문제를 파악하여 소스 코드를 검사할 수 있습니다. 애플리케이션이 배포되면 DAST(동적 애플리케이션 보안 테스트)와 같은 도구를 사용하여 호스트되는 동안 테스트할 수 있습니다. 기능 테스트, 카오스 테스팅, 침투 테스트 및 기타 종류의 테스트는 나중에 수행됩니다.
다음 항목을 고려합니다.
- 전체 개발 수명 주기를 포함하는 테스트 계획을 작성하나요?
- 테스터를 요구 사항 모임 및 전체 애플리케이션 개발 수명 주기에 포함하나요?
- 테스트 기반 설계 또는 동작 기반 설계를 사용하나요?
- 사용자 사례를 테스트하나요? 수용 기준을 사용자 사례에 포함하나요?
- Microsoft 위협 모델링과 같은 도구를 사용하여 설계를 테스트하나요?
- 단위 테스트를 작성하나요?
- 정적 코드 분석기 또는 기타 도구를 사용하여 코드 품질을 측정하나요?
- 자동화된 도구를 사용하여 애플리케이션을 테스트하나요?
- 보안 DevOps 사례를 구현하나요?
- 통합 테스트, 엔드투엔드 애플리케이션 테스트, 부하/성능 테스트, 침투 테스트 및 카오스 테스팅을 수행하나요?
마이크로 서비스 보안 평가
서비스 보호, 보안 액세스 및 보안 통신은 마이크로 서비스 아키텍처에서 가장 중요한 고려 사항 중 하나입니다. 예를 들어 여러 서비스에 걸쳐 있고 토큰 유효성 검사를 각 서비스에 사용하는 마이크로 서비스 기반 시스템은 실행 가능한 솔루션이 아닙니다. 이 시스템은 전체 시스템의 민첩성과 서비스 간에 구현 드리프트를 도입할 가능성에 영향을 줍니다.
보안 문제는 일반적으로 API 게이트웨이와 애플리케이션 방화벽에서 처리됩니다. 게이트웨이와 방화벽은 들어오는 요청을 받고, 토큰의 유효성을 검사하며, 트래픽을 가로채는 OWASP 상위 10개 원칙 구현과 같은 다양한 필터 및 정책을 적용합니다. 마지막으로 요청을 백 엔드 마이크로 서비스에 보냅니다. 이 구성을 통해 개발자가 보안의 교차 절단 문제가 아니라 비즈니스 요구 사항에 집중할 수 있습니다.
다음 항목을 고려합니다.
- 서비스에 인증 및 권한 부여가 필요하나요?
- API 게이트웨이를 사용하여 토큰 및 들어오는 요청의 유효성을 검사하나요?
- SSL 또는 mTLS를 사용하여 서비스 통신에 대한 보안을 제공하나요?
- 서비스 간에 필요한 통신을 허용하는 네트워크 보안 정책이 있나요?
- 해당하는 경우 방화벽(L4, L7)을 사용하여 내부 및 외부 통신에 대한 보안을 제공하나요?
- API 게이트웨이에서 보안 정책을 사용하여 트래픽을 제어하나요?
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
주요 작성자:
- Ovais Mehboob Ahmed Khan | 선임 클라우드 솔루션 설계자 - 엔지니어링
- 나빌 시디키 | 클라우드 솔루션 설계자 - 디지털 및 애플리케이션 혁신
비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.