개요
프로젝트 진행중에 외부에서 SFTP를 통해 데이터를 받아 처리하는 로직을 구현할 일이 있었습니다. 데이터는 SFTP서버를 거쳐 최종적으로 S3에 저장되어 람다로 처리하는 로직이었습니다.
이러한 조건에서 EC2로 SFTP 서버를 구성하지 않고 AWS Transfer를 사용해 서버 없이 SFTP 서버를 구축하고 파일을 S3로 보관하는 솔루션을 소개하고 CloudFormation 템플릿을 공유하려 합니다.
배경
지난 포스팅에서는 CodePipeline에서 외부 람다를 호출하기 위한 예제로 UITest를 위한 람다함수를 만들었습니다. 이번 포스팅에서는 지금까지 만든 모든 서비스를 모아서 CodePipeline을 구성하고 CloudWatch 이벤트를 위한 규칙을 만들어 자동화를 완성하도록 하겠습니다.
1화-CodeCommit, CodeBuild
2화-S3,SNS
3화-UITest Lambda
4화-Codepipeline, CloudWatch Rule, CF 템플릿 공유
배경
지난 포스팅에서는 S3에 리액트 앱을 호스팅하기 위한 버킷 생성과 S3를 정리하기 위한 Lambda, 그리고 파이프라인의 이벤트를 알려주기 위한 SNS를 만들어보았습니다. 이번 포스팅에서는 CodePipeline에서 외부 람다를 호출하는 내용을 다루려 합니다. 아시다시피 람다 자체는 거의 모든 것을 할 수 있기 때문에 필요한 로직에 람다를 호출해 파이프라인의 여러 작업중 아직 AWS에서 구현되지 않은 작업을 수행할 수 있습니다.
이번시간엔 예제로 리액트로 만들어진 앱의 UI테스트를 위한 람다를 만들어보겠습니다.
1화-CodeCommit, CodeBuild
2화-S3,SNS
3화-UITest Lambda
4화-Codepipeline, CloudWatch Rule, CF 템플릿 공유
배경
이전 포스팅에 이어 이번에는 S3 버킷과 S3버킷을 정리하기 위한 Lambda에 대해서 살펴보겠습니다.
1화-CodeCommit, CodeBuild
2화-S3,SNS
3화-UITest Lambda
4화-Codepipeline, CloudWatch Rule, CF 템플릿 공유
Devops의 꽃: 자동화
“The most powerful tool we have as developers is automation.”
AWS는 Devops를 “애플리케이션과 서비스를 빠른 속도로 제공할 수 있도록 조직의 역량을 향상시키는 문화 철학, 방식 및 도구의 조합” 으로 정의합니다. 그리고 이것을 이루기 위한 Devops의 가장 강력한 무기는 바로 자동화입니다.
속도가 느리고 수동으로 실행되는 반복적인 프로세스를 자동화하면 많은 시간을 줄일 수 있고 이는 개발자가 좀더 로직을 구현하는데 집중할 수 있도록 도와주며 이는 제공하는 서비스를 빠르게 제공할 수 있게 도와줄 뿐 만 아니라 서비스의 질적 향상에 엄청난 도움이 되기 때문이죠.
이번 포스팅시리즈 에서는 AWS의 Code시리즈(CodePipeline, CodeBuild, CodeCommit)과 연관된 여러 서비스를 통해 개발된 React앱의 빌드,테스트,마지막 승인,배포까지의 모든 과정을 자동화하고 각 스테이지의 진행상황을 SNS(슬랙,이메일 연동가능)으로 받아볼 수 있는 솔루션을 설명하며 CloudFormation 템플릿도 공유하려 합니다.
팀에서 운영하는 프로젝트중 하나는 Serverless 기반으로 백엔드를 구성하여 서비스하고 있습니다. 이 서비스에서 Backend API별 호출 빈도를 확인하는 로직이 필요하게 되었고 모든 API가 람다로 구성되어 있기 때문에 각 API의 호출 빈도를 알기 위해서 CloudTrail을 통해 특정 람다 그룹의 호출 로그를 확보하여 CloudWatch로 전송후 CloudWatch Insight로 분석하는 아키텍쳐로 문제를 해결하였습니다.
우선 이 포스트에서는 특정 이름으로 시작되는(특정 프로젝트의) 람다의 CloudTrail 로깅을 설정하고 이를 CloudWatch로 전송하는 솔루션과 그 CloudFormation 템플릿을 공유하려 합니다.
AWS를 사용하다 보면 가장 많이 하게되는 고민 중 하나는 요금 관련 고민입니다. 어떻게든 고정 지출 비용을 줄이는 것 만큼 확실한 효율 상승 효과는 없으니까요. 이런 수요를 알기 때문에 AWS에서도 매우 다양한 비용 절감 서비스(AWS Billing, Reserved Instance, Saving Plan 등)들을 제공하고 있습니다.
제공되는 서비스를 이용하는 것 이외에도 근본적으로 “사용하지 않으면 꺼둔다” 라는 단순한 방법으로도 많은 비용을 절감할 수 있습니다. 이번 포스트에서는 CloudWatch에서 제공하는 일정 규칙을 통해 퇴근후 자동으로 개발 리소스를 정지시키고 출근전 시작되도록 해서 비용을 절감하는 방법을 공유하려 합니다.
AWS의 여러 리소스를 관리하기 위해서는 태깅(Tag)은 매우 중요합니다. 각 리소스에 태깅을 통해 리소스를 그룹으로 묶어서 살펴볼수도 있고(Resource Group) 요금을 확인할때 태그로 묶어 요금을 확인할 수도 있습니다.
따라서 각 리소스에 태깅이 올바르게 이루어질 수 있도록 관리 감독하는 방법이 필요하며 AWS의 리소스가 설정된 규칙(태깅이 되어있는지, 암호화가 되어있는지 등)을 올바르게 준수하고 있는지를 확인할 수 있는 서비스가 AWS Config입니다.
이번에는 AWS 리소스가 지정한 이름의 태그가 붙어있지 않다면 알람을 전달하는 아키텍쳐를 소개하고 필요하신 분들이 쉽게 구성할 수 있도록 포스트 마지막에 Cloudformation 템플릿을 공유하려 합니다.
AWS IOT Core
AWS IOT Core 는 Serverless 서비스로 AWS Cloud 환경에서 IoT Device를 관리할 수 있도록 해주는 서비스입니다. 현재 개발중인 프로젝트에서는 IoT Core의 MQTT 기능을 활용하여 클라이언트와 서버간의 연결을 관리하고 있습니다.
IoT Core 서비스중 IoT Rule 서비스는 클라이언트에서 보낸 MQTT 메세지를 SQL형식으로 Query하여 AWS의 다른 서비스(이 케이스에서는 람다)로 전달해주는 굉장히 편리한 서비스이며 이 서비스를 사용하는 도중 발생한 버그와 해결한 경험을 공유하려 합니다.
아키텍쳐
로컬 서버에서 발생한 로그를 MQTT를 통해 IOT Core로 전송하면 IoT Core에서 Rule을 통해 내용을 필터링하여 DynamoDB에 넣는 람다함수로 전달하는 간단한 구조입니다.
IOT Rule의 경우 SQL 형식으로 특정 MQTT Topic 을 잡아내 해당 내용을 지정한 서비스(람다, SQS ,S3 등등)으로 보내주는 서비스입니다.
밑의 사진의 Rule의 경우 /ems/+/+/data 토픽에 대한 모든 내용을 ess_dev1_data_iot_pot라는 람다함수로 전달합니다.(+는 임의의 스트링입니다.즉 /ems/dev/test1/data 토픽 이나 /ems/prod/test2/data 같은 토픽을 잡아낼 수 있습니다. 자세한건 링크 참조해주세요). Select에 topic() 부분은 Payload에 토픽 필드를 추가해주기 위함입니다.
JSON Payload가 이상하게 도착했습니다.
문제는 로컬 서버에서 보낸 로그 Payload가 그대로 람다함수로 전달되지 않는 것이였습니다.
AWS Devops Engineer Pro 시험을 보았습니다.
이번에 AWS 데브옵스 엔지니어 프로페셔널 시험을 보고 합격하였습니다.
AWS Certified DevOps Engineer - Professional (이하 Devops Pro) 시험은 AWS의 여러 자격증 시험중 AWS의 환경을 운영하고 관리하며 Devops업무를 담당하는 시험입니다.
이전 포스트에서 설명한 것 처럼 Devops Pro 시험은 아래 단계의 SysOps/Developer Associate 시험보다 어렵고 요구하는 지식 역시 보다 전문적입니다. 실제로 제가 담당하는 업무와도 연관성이 있어서 공부하면서 실무에 엄청나게 도움이 되었습니다.
이번에는 간단하게 Devops Pro 시험공부후 합격한 후기를 공유할까 합니다.(이전 AWS Pro 시험 후기 와 많은 부분을 공유합니다.)
시험 후기
시험 장소
SRTC에서 보았습니다. 문정역의 SRTC가 강남 선정릉역으로 옴겼습니다. 사실 개인적으로는 이전 SRTC가 좀더 깔끔했던것 같은데새로 이전한 건물이 좀더 오래된 건물이라 그런 느낌이 들었나봅니다. 아무튼 시험을 보는데는 전혀 지장이 없고 오히려 아늑한 분위기에서 편안하게 시험을 봤습니다. 신분증과 제 명의의 신용카드를 ID로 제시하면(필수로 들고가야 합니다.) 간단한 확인과 함께 시험에 관한 전반적인 안내사항을 알려줍니다. 시험실에 입실하기 전 주머니 체크를 하는데 팔목도 걷고 발목도 걷는등 매우 꼼꼼히 체크합니다. 목걸이와 반지등의 악세사리도 반입 불가입니다. 단 결혼반지는 가능하다고 하여 번거롭게 결혼반지는 가지고 들어갈 수 있었습니다. 참고로 시험 대기실에선 전자기기 사용 금지기 때문에 태블릿 등으로 마지막 점검을 하려 한다면 주의가 필요합니다. 또한 코로나때문에 발열이나 기침이 있을땐 시험을 볼 수 없다.시험 환경
연필 두개와 여러장의 A4용지가 주어집니다. AWS Pro 시험과 달리 종이를 쓸 일은 별로 없었습니다. 운영에 관한 지식을 많이 물어보는 편이라 따로 계산이 필요한 문제가 없었기 때문입니다.시험 시간 및 문제들
180분동안 75문제를 풀어야 하는데, 한 문제당 2.4분 정도가 주어집니다. 시간 자체는 그렇게 모자란 편은 아니었지만 문제는 집중력입니다. 이번에도 쉴세없이 3시간(아래 언급할 추가시간을 합치면 3시간 30분)동안 집중하는건 쉬운일이 아니었습니다. 이전 AWS Pro 시험의 경험이 있었지만 여전히 75문제를 다 풀었을때는 좀 지치더군요. 다만 체감상 이전만큼 힘들지는 않았는데 문제 체감 난이도는 SA PRo시험보다 조금 더 쉬웠기 때문인 것 같습니다. 아무쪼록 시험을 준비할때 아래 언급할 연습문제 등에 꼭 시간체크를 해서 한번에 쉬지않고 180분동안 75문제를 푸는 경험을 해보는 것이 꼭 필요할 듯 싶습니다. 그리고 시간배분 역시 그리 시간이 모자라지 않으니 적당히 문제에 시간을 쓰고 여러번 읽어야 하는 문제는 과감히 스킵해서 맨 나중에 푸는 센스가 필요합니다.시험 범위
Devops 시험은 SA Pro 시험과 체감상 조금 달랐습니다. SA Pro 시험은 알고 있는 지식 범위내에서 아키텍쳐를 도출하며 필요한 상황에 적절한 방법으로 문제를 해결하는 방법을 테스트하는것이었다면, Devops Pro 시험은 “xxx을 하고싶을때 어떻게 하는가?” 에 관한것이라 지식의 범위가 훨신 많고 자세히 알아야 하며 외울게 많습니다. 꾸준히 AWS를 현업에서 사용한 경험이 도움이 많이 되었고 반대로 시험을 공부하면서 배운 것들을 현업에 적용시킬 여지도 많았습니다.
합격 팁
이번에도 시험을 준비후 한번에 합격하였는데 역시 이전과 마찬가지로 영어로 보았습니다. 영어로 시험을 본 이유는 이전과 같습니다. 번역이 매끄럽지 못하고 시험도 최신 유형의 반영이 늦기 때문입니다. 덤프등을 구해서 공부하는 방법도 한국어보다 오히려 영어가 더 편했습니다. 공부하면서 실력을 키우는것이 목표였던 만큼 저는 영어쪽이 훨신 더 도움이 되었습니다.
- Assoicate 시험을 먼저 보자
SA Pro시험과 달리 Devops Pro시험은 하위 자격증이 두개입니다. 하나는 SysOps고 하나는 Developer입니다. 이 둘 모두가 적절히 혼합되있는 만큼 이 두 자격증을 먼저 취득하신다면 시험 공부에 절대적으로 많은 도움이 될 것입니다. 절벽을 오르는것 보다 작은 계단을 오르는게 쉬운것처럼 하나하나 단계를 밟아나가는 편이 훨신 편할태니까요. 언급한 두 자격증 역시 AWS를 공부한다면 정말 좋은 이정표가 되는 자격증입니다. 거기다 시험 방식 및 출제 경향에 익숙해질 수 있는 점도 있습니다.