패스트캠퍼스 캐시백 챌린지 43일차

수강 인증샷

Microservice Architecture과 Monolithic Architecture의 장단점에 대한 리뷰와 통신패턴에 관한 클립들을 수강하는식으로 챌린지를 진행하였다. 상황별로 각각의 아키텍쳐로 개발할때 발생할 수 있는 상황에 대해 알 수 있었고, Synchronous와 Asynchronous에 관한 내용도 다루어주셔서 통신패턴들의 종류도 알게되었다. 향후에는 Django와 Flask로 개발하며 RabbitMQ도 다루게 될 것이라고 한다. 다음 포스팅부터는 Microservice Architecture로 개발해가는 포스팅을 할 예정이다.

 

 

모놀리식 아키텍처

• 장점

⇒ End-to-End 테스트가 용이

⇒ 빠르게 간단한 서비스를 만들 수 있음

 

• 단점

⇒ 조그마한 수정사항이 있어도 전체를 다시 빌드하고 배포

⇒ 유지보수도 힘듬

⇒ 덩치가 너무 커져 구동시간이 늘어남

⇒ 일부분의 오류가 전체에 영향을 미침

⇒ 각 기능에 따라 다른 언어를 선택할 수 없음

 

하나의 프로젝트에 있다보니 각 기능이 독립적이지않고 특정 기능의 수정사항이 생겨도 다른 기능에 영향을 많이 주게된다. 검수QA작업이 반복적이어야 하고 번거로워진다.

 

마이크로서비스 아키텍처

• 장점

⇒ 유지보수 용이

⇒ 거대한 서비스도 빠르게 수정가능

⇒ 각 가능에 따라 다른 언어를 선택할 수 있음

 

• 단점

⇒ 모니터링이 힘듬

⇒ End-to-end 서비스 구동 불편(테스트가 불편)

 

각 기능간의 interaction도 맞추어주어야하고 각 기능마다 다른 db를 사용하기에 싱크도 맞추어주어야하는 등.. 초기세팅시 구성해줄 내용이 많다.

업무배분시에는 MSA가 상당히 유용하다.

 

마이크로서비스 설계 - Domain Event 정의

• 이벤트는 Actor가 Action을 해서 발생한 결과입니다.
• 각자 생각나는 Event를 적고 더 이상 생각이 안 날때까지 붙입니다.
• 서로 상이하면서 중복된것을 없애거나 합칩니다.
• 이벤트가 발생하는 시간 순서대로 붙입니다.동시 수행되는 이벤트는 수직으로 붙입니다.
• 비즈니스 용어로 무슨 일이 발생했는지를 적는것이지,시스템 내에서 발생되는 것을 찾는게 아닙니다.

 

마이크로서비스 통신 패턴

• Synchronous Solution

⇒ 동기적

⇒ Rest API

⇒ 서비스 A에서 서비스 B로 직접 요청을 보내고 동기적으로 응답을 기다림

 

• Asynchronous Messaging

⇒ 비동기적

⇒ 메시지 브로커를 사용하여 서비스A에서 서비스 B로 메시지를 보냄

⇒ 서비스 A는 응답을 기다리지 않음

⇒ 서비스 B는 일반적으로 동일한 메시징 시스템을 통해 결과를 사용할 수 있을때(결과가 예상되는 경우)결과를 보냄

⇒ RabbitMQ와 Apache Kafka

 

Synchronous Solution의 문제점

• A가 연결을 시도할 때 B가 오프라인 상태 일 수 있다.
• 그런 경우 어딘가에 요청을 저장하고 나중에 다시 시도해야 하는가?
• 언제 다시 시도해야 하는가?
• 얼마나 자주 시도해야 하는가?
• A가 응답을 기다리는 동안 시간이 오래 걸리거나 실패할 수 있다.
• B가 데이터 처리를 완료했지만 A가 오프라인 상태인 경우 어떻게 처리해야하나?

 

Asynchronous Messaging

• A(Producer)에서 B(Consumer)로 메시지를 전달하고 B에서 A로 메시지를 전달할 때 중개자 역할을 하는 “메시지 브로커”
• 메시지 브로커는 Producer에서 메시지를 수신하여 Consumer에게 메시지를 전달하여 작업을 수행
• 메시지 브로커는 Consumer의 연결이 끊어졌을 때 임시 메시지 저장소를 제공
• 마이크로서비스 별로의 독립성을 확보

 

 

 

https://bit.ly/3L3avNW

패스트캠퍼스 [직장인 실무교육]

*본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.