팝콘도팝이다

요구사항과 문제 정의공연에 대한 조회 시 조회한 공연의 조회수를 늘려주는 기능이 존재한다. 조회수를 단순히 1 늘려주는 작업이며 DB에 접근하며 수정이 진행된다.여러 트랜잭션에서 조회수 갱신 시도 시 조회수가 예상보다 적은 수치로 기록되는 동시성 문제가 발생한다. 해당 조회수는 다른 API의 조회 기능에서 사용되며, 실시간으로 반영되어야 하기에 아키텍처의 Redis INCR 연산으로 미리 계산해두어 주기적으로 DB 반영하는 방법은 고려할 수 없었다. 공연을 조회하는 API에서 조회수 갱신이 같이 수행되고 있다.현재, 조회수를 갱신하는 API에는 크게 두가지 문제점이 존재한다. 문제1: 조회수 동시성 문제여러 트랜잭션이 동시에 조회수 증가 업데이트 요청 시 조회수가 정확하지 않게 갱신될 수 있다.문제2: ..

서버 배포와 함께 모니터링을 세팅하면서 다음과 같은 의문이 들었다.Spring Actuator가 기본으로 제공하는 메트릭으로는 파악하기 어려운 부분을 모니터링할 수 없을까?  특히나, 외부와 상호작용하거나 통신하는 부분을 모니터링하고 싶었다. 이러한 부분들에 대한 커스텀 메트릭을 만들기로 결정하였다. 다음과 같은 부분을 타겟으로 success, failure 횟수와 소요 시간을 메트릭화 하고자 한다.OpenAPIInternal API (core alarm)Redis Pub/Sub 모니터링을 위한 메트릭 추가를 횡단 관심사로 보았고, 각 메서드마다 이름을 주어 간편히 사용할 수 있도록 어노테이션과 AOP 기반으로 적용해보았다. 어노테이션, AOP 코드 예시@Target({ElementType.METHOD..

기존 상황 및 문제 정의기존 인프라 비용이 달마다 30만원 이상이 소요되고 있었으며, 딱히 트래픽을 받지 않는 상황에서 과하게 인프라 자원을 사용 중이었다.(ecs-fargate 를 과하게 사용하고 있었다.)이러한 인프라 구성을 개편하여 비용을 줄이고 우리가 예상하는 운영 시 트래픽에 맞게 사용하고 싶었다.이를 위해 작업한 내용을 공유하고자 한다. 다음과 같은 예상되는 초기 유저 수를 고려하고 있으며, 인스턴스의 크기와 개수는 경험을 토대로 프리티어 인스턴스로 충분할 것으로 예상하여 프리티어를 초기 테스트용 인스턴스로 설정했다.예상 유저 수: 100명원하는 처리량: 50 ~ 100tps사용 중인 인스턴스: aws t2.micro (프리티어)메모리: 1GB + swap memory 2GBvCPU: 1성능 ..