이번에 인턴 프로젝트를 진행하면서 인프라를 또 한번 구축하게 됐다.기존에 부트캠프를 진행하면서 팀원이 구축해둔 배포 인프라에서 OIDC와 SSM을 적극 활용하면서 보안 측면에서 고도화 해봤는데 이번에는 기존에 팀원이 구축한 Blue-Green 무중단 배포 인프라와 내가 고도화 시켰던 인프라를 접목해보았다. 구축해본 배포 인프라에 대해 정리하고자 한다.인턴 프로젝트는 보안 문제 때문에 구체적인 구현이나 코드를 공유하지 못할 것 같다.기존 방식의 문제일반적인 배포 방식은 다음과 같다. 1. 서버 중지2. 새 버전 코드 배포3. 서버 재시작 이 방식에서는 반드시 서버의 다운타임이 발생한다.그동안에는 규모도 작고 외부서비스도 별게 없어서 크게 문제가 없었는데 점점 규모가 있는 프로젝트를 진행하게 되면서 배포할 ..

전자상거래 플랫폼 백엔드 프로젝트를 진행하면서 Prisma ORM으로 쿼리들을 작성했는데 갱신 손실 문제가 발생해 해당 로직에서 사용되는 쿼리들을 Raw Query로 튜닝하여 해결하였다.그 과정을 정리하려고 한다.문제 상황주문 API에서 주문 데이터를 새로 생성할 때 사용자가 요청한 주문 수량과 실제 DB에 주문 가능 한 재고 수량을 계산해서 주문 데이터 생성을 진행해야한다.// 1. 주문 생성 const result = await this.prisma.$transaction(async (tx) => { // 주문 아이템 기준으로 재고 먼저 확보 (재고 locking) for (const item of builtData.matchedOrderItems) { const ..

이번 글에서는 저번에 이어 알림 발송 시스템 구축에 대해 자세히 작성하려고 한다.로그나 메트릭 수집 세팅과 달리 알림 발송은 전부 aws 콘솔에서 진행했고 모니터링의 용도 보다 범용적으로도 사용이 가능해서 아에 글을 분리하려고 했다.AWS SNS(Simple Notification Service)Amazon SNS는 내구성이 뛰어나고 안전한 고가용성의 완전 관리형 게시/구독 메시징 서비스이며, 이 서비스를 이용하면 마이크로서비스, 분산 시스템 및 이벤트 기반 서버리스 애플리케이션을 쉽게 분리할 수 있습니다. Amazon SNS는 많은 처리량이 필요한 푸시 기반 다자간 메시징을 위한 주제를 제공합니다.푸시 알림 서비스 - Amazon Simple Notification Service(SNS) - AWS 푸..

저번 글까지 해서 기존의 배포 환경을 고도화 해가는 과정에 대해 어느정도 정리했다.이번 글에서는 cloudwatch와 lambda를 통해 모니터링 및 알림 시스템을 구축하고 적용하는 내용에 대해 정리하려고 한다.CloudWatch vs Prometheus내가 이번에 구축해본 cloudwatch 보다 대부분 prometheus + grafana의 조합을 많이 사용하는 것 같다.일단 프로메테우스가 오픈소스이기 때문에 별도의 비용이 안들고 클라우드 와치에 비해 대시보드도 예쁘게 꾸밀 수 있기 때문인 것 같다.하지만 내가 일단 클라우드 와치로 모니터링 시스템을 구축한 이유는 프로메테우스와 그라파나의 조합은 별도의 모니터링 서버를 구성해서 운영해야한다.그래서 일단 모니터링에 대해 이해하고 빠르게 결과를 보기 위해..

저번 글에 이어서 이번엔 run command에 대해서 정리하려고 한다.run command도 parameter store와 마찬가지로 ssm의 도구 중 하나다.또한 run command도 aws 인프라이기 때문에 iam을 통해 접근 제어를 할 수 있어 관리가 편하다.Run Command의 정의AWS Systems Manager의 도구인 Run Command를 사용하여 관리형 노드의 구성을 원격으로 안전하게 관리할 수 있습니다. 관리형 노드는 Systems Manager용으로 구성된 하이브리드 및 멀티클라우드 환경의 모든 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 또는 비 EC2 시스템입니다. Run Command를 사용하면 일반적인 관리 작업을 자동화하고 대규모로..

parameter store는 aws ssm(systems manager)의 도구 중 하나다. 먼저 systems manager는 aws, 온프레미스, 멀티 클라우드 환경에서 노드를 대규모로 관리하고 운영할 수 있도록 도와준다고 나와있다.쉽게 생각하면 이름대로 시스템 관리자의 역할을 하는 통합 툴 같은 느낌이다. systems manager의 도구들로는 patch manager, session manager, parameter store, run command 등 다양한 도구들이 있다.이 도구들은 노드 도구, 애플리케이션 도구, 운영도구 등으로 나누어진다. patch manager, session manager, run command 등이 노드 도구이고 paramter store는 애플리케이션 도구다.도..

지난번에는 aws ssm parameter store를 사용해서 github secret과 배포 스크립트에서 불필요한 운영용 환경변수들을 전부 제거했다.이번에는 aws ssm run command와 OIDC를 사용해서 ssh와 배포용 환경변수들도 최대한 제거해나간 과정을 정리하려고 한다.ssh 없이 ec2에 접근하고 스크립트 실행하기현재 코드 상황에서는 github secret에서 ssh key 값을 가져와 키 파일을 만들고 그 키 파일을 통해 ec2에 접속한다.그 후 ssh로 접속한 ec2 내부에서 배포를 위한 스크립트 들을 직접 실행하게 된다.- name: Setup SSH key run: | mkdir -p ~/.ssh echo "${{ secrets.EC2_SSH_KEY }}" > ~..

이 글에서는 배포 과정에서 환경변수 노출을 최대한 제거 하는 방법을 고민했던 과정에 대해 정리하려고 한다. 현재 배포 상황은 다음과 같다.배포 이미지는 빌드 후 ecr에 push하고, ec2에서 최신 이미지를 pull 해서 docker compose로 띄운다.이런 상황에서 환경변수는 github secret에 저장하고 github actions를 거쳐 ec2 내부에 .env 파일로 복사하게 된다.그 후 docker container에 환경변수 파일로 주입해준다. 이러한 환경변수 주입 방식은 개발 로컬 환경의 .env, github secret의 환경변수를 모두 관리해줘야해서 실수하기 쉬운 상태였다.또한 배포 환경을 구축하면서 배포에 필요한 환경변수, api server 실행에 필요한 환경변수가 구분없이 ..