감성 개발자

매달 초가 되면 저는 습관처럼 AWS 청구서를 엽니다. 예전 회사에서 월 청구액이 예상보다 40% 넘게 튀어나온 적이 있었는데, 그때 원인을 추적하면서 알게 된 게 하나 있습니다. AWS 요금은 큰 실수 하나로 터지는 게 아니라, 아무도 안 보는 작은 낭비들이 조용히 쌓여서 터진다는 겁니다.이번 글은 제가 실무에서 실제로 잡아냈던 AWS 비용 낭비 포인트들을 정리한 것입니다. 콘솔에서 바로 확인할 수 있는 것들 위주라, 오늘 점심시간에 하나씩 열어보면서 따라 해볼 수 있는 수준으로 썼습니다.사진: Unsplash의 Growtika0. 시작은 무조건 비용 가시화부터비용 절감 얘기를 하면 다들 인스턴스 줄이는 것부터 떠올리는데, 순서가 틀렸습니다. 뭐가 얼마나 나가는지 모르는 상태에서 줄이는 건 감으로 하는..

RDS Proxy 는 2019년 12월에 발표된 AWS 의 서비스입니다. 관계형 DB의 connection 을 관리해주는 서비스인데, 사실 Java 개발자들은 이게 왜 필요하지 싶겠지만, 서버리스( 예 : Lambda ) 나 php, ruby 같은 언어에서는 이부분이 상당히 머리 아픈 구석이었습니다. 구글링을 해보면 여러가지 사례들이 있습니다. 우리도 해당 사례들과 비교해보며 서버에 스트레스 테스트를 해보았지만, 앞선 업체들과는 다른 양상을 보여 도입에 대한 고민을 엄청 했습니다. 저희 같은 경우는 PHP Laravel을 AWS ECS Fargate 에 올린 상태입니다. 즉 DB pool 관리는 안해주는 대환장 파티이다. 이번에 RDS Proxy를 적용하며 바뀐 DB 메트릭을 공개하려고 한다. 자신이 서..

CodePipeline과 Slack Bot으로 스마트하게 배포하는 구조를 정리한다. 핵심은 배포 직전에 Slack에서 사람이 승인하도록 만드는 것이다.만들고 싶었던 흐름GitHub push 하면 Docker 자동 빌드 및 테스트빌드가 완료되면 배포 직전에 confirm을 Slack Bot으로 받기Slack에서 최종 컨펌을 하면 배포 시작배포가 완료 및 실패가 되면 Slack으로 알림 받기트리거는 GitHub Actions vs CodePipeline빌드 트리거는 GitHub Actions와 CodePipeline으로 하는 방법 2가지가 있다.트리거 종류로는 비용이 바뀌지 않으니 CodePipeline에서 처리하는 것이 관리적 측면에서 좋다고 판단했다. AWS 리소스 접근 권한을 IAM 역할로 처리할 수 ..

ECS Fargate로 컨테이너를 운영하면서 정리한 순서와 개념이다. 서버를 직접 관리하지 않고 컨테이너만 올리면 되는 게 Fargate의 핵심이다.CODE 영역Dockerfile 생성buildspec.yaml 작성AWS 영역 준비 순서클러스터 생성리포지토리(ECR) 생성작업 정의(Task Definition) 생성보안 그룹(SG) 생성Application Load Balancer 생성 (미리 해둬야 편함)Target Group 생성 (로드밸런서 생성할 때 미리 생성, 필수는 아님)서비스 및 작업 생성ALB를 먼저 만들어두라는 게 실무 팁이다. 서비스를 생성하는 화면에서 ALB를 고르게 되는데, 그 자리에서 새로 만들려면 화면을 왔다 갔다 해야 한다.서비스와 작업의 차이서비스는 항상 돌아가는 개념작업(T..

AWS DMS(Database Migration Service)로 DB를 옮기면서 겪은 문제들을 기록해둔다. 마이그레이션이 "완료"로 뜨는데 데이터가 원본과 일치하지 않는 상황이 반복됐다.문제 1. 데이터가 완전히 일치하지 않는다DB 이전 시 deleted_at 같은 몇몇 컬럼들에 이전 시간 값이 박혀 있었다. 스키마에도 원래 없던 default 값이 들어가 있었다.원인: DMS는 스키마를 자동 생성할 때 원본 DDL을 그대로 복제하지 않는다. 타입을 자체 중간 타입으로 변환한 뒤 대상 DB 타입으로 다시 매핑하기 때문에, 이 과정에서 default 값이나 nullable 속성이 달라질 수 있다.해결: 스키마는 dump로 먼저 이전하고, DMS는 데이터만 옮기게 한다.# 1. 스키마만 덤프 (데이터 제외..

12 Factor APP을 하는 이유 최근 소프트웨어 서비스가 클라우드 서비스로 많이 바뀌게 되면서, 12 Factor는 확장성 좋은 SaaS 앱을 만들기 위한 방법론이다. 설정을 자동화 할수 있다. OS 따라 달라지는 부분이 명확하고, 이식성이 좋다. 클라우드 환경에 적합하다 CI / DI 에 용이하다. 툴, 아키텍쳐, 개발방식을 바꾸지 않아도 Scale up이 용이하다. 12 Factor 1. 코드 베이스 (Code Base) 애플리케이션(이하 앱)은 한 개의 코드 베이스 (Git, SVN)를 통해 관리하며, 동일한 코드로 운영/개발에 배포하여야 한다. - 앱은 1개의 코드 베이스로 1:1 관계다. - 앱은 1개의 코드 베이스로 운영/개발 등등에 배포된다. - 코드베이스 전략은 다른 11가지 전략의 ..