그래프 시작점을 x인덱스 한 칸만 옮기기 삽질

작업 이유: 그래프 시작점이 y축에 붙어있어서 심미적으로 불편했음

시작점이 x인덱스 한 칸만 옮기면 보기 딱 좋을 것 같았음

생각한 방법:

x인덱스 맨 앞에 임시 인덱스를 만들고, 라이브러리의 특정 인덱스 숨기기 파라미터를 이용해 해당 값만 안보이게 하고(칸은 그대로 남아있다) x인덱스를 오른쪽으로 한 칸씩 미는 방법을 생각했다.

예상 문제점:

요일별로 데이터 개수를 집계하는 방식이기에 개수집계함수도 손봐야한다.(기존은 요일 7개임을 이용했기 때문, 맨 처음에는 데이터가 안들어가도록 처리를 해줘야 할 것이다. Date객체를 이용하여 getDay를 이용하는 것이기에 따로 처리를 해줘야한다.

진행:

커스텀을 위해 차트 라이브러리의 코드를 일일이 살펴 어떤 패러미터가 있는지 살폈다. visual studio에서, 컴포넌트에 ctrl+클릭을 하면 해당 컴포넌트의 코드가 열린다. 이 코드에 컴포넌트의 파라미터들과 주석으로 설명들이 있었다.

getDay가 요일을 숫자형식으로 반환(0:일요일 ~ 6: 토요일)하니까, 게다가 맨 앞의 라벨을 임시라벨로 할 것이기에 getDay의 반환값에 1만 더해주면 되었다.

결과: 성공!

성장한 점:

라이브러리의 패러미터들을 가지고 라이브러리 컴포넌트에 원하는 옵션들을 설정할 수 있게 되었다.

보통 라이브러리를 사용하면 제시해주는 예시코드를 가져와서 데이터값만 바꾸거나, 색깔만 바꿨었는데, x축, y출 항목 라벨의 위치, 선의 형태 및 스타일 등등 세부적인 옵션들도 파헤쳐봐서 개발중인 앱의 스타일과 가장 비슷하고 적합한 스타일로 바꾼 적은 처음이었다.

라이브러리에 어떤 옵션들이 있고, 이 중 필요한 옵션은 뭐고 어떻게 바꿔야하는지 파헤쳐보는 작업은 어렵기도 했지만, 그만큼 코드를 자세하게 뜯어볼 수 있고 더 나아가서 뜯어본 코드를 내 입맛대로 다시 맞춰볼 수 있는 능력을 키운 것 같아서 뿌듯하다.

개선해보고 싶은 것

위의 그래프 그림을 보면 알겠지만, 그래프 선이 렌더링이 급격히 꺾이는 부분에서 그래프의 꼭짓점이 기준점과 맞지 않아 또 심미적 불편함(...)이 있다. 이런 그래픽적인 렌더링 부분을 약간의 곡선을 주고 그래프의 꺾이는 부분이 x축과 딱 맞도록 해서 더 이쁘게 만들어보고 싶다는 생각이 들었다.

약 2개월간의 클라우드 교육이 끝나고, 그 때의 풀타임(9시~6시)싸이클을 이어나가기 위해 잡았던 사후 목표가 바로 SAA였다.

AWS SAA 시험 접수 후기

내 시험 준비를 요약하면 다음과 같다.

요약

• 공부 기간: 약 10일(3월 4일 ~ 15일)
• 베이스: 기본적인 3Tier(Web, WAS, DB)솔루션 설계 가능, Multi-AZ, EKS, CloudFront, S3 등 기본적인 클라우드 인프라 및 AWS 서비스 개념들은 알고 있었음
• 참고 자료: Udemy 강좌 + 덤프 약 150문제
• 시험 방식: 오프라인(센터 방문 시험)

시험 수준 확인하기

우선 미리 합격한 사람들의 후기를 확인하면서 어떤 베이스에서 얼마만큼의 준비가 필요한지를 많이 살펴봤다. 충분히 베이스가 있으면 3일(...)만에 합격하신 분도 계시고, 노베이스에서 2달정도 걸려서 합격하신 분도 있었다.

나는 AWS에서 많이 쓰이는 S3, EC2 등은 알고 있고 실제 인프라 프로젝트를 하면서 써보기도 했으므로, 한 2~3주정도 필요할 것 같다고 가정했고, 일단 기출 문제를 우선 풀어보면서 현재 내 실력을 체크해봤다.

덤프(기출) 풀기

덤프 예제 사이트

AWS시험에서의 기출문제는 덤프라고 부르던데, 아무튼 이 덤프를 검색했을 때 가장 먼저, 그리고 제일 많이 나왔던 사이트가 바로 ExamTopics였다.

https://www.examtopics.com/exams/amazon/aws-certified-solutions-architect-associate-saa-c03/

좋은점

• 사람들이 어느 선택지가 맞는지 토론내용도 나와있어 해당 문제의 답이 왜 그것인지 같이 알 수 있어서 좋다.
• 문제 수가 많고, 실제 기출문제랑 비슷한 느낌이다.

아쉬운점

• 처음에 문제를 풀려고 하면 6문제정도 보여준 뒤 결제를 하거나 CAPTCHA를 하라고 해서 불편함이 있다. 로봇이 춤추면서 사람인증 하라한다.로봇 네이놈
• 사이트 자체가 영어로 되어있어서, 번역기를 돌려가며 풀어야 한다.

한국어 덤프 예제 블로그

그래서 내가 먼저 선택한 기출문제 자료는 바로 다음 블로그였다.

https://blog.naver.com/PostView.naver?blogId=gam_jaong&logNo=222909260062&parentCategoryNo=&categoryNo=18&viewDate=&isShowPopularPosts=false&from=postList

SAA-C03의 한국어덤프가 약 150문제정도 풀이와 함께 업로드되어있었다.

SAA시험은 한국어를 지원해주는지라 한국어로 문제를 푸는 것이 실전 연습에 더 좋다고 생각했고, 답이랑 풀이까지 나와있어서 공부하기 딱 좋았다.

첫 날에는 30문제 정도를 풀면서 SAA문제가 어떤 식으로 나오는지 대충 감을 잡았다. CloudFront나 S3등 이미 써본 서비스는 내용을 잘 알기에 정답을 바로 맞출 수 있었지만, 다뤄보지않은 SQS같은 서비스나 선택지 중에서도 모르는 게 나오면 틀리곤 했었다.

풀어야 할 문제도 많은데 모르는 개념을 놔둔채로 덤프만 돌렸다가는 더 효율이 낮을 것 같아서, SAA강의로 유명한 Udemy강좌와 덤프를 병행했다.

Udemy SAA 강좌

지금 SAA에서 가장 유명한 강의를 꼽으라면 Udemy의 강의가 아닐까 싶다.

https://www.udemy.com/course/best-aws-certified-solutions-architect-associate/

강의 사이트 접속하면 99,000원이라는 비싼 가격이지만, 사이트 접속 시 페이지 위에 뜨는 신규 수강생 혜택으로 결제하면 17,000원정도로 매우 싸져서 부담도 크게 없어진다.

이 Udemy강좌는 SAA에서 다루는 AWS서비스의 개념, 옵션들에 대한 이론을 설명해주고 실제 AWS 콘솔에서 실습하는 모습까지 다루어주며 아예 노베이스인 사람들도 이 강좌를 들으면 감이 많이 잡힐 정도로 좋은 구성이다.

AWS의 각 서비스마다 기본 설명 => 심화 단원으로 SAA레벨에서 필요한 수준의 깊이로 다뤄줘서 좋다.

실제 나도 덤프 풀이 시 내용 이해가 약간 부족했던 IAM부분의 Organigations 등등을 이 강좌를 보고 다시 학습해서 보완했고, 안써본 서비스인 SQS나 SNS에 대한 내용은 이 강좌를 보고 학습할 수 있었다.

오프라인 시험(Person VUE)

대망의 시험날짜가 되어 예약했던 Person VUE시험장에 갔다. AWS오프라인 시험 예약 방법

시험 예약 시 시간은 9am - 12am으로 3시간으로 되어있는데, 아마 이 시간 안에 시험장에 도착해서 SAA시험을 끝내면 되는 것 같다. 실제 SAA시험은 130분(연장 시 160분)이기 때문에, 즉 9시보다 조금 늦게 가도 괜찮다는 것!

나는 내 책상을 치우고 시험 끝나면 다시 옮기고 하는 과정이 번거로워서 깔끔하게 오프라인 시험장으로 선택했었다.

오프라인 시험 과정

시험장에 가면 프론트 데스크에 SAA를 보러 왔다고 말하면, 서류를 주신다. 해당 서류에 응시할 시험명과, 이것 저것 쓰면 시험장으로 안내해주신다.

시험장 앞에서는 가방, 외투를 사물함에 넣고, 직원의 안내에 따라 옷 주머니, 손목, 발목을 확인하여 반입금지 물품이 없는지 확인한다. 그 후 시험장 시험장 예약 리스트 문서에서 내 이름에 해당하는 곳에 입실 시간을 쓰고, 직원 안내를 받아 시험장 안으로 들어간다.

시험장 안은 학교 컴퓨터실마냥 독서실책상같은 양옆 가림막이 있는 책상이 줄지어있고 각 책상에 컴퓨터들이 한 대씩 있는 구조인데, 직원이 안내해준 자리로 가면 SAA를 보는 화면이 띄워져있다.

컴퓨터들을 잘 볼 수 있게 시험장 벽은 유리로 되어있고 밖에서 감독관이 감시하는 형태로 되어있었다.

자리에 앉고 안내가 끝나면 바로 시험 시작! 인데,,, 와... SAA시험창 UI가,,, 윈도우 XP를 보는 줄 알았다.(어릴 때가 생각나는 정겨운 폰트와 화질(?))

폰트와 배경 색은 바꿀 수 있지만, 오히려 바꾸느니만 못하기에 기본값으로 했다.

그렇게 65문제정도를 다 풀면 설문지가 나온다. 난이도는 어땠는지 등등,,, 이 설문지까지 모두 답하면 시험은 끝이다.

나는 문제를 꼼꼼하게 보고 검토하느라 시험시간 130분 중 100분이 걸렸던 것 같고, 종료시간보다 빨리 끝나면 손을 들면 직원이 와서 같이 밖으로 안내해준다.

시험장 입장 직전 입실 시간을 썼던 종이에 퇴실 시간을 쓰면, 완전 끝이다. 이제 사물함에 짐 찾아서 집에 가면 된다.

결과 발표

금요일 아침 9시정도에 응시했던 시험인데, 토요일 새벽 1시 정도에 갑자기 메일이 날아온다. 만약 합격이라면 제목에서부터 Congratulations로 시작하므로, 제목먼저 보고 바로 기뻐했다.

이 메일이 오면 SAA에 합격했다는 것이고, 한 3일 정도 뒤에 SAA뱃지를 받으라는 메일이 추가로 왔다.

AWS에서는 Credly를 이용해서 보유한 자격증을 이쁜 뱃지 형태로 보여줄 수 있다.

준비 중에 다른 곳에 크게 신경 써야 할 일이 있어서 생각보다는 공부를 많이 못한 지라 불합격하면 어쩌나 했는데, 다행히 합격 커트라인은 넘어서 다행이었다..!

합격 포인트

나름 베이스가 있었다고는 하지만, 그래도 10일정도 공부해서 합격할 수 있었던 포인트들을 정리하자면 다음과 같다.

이론 + 덤프 병행

이미 AWS서비스를 요구사항별로 능숙하게 사용할 수 있다면 덤프만 풀면서 문제가 어떻게 나오는지만 봐도 되겠지만, 그렇지 않고 아직 사용하지 않은 서비스가 있다거나 자세히는 모른다면, 꼭 이론강좌와 덤프를 병행하길 바란다.

이론 학습 없이 덤프만 풀면서 개념을 외우기에는 AWS의 서비스들도 많고, 여러 특성이나 옵션들도 많아서 그 많은 문제를 깡그리 외우지 않는 한 힘들다.

Udemy강의와 같이 이론을 먼저 잡고 덤프를 풀어야 효율이 더 좋고, 추후 덤프에서 보지 못했던 문제를 보더라도 이론이 받쳐주니 이를 기반으로 문제를 풀 수 있다.

덤프는 꼭 풀어보기

이론과 덤프 중에서 더 중요한 것을 고르라면 덤프라고 생각한다.

실전 문제에 가까운 덤프를 풀어보면서 문제가 어떻게 나오는지 감을 잡을 수 있다.

이론을 잘 공부한다고 해도, 문제가 어떻게 나오는 지 알아야 대비도 되고, 문제를 풀어보면서 배운 이론이 좀 더 잘 기억되기 때문에 덤프는 꼭 풀어보는 게 좋은 것 같다.

문제에서 요구하는 포인트에 집중할 것

SAA의 경우 문제를 보면 비용 효율적인 측면에서나 솔루션은 운영 복잡성을 최소화해야 합니다등등의 표현이 나온다. 즉 선택지만 보면 다 맞는 것 같다고 이 문제에서 등장하는 요구사항에 따라 답이 달라지게 되는 것이다.

이게 중요한 것이, 솔루션 아키텍트는 결국 고객이 원하는 요구사항에 최적화된 솔루션을 설계해주어야 하므로, 고객이 최소화된 운영 복잡성을 요구했는데 내 맘대로 성능은 좋은데 운영 복잡성이 높은 솔루션을 설계해준다면 그건 꽝이라는 것이다.

이처럼 같은 솔루션이라도 요구사항이 무엇인지에 따라 이 솔루션의 적합한지, 덜 적합한지가 나뉘게 되는 것이다.

SAA에서도 문제에서 요구사항들을 명시해주는 편이기에, 문제를 풀 때 이 요구사항을 체크해서 이에 제일 적합한선택지를 골라야 한다.

마치며

좋은 후기들과 좋은 자료들 덕분에 빠른 시간 안에 공부해서 SAA를 합격할 수 있었던 것 같다! 이 글도 누군가에게는 도움이 되길 바라며 내가 준비했던 내용들을 담아보았다.

클라우드 교육때의 사이클을 이어가서 SAA합격을 이루어낸 것처럼, 앞으로도 이 풀타임 루틴을 계속 이어나가서 의미있는 활동들을 계속 이어나가야 겠다.

클라우드에 대해서 더 공부할 수 있어 좋았고, 합격이라는 유의미한 기록도 남겨서 뿌듯했던 경험이었다.

약 2개월간의 클라우드 교육이 끝나고, 그 때의 풀타임(9시~6시)싸이클을 이어나가기 위해 잡았던 사후 목표가 바로 SAA였다.

내 시험 후기를 요약하자면 다음과 같다.

요약

• 공부 기간: 약 10일(3월 4일 ~ 15일)
• 베이스: 기본적인 3Tier(Web, WAS, DB)솔루션 설계 가능, Multi-AZ, EKS, CloudFront, S3 등 기본적인 클라우드 인프라 및 AWS 서비스 개념들은 알고 있었음
• 참고 자료: Udemy 강좌 + 덤프 약 150문제
• 시험 방식: 오프라인(센터 방문 시험)

시험 등록

우선 날짜가 정해져있어야 공부할 동력도 더 생길테니, 우선 시험부터 예약했다.

시험 등록은 아래 AWS Certification으로 접속해서 로그인하고, 접수할 수 있었다. https://www.aws.training/Certification 로그인은 기존 AWS계정이 있으면 그걸로 로그인할 수 있었던 것 같지만, 나는 이전 과금 청산할 때 깔끔하게 하고싶어서 계정을 탈퇴했던지라, 다시 회원가입하고 로그인해줬다.

로그인하면 CertMetrics라는 사이트에서 시험 예약을 진행할 수 있다.

AWS의 여러 자격증들 중 SAA-C03에 해당하는 녀석을 클릭해주면 된다. 시험을 처음 등록하는 거면 Autorize라는 버튼이 있어서, 이녀석을 클릭만 해주면 상태가 Autorized로 바뀌면서 시험 예약이 가능해진다.

SCHEDULE버튼을 누르면 본격적으로 시험 일정 예약 사이트로 접속된다.

시험 방식은 2가지였다.(온라인 or 오프라인)

나는 오프라인으로 센터에 방문해서 시험치는 방식을 택할 것이라 왼쪽의 in person at a test center를 클릭해줬다.

오프라인 센터 시험으로 본 이유는, 온라인의 경우 커닝 방지를 위해 내 책상을 치워야하고 그게 오히려 번거로웠고, 깔끔하게 센터에 가서 시험 보고 나오면서 홀가분한 기분을 느끼고 싶어서 그런 것도 있었다.

대충 신분증이 필요하다는 안내사항 확인하고 Next로 넘어가줬다.

다음으로는 시험 언어 선택이었다. 이 언어는 시험 문제를 어떤 언어로 볼 건지를 선택하는 것이었는데, 한국어가 있어서 바로 한국어를 선택했다. 영어가 아니더라도, 실제 시험에서는 원문 보기기능을 제공하기 때문에 번역이 어색할 경우의 걱정은 안해도 된다.

또한 영어가 아닐 경우에 시험 시간 30분 추가해주는 설정을 할 수 있었다는데, 내가 접수할 적에는 몰랐어서,,, 나는 기본값인 130분으로 시험을 봤었다.

시험 시간 많이 남아도 다 풀면 미리 나올 수 있기 때문에, 30분 추가 설정은 해 놓는게 좋다.(다다익선) 이 30분 추가 설정도 후술할 Udemy강좌에서 팁으로 알려준다...!(미리 볼 걸)

대충 안내사항이라 동의하고 넘어가줬다.

다음으로 센터 선택이다. 현재 위치 기반으로 가까운 센터 리스트를 보여준다. 영어로 네이버 지도에 검색해도 잘 안나올 것 같은 낯선 이름의 센터들이 주루룩 뜬다.(실제로도 안뜬다) 나는 가장 위에 있는 SRTC 센터가 가기 편하기도 하고 선정릉역 근처라 끝나고 T1사옥 구경할 생각에(페이커 기습숭배) 이 곳으로 정했다.

다음으로는 시험 날짜 선택이다. AWS의 SAA시험이 굉장히 좋았던 게, 정처기같이 1년에 2~3번정도가 아닌 상시 시험이라 당장 2일후의 시험도 예약 가능했다. 새벽에 시험 접수하면 다음날도 예약 가능한 것 같다.

채용공고 일정을 생각해서 빠르게 따고 싶기도 하고, 그러자니 너무 빨리 하기에는 준비 일정도 생각해서 접수날인 4일로부터 약 11일 뒤인 15일로 예약을 했다.

날짜를 선택하면 시험 시간도 선택하면 됐다. 9시시작인 1가지 옵션만 있어서 이걸로 했다.

시험 시작 시간까지 선택했으면 이제 결제만 남았다. 와! 17만원! 역시 비싸긴 하다. 실제 카드 결제 시 수수료도 붙어서 17만원보다 몇 천원..?조금 더 많이 나왔던 것 같다.

한 번 시험에 17만원이 사라지는 것을 구경하며 시험 의지를 한 번 더 다질 수 있다ㅎ

참고로 오프라인 센터 장소의 경우 네이버 지도로 검색해보니 안되서, 구글 지도로 검색해야 제대로 나온다.

프로젝트에서 실시간 데이터 수집 파이프라인 구축할 때 참고하였던 GitHub레포지토리 내용을 바탕으로 Terraform을 이용해 Kinesis 데이터 수집 파이프라인을 구축한 내용을 담아보았습니다.

콘솔로 구축하는 과정은 지난 번 포스트를 참고해주세요. AWS Kinesis로 API요청 정보 실시간 수집하기

이 포스팅을 통해 참고 레포지토리를 뜯어보며 자신의 상황에 적용해보는 데 있어 도움이 되었으면 좋겠습니다:)

참고 레포지토리

https://github.com/AmaraOgu/aws-data-pipelines 제가 참고했던 자료는 위의 GitHub레포지토리였습니다.

선정 이유

이 레포지토리에서 구축한 파이프라인의 시나리오는 웹에서 보내는 api가 API Gateway를 통하는데, 이 때 api데이터를 Kinesis로 수집하는 파이프라인이었습니다.

웹에서 보내는 api데이터를 수집하는 이 시나리오가 제가 참여중이던 프로젝트의 시나리오와 일치하여 적합하다고 판단했습니다.

시작하기

0. 프로젝트 구조

이 레포지토리에서는 Readme에 설명이 친절히 나와있습니다. 각 아키텍처에 대한 설명부터, 필요 리소스, 진행 과정에 필요한 Terraform 커맨드도 명시해주어서 README 자체로도 좋은 가이드가 되어있습니다.

그럼 프로젝트 구조부터 훑고 사전 리소스 생성, 코드 수정, 인프라 구축을 진행해봅시다.

프로젝트 구조

.
├── README.md 
├── helper-resources 
│   ├── process_data.py                 - contains Python code to be run by Lambda
│   ├── process_data.zip                - contains process_data.py in a zip archive
│   └── send_to_s3.py                   - contains sample code to send data to s3
├── modules
│   ├── api-gateway
│   │   ├── gateway.tf                  - API Gateway configuration
│   │   ├── output.tf                   - output of the configurations
│   │   ├── permission.tf               - permissions needed by the API Gateway
│   │   └── variables.tf                - variables used by the API Gateway configuration
│   ├── kinesis
│   │   ├── README.MD                   - guide on how to use the Kinesis module
│   │   ├── kinesis_firehose.tf         - Kinesis Firehose configurations
│   │   ├── kinesis_iam.tf              - Kinesis Firehose IAM requirements
│   │   ├── kinesis_stream.tf           - Kinesis Stream configurations
│   │   ├── output.tf                   - output of the configurations
│   │   └── variables.tf                - variables used by the Kinesis configuration
│   ├── lambda
│   │   ├── README.MD                   - guide on how to use the Lambda module
│   │   ├── lambda_function.tf          - Lambda function configuration
│   │   ├── lambda_iam.tf               - Lambda function IAM requirements
│   │   ├── output.tf                   - output of the configurations
│   │   ├── permissions.tf              - permissions needed by the Lambda function
│   │   └── variables.tf                - variables used by the Lambda configuration
│   └── s3
│       ├── README.MD                   - guide on how to use the S3 module
│       ├── bucket_iam.tf               - IAM configuration for the S3 bucket
│       ├── output.tf                   - output of the configurations
│       ├── s3_bucket.tf                - S3 bucket configuration
│       └── variables.tf                - variables used by the S3 configuration
└── setups
    ├── main.tf                         - configuration to build the resources
    ├── provider.tf                     - providers definition
    ├── terraform.tfvars                - values used in building the resources
    └── variables.tf                    - variables used by the configuration

이 파이프라인에 필요한 리소스들에 대한 내용이 modules폴더 내 각 리소스의 이름으로 구성되어있습니다. 또한 구조를 보았을 때, 필요한 모든 리소스를 통합적으로 프로비저닝할 수 있는 코드가 setups폴더 내 main.tf인 것으로 보입니다.

모듈 내 각 리소스 폴더에는 해당 리소스 설정 코드와, 다른 서비스들과의 상호작용을 위한 IAM권한 설정, 변수 등을 정의한 tf파일들이 있음을 확인할 수 있습니다.

파이프라인 구조도와, 프로젝트 구조를 통해 확인할 수 있는 프로비저닝 목록은 다음과 같이 정리할 수 있겠습니다.

1. Kinesis가 쓰기를 허용하도록 구성된 S3 버킷
2. Kinesis로 데이터를 보낼 수 있도록 구성된 Lambda 함수
3. 데이터를 수집하도록 구성된 Kinesis 스트림
4. Kinesis Stream에서 데이터를 수집하여 s3에 전달하도록 구성된 Kinesis Firehose
5. Lambda 함수를 호출하도록 구성된 API Gateway

1. 필요조건 확인하기

이 레포지토리에서는 Readme를 통해 사전 필요 조건을 명시해놓을 것을 확인할 수 있습니다.

1. AWS계정
2. Terraform실행을 위해 미리 설치되어있어야함
3. AWS 인프라 구축 시 인증을 위한 credentials설정이 되어있어야 함

위와 같이 aws인프라를 Terraform으로 프로비저닝하기 위한 기본적인 안내사항에 대해 나와있습니다.

2번의 Terraform은 저의 경우, AWS에서 인프라 구축용이자 bastion서버로 EC2를 생성해주었습니다. (운영체제는 default값인 Amazon Linux2)

그럼 Terraform을 이용하여 인프라 프로비저닝 작업을 완전히 EC2환경에서 끝낼 수 있기 때문입니다.

이 EC2에서 Terraform설치 및 AWS credentials설정을 해주었습니다.

Terraform 설치 가이드 AWS credentials설정 가이드

1-1. 프로젝트 코드 설치

위에서 기본적인 설정이 끝났다면, Terraform 코드 수정과 실행을 위해 레포지토리를 Clone받아옵니다.

git clone https://github.com/AmaraOgu/aws-data-pipelines.git

더 살펴볼 것은?

일단 Readme에 안내되어있는 사항에 대해서는 완료했지만, 혹시 모르니 코드도 살펴봐야 합니다. (안하고 바로 코드를 돌렸다가 수많은 오류를 마주했죠)

AWS인프라는 리소스를 어느 리전에 설정할 것인지, 혹 기존 리소스와 겹치는 것은 없는 지 등을 확인하기 위해서입니다.

1-2. 메인 코드들 톺아보기

그러기 위해 Terraform apply실행 시 메인이 되는 setups폴더 내의 코드를 살펴봅시다.

1) main.tf

# Creates an S3 bucket for storing the processed data
module "data-s3-bucket" {
  source      = "../modules/s3"
  bucket_name = var.bucket_name
}

# Creates an Amazon Kinesis data stream to send data from Lambda to S3
module "kinesis" {
  source                 = "../modules/kinesis"
  kinesis_stream_name    = var.kinesis_stream_name
  kinesis_firehose_name  = var.kinesis_firehose_name
  bucket_arn             = module.data-s3-bucket.bucket_arn

  depends_on             = [ module.data-s3-bucket ]
}

# Deploys an lambda function that sends data to the Kinesis stream
module "lamda_function" {
  source                  = "../modules/lambda"
  function_name           = var.function_name
  s3_key                  = var.s3_key
  handler                 = var.handler
  runtime                 = var.runtime
  timeout                 = var.timeout
  memory_size             = var.memory_size
  source_bucket           = var.source_bucket
  kinesis_data_stream_arn = module.kinesis.kinesis_data_stream_arn

  depends_on              = [ module.kinesis ]
}

# deploy API Gateway
module "data_procesing" {
  source                     = "../modules/api-gateway"
  api_gateway_name           = var.api_gateway_name
  resource_name              = var.resource_name
  lambda_function_name       = module.lamda_function.lambda_function_arn
  lambda_function_invoke_arn = module.lamda_function.lambda_function_invoke_arn
  integration_http_method    = var.integration_http_method
  stage_name                 = var.stage_name

  depends_on                 = [ module.lamda_function ]
}

이 프로젝트 코드를 통해 생성할 리소스들의 소스 코드의 위치, 리소스 이름을 정의하고 있습니다.

모듈을 통해 코드를 나눠놓았기에 main.tf에서는 하드코딩 없이 변수를 이용해서 값들을 적어놓았습니다. main.tf는 어떤 리소스가 생성되는 지 확인만 하고 넘어가도 될 것 같습니다.

2) provider.tf

provider "aws" {
  region = var.region
}

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 3.0.0"
    }
  }
}

provider.tf는 Terraform의 버전에 관련하여 작성한 파일인 것 같습니다.

별 내용이 없는 것처럼 보이지만, 주목할 것이 있습니다. 바로 리전입니다. AWS는 리전별로 리소스를 생성할 수 있기 때문에, 리전 설정도 중요합니다.

여기서도 main.tf과 같이 변수를 이용하여 리전을 설정하였습니다. 그렇다면 변수가 정의된 파일을 살펴보는 것이 필요하다는 결론에 이릅니다.

3) terraform.tfvars

# Providers block
region  = "us-east-1"

# Creates an S3 bucket for storing raw data
bucket_name = "product-data"

# Createing Amazon Kinesis data stream to send data from Lambda to S3
kinesis_stream_name    = "demo-datastream"
kinesis_firehose_name  = "demo_firehouse"

# Deploying an lambda function that sends data to the Kinesis stream
function_name           = "run_data_processing"
s3_key                  = "process_data.zip"
handler                 = "process_data.lambda_handler"
runtime                 = "python3.8"
timeout                 = 60
memory_size             = 128
source_bucket           = "helper-bucket123" 

# Deploying API Gateway
api_gateway_name           = "data-processing"
resource_name              = "product"
integration_http_method    = "POST"
stage_name                 = "dev"

찾고 있었던 변수들이 바로 여기에 정의되어있었습니다!

리전 설정 변경

region변수에 현재 us-east-1이라는 값이 들어가 있으니, 이 리전을 서울 리전값인 ap-northeast-2로 변경해줍니다.

# Providers block
region  = "ap-northeast-2"

S3 버킷 이름 수정

리전 변수 아래, 이 파이프라인에서 필요한 S3의 버킷 이름도 설정되어있습니다.

AWS S3를 몇 번 사용해보신 분은 바로 알아채시겠지만, S3의 경우, 글로벌 범위에서 유일한 이름을 가져야하기 때문에 리전을 바꿔준다고 해도 저 이름을 그대로 쓸 수 없습니다.(이미 만들었을 것이기 때문이죠)

버킷명 위의 주석으로 이 버킷의 이름은 새로 만들어지는 버킷의 이름이니, 전 세계에서 겹치지 않을만한 이름으로 값을 수정해줍니다.

Lambda 소스용 S3버킷 설정

이제 다른 리소스들의 이름은 겹쳐도 괜찮은 것들입니다. 하지만 그 중 S3가 또 보이는 부분이 있는데요, 바로 Lambda함수 관련된 부분인 4번째 블록에서 source_bucket부분입니다.

# Deploying an lambda function that sends data to the Kinesis stream
function_name           = "run_data_processing"
s3_key                  = "process_data.zip"
handler                 = "process_data.lambda_handler"
runtime                 = "python3.8"
timeout                 = 60
memory_size             = 128
source_bucket           = "helper-bucket123" 

살펴보면, source_bucket과 s3_key라는 변수명을 통해 Lambda함수의 코드를 이 버킷의 process_data.zip에서 가져와 사용한다는 것을 유추할 수 있습니다.

그대로 사용해도 괜찮지만, 저 버킷은 이 레포지토리 작성자가 만든 버킷이기에 저 버킷에 람다 함수인 process_data.zip이 없다면 완전한 파이프라인을 구축할 수 없으니, 완전히 제가 관리할 수 있도록 새로 생성해주는 것이 좋을 것 같습니다.

1-3. 정리

이로서 필요조건은 다음과 같이 6개로 정리됩니다.

1. AWS계정
2. Terraform실행을 위해 미리 설치되어있어야함
3. AWS 인프라 구축 시 인증을 위한 credentials설정이 되어있어야 함
4. terraform.tfvars에서 region값 서울(ap-northeast-2)로 변경
5. terraform.tfvars에서 S3버킷 명 유니크한 새 이름으로 설정
6. terraform.tfvars에서 Lambda코드 저장용 S3버킷 생성 및 해당 이름으로 설정 필요

5번까지는 커맨드 상에서 가능했지만, Lambda 코드 저장용 S3버킷 생성은 따로 해줘야 하므로 콘솔에서 미리 생성&람다 코드 버킷에 저장 후에, 이 버킷 이름을 terraform.tfvars에 넣어줘야 합니다.

이는 다음 포스팅에서 사전 리소스 구축 및 Terraform실행, 테스트에서 이어서 다루도록 하겠습니다.

최근 3-Tier 웹서비스의 인프라 구성 프로젝트를 진행하다, 실시간 랭킹 기능을 위한 실시간 데이터 수집 파이프라인을 구축할 일이 있었습니다.

AWS의 Kinesis를 이용하여 구축한 파이프라인에 대해 정리해볼 겸 Kinesis는 뭔지와, 데이터 수집 파이프라인의 구성방법에 대해 작성했습니다.

Amazon Kinesis

실시간으로 데이터 스트림을 수집, 처리, 분석해주는 AWS의 완전관리형 서비스

보통 실시간 데이터 수집 서비스라 하면 Kafka를 많이 들어보셨을 겁니다.

Kinesis도 이와 비슷하게 실시간으로 대규모의 데이터 스트림을 수집하고 처리해주는 AWS의 서비스입니다.

AWS 완전관리형 서비스이기에, Kinesis용 서버를 따로 관리할 필요 없이 서비스를 이용할 수 있습니다.

이는 대규모 데이터 수집에도 큰 이점으로 다가옵니다.

보통의 서버는 처리량이 높아지면 과부화되어 다운되는 것을 막기 위해 사용량에 따라 스펙이나 개수를 늘리는 오토스케일링을 적용하는 등의 관리가 필요합니다. 하지만 완전관리형 서비스는 이 관리를 AWS가 전담하고, 사용자는 그저 사용만 하면 되므로 관리 포인트가 줄고, 편리하고 안정적인 인프라를 구성할 수 있습니다.

이러한 Kinesis는 AWS환경에 최적화된 서비스이기에 인프라 구성과 운영 시 높은 편의성을 제공합니다.

Kinesis 종류

Kinesis는 수집, 처리, 분석을 담당하는 하위 서비스로 나뉘어있습니다.

• Data Streams - 데이터 스트림 수집 및 저장
• Data Firehose - 데이터 스트림 처리 및 전송
• Data Analytics - 스트리밍 데이터 분석 / 실시간 분석 생성 / 실시간 대시보드 제공 / 실시간 지표 생성
• Video Streams - 재생 및 분석을 위해 미디어 스트림을 캡처, 저장 및 처리

Kinesis를 쓴 이유?

왜 유명한 Kafka를 쓰지 않고 Kinesis를 쓴 이유는, 편의성의 이유가 컸습니다.

Kafka와 달리 Kinesis는 AWS완전관리형 서비스라 직접 Kinesis용 서버를 관리할 필요가 없기 때문입니다.

연동성 측면에서도, API관리를 AWS의 API Gateway를 이용하여 관리하고 있었기 때문에, 이와 연동하면 쉽게 api요청의 정보를 수집할 수 있을 것이라 판단했습니다.

api요청을 수집하기 위한 아키텍처

구성은 간단합니다. Lambda가 API Gateway에 들어오는 요청을 트리거해서 Kinesis로 보내주면, Data stream(수집) => Firehose(처리 및 전송)를 거쳐 S3에 저장됩니다.

aws콘솔로 구축해보기(feat. API Gateway)

우선 이 구성은 서비스용 api가 미리 있다고 가정합니다! 또한 이 api는 AWS의 API Gateway에 등록되어있어야 합니다. 이런 식으로 배포되어 스테이지에서 확인 가능한 api가 있어야 합니다.

Kinesis Data Stream 생성

우선 데이터 수집을 위한 Kinesis Data Stream을 생성해줍시다.

저의 경우 꾸준한 중~대규모 트래픽의 경우를 생각하여 용량 모드를 프로비저닝 모드로 했지만, 실습을 위해 잠깐의 데이터만 수집한다면 사용량에 따라 비용을 내는 온디맨드 방식을 선택해주시면 됩니다.

S3 생성

이제 데이터를 저장할 S3를 생성해줍니다.

이 때 S3는 전 세계 공통으로 고유한 이름이어야 합니다. 리전 상관없이 다른 S3버킷과 이름이 겹칠 수 없습니다.

Kinesis Firehose 생성

이제 수집된 데이터를 저장소에 전송해줄 Firehose 스트림을 생성합니다. 데이터의 소스는 Kinesis Data Streams으로, 데이터를 저장할 대상은 S3로 선택해줍니다.

찾아보기 버튼을 눌러 위에서 생성한 kinesis data stream의 arn을 넣어줍니다.

S3도 똑같이 생성했던 S3를 선택하여 arn주소를 넣어주고, api요청으로 오는 데이터를 받아볼 것이니 S3 버킷 접두사에 rawdata/로 설정해줍니다.

Lambda 생성

이제 API Gateway가 api를 요청할 때마다 Kinesis에 보내주는 Lambda를 생성해줍니다.

런타임은 Python으로 하여 람다 함수를 행성해줍니다.

import json
import boto3

def lambda_handler(event, context):
    # Extract the required fields from the API Gateway event
    if 'body' in event:
        event = json.loads(event['body'])
    else:
        event = json.loads(event['Records'][0]['body'])

    # Extract the required fields
    # required_fields = ['id', 'title', 'price', 'category']
    required_fields = ['id', 'title', 'price', 'category', 'name', 'phone', 'address',  'quantity', 'item_id', 'item_name']
    processed_data = {field: event.get(field) for field in required_fields}

    # Convert the processed data to JSON
    processed_data_json = json.dumps(processed_data)

    # Encode the data as a byte string
    encoded_data = processed_data_json.encode('utf-8')

    # Create a Kinesis client
    kinesis_client = boto3.client('kinesis')

    # Send the processed data to the Kinesis stream
    response = kinesis_client.put_record(
        StreamName='demo-datastream', #replace with your Kinesis stream name
        Data=encoded_data,
        PartitionKey='partition_key'
    )

    return {
        'statusCode': 200,
        'headers': {
            'Access-Control-Allow-Headers': 'Content-Type',
            'Access-Control-Allow-Origin': '*',
            'Access-Control-Allow-Methods': 'OPTIONS,POST,GET'
        },
        'body': 'Processed Data sent to Kinesis stream successfully.'
    }

api gateway에서 오는 데이터를 Kinesis에 보내고, Kinesis에서 오는 응답을 되돌려주는 이 코드를 함수 코드 소스에 작성해주고, Deploy해줍니다.

마지막으로 api요청을 감지하여 Lambda를 작동시킬 트리거를 생성하면 됩니다.

함수 개요 > 트리거 추가에서, 기존의 API를 선택해야하니 Use existing API를 선택하고, 하단의 API ID 검색창을 클릭하면 현재 API Gateway에 연결된 API 목록들이 나올겁니다.

여기서 수집하고자 하는 API를 선택한 후, API배포가 이루어진 스테이지를 선택 후 Security는 Open으로 선택하여 추가를 눌러 트리거를 추가해줍니다.

트리거를 추가하면 API엔드포인트가 발급되고, 배포된 해당 스테이지 환경에도 이 엔드포인트가 추가된 것을 확인할 수 있습니다.

API의 스테이지에 트리거용 메서드 run_data_processing이 잘 추가되어 있습니다.

이 엔드포인트를, api를 요청하는 로직에 이 엔드포인트에도 추가해주면 파이프라인 구축 완성입니다.

저의 경우 구매에 대한 POST요청을 보내는 로직을 run_data_processing의 엔드포인만 바꿔 둘 다 보내는 방식으로 진행했습니다.

결과

구매 요청 보낸 결과

console log로 응답 데이터를 찍어보니 Lambda에서 데이터 전송 성공 시 반환하는 메세지가 뜬 것이 확인됐습니다.

데이터 저장 결과

Kinesis로 성공적으로 보내진 데이터가 S3에도 잘 도착했는지 확인해봅시다.

S3내에 데이터가 저장 되었습니다! 다운받아 파일을 열어보면 POST요청 보낼 때 담았던 데이터대로 잘 저장되는 것을 확인할 수 있습니다.

마무리

조금은 생소할 수 있는 AWS Kinesis로 간단하게 api요청의 정보를 수집하고 저장하는 파이프라인 구축에 대해 다뤄보았습니다.

이 글에서는 Kinesis를 이용한 데이터 수집까지만 다루고 있지만, 분석 서비스인 Kinesis Analytics를 이용한다면 Kinesis를 여러 방면으로도 활용해보는 것도 좋을 것입니다.

참고 리소스: https://github.com/AmaraOgu/aws-data-pipelines

재사용이 가능한 독립된 모듈로, UI 컴포넌트는 웹과 모바일 화면에서 기능을 구성하는 최소한의 단위다.

예를 들면 웹사이트에서 보이는 한 버튼이 하나의 UI컴포넌트라 할 수 있다.

컴포넌트를 사용하면 좋은 것이, 사용자 입장에서는 다른 사이트에서 본 UI와 비슷한 UI로 인해 별도의 학습 없이도 사이트를 쉽게 사용할 수 있다.

개발자 입장에서도 기존에 사용했던 소스코드와 디자인을 재사용할 수 있어 생산성도 올라간다.

원래는 버튼마다 배경색, 테두리 둥글게, 안의 텍스트는 또 어떻게 할지 지정해줘야 하는데 이 UI컴포넌트라는 것을 사용하게 되면 기존에 있는 버튼의 UI를 그대로 가져다 쓸 수 있는 것이다.

컴포넌트 갤러리

https://component.gallery/ 위 사이트에서는 여러 가지 웹UI 컴포넌트들의 예시와 사용방법을 보여준다.

컴포넌트 실제로 적용해보기

컴포넌트 갤러리에서 버튼 컴포넌트를 선택하면 여러 버튼 UI에 대한 예시들이 나오고, 원하는 컴포넌트를 찾아 사용할 수 있다.

Github에서 제공하는 Button의 컴포넌트 사용하기 여러 버튼 컴포넌트 중 GitHub에서 제공하는 버튼을 클릭하면 GitHub의 사이트로 이동한다.

GitHub에서 제공하는 여러 컴포넌트들에 대해 UI의 생김새와 컴포넌트를 어떻게 적용하는지 코드를 보여준다.

그러나 html/css기준으로 깃헙의 컴포넌트를 사용하기 위해선 html파일에 'GitHub꺼 컴포넌트 사용할거다'라는 것을 알려줘야 한다.

Getting started에서 CSS사용하기 위한 링크를 header에 추가해주면 된다. 아래 코드를 html파일 header태그 안에 넣어주면 기본적으로 GitHub의 UI컴포넌트 사용을 위한 준비가 끝이다.

<link href="https://unpkg.com/@primer/css@^20.2.4/dist/primer.css" rel="stylesheet" />

<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <link href="https://unpkg.com/@primer/css@^20.2.4/dist/primer.css" rel="stylesheet" />
    <title>컴포넌트 써보기</title>

</head>

이제 GitHub사이트 왼쪽의 리스트에서 Buttons을 선택한 후 Button컴포넌트 코드를 html파일에 복붙한다.

<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <link href="https://unpkg.com/@primer/css@^20.2.4/dist/primer.css" rel="stylesheet" />
    <title>컴포넌트 써보기</title>

</head>
<body>
  <button class="btn" type="button">Button</button>
</body>
</html>

위 코드를 실행시켜 웹페이지를 확인해보면 GitHub의 버튼이 웹에 출력된 것을 확인할 수 있다.

위와 같은 방식으로 다시 GitHub사이트로 돌아가 왼쪽의 리스트에서 자신이 사용하고 싶은 컴포넌트를 찾아 코드를 복사해서 사용하면 GitHub의 UI를 쉽게 사용할 수 있다.

GitHub의 다른 컴포넌트들도 적용해본 모습이다.

단순히 코드를 재사용하는 것만으로 UI에 필요한 여러 요소들의 기능과 디자인을 쉽게 재사용할 수 있어 굉장히 편리하다!

GitHub Primer/CSS https://primer.style/css/getting-started