Project

요새 핫하다는 Antigravity 나도 한 번 찍먹 해보고자 간단한 포트폴리오 사이트를 만들기로 했다. 최근에 프로젝트하면서 어떤 팀원이 Antigravity 칭찬을 엄청 하셨었다. 우리 프젝 레포지토리를 기반으로(프론트가 전혀 없었던) 웹사이트 만든 걸 보여주셨는데, 결과물이 너무 충격적이었다. 이런 퀄리티가 가능하다고..? 그분이 말씀하시기를 "레포지토리 통째로 넘겨서 프롬프트 위주로 만들었다"라고 하셨는데 정말 그게 가능한가 싶어 직접 경험해보기로 했다. 디자인 잡도리Behance나 Dribble 등의 사이트를 통해 내 마음에 드는 느낌의 포트폴리오 웹사이트 디자인을 찾아 이런 느낌과 비슷하게 해달라고 요청했다. 완전 마음에 쏙 들게는 아니지만 50% 정도는 "이 정도면 괜찮군"할 법한 결과물을..

지난 포스팅에는 API Gateway를 생성하고, Gateway 엔드포인트를 통해 ALB를 거쳐 실제 ECS 서비스의 API를 호출하도록 하는 설정까지 완료했다. 모든 엔드포인트에 대한 배포는 완료되었고, 남은 배포 작업들을 리스트업해보았다. AWS 코드 디플로이 통해서 BLUE/GREEN 배포 하기ECS에 Grafana/Prometheus 설치 및 메트릭 수집 및 대시보드 구성Auto Scailing (트래픽 몰리면 서버 늘어나도록 설정) 한 열흘 올려놨다고 요금이 이정도로 나온다.. (MSK Serverless 클러스터 중간에 삭제하고, 다른 EC2 인스턴스에 있는 Kafka 쓰도록 바꾸었는데도..) 그러나 현재로서는 AWS 요금이 너무 나왔기도 하고.. 현재의 Rolling Update에서 BLUE..

현재 상황 ECS 서비스를 등록하던 중, 계속적으로 대상 그룹 상태가 Unhealthy라고 뜨게 되는 상황을 발견했다. 이 상황으로 인해 헬스 체크 뿐만 아니라 API 엔드포인트 요청조차도 불가능한 상황이 되었다. Cloudwatch에서 로그 봤을 때, product-service라는 ecs 서비스는 정상적으로 돌아가는 상황임을 알 수 있다. 문제 위와 같이 등록된 대상이 "Unhealthy" 상태로 뜨고, 헬스 체크가 실패했다는 메시지가 표시됨. 포스트맨에서 실서버 헬스 체크 했을 경우, 502/503 에러가 계속적으로 뜨는 현상이 발견되었다. 그리고 product-service에서 헬스 체크가 계속적으로 실패하다보니 결국에는 ECS 서비스의 배포 상태도 "롤백 실패"로 끝나게 되는 상태였다..

Secrets Manager에 환경 설정 저장 이전에 RDS, ELASTIC CACHE(REDIS), MSK 클러스터를 생성했을 당시, 각각의 설정 완료 후 생성된 엔드포인트들과 부트스트랩 서버(MSK)의 엔드포인트를 복사해둔다. MSK 클러스터의 BootStrap Servers의 엔드포인트 형식은 아래와 같다. boot-xxxxxxxx.c1.kafka-serverless.ap-northeast-2.amazonaws.com:9098 Secrets Manager에 보안 정보 저장"보안 암호 생성"을 누르고, 보안 암호 유형으로는 "다른 유형의 보안 암호"를 선택한다. 암호화 키는 aws/secretsmanager (기본값)으로 설정해둔다. 키/값은 .env 파일에 정의해둔 모든 환경변수와 보안 정보들로 채..

서론지난 포스팅에서는 사용자가 대기열에 진입(Entry)하는 과정을 정리해보았다. 하지만 진입만으로는 대기열 구현의 끝이 아니다. 사용자는 자신이 언제 입장할 수 있을지 끊임없이 궁금해하며 서버에 상태를 묻게 되는데, 이번 포스팅에서는 이 순번 조회 및 폴링(Polling) 로직을 어떻게 구현했는지 정리해보았다. 목표: 클라이언트에서 대기 요청을 통해 고객을 대기열에 진입하게 한 후, 대기열 순번 조회를 통해 현재 대기 순번을 UI를 통해 보여주는 것 폴링(Polling)이란?하나의 장치(또는 프로그램)가 충돌 회피 또는 동기화 처리 등을 목적으로 다른 장치(또는 프로그램)의 상태를 주기적으로 검사하여 일정한 조건을 만족할 때 송수신 등의 자료처리를 하는 방식 왜 폴링 로직이 필요한가?대기열 시스템에서 ..

서론 일반적인 타임딜 시스템에서는 오픈 직후, "폭발적 트래픽을 감당하는 것"과 "실시간 순번 보장"이라는 요구사항이 충족되어야 한다. 이번 포스팅에서는 대기열 시스템 구현 과정과 왜 해당 방법으로 대기열을 구현하게 되었는지에 대해 정리해보고자 한다. 왜 대기열이 필요할까? 타임딜의 핵심은 한정된 자원(재고)을 선착순으로 배분하는 것이다. 모든 요청을 곧바로 주문 서비스(DB)로 흘려보내면 아래와 같은 문제가 발생하게 된다.DB 커넥션 고갈: 수만 개의 트랜잭션이 한꺼번에 DB에 붙으려다 시스템이 멈추게 된다.부정확한 순서: 네트워크 지연 등으로 인해 나중에 온 사람이 먼저 처리될 수 있다.서비스 불능: 특정 서비스의 과부하가 전체 시스템(MSA)으로 전파될 수 있다. 현재 타임딜 프로젝트에서는 사용자들..

서론 타임딜 플랫폼의 핵심은 타임딜 오픈 직후, 폭주하는 트래픽을 제어하여 시스템을 보호하는 것이다. 이를 위해 설계된 Queue Service의 아키텍처와 도메인 구조를 DDD(Domain-Driven Design)와 헥사고날 아키텍처(Ports & Adapters Pattern)을 적용하여 코드를 작성하기로 하였다. 본론우리 대기열 서비스는 외부의 기술적 변화(Redis, Kafka, DB 등)로부터 핵심 비즈니스 로직을 격리하기 위해 헥사고날 아키텍처를 채택하기로 하였다. 다시 말하면 도메인(비즈니스 로직)이 외부 기술에 의존하지 않도록 격리하는 것이다. 따라서 계층 구조를 아래와 같이 구성하였다. 패키지 구조com.rushcrew.queue├── application # [애플..

서론 우리 타임딜 서비스 프로젝트에서의 대기열(Waiting Queue)의 목적은 "여러 사용자들이 몰릴 경우, 사용자의 주문 요청을 튕겨내지 않고 줄을 세워서 붙잡아두는 것"이다. 또한, 서비스 지속성 면에서의 목적으로는 대규모의 사용자가 주문을 요청할 경우, 주문(Order) 서버의 DB에 엄청난 부하가 가해지기에 서버 쪽에서 장애가 나거나 죽을 수도 있다. 따라서 대기열(Queue) 서버에서는 이러한 대규모 트래픽 상황에서의 DB 부하를 최소화하기 위해 Redis를 기반으로 대기열 데이터 구조를 설계하게 되었다. 본론 대기열 서비스에서 쓰일 Redis 큐를 다음과 같이 정의했다. Waiting Queue(대기열) : 주문 페이지에 입장하기까지 대기하는 상황Active Queue(활성열) : 주문 페..