AWS Community Day 2023 정리 (서버리스 세션)

개발자 생존기·2023년 11월 8일
awscommnitydayserverless서버리스
0

AWS

목록 보기
4/4

강연자료가 업데이트가 되어 있습니다!
https://event-us.kr/awskrug/event/71783

1. 모던 프론트엔드 개발자가 꼭 알아야 할 서버리스 서비스들

강의 내용 요약 by 클로바노트

00:00 ~ 02:11
프론트엔드 개발자의 인프라 공부

  • 모든 프로젝트 개발자가 꼭 알아야 할 커버리지 서비스들을 발표하게 된 김창현 사실 인사라고 함
  • 프론트엔드 개발자가 따로 없어서 인프라를 공부하게 되었고 자격증 딴 것을 기반으로 실제 프로젝트에 적용을 하고 있음

02:13 ~ 06:40
aws 클라우드 환경

  • aws 클라우드 환경을 이해하고 활용할 수 있는 백엔드 개발자든 뭐든 공고를 보면 aws 클라우드 환경을 이해하고 활용할 수 있는 사람을 많이 쓰는 것 같음
  • 프론트엔드한테 인프라 구축을 맡기지는 않겠지만 인프라 지식이 있으면 개발을 할 때나 커뮤니케이션 할 때 더욱 수월하기 때문에 요구를 하는 것 같음
  • 프론트엔드를 위한 서버리스 서비스도 있지만 프론트 핸드뿐만 아니라 웹 개발을 하는 다른 직군 개발자분들도 알면 좋거나 가장 많이 사용하는 서버리지 서비스들에 대한 내용을 담고 있음

07:01 ~ 08:03
서버리스 개발 모델

  • 클라우드 네이티브 개발 모델은 서버가 실종하지만 개발자는 서버를 구축하고 유지 관리하고 트래픽 맞게 오토 스킬 링스 세팅하고 할 필요가 없음
  • 개발자는 단지 추상화된 서버리스 모델을 설정하거나 코드만 배포하면 서버리스 모델들은 이벤트 기반 처리가 되어 실행됨
  • 서버리스에 대한 중요한 원칙 4가지를 이야기했는데 관리할 서버가 없으며, 유연하게 확장 가능하고 고가용성을 보장하고 사용하지 않는 용량에 대해서는 지불하지 않음

08:25 ~ 13:43
서버리스의 장점

  • 서버리스의 가장 큰 메리트는 관리할 포인트가 없으며 쓴 만큼 내고 유연하게 확장 가능한 포인트임
  • 인프라 지식에 미숙한 학생, 주니어들이 공부하려 했다가 aws 요금 폭탄 맞는 불상사를 예방할 수 있음
  • 신규 서비스를 런칭할 때 가장 힘든 점이 반응을 예상하기 어렵다는 것인데 인프라를 구축할 때 리소스는 얼마나 할당할지, 어느 포인트에서 스케일 아웃을 할지, 제한을 얼마나 둬야 될지 정량적으로 정하기가 되게 어려움
  • 앰플리파이드는 서버리스 서비스를 넘어서 백엔드와 인프라에 대한 걱정 없이 빠르게 프로스텍 앱을 만들기 위해 적합한 서비스임

14:02 ~ 18:39
피그마의 데이터 모델링

  • 피그마에서는 데이터 모델링을 통해서 간단하게 eid를 짠 뒤에 소스라는 거에 아이디와 테스트를 선언함
  • 피그마에 들어오면 프라이머 컬러로 바꾸실 수도 있고 디자이너들이 짜신 거를 그대로 임포트하시기만 하면 됨
  • 피그마 링크를 하면 피그마에 페이지들이 있는데 어떤 것을 받아들일지 설정을 할 수 있음
  • 콘텐츠를 넣을 때는 콘텐츠 메뉴를 통해서 데이터를 삽입할 수 있음
  • 그리드를 어떻게 설정할지 패딩과 마신 어떻게 설정할지 gui를 통해서 설정할 수 있음

18:51 ~ 21:26
Amplify 스튜디오의 기능

  • 페이지를 새로 만들어주고 텍스트에서 세이브 했을 때 데이터를 추가하기로 업체를 추가해놨음
  • 유저 관리나 콘텐츠 관리를 위해 보통 어드민을 따로 짜야 되는데 애플리파이 스튜디오를 어드민처럼 사용하면 됨

21:48 ~ 22:45
라다의 콜드 스타트 타임

  • 콜드 스타트는 서버 리스트 서비스들은 사용한 만큼만 지불되기 때문에 함수가 실행되지 않을 때는 잠시 컴퓨팅 파워를 꺼둠
  • 함수를 호출하면 남자 컨테이너를 띄우고 실행 환경을 구성하기 위해 약간의 딜레이가 발생함
  • 라다는 언어 외에도 할당된 메모리에 따라서 콜드 스타트 타임이 다른 것을 확인할 수 있음

23:10 ~ 25:46
콜드 스타트의 원인

  • 콜드 스타트를 해결하기 위해서 람다 함수를 5분마다 호출하는 방법이 대중적임
  • 콜드 스타트가 정확히 어떻게 동작하고 하기 때문에 생기는지 잘 모르시는 분들이 계신데 콜드 스타트에 대해 간략히 말씀드림
  • 콜드 스타트가 발행하게 되면 발생하게 되면 남자는 실행 환경을 처음부터 실행하는 대신 캐싱된 스냅 서비스를 이용하여 런타임을 실행하기 때문에 콜드 스타트 시간을 계산하게 됨
  • 스냅스타트를 사용하는 경우 기존의 콜드 스타트 세 가지 단계 코드 다운로드, 컨테이너 실행 런타임 실행 과정이 필요 없기 때문에 난데 실행 시간을 단축시키고 5분마다 계속 호출로 인한 사용 비용도 절감할 수 있음

26:14 ~ 28:13
스나트 패트의 유의사항

  • 스나트 패트를 사용할 때 유의사항과 모범 사례에 대해 설명하고 있음

28:33 ~ 30:15
api 게이트웨이의 기능

  • api 게이트웨이는 작은 단위 서비스를 통합적으로 관리할 수 있음
  • api 게이트웨이를 사용하게 되면 사용자는 각 서비스의 엔드 포인트 대신 api 게이트웨이로 요청을 보내게 되고, 요청을 받은 api 게이트웨이는 설정에 따라 각 서비스 엔드 포인트로 사용자를 대신하여 요청하고 응답을 받으면 다시 사용자에게 전달하는 프록시 역할을 하게 됨
  • api 게이트웨이의 주요 기능은 인증 및 인가, 라우팅과 로드 배너 시, 서비스 디스커버리임

30:39 ~ 33:11
클라우드 서비스의 정보 제공

  • 클라우드 경우 sk 인아웃이 자주 발생하고 컨테이너 생성 소멸에 따라 ip 포트 주소가 달라질 뿐더러 고정된 값이 아니기 때문에 서비스를 검색하여 정보를 제공해 주는 것은 필수라고 할 수 있음
  • api 게이트웨이를 사용하는 방법에 대해 설명하고 있음

기억해야 하는 것들

Lambda Snap Start

  • Lambda의 Cold Start는 사용 언어 및 할당된 메모리 사이즈에 따라 서로 다르게 나타난다. 일반적으로 스크립트 언어인 node 및 python의 경우 작고, 컴파일이 필요한 java, c#의 경우 큰 편이다.
    2017년 자료이므로 경향만 보자.

    https://theburningmonk.com/2017/06/aws-lambda-compare-coldstart-time-with-different-languages-memory-and-code-sizes/

  • Cold start가 왜 발생하는지 알기 위해서는 lambda의 life cycle에 대해 알아야 합니다. 아래와 같이 코드를 다운로드하고, 컨테이너를 실행하고, 런타임을 bootstrap이라는 실행 파일로 함수 배포 패키지에 포함하고, 코드를 실행하는 과정을 거칩니다.

  • 지금까지 Lambda의 Cold start는 불가피한 것으로 받아들이고 이를 최소화하기 위해 주기적으로 해당 lambda를 주기적으로 실행시키는 warm up 방식을 사용하였다. 그러나 이는 돈이 듭니다.

  • lambda snap start는 lambda의 사전 초기화된 스냅샷을 생성하고, 콜드스타트시 해당 스냅샷을 사용하여 코드를 실행하는 기능으로, snap start를 사용하는 경우 lambda function을 배포한 후 초기화 단계를 실험하고, 초기화 단계가 완료되면 메모리 및 로컬 디스크를 포함한 전체 기능의 스탭샷 이미지를 생성하고 캐싱하게 됩니다.

  • 그러나 sanp start를 도입하게 되면 lambda는 실행 환경을 처음부터 구축하는 대신 캐싱된 값을 이용하여 런타임을 실행하기 때문에 불필요한 warm up을 줄일 수 있고, 비용을 절감할 수 있습니다.

  • lambda snap start는 2022년 AWS Re:Invent에서 최초로 공개되었고, 몇 달 전에 한국에서 서비스가 시작되었습니다. java 11 및 java17 에서 지원합니다. 지원 기능 및 제한 사항은 아래 페이지를 참고하면 됩니다.

https://docs.aws.amazon.com/ko_kr/lambda/latest/dg/snapstart.html
https://aws.amazon.com/ko/blogs/korea/new-accelerate-your-lambda-functions-with-lambda-snapstart/

AWS Amplify

  • 풀 스택 및 모바일 앱을 심플하게 개발할 때 좋다. 특히 스타트업에서 빠르게 개발하거나 POC 용도로 많이 활용되고 있다.
  • Amplify Studio를 통해 포인트 앤 클릭으로 풀 스탭 앱을 빠르게 구축하고 배포할 수 있다.
  • vue, react, angular 등 다양한 프론트엔드를 지원한다.
    https://aws.amazon.com/ko/amplify/studio/?nc=sn&loc=2&dn=1

2. AWS SAM과 Localstack을 활용하여 로컬에서 서버리스 앱 테스트

강의 요약 by 클로바노트

00:00 ~ 02:54
로컬 스펙을 활용한 aws 람다 테스트

  • 로컬 환경에서 aws 람다를 테스트해 볼 수 있는 부분에 집중해서 다뤄보고자 함
  • 로컬 스펙이라는 것을 활용해서 로컬 환경에 x3를 띄워보는 방법도 살펴보려고 함
  • 런타인 인터페이스 애뮬레이터라고 부르는 rie와 런타인 인터페이스 클라이언트라고 하는 ric가 무엇인지에 대해서도 살펴볼 것임

03:19 ~ 08:03
서버리스 애플리케이션

  • 다음과 같이 두 가지 난방 함수를 만들어보고자 함
  • 영상 업로드 애플리케이션 같은 경우 api 게이트웨이를 통해서 생성한 엔드 포인트를 통해 htp 메서드 탭을 요청하면 람다수가 s3 버킷에 서명된 url을 요청하고 이를 다시 반환해주는 과정임
  • 이를 로컬에서 대체해 보면 awss이 api 게이트웨이의 역할을 대신해 주게 되고 로컬 스텝이 s3 버킷의 역할을 대신해 주게 됨
  • 샘은 서버리스 애플리케이션 모델로 클라우드 포메이션 문법을 활용해서 로컬 환경에서 서버리스 애플리케이션을 구동하게 도와주고 실제 이것을 aws 상에 배포하고 관리할 수 있게 도와주는 서비스임

08:26 ~ 11:04
람다 함수를 이용한 업로드 url 설정

  • 람다 함수를 정의한 프로포티에 api 게이트웨이를 이벤트로 사용을 할 거기 때문에 이벤트라는 속성 내에 api 게이트웨이 관련된 값들을 적어주면 됨
  • 해당 람다 함수는 htp api라는 이벤트를 가게 되고 해당 api는 업로드 url이라는 엔드 포인트와 함께 htp 메서드가 명시되어 있는 것을 확인할 수 있음
  • 라나우트 리소스를 정의한 것처럼 해당 api 게이트웨이에 대한 세부적인 부분을 참조해 주기 위해서 램프 공법을 활용해서 가르쳐주게 됨

11:23 ~ 15:28
도커 컨테이너의 로컬 스펙

  • 로컬 스펙이라는 호스트와 4,566이라는 포트를 가진 엔드 포인트를 값으로 설정해서 컴퍼스로 띄우는 컨테이너끼리 내부 통신이 가능하게 해줌
  • 로컬 스펙으로 s3 서비스를 띄우고, 다른 도커 컨테이너를 띄워서 로컬 스펙으로 s3 서비스를 띄우고, 다른 도커 컨테이너를 띄워서 그 컨테이너에서 엔드 포인트 url을 찔러줘서 버킷을 만들어주게 되는 것임
  • api 게이트웨이의 tp api의 문서를 보면 커터가 최대 10메가바이트의 페이로드까지 받을 수밖에 없게 제한되어 있음
  • 난바 한수의 경우 결국 6메가바이트보다 작은 페이로드를 전달해야 되고, 영상과 같이 만약 6메가바이트보다 큰 파일이 전달될 경우에는 s3에 서명된 url을 사용해야 된다는 이야기가 됨

16:02 ~ 19:08
람다 서비스의 로컬 실행

  • aws 람다 서비스를 로컬 환경에서 실행하기 위해 rie와 ric를 사용함
  • rie는 람다 서비스를 보관한 일종의 실행 파일임
  • ric는 람다 서비스와 실제 우리가 작성한 함수가 통신하는 api 계층임

19:34 ~ 21:08
api 게이트웨이의 페이로드 크기

  • 구조상에서 6메가바이트 이상의 크기를 가진 영상 파일을 전달한다고 가정을 해보면 사용자가 api 게이트웨이 엔드 포인트로 영상 데이터를 전송하게 됨
  • 로컬 환경에서 api 게이트웨이를 대신해주는 플라스크 웹 애플리케이션을 통해서 데이터가 전달됨
  • rie로 전송된 데이터는 6메가바이트가 넘었네 하고서 오류를 발생시킴
  • rie에서 페이로드 크기를 다루는 방법을 살펴보면 실행 파일은 고온으로 작성되고 빌드된 아키텍트인데 내부적으로 스페이워드 사이즈라고 하는 상수 변수 값을 설정하고 주석 처리된 것처럼 6 내리바이트보다 조금 더 큰 값으로 정의하고 있다는 것을 알 수 있음

21:27 ~ 25:17
파이썬 언어 환경의 역직렬화

  • rac에서 오류 메시지를 반환하게 되는데 o 네이블 2, o 마셜 인풋이라고 하는 마샬은 보통 파이썬 언어 환경에서 사용하는 역직렬화 디시비니얼라이제이션을 의미함
  • ric에서 내부적으로 오류를 처리하는 방법을 가볍게 살펴보시면 페이록을 다루는 함수 코드인 엄마셜 리퀘스트 메서드임
  • 제이슨 패키지를 활용해 로즈 메소드를 활용해서 페이로드를 역직렬화하려고 했을 때 ri으로부터 일부 분의 페이로드만 전달되었기 때문에 오류가 발생을 함
  • 이 부분에서 오류를 반환해 주게 되고 어네이블트, 엄마셜링크로드로 반환하고 있다는 걸 알 수 있음

25:37 ~ 28:35
플라스크의 api 게이트웨이 대체

  • api 게이트웨이를 대체할 플라스크가 샘이 만들어줌
  • 내부적으로 실제 문자열을 활용해서 토크 파일을 작성함
  • 플라스크 객체에서 re 시넥 파일로 페이 보드를 찌르는 부분이 있을 텐데 어떻게 되는 거지라는 궁금증이 있을 수 있음
  • 샘이 내부적으로 rie를 사용하는 방법을 간략하게 살펴보면, 2015년 5월 31일 펑션스라고 하는 경로를 그대로 사용을 하고 있음
  • 샘은 내부적으로 플라스크 웹 애플리케이션을 생성해서 api 게이트웨이를 대체하게 되고 이 api 게이트웨이를 대체한 플라스크 친구는 페이 로드를 전달받게 됐을 때 rie로 엔드 포인트로 찔러준다라고 생각을 해 주시면 됨

28:57 ~ 32:11
람다 함수의 정의

  • 람다 함수 정리하는 부분만 살펴보면 다음과 같이 거의 유사한데 메타 데이터 소송만 우리가 정의함
  • 실제 만들어진 도커 파일을 살펴보면 앞서 집 패키지 유형에서 살펴봤던 것과 동일하게 남가에서 제공해주는 공식적인 이미지와 우리가 cmd라고 하는 부분에 람다 흡수의 엔트리 포인트가 돼줄 핸들러 부분을 작성했다는 것을 알 수 있음
  • s3를 왜 정의하지 않았지? 이 부분이 조금 궁금하실 수 있을 것 같은데 로컬 스펙으로 이미 정의를 했기 때문에 생략했다라고 생각해 주시면 될 것 같음

32:41 ~ 36:18
클라우드 포메이션 야물 분법

  • 클라우드 포메이션 야물 분법을 활용해서 남당 함수와 여러 가지 서버리스 리소스를 정의할 수 있음
  • 샘을 활용해서 rie라고 하는 애뮬레이터를 추가하고 로컬 환경에서 람다 함수를 실행하는 방법을 알게 됨
  • 로컬 스텝을 활용해서 cli를 함께 추가해 줘서 s3 서비스 자체와 버킷을 만드는 방법도 알게 됨
  • 플라스크 웹 프레임워크를 사용해 api 게이트웨이를 모방한다는 것을 알 수 있게 됨
  • 페이로드 크기에는 제한이 있고 오류 메시지가 우리가 생각했던 것과 다르기 때문에 유의해야 함
  • 제이슨 객체 형식의 3 이벤트를 정의하고 양사 함수를 실행하는 간단한 로컬 인포크라고 하는 명령어도 살펴봄

기억해야 하는 것들

  • 이미 localstack을 활용하기 위해 여러 자료들을 보고 사내에서 환경을 구축하려 했으나 쉽지 않았음

  • 오히려 해당 강의에서는 Localstack보다는 SAM에 대해 생각보다 깊이 다루어서 생각해 볼 것들이 많았음

  1. Docker compose 기반
  1. Test Container 기반

3. 서버리스에서 부하테스트를 해야하는 다양한 목적과 실제 사레를 바탕으로 한 프랙티스 소개

강의내용 요약 by 클로바노트

00:00 ~ 01:13
서버리스의 통합 테스트 목적

  • 서버리스에서 통합 테스트를 하는 목적 세 가지가 있음
  • 서버리스의 비용을 미리 파악하기 위함이라는 이유가 있음
  • 서버리스 아키텍처와 요금 구성이 주로 사용량, 실행 단위의 종량제 요금이라는 거는 여러분 잘 아실 것 같음

01:36 ~ 04:01
비용 할당제

  • 비용 할당제를 사용하면 미리 요금을 내보고 항원치 요금을 안면 한 달 치 요금 알 수 있고 한 달 치 요금을 안면 1년 치 요금을 알 수가 있음
  • 서버에서는 전체기 때문에 총량을 알면은 총 비용을 알 수가 있기 때문에 부하 테스트를 미리 돌려보고 거기에서 나온 비용을 베이스로 해서 요금 계산을 하면 비교적 정확하게 그리고 효율적으로 비용을 낼 수 있다는 부분을 알려주는 것임

04:26 ~ 07:30
보안 테스트

  • 보안 테스트를 해보면 이런 부분을 알 수가 있고 트래픽을 얼마만큼 높이 얼마만큼 더 이파시도에 상한선을 조정을 해야 된다라는 부분이 보이기 때문에 그런 부분을 부가 데스를 미리 걸어보고 알 수 있다는 장점이 있음
  • 부하 테스트 결과를 보고 어떻게 최적화를 하면 되는지에 대한 부분을 생각을 하게 되는데 예를 들면 람다 같은 경우에 콜드 스타트 문제 같은 경우는 많이들 아실 거라고 생각함
  • 부하 테스트를 하다 보면은 서비스 할당량이 소량을 늘리거나 버스트 리닛을 고려하면서 람다를 타고 했어야 했던 그런 상황이 있었음
  • 보안 테스트를 해볼 수 있는 것을 나눠 드리겠음

07:53 ~ 11:17
람스의 스크롤링

  • 람스가 어떻게 돌았는지 잘 모름
  • 통크 버킷 알고리즘이라는 알고 있는 바로 유사하게 동작을 한다고 함
  • 스크롤링을 해주기 위해서는 구항을 어느 정도 사전에 조금씩 걸려줘야 처리할 수 있는 양이 늘어남
  • 부하 테스트를 하기 위한 큐드 활용법에 대해 설명하고 있음

11:17 ~ 13:24
프라게이트웨이의 기능

  • 테스트 클라이언트가 프라게이트웨이 테스크기 때문에 서버스를 어느 정도 사용해보신 분들이라면 구성도 이해하기 쉬울 것 같음
  • 도큐멘터도 설명이 잘 나와 있어서 어떻게 사용하기도 쉽고 시나리오대로 테스트를 할 수 있는 기능도 들어있음
  • 부하 테스트를 할 때 주의사항은 클라이언트를 점진적으로 늘려가는 게 좋음

13:52 ~ 15:48
부하 테스트의 활용

  • 로브나 트레이싱 같은 기능을 사용할 경우 부하 시험을 하면 부하량이 늘어나는 만큼 요금도 많이 늘어남
  • 에러를 계로 해두신다든지 아니면 진짜 필요한 거 말고는 안 나오게 하는 주식으로 설정을 미리 해두시면 좋을 것 같음
  • 외부 시스템을 연계하는 경우에 서비스 할당량을 확인을 해보거나 아니면 무킹을 해서 실제로 리퀘스트는 뜨지 않지만 네트워크가 받아온다는 이를 치고 다음 처리로 넘어갈 수 있도록 하는 개입이 필요함
  • 서브리스에서 부하 테스트를 활용한 사례에 대해서 말씀을 드리겠음

16:17 ~ 19:14
방송국의 스트리밍 서비스

  • 방송국에서 hod라는 스트리밍 서비스를 개발해서 서비스를 하고 있음
  • 방송 자체는 전국적 지명도가 있는 것임
  • rps로 보셔도 무방할 것 같음

19:45 ~ 21:23
앱 싱크의 토털 소비자

  • 앱 싱크의 토털 소비자라는 게 처리하는 데이터에 있고 용량에 따라서 다르기 때문에 일단 캐싱을 하자고 함
  • 기존 시스템에 영향을 안 주는 상태에서 가치가 있어야 되기 때문에 q 신중에 보면 버즈 데이트라고 하는데 스키마를 거지를 해서 부하가 걸리는 부분만 다른 애칭이 있는 포드로 가도록 조정을 함
  • 프론트엔드에서는 머시 pit 세포 도로 이렇게 설계를 설계함

21:50 ~ 24:02
택시 서비스 활성량 완화 신청

  • 택시를 도입하고 나서 서비스의 활성량 완화 신청을 함
  • 데이터를 가지고 결론을 내니까 얘기가 빨랐음
  • 설득이라든지 이런 걸 하기 위해서도 데이터를 가지고 결론을 내는 게 좋은 수단이 될 수도 있음

기억해야 하는 것들

부하테스트를 해야 하는 이유

  1. 비용
  • 사전에 미리 계산하는 것은 현실적으로 어렵다.
  • 비용 할당 태그를 부착하고 하루 부하테스트를 해보는 것이 현실적이다. (pay as you go)
  • 자원 할당을 추가로 요구할 때, 왜 얼마만큼의 근거가 된다.
  1. 문제점을 조기에 발견
  • 의외의 포인트에서 문제를 발견할 수 있음
  1. 최적화 성능 튜닝
  • 예를 들어 Lmabda의 동시성 설정을 어떻게 해야 하는가 등

부하테스트 시 주의해야 하는 것들

  1. incremental하게 시도해라
  2. log level을 꼭 확인하라 (debug면 안된다.)

AWS Distributed Load Testing on AWS

  • 대규모 기반의 로드가 있는 상태에서 소프트웨어 애플리케이션 테스트를 자동화하는 솔루션으로 출시 전에 잠재적 성능 문제를 식별하는 데 도움이 됩니다. 그리고 서버를 프로비저닝하지 않고도 일관된 속도로 트랜잭션 레코드를 생성하여 수천 명의 연결된 사용자를 구축하고 시뮬레이션합니다. 이 솔루션을 사용하여 여러 AWS 리전에서 테스트를 실행할 수도 있습니다.

https://aws.amazon.com/ko/solutions/implementations/distributed-load-testing-on-aws (aws 공식 문서)

https://aws.amazon.com/ko/blogs/korea/how-to-load-test-your-game-on-aws/ (게임 환경에서 부하 테스트)

4. Amazon EventBridge를 활용한 Event-Driven 아키텍쳐 설계 및 활용

강의요약 by 클로바노트

요약
00:06 ~ 03:36
이벤트 드리븐 아키텍처

  • 아마존 이벤트 브리스를 활용한 이벤트 드리븐 아키텍처 설계 및 활용에 대해서 발표를 드릴 리콘스의 박상원이라고 함
  • 이벤트 드리븐 아키텍처가 무엇인지에 대해서 살펴봄
  • 이벤트 드리븐 아키텍처는 이벤트를 활용하여 분리된 서비스를 연결하거나 실행시키는 아키텍처로 마이크로 서비스 기반의 현대 애플리케이션에 자주 활용됨

04:00 ~ 05:45
이벤트 드리븐 아키텍처

  • 이벤트 드리븐 아키텍처는 db가 변동을 하면 키드s을 통해서 람다로 호출이 됨
  • 이벤트 드리븐 아키텍처를 아디메스에서도 구현이 가능함
  • 이벤트 드리븐 아키텍처의 예시를 보여주고 이벤트가 무엇인지에 대해 설명하고 있음

06:13 ~ 07:33
서버러스 구조에 적합한 이벤트 기반 아키텍처

  • 이벤트 기반 아키텍처는 서버러스 구조에 적합한 이유가 여기서 나옴
  • 서버러스 구조는 수십 개 수백 개의 우드가 올라갔다 내려갔다 할 수 있고 그렇게 자유롭게 수량이 변하기 때문에 많은 부하에도 흔들리지 않는 아키텍처가 필요함

07:48 ~ 10:51
이벤트 드리븐 아키텍처

  • 이벤트 드리븐 아키텍처는 크게 세 가지 정도의 구성 요소로 얘기를 할 수 있음
  • 이벤트 소수는 누가 발생 시장인지, 이벤트 대상은 누가 처리할 것인지, 이벤트 라우터는 적재 적소에 라우팅해 주는 역할을 함
  • 이벤트 브리지는 자체 애플리케이션, 통합 사스 애플리케이션 및 aws 서비스에서 생성된 이벤트를 사용하여 이벤트 기반 애플리케이션을 대규모로 손쉽게 구축할 수 있는 서버리스 이벤트 버스임

11:14 ~ 11:54
이벤트의 정의

  • 거의 대부분의 액션이 이벤트로 정의가 되어 있음
  • 이벤트는 이벤트를 처리하기 위한 내용들로 구성이 되어 있음

12:20 ~ 16:05
이벤트 기반 아키텍처

  • 이벤트는 일종의 스캐너로 내가 원하는 이벤트가 걸리면 즉시 반응을 해서 내가 원하는 대상의 서비스에게 던져주는 것임
  • 이벤트 규칙 패턴을 설정하면 스캐너를 설정해서 원하는 이벤트를 잡아다가 스텝 펑션이든 sks든 sns든 이런 것으로 던져주는 것임
  • 이벤트 기반 아키텍처를 구현할 때 로그 기반으로도 이벤트 기반 아키텍처를 구현할 수 있는데 이건 참고임

16:05 ~ 18:17
시트 자동 정지 시스템

  • 라지 이상의 시트가 올라갔을 때 자동으로 정지하고 모든 ec2가 올라간 내용을 기록하는 아키텍처를 보여줌
  • 관리자라면 원하지 않는 시트가 올라가면 자동으로 중지되는 시스템을 활용할 수 있음

18:50 ~ 22:45
이벤트 기반 아키텍처

  • 이벤트 기반 아키텍처를 통해서 모니터링한다든지 대응을 할 수 있음
  • 이벤트 규칙 패턴을 설정해서 대응을 하는 것을 보여드림
  • s3를 업로드하는 비용은 무료이고 트래픽 비용은 무료임

23:04 ~ 26:30
이벤트 강화 방법

  • 이벤트를 강화할 수 있는 방법으로 외부에 힘을 길러서 외부 api를 부른다든지 스텝 펑션을 부른다든지 해서 이벤트를 강화시킨 다음에 강화된 이벤트를 대사에게 전달해 줄 수 있음

26:52 ~ 27:59
다이나모 db로 조회

  • 다이나모 db로 조회를 해서 실제 주문번호라든지 어드레스라든지 이런 것들을 sqs에 담는 게 아니라 다이나모 db에 담아놓고 가져다가 전달을 하는 것임
  • 이렇게 하면 두 가지 이점이 있음
  • 첫 번째는 sqs 혹은 여러 가지 스트림의 용량을 줄일 수가 있음
  • 두 번째는 여러분께서 동쪽으로 이 부분을 바꿀 수 있음

28:18 ~ 32:32
크롯 익스프레션

  • 특정한 시간에 이벤트를 만들 수 있는 기능은 크롯 익스퍼레이션을 사용함
  • 메인 익스프레션은 5분마다 1분마다 더 이상 말할 게 없기 때문에 간단하게 쓰면 됨
  • 클로드 익스프레션은 특정 주기를 표현하기 위한 표현식임
  • 자세한 내용은 생략하고 예제만 보여드림

32:33 ~ 37:07
프론디건 이벤트

  • 프론디건 이벤트는 1분 단위로 주기적으로 호출할 수 있는 서브 미니 이벤트가 처리 가능함
  • 주기적인 이벤트 혹은 주기적인 호출을 하고 싶다면 크론 이벤트를 활용해서 여러 가지 로직들을 처리할 수 있음
  • 서버라든지 이런 곳에다가 넣고 있는 크론 이벤트 주기적인 배치 자 이런 것들을 이런 식으로 여러분께서 처리를 해볼 수가 있음

기억해야 하는 것들

강의 PDF 및 git repository 필요하시면 외부 메일 알려주세요~

Event (명령이 아닌 관찰한 내용이다.)

  • 명령 : 생성 주체가 대상의 행동에 관심을 가지고 회신을 기다림
  • 이벤트: 생성 주체는 대상의 행동에 관심이 없음
  • 예시: 재채기라는 이벤트가 발생했을 때, 사람들이 나를 쳐다본다.

구성 요소 및 특성

  • 구성 요소: 사건의 내용, 사건의 발생 시간 및 발생 주체, 불변성 (과거 생성된 이벤트는 변경될 수 없음)

분산처리 및 확장이 쉬움

  • 차들이 많아지는데 경찰이 모든 차량에 대해 수신호로 처리할 수 있을까?

  • 신호등은 전혀 부하를 받지 않는다. 신호등은 빨강에서 초록으로 바뀔 뿐이다. 그것을 가지고 다른 차량들이 관찰을 해서 통과한다. 즉 차량이 많아져도 부하를 받지 않는다. 쉽게 분산 처리 및 확장할 수 있다.

EDO 여부

  • rdbms에도 이벤트드리븐아키텍쳐가 가능하다. insert, delete,update 등을 스트림으로 전달할 수 있고, db가 변동을 하게 되면 키네시스 등을 통해 lambda를 호출하는 식으로 연결 가능
  • 신규 유저가 인서트되거나, 결제가 이루어지는 그런 이벤트 받아서 알림을 받거나 보낸다든지, 특정 ㅀ직을 실행시키는 식으로 입벤트 드리븐 아키텍처를 구현할 수 있다.

profile
개발자 생존기
NP-Hard 문제를 풀어봅니다.
이전 포스트

(요약) AWS Graviton과 함께하는 계획문제 최적화 애플리케이션 개발

0개의 댓글