AWS COMMUNITY DAY 2023 (서버리스 트랙 다녀온 후기)

행사를 참석하면서 적은 내용들과 제 짧은 느낀점들을 공유하고자 이 글을 작성했습니다. 틀린 내용이 있거나 이슈가 될 수 있는 부분은 언제든 댓글로 지적해주시면 반영하겠습니다. 강의자분들께서 해주신 모든내용을 정확히 기록하진 못했다는 점 참고 부탁드리겠습니다.

 

토요일 오후 1시, 주말을 반납한 열정이 가득한 개발자들의 모임이 시작되었다.

 

개발자로 3년이상을 지내면서 aws 컨퍼런스나 행사들에 참여하고자 하는 열망은 늘 있었지만 실천으로 옮기지 못했다. 우연히 인터넷을 돌다가 행사일정을 발견하여 신청할 수 있는 상황이 만들어지길 바래왔나보다. 나는 'aws' 를 주제로 만들어진 카카오톡 오픈채팅방에 두 곳이나 가입이 되어 있다. 구직을 하면서 기술면접을 보러 갔던 곳 중 한 곳의 개발자분이 알고보니 우리나라 aws 의 나름 권위자셨고  그분에 대해 검색을 하다가 aws 의 커뮤니티가 카카오톡 채팅방을 통해서도 구성되어 있다는 사실을 알게 된 것이다. 결과적으로 그분과 함께 일할 수 는 없게 되었지만, 나름 큰 수확을 얻게 되었다. 이 채팅방들에는 aws 전문가분들부터 뉴비들까지 다양하게 분포되어 있다. 하지만 모두들 하나같이 열정적이고 aws 에 진심이다. 이번 커뮤니티데이도 채팅방덕에 알게 되었고 이른시간에 여유롭게 신청을 할 수 있었다. 마침내 내 인생에서의 첫 aws 행사를 참석할 수 있게 된 것이었다. 혼자가긴 좀 어색해서 개발자 친구를 바로 꼬셨고 함께 참석하게 되었다.

 

모임 참여 QR 코드로 인증을 하면서 위와 같은 모임 굿즈를 받을 수 있었다. 5000원에 굉장히 혜자로운 구성의 굿즈를 받을 수 있었고, 값진 강의들이 더 기대가 되었다. 개발자 전투식량은 위트만점이었다.

 

시작, 기조연설

기조연설은 Donnie Prakoso 님과 Derek Bingham 님이 <Integrating GenAI into Development Workflow> 라는 주제로 진행해주셨다. aws 코리아(아키텍처/데브옵스 트랙)에서 진행을 해주시면서 라이브 영상 송출을 통해 한국지식센터(서버리스 트랙)과 한국타이어빌딩(분석/인공지능 트랙)에서 보게되었는데, 아무래도 현장이 아니다보니 사운드와 몰입도가 아쉽긴했다. 주제와 관련된 다양한 서비스들을 보여주는데 Amazon bedrock 이라는 서비스가 눈에 들어왔다. chat GPT 처럼 질문을 던졌을 때 그에 대한 답을 해주는 기능을 볼 수 있었는데 추후 aws 에 있는 수많은 서비스들과의 좋은 시너지를 낼 수 있지 않을까 하는 기대감이 생겼다. 

 

첫번째, 모던 프론트엔드 개발자가 꼭 알아야할 서버리스 서비스들(윤창현 님)

첫 순서라 떨리실 법도 한데 스타트를 잘 끊어주셨다. 현재 몸담고 계신 회사의 규모가 그리 크지 않아 데브옵스를 온전히 담당하는 동료분이 없으셔서 프론트 개발자임에도 다방면으로 인프라를 구축하고 계신다고 했다. 딥하게 인프라에 관여하기엔 부담스러운 부분이 있어 관리 주도권을 aws 에게 넘길 수 있는 서버리스를 애용하시는 듯 하였다. 그 중 유용하게 사용하고 계신 AWS Amplify 라는 것을 추천해주셨다. 아래와 같이 강의 내용을 정리해보았다.

1. Modern Web Application
   1. 이전에는 단순 스태틱파일을 서버에서 던져주는 CSR 이 성행했었고 서버의 직접적인 성능보다는 네트워크 대역폭이 더 중요했음
   2. 하지만 요새 SSR 이 커지면서 서버의 역할이 굉장히 중요해졌음
   3. Micro Architecture 가 생겨났고 관리 소요가 많아졌음
   4. 여기서 이제 서버리스의 장점들이 부각되기 시작했음
      1. 서버리스는 말그대로 서버가 없는 것이 아니라 추상화되어있는 서버다. 개발자가 구체적인 관리를 할 필요가 없다
         1. 중요한 원칙 4가지
            1. No server management
            2. Flexible scaling
            3. High availability
            4. No idle capacity
   5. Aws amplify?
      1. 대부분의 회사들은 신규서비스 런칭이 많다.
         1. 시장의 반응을 예상하기 어려우며 이에 따라 자원을 사전책정하는게 어려움
         2. 이런 경우에 위 서비스는 장점이 있다고 생각이 됨
         3. 빠르게 풀스택 앱을 만들기에 편함(인증, 디비, nestjs api 등등 제공하고 있는 내부툴들이 많음)
         4. 특히 프론트엔드 개발자들에게는 amplify studio 라는 툴이 굉장히 효율적임
            1. 피그마와의 연동을 통해 프론트엔드 코드를 작성할 수 있는 기능을 가장 추천함
            2. Web UI 를 통해 컴포넌트 작업을 다하고 github 리파지토리를 pull 하듯이 amplify cli 를 통해 명령어를 입력하여 코드를 내려받을 수 있음
            3. 반응성이 뛰어난 웹을 만들어주는 코드가 작성되진 않지만 poc 용으로 빠르게 작성하기엔 굉장히 좋은 서비스임
            4. 디비관리를 할때 admin 권한의 계정을 만들거나 까다로운 작업들이 있는데, amplify studio 자체에서 admin 으로 하여 데이터들을 만들 수 있음(디비를 연동시키는 개념이 아니라 이 자체에 데이터를 저장하는 느낌인 거 같음)
2. 서버리스란?
   1. 최대 사용 10GB, 최대 유지시간 15분
   2. 단점: context 를 유지할 수 없다보니 디비커넥션을 유지한다거나 하기 힘들다는 문제가 있음
   3. 콜드 스타트는 단점 중 하나임
   4. 사용하는 언어와 코드에 따라 콜드스타트 시간이 다름(특징을 충분히 비교하고 사용하는게 좋음)
      1. 5분마다 계속 찔러주면서 콜드스타트를 방지하는게 보편적인 방법
   5. 람다는 요청이 발생한시점에 인스턴스를 기동하고 
      1. 코드 다운로드
      2. Start new container
      3. 위 두가지를 다 하는게 cold start
   6. 스냅스타트가 뭘까?(거의 자바를 위한 솔루션?)
      1. 콜드스타트를 없애줌(완전 없애주는건지 자세힌 모르겠음)
      2. 이니시에이션 시간이 6.3초에서 142 ms 로 스프링 애플리케이션에 대한 이닛을 줄일 수 있음
      3. 최대 단점은 이건 자바 전용임(노드js 는 이미 콜드스타트 자체가 짧기때문에 없음)
      4. 유의사항
         1. 호스트 이름을 고유한 실행 환경 식별자로 사용하지 않음
         2. 대규모 함수 호출에서 가장 효과적
         3. 초기화 코드에서 시작 지연 시간에 영향을 미치는 클래스로드
         4. 캐싱된 스냅샷은 14일 동안 사용하지 않으면 제거 됨
3. API Gateway
   1. MSA 가 부각되면서 동시에 부각되는 서비스
   2. RESTful API 나 웹소켓 API 를 효율적으로 관리하는데 장점이 있음
   3. 프록시 역할을함
   4. 역할
      1. 인증/인가
      2. 라우팅/로드밸런싱
      3. 서비스 디스커버리
         1. 내가 원하는 서비스의 IP 등 여러 정보들을 쉽게 알 수 있도록 도와주는 서비스(?: 좀더 알아봐야할듯)
      4. Pattern
         1. API Gateway Pattern 이라는 것이 있음

 

두번째, 쌤(SAM)! 도와주세요!(이태현 님)

영상 업로드라는 기능을 서버리스와 S3 의 조합으로 푸는 것을 컨텐츠로 강의를 진행해주셨다. 인상깊었던 부분은 해당 컨텐츠를 로컬로 테스트하기 위해 정말 AWS Lambda부터 S3 까지 모두 로컬로 구현을 하여 그 동작과정을 디테일하게 설명해주셨다는 것이다. 이 부분만큼은 누구보다 잘 설명할 수 있을 것 같은 자신감으로 강의를 해주셔서 몰입해서 들을 수 있었다. 내용이 다소 많아 진행이 빨랐음에도 불구하고 설명을 너무 잘해주셔서 이해가 잘됐다. 아래와 같이 강의내용을 정리해보았다.

1. 개요
   1. Lambda함수를 어떻게 하면 로컬에서 테스트해볼 수 있을까?
   2. 영상을 업로드하고 이 부분 일부를 떼내어 썸네일로 업로드를 하고 싶다. 여기에 Lambda를 적용해보고 싶다
   3. API Gateway -> 영상업로드(Lambda) -> S3 -> Lambda -> S3 (소스코드도 한곳에서 관리하고 이를 로컬에서 테스트해보고 싶다)
2. 목표
   1. AWS SAM 이 무엇인지 직접 템플릿 yaml 파일을 살펴보며 이해
   2. 로컬에서 API Gateway 를 구동해보며, zip 패키지 유형의 내부작동 이해
   3. AWS API Gateway 를 로컬에서 사용할 때 유의해야할 점 이해
   4. Localstack 을 사용하여 로컬에서 AWS S3 구축하는 방법 이해
   5. 외 4가지 더(자세히 적지 못했음..)
3. 프로젝트 개요
   1. Gateway 의 역할을 SAM 이 하고 / S3 의 대체를 Localstack S3 가 하게 됨
      1. API Gateway / S3 => (local) Sam(파이썬 플라스크 코드) / Localstack
   2. SAM 이란?
      1. AWS Serverless Application Model 
      2. CloudFormation 이란?
         1. IaC(infrastructure as a code)
         2. yaml 파일을 이용
      3. 클라우드포메이션과 같은 IaC but, 서버리스를 관리하는데 적합한 서비스
      4. 클라우드 포메이션을 활용하여 여러 환경들을 서버리스로 올리는데 도움을 주는 서비스로 이해하자
      5. 문법이 클라우드포메이션과 굉장히 흡사함
         1. 위 로컬 프로젝트에 사용될 예시 
            1. 런타임: 파이썬
            2. 패키지: zip(default)
            3. codeUri 및 Handler : Lambda함수의 엔드포인트
   3. Docker 를 통해 S3-Local 을 올려보자
      1. docker-compose.yaml 을 이용해서 Localstack을 올림
      2. 이는 S3 자체를 올리는 거라 버킷은 추가적인 작업을 통해 별도로 만들어야 함
   4. 영상을 직접 업로드하면 안되나? 왜 presigned url 을 사용하지?
      1. Lambda는 무조건 6mb 보다 작은 페이로드를 전달해야하기때문에 큰파일의 경우는 무조건 presigned url 을 이용해야함
   5. SAM build 명령을 통해 zip 패키지 유형의 영상 업로드 어플리케이션을 빌드
      1. SAM 은 RIE(Runtime Interface Emulator) 를 생성해줌(얘가 사실상 Lambda 그 자체의 역할)
         1. 실제 소스코드와의 내부 통신을 하는 역할
         2. API gateway(SAM Flask Framework 를 이용한 gateway 모방) -> Lambda 서비스(RIE) -> Runtime API(RIC: Runtime Interface Client) -> 내부소스코드(도커 볼륨 마운트. 도커에 올라가있는 건 결국 소스코드 뿐?)
      2. RIE 에서 페이로드 사이즈를 관리하는 방법
         1. 리밋리더를 통해 페이로드를 자르면서 전달
         2. 오류가 발생하는 부분은 RIC 에서 오류가 발생함(일부분의 페이로드만 전달이 되었기 때문에)
         3. 업로드 테스트에서 unmarshal(파이썬에서 사용하는 역직렬화 관련된 에러) 오류가 발생할 경우 페이로드 크기 의심 필요
      3. 파일을 정확히 6MB 보내면 문제가 생기지 않을까?
         1. 내부적으로 Base64encoding 을 하게되면서 6bit 단위로 잘라 8bit 의 ascii 로 변환하기 때문에 사이즈가 오버가 됨(굉장히 디테일…)

 

쉬어가기, AWS 퀴즈쇼

강의 두개를 듣고 쉬어가는 시간으로 준비해주신 퀴즈쇼가 진행됐다. 난이도는 평이한듯 어려웠다.(내기준ㅠ) 직접 손들며 답을 말하는 식의 퀴즈쇼였다면 참여에 부담을 느끼는 분들이 많았을 텐데, 웹서비스를 이용하여 각자 노트북또는 핸드폰으로 참여할 수 있어 참여율이 높고 편안한 분위기로 진행되었다. 이런 부분에서 정말 세심하게 신경을 쓰셨다고 생각했고 행사를 준비하신 모든 분들께 다시 한번 감사할 수 있었다.

 

세번째, 서버리스에서 부하 테스트를 하는 목적과 실제 모범 사례 소개(김선우 님)

일본에서 서버리스를 전문적으로 컨설팅해주고 적용해주는 회사에서 중요한 역할을 하고 계신 분이셨다. 서버리스를 이용했을 때 낼 수 있는 퍼포먼스를 직접 이루신 성과를 통해 설명해주셔서 몰입해서 들을 수 있었다. 일본에 오랫동안 계셨지만 진한 경상도 사투리는 큰 매력포인트였다. 아래와 같이 강의내용을 정리해보았다.

1. 부하테스트란 무엇인가?
   1. 넓은 범주로 부하테스트라고 하지만 세부적으로 종류가 나뉘어 있음
      1. 로드 테스팅(높은 부하가 걸려있는 상태로 성능을 검증하는 테스트)
      2. 스트레스 테스팅(시스템이 처리할 수 있는 한계)
      3. 스파이크 테스팅(요청이 단시간 급격하게)
      4. Soak 테스팅(장시간 가동 시킬 경우에도 안정적인 성능과 원할한 접속이 유지되는 테스트)
   2. 왜 해야하는데?
      1. 시스템 아키텍처의 한계를 테스트
      2. 프로덕션 릴리스 이후의 시나리오 예행연습
      3. 트래픽이 큰 워크로드의 성능 검증
2. 서버리스 워크로드에 부하 테스트가 필요한 이유
   1. 서버리스의 비용 미리 파악
      1. 주로 사용량(실행단위)의 종량제 요금
      2. 인스턴스나 컨테이너를 베이스로 하는 다른 구성의 아케텍처에 비해, 요금계산이 복잡하여 릴리스 이후 운용단계에서 얼마가 들지 견적이 어려움
      3. 실제로 비용을 발생시켜서 확인하는 방법
         1. 1일 정도의 사용량을 상정하고 부하를 걸어보고 그것을 기준으로 기간에 대한 비용을 계산해보기
   2. 서비스 할당량의 추가 요청을 위한 근거 수집
      1. 병목현상, 짚어내기 어려운 문제점을 조기에 발견
   3. 최적화와 성능 튜닝
      1. 같은 구성이라도 예를 들면 AWS Lambda 의 실행에도 다양한 설정이 존재
      2. 부하테스트의 결과를 보고 튜닝 하는 것이 효율적이며 효과적일 수 있음
      3. AWS Lambda 에서 throttling 이 발생한다면?
         1. AWS Lambda에서의 버스트 동시성을 이해하기(일종의 AWS에서 걸어둔 리미트인데 갱신이 안되는 리미트라 관리를 철저하게 해야하는(?) 그런느낌?)
3. 부하 테스트를 하기 위한 툴과 활용법
   1. 시험 툴의 종류
      1. Apache JMeter
      2. Serverless-artilery
      3. LOCUST
   2. 시험툴의 기본적인 구성
      1. 부하를 주기 위한 workers 는 설정에 따라 클러스터를 생성하여 진행
      2. 부하 테스트 또한 풀 서버리스 구성으로 대응 가능
   3. 부하 시험툴의 상세한 구성의 예
      1. http 뿐만 아니라 Mqtt 도 지원
   4. Distributed Load Testing on AWS(추천)
      1. 공식 웹사이트에서 공유되는 클라우드포메이션 템플릿을 이용하여 손쉽게 구축 가능
      2. 도큐먼트 풍부함
      3. 시나리오 타입 선택 항목
         1. Single http endpoint
         2. JMeter
      4. 테스트 결과의 서머리와 RPS 등의 리포트를 Web UI 에서 바로 확인할 수 있게 출력 됨
4. 주의사항
   1. 일반적인 테스트에서는 갑자기 바로 대량의 부하를 걸지 않을 것
      1. 100, 1000, 5000, 10000 클라이언트 수와 같이 점진적으로 증가시키면서 진행
   2. 로그 및 트레이싱 등, 부하시험에 의해 요금이 늘어갈 가능성이 있는 부분에 유의(매우 중요)
      1. 예를 들어 로그 debug 레벨로 설정한 채 테스트하지 않을 것!
   3. 연계하는 시스템이나 다른 시스템에 영향을 주는 경우, 사전에 Mock 으로 대체하는 등의 대응이 필요함
   4. 네트워크 대역의 관점에서 사전신청이 필요한 케이스가 있기도 하기 때문에 미리 도큐먼트를 확인해보길 권장
5. 서버리스에서 부하 테스트를 활용한 사례
   1. 전국적 지명도를 가진 인기방송의 온디맨드 영상 공개
      1. 외주 없이 방송사 내부 인력을 중심으로 풀 서버리스 구성의 개발을 진행하여 서비스 중
      2. 전국적인 지명도를 가진 시리즈 신작의 첫 에피소드가 한날 한시에 공개되어야 했음
      3. 공개 시간에 딱 맞춰 5000 tps 까지의 스파이크를 벼텨야 하는 요구조건
   2. 문제진단
      1. Appsync 사용 및 Graphql 에 최적화된 Dynamodb 로 인해 스케일이 힘들었던 구조
      2. 미리 진행했던 구성리뷰와 적은양의 부하테스트로 실현가능성을 검토
      3. Appsync 에서는 복잡한 데이터 구조로 인해 몇십번의 쿼리만으로 컴퓨팅 토큰 소모량의 서비스 할당량에 걸리고, Dynamodb는 Hot-partitioning 으로 인해 성능이 충분히 나오지 않았던 상태
   3. 문제 해결을 위한 구성 검토
      1. 외부 캐시 서비스(momento) 를 사용하여 AWS 내의 부하를 줄이고, AWS Appsync 의 merged api 를 사용하여 기존 구성 변경을 최소화
      2. 데이터를 압축 및 chunk 로 분리하여 비동기적인 송수신으로 성능향상
      3. 두가지 설계안을 검토, 팀내에서 의논하여 AWS 및 외부 캐쉬 서비스의 서비스 할당량을 추가 신청을 검토
   4. 서비스 할댱량 추가를 위한 자료 작성
      1. 각 구성의 부하 시험을 실행하고 그 결과 데이터에 기반한 근거 및 자료를 들고 서비스 할댱량 추가를 요청(Momento 에 대해서도 추가 요청)
      2. 구체적으로는 캐쉬의 도입으로 Appsync 의 부하를 획기적으로 줄였으며, 다이나모디비 또한 감당 가능한 수준으로 성능이 회복됨
      3. 그럼에도 불구하고 Appsync 의 Token consumed 는 일부 다른 기능에서 추가가 필요했기 때문에, 필요한 양을 정확히 파악하여 신청하고 승인됨
   5. 본 공개를 위한 부하 테스트 진행 및 결과
      1. 테스트 환경을 세팅하고 각종 서비스 할당량이 추가된 상태에서 부하 테스트를 진행
      2. 목표했던 5000tps 의 스파이크 발생시에도 선능 손실 및 에러 없이 버티는 상태를 확인
      3. 실제 신작 공개 후 아무런 문제 없이 원할한 시청 및 서비스 이용이 가능

 

네번째, Amazon Eventbridge를 활용한 Event-Driven 아키텍처 설계 및 활용

사실 이번 커뮤니티는 이분 덕분에 참여를 했다고해도 과언이 아니다. 내가 참여하고 있는 AWS 오픈채팅방 중 한곳에 Host 이시고, AWS 강의실이라는 유튜브 채널을 운영하고 계신 서버리스의 권위자시다. 채널에 게시된 강의들을 봐도 말씀을 워낙 조리있게 잘해주시고 예시도 적절하게 들어주시는 경우가 많아 도움을 많이 받고 있었다. 이런 경험들을 기반으로 이번 강의 또한 퀄리티가 높은 강의일 것이라고 생각했었고, 예상은 빗나가지 않았다. 어찌보면 서버리스라는 카테고리에서 실무에서 적용하기 용이한 가장 적합한 주제를 선정해주시지 않았나 라는 생각을 하게 되었다. 또한 간단한 Live Demo 시연을 통해서 이해를 도와주셨다. 강의자료를 제공해주신다고 사전에 말씀해주신덕에 맘편히 메모를 멈추고 몰입을 해서 들을 수 있어 감사했다. 아래와 같이 강의내용을 정리해보았다.

 

1. Event-Driven 아키텍처 및 Event 소개
   1. Event-Driven 아키텍처란?
      1. Event-Driven 아키텍처는 이벤트를 활용하여 분리된 서비스를 연결하거나 실행시키는 아키텍처로 마이크로 서비스 기반의 현대 어플리케이션에 자주 활용됨 - AWS -
      2. AWS Lambda란?
         1. 서버를 프로비저닝 또는 관리하지 않고도 실제로 모든 유형의 애플리케이션 또는 백엔드 서비스에 대한 코드를 실행할 수 있는 이벤트 중심의 서버리스 컴퓨팅 서비스
      3. 이벤트란?
         1. 명령이 아닌 관찰한 내용
            1. 명령: 생성 주체가 대상에 행동에 대한 관심을 가지고 회신을 기다림
            2. 이벤트: 생성 주체는 대상의 행동에 관심이 없음(ex. 신호등의 불이 변경되는 경우 신호등은 대상의 행동에 관심이 없음)
               1. AWS 의 이벤트는 JSON 형태로 돌아다님
         2. 구성요소 및 특징
            1. 구성 요소
               1. 사건의 내용
               2. 사건의 발생 시간 및 주체
               3. 불변성: 과거의 생성된 이벤트는 변경될 수 없음을 보장
            2. 분산 처리 및 확장이 쉬움
2. Amazon EventBridge
   1. Amazon EventBridge란?
      1. 자체 애플리케이션, 통합 SaaS 애플리케이션 및 AWS 서비스에서 생성된 이벤트를 사용하여 이벤트 기반 애플리케이션을 대규모로 손쉽게 구축할 수 있는 서버리스 이벤트 버스
      2. AWS의 이벤트의 처리를 담당하는 서버리스 이벤트 라우팅 서비스
         1. 다양한 AWS 서비스에서 생성된 서비스를 라우팅
         2. 혹은 주기적으로 이벤트를 발생시켜서 전달(트리거)
      3. 세 가지 활용 방법
         1. 이벤트 라우팅
            1. 이벤트 버스
            2. 이벤트 파이프
         2. 스케쥴 기반 이벤트 생성 
   2. 이벤트 버스 및 규칙
      1. 이벤트 버스
         1. AWS 및 다른 소스에서 발생한 이벤트를 받고 전달하는 라우터
         2. 많은 소스에서 이벤트를 받아 많은 곳에서 처리하는 아키텍처(N:N)에 활용
         3. 규칙(Rule)을 활용해서 이벤트를 선별하여 대상에 전달
            1. 규칙(Rule): 일종의 필터 -> 이벤트 패턴으로 이벤트 선별 후 원하는 서비스에 전달
            2. 주요 전달 대상
               1. Custom API
               2. API Gateway
               3. CodePipeline
               4. SQS
               5. Lambda
               6. SNS
               7. ...
         4. AWS API Call via CloudTrail
            1. 미리 지정된 Event 이외에 상황을 처리할 때 사용
            2. CloudTrail의 로그를 통해 이벤트를 발생시키는 방법
            3. CloudTrail이 활성화 되어있어야 사용 가능
   3. 파이프
      1. 이벤트 소스와 대상을 포인트-포인트로 연결하는 서비스
         1. 이벤트 전달 중 외부 연결(API, Lambda, API Gateway, StepFunctions)를 통해 내용 추가 가능
         2. 예: SQS 메시지에서 아이디로 인벤토리 조회 후 StepFunctions 전달
      2. 다양한 소스와 연동 가능
         1. DynamoDB 스트림
         2. Kinesis 스트림
         3. Amazon MQ broker
         4. MSK 스트림
         5. SQS
         6. 자체 관리 Apache 카프카 스트림
      3. 파이프 기타 활용
         1. 키네시스 스트림 데이터 나누기
            1. 하나의 스트림을 패턴에 따라 분산
            2. 개별로 처리 가능
         2. Claim Check 패턴
            1. SQS에는 idx만 저장 후 실제 페이로드는 DDB에 저장
            2. 이벤트 처리 시점에 DDB에서 실제 데이터 조회 후 전달
            3. 장점
               1. SQS 이벤트 메시지 경량화 가능
               2. 이벤트 내용 동적으로 변경 가능
   4. Cron 규칙(스케쥴 규칙)
      1. 일정 주기, 혹은 특정 시간에 이벤트를 발생시키는 규칙
      2. 두 가지 모드
         1. 일정 주기 - 예: 매 20분마다, 매 1분마다
            1. Rate Expression을 활용
               1. 일정 주기를 표시하는 표현식
               2. 예: cron("5 minutes"): 매 5분마다
         2. 특정 시간 - 예: 매달 5일 오후 2시 30분마다 / 월, 수, 금 오전 1시마다
            1. Cron Expression을 활용
               1. 특정 시간의 주기를 표현하기 위한 표현식
               2. 모든 Cron Expression 은 UTC 기준
               3. 1분 단위가 최소 단위
      3. Sub Minute 이벤트 처리
         1. SQS 의 DelaySeconds를 활용
         2. DelaySeconds: x초 후에 메시지 처리 가능
            1. 예: 매 5초마다 이벤트를 발생시키고 싶다면,
            2. 1분 마다 0,5,10,15,...,55 초 딜레이를 가진 메시지 12개를 Queue에 넣어 처리

 

내용을 좀 더 친절하게 정리해서 포스팅을 하고 싶지만 워낙 내용이 방대하기도 했고, 자칫 잘못된 이해로 더 잘못된 해석이 들어간 전달이 될까봐 급하게 적은 내용들을 맞춤법만 정리해서 올리기로 했다. 정말 배울내용이 많은 알찬 커뮤니티데이였고, 꾸준히 이런 행사일정을 눈여겨보면서 참여해야겠다.

 

다시한번 행사를 준비하느라 고생하신 모든 분들께 감사의 말씀을 올린다.