정확히는 아기 고양이

고양이도 이력서 쓰는데..

2. 밴드 드럼으로 참가하기

아 이건 피아노

이게 드럼 드럼 하이햇 그렇게 치는 거 아닙니다 - mastermusic

• 원인
  • 레디스 스트림 데드락 발생

    - PostgreSQL의 데드락 대응  : 데드락 감지한 트랜잭션 하나를 강제로 실패 (관련글 : https://velog.io/@halo_3735/데드락-victim희생-트랜잭션-선택-알고리즘

• 원인

  !image.png

  !image.png

  1. 멀티인스턴스구조

     1. 컨슈머 그룹에 의해서 각 인스턴스의 백엔드 서버는 별도의 이벤트를 가져감
        1. 하지만 동일한 내용의 이벤트를 가져가는 것은 컨슈머 그룹이 막을 수 없음
           1. before_update에 들어있는 유저들만 업데이트를 하는 쿼리가 가지고 있는 유저 아이디가 1,2이고
              1. 다른 쿼리가 2,1일때
                 • 서로 1과 2를 가지고있는 상태에서
                 • 2와 1을 락 걸려고 시도하기 때문에
                   • deadlock timeout이 난 것이고
                     • 이것때문에 지연 발생

     데드락 해결방법

     1. Row Lock 순서 보장

  • 근데 트랜잭션 1이 userId 1인 행 락을 계속 잡고 있으면, 다른 트랜잭션들을 기아상태가됨

    가. 최대한 빨리 행락을 잡고있는 요소를 없애기

    1. 카드 수 증가랑 묶여있는 알림 생성을 별도의 트랜잭션으로 분리

       1. 하나의 트랜잭션에서 행락을 계속 잡고있기 때문에
          1. 단점
             1. lock wait가 발생
                1. 동일한 업데이트 형태의 배치 3대가 동시에 돌면 2대는 항상 기다리니까
                   1. 지연
                   2. 다른세션이 lock wait 때문에 db세션을 잡고있다
                      1. 세션 낭비
                         1. cpu 증가

       나. 알림 비동기 처리

    2. 트랜잭션 단위로 락을 잡고있기 때문에 같은 트랜잭션에있는 알림처리를 별도의 트랜잭션으로 분리하여 의존성 낮추기

       !image.png

       • 우선순위 낮다 0.03세션 밖이 안잡아먹어서

    2. ShedLock (분산락)

  1. 하나의 인스턴스만

  2. 단점

     1. ShedLock 잡은 서버가 죽으면 락 만료 전까지 다른 서버도 실행 못 함
        1. 락 TTL 설정
        2. 쿠버네티스 환경에서는 pod로 서버 재시작

     3. 단일 컨슈머

  3. 해당 인스턴스가 죽으면 장애생김

ShedLock (분산락) 어떻게 구현할건데?

계봉 예정작

어떤 것을 희생양으로 삼을 것인가?

• vitim 희생양

• 데드락 victim(희생 트랜잭션) 선택 알고리즘

  • 죽였을 때 손해가 작은 트랜잭션

    • 데드락 감지한 자신이 죽음

      1. 데드락 타임아웃 난 후 락 대기 사이클 확인

          if (FindLockCycle(startProc, softEdges, &nSoftEdges))
          {
              if (nSoftEdges == 0)
                  return -1;      /* hard deadlock detected */
              softFound = nSoftEdges;
          }

         • 사이클이 존재하고 풀 수 없으면 -1 : hard deadlock 판단

      2. 감지한 트랜잭션 에러 받기

         state = DeadLockCheck(MyProc);
         
         switch (state)
         
         ...
         
         case DS_HARD_DEADLOCK:
          Assert(MyProc->waitLock != NULL);
          RemoveFromWaitQueue(MyProc, LockTagHashCode(&(MyProc->waitLock->tag)));
          break;

  • 희생양 고르면 abort

    • abort : 트랜잭션 중단하고 되감기

개봉예정작

참고 : https://www.microsoft.com/en-us/research/publication/time-clocks-ordering-events-distributed-system/?utm_source=chatgpt.com

“시간”은 정말 절대적일까?

우리는 보통 시간을 절대적인 기준이라고 생각한다.

오전 9시는 모두에게 같은 오전 9시이고, 먼저 일어난 일과 나중에 일어난 일은 명확하다고 느낀다.

그런데 아인슈타인은 말했다.

“그건 관찰자에 따라 달라질 수 있다.”

동시에 일어난 사건도 사람마다 다르게 볼 수 있다고?

특수 상대성 이론에서는 두 사건의 순서가 관찰자마다 달라질 수 있다.

어떤 관찰자는:

• A 사건이 먼저 발생했다고 보고

다른 관찰자는:

• B 사건이 먼저 발생했다고 볼 수 있다.

절대적인 “동시”라는 개념이 깨진 것이다.

남는 건 단 하나다.

“영향을 줄 수 있었는가?”

즉, 인과관계(causality)만이 진짜 순서를 결정한다.

그런데 이게 왜 컴퓨터공학이랑 연결될까?

분산 시스템도 똑같은 문제를 겪는다.

서울 서버와 뉴욕 서버는 절대적으로 동일한 시간을 공유하지 못한다.

네트워크 지연은 항상 존재하고, 서버 시계도 미세하게 어긋난다.

그래서 어떤 요청이 “진짜 먼저” 도착했는지를 완벽하게 알 수 없다.

그렇다면 컴퓨터는 순서를 어떻게 판단할까?

여기서 Leslie Lamport가 등장한다.

:contentReference[oaicite:0]{index=0} 는 1978년 논문에서 놀라운 관점을 제시한다.

“실제 시간을 믿지 말자.”

대신:

• 누가 누구에게 영향을 주었는가
• 어떤 이벤트가 어떤 이벤트를 발생시켰는가

즉 “인과관계”만 추적하자는 것이다.

Lamport는 왜 이런 생각을 했을까?

흥미롭게도 Lamport는 직접 말한다.

자신은 특수 상대성 이론을 직관적으로 이해하고 있었고, 그 덕분에 분산 시스템 문제의 본질을 바로 이해할 수 있었다고.

그가 깨달은 핵심은 이것이었다.

“사건에는 절대적인 전체 순서(total ordering)가 존재하지 않는다.”

오직:

• causality
• partial ordering

만 존재한다.

그래서 탄생한 것이 무엇일까?

이 생각은 이후 현대 분산 시스템의 뿌리가 된다.

• Logical Clock
• Vector Clock
• Distributed Consensus
• Paxos
• Raft

같은 개념들이 모두 여기서 시작된다.

오늘날:

• Kafka
• Cassandra
• Google Spanner

같은 거대한 시스템들도 결국은 이 문제와 싸우고 있다.

“시간은 정말 절대적인가?”

그리고 컴퓨터공학은, 생각보다 물리학과 훨씬 가까운 곳에 있었다.

개봉 예정작

1. 해당 쿼리는 한번요청당 평균적으로 0.29ms 지연 시간을 보인다.
   1. 하지만 특정구간 튀는 쿼리들 즉. 100ms를 넘어가는 쿼리가 0.1% 존재한다는거다
      1. 이게 문제가 될지 어떻게 판단하지?

계종 예정작

개봉 예정작

개봉예정작

비슷한 케이스 : https://tech.kakaopay.com/post/jvm-warm-up/

무결하다는 것은 뭘까

정답이 아닌것?

정답이 어딨나

약속을 지키지 않는 것 = 무결하지 않는 것

1.1. 문서 목적

1.2. 목차

1) 개요

2) V2 배포일

3) 각 서비스 별 예상 비용

4) 총합

2. V2 배포일

2026.03.02~2026.03.22, 총 21일

3. 각 서비스별 예상 비용

3.1 고정 비용

3.1.1 인스턴스

📦 EC2 인스턴스 구성

💰 EC2 비용 (21일 기준)

📊 최종 정리

3.2.2 EBS 볼륨

EC2 인스턴스의 애플리케이션 데이터 및 로그 저장을 위해 gp3 타입 EBS 볼륨을 사용하였다.

EBS 구성

비용 산정

• 단가: $0.096 / GB / month
• 총 용량: 194GB

월 비용
= 194GB × $0.096
= $18.62

21일 비용
= $18.62 × (21 / 31)
≈ $12.62

총 비용(21일): $12.62

성능 설정

3.2.3 RDS 스토리지

Release 환경과 Prod 환경에 각각 PostgreSQL RDS 인스턴스를 구성하였다.

RDS 스토리지 구성

비용 산정

• 스토리지 타입: gp3
• 단가: $0.138 / GB / month

월 비용
= 400GB × $0.138
= $55.20

21일 비용
= $55.20 × (21 / 31)
≈ $37.40

총 비용(21일): $37.40

설정

3.2 가변 비용

가변비용은 실제 네트워크 전송량 및 서비스 사용량에 따라 변동되는 비용이다.

3.2.1 데이터 전송 (Internet Out)

외부 인터넷으로 나가는 아웃바운드 트래픽에 대해 과금된다.

퍼블릭 서브넷의 경우 EC2 → IGW → 인터넷, 프라이빗 서브넷의 경우 EC2 → NAT Gateway → IGW → 인터넷 경로로 전송된다.

API 응답 전송, 외부 API 호출, 파일 다운로드 제공 등이 해당되며, 인바운드(수신)는 무료이고 아웃바운드(송신)만 과금된다.

단가

사용량

비용 산정

21일 예상 사용량
= 1.39 GB × 21일
= 29.19 GB

21일 예상 비용
= 29.19 GB × $0.126
≈ $3.68

예상 비용 (21일): $3.68

3.2.2 데이터 전송 (Regional, AZ간)

동일 리전 내 서로 다른 가용영역(AZ) 간 데이터 전송에 대해 과금된다.

예를 들어 AZ-a(10.0.3.x) 와 AZ-b(10.0.4.x) 간 통신이 해당된다.

ALB → EC2(다른 AZ), EC2 → RDS(다른 AZ) 등 AZ 간 내부 통신 시 발생하며, 송신과 수신 양방향 각각 과금된다.

사용량

비용 산정

21일 예상 사용량
= 4.84 GB × 21일
= 101.64 GB

21일 예상 비용
= 101.64 GB × $0.01
≈ $1.02

예상 비용 (21일): $1.02

3.2.3 S3 저장 및 요청

S3 버킷에 저장된 데이터 용량 및 API 요청 수에 따라 과금된다.

파일 업로드/다운로드, 정적 자산 저장, 로그 저장 등이 해당된다.

단가

예상 비용

3.2.4 가변비용 합계

3.3 혼합 비용

혼합비용은 리소스가 존재하는 시간에 따라 발생하는 고정비용과, 실제 데이터 처리량에 따라 발생하는 가변비용이 함께 포함되는 비용이다.

3.3.1 NAT Gateway

프라이빗 서브넷의 리소스가 인터넷에 접근할 때 사용되는 게이트웨이이다.

NAT Gateway가 존재하는 것만으로 시간당 요금이 발생하며, 이를 통해 처리되는 데이터량에 따라 추가 요금이 발생한다.

프라이빗 서브넷의 EC2가 외부 API 호출, 패키지 다운로드 등 인터넷 접근 시 사용된다.

단가

구성

비용 산정

고정 비용
= $0.045 × 24h × 21일
= $22.68

가변 비용
= 데이터 처리량 기반
≈ $0.50

소계: $23.18

3.3.2 VPC Endpoint (Interface)

프라이빗 서브넷에서 AWS 서비스에 접근할 때 인터넷을 거치지 않고 AWS 내부 네트워크를 통해 연결하는 엔드포인트이다.

SSM(Session Manager), EC2 Messages 등 AWS 관리형 서비스 접근 시 사용된다.

엔드포인트가 존재하는 것만으로 시간당 요금이 발생하며, 통과하는 데이터량에 따라 추가 요금이 발생한다.

단가

구성

비용 산정

고정 비용
= 5개 × $0.01 × 24h × 21일
= $25.20

가변 비용
= 데이터 처리량 기반
≈ $0.10

소계: $25.30

3.3.3 ALB (Application Load Balancer)

들어오는 트래픽을 여러 EC2 인스턴스에 분산하는 로드밸런서이다.

ALB가 존재하는 것만으로 시간당 요금이 발생하며, 처리하는 트래픽량에 따라 LCU(Load Balancer Capacity Unit) 요금이 추가된다.

단가

구성

비용 산정

고정 비용
= 2개 × $0.0225 × 24h × 21일
= $22.68

가변 비용
= LCU 사용량 기반
≈ $2.00

소계: $24.68

3.3.4 RDS (Relational Database Service)

관리형 관계형 데이터베이스 서비스이다.

인스턴스가 실행 중인 시간에 대해 요금이 발생하며, gp3 스토리지의 경우 기본 IOPS(3000)가 포함되어 있어 일반적인 워크로드에서는 추가 I/O 비용이 발생하지 않는다.

백업은 할당된 스토리지 용량까지 무료이며, 초과 시 추가 요금이 발생한다.

단가

구성

비용 산정

고정 비용
= 2개 × $0.056 × 24h × 21일
= $56.45

가변 비용
= I/O, 백업 초과분
≈ $0.00

소계: $56.45

3.3.5 CloudWatch

AWS 리소스의 모니터링 및 로그 관리 서비스이다. 기본 메트릭(EC2, RDS 등)은 무료로 제공되며, 커스텀 메트릭과 10개 초과 알람은 추가 과금된다. 로그는 수집 시 GB당, 저장 시 GB/월 단위로 과금된다.

단가

구성

비용 산정

고정 비용
= 2개 × $0.10 × 0.68
= $0.14

가변 비용
= 0.11GB × $0.03 × 0.68
≈ $0.01

소계: $0.15

3.3.6 Route 53

AWS의 DNS 서비스이다. 도메인의 DNS 레코드를 관리하는 호스팅 존당 월 고정 요금이 발생하며, DNS 쿼리 수에 따라 추가 요금이 발생한다.

단가

구성

비용 산정

고정 비용
= 1개 × $0.50 × 0.68
= $0.34

가변 비용
= DNS 쿼리 수 기반
≈ $0.01

소계: $0.35

3.3.7 Parameter Store

AWS Systems Manager의 구성 데이터 및 시크릿 관리 서비스이다. 표준 파라미터는 무료이며, 고급 파라미터는 파라미터당 과금된다. 현재는 표준 파라미터만 사용 중인 것으로 가정하였다.

단가

구성

비용 산정

고정 비용
= 표준 파라미터 무료
= $0.00

가변 비용
= API 호출 무료
= $0.00

소계: $0.00

3.3.8 ElastiCache (Valkey/Redis)

인메모리 캐시 서비스로 세션 관리, 캐싱 등에 사용된다. Valkey(Redis 호환) 엔진을 사용하며, 인스턴스 실행 시간에 대해 고정 과금되고 백업 스토리지와 데이터 전송에 대해 가변 과금된다.

단가

구성

비용 산정

고정 비용
= 2개 × $0.019 × 24h × 21일
= $19.15

가변 비용
= 백업/전송량 기반
≈ $0.00

소계: $19.15

3.3.9 Amazon MQ (RabbitMQ)

메시지 브로커 서비스로 서비스 간 비동기 통신에 사용된다. RabbitMQ 엔진을 사용하며, 브로커 인스턴스 시간과 스토리지에 대해 고정 과금되고 데이터 전송에 대해 가변 과금된다.

단가

구성

비용 산정

고정 비용
= 2개 × $0.034 × 24h × 21일
= $34.27

가변 비용
= 메시지/전송량 기반
≈ $0.10

소계: $34.37

3.3.10 DMS (Database Migration Service)

데이터베이스 마이그레이션 서비스로 무중단 배포 시 DB 동기화에 사용된다. 복제 인스턴스 실행 시간에 대해 고정 과금되며, 전송 데이터량에 따라 추가 비용이 발생한다. 아래 비용은 2월 실제 사용량을 기준으로 산정하였다.

단가

사용량

비용 산정

고정 비용
= 219h × $0.070
= $15.33

가변 비용
= 0.49 GB × $0.02
≈ $0.01

소계: $15.34

3.3.11 혼합비용 합계

4. 총합

총 예상 비용은 고정비용, 가변비용, 혼합비용을 합산하여 산정하였다.

4.1 비용 합계

4.2 산정식

총 예상 비용
= 고정 비용 + 가변 비용 + 혼합 비용
= $165.33 + $4.71 + $198.97
= $369.01

4.3 최종 정리

2026.03.02부터 2026.03.22까지 총 21일간 MINE 서비스 인프라를 운영할 경우 전체 예상 비용은 $369.01로 산정된다.

1.1 문서 목적

FI와 ASG 제한 걸린 상황일 때, 장애 알림과 대응에대한 하나의 케이스를 정리한 문서이다.

1.2 목차

1) 개요

2) 준비

3) 실행

4) 결과

5) 대응 방법

6) 도입 후 개선된 사항

7) 고찰

2. 상황

백엔드 인스턴스가 2개가 디폴트인 ASG에서 하나가 문제가 생겨 다운되었지만, ASG 자체에 문제가 생겨 인스턴스가 띄워지지 않아 트래픽 분산이 정상적으로 이루어지지 않는 상황

2.1 부하테스트

• soak 테스트
• 동시접속자 3000명
• Get /categories
• 10분

2.2. FI

• 백엔드 인스턴스 1개 중지
• FIS Action: aws:ec2:stop-instances
• 대상: mine_mvp1_be_asg 중 1개
• 주입 시간: 5분

2.3. ASG 제한

• 백엔드 Release 서버 ASG 그룹 새로운 인스턴스 Lanch 정지

  

  • ASG의 장애를 표현하고자함

2.4. API Base Line

부하 없었던 정상 트래픽을 가지고 있는 release 서버 2026.02.20 00:00:00 ~ 2026.03.01 11:59:59 시간대 API별 p95 API 응답 속도 리스트 사용

3. 실행

3.1 순서

1) 부하테스트 실행

2) FI 실행

3) 알림 관측

4. 결과 예상

가. 모니터링

• get /catergories 의 초당 요청 횟수 증가
• get /catergories 200 응답 퍼센테이지 감소
• get /catergories의 API p95 응답지연 증가
• get /catergories의 API p99 응답지연 증가

나. 알림

1) Discord 인스턴스 수 부족 경고

2) Discord API 응답시간 경고

3) Discord 500 에러 증가 경고

4. 결과

4.1.1 모니터링

P95가 21:06분부터 baseline을 넘어 5분동안 지속되고 21:12분에 23.04ms를 찍는 것을 확인할 수 있다.

4.1.2 Discord asg 인스턴스 수 부족 경고

인스턴스의 개수가 크기조절 한도 최소값보다 작은 asg에 문제가 있는 상황에 대한 알림이 도착

4.1.3 API 응답시간 지연 알람

4.1.1 에서 언급한, 5분동안 baseline을 넘은, 21:12분에 23.04ms /categores api 응답시간 지연 감지 알림이 도착

4.1.4 Discord 500 에러 증가 경고

500에러가 발생하지 않아 해당 알림이 오지 않았다.

5. 대응 방법

5.1 AWS ASG 접속해서 문제 해결

5.2 인스턴스 정상 복구 알림 대기

ASG가 정상적으로 동작하여 최소 개수보다 인스턴스가 띄워지면 해당알림이 도착한다.

5.3 트래픽 관측

4.1.3의 알림에 나온 바로가기 (http://localhost:3333/d/adx8tjx)의 PR 95 Requests Duration 패널과 2.4의 API baseline을 참고하여 응답시간 정상화를 확인한다.

5.4 장애 대응 일지 작성

6. 도입 후 개선된 사항

1) 개발자 혹은 인프라 팀원들에게 장애를 알림을 알려주어 발생시 즉시 조치할 수 있을 뿐더러, 대응 프로세스까지 제공하여 조치에 걸리는 시간을 줄일 수 있다.

2) 팀원들과 장애를 공유하여 같은 장애가 일어날 시, 추적에 용이하다.

7. 고찰

1) 새로 띄워진 인스턴스 자체에 문제가 생기는 경우에 대한 알림 추가 필요

2) 해당 값이 100% 참값은 아니기 때문에 지속적인 baseline에 대한 지속적인 유효성 검사 필요

가. 문서 목적

이분탐색에 대해 정리한 글이다.

나. 목차

2. 시간 복잡도

모든 알고리즘에서 시간복잡도는 빼먹을 수 없다. 왜냐하면 가장 효율적인 알고리즘을 찾아 컴퓨터 연산량을 줄임으로서 회사에게 이득이 될 수 있고 빠른 사용자 응답 제공으로 이탈률을 줄일 수 있기 때문이다.

이분탐색의 시간복잡도는 정렬 후에 빨라진다. 만약 탐색을 한번만하고 대상 배열을 안 쓸 예정이라면 정렬을 할 필요가 없다. 왜냐하면 정렬에는 O(nlogn)이 사용된다. 만약 당신이 병합 정렬을 쓴다면 말이다. 순차탐색은 n 이므로 한번만 할 시에는 O(n)이다. 하지만 만약 여러번의 탐색을 진행한다면 이야기가 달라진다. 순차탐색은 매번 O(n)을 여러번인 n번 만큼 진행하기 때문에 시간복잡도는 O(n^2)을 의미한다. 하지만 이분탐색은 O(logn)을 여러번인 n번 만큼 진행한다면 O(nlogn)이 되므로 순차탐색보다 빠르다. 여기서 집중해야할 점은 한번 탐색하는게 아닌 여러번 탐색하는 경우에 이미 정렬된 배열을 1/2씩 쪼개면서 탐색하는 이분탐색은 O(logN)의 성능을 가졌기 때문으로, 매번 O(n)이 시행되어야 하는 순차탐색보다 빠르다는 것이다.

결국 이분탐색은 초기 O(nlogn)인 정렬만 해주면 되는 처음에만 힘이 빡 들어가는 그 뒤에는 순탄한 알고리즘 인 것이다.

하지만 새로운 데이터가 계속 추가된다면? 그때는 이분탐색을 사용해서 들어갈 위치를 찾고 그 위치의 뒤에 원소들을 한칸씩 뒤로 밀면 되므로, O(logn) + O(n) = O(n)이 된다.

3. mid

(left+right) // 2 = mid

4. 진행 방법

mid를 먼저 구하고 찾고자 하는 값이 mid면 그 값이나 인덱스를 출력한다. 만약 아니라면 mid와 대소비교를 진행한다. mid보다 크면 left = mid +1, 작다면 right = mid -1이다.

5. 키워드

• left = mid + 1
• right = mid - 1
• left <= right : 결국 마지막에 같은 값이 되서

6. 느낀점

내 생각에 알고리즘은 뚝심이다. 끝까지 풀어서 모든 로직의 이유를 경험하여 직관적으로 풀 수 있게 만드는 "뚝심"

7. 시간초과

import sys

input = sys.stdin.readline

N = int(input())

a = sorted(list(map(int, input().split())))


M = int(input())


n_arr = list(map(int, input().split()))

def bs(n):
    left = 0
    right = N-1


    while left <= right:
        mid = (left + right) // 2

        if n == a[mid]:
            return mid

        elif n <= a[mid]:
            right = mid -1

        else:
            left = mid + 1
    return -1


def find_left_right(idx, n):
    origin_idx = idx
    cnt = 1
    start_idx = 0
    end_idx = N-1

    # 왼쪽 찾기
    while idx > 0 :
        idx -=1
        if a[idx] == n:
            cnt+=1
        else:
            break

    idx = origin_idx
    # 왼쪽 찾기
    while idx < end_idx :
        idx +=1
        if a[idx] == n:
            cnt+=1
        else:
            break

    return cnt       


    # 오른쪽 찾기

ans = []
for n in n_arr:
    cnt=0
    idx = bs(n)

    if idx == -1:
        cnt = 0
    else:
        cnt = find_left_right(idx, n)

    ans.append(cnt)

for i in ans:
    print(i, end=" ")

8. 문제

가. 백준 1920

import sys

input = sys.stdin.readline


N,K = map(int, input().split())

a=[]

for i in range(N):
    a.append(int(input()))


# 이분탐색

max_num = max(a)

left = 1
right = max_num
ans = 0

while left <= right:
    mid = (left + right) //2
    cnt = 0

    for i in a:
        cnt += i//mid


    if cnt >= K :
        left = mid + 1
        ans = mid

    else:
        right = mid - 1

print(ans)



# 결론
# 1. 더 긴 선의 길이로 얻고자하는 선의 개수만큼 얻을 수 있다면
#   mid보다 큰 값 = left = mid + 1로 탐색을 진행하면 되고

# 2. 얻고자하는 선의 개수를 만족하지 않아, 선을 더 작게 가져가야 한다면
#   mid보다 작은 값 = right = mid - 1로 탐색을 진행해야 한다.

1.1 문서 목적

여러 인스턴스로 되어있는 우리 서비스의 트래픽과 각종 지표들을 하나의 모니터링 서버에서 관측해보자

1.2 목차

1) 개요 2) 각 서비스별 매트릭 수집 3) 남은 서비스 매트릭 발산 로직 추가 4)

2. 각 서비스별 매트릭 수집

2.1 현재 상황

현재 프론트와 백엔드는 매트릭을 수집중이고 AI는 진행되고 있지 않다. DB는 로컬에서 매트릭을 수집하였지만 AWS RDS로 변경되어 매트릭을 수집을 추가해야한다.

2.2 해야할 것

현재 RDS와 AI의 매트릭을 수집해야한다.

3. 남은 서비스 매트릭 expose 로직 추가

3.1 현재 남은 서비스

현재 AI와 RDS 매트릭 발산 로직을 추가해야한다.

3.2 AI

AI 서버 성능 지표 측정을 위한 메트릭 expose 구현

3.3 RDS

4. 프로메테우스

로컬에서 아래 명령어 치고 localhost:9090 으로 접속

aws ssm start-session \
  --target i-0fc15744c6ed54094 \
  --document-name AWS-StartPortForwardingSession \
  --parameters '{"portNumber":["9090"],"localPortNumber":["9090"]}' \
  --region ap-northeast-2

5. 그라파나

로컬에서 아래 명령어 치고 localhost:3000 으로 접속

aws ssm start-session \
  --target i-0fc15744c6ed54094 \
  --document-name AWS-StartPortForwardingSession \
  --parameters '{"portNumber":["3000"],"localPortNumber":["3000"]}' \
  --region ap-northeast-2   

5.1 문제 1

현재 126, 49가 ai prod 인스턴스들인데,

ai prod 1 : 10.0.4.126 ai prod 2 : 10.0.3.49

인데, 10.0.4.126 밖이 그라파나에 안나오고

이건 외국인 즉 시간복잡도, Time Complexity를 이름 붙인 서양인의 관점에서 생각해보아야 한다.

복잡하다는 감정적인 단어보다 왜 복잡이라는 단어가 나왔는지 이유에 대해 봐야한다. 해당 설명에서는 "여러 부분"이라는 단어가 나왔다. 이 키워드에 집중을 해보자

여러 부분이라는게 뭘 의미하는 걸까?

단순한 순차탐색인 O(n)이라면 하나의 배열에서 모든게 이루어진다. 그러면 하나의 부분일까? 아니다. 해당 배열에서도 연산구조가 여러개로 나뉜다. 바로 루프와 조회 등등이다.

이러한 관점에서 보면 모든 알고리즘은 여러 연산 구조로 이루어져있기 때문에 "복잡도"라는 단어를 쓰는 것이 타당한 것이다.

하지만 왜 하필 "시간"일까.

왜 하필 시간일까?

여러 연산이 걸리는 횟수를 표현한 것이기 때문에 횟수 복잡도가 맞지 않을까? 시간이 먼저는 아니지 않는가. 연산횟수가 적어지면 연산 시간이 줄어들거 아닌가.

과연 그럴까? 연산횟수가 무조건 적은 연산이 연산 시간이 적다고 말할 수 있냐는 말이다. "시간"이라는 단어가 붙은 이유는 이러한 현실적인 예외 속에 있다.

CPU는 항상 같은 연산 횟수를 처리할 때, 동일 연산 시간이 보장되어 지지 않는다. 다양한 변수들이 존재하기 때문이다. 메모리, 유동적인 클럭 등 다양한 이유들이 그 예시이다. 따라서 인간의 관점에서 인간의 문제를 해결할 수 있는데, 사용할 수 있는 인간이 정해놓은 지표인 "시간"을 사용하는 것이다.

그래서 시간 복잡도가 뭔데

결론은 시간복잡도는 여러부분으로 이루어진 인간이 측정할 수 있는 시간이라는 단위를 사용하여 포장한 "연산 횟수"를 의미한다.

복잡도라는 단어를 쓰는 이유는 여러 연산 로직이 들어가 있어서 이고 시간이라는 단어를 쓰는 이유는 CPU 동일 연산 시간별 동일 연산 횟수를 보장하지 않기 때문에, 인간 입장에서 절대적으로 측정할 수 있는 지표인 시간을 사용한 것이다. (해당 지표를 써서 컴퓨팅 자원 소모를 아낌으로서 비용 및 시간적인 측면에서 아낄 수 있고 이는 회사의 성장으로 이어진다)

1. 개요

1.1 문서 목적

이 문서는 Mine 서비스의 클라우드 운영 비용을 예측하기 위해 작성되었다.

1.2 Mine 서비스 MVP1 범위

2026년 2월 2일부터 3월 2일까지 29일동안 운영된다.

1.3 MVP1 단계에서 비용 예측이 필요한 이유

Mine 서비스는 자체 사내 인프라가 구축되어있지 않고 현재 클라우드 서비스를 사용중이며 해당 서비스를 지출할 돈이 없으면 서버 운영을 할 수가 없는 상황이다. 따라서 해당 서비스에 투자된 1,000,000원보다 운영 비용이 커지면 지속적인 운영이 어려워지고 이러한 상황을 사전에 방지하기 위해 비용 예측을 진행하여 위와 같은 문제를 방지할 예정이다. 이 문서는 위와 같은 목적으로 작성되었다.

2. MVP1 클라우드 구성

2.1 MVP1에서 사용 중인 AWS 서비스

• t4g.medium 인스턴스 2개 (dev/prod 각 1개)
• EBS 볼륨 30 GiB × 2 (dev/prod 각 1개)
• EBS 스냅샷 30 GiB × 2 (dev/prod 각 1개)
• 퍼블릭 IP 2개 (dev) / 2개 (prod)
• 데이터 전송 (리전 내)
• 기타 사용량 유형 없음 (dev/prod 반씩)

2.2 전체 아키텍처 간단 요약

현재 운영서버와 프로덕션 서버를 동일한 환경에서 운영중이다. 이에 따른 요금도 동일하게 나온다.

3. MVP1 비용 예측을 위한 기준

3.1 고정 비용

• EC2 인스턴스 비용
• EBS 볼륨 기본 프로비저닝 비용
• 퍼블릭 IP 사용 비용

3.2 변동 비용

• 스토리지 IOPS : 프로비저닝 비용 + 초과비용
• 스토리지 처리량 : IOPS랑 동일한 형식
• EBS 스냅샷: 변경된 블록만 증분식 저장 비용 발생
• 사용량 유형 없음

주의: 현재 IOPS와 처리량은 무료 범위 내이며, 추후 MAU 증가 시 측정 필요

4. MVP1 기간 동안의 비용 예상

4.1 고정 비용

4.2 변동 비용

4.3 비용 총합

5. 추가적인 비용 추적 필요한 사항

5.1 필요사항

• 스토리지 처리량 : 100만 MAU시, 평균 처리량 측정 필요
• 스토리지 iops : 100만 MAU시, 평균 iops 측정 필요

5.2 추적 방법

node_exporter 설치 후 매트릭을 프로메테우스로 수집하여 그라파나로 추적 예정

5.2.1 iops

• 읽기 IOPS: node_disk_reads_completed_total
• 쓰기 IOPS: node_disk_writes_completed_tota
• 최종 IOPS = 읽기 IOPS + 쓰기 IOPS = node_disk_reads_completed_total+node_disk_writes_completed_total

5.2.2 처리량

• 읽기 바이트: node_disk_read_bytes_total
• 쓰기 바이트: node_disk_written_bytes_total
• 최종 바이트 = 읽기 바이트 + 쓰기 바이트 = node_disk_read_bytes_total + node_disk_written_bytes_total

5.3 추후 MVP2 비용 산정에 반영

해당 수치들을 일일 및 월별로 측정하여 비용산정에 반영 예정

6. 비용 감소 가능 항목

6.1 비용 감소 가능 항목 리스트

• EC2 로그 S3 이전을 통한 로컬 디스크 사용량 감소
• 불필요한 EBS 스냅샷 생성 최소화

6.2 적용 방법

6.2.1 EC2 로그 S3 이전

• EC2에 쌓이는 로그 파일을 정기적으로 S3로 이동
• 로컬 디스크 사용량 감소 → EBS 볼륨 추가 확장 비용 절감
• 장기 보관 로그는 S3 Standard-IA나 Glacier 사용으로 비용 최소화

6.2.1 스냅샷 생성 주기 조정

• 자동 스냅샷 정책을 주기별(예: 주 1회)로 설정
• 사용하지 않는 스냅샷은 주기적으로 삭제

7. 정리

7.1 MVP1 운영 가능 여부 판단

예상 총 운영 비용은 약 28.242 US$로, 계획된 예산 1,000,000원 내에서 충분히 운영 가능하고 고정 비용과 변동 비용 모두 MVP1 수준에서는 큰 변동이 없으며, 스냅샷 주기 조정과 로그 S3 이전 등 최소한의 비용 최적화로 안정적 운영이 가능하다.

7.2 100MAU 대비 MVP2 확장 시 고려해야 할 비용 요소

7.2.1 스토리지 IOPS 및 처리량 증가

MAU 증가로 디스크 읽기와 쓰기 요청량이 증가하면서 EBS 비용이 상승할 가능성이 있으며, 이를 대비해 부하 테스트와 모니터링을 통해 비용을 재고려해야한다.

7.2.2 오토스케일링을 위한 AWS 로드밸런서 비용 고려

멀티 인스턴스 구성 시 ASG와 ALB(Application Load Balancer) 도입이 예정이며, ALB의 시간당 과금과 LCU(Load Balancer Capacity Unit) 기반 변동 비용이 추가로 발생한다. 또한 인스턴스 수 증가에 따른 퍼블릭 IP 비용도 함께 고려해야 한다.

7.2.3 데이터베이스 분리 및 관리형 서비스 전환 비용

현재 EC2 내에서 운영 중인 데이터베이스를 RDS 등 관리형 서비스로 분리할 경우, 인스턴스 비용과 스토리지 비용이 별도로 발생하며 DB 장애 대비 Multi-AZ 구성 시 비용이 약 2배로 증가할 수 있으므로 DB 분리 시점과 스펙을 검토해야 한다.

1. 필요성

모니터링은 서버가 문제에 생겼을시, 문제가 어느 지점인지 빠르게 파악하고 해결하기 위해서 진행한다. 예를들어 모니터링의 지표를 확인하여 DB에 병목이 생겨 문제가 생긴 것을 알았다면 쿼리를 최적화를 시켜 개수를 줄이는 방향으로 DB IO 문제를 해결할 수 있다.

• 유진 수정

  MINE 서비스는 음성 입력 → AI 분석 → 피드백 생성까지 하나의 학습 흐름이 길고,

  각 단계가 Backend(Spring Boot) · AI(FastAPI) · DB(PostgreSQL) 에 걸쳐 분산되어 있다.

  이로 인해 장애나 지연이 발생했을 때 단순히 “느리다 / 안 된다” 수준으로는 문제 지점을 즉시 특정하기 어렵다는 문제가 있었다.

  따라서 모니터링의 목적은 다음과 같다.

  • 장애 발생 시 프론트·백엔드·DB·AI 중 어느 계층이 병목인지 즉시 구분

  • “CPU 문제인지 / DB 병목인지 / 쿼리 문제인지”를 지표 기반으로 판단

  • 사용자 학습 흐름(녹음 → 분석 → 피드백)이 끊기지 않도록 선제 대응

    예를 들어,

  • API 응답 시간이 증가했을 때

    → 백엔드 CPU 사용률은 낮고

    → DB Connection 수와 Cache Miss 비율이 급증한다면

    → DB 병목으로 판단하고 쿼리/커넥션 풀을 우선 점검할 수 있다.

즉, 모니터링은 단순 상태 확인이 아니라

“**장애의 원인을 빠르게 좁히기 위한 도구**”로 활용하기 위해 구축하였다.

2. 필요한 데이터 지표 설정

• 모니터링 지표는 다음 기준으로 선정하였다.
  • 실제 장애 상황에서 원인 분리에 도움이 되는가
  • 각 파트(프론트 / 백엔드 / DB)가 “우리 쪽 문제인가?”를 지표로 설명할 수 있는가
  • 학습·대결·챌린지처럼 트래픽이 몰리는 시점의 병목을 파악할 수 있는가

특히 MINE은

• 실시간 요청(녹음, PvP)
• AI 분석처럼 처리 시간이 긴 작업

이 혼합된 구조이기 때문에 단순 트래픽 지표보다 “지연 원인을 설명해주는 지표”를 우선적으로 선택했다.

2.1 백엔드

2.2 프론트

• 프론트는 “서버는 정상인데 사용자는 느리다고 느끼는 상황”을 판단하기 위해 체감 성능 지표(Core Web Vitals 중심)로 선정했다.

2.4 DB

• DB 지표는 API 지연 발생 시 원인이 DB인지 여부를 판별하는 핵심 기준으로 사용한다.

2.4 AI 서비스

• https://grafana.com/grafana/dashboards/16110-fastapi-observability/
• 성능지표

위와같이 문제상황이나 서비스 성능 향상에 필요한 데이터가 필요하다고 판단되었고 해당 데이터 위주로 모니터링 환경 패널들을 구축할 예정이다.

3. 도구 선정

2에서 선정한 리소스에 병목이 혹은 부하가 생기는지 관측하기 위한 매트릭또한 얻어야했고 GUI가 필요하였다.

3.1 매트릭 수집 도구

3.2 GUI 도구

결론적으로 프로메테우스와 그라파나를 선정하였다.

4. 매트릭 추출

4.1 백엔드

• 백엔드 매트릭을 acutrator를 사용하여 수집하였다.

4.1.1 매트릭 분석 예시

API별 평균 응답시간을 계산해보았다.

http_server_requests_seconds_count{application="mine",error="none",exception="none",method="GET",outcome="SUCCESS",status="200",uri="/cards"} 23
http_server_requests_seconds_sum{application="mine",error="none",exception="none",method="GET",outcome="SUCCESS",status="200",uri="/cards"} 0.738544951

• http_server_requests_seconds_sum : GET /cards API 전체 요청 횟수
• http_server_requests_seconds_count : GET /cards API 전체 요청에 걸린 초

그라파나 예상 쿼리문은 다음과 같다.

sum by(uri)(http_server_requests_seconds_sum{application="$app_name"}) / sum by(uri)(http_server_requests_seconds_count{application="$app_name"})

위 쿼리문을 수학공식으로 표현하면

$$ \text{평균 응답시간}{uri} = \frac{\sum \text{http_server_requests_seconds_sum}{uri}}{\sum \text{http_server_requests_seconds_count}_{uri}} $$

• API별 평균 응답시간은 API별 전체 응답시간에서 API별 전체 응답 횟수로 나눈 것이다.
• 예를들어 영미, 철수가 뛰는데 1초, 2초가 걸렸다면 둘이 합친 전체시간이 6초라면 이 두사람의 평균 뛰는 시간은 (1+2)/6 = 0.5인 것이다.
• 이러한 방식으로 방법으로 API별 평균 응답시간을 구할 수 있고 GUI와 연결하여 시각적으로 확인할 예정이다. 추가적으로 그라파나에서 제공되는 템플릿을 활용할 예정이다.

4.1.2 백엔드 서비스가 매트릭 던지는 기능 추가

해당 매트릭을 Spring Boot에서 얻어내기 위한 방식은 다음과 같다.

먼저 Prometheus 기반 메트릭 수집을 위해 Spring Boot 백엔드에 Actuator 및 Micrometer 설정을 추가하였다.

이를 통해 애플리케이션의 상태 정보와 JVM 및 HTTP 요청 관련 메트릭을 Prometheus가 직접 수집할 수 있도록 구성하였다.

1. Prometheus 메트릭 노출을 위해 Actuator 및 Prometheus Registry 의존성을 추가하였다.

// build.gradle
implementation 'org.springframework.boot:spring-boot-starter-actuator'
implementation 'io.micrometer:micrometer-registry-prometheus'

1. application.yml에 Actuator 엔드포인트 노출 및 Prometheus 메트릭 설정을 추가하였다. /actuator/prometheus 엔드포인트를 통해 메트릭을 노출하고, 애플리케이션 식별을 위한 태그를 함께 설정하였다.

# application.yml
management:
  endpoints:
    web:
      exposure:
        include: health,info,prometheus,metrics
      base-path: /actuator
  endpoint:
    health:
      show-details: always
    prometheus:
      enabled: true
  metrics:
    export:
      prometheus:
        enabled: true
    tags:
      application: ${spring.application.name}

1. 보안 설정에서는 Prometheus 서버가 인증 없이 메트릭을 수집할 수 있도록 Actuator 관련 엔드포인트를 허용하였다.

// SecurityConfig.java
.requestMatchers(
    "/actuator/prometheus",  // Prometheus 메트릭 수집 엔드포인트
    "/actuator/health",      // 헬스체크
    "/actuator/info"         // 애플리케이션 정보
).permitAll()

4.1.3 결론

이를 통해 Prometheus가 /actuator/prometheus 엔드포인트를 주기적으로 스크래핑하여

백엔드 애플리케이션의 상태, JVM 리소스, 요청 처리 메트릭을 수집할 수 있도록 구성하였다.

4.2 프론트

아래 사진을 보면, 매트릭 수집이 정상적으로 수집되는 모습을 볼 수 있다.

해당 매트릭을 수집하기 위해 Next.js 프론트엔드에 Web Vitals 수집 로직을 추가하고, Prometheus가 스크래핑할 수 있는 API 엔드포인트를 구현하였다.

4.2.1 프론트 매트릭 수집 로직 구현

먼저 클라이언트 단에서는 useReportWebVitals 훅을 활용하여 Web Vitals(FCP, LCP, CLS, INP)를 수집하도록 구성하였다.

// src/shared/lib/WebVitalsTracker.tsx
'use client'

import { useReportWebVitals } from 'next/web-vitals'
import { reportWebVitals as sendMetrics } from './webVitals'

export function WebVitalsTracker() {
  useReportWebVitals(sendMetrics)
  return null
}

수집된 매트릭은 sendBeacon을 우선적으로 사용하여 페이지 이탈 시에도 안정적으로 서버에 전송되도록 하였다.

// src/shared/lib/webVitals.ts
import type { NextWebVitalsMetric } from 'next/app'

export function reportWebVitals(metric: NextWebVitalsMetric) {
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
  })

  if (navigator.sendBeacon) {
    navigator.sendBeacon('/api/metrics', body)
  } else {
    fetch('/api/metrics', {
      method: 'POST',
      body,
      keepalive: true,
    })
  }
}

서버 측에서는 prom-client의 Histogram을 사용하여 각 Web Vital 지표를 버킷 단위로 집계하였으며, Prometheus가 주기적으로 스크래핑할 수 있도록 GET 엔드포인트를 함께 제공하였다.

// src/app/api/metrics/route.ts
import { NextResponse } from 'next/server'
import { register, Histogram } from 'prom-client'

const fcpHistogram = new Histogram({
  name: 'nextjs_fcp',
  help: 'First Contentful Paint (in ms)',
  buckets: [100, 200, 500, 1000, 1500, 2500, 4000],
})

const histograms: Record<string, Histogram> = {
  FCP: fcpHistogram,
}

export async function POST(request: Request) {
  const { name, value } = await request.json()
  histograms[name]?.observe(value)
  return new NextResponse('Metric received', { status: 202 })
}

export async function GET() {
  return new NextResponse(await register.metrics(), {
    headers: { 'Content-Type': register.contentType },
  })
}

마지막으로 layout.tsx에 트래커 컴포넌트를 추가하여 모든 페이지에서 Web Vitals가 자동으로 수집되도록 적용하였다.

// src/app/layout.tsx
<WebVitalsTracker />

4.2.2 결론

이를 통해 Next.js → Prometheus → Grafana 흐름으로 프론트엔드 성능 지표를 시각화할 수 있는 기반을 구축하였다.

4.3 AI @남는 사람이 진행할 예정

4.4 DB

4.4.1 PostgreSQL 메트릭 수집 아키텍처

• PostgreSQL 자체는 Prometheus 메트릭을 직접 제공하지 않기 때문에, postgres-exporter를 통해 내부 통계 뷰(pg_stat_*)를 수집한다.

[ PostgreSQL (host) ]
        ↑
        |  (SQL로 상태 조회)
        |
[ postgres-exporter (container) ]
        ↑
        |  HTTP /metrics (9187)
        |
[ Prometheus (container) ]
        ↑
        |  PromQL query
        |
[ Grafana ]

4.4.2 메트릭 추출 방식

1. 모니터링 전용 DB 계정 생성

• 운영 DB 보안을 위해 읽기 전용 모니터링 계정을 생성한다.
• 애플리케이션 계정과 분리하여 권한 최소화 원칙을 적용한다.

# 모니터링 전용 유저 생성
CREATE USER <user> WITH PASSWORD '<pw>';

# 시스템 통계 및 설정 읽기 권한 부여
GRANT pg_monitor TO <user>;

# 특정 DB(mine_project_db) 접속 권한 명시
GRANT CONNECT ON DATABASE mine_project_db TO <user>;
GRANT CONNECT ON DATABASE postgres TO <user>;

2. PostgreSQL 설정 확인 및 수정

• Postgres가 외부(컨테이너) 접근을 허용하도록 설정한다.
• pg_hba.conf에 들어가는 네트워크 대역은 아래 명령어로 확인할 수 있다.
  • docker compose exec postgres-exporter sh -lc "ip a; echo '---'; ip route"

# postgresql.conf
listen_addresses = '*'

# pg_hba.conf
host    all    monitor    <Docker 컨테이너 네트워크 대역>    md5

3. 방화벽(UFW) 설정

• 우리 서버에 UFW 방화벽이 적용되어 있어, Docker 네트워크 접근을 명시적으로 허용한다.
• 해당 설정이 없을 경우 Exporter는 접속 시도는 하나 타임아웃으로 실패한다.

sudo ufw allow from <Docker 컨테이너 네트워크 대역> to any port 5432 proto tcp

4. postgres-exporter 구성

• Docker Compose를 통해 postgres-exporter를 실행한다.
• Exporter는 PostgreSQL 내부 통계 정보를 주기적으로 조회하여 /metrics 엔드포인트로 노출한다.

  postgres-exporter:
    image: prometheuscommunity/postgres-exporter
    extra_hosts:
      - "host.docker.internal:host-gateway"
    ports:
      - "9187:9187"
    environment:
      DATA_SOURCE_NAME: "postgresql://user:pw@host.docker.internal:5432/postgres?sslmode=disable"
      WEB_LISTEN_ADDRESS: ":9187"
    depends_on:
      - prometheus
    networks:
      - monitoring

5. Prometheus 기반 메트릭 수집

5.1 백엔드

백엔드(Spring Boot)가 /actuator/prometheus엔드포인트로 메트릭을 노출하고, Prometheus가 해당 엔드포인트를 주기적으로 scrape하여 메트릭을 수집하는 것을 확인하였다.

5.2 프론트

Prometheus가 Next.js에서 노출한 /api/metrics 엔드포인트를 통해 프론트엔드 메트릭을 정상적으로 수집하는 것을 확인하였다.

5.3 AI

5.4 DB

PostgreSQL은 postgres-exporter를 통해 메트릭을 노출하고, Prometheus가 이를 수집하여 DB 상태 지표를 모니터링한다.

6. 서비스 별 모니터링 구축

6.1 백엔드

6.1.1 백엔드 Grafana 대시보드 구성

6.1.2 상세보기

백엔드 그라파나 전체보기에서 “다른 지표들 더보기 링크”에 들어가면 여러 리소스 상태를 관측할 수 있도록 설정했다.

• 각 지표에는 description과 해석 기준을 함께 기재하여, 해당 지표가 어떤 것을 의미하는지를 바로 알 수 있디.

6.2 프론트 - @Halo.won(원현섭)

6.2.1 프론트 Grafana 대시보드 구성

좌측에는 현재 측정되고 있는 평균값들을 나타내게 하였고 우측에는 지속해서 시간별로 변하는 평균값들을 그래프로 표현하게 하여 프론트 팀원이 시간대별로 해당 지표를 확인하고 성능 개선에 도움이 되게 구성하였다.

6.3 DB

6.3.1 DB Grafana 대시보드 구성

• 2.4 DB에서 정의한 핵심 지표를 중심으로, DB 병목 지점을 판단하는 데 필요한 추가 지표들을 함께 수집하여 Grafana 대시보드로 시각화하였다.
• 각 지표에는 description과 해석 기준을 함께 기재하여, DB에 익숙하지 않은 작업자도 “정상 / 이상 상태”를 빠르게 판단할 수 있도록 구성하였다.
• 본 대시보드는 API 응답 지연 발생 시, DB가 원인인지 여부를 빠르게 판단하는 용도로 사용한다.

6.3.2 DB 병목 판단을 위한 주요 지표 정리

• 2.4 DB에서 정의한 지표를 위의 대시보드에서 찾아보면 아래와 같이 정리할 수 있다.

7. 트러블 슈팅

7.1 프롬테일 과다 CPU 점유 문제

7.1.1 문제점

현재 EC2 CPU

![image.png](attachment:3af5202d-86f4-4ede-89e8-329d27d71b00:image.png)

• 2차 테스트

  

• 3차 테스트

  

프롬테일이 CPU는 코어 하나 기준 35%이상 잡아먹는 상황 발생하였고 램도 초반에 컨테이너가 띄워질때는 전체의 42%를 잡아먹는 현상이 발생하였다. 4G기준 42%면 1.8G라고 하였을 때, 기본 OS 메모리를 생각하면 4G까지 생각하여야 했다. 따라서 기존 프로덕션 서버 인스턴스와 동일한 , vcpu 2코어 및 Ram 4G, t4g.medium을 선정했다.

7.1.2 원인 파악

큰 용량의 로그파일을 읽는 프롬테일 프로세스 CPU 과다 점유 문제였다.

현재 프롬테일이 78%나 CPU를 먹고있는 상황이라 해당 문제의 원인을 파악할 필요가 있었고 그 문제를 아래 사진의 로그 파일에서 찾았다. 따라서 로그파일을 몇일 주기로 저장해서 프롬테일이 읽을 로그 파일 크기를 줄일지 결정할 필요성이 있었다.

현재 프롬테일이 읽고 있는 백엔드 로그가 1.8G라는것을 확인하였고 프롬테일 시작시 파일 끝 위치 계산하고 stack_trace가 제한이 8192mb라 읽는 비용이 많이들고 positions이 존재하지 않아 해당 큰 로그파일을 한번에 읽는데 많은 CPU를 사용하게 된다는 문제점 또한 파악하였다.

7.1.3 해결 방법

로그를 하루 단위로 날짜이름으로 저장하기로 결정하였다. 실시간으로 하루의 로그를 프롬테일이 읽어서 실시간 로그를 그라파나를 통해서 개발자들에게 제공하기로 하였고 하루단위로 따로 저장해서 개발자들에게 제공하기로 결정하였다. 하루로 정한 이유는 날짜별로 관리하기 쉽게 하기 위해서였다.

cron + logrotate 조합을 사용하여 일단위로 명령을 실행하게 하였고 logrotage로 로그를 잘랐다.

• logrotate 설정 파일 생성

    sudo vi /etc/logrotate.d/backend

• 작성

    /home/ubuntu/mine/backend/shared/logs/backend.log {
        daily
        rotate 14
        missingok
        notifempty
        dateext
        dateformat -%Y%m%d
        olddir /home/ubuntu/mine/backend/shared/logs/save_logs
        copytruncate
        compress
    }
  

• 테스트

    sudo logrotate -f /etc/logrotate.d/backend
  

• 결과

  

위 결과 사진처럼 로그파일이 날짜이름으로 분리되는 것을 확인하였다.

7.1.4 결과

그 결과 프롬테일이 CPU를 0.7% 그리고 메모리를 2.1% 사용하고 로키 또한 0.7% 그리고 2.1%씩 차지하는 것을 확인할 수 있었다.

추가적으로 2026년 2월 4일에 52M의 로그가 쌓인 것을 확인가능하였고 계속해서 크기를 추적하여 인스턴스 디스크 용량 산정에 반영할 예정이다.

7.2 방화벽 설정으로 인한 PostgreSQL 메트릭 수집 실패

7.2.1 문제점

• Grafana에서 PostgreSQL 대시보드가 No data 로 표시되었다.

• Prometheus Targets 페이지에서는 postgres-exporter가 UP 상태이나

  실제 DB 관련 메트릭(pg_stat_activity_count 등)이 수집되지 않았다.

• postgres-exporter 로그에서 타임아웃 오류 반복 발생했다.

7.2.2 원인 파악

• exporter 컨테이너에서 DB 호스트(host.docker.internal:5432)로의 네트워크 연결 타임아웃 발생하는것으로 보아 서버에 설정된 UFW 방화벽문제라는 것을 알았다.
  • Docker bridge 네트워크(<Docker 컨테이너 네트워크 대역>, docker0)에서 들어오는 트래픽이 PostgreSQL 포트(5432)에 대해 허용되지 않아 exporter → DB 연결이 차단되었다.

7.2.3 해결방법

• Docker 네트워크 대역에서 PostgreSQL 포트 접근 허용했더니 문제가 해결되었다.

    sudo ufw allow from <Docker 컨테이너 네트워크 대역> to any port 5432 proto tcp

• Prometheus → postgres-exporter → PostgreSQL 연결 정상화 확인

  • /metrics 엔드포인트에서 pg_stat_* 메트릭 노출
  • Grafana PostgreSQL 대시보드에 메트릭 정상 표시

7.3 프로메테우스 컨테이너에서 nextjs/metrics에 접근이 안되는 문제

7.3.1 문제점

curl [http://localhost:3000/api/metrics](http://172.31.39.74:3000/api/metrics) 실행시, 현재 아래와 같은 매트릭을 반환하고 있다.

# HELP nextjs_fcp First Contentful Paint (in ms)

# TYPE nextjs_fcp histogram

nextjs_fcp_bucket{le="100"} 4
nextjs_fcp_bucket{le="200"} 20
nextjs_fcp_bucket{le="500"} 25
nextjs_fcp_bucket{le="1000"} 36
nextjs_fcp_bucket{le="1500"} 36
nextjs_fcp_bucket{le="2500"} 38
nextjs_fcp_bucket{le="4000"} 40
nextjs_fcp_bucket{le="+Inf"} 40
nextjs_fcp_sum 21670.300000071526
nextjs_fcp_count 40

# HELP nextjs_lcp La

하지만 현재 프로메테우스가 컨테이너로 실행되고 있고 어째서인지 로컬호스트에서 실행중인 nextjs가 주는 매트릭에 접근이 안된다.

- job_name: 'nextjs-frontend'
    static_configs:
      - targets: ['172.31.39.74:3000']  # EC2면 자체 IP 사용 가능
    metrics_path: '/api/metrics'

현재 nextjs/metrics에 접근하는 prometheus.yml파일은 위와 같다.

7.3.2 시도

1. 첫번째 시도 - 실패

- targets: ['172.31.39.74:3000']  # EC2면 자체 IP 사용 가능

1. 두번째 시도 - 실패

 - targets: ['172.17.0.1:3000'] 

1. 세번째 시도 - 실패

 - targets: ['localhost:3000'] 

7.3.3 해결 방법

서버에 있는 파일 모니터링 코드 원본

• docker-compose.yml

    services:
      loki:
        image: grafana/loki:latest
        ports:
          - "3100:3100"
        command: -config.file=/etc/loki/local-config.yaml
        volumes:
          - loki-data:/loki
        networks:
          - monitoring
  
      promtail:
        image: grafana/promtail:latest
        volumes:
          - /home/ubuntu/mine/backend/shared/logs:/logs
          - /home/ubuntu/loki-setup/promtail-config.yml:/etc/promtail/config.yml
        command: -config.file=/etc/promtail/config.yml
        networks:
          - monitoring
  
      prometheus:
        image: prom/prometheus:latest
        ports:
          - "9090:9090"
        volumes:
          - /home/ubuntu/loki-setup/prometheus.yml:/etc/prometheus/prometheus.yml
          - prometheus-data:/prometheus
        command:
          - '--config.file=/etc/prometheus/prometheus.yml'
        networks:
          - monitoring
  
      grafana:
        image: grafana/grafana:latest
        ports:
          - "3001:3000"
        environment:
          - GF_SECURITY_ADMIN_PASSWORD=admin
        volumes:
          - grafana-data:/var/lib/grafana
        networks:
          - monitoring
  
      postgres-exporter:
        image: prometheuscommunity/postgres-exporter
        ports:
          - "9187:9187"
        environment:
          DATA_SOURCE_NAME: "postgresql://mine:305dadd728bc1dc07c1a0bde523dba47@mine-db:5432/mine_project_db?sslmode=disable"
          WEB_LISTEN_ADDRESS: ":9187"
        depends_on:
          - prometheus
        networks:
          - monitoring
  
    volumes:
      grafana-data:
      loki-data:
      prometheus-data:
  
    networks:
      monitoring:
        driver: bridge

• prometheus.yml

    global:
      scrape_interval: 15s
  
    scrape_configs:
      - job_name: 'prometheus'
        static_configs:
          - targets: ['localhost:9090']
  
      - job_name: 'loki'
        static_configs:
          - targets: ['loki:3100']
  
      - job_name: 'promtail'
        static_configs:
          - targets: ['promtail:9080']
  
      - job_name: 'postgres'
        static_configs:
          - targets: ['postgres-exporter:9187']
  
      - job_name: 'backend'
        static_configs:
          - targets: ['172.17.0.1:443']
        scheme: https
        metrics_path: '/server/actuator/prometheus'
        tls_config:
          insecure_skip_verify: true
  

• promtail-config.yml

    server:
      http_listen_port: 9080
  
    positions:
      filename: /tmp/positions.yaml
  
    clients:
      - url: http://loki:3100/loki/api/v1/push
  
    scrape_configs:
      - job_name: backend
        static_configs:
          - targets:
              - localhost
            labels:
              job: backend
              app: mine
              __path__: /logs/backend.log
  
        pipeline_stages:
          - json:
              expressions:
                timestamp: timestamp
                level: level
                message: message
                logger: logger
                path: path
                method: method
                clientIp: clientIp
                status: status
                userId: userId
                stack_trace: stack_trace
  
          - labels:
              level:
              logger:
              path:
              method:
              status:
              userId:
  
          - timestamp:
              source: timestamp
              format: RFC3339

8. 병목 지점 파악 사례

8.1 상황 발생

• 서비스 오픈 이후, 일부 사용자 요청에서 간헐적인 오류가 발생
• 초기에는 일시적인 네트워크 문제로 판단했으나, 동일 시점에 오류 로그가 반복적으로 발생하여 원인 분석을 진행했다.

8.2 백엔드 로그 기반 이상 징후 확인

• 백엔드 로그 확인 결과, 특정 시점에 카드 생성 API (POST /server/cards) 요청이 비정상적으로 집중되고 있었다.
• 다수의 요청이 짧은 시간 안에 반복적으로 유입되며, 일부 요청은 정상 처리되지 못하고 실패(499 등)로 종료되는 현상이 확인되었다 → 단순 요청 실패가 아닌, 트래픽 집중으로 인한 병목 가능성을 의심했다.

8.3 모니터링 지표 기반 교차 분석

로그만으로는 원인을 단정할 수 없기 때문에, 기존에 구축해 둔 모니터링 지표를 함께 확인했다.

8.3.1 백엔드 관점 분석 - @Halo.won(원현섭)

1. 문제점

가. 트래픽 부하시, 응답속도 저하 발생

운영서버 평균 응답속도가 0.4ms로 관측되지만, 부하시에는 최대 약 5초까지 나오는 것을 확인할 수 있었다. 해당이유를 아래 2가지 경우에서 찾아 볼 수 있었다.

나. CPU 코어 수 부족

CPU가 처리해야하는 실행가능한 작업(톰캣 워커 스레드, DB 쿼리 실행중인 비즈니스 로직 스레드 등)은 하나의 CPU에 할당되어야 처리가 된다. 하지만 위와 같은 지표에서 부하가 걸렸을 시, 특정 스레드들을 cpu가 바로 처리가 못하는 상황에서 병목이 생겼였다

최고치는 17:57:15 시각에 16의 실행가능한 작업들이 남아있었고 cpu를 바로 교체할 수 없기에 해당 문제들을 해결할 수 있는 방법을 지표를 활용해 찾을 예정이다.

• x

  

  용어	설명
  Used	현재 실제로 사용 중인 힙 메모리
  Commited	jvm이 os로 부터 할당받은 메모리 크기

  위 사진은 17:57:15 시각에 힙 중에서 eden에서 살아남은 데이터들이 저장되는 survivor space이다. 사용가능한 힙메모리가 0.5mib 남지않고 그 뒤에는 10mib를 풀로써 어 근데 이게 병목 이유가되나

1. 해결 방안

가. HikariCP 늘리기

위 그림과 표에 따르면 할당가능한 커넥션수(idle)는 10개를 넘어가지 않는데 커넥션 할당 대기중인 스레드 수(pending)가 특정 시점 188까지 오르는 것으로 보인다. 해당 시점에서 스레드는 커넥션을 할당받지 못해 DB 접근을 못하게 되고 해당 과정에서 병목이 생기는 것을 알 수 있었다.

커넥션 객체 증가에 대한 JVM 힙 메모리 할당 트레이드 오프를 생각해보면 현재 부하시, 커넥션 풀 최대 185개 필요하고 여유있게 200까지 놓는다고 하면(현재 10개 생성중), 커넥션 객체를 하나에 4kb 잡아서 200개시 약 0.7mb heap 메모리가 필요하다. 현재 관측된 바로는 jvm이 힙을 Os로부터 최대 1G , 사전 확보 256mb 이므로 0.7mb정도는 트레이드 오프관점에서 괜찮다고 판단하였다.

따라서 Spring boot에서 HikariCp 커넥션 풀을 늘리는 방법을 진행한다.

application.properties를 아래와 같이 변경한다.

spring.datasource.hikari.maximum-pool-size=50
spring.datasource.hikari.minimum-idle=10
spring.datasource.hikari.idle-timeout=300000
spring.datasource.hikari.max-lifetime=1800000
spring.datasource.hikari.connection-timeout=30000

application.yml일 경우는 아래와 같다.

spring:
  datasource:
    hikari:
      maximum-pool-size: 50
      minimum-idle: 10
      idle-timeout: 300000
      max-lifetime: 1800000
      connection-timeout: 30000

1. 결론

주된 원인으로는 HikariCp 커넥션 풀 개수가 10개라서 DB쿼리가 해당 요청을 처리 못하는 것으로 나왔다. 이 때문에 IO작업을 대기하는 작업들이 생겨나고 CPU가 처리해야하지만 하지 못하는 작업들이 존재함에따라 CPU부하가 생겨나는 것이였다.

따라서 일단 HikariCp 커넥션 풀 개수를 50개로 늘려보고 부하를 한번더 주입하여 테스트 하기로 하였다.

1. 기타

아래 링크는 부하가 걸렸을 때, 그라파나 스냅샷이다.

https://snapshots.raintank.io/dashboard/snapshot/cRALkG5IhEPJ51JbnGQv1Ik4GHVjyxkn?orgId=0&from=2026-02-05T08:40:00.000Z&to=2026-02-05T09:20:00.000Z&timezone=browser&var-application=mine&var-instance=172.17.0.1:443&var-hikaricp=HikariPool-1&var-memory_pool_heap=$__all&var-memory_pool_nonheap=$__all&refresh=5s

8.3.2 DB 관점 분석

1. DB CPU와 Memory

   

   • CPU 사용량이 최대치(100%)를 계속 점유하지 않았다는 것은, 실행된 SQL 쿼리들이 복잡한 연산(CPU Bound)을 필요로 하기보다는 대기(Wait)하는 시간이 더 많았기 때문에, 시스템의 물리적 한계치에 도달하지 않았다는 것을 알 수 있었다.
   • 전체 메모리 점유율이 매우 낮은것으로보아, 메모리 부족으로 인해 DB가 강제 종료되거나 스왑(Swap)이 발생하여 느려진 것도 아닌것으로 판단했다.

2. 커넥션과 세션 상태

   

   

• Active sessions (활성 세션 급증): 평소 0~1 수준이던 활성 세션이 특정 시점에 최대 9개(Max 9)까지 수직 상승하는 것을 보아 이는 DB가 요청을 처리하는 속도보다 새로운 요청이 들어오는 속도가 더 빠르다는 것을 의미한다. 순간 DB가 동시에 9개의 쿼리를 처리하느라 풀 가동 중이었다는 뜻이다.
• Idle sessions (대기 세션): Idle in transaction 상태의 세션이 관찰되는데, 이는 애플리케이션이 DB에 연결을 열어놓고 쿼리를 실행한 뒤, 트랜잭션을 제대로 닫지(Commit/Rollback) 않고 붙잡고 있다는 신호입니다. 이 세션들이 커넥션 풀을 점유하여 병목을 만든다고 판단할 수 있다.
• 결론
  • 일부 세션이 Idle in transaction 상태로 들어가며 DB 자원을 점유한 채 응답을 안 줌.
  • 남은 자원으로 요청을 처리하려다 보니 Active sessions가 9까지 치솟으며 부하 발생.
  • 트랜잭션과 락을 오래 붙잡는 요청이 누적되면서 DB 응답을 기다리는 백엔드 요청이 쌓였고, 그 결과 백엔드 워커 스레드가 고갈되어 타임아웃이 발생했다고 판단했다.

1. 락(Lock) 경합 발생

   

• RowExclusiveLock의 의미: "나 지금 쓰는 중이야!"
  • 그래프에서 가장 눈에 띄는 빨간색 계열의 rowexclusivelock은 주로 INSERT, UPDATE, DELETE와 같은 쓰기 작업을 할 때 자연스럽게 발생한다. 다만, 동시에 너무 많이 생긴것이 문제이다.
    • 상황 해석: 카드를 생성하는 POST 요청이 들어오면 DB는 해당 데이터를 테이블에 넣기 위해 행(Row) 단위로 잠금을 건다.
    • 병목 지점: 수백 개의 API 요청이 동시에 테이블에 쓰기작업을 하러 RowExclusiveLock을 요청하면서 DB가 이 순서를 처리하느라 부하가 급증한 것으로 판단된다.
• AccessShareLock의 동반 상승: "나도 좀 읽자!"
  • 노란색 그래프인 accesssharelock 수치도 498까지 높게 올라가있는 것을 볼 수 있고, 이는 보통 SELECT 쿼리를 실행할 때 발생한다.
    • 상황 해석: 카드 생성(INSERT)만 일어나는 게 아니라, 생성 직후에 "잘 생성됐는지 확인"하거나 "전체 카드 목록을 다시 불러오는" 등의 조회 작업이 동시에 몰렸을 수 있겠다고 판단했다.
    • 경합 발생: PostgreSQL에서 읽기(AccessShare)와 쓰기(RowExclusive)는 서로를 직접적으로 막지는 않지만, 너무 많은 요청이 한꺼번에 몰리면 CPU와 메모리 자원을 나눠 쓰느라 전체적인 처리 속도가 느려진 것이 아닌가 하는 생각이 들었다.
• RowShareLock: "이 데이터 건들지 마"
  • rowsharelock 수치(365)도 굉장이 높은데, 이는 보통 SELECT ... FOR SHARE 같은 쿼리나 외래 키(Foreign Key) 제약 조건을 확인할 때 발생한다.
    • 결정적 원인: 카드 생성 시 유저 ID나 카테고리 ID 같은 외래 키를 참조하고 있다보니, DB는 부모 테이블의 데이터가 지워지지 않도록 락을 건것으로 보인다.
    • 결과: 수많은 카드 생성 요청이 부모 테이블(유저 테이블)의 특정 행을 동시에 참조하려고 시도하면서 여기서도 대기열이 발생한 것으로 볼수도 있을 것 같다.
• 결론 : DB가 죽은 게 아니라, 줄이 너무 긴 상태라고 판단했다.
  • 현재 락 그래프가 0이다가 특정 시점에 수직으로 솟구친 것은 DB 하드웨어의 한계보다는 '동시성 제어'에서 병목이 온 것 같다.
  • exclusive lock처럼 테이블 전체를 꽉 막아버리는 락은 없지만, 자잘한 로우 락(Row Lock)들이 수천 개가 얽히면서 DB 세션이 포화 상태가 되어 API 응답 시간이 길어지고, 결국 백엔드 서버의 커넥션 풀이 다 차버려서 서비스가 "터지는" 현상으로 이어진 것 같다.

DB 관점 최종 결론

• DB CPU, 메모리, 커넥션 수치는 모두 임계치에 도달하지 않았으며, DB 하드웨어 또는 쿼리 성능 자체가 병목이 된 상황은 아니었다.
• 다만 특정 시점에 카드 생성 API 요청이 대량으로 유입되며, INSERT + SELECT가 혼합된 트랜잭션이 동시에 실행되었다.
• 이 과정에서 다수의 세션이 Idle in transaction 상태로 전환되었고, RowExclusiveLock, RowShareLock 등 다수의 row-level lock이 단시간에 집중되었다.
• 결과적으로 DB는 정상 동작 중이었으나, 동시성 제어 비용과 트랜잭션 유지 시간 증가로 응답 지연이 발생하였고, 이 지연이 누적되며 백엔드 요청 타임아웃으로 이어졌다.

8.4 병목 지점 결론

CPU 부하가 걸리는 이유중에 백엔드에서는 DB 커넥션이 부족해 대기 작업이 많아질수록, 대기 스레드들이 깨어나 풀 상태를 계속 확인하게 된다. 이 작업에서 작동하는 루프나 로직 및 Lock을 획득하는 과정에서 CPU를 사용하게된다. 따라서 HikariCP 커넥션 풀을 10개에서 200개로 증가할 예정이고 추가 부하테스트를 진행하여 다른 병목지점을 찾을 예정이다.