[빗썸테크아카데미] 첫번째 - OT, 동기/비동기와 Event-driven Architecture

[빗썸테크아카데미] 첫번째 - OT, 동기/비동기와 Event-driven Architecture

 

 

https://be-developer.tistory.com/34

[빗썸 테크 아카데미] BE 심화 과정 최종 합격 후기 >< (+기술과제)

 

 

드디어 개강한 빗썸테크아카테미 백엔드 심화과정 :)

지원서 접수 다음날 바로 과제가 나오고, 과제기간 이틀 후 또 바로 합격자가 나오고, 또 바로 교육이 시작되었다.

스피드하게 진행되는게 내스타일

 

어제 첫 수업시간을 가졌고, 수업 시작전 OT시간을 가진 뒤 동기와 비동기, 그리고 Event-driven Architecture의 개념에 대해 학습했다.

 

 

 

 

1. OT

OT는 우선 백엔드와 프론트 다 같은 줌 링크에서 진행을 했고, 공통사항에 들은 후 프론트와 백엔드 줌 링크가 나누어졌다.

공통사항에서는 일단 디스코드 잘 깔았는지, URCLASS 잘 가입했는지, 블로그는 잘 생성했는지 등을 확인을 했다.

그 후 백엔드만 모였는데, 이번 기수의 백엔드는 총 24명이었다.

전부 카메라를 키고 수업을 진행해야했고 생각지 못하게 각자 한명씩 돌아가면서 자기소개를 진행했다.

 

자기소개를 들어보니, 한분만 취준생이었고 나머지는 직장인 분이셨다.

나는 백엔드 과정이라서 대부분 자바 개발자일 줄 알았는데, 백엔드가 궁금해서, 또는 전향하려고 백엔드 과정을 진행하시는 프론트엔드분들이 꽤 있었다.

지하철에서 퇴근길에 들으시는 분들도 있었는지, 자기소개하는데 막 지하철 소리 들리고, 사람들 삑삑 카드찍는 소리도 들리고 그랬는데 정말 다들 열정적이구나,,, 싶었다.

 

자기소개를 진행하고 몇가지 공지를 더 한뒤 바로 수업에 들어갔다.

 

 

 

---

 

2. 동기/비동기 프로그래밍

 

2.1 동기(Synchronous) 프로그래밍

- 요청자가 처리자의 종료 시점을 확인

 

 

2.1.1 동기 프로그래밍의 예시

카페에 들어간 상황

요청자가 카페에 들어가서 주문을 하면, 사장님(처리자)이 주문을 받고 메뉴를 만드는 동안 요청자는 사장님이 음료를 언제 다 만드는지 계속 보고 있다가, 음료가 완성되어 받아서 나가면 사장님은 이 한건의 주문이 완료가 된다.

 

 

 

웹사이트 쇼핑몰 검색 창

 

 

 

클라이언트(요청자)는 검색창, 인기검색어, 광고, 아이템들에 대한 API 요청을 서버(처리자)에 보낸다.

서버가 각 API 요청을 동기적으로 하나씩 순차적으로 처리한다면 페이지 로딩만 한세월 걸릴 것이다.

한국인은 페이지가 느린걸 절대 못참기 때문에 페이지를 전부 떠나감

-> 해결법 : 서버를 nonblocking 상태로 만들어서 받은 요청에 각각 리소스를 할당해, 완료되는 것 부터 리턴하게 하면 사용자는 빨리 뜨는것부터 바로바로 볼 수가 있다.

 

 

2.2 비동기(Asynchronous) 프로그래밍

- 요청자가 처리자의 종료 시점을 신경쓰지 않음

 

 

2.2.1 비동기 프로그래밍의 예시

카페에 들어간 상황

 

 

요청자가 카페에 들어가서 주문을 하면, 사장님(처리자)이 주문을 받고 요청자에게 진동벨(Callback)을 준다. 사장님이 메뉴를 만드는 동안 주문자는 사장님이 언제 음료를 완성하는지 확인할 필요 없이 자기 할일을 하고 있다가 진동벨이 울리면 음료를 받아서 나간다.

 

 

 

2.3 동기와 비동기의 코드 처리

@Async는 비동기로 처리하라는 어노테이션

 

동기적 처리 (@Async이 없는 경우)

main 함수가 실행되어 for문이 0부터 100까지 돈다면,

myservice.service는 동기적으로 처리가 되면서 0~100 까지 순차적으로 찍히게 된다.

ex) 0,1,2,3,4,5...

 

 

비동기적 처리 (@Async이 있는 경우)

main 함수가 실행되어 for문이 0부터 100까지 돈다면,

myservice.service는 비동기적으로 처리가 되면서 어떤 쓰레드가 먼저 일을 끝낼지 모르기 때문에 0~100 까지 비순차적으로 찍히게 된다.

ex) 0,2,1,3,4,6,5...

 

 

 

 

3. Event-driven Architecture

3.1 Event Driven Architecture의 주요 요소

 

Event

• 관찰하기로 약속된 주요 사건
• message, notification등...

 

Producer

• Event를 생성해서 Event Bus로 보내는 역할
• publisher라고도 불림

 

Consumer

• Event Bus에서 이벤트를 받아서 처리하는 곳
• 주로 각각의 서버들
• receiver나 subscriber라고 불림

 

Event Bus

• Producer가 이벤트를 실어 놓는 곳
• Producer에서 Consumer로 이벤트 전달
• 주로 message queue나 event queue로 구성
• EventBus가 좀더 똑똑해지면 Event Broker라고도 표현이 됨
• Event Broker : 이벤트를 단순 싣는 역할이 아닌, 누구한테 나눠줄지 어느시점에 나눠줄지 관여 가능

 

 

3.1.1 예시

 

Topic Space(Producer)는 Topic(Event)을 생성한 뒤 Event Broker로 보낸다.

Event Broker는 System A~D(Consumer)와 DS(Consumer)에 적절하게 이벤트를 분배한다.

 

 

 

3.2 Event Driven 제약 사항

• 이벤트는 발생한 사건에 대해 약속된 형식 사용
• 불변 : 과거의 메시지를 변경할 수 없음
• 발생한 사건에 대한 결과 상태 전달
• 생성자는 이벤트를 누가 처리했는지 이벤트 처리 상태에 관여하지 않음
• 소비자는 이벤트를 누가 생성했는지, 생성자에 관심 갖지 않음

 

 

3.3 Event Driven Architecture 설계시 고려 사항

Loosely coupling

• 한 모듈이 따른 모듈에 너무 종속적이면 안된다.
• 고려사항이라고는 하지만 비동기적인 프로그램을 하기 위해선 사실상 필수 사항

 

Removing dependencies 

• 의존성을 제거
• 의존성을 제거 해서 Loosely한 coupling 상태로 만들어야 함

 

Nonblocking transaction

• 트랜잭션 단계에서 서로 영향을 주지 않도록 해야함.
• 회원가입을 할때, 핸드폰 인증을 하고 이메일 인증을 순차적으로 진행을 하는데 이메일 인증에서 오류가 났다고 해서 핸드폰 인증까지 같이 취소가 되면 안됨

 

Asynchronized callback

• 비동기 콜백은 필수는 아님
• 그러나 사용의 편리성으로 가장 많이 사용

 

Fallback /Retry

• 실패 했을 경우 어떻게 하고 어디까지 돌아가서 재시도 할것인가를 구분 지을 필요 있음
• 딱히 정해진 방식이 없어서 설계자의 능력이 중요

 

Event logging

• 비동기는 로그가 중구난방으로 찍히기 때문에, 이벤트 로그가 잘 찍히게 설계해야함.

 

 

 

 

3.3 Event Driven Architecture Pattern

 

Single Producer - Single Consumer

• 하나의 생성자가 있고 하나의 소비자가 있어서 이벤트 버스를 그냥 거치기만 한다의 아주 단순한 개념
• 동기와 다를바 없음

 

Single Producer - Mulit Consumer

• 이벤트의 처리비용이 이벤트의 생성비용보다 높을 경우
• 대부분의 경우에는 Producer보다 Consumer가 더 많음
• Producer는 만들어내기만 하면 되는데 Consumer는 복잡한 로직으로 이벤트를 처리해야하기 때문

 

Dead letter Queue(DLQ)

• 이벤트 처리가 계속 실패하고 설정한 재시도 시간 동안 처리되지 않을 경우 main message queue에서 제거하고 사후 분석을 위해 DLQ로 이동
• 이벤트를 생성할때 created 시간과 expires 시간을 설정해서 expires 시간이 만료되면 이벤트를 DLQ로 넘긴다.

 

Time to Live

• 처리되지 않은 이벤트의 생명 주기를 제한하여 만료되면 이벤트 폐기
• ex) 코인이 10만원 찍으면 알려달라고 알림을 걸어놨는데, 서버상의 문제로 인해 코인이 10만원이 된지 10분이 지났는데도 알림이 안가면 이미 그 알림은 너무 늦어 의미가 없기 때문에 폐기.

 

 

 

3.4 Event Driven Architecture의 특징과 장단점

특징과 장점

• Sevice간 호출이 많은 Microservice Architecture에 적합.
• Infra Structure의 유연한 사용
• Polyglot 구성에 용이 -> 모듈별로 서로 다른 언어와 DB 사용 가능
• 가용성, 응답성 ↑ -> 효율성, 성능 ↑ -> 요청이 많아질 수록 성능 향상 기대
• Fault Isolation : 에러가 생겨도 각각의 모듈에 독립적으로 생기기 때문에 다른 모듈은 정상 가동이 가능

 

 

단점

• 설계 복잡도, 운영 복잡도 증가
• Message Broker 의존성 증가 ->Fault Isolation의 장점이 있어도 모든 Message가 모이는 Message Broker 자체가 고장나면 시스템이 멈춰버림
• 코드 가독성 하락 -> 눈에 익은 코드가 아니므로 코드 읽기가 어려움
• 디버깅 난이도 상승 -> 스텝투스텝으로 동기적으로 따라갈 수가 없고, 중구난방으로 로그가 찍히기 때문에 어디서 고장이 났는지 파악하기 힘듬
• log를 통한 system flow 가독성 하락

 

 

 

---

수업 후기

 

 

수업 도중에 배운 내용에 대해 간단한 퀴즈가 나왔다.

 

Pop Quize

1. 비동기 프로그래밍 한줄 요약해주세요

2. Event Driven Architecture의 구성 요소를 설명해주세요.

 

퀴즈가 나오고 풀어볼 사람 손을 들어달라고 했는데, 생각보다 참여율이 좋았고 신기했던게 오늘 배운 내용을 바로바로 답변할 수 있는 분들이 계셔서 너무 신기했다...

 

진짜 열심히 공부해야겠다..

 

그나저나 첫날인데도 너무 피곤했는데 6주동안 잘 달릴수 있을까..?