Amazon Simple Notification Service(Amazon SNS)
— AWS — 6 min read
Amazon Simple Notification Service(Amazon SNS)
- 주제 (topic) 생성
- 해당 하는 모든 구독자에게 메시지를 푸시
- 알림톡에 발생시 queue 에 메세지를 등록 쌓는다
- 카카오 메세지 시스템 서비스에서 구독한다
- 카카오 메세지 시스템 서비스에서 인포뱅크에 발송요청
aws configure AWS cAccess Key ID
20220901
비동기 프로그래밍
성장 정체되고있다...
제러드와일버그 => 대체 뭐가 문제야
고원과협곡모델
일이 도전적이지 않아서 정체된 느낌..
적당한 난이도에서 몰입이 일어난다 이때 성장이 발생한다 내가 하는일이 뻔해서 지루하다
비동기와 동기
일상은 비동기
이벤트드리븐프로그래밍 => javascript 클릭 비동기의 이벤트
os 는 프로세스 단위로 cpu 를 실행
함수를 호출하면 기다린다
rest 동기
비동기프로그래밍 프로세스간 통신을 할 때 messaging system
병렬프로그래밍
레이스컨디션 => 경쟁 발생 lock 을 걸어서 순서를 정함 쎄마포 뮤텍스
선택을 할 때 중요한 것은 정보의 양 fff
form follow function 형태는 기능에 따른다
계기가 필요하다 비동기 프로그램은 왜하냐 알림톡이 오류가나니 기부가 안된다 이런..
알림톡 장애가 나도 기부가 가능하도록 한다
트래픽이 많다면.. 우리는 몇명 안돼지만.. 많은 곳은 비동기 프로그래밍을 한다
장애는 내가 배울 수 있는 기회
kafka 레비랭큐 aws의 ?? => 중계시스템
[A] => [ 큐(중계기로 비동기) ] => [B]
Message 형태는 json 으로 보냄
서버와 서버사이의 통신을 비동기로 한다 command 메세지 event message
나 기부 등록 => [구독] => 알람톡 => event
카프카는 토픽이란 단위로 보냄 PUB/SUB 방식
QUE 에 넣으면 비동기 messaging 왜씀? eliminate Polling 접수기 목록은 주기적으로 서버데이터를 가져와서 보여줌
polling 이 좋아? 프로그램 모델이 단순하지만 자원이낭비.. resouce 낭비 중간에 메세지 시스템을 써 polling 안하도록 바꿀 수 잇다
bynamic Targeting 알림톡을 보내는데
[ 기부 ] = > [큐] = >[메세지시스템(dynamic targeting)] => [인포벵크 등등..]
큐에 log 를 보내서 dooray
대량 시스템은 kafka que 써서 씀 req => 쓰레드 (이 안에 메모리와 cpu 를 씀) => 최대한 빨리 종료시켜서 다른사람이들어볼 수 있도록 한다 요청이 오면 que 에 쌓는다
분산프로그래밍 스케일out ,스케일up (메모리,cup 올림) 하지만 비싸고 한계있어서 피시를 붙여서 스케일 out
log 를 보다가 error 가 있으면
많은 trafic
aws sns 쓰자
결과적 일관성
트랜잭션은 all of noting
배치가 돌아서 아림톡을 보낸다 que 를 쓰며 ㄴ좋지만 배치 table 에 넣고 돌리자
분산 시스템에서는
성공할때까지 시도
알림톡을 보낼떄 코드 중복을 없앤다 메세징 시스템 만듬
분산환경으로 갈수록 스슨하게 만든다
알림톡이 실패하면 일관성이깨지는 것이지만 단기적으로는 깨지지만 다시 시도해서 결국 보내지도록 하는것 결과적일관성
지금시스템은 결과적 일관성 당장은아닌데
트래픽이 많을수록 바로 받을 수 없다
[여러스스템] => [AWS SNS=> 이안에 여러 topic 존재] => [카톡보내는 서비스]= >[인포벵크]
아직 강결합이 해결되지 않음
topic 에 event 만 쏴주고 카카오비즈
aws 로그 topic 에 보냄
카카오시스템이 도메인 이벤트를 구독한다
각 서비스 => 로그체널로 쏴서 => logging service 에서 => 두레이로 보냄 => aws s3 => 슬랙
중복이 사라짐,관심사를 분리 => 좋은코드
기부 상태를 명확하게 하여 => 기부상태가 변경되면 => event 를 등록
필요성을
sns subclibe sending 구독한곳으로 오는지 테스트 해보기
어떤 기여를 할지 찾아본다 go SDK 를 스터디 하자
젠킨스 배포시 0. AWS LAmda 에 코드를 실행
- cloud watch 를 보고 싶다 =
시간이 필요한 => 배치성 작업은 => 젠킨스
코드가 불편하다 더 나은 경우가 어떤건지 생각해야지 성장한다
복합적인 문제는 다양한 관점으로 봐야 한다 이것이 시니어가 하는 일 (의사결정을 합리적으로 해야 한다)
단일관점은 위험하다 요구적으로 배치를 golang 으로 만들면 된다 => 주환님이 배치 만든것도 있다