소프트웨어 아키텍처 패턴

[배포 및 테스트 패턴] 카오스(Chaos) 엔지니어링 프로덕션 테스트 패턴

카오스 엔지니어링 – 문제 상황 클라우드에서 실행되는 분산 시스템에서 장애는 피할 수 없는 요소이다. 운영상황에서 인프라는 언제든지 문제가 발생할 수 있다. 실제 문제가 발생할 때까지는 어떻게 대응해야 할지 알 수가 없다. 카오스 엔지니어링 패턴 카오스 엔지니어링 패턴은 운영 시스템에 임의로 장애 상황을 발생시키는 것이다. 이런 장애에 시스템이 어떻게 반응하는지 모니터링 하고 결과를 분석한다. 카오스 엔지니어링 패턴 - 장점 개발자들에게 장애에 대해 더 많은 생각을 하게 한다. 개발팀의 능력을 테스트해 볼 수 있다. 시간이 지나면서 시스템의 복원력 및 안정성이 높아지고 모니터링 및 운영 이슈 해결 능력이 높아진다. 참고 https://www.udemy.com/course/cloud-computing-so..

2024. 2. 25. 20:15

소프트웨어 아키텍처 패턴

[배포 및 테스트 패턴] 카나리(Canary) 릴리스 및 A/B 테스트 패턴

카나리 릴리스 및 A/B 테스트 배포 패턴 롤링 배포와 블루 그린 배포 패턴의 장점을 살린 배포 패턴이다. 카나리 릴리스 카나리 릴리스는 기존 서버 그룹 안에 작은 서브셋을 만든 다음 새 소프트웨어 버전을 업그레이드 하는 방법이다. 안전하다. 카나리 배포를 효과적으로 수행하기 위해서는 모니터링을 자동화할 수 있도록 성공 기준을 명확하게 설정해야 한다. A/B 테스팅 vs 카나리 릴리스 A/B 테스팅 A/B 테스팅 참고사항 실험 버전에 참여한 사용자들은 자신이 실험에 참여했다는 사실을 모른다. 우리도 사용자로서 A/B 테스팅 실험에 참여하고 있다. (인지하지 못한다) 실험 기간은 사용 사례에 따라 달라진다. 참고 https://www.udemy.com/course/cloud-computing-softwar..

2024. 2. 25. 20:14

소프트웨어 아키텍처 패턴

[배포 및 테스트 패턴] 블루-그린 패턴

블루-그린 배포 패턴 – 문제 상황 롤링 배포에서는 소프트웨어 새 버전을 릴리스할 때 서버를 한대씩 내리고 배포하는 방식을 사용했다. 하지만 장애가 연쇄적으로 발생할 가능성이 있고, 호환성 문제가 발생할 수 있다. 블루-그린 배포 패턴 블루-그린 배포 패턴에서는 운영서버와 동일한 배포 환경인 그린 환경을 두고 업그레이드를 진행한 다음 그린 환경을 운영서버로 변경하는 방식이다. 블루-그린 배포 패턴 - 장점 블루환경과 그린환경은 동일한 서버 개수를 가지고 있다. 특정 시점에 하나의 버전만 가지고 있다. 블루-그린 배포 패턴 - 단점 실제 필요한 서버 수의 두 배로 실행을 해야 한다. 즉, 추가적인 하드웨어 비용이 든다. 참고 https://www.udemy.com/course/cloud-computing-..

2024. 2. 25. 20:13

소프트웨어 아키텍처 패턴

[배포 및 테스트 패턴] 롤링 배포 패턴

롤링 배포 패턴 – 문제 상황 애플리케이션의 새로운 버전에 맞게 운영 서버를 업그레이드 해야 하는 상황이다. 보통 다운타임이 필요하다. 롤링 배포 패턴 롤링 배포 패턴에서는 모든 서버를 중단하고 새 버전을 배포하는 대신 로드 밸런서를 사용해 애플리케이션 서버를 하나씩 닫고 하나씩 배포하는 패턴이다. 롤링 배포 패턴 - 장점 롤링 배포 패턴 - 단점 참고 https://www.udemy.com/course/cloud-computing-software-architecture-patterns-korean

2024. 2. 25. 20:12

소프트웨어 아키텍처 패턴

[신뢰성, 오류, 복구 패턴] 데드-레터 큐(Dead-Letter Queue) 패턴

데드 레터 큐 패턴 메시지 브로커에서 목적지로 전송될 수 없는 메시지의 특별한 큐이다 메시지 전송방식은 2가지가 있다. 프로그래밍적 발행 원래 큐에서 자동으로 메시지를 DLQ로 이동 메시지 브로커가 기능을 제공해야 한다 데드 레터 큐 패턴 – 문제 상황 온라인 스토어에서 주문하는 서비스이다. 일반적으로 정상적으로 진행이 되지만 특정 경우에 주문 접수가 되지 않는다. 여러 가지 원인이 있을 수 있지만 다양한 문제의 원인을 어떻게 파악할 수 있을까? 데드 레터 큐 패턴 이러한 문제를 해결하기 위해 데드 레터 큐를 사용한다. 데드 큐는 목적지로 배달될 수 없는 메시지를 위한 특별한 큐이다. 데드 큐로 보내는 방식은 프로그래밍 방식과 메시지 브로커에서 자동 전송하는 방식이 있다. 데드 레터 큐 패턴 – 중요 내..

2024. 2. 25. 20:11

소프트웨어 아키텍처 패턴

[신뢰성, 오류, 복구 패턴] 서킷 브레이커(Circuit Breaker) 패턴

서킷 브레이커 – 문제 상황 온라인 데이팅 서비스에서 이미지 서버에 심각한 문제가 발생한 상황. 1시간의 복구 시간이 필요한 상황에서 데이팅 서비스에서는 어떻게 처리해야 할까? 서킷 브레이커 고려사항 이미지 서버의 지난 N번 요청 실패 재시도를 사용해야 할까? 재시도하지 말아야 할까? 재시도 패턴 – Optimistic 접근 다음 요청에는 성공할 것이다 서킷 브레이커 – Pessimistic 접근 다음 요청에도 실패할 것이다 서킷 브레이커 서킷 브레이커는 다른 서비스로의 요청을 래핑한다. 정상일 때는 회로가 폐쇄되어 있고 성공/실패 요청을 추적하고 있다. 서킷 브레이커 – 상태 서킷이 Open된 다음 결함이 복구되었다는 사실을 어떻게 알 수 있을까? 서킷 브레이커 패턴 – 고려사항 서킷 브레이커가 Ope..

2024. 2. 25. 20:10

소프트웨어 아키텍처 패턴

[신뢰성, 오류, 복구 패턴] 재시도(Retry) 패턴

재시도 패턴 – 문제 상황 클라이언트가 서비스를 호출하는 시스템이다. 또한 서비스는 다른 서비스를 호출하고 가끔 에러가 발생하고 있는 상황이다. 특히, 클라우드 환경에서는 Software/Hardware/Network 오류로 인해 Delay, Timeout, Failure 등이 자주 발생할 수 있다. 재시도 패턴 원격 서버에 같은 요청을 다시 전송하여 동일 작업을 재시도 한다. 재시도 패턴 - 고려사항 어떤 에러를 재시도할 것인가? 일시적인지? 복구 가능한지? 지연/백오프 전략을 사용할 것인가? 재시도 스톰(Retry Storm)이 발생할 수 있다. 랜덤화와 지터 재시도 횟수와 시간 멱등성 재시도 로직을 어디에 둘 것인가? 재시도 스톰 (Retry Storm) 재시도 패턴 – 백오프 전략 장애가 발생한 ..

2024. 2. 25. 20:08

소프트웨어 아키텍처 패턴

[신뢰성, 오류, 복구 패턴] 속도 제한 패턴

문제 상황 – 시나리오 특정 클라이언트의 높은 트래픽으로 인해 다양한 문제가 발생한다. 쓰로틀링 패턴 특정 기간 발생하는 요청 수에 제한을 두는 패턴이다. 속도제한 - 대응 클라이언트가 제한을 넘었을 때 어떻게 대응할 것인가? 요청을 무시 요청을 대기시키고 이후에 처리 품질 저하 / 대역폭 제한 속도제한 - 고려사항 어디에 제한을 둘 것인가? API 기준 고객 기준 참고 https://www.udemy.com/course/cloud-computing-software-architecture-patterns-korean

2024. 2. 25. 20:07

소프트웨어 아키텍처 패턴

[기능 확장 패턴] 프론트엔드를 위한 백엔드 (BFF) 패턴

문제 상황 온라인 스토어가 시간이 지나면서 프론트엔드 코드가 더 복잡해지고 다양해지고 있는 상황이다. 해당 기능을 지원하기 위한 백엔드 역시 점점 복잡해진다. BFF – 벡엔드를 위한 프런트엔드 BFF 패턴을 사용하면 지원하는 프론트엔드 유형에 따라 개별 백엔드로 나눌 수 있다. 풀스택 개발자 팀을 둘 수 있고 독립적으로 개발할 수 있다. BFF 고려사항 – 공유 기능 각 백엔드에서 사용되는 공통 비즈니스 기능을 어떻게 관리해야 할 것인가? BFF 고려사항 – 1. 라이브러리 사용 모든 공유 로직과 API를 포함하는 공유 라이브러리를 구성하여 백엔드에서 재사용하면 된다. BFF 고려사항 – 2. 공유 서비스 생성 공유 기능을 개별 서비스로 만들고 범위와 API, 소유 팀을 명확히 정의하는 방법도 있다. ..

2024. 2. 25. 20:06

소프트웨어 아키텍처 패턴

[기능 확장 패턴] 손상 방지 어댑터(Anti-Corruption Adapter) 패턴

문제 상황 – 마이크로서비스로 분할 문제 상황 – 하나씩 변환 문제 영역: corruption 이때의 문제점은 새로운 시스템의 일부가 이전 시스템의 프로토콜이나 API 및 데이터 모델을 지원해야 한다는 점이다. 손상 방지 어댑터 패턴 새로운 시스템은 새로운 데이터 모델, 새로운 API, 새로운 기술을 사용해 손상 방지 어댑터 서비스와 통신한다. 참고 https://www.udemy.com/course/cloud-computing-software-architecture-patterns-korean

2024. 2. 25. 20:05

소프트웨어 아키텍처 패턴

[기능 확장 패턴] 사이드카(Sidecar) 및 앰배서더(Ambassador) 패턴

사이트카 패턴 – 문제 상황 각 서비스에는 핵심 기능 외에 여러가지 추가 기능이 필요하게 된다. 공통적으로 필요한 추가기능을 어떻게 효과적으로 관리를 해야 할지 고민이다. 코드 재사용 - 라이브러리 코드 재사용 원칙에 따라 하나의 라이브러리가 될 수 있다. 하지만 마이크로서비스 아키텍처에는 문제가 될 수 있다. 사이드카 패턴 사이드카 패턴은 애플리케이션에서 필요한 기능을 메인 애플리케이션과 동일한 서버에 개별 프로세스나 개별 컨테이너로 실행할 수 있다. 앰배서더(Ambassador) 패턴 서비스를 대신 해 모든 네트워크 요청을 전송하는 역할을 한다. 프록시와 비슷하지만 동일한 호스트에서 실행이 된다. 모든 통신이 앰배서더를 통해 이루어지므로 서비스 간 분산 추적을 할 수 있고 문제를 파악하기 용이해진다...

2024. 2. 24. 19:50

소프트웨어 아키텍처 패턴

[성능 패턴] 이벤트 소싱(Event Sourcing) 패턴

이벤트 소싱 패턴 각 이벤트는 시스템 내 특정 엔티티에 대한 변경 사항과 사실 정보로 구성된다. 이벤트의 가장 중요한 특징은 불변성이다. 일단 시스템에 들어오면 절대 변하지 않는다. 로그의 마지막에 새로운 이벤트를 추가하는 작업만 가능하다. 이벤트 소싱 – 이벤트를 어디에 저장해야 하나? 데이터베이스 – 각 이벤트에 대한 개별 레코드 메시지 브로커 – 각 이벤트에 대한 개별 메시지 이벤트 소싱 & CQRS 이벤트 소싱 + CQRS 조합은 매우 인기가 있다 그 이유는: 이력과 감사정보를 확인할 수 있다. 빠르고 효율적인 쓰기 작업 빠르고 효율적인 읽기 작업 참고 https://www.udemy.com/course/cloud-computing-software-architecture-patterns-korean

2024. 2. 24. 19:48

소프트웨어 아키텍처 패턴

[성능 패턴] CQRS 패턴

CQRS 패턴 - 용어 Command 데이터의 결과를 위해 수행하는 작업 새로운 레코드를 삽입하거나 기존 레코드를 업데이트 또는 삭제하는 작업 예: 사용자 추가 리뷰 수정 댓글 삭제 Query 오직 데이터를 읽어서 호출자에게 반환 예: 카테고리의 모든 상품 조회 CQRS 패턴 CQRS에서는 명령파트와 쿼리파트를 완전히 분리한다. 비즈니스 로직, 입력 값 검증, 권한체크 등은 복잡한 작업은 Command 서비스에서 수행한다. 각 파트는 개별 프로그래밍 언어의 데이터 모델을 사용해 독립적으로 발전해갈 수 있게 된다. CQRS 장점 두 가지 작업 유형으로 시스템을 최적화할 수 있다. 특히 읽기와 쓰기 작업이 빈번하다면 고확장성 CQRS - 동기화 CQRS - 단점 Command와 Query 데이터베이스 간의 ..

2024. 2. 24. 19:47

소프트웨어 아키텍처 패턴

[성능 패턴] 구체화된 뷰(Materialized View) 패턴

데이터 저장 비즈니스나 고객 정보를 저장할 때는 성능과 비용면에서 가장 효율적인 방법을 찾는 것이 우선사항이다. 하지만, 데이터 저장 방법은 다양한 유형의 워크로드를 반영하지 않는 경우도 많다. 데이터 조회에 따른 문제 구체화된 뷰 패턴 해당 쿼리의 일부 또는 전체가 필요할 때, 구체화된 뷰에서 바로 읽어 들일 수 있다. 특히 애그리게이트 함수나 데이터 변환, 조인 시 지연 시간과 오버헤드를 크게 줄일 수 있다. 구체화된 뷰 고려사항 구체화된 뷰 테이블이 사용하는 추가 공간이 필요하다. 트레이드 오프 고성능을 위한 추가 공간 클라우드 환경 – 성능과 공간 중 어떤 것이 좋을지 고려 구체화된 뷰를 어디에 저장할 것인가? 원래 데이터가 있는 동일한 데이터베이스 DB 설정 지원 데이터베이스가 데이터 읽기 최적..

2024. 2. 24. 19:46

소프트웨어 아키텍처 패턴

[성능 패턴] 트랜잭셔널 아웃박스(Transactional Outbox) 패턴

문제 상황 사용자 서비스는 사용자를 데이터베이스에 추가하고 메시지 브로커에 이벤트를 전송한다. 그 이후 다른 서비스에서 해당 이벤트를 받아 후속 작업을 진행한다. 문제 상황 – 코드 예제 트랜잭셔널 아웃박스 패턴 트랜잭셔널 아웃박스에서는 메시지 브로커로 이벤트를 전달하는 대신 outbox라는 테이블을 이용하여 트랜잭션을 보장할 수 있게 한다. 트랜잭셔널 아웃박스 패턴 – Solution 트랜잭셔널 아웃박스 데이터/메시지 유실 문제를 해결한다. 각 데이터베이스는 적절한 이벤트 발생을 보장한다. 참고 https://www.udemy.com/course/cloud-computing-software-architecture-patterns-korean

2024. 2. 24. 19:45