스톡옵션은 스타트업에 합류하는 인재들의 출구전략 중 하나입니다. “어떻게 내 노력을 보상받을 것인가?” 에 대한 대표의 응답이기도 하죠. 잘하면 회사의 성장에 따라 많은 차익을 챙길 수 있지만 현실에서 이런 모습으로 스톡옵션을 행사하는 경우는 자주 볼 수 없습니다. 스톡옵션의 최소 행사기간인 2년을 채우지 못하는 기업들이 정말 많고 2년을 넘기더라도 주식을 팔 수 있는(상장, 혹은 장외시장) 정도의 회사가 되기 쉽지 않기 때문입니다.
다행히 재직중인 회사는 정상궤도로 올라가고 있었고 저는 스톡옵션을 행사하는 것이 매력적이라고 판단해서 스톡옵션을 행사했습니다. 그렇게 저는 당당히 회사의 주주가 되었습니다. 제가 다니고 있는 회사에 주주라는건 참 요상한 기분이긴 합니다.
그리고 이번 포스팅에서는 제가 스톡옵션을 행사하면서 겪은 이야기를 풀어볼까 합니다.
프로젝트 진행중에 외부에서 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 템플릿 공유
“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 는 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에 토픽 필드를 추가해주기 위함입니다.
문제는 로컬 서버에서 보낸 로그 Payload가 그대로 람다함수로 전달되지 않는 것이였습니다.