일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |
- 생성 패턴
- Rust
- 티스토리챌린지
- MAPF
- ssh
- leetcode
- Go-lang
- DevOps
- 지표
- 경로 계획 알고리즘
- PostgreSQL
- 구조 패턴
- AWS 비용 절감
- 도커 주의사항
- 신혼 여행
- 오블완
- 14일 공부
- study
- terraform
- Playwright
- 논문 정리
- AWS
- 디자인 패턴
- Monthly Checklist
- github
- 실용주의 프로그래머
- amazon ecs
- docker
- Til
- 청첩장 모임
- Today
- Total
밤 늦게까지 여는 카페
[Amazon Q Developer 리뷰] 4시간 만에 AWS 서비스 모니터링 뚝딱 도구 만들기 본문
안녕하세요. 이제 슬슬 여름 날씨로 바뀌고 있습니다... 여름 싫어요... ㅜㅠ
이번에는 생성형 AI 도구인 Amazon Q를 이용해서 인프라 부하 모니터링 도구를 만들어 본 경험을 기록해보겠습니다.
1. Amazon Q Developer가 뭐에요?
Amazon Q Developer는 AWS에서 만든 생성형 AI 도구인 Amazon Q 제품군 중 하나로
소프트웨어 개발, 테스트, 배포, 문서 작성 등 다양한 작업을 지원해줍니다.
저는 우연히 링크드인에서 본 Bhairav M님의 글 을 보고 관심이 생겼고
마침 테스트를 위한 AWS 서비스 모니터링 도구가 필요해서 사용해보게 되었습니다.
Amazon Q Developer는 CLI로도 사용할 수 있고, IDE에 extension을 설치해서도 사용할 수 있습니다.
- JetBrains, VS Code, Visual Studio, Eclipse에서 사용할 수 있다고 합니다.
저는 VS Code에 extension을 설치해서 사용했습니다.
2. Amazon Q Developer로 AWS 서비스 모니터링 도구 만든 과정
2.1. 모니터링 도구 요구사항
만들어야 했던 모니터링 도구의 요구사항을 알아봐야겠죠?
모니터링 도구의 요구사항은 다음과 같습니다.
- 인프라 이상 감지
- RDS DB
- 인스턴스의 DB Load가 N분 동안 평균 T를 넘었는지
- 인스턴스의 CPUUtilization이 N분 동안 평균 T를 넘었는지
- Amazon MQ
- 브로커의 MessageCount가 N분 동안 평균 T를 넘었는지
- Elasticache
- 클러스터의 NetworkBytesIn+NetworkBytesOut이 N분 동안 평균 T를 넘었는지
- EC2 AutoScalingGroup
- 인스턴스 드레이닝이 발생했는지
- RDS DB
- 알림 전송
- 인프라 이상이 감지될 시, 슬랙으로 알림 전송
- 어떤 서비스에서 어떤 부하가 발생했는지 식별 가능
2.2. 개발 과정
요구사항을 개발한 과정은 크게 세 단계로 나뉘었던 것 같습니다.
1단계: 채팅을 통한 프로젝트 초안 생성: 30분
2단계: 리소스 네이밍, 알림 내용 변경 등의 세세한 조정: 2시간
3단계: 실제로 배포하면서 발생한 자잘한 버그 수정: 1시간 30분
1단계에서 프로젝트 초안을 생성하는데는 요청 3개면 충분했습니다.
1. 요구사항 전달
I want to receive an alarm message from slack bot, when metrics of aws services exceed the threshold.
RDS PostgreSQL: DBLoad > 2 for 5 minutes, CPU Utilization > 80 for 5 minutes
Amazon MQ RabbitMQ: # of Accumulated Messages > 500 for 5 minutes
Elasticache: NetworkBytesIn + NetworkBytesOut > 500MB for 5 minutes
EC2 instances generated by specific ASG: when it is drained.
2. javascript로 작성된 lambda 함수 python으로 변경 요청
Could you implement the Lambda function in python language?
3. 불필요한 배포 스크립트 삭제 요청
Thank you! Could you remove simple deployment?
2단계에서는 알림 메시지를 어떻게 작성해야 개발자들이 문제가 발생한 AWS 서비스를 빠르고 쉽게 식별할 수 있을지 고민하는데 시간이 많이 소요되었던 것 같습니다.
내용을 풍부하게 작성할지, 아니면 최소한의 정보만 전달할지 이리저리 고민하다가 일단 최소한의 정보를 전달해보기로 결정했습니다.
- 슬랙 특성 상 너무 긴 메시지는 오히려 안 보게 되는 것 같아서 이와 같은 결정을 했습니다.
3단계에서는 배포 스크립트를 수정하는데 시간이 많이 소요되었습니다.
Cloudformation의 기능을 Serverless Application Model(SAM)과 혼동했던 부분이 있었고 이로 인해 불필요한 시간 소요가 생겼습니다.
3. 후기
✅ AWS 서비스 학습 시간, 개발 시간의 엄청난 단축
Amazon Q Developer 없이 처음부터 인프라 모니터링 도구를 만들었다면 최소 3일은 걸렸을 것 입니다.
- 기존 업무를 수행하면서 Cloudformation 템플릿 문법, Cloudwatch Alarm에 대해서 다시 공부하는 것이 어려웠을 것 같습니다.
✅ 매우 만족스러운 결과물
프로젝트 구조, Cloudformation 템플릿, lambda 함수, 배포 스크립트 모든 것이 만족스러웠습니다.
심지어 README.md도 깔끔하게 잘 작성해줬습니다!
프로젝트가 규모가 크지 않아서(500줄 이하) 그런지는 모르겠지만 전체적으로 👍👍👍
❓ Amazon Q Developer가 가장 잘하는지는 추가적인 조사 필요
시장에는 Cursor, Windsurf, Aider와 같은 AI 코드 에디터, Copilot, Gemini 등의 개발 보조 도구들도 많습니다.
이들보다 Amazon Q Developer의 성능이 좋은지는 아직 모르겠습니다.
다음에는 다른 도구들을 이용해서 AWS 프로젝트를 개발부터 배포까지 진행해보고 싶네요.
❓ 90% => 100%를 가르는 것은 사용자
당연하겠지만 Amazon Q Developer가 모든 것을 완벽하게 수행하지는 못합니다.
Cloudwatch Alarm 조건을 잘못 생성해줬던 것처럼 사용자의 요구사항을 잘못 반영할 수도 있고
혹은 제가 배포 스크립트를 잘못 이해했던 것처럼 사용자가 잘못된 방식으로 실행할 수도 있습니다.
Amazon Q Developer가 만들어준 결과물을 100%로 만드는 것은 사용자라는 것을 명심해야 합니다.
'리뷰' 카테고리의 다른 글
[2025년 AI 툴 추천] 업무 효율 올릴 수 있었던 3가지 AI 툴 리뷰 (2) | 2025.05.08 |
---|---|
[번역] 2023-04-04 피그마 인프라팀의 "The growing pains of database architecture" (0) | 2024.10.12 |
[2023-12] 스크럼 가이드 리뷰 (0) | 2023.12.07 |
도메인 주도 개발 시작하기 - 2. 아키텍처 개요 (0) | 2022.11.25 |
도메인 주도 개발 시작하기 - 1. 도메인 모델 시작하기 (2) | 2022.11.15 |