[부캠챌린지] Day12 - 디자인 패턴, 그리고 동기와 비동기

※ 본 카테고리의 내용은 부스트캠프 챌린지 기간동안 학습한 내용을 바탕으로 정리한 내용입니다.

 

목차

---

0. 옵저버 패턴

 

위키백과 / 출처 : https://ko.wikipedia.org/wiki/%EC%98%B5%EC%84%9C%EB%B2%84_%ED%8C%A8%ED%84%B4

 

옵저버 패턴(Observer Pattern)은 어떤 객체의 상태가 변할 때 그와 연관된 객체들에게 알림을 보내는 디자인 패턴입니다.

 

관찰 대상(A와 B)에게 이벤트가 발생하면 관찰자(Observer)는 콜백을 받습니다.

이 말은 관찰 대상이 누구인지 옵저버는 이미 알고 있다는 이야기가 되겠죠?

관찰 대상들은 관찰자에게 의존성을 가지게 되고, 어떤 변화가 생기게 된다면 관찰자를 통해서 자동으로 갱신될 수 있습니다.

이 말은 계층적 구조의 상호작용을 필요로 하는 곳에서 옵저버 패턴이 굉장히 유용할 수 있다는 것이겠죠?

하지만 전달된 정보가 올바른 정보인지 아닌지는 명확하지 않기 때문에 그것을 처리할 수 있는 방안이 필요하고, 관찰자 역할을 하는 쪽에 불필요한 정보가 있는지를 지속적으로 확인하고 처리해야 한다는 단점이 있습니다.

 

⭕ 장점

• 일관성이 높음
• 게시-구독 관계로 변경된 정보를 아래로 통보하는 데에 용이
• 계층적 구조에서 유용하게 사용

 

❌ 단점

• 전달받은 정보가 올바른 정보인지 확인하는 절차가 필요
• 관찰자(감시자)에게 불필요한 정보가 있는지 확인 필요

 

---

1. 발행-구독 패턴

 

출처 : https://daddyprogrammer.org/post/3688/redis-spring-data-redis-publish-subscribe/

 

발행-구독 패턴(Publish-Subcribe Pattern)은 특정 토픽을 구독한 모두에게 메시지를 전달하는 방식입니다.

가장 대표적으로는 유튜브 구독 시스템을 들 수 있습니다.

퍼블리셔는 영상을 만들고, 구독자는 좋아하는 유튜버에게 구독 버튼을 누릅니다.

이제 구독 버튼을 누른 구독자는 유튜버가 영상을 올리면 알림이 가게 됩니다.

 

구독자와 유튜버 사이에는 분명 무언가 중간 다리가 있겠죠?

구독 처리, 알림 발송, 구독 취소 등의 중간 과정을 유튜브라는 회사에서 처리하게 됩니다.

 

이러한 발행-구독 패턴의 가장 핵심적인 부분은 구독자와 유튜버(퍼블리셔)는 서로가 서로를 알지 못한 상태로 구독이라는 연결매체로 서로 이어지게 됩니다.

누가 누구를 구독했는지는 사실 유튜브라는 회사(Publish Center)만이 아는 것이죠.

(물론 현실에서는 유튜브측에서 누가 누구를 구독했는지 정보를 공개하기 때문에 서로 다 알고 있지만 말이죠!)

 

이렇게 발행자와 구독자가 느슨하게 결합되어있기 때문에 서로에게 영향을 받지 않고 동작할 수 있게 됩니다.

이전 클라이언트-서버 패러다임에서는 서버가 Running상태가 아니면 클라이언트가 서버로 메시지를 보낼 수 없고, 서버 또한 클라이언트가 동작하기 전에는 클라이언트에게 메시지를 보낼 수 없는 구조였습니다.

하지만 발행-구독 패턴을 이용해서 서로를 분리함으로써 더욱 자유로운 동작이 가능해진 것이죠!

 

물론 이렇게 좋아보이기만 하는 발행-구독 패턴에도 단점은 존재합니다.

너무나도 많은 부분이 분리(Decoupling)되면서 애플리케이션에 반드시 필요한 부분의 명세까지 덩달아 어려워진다는 점, 그리고 발행자와 구독자 사이에 위치하는 중간 연결 매체의 힘이 커지면서 보안 문제가 발생할 가능성이 커집니다. 또한 매개체측의 실수로 잘못된 데이터가 공유될 수 있습니다.

 

⭕ 장점

• 서로의 존재를 알 필요 없음
• 시스템이 어떻게 운영되는지 역시 알 필요가 없음
• 서로가 준비되어 있지 않더라도 비동기 통신이 가능함

 

❌ 단점

• 애플리케이션의 속성 명세가 어려움
• 보안 문제 가능성 높음
• 잘못된 정보를 공유할 가능성 높음

 

1.0. Redis 모듈

발행-구독 패턴을 그대로 따르는 좋은 예시가 바로 Redis 모듈입니다.

Redis 모듈은 하나의 클라이언트가 메시지를 발생시키면 연결된 다수 클라이언트에게 메시지를 전달할 수 있는 구조로 되어있습니다.

딱 발행-구독 패턴이죠?!

추가로 NoSQL 데이터베이스중 하나이기 떄문에 텍스트 뿐만이 아닌 다양한 자료구조를 저장할 수 있으며, In-memory 특성으로 데이터를 메모리에 저장해서 접근 속도를 빠르게 할 수 있습니다.

 

Redis

 

 

---

※ Event Emitter, Promise/then, async/await 복습 필요!