microservices-patterns
검증된 패턴으로 마이크로서비스 아키텍처 설계하기
마이크로서비스로 분산 시스템을 구축하면 서비스 경계, 서비스 간 통신, 장애 허용성 측면에서 복잡성이 증가합니다. 이 스킬은 서비스 분해, 이벤트 주도 아키텍처, 사가 조정, 서킷 브레이커 구현을 위한 실전 검증된 패턴을 제공하여 탄력적이고 확장 가능한 시스템을 구축할 수 있도록 도와줍니다.
스킬 ZIP 다운로드
Claude에서 업로드
설정 → 기능 → 스킬 → 스킬 업로드로 이동
토글을 켜고 사용 시작
테스트해 보기
"microservices-patterns" 사용 중입니다. 이커머스 플랫폼을 마이크로서비스로 어떻게 분해해야 하나요?
예상 결과:
- 이커머스 플랫폼의 경우, 비즈니스 역량을 중심으로 서비스를 구성하는 것을 권장합니다:
- 1. **Order Service** - 주문 라이프사이클, 장바구니, 주문 이력 관리
- 2. **Payment Service** - 결제 처리, 환불, 결제 수단 처리
- 3. **Inventory Service** - 제품 재고, 예약, 창고 위치 추적
- 4. **Catalog Service** - 제품 목록, 검색, 카테고리 관리
- 5. **User Service** - 인증, 프로필, 선호도
- 6. **Shipping Service** - 배송 추적, 라벨 생성, 배송업체 연동
- 각 서비스는 자체 데이터베이스를 소유하며 잘 정의된 API 또는 이벤트를 통해 통신합니다. Order Service는 OrderCreated 이벤트를 발행하고 Payment와 Inventory 서비스가 이를 구독하여 각자의 작업을 비동기적으로 처리합니다.
"microservices-patterns" 사용 중입니다. 주문 처리 사가에서 결제 실패를 어떻게 처리하나요?
예상 결과:
- OrderFulfillmentSaga에서 결제 단계가 실패하면 사가 조정자가 역순으로 보상 작업을 트리거합니다:
- 1. 결제 실패 - 결제에 대한 보상 작업 불필요
- 2. 재고 보상: InventoryService.release(reservation_id)를 호출하여 예약 해제
- 3. 주문 보상: OrderService.cancel(order_id)를 호출하여 주문 취소
- 4. 오류 세부 정보와 함께 실패 결과를 클라이언트에 반환
- 핵심은 각 보상 작업을 멱등성 있게 설계하고 보상 자체가 부분적으로 실패할 수 있는 경우를 처리하는 것입니다. 모든 보상 작업을 로그에 기록하고 필요시 수동 개입을 위해 운영자에게 알립니다.
"microservices-patterns" 사용 중입니다. 서킷 브레이커가 즉시 열리는 이유와 조정 방법은?
예상 결과:
- 서킷 브레이커는 슬라이딩 윈도우 내에서 실패가 failure_threshold를 초과하면 열립니다. 일반적인 원인과 해결책:
- **너무 쉽게 열리는 경우:**
- - failure_threshold 증가 (5 대신 10 시도)
- - recovery_timeout 증가 (30초 대신 60초 시도)
- - 닫히기 전에 여러 성공이 필요하도록 success_threshold 추가
- **너무 오래 열려 있는 경우:**
- - 더 빠른 테스트를 위해 recovery_timeout 감소
- - 트래픽 볼륨에 기반한 적응형 임계값 사용
- **모범 사례:**
- - 서비스의 정상 오류율을 기반으로 failure_threshold 설정
- - 일반적인 장애 지속 시간보다 길게 recovery_timeout 설정
- - 매개변수 조정을 위해 서킷 상태 변경 모니터링
보안 감사
안전Static analysis detected 36 patterns across 2 files. All findings evaluated as false positives or safe educational content. The 18 weak crypto alerts match on words like design and description in documentation. The 11 external command alerts are markdown code fences for syntax highlighting. Network patterns are legitimate example URLs for teaching microservices communication. No actual security risks identified.
위험 요인
🌐 네트워크 접근 (7)
품질 점수
만들 수 있는 것
모놀리스를 마이크로서비스로 마이그레이션
Strangler Fig 패턴을 적용하여 레거시 모놀리스에서 기능을 점진적으로 추출하여 독립적으로 배포 가능한 서비스로 전환하면서 시스템 안정성을 유지합니다.
이벤트 주도 주문 처리 구축
Order, Payment, Inventory 서비스가 Kafka 이벤트를 통해 비동기적으로 통신하며 실패한 트랜잭션에 대한 사가 기반 보상 처리를 하는 주문 관리 시스템을 설계합니다.
서비스 호출에 복원력 추가
서킷 브레이커와 지수 백오프를 사용한 재시도를 구현하여 서비스를 연쇄 장애로부터 보호하고 부분 장애 상황에서 전체 시스템 안정성을 개선합니다.
이 프롬프트를 사용해 보세요
{application_type} 애플리케이션을 마이크로서비스로 분해하는 것을 도와주세요. 애플리케이션의 주요 기능은 다음과 같습니다: {list_functions}. 서비스 경계를 어떻게 정의해야 하며 어떤 분해 전략을 사용해야 하나요?마이크로서비스 아키텍처를 위한 API 게이트웨이 패턴을 설계해 주세요. 다음과 같은 서비스들이 있습니다: {list_services}. 게이트웨이가 인증, 속도 제한, 요청 집계를 어떻게 처리해야 하나요?다음 단계들을 포함하는 {business_process}에 대한 사가 패턴 구현을 도와주세요: {list_steps}. 각 단계에 대해 어떤 보상 작업을 정의해야 하며 부분 실패를 어떻게 처리해야 하나요?{service_name} 서비스가 가끔 지연 스파이크를 경험합니다. 서킷 브레이커 매개변수(failure_threshold, recovery_timeout, success_threshold)를 어떻게 구성해야 하며 기존 HTTP 클라이언트와 어떻게 통합해야 하나요?모범 사례
- 느슨한 결합과 높은 응집도를 보장하기 위해 기술 계층이 아닌 비즈니스 역량과 일치하는 명확한 서비스 경계를 정의하세요
- 시스템 복원력을 개선하고 블로킹 종속성을 줄이기 위해 최종 일관성을 허용할 수 있는 작업에는 비동기 이벤트 주도 통신을 사용하세요
- 서비스 간 호출에는 항상 서킷 브레이커를 구현하고 클라이언트가 부과한 타임아웃 예산보다 짧은 타임아웃을 구성하세요
피하기
- 분산 모놀리스 - 공유 데이터베이스나 동기식 종속성 체인을 통해 긴밀하게 결합된 마이크로서비스를 만들어 독립적인 배포의 이점을 상실함
- 수다스러운 서비스 - 단일 사용자 요청을 완료하기 위해 수십 번의 왕복 호출이 필요한 서비스를 설계하여 지연과 실패 지점을 증가시킴
- 모든 것을 동기식으로 - 모든 서비스 간 통신에 요청-응답 통신을 사용하여 긴밀한 결합을 만들고 독립적인 확장 및 장애 격리를 방해함