그냥 push방식 데이터처리 방식을 다 이벤트 기반프로그래밍이라고 하지않음?
Observable, Promise, Future 혹은 그냥 단순하게 addEventListener ㅣ런것부터..
ㅇㅏ니면 정의나 규칙같은게 있는것?
메세징 ㅅㅓ버라는것을 이번에 알게되었는데,
그럼 메세징서버를 중개서버로 두고 있는 기술들은 모두 메세징서버에다가 요청 보내고, 거기서 알아서 처리해서 (MSA라 하면 ) API요청을 순차적으로 보내 완료된 작업들을 처리해주는 식?
이벤트 기반은 "이 이벤트가 발생하면 이 함수를 실행시켜주셈"하고 콜백함수를 넣어 놓는 방식이 대부분일듯. 예를 들어 js에서 callback 등록해서 마우스 이동, 클릭 등의 이벤트를 받는다든지. 이게 가능하려면 콜백함수를 받는 쪽이 이벤트를 감지하고, 실행시켜줘야함. 받는 쪽이 OS일 수도 있고, 프레임워크일 수도 있고 뭐 그렇고
그냥 메시지 시스템을 비동기 동작만으로 생각하면 그 말도 맞음 - dc App
이벤트 콜백 방식으로 도는 메시지 방식에 응답-요청 쌍에 대응하는 키 주면 필터로 감싸서 프로미스 만들어 쓰기도 하고 넓게보면 이벤트 핸들러 표현으로 프로미스고 뭐고 다 만들 수 있긴함 - dc App
요청 하나에 응답 하나 이런식이면 보통 이벤트 방식이라 안함 - dc App
이건 뭐에대한 답변임? 메세지시스템? 이벤트 드리븐?
Promise 쓰는거
Promise/Future 랑 EventListener/Observable/AsyncIterator 이렇게 둘로 나눠서 생각하면 됨 앞에거는 요청이 있고 응답이 있는 구조인데 뒤에건 그런 제약이 없음
음 보통 여러개의 이벤트를 처리하는 경우를 이벤트 드리븐이라고 하는구나..
머 subscribe하는 형태로도 볼수있을것같고..
한개의 응답 + 비동기X = 함수 호출 여러개의 응답 + 비동기 X = 제너레이터 한개의 응답 + 비동기 = 비동기 함수 호출 여러개의 응답 + 비동기 = EventListener/Observable/AsyncIterator
비동기만 있어도 넓은의미에서는 이벤트 드리븐 맞긴한데 보통 응답이 여러개인 경우를 말함
난 처리되는 이벤트 (혹은 요청) 개수에 따라서 나누는줄알았는데 응답개수로 나누는거였구만
덕분에 지식의 빈틈들을 잘 점검할수있었습니다.
인프라 내 다른 서비스들끼리 통신할 때 크게 동기 방식이랑 비동기 방식(메시지 큐)이 있어요. 동기 방식은 서비스 사이에 특정 포트 열어 놓고 REST, GraphQL, gRPC 등의 프로토콜로 직접 통신할 수 있는데, 보통 프록시 인터페이스를 거쳐서 전달돼요. (Kubernetes에서는 사이드카 컨테이너 형태로 inject) 이 프록시끼리 연결되려면 Consul 같은 서비스 디스커버리가 locate랑 health check를 해주도록 해야겠죠. REST가 웹에서 그랬듯이 국룰이지만 리소스의 multiplexing 문제와 동사(GET, PUT, POST 등)가 쿼리 동작을 표현하는 데 한계로 작용하기도 해요. 그래서 GraphQL이나 gRPC 같이 풍부한 쿼리가 가능한 프로토콜도 사용세가 늘어나고 있습니다.
비동기 통신, 메시지 브로커를 매개로 하는 방식은 publisher 서비스가 메시지 큐에 요청을 push하면, 나중에 consumer 서비스가 언제든 큐에서 그 요청을 읽어와서 적용할 수 있어요. MQ가 여러 서비스의 중심에 위치하게 되면, 동기 통신 때처럼 서비스 간 coupling이 스파게티처럼 복잡하게 엉키게 될 일이 없어요. MQ도 HA 세팅을 하거나 걍 서버리스 서비스를 이용하면 SPoF가 되진 않을 테고... 만약 하나의 트랜잭션(결제)이 여러 서비스에 걸쳐 진행된다면(MSA에서 일반적인 패턴), 서비스 중 하나가 죽어서 요청이 실패할 때 atomicity를 보장하는 게 큰 이슈가 됩니다.
요즘은 이를 해결하기 위해 분산 트랜잭션보단 DB와 MQ를 직접 연결하거나 사가 패턴으로 보상 트랜잭션을 보장합니다. 예컨데 DB 업데이트 후 메시지가 제대로 발행되지 않고 서비스가 죽으면 다음 서비스도 처리가 안 되고, DB가 불안정한 상태로 남겠죠. 그래서 DB 테이블이나 트랜잭션 로그를 직접 읽는 서비스를 띄워서, 이로부터 메시지를 발행, 서비스의 가용성을 보장할 수 있게 됩니다.
예컨데 DynamoDB는 DDB Streams에서 읽어올 수 있고, Aurora 같이 트랜잭션 로그를 지원 안 하면... 번거롭지만 별도의 테이블에 timestamp와 함께 로그를 찍고, 주기적으로 로그 테이블을 읽어오는 패턴을 먼저 떠올려 볼 수 있겠죠. 비효율적이어 보일 수 있지만 atomicity 보장이 가장 중요하니까요...
요즘은, 특히 MSA가 적용된 인프라에서는 CAP 중에서 Consistency를 포기하고 대신 Eventually Consistency를 채택합니다. 적절한 안전 장치를 걸어 두면, DB에 언제 접근하든 특정 row가 항상 같은 상태일 필요는 없으니까, 분산 컴퓨팅 아키텍처 상에서 제약이 줄어드니까요. 비동기 메시징도 EC와 Availibility를 핵심 원리로 전제하고 활용됩니다. 뇌절을 하자면 요즘같이 IoT다 뭐다 해서 세계 곳곳의 온갖 디바이스로부터 실시간 데이터가 수집되는데, 이 데이터들이 글로벌 스케일에서 Consistency를 유지한다는 건 꿈같은 얘기죠. 그냥 EC를 전제하고 디바이스와 가까운 서버에서 데이터 수집/서비스 제공을 하는 형태를 엣지 컴퓨팅이라고 해요.