codepipeline 과 slackbot 으로 스마트하게 배포하기 스크린샷 및 코드 준비중 내용 : 1. github push 하면 docker 자동 빌드 및 테스트 2. 빌드가 완료되면 배포 직전에 confirm 을 slack bot 으로 받기 3. slack 에서 최종 컨펌을 하면, 배포 시작 4. 배포가 완료 및 실패가 되면, slack으로 알림 받기 빌드 트리거는 github action 과 codepipeline으로 하는 방법 2가지가 있지만, 트리거로 종류로는 비용이 바뀌지 않으니 codepipeline 에서 처리하는 것이 관리적 측면에서 좋음. 순서 : codepipeline 에서 트리거 push 할 때 작동되록 설정 buildspec.yml 에서 빌드 및 테스트 confirm 에서 SNS..

스크린샷 준비중 CODE 영역 Dockerfile 생성 buildspec.yaml 작성 AWS 영역 클러스터 생성 리포지토리 생성 작업 정의 생성 SG 생성 application load balancer 생성 (미리 해둬야 편함) target group 생성 (load balancer 생성 할때 미리 생성, 필수는 아님) 서비스 및 작업 생성 서비스는 항상 돌아가는 개념 작업은 1회성 개념이 강함 하지만 서비스도 내부에서는 작업 예약된 작업 크론 작업 서비스 생성 (작업도 비슷) 시작 유형 fargate 작업정의, 클러스터 선택 서비스 이름 생성 ( 생성 후 이 이름이 노출됨 ) 작업 갯수 ( 몇개의 작업을 돌릴지 선택 ) 후에 나오는 오토 스케일링과 콤보를 이룰수 있음. 최소 정상 상태 백분율 및 최대..

DB 데이터가 완전히 일치하지 않는 문제 DB 이전시 deleate_at 같은 몇몇 컬럼들이 이전 시간 값이 박혀 있다. 스키마에 default 값이 뭔가 없던것이 박혀 있다. 해결 : 스키마는 dump로 이전 값이 일부 안들어온다. 혹은 에러 발생 외래키 무시 옵션 시간이 계속 틀리다 endpoint 에 타임 zone 설정등이 있다. https://docs.aws.amazon.com/ko_kr/dms/latest/userguide/CHAP_Source.MySQL.html#CHAP_Source.MySQL.ConnectionAttrib

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

AWS RDS 비용 줄이는 방법 및 최적화 하기 서론 ( 안 읽어도 됨) 현재 필자가 다니는 회사는 예약관리 서비스를 하고 있습니다. 처음 입사 했을 때는 사용자가 그리 많지 않아서 T시리즈를 이용해도 문제가 없었지만, 입사 후 갑자기 폭팔적인 서비스 성장으로 인해 순간 동접 1만을 넘는 거대한 서비스가 되었고, 현재 해당 분야 업계 1위가 되었습니다. 서비스 성장은 언제나 즐겁지만, 스타트업들의 개발 코드는 여기서부터 문제입니다. 서비스를 위한 기능 추가만 하다보니 코드가 그렇게 깔끔하지 않을 뿐더러, ORM 코드들의 최적화되지 않은 쿼리도 문제였습니다. 이 문제는 우리 회사도 다르지 않았습니다. 처음 MariaDB 를 사용하고 있었는데.. DB 의 CPU 가 90프로를 넘기는 경우가 종종 있었고, 업..

MariaDB 빠르게 백업하고 복원하기 이번에 RDS mariadb 에서 RDS auroradb 로 이전하게 되었다. 한달에 회원이 1~2만명 씩 꾸준히 늘어나고 있고, 피크 타임, 이벤트 타임 때 DB를 유연하게 움직이기 위해서 mariadb 를 보내줘야 했기 때문이다. 문제는 데이터가 너무 많았다. 물론 초대형 사이티들의 테라급은 아니지만, 적어도 내 경험 (이력) 에서 가장 많은 데이터다. 그냥 무작정 툴로 QA 서버를 백업과 복원을 했더니 4시간이 넘게 걸렸다. (우리는 production 서버의 한달 전 데이터가 staging, staging 의 한달전 데이터가 QA 다) 아무런 옵션 없이 하는 것은 무식한 짓인 것을 깨달아 경험을 공유할겸 나중에 내가 보고 다시 하려고 적어둔다. --no-au..