어느 CTO님의 말씀이 굉장히 가슴을 때렸다.

"열정과 야망을 구분할 수 있어야한다."

야망이 나쁜 것인가를 생각해보았을때,

직관적으로 그렇다라고 말할 수는 없었다.

야망은 나쁜 것인가?

가장 오래된 책중에 하나인 성경에 따르면, 야망이 죄로 이어질 때,

나쁜 것이 된다고 한다.

야망이 죄로 이어지지 않게 하려면 무엇을 해야할까?

뚜렷한 목표가 있어야한다.

우리는 이것을 "비전"이라고 한다.

비전을 세우는 법

질문의 개수 : 2개

무결하다는 것은 뭘까

정답이 아닌것?

정답이 어딨나

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

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 밖이 그라파나에 안나오고

가. 문서 목적

이분 탐색의 시간복잡도에 대해 알아보던 중, 복잡도라는 표현을 사용한 사람의 의도가 궁금해서 한번 찾아보았다. 더불어 "시간"에 대한 나의 해석 또한 들어가있다.

나. 목차

1) 개요 2) 연산횟수가 늘어난다고 해서 복잡도라는 표현을 쓰는 것은 맞을까 3) 여러 부분 4) 시간 5) 결론

2. 연산횟수가 늘어난다고 해서 복잡도라는 표현을 쓰는 것이 맞을까

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

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

3. 여러 부분

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

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

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

4. 시간

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

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

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

5. 결론

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

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

가. 문서 목적

해당 문서는 문서를 어떻게 하면 읽는 사람이 편하게 통일된 형식으로 작성할 수 있을까에 대해서 작성하였고 추후 문서를 작성하는 나자신의 참고자료로써도 사용될 예정이다.

나. 목차

1) 개요 2) 문서화 형식 3) 문서화를 잘하면 작성자에게 좋은 점

2. 문서화 형식

가. 개요를 통해 읽는 사람이 문서 전체 내용을 알게하라

*두괄식으로 쓰라는 것이다. *

당신이 흥미진진한 글을 쓰는 작가가 아닌이상, 끝에 결과가 오는 미괄식으로 쓸 필요는 없지 않은가. 해당 문서에도 나와있듯이 모든 문서에는 개요라는 첫번째 단락을 통해서 읽는 사람이 해당 문서의 순서를 한눈에 파악할 수 있게 해야한다. 이 방식을 통해 읽는 사람은 이 문서를 두번 읽는 듯한 마치 알고 있는 것을 읽게만드는 효과를 느낄 수 있다.

나. 사람들은 크고 두꺼운 글자부터 읽는다.

이게 눈이 먼저 갈껄?

이거보다

다. 항목번호는 통일

필자는 1. -> 가 -> 1)을 사용하고 있다. 이 방식은 널리쓰이는 방식으로 독자가 읽기 훨씬 수월하게 한다.

라. -보단 표를 사용해라

노션이 유행한 나머지 많은 사람들이 아래와 같이 쓴다.

• 아침에 일어나서
• 밥을 먹었고
• 설거지를 했다

뭐가 더 낫나요?

📌 해당 문서는 2026년 02월 09일에 업데이트 되었습니다.

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개로 증가할 예정이고 추가 부하테스트를 진행하여 다른 병목지점을 찾을 예정이다.

장애가 일어난 시점에 빠르게 대응해서 서비스 손실과 이어지는 사용자 이탈률을 줄이는데 목적으로 한다.

2. 장애 상황 선정

2.1 시스템의 정상적인 사용이 어려운 경우

가. 서비스가 불능이고 이것은 리소스 낭비로 이어지므로 즉각적인 대응이 필요하다고 판단하여 장애 알림 대상으로 선정

3. 각 상황별 장애 판단 방법

3.1 시스템의 정상적인 사용이 어려운 경우

가. 각 서비스가 완전히 다운되는 경우

• 헬스체크를 시도하여 생존 여부 판단
• 헬스체크 실패시 서비스 완전 다운 알람 클라우드 및 해당 담당 개발자들에게 전송

나. 서비스 응답이 자꾸 실패하는 경우 (5xx error 기준)

• 5분간 100명의 동시요청중 5~9명까지는 응답이 실패해도 재요청으로 처리하고 장애 경고 알람만 보내는 것으로 결정
• 10% 이상부터는 문제상황이라고 인지하고 장애 확정 알림을 보내 해당 서비스 개발자들 및 엔지니어가 즉시 조치 혹은 롤백 예정

4. 장애 알람

4.1 헬스체크 실패 알람

1. 인스턴스 자체의 헬스체크

1분간격 헬스체크 1번 실패시 아래의 같은 디스코드 봇이 알람을 보내게 설정, 자세한 구현 방식은 바로 아래 4.2 참고

4.2 서비스 응답 5xx 10% 이상 알람

5분간격으로 모아진 에러들의 10%가 5xx일 경우 아래 사진과 같이 디스코드 알림 계획

EC2 인스턴스에 CloudWatchAgentServerPolicy 정책이 포함된 IAM Role 삽입

나. Nginx 로그 분리

1. nginx sites-available/default 수정

...
# 프론트 서버(Next.js 서버)
    location ^~ /api/ {
        access_log /var/log/nginx/fe_access.log json_log;
        error_log /var/log/nginx/fe_error.log;
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Port $server_port;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_redirect http://localhost:3000 https://$host;
        proxy_redirect http://127.0.0.1:3000 https://$host;
    }

    # 백엔드 API (Spring Boot)
    location ^~ /server/  {
        access_log /var/log/nginx/be_access.log json_log;
        error_log /var/log/nginx/be_error.log;
        proxy_pass http://127.0.0.1:8080/;
    }

    # AI 서버 (FastAPI)
    location /ai/ {
        access_log /var/log/nginx/ai_access.log json_log;
        error_log /var/log/nginx/ai_error.log;
        proxy_pass http://127.0.0.1:8000/;
    }

    # 프론트 (Next.js SSR)
    location / {
        access_log /var/log/nginx/fe_access.log json_log;
        error_log /var/log/nginx/fe_error.log;
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Port $server_port;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_redirect http://localhost:3000/ /;
        proxy_redirect https://localhost:3000/ /;
        proxy_redirect http://127.0.0.1:3000/ /;
        proxy_redirect https://127.0.0.1:3000/ /;
    }
}

...

• 전체 코드

    ##
    # You should look at the following URL's in order to grasp a solid understanding
    # of Nginx configuration files in order to fully unleash the power of Nginx.
    # https://w.nginx.com/resources/wiki/start/
    # https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/
    # https://wiki.debian.org/Nginx/DirectoryStructure
    #
    # In most cases, administrators will remove this file from sites-enabled/ and
    # leave it as reference inside of sites-available where it will continue to be
    # updated by the nginx packaging team.
    #
    # This file will automatically load configuration files provided by other
    # applications, such as Drupal or Wordpress. These applications will be made
    # available underneath a path with that package name, such as /drupal8.
    #
    # Please see /usr/share/doc/nginx-doc/examples/ for more detailed examples.
    ##
  
    # Default server configuration
    #
    #server {
    #       listen 80 default_server;
    #       listen [::]:80 default_server;
  
            # SSL configuration
            #
            # listen 443 ssl default_server;
            # listen [::]:443 ssl default_server;
            #
            # Note: You should disable gzip for SSL traffic.
            # See: https://bugs.debian.org/773332
            #
            # Read up on ssl_ciphers to ensure a secure configuration.
            # See: https://bugs.debian.org/765782
            #
            # Self signed certs generated by the ssl-cert package
            # Don't use them in a production server!
            #
            # include snippets/snakeoil.conf;
  
    #       root /var/www/html;
  
            # Add index.php to the list if you are using PHP
    #       index index.html index.htm index.nginx-debian.html;
  
    #       server_name _;
  
    #       location / {
                    # First attempt to serve request as file, then
                    # as directory, then fall back to displaying a 404.
    #               try_files $uri $uri/ =404;
    #       }
  
            # pass PHP scripts to FastCGI server
            #
            #location ~ \.php$ {
            #       include snippets/fastcgi-php.conf;
            #
            #       # With php-fpm (or other unix sockets):
            #       fastcgi_pass unix:/run/php/php7.4-fpm.sock;
            #       # With php-cgi (or other tcp sockets):
            #       fastcgi_pass 127.0.0.1:9000;
            #}
  
            # deny access to .htaccess files, if Apache's document root
            # concurs with nginx's one
            #
            #location ~ /\.ht {
            #       deny all;
            #}
    #}
  
    # Virtual Host configuration for example.com
    #
    # You can move that to a different file under sites-available/ and symlink that
    # to sites-enabled/ to enable it.
    #
    #server {
    #       listen 80;
    #       listen [::]:80;
    #
    #       server_name example.com;
    #
    #       root /var/www/example.com;
    #       index index.html;
    #
    #       location / {
    #               try_files $uri $uri/ =404;
    #       }
    #}
  
    #server {
  
            # SSL configuration
            #
            # listen 443 ssl default_server;
            # listen [::]:443 ssl default_server;
            #
            # Note: You should disable gzip for SSL traffic.
            # See: https://bugs.debian.org/773332
            #
            # Read up on ssl_ciphers to ensure a secure configuration.
            # See: https://bugs.debian.org/765782
            #
            # Self signed certs generated by the ssl-cert package
            # Don't use them in a production server!
            #
            # include snippets/snakeoil.conf;
  
    #       root /var/www/html;
  
            # Add index.php to the list if you are using PHP
    #       index index.html index.htm index.nginx-debian.html;
     #   server_name imymemine.kr; # managed by Certbot
  
    #       location / {
                    # First attempt to serve request as file, then
                    # as directory, then fall back to displaying a 404.
    #               try_files $uri $uri/ =404;
    #       }
  
            # pass PHP scripts to FastCGI server
            #
            #location ~ \.php$ {
            #       include snippets/fastcgi-php.conf;
            #
            #       # With php-fpm (or other unix sockets):
            #       fastcgi_pass unix:/run/php/php7.4-fpm.sock;
            #       # With php-cgi (or other tcp sockets):
            #       fastcgi_pass 127.0.0.1:9000;
            #}
  
            # deny access to .htaccess files, if Apache's document root
            # concurs with nginx's one
            #
            #location ~ /\.ht {
            #       deny all;
            #}
  
     #   listen [::]:443 ssl ipv6only=on; # managed by Certbot
      #  listen 443 ssl; # managed by Certbot
       # ssl_certificate /etc/letsencrypt/live/imymemine.kr/fullchain.pem; # managed by Certbot
       # ssl_certificate_key /etc/letsencrypt/live/imymemine.kr/privkey.pem; # managed by Certbot
        #include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
       # ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
  
    #}
    #server {
    #    if ($host = imymemine.kr) {
    #        return 301 https://$host$request_uri;
    #    } # managed by Certbot
  
    #       listen 80 ;
    #       listen [::]:80 ;
    #    server_name imymemine.kr;
    #    return 404; # managed by Certbot
  
    #}
  
    # /etc/nginx/sites-available/default
  
    # 80 -> 443 리다이렉트 (+ 선택: ACME 챌린지)
    server {
        listen 80;
        listen [::]:80;
  
        server_name imymemine.kr www.imymemine.kr;
  
        # (선택) HTTP-01 챌린지를 명시적으로 유지하고 싶으면
        location ^~ /.well-known/acme-challenge/ {
            root /var/www/certbot;
        }
  
        location = /robots.txt {
            root /var/www/html;
            access_log off;
            log_not_found off;
        }
  
        location / {
            return 301 https://$host$request_uri;
        }
    }
  
    # HTTPS reverse proxy
    server {
        listen 443 ssl;
        listen [::]:443 ssl;
  
        server_name imymemine.kr www.imymemine.kr;
  
        ssl_certificate     /etc/letsencrypt/live/imymemine.kr/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/imymemine.kr/privkey.pem;
  
        include /etc/letsencrypt/options-ssl-nginx.conf;
        ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
  
        location = /robots.txt {
            root /var/www/html;
            access_log off;
            log_not_found off;
        }
  
        # 공통 프록시 헤더
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
  
        # Next가 외부 origin 추론할 때 도움되는 헤더
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Port $server_port;
  
        # Swagger(FastAPI)
        location = /openapi.json {
            access_log /var/log/nginx/ai_access.log json_log;
            error_log /var/log/nginx/ai_error.log;
            proxy_pass http://127.0.0.1:8000/api/v1/openapi.json;
        }
  
        location = /api/v1/openapi.json {
            access_log /var/log/nginx/ai_access.log json_log;
            error_log /var/log/nginx/ai_error.log;
            proxy_pass http://127.0.0.1:8000/api/v1/openapi.json; 
        }
  
        # Swagger/OpenAPI docs endpoints (springdoc 기본)
        location ^~ /v3/api-docs/ {
            access_log /var/log/nginx/be_access.log json_log;
            error_log /var/log/nginx/be_error.log;
            proxy_pass http://127.0.0.1:8080/v3/api-docs/;
        }
  
        location = /v3/api-docs {
            access_log /var/log/nginx/be_access.log json_log;
            error_log /var/log/nginx/be_error.log;
            proxy_pass http://127.0.0.1:8080/v3/api-docs;
        }
  
        location = /v3/api-docs/swagger-config {
            access_log /var/log/nginx/be_access.log json_log;
            error_log /var/log/nginx/be_error.log;
            proxy_pass http://127.0.0.1:8080/v3/api-docs/swagger-config;
        }
  
        # 프론트 서버(Next.js 서버)
        location ^~ /api/ {
            access_log /var/log/nginx/fe_access.log json_log;
            error_log /var/log/nginx/fe_error.log;
            proxy_pass http://127.0.0.1:3000;
            proxy_http_version 1.1;
  
            proxy_set_header Host $host;
            proxy_set_header X-Forwarded-Host $host;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header X-Forwarded-Port $server_port;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  
            proxy_redirect http://localhost:3000 https://$host;
            proxy_redirect http://127.0.0.1:3000 https://$host;
        }
  
        # 백엔드 API (Spring Boot)
        location ^~ /server/  {
            access_log /var/log/nginx/be_access.log json_log;
            error_log /var/log/nginx/be_error.log;
            proxy_pass http://127.0.0.1:8080/;
        }
  
        # AI 서버 (FastAPI)
        location /ai/ {
            access_log /var/log/nginx/ai_access.log json_log;
            error_log /var/log/nginx/ai_error.log;
            proxy_pass http://127.0.0.1:8000/;
        }
  
        # 프론트 (Next.js SSR)
        location / {
            access_log /var/log/nginx/fe_access.log json_log;
            error_log /var/log/nginx/fe_error.log;
            proxy_pass http://127.0.0.1:3000;
            proxy_http_version 1.1;
  
            proxy_set_header Host $host;
            proxy_set_header X-Forwarded-Host $host;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header X-Forwarded-Port $server_port;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  
            proxy_redirect http://localhost:3000/ /;
            proxy_redirect https://localhost:3000/ /;
            proxy_redirect http://127.0.0.1:3000/ /;
            proxy_redirect https://127.0.0.1:3000/ /;
        }
    }
  

2. nginx.conf 수정

... 

        #  CloudWatch용 JSON 포맷 추가
        log_format json_log escape=json '{'
                '"time":"$time_iso8601",'
                '"remote_addr":"$remote_addr",'
                '"status":$status,'
                '"request":"$request",'
                '"request_time":$request_time,'
                '"upstream_response_time":"$upstream_response_time",'
...

• 전체 코드

    ubuntu@ip-172-31-39-74:/etc/nginx$ cat nginx.conf
    user www-data;
    worker_processes auto;
    pid /run/nginx.pid;
    error_log /var/log/nginx/error.log;
    include /etc/nginx/modules-enabled/*.conf;
  
    events {
            worker_connections 768;
            # multi_accept on;
    }
  
    http {
  
            map $http_upgrade $connection_upgrade {
                default upgrade;
                ''      close;
            }
            ##
            # Basic Settings
            ##
  
            sendfile on;
            tcp_nopush on;
            types_hash_max_size 2048;
            # server_tokens off;
  
            # server_names_hash_bucket_size 64;
            # server_name_in_redirect off;
  
            include /etc/nginx/mime.types;
            default_type application/octet-stream;
  
            ##
            # SSL Settings
            ##
  
            ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
            ssl_prefer_server_ciphers on;
  
            ##
            # Logging Settings
            ##
            log_format main
                    '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_user_agent" '
                    'request_time=$request_time '
                    'upstream_time=$upstream_response_time';
  
            # ✅ (halo) CloudWatch용 JSON 포맷 추가
            log_format json_log escape=json '{'
                    '"time":"$time_iso8601",'
                    '"remote_addr":"$remote_addr",'
                    '"status":$status,'
                    '"request":"$request",'
                    '"request_time":$request_time,'
                    '"upstream_response_time":"$upstream_response_time",'
                    '"body_bytes_sent":$body_bytes_sent'
            '}';
  
            access_log /var/log/nginx/access.log main;
  
            ##
            # Gzip Settings
            ##
  
            gzip on;
  
            # gzip_vary on;
            # gzip_proxied any;
            # gzip_comp_level 6;
            # gzip_buffers 16 8k;
            # gzip_http_version 1.1;
            # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
  
            ##
            # Virtual Host Configs
            ##
  
            include /etc/nginx/conf.d/*.conf;
            include /etc/nginx/sites-enabled/*;
    }
  
    #mail {
    #       # See sample authentication script at:
    #       # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
    #
    #       # auth_http localhost/auth.php;
    #       # pop3_capabilities "TOP" "USER";
    #       # imap_capabilities "IMAP4rev1" "UIDPLUS";
    #
    #       server {
    #               listen     localhost:110;
    #               protocol   pop3;
    #               proxy      on;
    #       }
    #
    #       server {
    #               listen     localhost:143;
    #               protocol   imap;
    #               proxy      on;
    #       }
    #}
    ubuntu@ip-172-31-39-74:/etc/nginx$ 

다. CloudWatch EC2에 설치

rm amazon-cloudwatch-agent.deb*
wget https://s3.amazonaws.com/amazoncloudwatch-agent/ubuntu/arm64/latest/amazon-cloudwatch-agent.deb
sudo dpkg -i amazon-cloudwatch-agent.deb

라. CloudWatch Agent config 구성

/opt/aws/amazon-cloudwatch-agent/etc/config.json

{
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "/var/log/nginx/fe_access.log",
            "log_group_name": "/nginx/fe",
            "log_stream_name": "{instance_id}"
          },
          {
            "file_path": "/var/log/nginx/be_access.log",
            "log_group_name": "/nginx/be",
            "log_stream_name": "{instance_id}"
          },
          {
            "file_path": "/var/log/nginx/ai_access.log",
            "log_group_name": "/nginx/ai",
            "log_stream_name": "{instance_id}"
          }
        ]
      }
    }
  }
}

마. CloudWatch Log Group 확인

로그 그룹 확인 가능

바. 지표 필터 등록

• BE-5XX-Filter : 500이상 에러들 필터링하는 지표 필터

• BE-Total-Filter : 모든 에러를 필터링하는 지표 필터

• 5xx 에러 필터 패턴 예시

사. 경보 추가

위의 두개의 필터 BE-5XX-Filter 및 BE-Total-Filter로 걸러진 필터들의 총 합계 비율을 퍼센트로 환산하였을 때, 10%가 넘으면 작동하는 경보 추가

아. 람다로 경보랑 디스코드 연동

1. 디스코드 훅 연동

2. 람다.py 작성

DISCORD_WEBHOOK_URL에 디스코드 봇 훅 링크 삽입

import json
import urllib.request

DISCORD_WEBHOOK_URL = [훅 링크]

LOG_LINKS = {
    "BE": "https://ap-northeast-2.console.aws.amazon.com/cloudwatch/home?region=ap-northeast-2#logsV2:log-groups/log-group/$252Fnginx$252Fbe",
    "FE": "https://ap-northeast-2.console.aws.amazon.com/cloudwatch/home?region=ap-northeast-2#logsV2:log-groups/log-group/$252Fnginx$252Ffe",
    "AI": "https://ap-northeast-2.console.aws.amazon.com/cloudwatch/home?region=ap-northeast-2#logsV2:log-groups/log-group/$252Fnginx$252Fai"
}

def lambda_handler(event, context):
    sns_message = event['Records'][0]['Sns']['Message']

    try:
        alarm = json.loads(sns_message)
        alarm_name = alarm.get('AlarmName', 'Unknown')
        new_state = alarm.get('NewStateValue', 'Unknown')
        reason = alarm.get('NewStateReason', '')

        if new_state == 'ALARM':
            emoji = '🚨'
            color_text = 'ALERT'
        elif new_state == 'OK':
            emoji = '✅'
            color_text = 'OK'
        else:
            emoji = '⚠️'
            color_text = new_state

        error_rate = ''
        if 'datapoints' in reason:
            start = reason.find('[') + 1
            end = reason.find(' (')
            if start > 0 and end > 0:
                error_rate = reason[start:end]

        server_type = 'BE'
        if 'FE' in alarm_name:
            server_type = 'FE'
        elif 'AI' in alarm_name:
            server_type = 'AI'

        log_link = LOG_LINKS.get(server_type, LOG_LINKS['BE'])

        content = emoji + " **[" + color_text + "] " + alarm_name + "**\n"
        if error_rate:
            content += "Error Rate: **" + str(round(float(error_rate), 1)) + "%**\n"
        content += "Log: " + log_link

    except:
        content = "Alert: " + sns_message[:500]

    discord_message = {"content": content}

    req = urllib.request.Request(
        DISCORD_WEBHOOK_URL,
        data=json.dumps(discord_message).encode('utf-8'),
        headers={
            'Content-Type': 'application/json',
            'User-Agent': 'AWS-Lambda-SNS-Discord'
        },
        method='POST'
    )

    urllib.request.urlopen(req)

    return {'statusCode': 200}

3. 트리거 연동

자. 알람 확인

1. 500에러 발생

2. 디스코드 알람

5. 장애 대응 방법

1. 디스코드 알람에서 로그를 확인한 후 로그 링크를 클릭

2. 로그스트림 클릭

3. 로그이벤트 검색

• 검색 창에 입력

    { $.status >= 500 }

  해당 페이지에서 어떤 API가 어느시간대에 500에러가 떳는지 확인할 수 있다.

4. 3번에서 얻은 에러 api와 시간 정보를 가지고 백엔드 서버 로그에서 500에러뜬 api 및 확인

6. 개선 필요 사항

가. 현재 5번 프로세스가 개발자 입장에서는 너무 복잡함

현재 EC2로그에 들어가서 500발생 시간대와 API를 가지고 로그 검색을 하기에는 로그가 너무 많아 어려운 상황이기 때문에 로그 분석 환경을 별도로 만들어 개발자들에게 제공할 필요성이 있다.

드디어 풀었다..

백준 13023

1. 인사이트

1. ArrayList에 Initital Capacity를 초기에 잡아줘도 실제 size는 0이다.

   ArrayList<Integer> a = new ArrayList<>(3);
   System.out.println(a.size());
   

... 0

2. 위 13023같은 문제는 모든 노드를 출발점으로 하여 DFS를 하기 때문에, 2차원 연결 정보 그래프보다 ArrayList를 사용하는 것이 TLE(Time limit Exceeded)를 방지할 수 있다.

# 2. 전체 풀이
```java
// 백준 13023

import java.util.*;
import java.io.*;

public class P25 {
    static boolean flag = true;
    static ArrayList<ArrayList<Integer>> graph;
    static boolean[] vst;
    static int cnt = 5;

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));
        StringTokenizer st;

        int N, M;

        st = new StringTokenizer(br.readLine());
        N = Integer.parseInt(st.nextToken());
        M = Integer.parseInt(st.nextToken());

        graph = new ArrayList<>(N);

        for (int i =0; i<N; i++){
            graph.add(new ArrayList<>());
        }

        for (int i = 0; i < M; i++) {
            st = new StringTokenizer(br.readLine());

            int a = Integer.parseInt(st.nextToken());
            int b = Integer.parseInt(st.nextToken());

            graph.get(a).add(b);
            graph.get(b).add(a);
        }

        for (int i = 0; i < N; i++) {
            if (!flag) break;

            else {
                vst = new boolean[N];
                vst[i] = true;
                DFS(i, 1);
            }
        }


        if (flag) {
            bw.write(0 + "");
        } else {
            bw.write(1 + "");
        }

        bw.flush();
        bw.close();

    }

    static void DFS(int n, int dep) {

        if (!flag) {
            return;
        }
        if (dep == cnt) {
            flag = false;
            return;
        }

        for (int i : graph.get(n)) {
            if (vst[i] == false) {
                vst[i] = true;
                DFS(i, dep + 1);
                vst[i] = false;
            }
        }

    }
}

요즘 카카오 부트캠프 수업을 들으면서 깊이있는 탐구라는것이 나에게 얼마나 흥미와 관심을 가져다 주는지 모르겠다. 하지만 마음 한 편에는 우주를 공부하는 것에 막연한 기대감을 놓지 못하고 있다. 허성범의 강의를 보았고 좋아하는 것을 남들의 시선을 신경쓰지말고 최선을 다하며 하다보면 후회는 남지 않을 것이다라는 말을 되새기며 지금 하고 있는 일에 최선을 다해보려고 한다. 만약 이것이 정녕 내가 싫어하는 일이더라도 후회는 남기고 싶지 않기 때문이다. 🙈 (들어가는 이야기, 제리라는 풀스택 팀원 덕분에 해당 부분에 대한 즐거움(?)을 알게되었다.)

BFS는 Breadth의 뜻이 가장 두드러지는 노드 탐색 방법이다. 노드와 노드끼리 연결되어 있다면 한 방향으로 계속 탐색하는 것이 아닌, 이어진 주변 노드에 계속 발을 걸치는 것이다. 하지만 실제 구현은 설계와는 다른 아이러니한 점이 발생한다.

간단히 생각해보면 노드를 방문해야 방문처리를 하지만, 구현에서는 해당 노드를 방문할 예정이라고 장바구니 담듯이 담아놓는 큐에 담을 때마다 방문처리를 하는 것이다. 왜냐하면 또다른 연결된 다른 노드에 의해 한번더 중복으로 특정 노드가 한번 더 담길 수 있기 때문이다.

결론적으로 너비 우선 탐색으로 하는 BFS는 방문시에 방문체크를 한다고 하지만 정확히 말하면, 방문하기로 한 노드를 선별하는 타이밍에 방문 체크를 해줘야한다는 것이다. 바로 문제풀이로 넘어가보자

🔍 Problem

백준 11724

📃 Input&Output

*🌁 문제 배경 *

가. 문제 설명 BFS를 사용하여 총 경로의 개수를 구하는 것

나. 접근 방법 BFS를 여러번 돌리며, BFS가 실행된 개수 = 경로의 수 라는 메커니즘으로 해결하였다.

다. 문제 유형 BFS

📒 수도 코드

*가 * Bfs에 While문 씌우기

💻 Code

import java.util.*;
import java.io.*;

public class P23 {
    static int cnt=0;

    public static void main(String[] args) throws IOException{
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));
        StringTokenizer st;

        int N,M;

        st = new StringTokenizer(br.readLine());

        N = Integer.parseInt(st.nextToken());
        M = Integer.parseInt(st.nextToken());

        int[][] graph = new int[N+1][N+1];
        boolean[] vst = new boolean[N+1];

        for (int i=0; i<M; i++){
            st = new StringTokenizer(br.readLine());
            int a = Integer.parseInt(st.nextToken());
            int b = Integer.parseInt(st.nextToken());

            graph[a][b] = 1;
            graph[b][a] = 1;
        }

        BFS(vst, graph);

        bw.write(cnt+"");
        bw.flush();

        bw.close();
    }

    static void BFS(boolean[] vst, int[][] graph){

        Queue<Integer> que = new LinkedList<>();

        for (int i=1; i<vst.length; i++){
            if(!vst[i]){
                que.add(i);
                while(!que.isEmpty()){
                    int n = que.poll();
                    for (int j=1; j<vst.length; j++){
                        if (graph[n][j] == 1 && !vst[j]  ){
                            que.add(j);
                            vst[j]=true;
                        }
                    }
                }
                cnt++;
            }
        }
    }
}

🤔 느낀점

재미를 느끼고 싶다

나눠진 배열을 합치며 정렬해가는 알고리즘이다. 이게 무슨 말인고 하니, 순서대로 설명하자면 아래와 같다.

1. 원소 한개씩으로 나눈다.
2. 두개씩 묶는다.
3. 1 묶은 배열을 정렬한다.
4. 계속 두개씩 묶어서 계속 정렬한다.
5. 결국 정렬된 하나의 배열이 나온다.

2. 수도코드

25.10.02 - 08:30:00 작성예정

특정 문제를 푸는데 컴퓨터가 실행하는 연산 횟수이다. 예를들어 특정 두 수의 크기를 한번 비교하면 한번의 연산이 이루어지는 것이다. 시간복잡도는 아래와 같이 3가지로 이루어진다. 해당 시간복잡도는 프로그램의 입력값의 길이에 의해 결정된다. 하지만 표기법에서는 입력값의 길이를 n으로 지정한다. 그리고 항상 최악의 경우를 고려한다.

2. log N

해당 시간복잡도의 대표적인 연산은 이진탐색이다.

위에서 66을 찾기위해 중앙값과 비교하는 연산이 총 3번 일어나고

3. N*logN

해당 시간복잡도의 대표적인 연산은 병합정렬이다. 위에서 정렬하기 위해 각 층, 총 3개의 층에서 정렬이 한번씩 난다. 각 층마다 노드안에 포함되어 있는 숫자의 개수는 다르지만 층에서 봤을 때, 총8번의 정렬이 일어난다. 그리고 깊이는 3으로 8x3해서 총 24번이 일어난다. 시간복잡도로 따지면 n=8이므로 한층당 n번의 정렬이 일어나고 깊이는 logn이 된다. 따라서 병합정렬의 시간복잡도는 NlogN인 것이다.

백준 11004 K번째 수 구하기

📃 Input&Output

*🌁 문제 배경 *

가. 문제 설명 정렬 문제이다. 하지만 필자는 퀵정렬을 학습하고자, 퀵정렬을 구현하였다.

나. 접근 방법

다. 문제 유형

📒 수도 코드

가. 퀵정렬을 한다. ** 🔥 퀵정렬이란? **나. 정렬된 배열에서 첫번째 입력 줄의 두번째 입력값을 idx로 하는 원소를 출력한다.

💻 Code

import java.io.*;
import java.util.Arrays;
import java.util.Scanner;
import java.util.StringTokenizer;

public class P19 {

    static void quickSort(int[] arr){
        if(arr.length==1){
            return;
        }
        quickSort(arr, 0, arr.length-1);
    }

    static void quickSort(int[] arr, int start, int end) {
        int part2 = partition(arr,start,end); // part2 : 두번째 배열의 첫번째 idx
        if(start+1<part2){
            quickSort(arr,start,part2-1);
        }
        if(part2<end){
            quickSort(arr,part2,end);
        }

    }
    static int partition(int[] arr, int start, int end){
        int pivot = arr[(start+end)/2];

        while(start<=end){
            while(arr[start]<pivot) start++;
            while(arr[end]>pivot) end--;
            if(start<=end){
                swap(arr, start, end);
                start++;
                end--;
            }
        }

        return start;       // 두 번째 파티션의 첫 번째 index를 결국 start가 end를 넘어서 반환
    }

    static void swap(int[] arr, int start, int end){
        int tmp = arr[start];
        arr[start] = arr[end];
        arr[end] = tmp;
    }

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));
        StringTokenizer st = new StringTokenizer(br.readLine());
        int N = Integer.parseInt(st.nextToken());
        int M = Integer.parseInt(st.nextToken());
        int[] arr = new int[N];
        st = new StringTokenizer(br.readLine());
        for(int i=0; i<N; i++){
            arr[i] = Integer.parseInt(st.nextToken());
        }
        quickSort(arr);
        bw.write((arr[M-1])+"");

        bw.flush();
        bw.close();

    }
}

🤔 느낀점

List정렬이 배열 정렬보다 더 안전하다고 한다. 그렇다면 배열을 리스트로 바꾸는 방법은 무엇일까

int[] arr = new int[]{1,2,4,1,2};
List<Integer> list = Arrays.stream(arr).boxed().toList()

Integer[] arr = ~;
list = Arrays.asList(arr);

결국 List는 래퍼클래스 자료형이 필요했던 것이다.