Let there be Light

[reciping 3차] 서비스에 맞춰 배포 전략을 직접 비교해봐요! - 장/단점 정리

S_N_Y — Wed, 5 Nov 2025 05:46:20 +0900

※ 기존에 기록해둔 노션 글을 옮겨적은 것으로, 노션 템플릿에 맞게 적게된 글이라 해당 링크를 통해 더 가독성있게 보실 수 있습니다.

https://www.notion.so/2690661ce62880c9ae52cd0a90c13cdd

서비스에 맞춰 배포 전략을 직접 비교해봐요! - 장/단점 정리 | Notion

1. 각 배포 전략별 특징

pleasant-sand-55a.notion.site

MSA로 분리된 서버들의 각 특징에 맞게 배포 전략을 수립하는 겸, reciping의 User-service를 기준으로 배포 전략(카나리, 블루그린, 롤링)을 각각 모니터링툴(prometheus-grafana) K6를 이용하여 직접 비교하며 장단점을 비교해보겠습니다.

1. 각 배포 전략별 특징

항목	카나리(Argo Rollouts)	블루-그린(Argo Rollouts)	롤링 업데이트(K8s Deployment)
리스크/블라스트 반경	매우 낮음(점진)	낮음(즉시 전환)	중간(점진이지만 전체 대상)
롤백 속도	빠름(스텝 롤백/중단)	매우 빠름(트래픽 스위치)	느린 편(이전 ReplicaSet 재기동)
지연/끊김	거의 없음(가중치 전환)	거의 없음(스위치 순간만 주의)	거의 없음(준비성 검증 필요)
전체 소요 시간	가장 김(스텝+검증)	짧음(빌드 2셋+스위치)	중간
모니터링/자동화	높음(분석 템플릿 권장)	중간(스위치 전 검증)	낮음(기본 헬스체크)
인프라 비용	중간(일시 120~150%)	높음(항상 200%)	낮음(110~130%)
구현 복잡도	중간~높음	중간	낮음
데이터 마이그레이션	확장-수축에 최적	호환 전환에 유리	주의 필요
캐시/세션 영향	단계적 검증 용이	교체 시 캐시 워밍 필요	점진 교체로 비교적 안전
트래픽 제어	정밀(가중치/헤더/쿠키)	on/off 스위치	없음(컨트롤 불가)
관측 성숙도 요구	높음	중간	낮음

2. 사전 시나리오 및 사용할 표 템플릿 ️

2-1) 사전 시나리오 -요약본

기준선 10~15분 수집 : RPS, 오류율, p95, CPU/메모리, 재시작
부하 : k6
대시보드 : 그라파나 유저팀 전용 대시보드인 user-service-overview 활용
[ 롤링 업데이트] : (리소스 2배 기준) 롤백은 이전 ReplicaSet 재기동으로
[ 블루 그린 ] : (리소스 2배 기준) 프리뷰 예열/스모크 후 스위치
[ 카나리 ] : 유의 → SLO 기준이라 표 상으로는 시간이 가장 길 수 있음. → 현재는 Pod 비율 기반 분할

2-1) 사전 시나리오 - 상세본

0️⃣ [ 실험 설계 ]

1) 카나리

현재 스텝을 실험형으로 조정: 30%→60%→100%, 각 단계 3~5분 관찰.
실패 유도 한 번 포함(의도적 readiness 실패/느린 응답 등) → Abort 후 복구시간 실측.

승격 및 중단 커멘트 명령어들은 아래와 같습니다.

kubectl argo rollouts get rollout reciping-user-service -n reciping | cat
kubectl argo rollouts promote reciping-user-service -n reciping
kubectl argo rollouts abort reciping-user-service -n reciping

롤백 시간 계측 하는 법 : Abort 시각(t0)과 오류율/지연이 기준선으로 회복된 시각(t1)을 기록

2) 블루그린

rollout.yaml의 strategy: blueGreen 블록 선택

예시) activeService, previewService, autoPromotionEnabled/Seconds, scaleDownDelaySeconds.

실험 절차: 그린(프리뷰) 레플리카 예열 → 내부 스모크(소량 부하) → 스위치 → ALB/연결 드롭/5xx 유무 확인.
롤백 시간 계측 하는 법 : 스위치 되돌리기(수 초~수십 초). t0(스위치)~t1(오류율 0% 근접·HealthyHostCount 안정) 기록

3) 롤링업데이트

블루그린과 마찬가지로rollout.yaml에 strategy.rollingUpdate 블록 선택
실험 포인트: 레디니스 실패율, unavailableReplicas, 배포 총소요, rollout undo 롤백 시간.

1️⃣ [ 계측 쿼리 ]

기존에 PromQL을 적용한 커스텀 대시보드와 동일 라벨로 정리할 것이고, 적용한 쿼리는 아래와 같습니다.

https://github.com/Reciping/reciping-k8s-resources/blob/dev/manifests/monitoring/dashboards/user-service-overview.yaml

reciping-k8s-resources/manifests/monitoring/dashboards/user-service-overview.yaml at dev · Reciping/reciping-k8s-resources

AI기반 통합 레시피 추천 및 검색 플랫폼 '레시핑' - Helm chart, ArgoCD, Manifest, Monitoring, kubectl - Reciping/reciping-k8s-resources

github.com

(PromQL 기준)

오류율(%) :

"100 * ( ( sum by (reciping_service) (rate(http_server_requests_seconds_count{namespace=\"reciping\",reciping_team=\"$team\",reciping_service=\"$service\",status=~\"5..\",uri!~\"/actuator/.*\",uri=~\"$endpoint\"}[5m])) or on (reciping_service) (0 * sum by (reciping_service) (rate(http_server_requests_seconds_count{namespace=\"reciping\",reciping_team=\"$team\",reciping_service=\"$service\",uri!~\"/actuator/.*\",uri=~\"$endpoint\"}[5m])) ) ) / clamp_min( sum by (reciping_service) (rate(http_server_requests_seconds_count{namespace=\"reciping\",reciping_team=\"$team\",reciping_service=\"$service\",uri!~\"/actuator/.*\",uri=~\"$endpoint\"}[5m])), 1) )", "legendFormat": "{{reciping_service}}"

p95 :

"histogram_quantile(0.95, sum by (le) ( rate(http_server_requests_seconds_bucket{namespace=\"reciping\",reciping_team=\"$team\",reciping_service=\"$service\",uri!~\"/actuator/.*\",uri=~\"$endpoint\"}[5m]) ))", "legendFormat": "P95"

RPS :

"sum by (reciping_service) (rate(http_server_requests_seconds_count{namespace=\"reciping\",reciping_team=\"$team\",reciping_service=\"$service\",uri!~\"/actuator/.*\",uri=~\"$endpoint\"}[5m]))", "legendFormat": "{{reciping_service}}"

컨테이너 재시작(5m) :

"sum by (pod) (increase(kube_pod_container_status_restarts_total{namespace=\"reciping\"}[5m]))", "legendFormat": "{{pod}}"

2️⃣ [ 실행·기록 체크리스트 ]

[ ] 베이스라인 : 배포 10~15분 전 기준 RPS/p95/p99/오류율/CPU/메모리 캡쳐
[ ] 배포 이벤트 타임스탬프 : 시작, 단계 승격/스위치, 종료, 롤백 시작/종료 각각 기록
[ ] 스파이크 캡처 : 각 이벤트±2분 윈도우의 p95 피크, 오류율 피크 수치 기록
[ ] 비용/자원 : 동시 가동 Pod-분(레플리카×시간) 추정치 기록

3️⃣ [ 사용할 최종 표 템플릿 ]

트래픽 차단 기준(traffic cutoff) / SLO 회복 기준(오류율/지연이 베이스라인으로 돌아올 때)으로 분리

참고) Prometheus 5m rate/quantile 윈도우와 컨트롤러 상태(Progressing→Healthy)를 기준으로 SLO 측정

전략	배포 총소요	롤백 소요(트래픽 차단/SLO 회복)	RPS 피크	RPS 평균	p95 피크(s)	p95 평균(s)	오류율 피크(%)	오류율 평균(%)	비고
카나리
블루그린
롤링업데이트

3. 부하(k6) 세팅하기

부하를 주기 위해서 k6를 세팅해보겠습니다.

먼저 reciping-k8s-resource/test/k6-user-service.js 추가

https://github.com/Reciping/reciping-k8s-resources/blob/dev/test/k6-user-service.js

reciping-k8s-resources/test/k6-user-service.js at dev · Reciping/reciping-k8s-resources

AI기반 통합 레시피 추천 및 검색 플랫폼 '레시핑' - Helm chart, ArgoCD, Manifest, Monitoring, kubectl - Reciping/reciping-k8s-resources

github.com

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  scenarios: {
    steady: {
      executor: 'constant-arrival-rate',
      rate: __ENV.RATE ? parseInt(__ENV.RATE) : 300, // req/s
      timeUnit: '1s',
      duration: __ENV.DURATION || '15m',
      preAllocatedVUs: __ENV.VUS ? parseInt(__ENV.VUS) : 100,
      maxVUs: __ENV.MAX_VUS ? parseInt(__ENV.MAX_VUS) : 200,
    },
  },
  thresholds: {
    http_req_failed: ['rate<0.01'],
    http_req_duration: ['p(95)<300'], // p95 < 300ms 기본 SLO
  },
};

const BASE = __ENV.BASE || 'http://reciping-user-service.reciping:8080';
const paths = [
  '/api/v1/users/signup',
  '/api/v1/users/123/created-at',
  '/api/v1/users/me',
  '/api/v1/mypage',
  '/api/v1/mypage/bookmarks',
  '/api/v1/auth/refresh',
  '/login',
];

export default function () {
  const p = paths[Math.floor(Math.random() * paths.length)];
  const res = http.get(`${BASE}${p}`, { tags: { endpoint: p } });
  check(res, { 'status<400': (r) => r.status < 400 });
  sleep(0.05);
}

k6 설치하기 (윈도우 bash 기준)

choco install k6 -y

# choco 설치되어 있어야 합니다.(관리자 권한으로 실행)

# 스크립트 적용/갱신
kubectl -n reciping create configmap k6-user-script --from-file=test/k6-user-service.js --dry-run=client -o yaml | kubectl apply -f -

# 기존 잡 제거 후 실행
kubectl -n reciping delete job k6-user-baseline --ignore-not-found
cat <<'YAML' | kubectl apply -f -
apiVersion: batch/v1
kind: Job
metadata:
  name: k6-user-baseline
  namespace: reciping
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: k6
          image: grafana/k6:0.46.0
          env:
            - name: RATE
              value: "200"        # 안정 확인 후 300으로 재실행
            - name: DURATION
              value: "15m"
            - name: VUS
              value: "100"
            - name: MAX_VUS
              value: "200"
          args: [ "run", "-e", "BASE=http://reciping-user-service.reciping:8080", "/scripts/k6-user-service.js" ]
          volumeMounts: [ { name: script, mountPath: /scripts } ]
      volumes:
        - name: script
          configMap:
            name: k6-user-script
            items: [ { key: k6-user-service.js, path: k6-user-service.js } ]
YAML

kubectl -n reciping logs -f job/k6-user-baseline

home@DESKTOP-0L33BAC MINGW64 ~/Desktop/groom/dev_sini/reciping-k8s-resources (dev)
$ kubectl -n reciping get job k6-user-baseline -o jsonpath='{.status.startTime}{"\n"}'
2025-08-21T17:10:01Z

# 이렇게 시간을 확인하고, 그라파나 대시보드에서 t0-1m, To: t1+1m로 설정 후 Apply

4. 대시보드에서 나온 데이터 값 쉽게 확인하는 방법

t0-1m, To: t1+1m로 설정 후 Apply time range 클릭

각 표의 … 클릭 후 Edit 클릭

우측에서 Legend - Values에서 이런 식으로 세팅 (실제로는 Max와 Mean으로만 측정)

아래와 같이 세팅되는 것을 확인할 수 있습니다.

배포 전략 별 비교 원본 데이터 캡쳐본

[ 카나리 ]

기존 배포 전략이 카나리로 시작했기 때문에 그대로 실행

1. 드레인 테스트 - 카나리 60%에서 실행한 결과

2. 크래시 테스트 - 카나리 60%에서 실행한 결과

3. 롤백

home@DESKTOP-0L33BAC MINGW64 ~/Desktop/groom/dev_sini/reciping-k8s-resources (dev)
$ TS=$(date -u +%Y-%m-%dT%H:%M:%SZ); echo patch_restartedAt=$TS; kubectl -n reciping patch rollout user-service-app-reciping-user-service --type=merge -p '{"spec":{"template":{"metadata":{"annotations":{"kubectl.kubernetes.io/restartedAt":"'$TS'"}}}}}' | cat; echo "waiting for Healthy..."; for i in {1..120}; do PHASE=$(kubectl -n reciping get rollout user-service-app-reciping-user-service -o jsonpath='{.status.phase}' 2>/dev/null); echo phase=${PHASE:-}; if [ "$PHASE" = "Healthy" ]; then echo t_abort1_KST=$(TZ=Asia/Seoul date '+%Y-%m-%d %H:%M:%S KST'); break; fi; sleep 2; done; kubectl -n reciping get rollout user-service-app-reciping-user-service -o jsonpath='{.status.stableRS} {"\n"}'
patch_restartedAt=2025-08-21T18:49:02Z
rollout.argoproj.io/user-service-app-reciping-user-service patched
waiting for Healthy...
phase=Progressing
phase=Progressing
phase=Progressing
phase=Progressing
phase=Progressing
phase=Progressing
phase=Progressing
phase=Progressing
phase=Progressing
.
.
.
phase=Progressing
phase=Progressing
phase=Progressing
phase=Paused
phase=Paused
phase=Paused
7d4d84ff5c 

home@DESKTOP-0L33BAC MINGW64 ~/Desktop/groom/dev_sini/reciping-k8s-resources (dev)
$ kubectl -n reciping get rollout user-service-app-reciping-user-service \
  -o jsonpath='{.status.abortedAt}{"\n"}{.status.conditions[?(@.type=="Available")].lastTransitionTime}{"\n"}'

2025-08-21T18:47:23Z

[ 블루그린 ]

1) 블루그린으로 스위치

# 차트에 반영된 값: strategy.type=blueGreen 로 바꾸고 배포
yq -i '.strategy.type = "blueGreen"' charts/reciping-user-service/values.yaml
# 변경 확인 - 굳이 안 해도 됨
git diff -- charts/reciping-user-service/values.yaml | cat

2) ArgoCD 동기화

argocd app sync user-service-app

3) 프리뷰 예열 확인

kubectl -n reciping get svc reciping-user-service reciping-user-service-preview
kubectl -n reciping get rs,po -l app=reciping-user-service -o wide

4) 스위치와 롤백 측정

스위치 시작 시각(t_sw0 KST) 기록 후, 프리뷰→액티브 승격

TZ=Asia/Seoul date '+t_sw0(KST)=%Y-%m-%d %H:%M:%S KST'

# 블루그린 승격(자동승격 false라 수동 필요)
# 플러그인 없으면 서비스 셀렉터 전환으로도 가능하지만, 여기서는 Argo Rollouts 승격
# argo rollouts 플로그인 설치되어있을 경우, 아래와 같이 쉽게 승격 가능
kubectl argo rollouts promote user-service-app-reciping-user-service -n reciping

스위치 완료 : svc/reciping-user-service의 Grafana에서 오류율/지연 회복 확인
롤백 테스트(t_bg_rb0): 바로 반대로 되돌림

kubectl argo rollouts promote --to-revision <stable-revision> user-service-app-reciping-user-service -n reciping

블루그린 롤백 캡쳐 데이터

이런 식으로 롤링 업데이트까지 완료

️ 최종 표 완성본

전략	배포 총소요	롤백 소요(트래픽/SLO 회복)	RPS 피크	RPS 평균	p95 피크(s)	p95 평균(s)	오류율 피크(%)	오류율 평균(%)	비고
카나리	10–20m	00:05 / 14:30	198	195	0.0364	0.00943	17.2	15.2	60% 단계 Abort, 5m 윈도우·컨트롤러 상태 반영
블루그린	3–5s(스위치) / 예열 포함 1–3m	00:03 / 00:45	195	190	0.006	0.003	0.3	0.1	프리뷰 2 예열, 드레인 OK 가정
롤링업데이트	1–3m	해당 없음 / 02:00	183	171	0.030	0.020	0.8	0.5	maxSurge=0, 이미지 캐시 가정

결론

☑️ 카나리 : SLO 회복 기준(5m 윈도우, 유도 장애, 60% 단계)이라 길게 보이긴 하지만, 트래픽 cutoff 기준이면 수 초만 걸림

☑️ 블루그린 : 프리뷰 2 예열(동일 비용) 가정일 때지만, 잘못 스위치하면 전체 영향(폭발 반경 100%)이라는 위험 존재

☑️ 롤링 : replicas=2, maxSurge=0 가정에서 1~3분이나 규모 커지면 더 늘어남(소규모(2개)면 1~3m도 가능, 대규모일수록 분·십여 분)

[ 최종 결론 ]

고위험/불확실 변경(런타임, 주요 로직, 성능 민감) + 위험 최소화일 경우 : → 카나리 기본. 폭발 반경 제한, 메트릭 게이팅, 단계적 승격/중단.
비호환 스키마/런타임 교체/즉시 롤백이 최우선일 경우 : → 블루그린(예열 확보+스위치, 캐시 워밍/연결 드레인만 주의)
저위험/작은 변경(Stateless, 빠른 교체)일 경우 : → 롤링업데이트(maxUnavailable/surge로 속도·안정성 트레이드 오프해야 함)

[ reciping-user-service 자체에 대한 배포 전략 결론 ]

⇒ reciping-user-service는 유저 서비스인 만큼 사용자 체감 지연과 실패율에 민감합니다. 실측 결과, 카나리에서 단계별 p95 변동은 있었으나 오류율은 SLO 내 유지되었고, 롤백은 1분 내 복귀했습니다. 블루그린은 스위치/롤백 시간이 총합 기준으로는 가장 짧았으나, 자원 비용이 높을 수 밖에 없는 구조였습니다. 롤링 업데이트는 배포 속도가 괜찮지만 실패 시에 롤백 시간까지 고려한다면 이전 ReplicaSet 재기동해야하기 때문에 절차가 다른 배포 전략보다 어렵고 치명적이라고 판단했습니다. 이에 따라 주요 로직인 user-service의 기존 전략대로 기본 전략은 카나리로(메트릭 게이트 적용), 비호환 릴리스나 즉시롤백이 필요하다면 블루그린, 경미한 변경은 롤링업데이트로 운영해야한다고 판단하는 걸로 결론 지었습니다.

[reciping 3차] 모니터링 구축하기 - 태그기반 팀별 대시보드 구성 및 추이기반 알람 세팅까지

S_N_Y — Wed, 5 Nov 2025 05:46:01 +0900

※ 기존에 기록해둔 노션 글을 옮겨적은 것으로, 노션 템플릿에 맞게 적게된 글이라 해당 링크를 통해 더 가독성있게 보실 수 있습니다.

https://www.notion.so/2690661ce62880aea2ddeaa87e17e48f

모니터링 구축하기 - 태그기반 팀별 대시보드 구성 및 추이기반 알람 세팅까지 | Notion

1. 사전 작업

pleasant-sand-55a.notion.site

1. 사전 작업

백엔드 서버와 helm chart에서 사전에 작업해야하는 것들입니다.

1-1) 백엔드 서버

build.gradle에 프로메테우스 레지스트리 의존성 추가

implementation 'io.micrometer:micrometer-registry-prometheus'

build.gradle에 actuator 의존성 추가

implementation 'org.springframework.boot:spring-boot-starter-actuator'

applications.properties(혹은 yaml)에 아래를 추가

management:
  endpoints:
    web:
      exposure:
        include: health,info,prometheus

  endpoint:
    health:
      probes:
        enabled: true   # /actuator/health/liveness, /readiness 활성화
    prometheus:
      enabled: true

  metrics:
    distribution:
      percentiles-histogram: # HTTP 히스토그램(퍼센타일) 활성화 권장
        http:
          server:
            requests: true

+) securityConfig가 설정되어있는 서버라면 SecurityFilterChain을 아래와 같이 추가

(/actuator/prometheus 등 프로메테우스 관련 actuator 경로를 노출시켜주어야 합니다.)

https://github.com/Reciping/reciping-ads-service-BE/commit/6ca4a3cb99d81fecb793755bba0b99f72f87aa60

:recycle: refactor : permit for monitoring health check · Reciping/reciping-ads-service-BE@6ca4a3c

+ .requestMatchers("/actuator/health", "/actuator/health/**", "/actuator/info", "/actuator/prometheus").permitAll()

github.com

1-2) helm chart

요약 : 각 서비스의 기존 helm chart에서 podmonitor.yaml, rollout.yaml, values.yaml 수정 필요

각 서비스의 podmonitor.yaml 추가 (아래 깃헙에서 코드 확인)

https://github.com/Reciping/reciping-k8s-resources/blob/dev/charts/reciping-user-service/templates/podmonitor.yaml

reciping-k8s-resources/charts/reciping-user-service/templates/podmonitor.yaml at dev · Reciping/reciping-k8s-resources

AI기반 통합 레시피 추천 및 검색 플랫폼 '레시핑' - Helm chart, ArgoCD, Manifest, Monitoring, kubectl - Reciping/reciping-k8s-resources

github.com

https://github.com/Reciping/reciping-k8s-resources/blob/dev/charts/reciping-ads-service/templates/podmonitor.yaml

reciping-k8s-resources/charts/reciping-ads-service/templates/podmonitor.yaml at dev · Reciping/reciping-k8s-resources

AI기반 통합 레시피 추천 및 검색 플랫폼 '레시핑' - Helm chart, ArgoCD, Manifest, Monitoring, kubectl - Reciping/reciping-k8s-resources

github.com

기존 각 서비스 helm chart에 team 태그를 추가해야 합니다.

# 각 helm chart의 values.yaml에 team 추가 (예시 : 유저팀)
# reciping-k8s-resource/charts/reciping-user-service/values.yaml
team: user

그리고 values.yaml에도 actuator 경로 노출(각 서비스 helm chart의 values.yaml 경로 참고하기)

metrics:
  prometheus:
    enabled: true
    path: /actuator/prometheus
    port: 8080
    podMonitor:
      enabled: true

rollout.yaml에 업데이트한 team 태그 환경변수로 추가

reciping.io/team: {{ .Values.team }}

⬇️ 이런 식으로 수정합니다.

https://github.com/Reciping/reciping-k8s-resources/commit/2782c5165c6c9392614d20d3538350062ef39394

:recycle: refactor : set team tag · Reciping/reciping-k8s-resources@2782c51

checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}

github.com

2. Slack으로 임계치 알람받기

slack webhook url이 필요하기 때문에 그 작업을 먼저 해주겠습니다.

slack 앱 디렉토리 접속

https://api.slack.com/apps

Slack API: Applications | Slack

Your Apps Don't see an app you're looking for? Sign in to another workspace.

api.slack.com

Create New App → From scratch 선택

슬랫봇처럼 커스텀 슬랙봇 이름 정하기 - Monitoring Alerts 적기

Incoming Webhooks → Activate Incoming Webhooks → On

Add New Webhook 클릭

알람 받을 채널 선택 - 슬랙에 먼저 각 팀별 서버 파고 여기서 지정하면 됩니다.

발급받은 Webhhook URL 복사하면 됩니다.

팀별로 웹훅 만든 모습

해당 URL을 Copy해서 kube-prometheus-stack관련 설정 파일(저장소, 대시보드, Grafana Ingress(ALB)/PVC, Alertmanager 팀별 라우팅(ads/user)등..) values.yaml을 세팅합니다.

최종 완성본은 아래를 참고하세요.

https://github.com/Reciping/reciping-k8s-resources/blob/dev/monitoring/values.yaml

reciping-k8s-resources/monitoring/values.yaml at dev · Reciping/reciping-k8s-resources

AI기반 통합 레시피 추천 및 검색 플랫폼 '레시핑' - Helm chart, ArgoCD, Manifest, Monitoring, kubectl - Reciping/reciping-k8s-resources

github.com

+) Alert rule 세팅하기 - 추이기반(베이스라인) 알람 세팅까지

그리고 PromQL을 커스텀으로 세팅해서 어떤 hook에 알람을 받을지 정의합니다.

1. 일반 alerts hook 세팅

< 설정 설명 1 >

http-availability :

ServiceErrorRateHighWarning: 5xx 비율 > 5% 10분
ServiceErrorRateHighCritical: 5xx 비율 > 10% 5분
ServiceInstancesDown: 해당 서비스 타겟 up이 0 → 2분

http-latency :

ServiceLatencyP95High: P95 > 500ms 10분
ServiceLatencyP99High: P99 > 1s 5분

jvm-and-runtime :

JvmHeapUsageHigh: heap 사용률 > 90% 10분
ContainerRestarts: 5분 내 재시작 발생 시 경고

https://github.com/Reciping/reciping-k8s-resources/blob/dev/manifests/monitoring/rules/service-prod-rules.yaml

reciping-k8s-resources/manifests/monitoring/rules/service-prod-rules.yaml at dev · Reciping/reciping-k8s-resources

AI기반 통합 레시피 추천 및 검색 플랫폼 '레시핑' - Helm chart, ArgoCD, Manifest, Monitoring, kubectl - Reciping/reciping-k8s-resources

github.com

2. 추이 기반(베이스라인) alerts hook 세팅

< 설정 설명 2 >

http-anomaly :

ServiceTrafficAnomaly: 최근 5분 RPS가 1시간 평균 대비 3σ 초과(그리고 RPS>0.1) 10분
ServiceErrorRateAnomaly: 최근 5분 에러율이 1시간 평균 대비 3σ 초과(그리고 RPS>0.1) 10분

https://github.com/Reciping/reciping-k8s-resources/blob/dev/manifests/monitoring/rules/service-anomaly-rules.yaml

reciping-k8s-resources/manifests/monitoring/rules/service-anomaly-rules.yaml at dev · Reciping/reciping-k8s-resources

AI기반 통합 레시피 추천 및 검색 플랫폼 '레시핑' - Helm chart, ArgoCD, Manifest, Monitoring, kubectl - Reciping/reciping-k8s-resources

github.com

3. monitoring app 배포하기 ️

ArgoCD 기반으로 모니터링툴도 배포할 것입니다. monitoring-app.yaml도 작성해줍니다.

(Helm 차트 + manifests/monitoring 동시 적용)

https://github.com/Reciping/reciping-k8s-resources/blob/dev/app/monitoring-app.yaml

reciping-k8s-resources/app/monitoring-app.yaml at dev · Reciping/reciping-k8s-resources

AI기반 통합 레시피 추천 및 검색 플랫폼 '레시핑' - Helm chart, ArgoCD, Manifest, Monitoring, kubectl - Reciping/reciping-k8s-resources

github.com

EBS CSI 드라이버 설치 기반 Storage Class(gp3 혹은 gp2) 정의 - PVC

https://github.com/Reciping/reciping-k8s-resources/blob/dev/manifests/storage/gp2-csi.yaml

reciping-k8s-resources/manifests/storage/gp2-csi.yaml at dev · Reciping/reciping-k8s-resources

AI기반 통합 레시피 추천 및 검색 플랫폼 '레시핑' - Helm chart, ArgoCD, Manifest, Monitoring, kubectl - Reciping/reciping-k8s-resources

github.com

Storage Class는 ebs.csi.aws.com 프로비저너가 있어야 합니다. Add-on이 없다면 설치가 필요합니다.

(설치되어 있지 않다면 콘솔에서 EBS CSI 활성화 해주기)

# 클러스터 이름 먼저 확인
aws eks list-clusters --region ap-northeast-2

# EKS Add-on 설치
eksctl enable addon --name aws-ebs-csi-driver --cluster <cluster-name> --region ap-northeast-2

# IRSA 역할 생성 + SA에 주입
eksctl create iamserviceaccount \
  --cluster reciping-cluster \
  --namespace kube-system \
  --name ebs-csi-controller-sa \
  --role-name AmazonEKS_EBS_CSI_DriverRole \
  --attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \
  --override-existing-serviceaccounts \
  --approve \
  --region ap-northeast-2
  
# EKS 애드온에 역할 연결
aws eks update-addon \
  --cluster-name reciping-cluster \
  --addon-name aws-ebs-csi-driver \
  --service-account-role-arn <위 Role ARN> \
  --region ap-northeast-2

# 선택사항) 드라이버 준비 확인 - 두 리소스가 모두 Ready여야 함.

# 컨트롤러 확인
kubectl -n kube-system get deploy ebs-csi-controller
# 노드 컴포넌트 확인
kubectl -n kube-system get ds ebs-csi-node

-------
# 나중에 배포됐을 경우, PVC 이벤트 확인할 때 사용하는 명령어
# Events에 'provisioned' / 'bound' 메시지가 뜨면 정상
kubectl -n monitoring get pvc
kubectl -n monitoring describe pvc kube-prometheus-stack-grafana

monitoring 네임스페이스 만들기

# yaml에 네임스페이스까지 자동으로 만드는 것까지 정의되어있으나, 혹시 모르니 미리 만들어두기
kubectl create namespace monitoring

모니터링 앱 배포하기

kubectl apply -n argocd -f app/monitoring-app.yaml

결과 :

사전에 웹훅 발생시킬 수 있는 명령어 입력 후, 제대로 동작하는지 확인

참고) Container sleep 임의 발생 후, Restart 명령어

POD=$(kubectl -n reciping get pod -l app=reciping-user-service -o jsonpath='{.items[0].metadata.name}')
CNTR=$(kubectl -n reciping get pod "$POD" -o jsonpath='{.spec.containers[0].name}')

# 먼저 정상 동작하는지 테스트: 시그널 거부면 Permission denied가 뜸
kubectl -n reciping exec "$POD" -c "$CNTR" -- sh -c 'kill -s TERM 1 || true'
sleep 2
kubectl -n reciping exec "$POD" -c "$CNTR" -- sh -c 'kill -s KILL 1 || true'

kubectl -n monitoring port-forward svc/kube-prometheus-stack-prometheus 9090:9090
# 브라우저 → http://localhost:9090/rules → service-prod-rules 확인
# 또는 Alertmanager에서 Firing 시 Slack 메시지 한글 문구 확인

9090으로 포트포워딩한 뒤, rules 확인하면 각 적용된 rules를 확인할 수 있습니다.

# alertmanager는 아래로 포트포워딩 후 확인
kubectl -n monitoring port-forward svc/kube-prometheus-stack-alertmanager 9093:9093
# 브라우저 http://localhost:9093/#/alerts → 동일 알람 Firing 확인
# Slack: #user-alerts, #ads-alerts 채널로 도착 확인

해당 오류(예 : ContainerRestartRaw)(웹훅)가 발생하면 Alertmanager에 해당 user-slack alert이 생기는 것을 알 수 있습니다.

ContainerRestart 알람 웹훅 발생

팀별, 서비스별, 심각도별, 상태별 구분되어 알람이 가는 모습

+) 영상 기록

Route53에서 와일드카드(*.reciping.kr)을 정의해두고 있어서 ACM ARN 적용하면 되니, https://grafana.reciping.kr 연결 쉽게 가능

첫 로그인 화면 - username : admin / password : kelly123

# 초기 username/password 아는 법

# username
kubectl -n monitoring get secret kube-prometheus-stack-grafana -o jsonpath='{.data.admin-user}' | base64 -d; echo
# password
kubectl -n monitoring get secret kube-prometheus-stack-grafana -o jsonpath='{.data.admin-password}' | base64 -d; echo

4. 태그 기반으로 팀별 대시보드 구성하기

이미 태그 기반으로 대시보드가 나타나게는 구성이 되어있으나, 팀별 커스텀한 대시보드는 따로 구성해야 합니다.

1) 부서별 대시보드 구성 yaml 파일 추가 후, 모니터링 앱 재배포하기

https://github.com/Reciping/reciping-k8s-resources/blob/dev/manifests/monitoring/dashboards/user-service-overview.yaml

reciping-k8s-resources/manifests/monitoring/dashboards/user-service-overview.yaml at dev · Reciping/reciping-k8s-resources

AI기반 통합 레시피 추천 및 검색 플랫폼 '레시핑' - Helm chart, ArgoCD, Manifest, Monitoring, kubectl - Reciping/reciping-k8s-resources

github.com

https://github.com/Reciping/reciping-k8s-resources/blob/dev/manifests/monitoring/dashboards/ads-service-overview.yaml

reciping-k8s-resources/manifests/monitoring/dashboards/ads-service-overview.yaml at dev · Reciping/reciping-k8s-resources

AI기반 통합 레시피 추천 및 검색 플랫폼 '레시핑' - Helm chart, ArgoCD, Manifest, Monitoring, kubectl - Reciping/reciping-k8s-resources

github.com

+) advanced 대시보드를 하나 더 만들어서 알람배지(패널링크)로 Alertmanager/Explore 링크 추가도 가능

여기서 알람 배지(패널링크)란?

: 대시보드 상단에 작은 통계 배지 패널(예: “Active Alerts”)을 두고, 배지를 클릭하면 Alert 상세 페이지나 Explore/Alertmanager로 바로 이동하는 “패널 링크”를 붙이는 것

배지에 아래처럼 링크를 붙일 수 있습니다 ⬇️

Alertmanager UI: /alertmanager/#/alerts?filter=reciping_team%3Duser
Explore(사전 쿼리 포함): /explore?left=...ALERTS%7Breciping_team%3D%22user%22%7D...

+) 해당 advanced 대시보드 yaml 코드

apiVersion: v1
kind: ConfigMap
metadata:
  name: grafana-dashboard-user-service-advanced
  namespace: monitoring
  labels:
    grafana_dashboard: "1"
  annotations:
    grafana_folder: "Teams"
data:
  user-service-advanced.json: |
    {"schemaVersion":39,"version":1,"title":"User Service Advanced","tags":["team:user"],"time":{"from":"now-6h","to":"now"},
     "templating":{"list":[
       {"name":"team","type":"constant","label":"team","query":"user","hide":2},
       {"name":"service","type":"constant","label":"service","query":"reciping-user-service","hide":2},
       {"name":"endpoint","type":"custom","label":"endpoint","query":"^/api/v1/users/signup$,^/api/v1/users/.*/created-at$,^/api/v1/users/me$,^/api/v1/mypage$,^/api/v1/mypage/bookmarks$,^/api/v1/auth/refresh$","includeAll":true,"allValue":".*","multi":true,"current":{"text":"All","value":["$__all"]}}
     ]},
     "panels":[
      {"type":"row","title":"Badges","collapsed":false,"gridPos":{"h":1,"w":24,"x":0,"y":0}},
      {"type":"stat","title":"Active Alerts (User)","gridPos":{"h":3,"w":6,"x":0,"y":1},
       "targets":[{"expr":"count(ALERTS{alertstate=\"firing\",reciping_team=\"user\"})"}]},
      {"type":"stat","title":"5xx Error Rate (%)","gridPos":{"h":3,"w":6,"x":6,"y":1},
       "targets":[{"expr":"100 * ( sum(rate(http_server_requests_seconds_count{namespace=\"reciping\",reciping_team=\"user\",reciping_service=\"reciping-user-service\",status=~\"5..\",uri!~\"/actuator/.*\"}[5m])) / sum(rate(http_server_requests_seconds_count{namespace=\"reciping\",reciping_team=\"user\",reciping_service=\"reciping-user-service\",uri!~\"/actuator/.*\"}[5m])) )"}]},
      {"type":"stat","title":"P95 (s)","gridPos":{"h":3,"w":6,"x":12,"y":1},
       "targets":[{"expr":"histogram_quantile(0.95, sum by (le) ( rate(http_server_requests_seconds_bucket{namespace=\"reciping\",reciping_team=\"user\",reciping_service=\"reciping-user-service\",uri!~\"/actuator/.*\"}[5m]) ))"}]},
      {"type":"stat","title":"RPS","gridPos":{"h":3,"w":6,"x":18,"y":1},
       "targets":[{"expr":"sum(rate(http_server_requests_seconds_count{namespace=\"reciping\",reciping_team=\"user\",reciping_service=\"reciping-user-service\",uri!~\"/actuator/.*\"}[5m]))"}]},
      {"type":"row","title":"Traffic & Errors","collapsed":false,"gridPos":{"h":1,"w":24,"x":0,"y":0}},
      {"type":"timeseries","title":"RPS (5m rate)","gridPos":{"h":7,"w":12,"x":0,"y":1},
       "targets":[{"expr":"sum by (uri) (rate(http_server_requests_seconds_count{namespace=\"reciping\",reciping_team=\"$team\",reciping_service=\"$service\",uri!~\"/actuator/.*\",uri=~\"$endpoint\"}[5m]))","legendFormat":"{{uri}}"}]},
      {"type":"timeseries","title":"오류율 (5m %)","gridPos":{"h":7,"w":12,"x":12,"y":1},
       "targets":[{"expr":"100 * ( sum by (uri) (rate(http_server_requests_seconds_count{namespace=\"reciping\",reciping_team=\"$team\",reciping_service=\"$service\",status=~\"5..\",uri!~\"/actuator/.*\",uri=~\"$endpoint\"}[5m])) / sum by (uri) (rate(http_server_requests_seconds_count{namespace=\"reciping\",reciping_team=\"$team\",reciping_service=\"$service\",uri!~\"/actuator/.*\",uri=~\"$endpoint\"}[5m])) )","legendFormat":"{{uri}}"}]},

      {"type":"row","title":"Latency","collapsed":false,"gridPos":{"h":1,"w":24,"x":0,"y":8}},
      {"type":"timeseries","title":"HTTP P95 (s)","gridPos":{"h":7,"w":12,"x":0,"y":9},
       "targets":[{"expr":"histogram_quantile(0.95, sum by (uri,le) ( rate(http_server_requests_seconds_bucket{namespace=\"reciping\",reciping_team=\"$team\",reciping_service=\"$service\",uri!~\"/actuator/.*\",uri=~\"$endpoint\"}[5m]) ))","legendFormat":"{{uri}}"}]},
      {"type":"timeseries","title":"HTTP P99 (s)","gridPos":{"h":7,"w":12,"x":12,"y":9},
       "targets":[{"expr":"histogram_quantile(0.99, sum by (uri,le) ( rate(http_server_requests_seconds_bucket{namespace=\\\"reciping\\\",reciping_team=\\\"$team\\\",reciping_service=\\\"$service\\\",uri!~\\\"/actuator/.*\\\",uri=~\\\"$endpoint\\\"}[5m]) ))","legendFormat":"{{uri}}"}]},

      {"type":"row","title":"Auth & Signup Funnel","collapsed":false,"gridPos":{"h":1,"w":24,"x":0,"y":16}},
      {"type":"timeseries","title":"Signup Attempts vs Success (5m)","gridPos":{"h":6,"w":12,"x":0,"y":17},
       "targets":[
        {"expr":"sum by (status) (rate(http_server_requests_seconds_count{namespace=\\\"reciping\\\",reciping_team=\\\"$team\\\",reciping_service=\\\"$service\\\",uri=\\\"/api/v1/users/signup\\\"}[5m]))","legendFormat":"signup {{status}}"},
        {"expr":"sum by (status) (rate(http_server_requests_seconds_count{namespace=\\\"reciping\\\",reciping_team=\\\"$team\\\",reciping_service=\\\"$service\\\",uri=\\\"/api/v1/auth/refresh\\\"}[5m]))","legendFormat":"auth {{status}}"}
       ]},
      {"type":"timeseries","title":"Signup P95 (s)","gridPos":{"h":6,"w":12,"x":12,"y":17},
       "targets":[{"expr":"histogram_quantile(0.95, sum by (le) ( rate(http_server_requests_seconds_bucket{namespace=\"reciping\",reciping_team=\"$team\",reciping_service=\"$service\",uri=\"/api/v1/users/signup\"}[5m]) ))","legendFormat":"signup P95"}]},

      {"type":"row","title":"My Page","collapsed":false,"gridPos":{"h":1,"w":24,"x":0,"y":23}},
      {"type":"timeseries","title":"MyPage P95 (s)","gridPos":{"h":6,"w":12,"x":0,"y":24},
       "targets":[{"expr":"histogram_quantile(0.95, sum by (le) ( rate(http_server_requests_seconds_bucket{namespace=\"reciping\",reciping_team=\"$team\",reciping_service=\"$service\",uri=\"/api/v1/mypage\"}[5m]) ))","legendFormat":"mypage P95"}]},
      {"type":"timeseries","title":"Bookmarks RPS (5m)","gridPos":{"h":6,"w":12,"x":12,"y":24},
       "targets":[{"expr":"sum(rate(http_server_requests_seconds_count{namespace=\"reciping\",reciping_team=\"$team\",reciping_service=\"$service\",uri=\"/api/v1/mypage/bookmarks\"}[5m]))","legendFormat":"bookmarks"}]},

      {"type":"row","title":"Reliability","collapsed":false,"gridPos":{"h":1,"w":24,"x":0,"y":30}},
      {"type":"timeseries","title":"Instances Up","gridPos":{"h":6,"w":12,"x":0,"y":31},
       "targets":[{"expr":"sum by (pod) (up{namespace=\"reciping\",reciping_service=\"$service\"})","legendFormat":"{{pod}}"}]},
      {"type":"timeseries","title":"컨테이너 재시작 (5m)","gridPos":{"h":6,"w":12,"x":12,"y":31},
       "targets":[{"expr":"sum by (pod) (increase(kube_pod_container_status_restarts_total{namespace=\"reciping\"}[5m]))","legendFormat":"{{pod}}"}]}
     ]}

# 재배포 후, health 확인까지 하는 명령어
argocd app sync kube-prometheus-stack --grpc-web && argocd app wait kube-prometheus-stack --health --timeout 600 | cat

결과 :

태그가 붙어있는 모습

이런 식으로 dashboard configmap에서 Teams 폴더를 구성해놓으면 아래와 같이 teams 폴더에서 한꺼번에 확인 가능하다.

엔드포인트 별 선택 가능하게끔 세팅

광고팀 A/B 테스트 대시보드 추가된 모습

유저팀 엔드포인트 바로가기 필터를 구성한 모습

유저팀 대시보드 2

+) 영상 기록

[reciping 3차]Terraform으로 EKS 기반 인프라 구축하기 (2)

S_N_Y — Wed, 5 Nov 2025 05:45:31 +0900

※ 기존에 기록해둔 노션 글을 옮겨적은 것으로, 노션 템플릿에 맞게 적게된 글이라 해당 링크를 통해 더 가독성있게 보실 수 있습니다.

https://www.notion.so/Terraform-EKS-2690661ce62880908eafea7c3e73742c

Terraform으로 EKS 기반 인프라 구축하기 | Notion

1. 인텔리제이에서 테라폼 만들기

pleasant-sand-55a.notion.site

7. Fluent Bit DaemonSet 구성하기(Helm Provider를 이용한 배포 자동화)

Helm chart로 배포하는 것 뿐만 아니라, Helm Chart + Terraform 방식으로 재구성하고 Terraform에 있는 Helm Provider를 이용해 배포 자동화를 구현하겠습니다.

reciping-k8s-resources/
└── logging/
    ├── fluent-bit-configmap.yaml
    └── fluent-bit-daemonset.yaml
    
# 원래 버전은 위와 같으나(helm으로만 하는 것), 자동화 설정을 테라폼에서 하였으니 이 부분은 지워도 됩니다.

여기서 configmap이란? : 로그 포맷, 출력 대상, 필터 등 공통 설정값을 따로 관리 Terraform Helm Provider란? : 배포를 GitOps 스타일로 관리, 인프라 코드에 배포 상태를 통합

1. AWS에서 제공하는 Fluentbit 공식 Helm chart 설치

Terraform에서 helm_release를 통해 배포할 때는 Helm CLI 명령어를 직접 쓰지 않고, Terraform이 Helm Provider를 통해 Helm Chart를 알아서 받아와서 설치합니다.

helm repo add fluent https://fluent.github.io/helm-charts
helm repo update

2. 태깅 포함 Fluent Bit DaemonSet을 Helm + Terraform으로 자동화 구성하기

reciping-terraform/
├── modules/
│   └── fluent-bit/
│       ├── main.tf                  # Helm Release 정의
│       ├── variables.tf             # Helm에 넘겨줄 변수 정의
│       ├── outputs.tf               # Helm 설치 결과 출력 정의
│       └── values.yaml              # Helm chart용 Fluent Bit 설정
└── environments/
    └── prod/
        ├── main.tf                  # module "fluent-bit" 호출
        ├── variables.tf             # 모듈에 넘겨줄 변수 선언
        └── terraform.tfvars         # 실제 배포 환경 변수 주입

# 테라폼/생성 배포하는 법 다 완수 후, 해야할 일

# 1. fluent bit pod 확인
kubectl get pods -n observability

# 2. 로그 수집 정상 여부 확인(<fluent-bit-pod-name>에 위에서 name 뜬거 복붙)
kubectl logs -n observability <fluent-bit-pod-name>

# 3. Fluent Bit DaemonSet 확인
kubectl get pods -n observability -l app.kubernetes.io/name=fluent-bit

# 4. kafka에 정상 수집 확인
kafka-console-consumer.sh \
  --bootstrap-server 10.0.128.81:9092 \
  --topic logs.observability \
  --from-beginning

최종 결과 :

https://github.com/Reciping/reciping-terraform/tree/dev/modules/fluent-bit

reciping-terraform/modules/fluent-bit at dev · Reciping/reciping-terraform

AI기반 통합 레시피 추천 및 검색 플랫폼 '레시핑' - 테라폼. Contribute to Reciping/reciping-terraform development by creating an account on GitHub.

github.com

8. 각 서버를 Pod에 띄우기 & ArgoCD 세팅(CD)

ECR에 prod버전 이미지를 업로드한 후의 배포 문서입니다. ECR에 올리는 과정은 다음 과정에 정리되어 있습니다. (4. ECR 생성하기 참고)
️ECS(EC2, Fargate)로 백엔드 애플리케이션 배포하기 + 기본 EC2배포까지 - 7. ECR 생성하기
혹은 CI 스크립트가 github actions에 세팅되어있으면 ECR에 이미지 쉽게 업로드 되어있으니 참고
https://github.com/Reciping/reciping-user-service-BE/blob/dev/.github/workflows/ci.yml

Hem chart로 정의하고 본격적인 배포를 해보겠습니다.

reciping-k8s-resources/
└── charts/
    └── reciping-like-service/
        ├── Chart.yaml          ← 
        ├── values.yaml         ← 실제 JWT 값 등을 저장하는 장소(진짜 적용은 secret)
        └── templates/
            ├── rollout.yaml    ←   (카나리/블루그린 유연하게 변경 가능)
            ├── service.yaml    ←   ClusterIP 서비스 정의
            ├── ingress.yaml    ←   선택사항) ALB 연동시 필요(ALB 연동용 Ingress 리소스)
            ├── configmap.yaml  ←   application-prod.yaml (환경변수) 주입
            ├── secret.yaml     ←   JWT/DB credential 등 민감 정보

안에 내용들은 주석으로 설명을 세세하게 달았습니다. 커밋 참고해주세요.

https://github.com/Reciping/reciping-k8s-resources/commit/26853ccbdf3bae06192112f13d7299911fa36cd2

:sparkles: feat : update helm chart(reciping-like-service) · Reciping/reciping-k8s-resources@26853cc

+ name: like-service # 서비스 이름. Rollout, Ingress, DNS 모두 이 이름을 사용하게 됨

github.com

+) like-service여서 다른 서비스(user-service..) 주석 달아놓은 커밋 참고하시면 됩니다.

8-1 . 가장 처음 CD 시작할 시, argoCD UI가 아닌 argo CLI로 배포하기

ArgoCD 네임스페이스 설정

⇒ 보통 ArgoCD는 argocd라는 네임스페이스에 설치하는 것이 업계 표준입니다.

kubectl create namespace argocd

2. ArgoCD Helm 저장소 추가

helm repo add argo https://argoproj.github.io/argo-helm
helm repo update

3. helm chart로 argoCD 설치

helm install argocd argo/argo-cd \
  --namespace argocd \
  --create-namespace \
  --set server.service.type=LoadBalancer

# argo/argo-cd: ArgoCD의 공식 Helm Chart.
# --namespace argocd: 앞서 만든 네임스페이스에 설치.
# --set server.service.type=LoadBalancer: ArgoCD Web UI를 외부에서 접속할 수 있도록 ELB 생

4. ArgoCD 제대로 설치되어있는지 확인

kubectl get all -n argocd

결과화면

+) ArgoCD CLI 설치하고 아래 명령어로 제대로 설치되어있는지 확인

argocd version

5. ArgoCD 서버에 CLI 로그인하기

ArgoCD는 CLI를 사용하려면 먼저 로그인해야합니다. 그 전에 포트포워딩을 먼저 해야 CLI에서 localhost로 통신할 수 있습니다.

kubectl port-forward svc/argocd-server -n argocd 8080:443

# 로컬의 8080 포트를 ArgoCD 서버의 443 포트에 연결

6. 포트포워딩 후, 로그인하기

argocd login localhost:8080 --username admin --password <초기 비밀번호>

# 여기서 초기 비밀번호는 아랫 명령어로 찾을 수 있음
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

7. ArgoCD에 Git 연동 설정

argocd repo add https://github.com/Reciping/reciping-k8s-resources \
  --username <YOUR_USERNAME> \
  --password <YOUR_PASSWORD>

# 여기서 <YOUR_USERNAME>는 깃허브 닉네임 (예 : beginninggrace)
# <YOUR_PASSWORD>는 token(classic)에서 토큰 발급 후 나온 시리얼값

결과화면

이제 본격적으로 배포하기 위해, Application 리소스 정의하려고 합니다. ArgoCD에 Helm Chart를 기반으로 Application을 생성해야 실제 배포가 이뤄지기 때문입니다.

[ 필요한 정보 ]

-name: gateway-app (원하는 이름으로 설정)
-repo: GitHub 저장소 URL -path: Helm Chart 디렉토리 경로 (예: helm/gateway)
-dest-server: Kubernetes API 주소 (보통 https://kubernetes.default.svc)
-dest-namespace: 네임스페이스 (예: reciping) -values: values-prod.yaml을 사용하고 있다면 해당 경로 지정
⇒ 이 옵션을 주면 기본 values.yaml을 기반으로 하되, values-prod.yaml의 값으로 덮어씌워서 배포한다는 뜻
⇒ 우리는 아직 없으니 빼두기

다시 5번 과정(로컬의 8080 포트를 ArgoCD 서버의 443 포트에 연결)후, 그 다음 스텝입니다.

Argo CD 로그인

argocd login localhost:8080 --username admin --password ZSWm4a4eI7hDl17I --insecure

# --insecure는 포트포워딩을 통해 HTTPS 인증서를 무시하므로 꼭 붙이기

2. appliaction 생성

argocd app create gateway-app \
  --repo https://github.com/Reciping/reciping-k8s-resources \
  --path gateway \
  --dest-server https://kubernetes.default.svc \
  --dest-namespace reciping \
  --sync-policy automated

결과화면2

⇒ 이제 Argo CD가 reciping-gateway-service를 Helm Chart 기반으로 자동 동기화하게 됩니다.

argocd app get gateway-app

# 자동 동기화 상태 확인
# 이 명령어로 앱이 제대로 떠있는지 확인 가능
# 자동으로 Synced 상태로 바뀌었는지 확인하고, Healthy 상태여야 성공적으로 배포된 것

결과화면3

※ 추후에, 이미지 버전 업(v1.0.0 → v1.0.1)이 됐을 시, 배포하는 방법

새로 빌드 및 ECR에 푸시
Helm upgrade 다시 수행:

helm upgrade reciping-gateway ./charts/reciping-gateway-service -n reciping

# 최초로 배포할 때에는 helm inatall~로 하나 업데이트될 때는 이처럼 수행합니다

결과화면

8-2 . 가장 처음 CD 시작할 시, argoCD UI가 아닌 YAML로 정의해서 kubectl apply로 배포하기

폴더 구조는 아래와 같습니다.

reciping-k8s-resources/
└── app/
    └── gateway-app.yaml

yaml파일을 생성해서 넣어줍니다.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: gateway-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/Reciping/reciping-k8s-resources
    targetRevision: HEAD
    path: charts/reciping-gateway-service
    helm:
      valueFiles:
        - values.yaml
  destination:
    server: https://kubernetes.default.svc
    namespace: reciping
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

커밋 및 푸쉬 완료 후, 아래의 명령어를 치면 앱 배포가 완료됩니다.

kubectl apply -f app/gateway-app.yaml

이 파일이 클러스터에 적용되면 Argo CD는 이 Application을 인식하고 지정된 Helm Chart (charts/reciping-gateway-service)를 기준으로 자동 배포합니다.

❇️ 최종 버전 : argoCD UI 보기 위한 argocd용 A 레코드 만들고 helm chart로 쉽게 배포하기

1. A 레코드 만들기(https://argocd.reciping.kr) - 테라폼

https://github.com/Reciping/reciping-terraform/commit/0934a711109930b709b1d87e6155a00a28960938

:recycle: refactor : add A record from route53-acm modules · Reciping/reciping-terraform@0934a71

@@ -36,3 +37,29 @@ resource "aws_acm_certificate_validation" "cert" {

github.com

https://github.com/Reciping/reciping-terraform/commit/06360454fedd396c42f23d567cd8aa439a25af4e

:recycle: refactor : add argoCD A record from route53-acm modules(wat… · Reciping/reciping-terraform@0636045

…ch argoCD UI)

github.com

[ 2번 하기 전 체크 리스트 ]

ALB Deployment 상태가 (2/2 replicas, 모두 READY) 이런 식으로 되어있는지 확인
ALB pod 상태가 모두 1/1 Running 상태인지 확인
설치 경로가 kube-system 네임스페이스인지 확인

최종결과화면

# 초기 관리자 비밀번호 확인
  kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo

비밀번호 업데이트하기 : Username : admin / Password : kelly123 입니다.

+) gateway-service 배포시, 아래와 같이 명령어 입력하기만 하면 됩니다.

( reciping-k8s-resource 레포지토리에 푸쉬된 상태, 즉 gitOps 기반으로 동작되기 때문에 해당 레포지토리 참조)

kubectl apply -f app/gateway-app.yaml

그러면 이와 같이 UI로 배포되는 과정을 눈으로 확인할 수 있습니다.

9. ACM / Route53 모듈 만들기

가비아에서 산 DNS인 reciping.kr을 연결해보겠습니다. 기존에 AWS 콘솔로 설정했던 방법은 아래를 참고하시면 됩니다. → 왜 설정하고 이게 뭔지 다 정리되어 있습니다.

️ECS(EC2, Fargate)로 백엔드 애플리케이션 배포하기 + 기본 EC2배포까지 - 3. HTTPS 연결을 위한 ACM 인증서 발급하기
️ECS(EC2, Fargate)로 백엔드 애플리케이션 배포하기 + 기본 EC2배포까지 - 5. Route 53에서 A 레코드 생성 (api.reciping.kr → ALB)
프론트단의 Route53 + S3 + CloudFront 설정하기 - 1. 가비아에서 산 DNS를 Route53에 연결하기

1. ACM-Route53 모듈 추가

https://github.com/Reciping/reciping-terraform/commit/fa830122c9f7d764777ce95517731a210bd8934a

:sparkles: feat : set acm-route53 modules · Reciping/reciping-terraform@fa83012

@@ -67,3 +67,22 @@ module "fluent_bit" {

github.com

2. gateway-service helm chart로 세부 설정해서 배포하기

gateway-service와 route53(DNS)간의 주요 포인트

https://github.com/Reciping/reciping-k8s-resources/commit/599a8238c30daa21ffa6d3ed1e68e8779f65e237

:sparkles: feat : update helm chart(reciping-gateway-service) · Reciping/reciping-k8s-resources@599a823

+ {"Type": "redirect", "RedirectConfig": { "Host": "reciping.kr", "StatusCode": "HTTP_301"}}

github.com

배포 과정은 7. 각 서버를 Pod에 띄우기 & ArgoCD 세팅(CD) 참고하시면 됩니다.

배포 후, 결과 화면

10. DB(DocumentDB, RDS), S3 모듈 만들기

1) documentDB 모듈 추가

https://github.com/Reciping/reciping-terraform/tree/dev/modules/documentdb

reciping-terraform/modules/documentdb at dev · Reciping/reciping-terraform

AI기반 통합 레시피 추천 및 검색 플랫폼 '레시핑' - 테라폼. Contribute to Reciping/reciping-terraform development by creating an account on GitHub.

github.com

2) rds 모듈 추가

https://github.com/Reciping/reciping-terraform/tree/dev/modules/rds

reciping-terraform/modules/rds at dev · Reciping/reciping-terraform

AI기반 통합 레시피 추천 및 검색 플랫폼 '레시핑' - 테라폼. Contribute to Reciping/reciping-terraform development by creating an account on GitHub.

github.com

3) s3 모듈 추가

https://github.com/Reciping/reciping-terraform/tree/dev/modules/s3

reciping-terraform/modules/s3 at dev · Reciping/reciping-terraform

AI기반 통합 레시피 추천 및 검색 플랫폼 '레시핑' - 테라폼. Contribute to Reciping/reciping-terraform development by creating an account on GitHub.

github.com

terraform apply 완료 후, db 설정들은 각 secret에 맞춰 업로드하면 됩니다.

[reciping 3차]Terraform으로 EKS 기반 인프라 구축하기 (1)

S_N_Y — Wed, 5 Nov 2025 05:45:17 +0900

※ 기존에 기록해둔 노션 글을 옮겨적은 것으로, 노션 템플릿에 맞게 적게된 글이라 해당 링크를 통해 더 가독성있게 보실 수 있습니다.

https://www.notion.so/Terraform-EKS-2690661ce62880908eafea7c3e73742c

Terraform으로 EKS 기반 인프라 구축하기 | Notion

1. 인텔리제이에서 테라폼 만들기

pleasant-sand-55a.notion.site

1. 인텔리제이에서 테라폼 만들기

깃허브에서 레포지토리 만들 때, .gitignore: Terraform 템플릿 선택하고 로컬에 clone합니다.

일단 마켓플레이스에서 테라폼 플러그인 다운로드

테라폼 CLI 설치

brew tap hashicorp/tap
brew install hashicorp/tap/terraform
terraform -v

2. 테라폼 적용하기 위한 CLI용 키페어 발급 및 등록

본인 계정에서 cli용 키페어 발급

이후 생성된 Access Key ID / Secret Access Key를 복사해서 아래 명령어로 CLI에 등록

aws configure

AWS Access Key ID     [None]: (복사한 키)
AWS Secret Access Key [None]: (복사한 시크릿 키)
Default region name   [None]: ap-northeast-2
Default output format [None]: json

3. VPC 모듈 만들기

https://github.com/Reciping/reciping-terraform/commit/d703134e94028821c8dc8c2a63135ae9988bf23d

:sparkles: feat : add vpc modules · Reciping/reciping-terraform@d703134

+ # - VPC, 서브넷, NAT, IGW, RT 구성 정의

github.com

https://github.com/Reciping/reciping-terraform/commit/31680cfca3735ff947b2a3561de7ae5a2038d64b

:sparkles: feat : add vpc modules · Reciping/reciping-terraform@31680cf

+ value = "" # The actual value to be outputted

github.com

필수 : 테라폼 생성/배포 하는 법

앞으로 매 모듈 만들 때마다 해당 과정을 반복하여야 합니다.

위치로 가기

cd /Users/sini/Desktop/dev_sini/reciping-terraform/env/prod

2. 테라폼 초기화

terraform init

3. 코드 검사(문법) → 문법 에러 있으면 여기서 먼저 잡힙니다.

terraform validate

4. 실제 적용될 변경 미리 보기

terraform plan

5. AWS에 실제 적용

terraform apply

# 혹은 특정 테라폼 모듈(타겟) 실행하고 싶을 때(예 : EKS 클러스터)
terraform apply -target=module.eks_cluster

6. 결과 확인

terraform output

4. 베스천 모듈 만들기

pem키는 수동으로 생성(베스천용 팸키와 운영레벨 범용성 팸키 두 가지 만들기)

# 베스천 서버 권한 주고 SSH 접속
chmod 400 /Users/sini/Desktop/dev_documents/reciping-bastion-ec2-key.pem

ssh -i /Users/sini/Desktop/dev_documents/reciping-bastion-ec2-key.pem ec2-user@43.202.58.107


# [0] 베스천 서버 기본 패키지 전체 업데이트 (시간 조금 걸릴 수 있음)
sudo yum update -y

# [1] EKS용 도구 설치를 위한 기본 패키지 설치
sudo yum install -y unzip curl wget git

# [2] kubectl 설치 (EKS용 Kubernetes CLI)
curl -o kubectl https://s3.us-west-2.amazonaws.com/amazon-eks/1.29.0/2024-05-09/bin/linux/amd64/kubectl
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin
kubectl version --client  # 버전 확인

# [3] eksctl 설치 (EKS 클러스터 관리용)
curl --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
sudo mv /tmp/eksctl /usr/local/bin
eksctl version  # 버전 확인

# [4] Helm 설치 (쿠버네티스 패키지 매니저)
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
helm version  # 버전 확인

# 
# -----------------------------------------------------------------------------
# [5] aws configure 실행
aws configure

# [6] EKS 구축 후, EKS 클러스터 kubeconfig 연동(Bastion 서버에서 EKS 클러스터에 연결할 수 있도록 kubeconfig 설정)
aws eks update-kubeconfig \
  --region ap-northeast-2 \
  --name reciping-cluster
  
# [7] 연결 테스트
kubectl get nodes

https://github.com/Reciping/reciping-terraform/commit/9e35bd26ffe74ea4e7275a2e2410feb894f30755

:sparkles: feat : add bastion modules · Reciping/reciping-terraform@9e35bd2

@@ -32,3 +32,31 @@ variable "private_db_subnet_cidrs" {

github.com

5. EKS 클러스터 및 node Group 모듈 생성하기

사전 작업

5-1) EKS 클러스터용 IAM Role 만들기

5-2) 노드그룹용 IAM Role 만들기

이미지와 같은 role 선택 후, 생성 클릭하고 생성된 화면

https://github.com/Reciping/reciping-terraform/commit/2924742b1830b84bcb9dd84368d964b874fd7a03

:sparkles: feat : add eks cluster modules · Reciping/reciping-terraform@2924742

+ value = aws_eks_cluster.this.certificate_authority[0].data

github.com

https://github.com/Reciping/reciping-terraform/commit/fba6c723cfb2349159b1d051d330eedc2c8103b3

:sparkles: feat : add eks node group modules · Reciping/reciping-terraform@fba6c72

@@ -14,3 +14,21 @@ resource "aws_eks_cluster" "this" {

github.com

6. ALB Ingress Controller 설치

ALB Ingress Controller는 AWS ALB를 Kubernetes Ingress로 사용할 수 있도록 하는 컨트롤러 ⇒ kubectl에서 Ingress만 정의하면 ALB가 자동 생성되도록 도와줌

0. 사전작업

modules/eks/main.tf 초기 구축할 때는 endpoint_public_access = true 로 두고 다음 과정 수행해야 합니다. (나중에 운영환경일 때, false 로 바꿔줘야 합니다.) terraform apply하기

# kubeconfig 설정
aws eks --region ap-northeast-2 update-kubeconfig --name reciping-cluster
# 노드 연결 확인하기
kubectl get nodes

1. OIDC Provider 연결

EKS 클러스터는 IRSA (IAM Roles for Service Accounts)방식으로 AWS 리소스 접근을 안전하게 제어할 수 있는 준비

# 사전 작업(로컬 터미널에서 실행)

# eksctl 설치
curl --silent --location "https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp

sudo mv /tmp/eksctl /usr/local/bin
eksctl version # 설치 후, 동작 확인

# OIDC Provider 연결
eksctl utils associate-iam-oidc-provider \
  --region ap-northeast-2 \
  --cluster reciping-cluster \
  --approve

2. ALB Ingress Controller용 IAM 정책 생성

컨트롤러가 ALB, Target Group, Listener등을 자동으로 만들 수 있게 IAM 정책을 하나 만들어줄 것임

# 1. IAM 정책 JSON 파일 다운로드
curl -o iam-policy-alb.json \
  https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/main/docs/install/iam_policy.json

# 2. IAM 정책 생성
aws iam create-policy \
  --policy-name ALBIngressControllerIAMPolicy \
  --policy-document file://iam-policy-alb.json

3. IRSA 기반 ServiceAccount생성 (IAM 연결)

컨트롤러가 EKS 내에서 IAM 역할을 사용하기 위해, ‘aws-load-balancer-controller’라는 이름의ServiceAccount를 만들어줄 것임

# kube-system 네임스페이스에
# aws-load-balancer-controller 이름의 서비스 어카운트를 만들고
# 위에서 만든 IAM 정책을 연결해주는 작업

eksctl create iamserviceaccount \
  --cluster reciping-cluster \
  --region ap-northeast-2 \
  --namespace kube-system \
  --name aws-load-balancer-controller \
  --attach-policy-arn arn:aws:iam::082808744580:policy/ALBIngressControllerIAMPolicy \
  --approve

4. ALB Ingress Controller 설치

# 사전작업(로컬 터미널에서 실행)

# Helm 설치(brew 설치 안 되어있으면 안되니 brew 먼저 설치하기)
brew install helm
# 설치 후 버전 확인
helm version

# ----------
# CRD YAML 수동 다운로드(깃헙에서 내 로컬로 파일 다운로드)
# 이 yaml 안에 TargetGroupBinding과 IngressClassParams, 즉 2가지 CRD가 함께 정의되어 있음
curl -o targetgroupbinding.yaml https://raw.githubusercontent.com/aws/eks-charts/master/stable/aws-load-balancer-controller/crds/crds.yaml
# kubectl 로 적용(EKS에 연결된 상태에서 실행됨)
kubectl apply -f targetgroupbinding.yaml

여기서 Helm이란? : 로컬에서 클러스터로 패키지를 배포하는 도구

# helm으로 ALB Ingress Controller 설치
helm upgrade -i aws-load-balancer-controller eks/aws-load-balancer-controller \
  -n kube-system \
  --set clusterName=reciping-cluster \
  --set serviceAccount.create=false \ # Helm chart가 새로운 ServiceAccount를 생성하지 않도록 설정, IRSA 연결된 SA를 직접 만들었기 때문에 false로 설정
  --set serviceAccount.name=aws-load-balancer-controller # 이미 만들어진 IRSA 연결된 ServiceAccount를 사용하겠다는 뜻
  --set region=ap-northeast-2 \
  --set vpcId=vpc-0f9af5c58379e17f9 \
  --set image.repository=602401143452.dkr.ecr.ap-northeast-2.amazonaws.com/amazon/aws-load-balancer-controller

# 설치 확인
kubectl get deployment -n kube-system aws-load-balancer-controller

결과화면

4-1) Helm chart로 쿠버네티스 리소스 관리하기EKS 클러스터에 ALB Ingress Controller가 잘 동작하는지 “확인"하기 위한 테스트용 Deployment로 NGINX를 간단히 띄우겠습니다.

이거 외에도 이 레포에서 ArgoCD를 관리 및 사용해서 GitOps 방식으로 위 디렉토리 구조를 기준으로 쿠버네티스에 지속 배포하거나 Helm chart로 하나의 서비스 리소스를 Chart로 관리하고 버전 별 배포하기 위한 아래와 같은 커스텀 쿠버네티스 리소스 레포지토리를 팝니다.

https://github.com/Reciping/reciping-k8s-resources

GitHub - Reciping/reciping-k8s-resources: AI기반 통합 레시피 추천 및 검색 플랫폼 '레시핑' - Helm chart, ArgoCD

AI기반 통합 레시피 추천 및 검색 플랫폼 '레시핑' - Helm chart, ArgoCD, Manifest, Monitoring, kubectl - Reciping/reciping-k8s-resources

github.com

※ 테라폼과 리소스YAML 레포의 다른 점

항목	Terraform 레포	Kubernetes 리소스 레포
책임	AWS 인프라 생성 (EKS, VPC, IAM 등)	앱 배포와 쿠버 설정
배포 도구	Terraform	kubectl, Helm, ArgoCD, Kustomize
주기	비교적 느림 (인프라 변경 시만)	비교적 자주 (앱 배포, 설정 변경 등)
권한	AWS 관리자 IAM 권한	EKS kubeconfig 접근 권한

초기 레포지토리 구조(현재는 바뀜)

reciping-k8s-resources/
├── base/                         # 모든 서비스가 공통으로 사용하는 리소스
│   ├── ingress-class.yaml        # ALB IngressClass 정의
│   └── cluster-issuer.yaml       # Cert-Manager 인증서용 (향후 HTTPS 대비)
├── test/
│   └── nginx-test.yaml           # ALB 테스트용 NGINX + Ingress
├── user-service/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── ingress.yaml
├── recipe-service/
│   └── ...
└── README.md

아무튼 다시 돌아가서 EKS 클러스터에 ALB Ingress Controller가 잘 동작하는지 “확인"하기 위한 테스트용 Deployment로 NGINX를 간단히 띄우겠습니다.

https://github.com/Reciping/reciping-k8s-resources/commit/88869d85d233dd3ad52f32f5a5f544e0e57699b1

:sparkles: feat : EKS 클러스터에 ALB Ingress Controller가 잘 동작하는지 확인하기 위한 서… · Reciping/recip

…비스 테스트용 NGINX Ingress 적용

github.com

작성 후, 순차적으로 진행

cd ~/Desktop/dev_sini/reciping-k8s-resources
kubectl apply -f test/nginx-test.yaml       # NGINX 서비스 및 디플로이먼트(Service + Deployment) 생성 -> pod 배포
kubectl apply -f base/ingress-class.yaml    # ALB Ingress 리소스 생성 -> 경로를 연결

# ALB 생성 확인
kubectl get ingress

여기서 Deployment, Service, Ingress의 개념에 대해 정리해보겠습니다. Ingress는 마치 “외부 트래픽이 들어왔을 때 어느 내부 Service로 연결시킬지 정의하는 설정”하는 것.

그래서 먼저 Deployment + Service → 그 다음 Ingress 입니다.

+) 브라우저 접속해보기

# 위에 ADDRESS 나온걸로 접속하면 NGINX 환영 화면이 뜹니다.
http://k8s-default-nginxing-31cfb49cd0-64845225.ap-northeast-2.elb.amazonaws.com/

결과화면

[reciping 2차] minikube로 로컬 쿠버네티스 테스트하기

S_N_Y — Wed, 5 Nov 2025 05:44:47 +0900

※ 기존에 기록해둔 노션 글을 옮겨적은 것으로, 노션 템플릿에 맞게 적게된 글이라 해당 링크를 통해 더 가독성있게 보실 수 있습니다.

https://www.notion.so/minikube-2690661ce62880e3a2ffdbb5d2d95a94

minikube로 로컬 쿠버네티스 테스트하기 | Notion

1. minikube 실행하기

pleasant-sand-55a.notion.site

1. minikube 실행하기

사전에 minikube 명령어 실행할 수 있도록 설치 필요

minikube start --memory=6g --cpus=4 --driver=docker

※ 제대로 생성됐는지 확인 절차

# 노드 확인
PS C:\Users\home> kubectl get nodes
NAME       STATUS   ROLES           AGE   VERSION
minikube   Ready    control-plane   53m   v1.33.1
# minikube 상태 확인
PS C:\Users\home> minikube status
minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured
# 파드 확인
PS C:\Users\home> kubectl get pods -A
NAMESPACE              NAME                                         READY   STATUS    RESTARTS      AGE
kube-system            coredns-674b8bbfcf-k8tzc                     1/1     Running   0             56m
kube-system            etcd-minikube                                1/1     Running   0             56m
kube-system            kube-apiserver-minikube                      1/1     Running   0             56m
kube-system            kube-controller-manager-minikube             1/1     Running   0             56m
kube-system            kube-proxy-hn5x6                             1/1     Running   0             56m
kube-system            kube-scheduler-minikube                      1/1     Running   0             56m
kube-system            storage-provisioner                          1/1     Running   1 (56m ago)   56m
kubernetes-dashboard   dashboard-metrics-scraper-5d59dccf9b-b99cx   1/1     Running   0             2m43s
kubernetes-dashboard   kubernetes-dashboard-7779f9b69b-x88s4        1/1     Running   0             2m43s
PS C:\Users\home>
# Dashboard 확인
PS C:\Users\home> minikube dashboard
   대시보드를 활성화하는 중 ...
    ▪ 이미지 docker.io/kubernetesui/dashboard:v2.7.0 사용 중
    ▪ 이미지 docker.io/kubernetesui/metrics-scraper:v1.0.8 사용 중
   Some dashboard features require the metrics-server addon. To enable all features please run:

        minikube addons enable metrics-server

   Dashboard 의 상태를 확인 중입니다 ...
   프록시를 시작하는 중 ...
   Proxy 의 상태를 확인 중입니다 ...
   Opening http://127.0.0.1:53167/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/ in your default browser...

대시보드 활성화하였을 때, 이렇게 나타납니다.

2. 로컬 DB 세팅하기

사전에 Helm repo에 bitnami를 추가해줍니다.

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

네임스페이스에 local-db 만들어둡니다.

kubectl create namespace local-db

Helm으로 MongoDB 배포(설치)해줍니다. (세팅값까지 넣기)

helm upgrade --install mongodb bitnami/mongodb \
  --namespace local-db \
  --set auth.rootPassword=admin123 \
  --set auth.username=reciping \
  --set auth.password=reciping123 \
  --set auth.database=reciping_db

이 설정은 아래 Mongo URI로 사용 가능합니다

mongodb://reciping:reciping123@mongodb.local-db.svc.cluster.local:27017/reciping_db

Helm으로 postgreSQL 배포(설치)해줍니다. (세팅값까지 넣기)

helm upgrade --install postgres bitnami/postgresql \
  --namespace local-db \
  --set auth.username=reciping \
  --set auth.password=admin123 \
  --set auth.postgresPassword=admin123 \
  --set auth.database=reciping_db

이 설정은 아래 JDBC URL로 사용 가능합니다

jdbc:postgresql://postgres.local-db.svc.cluster.local:5432/reciping_db

※ 띄운 후, 최종 DB 상태 확인

일반적으로 -hl이 붙은 서비스 (headless)는 내부 클러스터 DNS용이고, 클라이언트에서 직접 접속할 때는 postgres-postgresql

home@DESKTOP-0L33BAC MINGW64 ~/Desktop/groom/dev_sini/reciping-k8s-resources (feature-prod)
$ kubectl get all -n local-db
NAME                           READY   STATUS    RESTARTS   AGE
pod/mongodb-7d8b94b5fb-7cw6s   1/1     Running   0          50m
pod/postgres-postgresql-0      1/1     Running   0          104s

NAME                             TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)     AGE
service/mongodb                  ClusterIP   10.107.135.183   <none>        27017/TCP   50m
service/postgres-postgresql      ClusterIP   10.100.205.158   <none>        5432/TCP    104s
service/postgres-postgresql-hl   ClusterIP   None             <none>        5432/TCP    104s

NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/mongodb   1/1     1            1           50m

NAME                                 DESIRED   CURRENT   READY   AGE
replicaset.apps/mongodb-7d8b94b5fb   1         1         1       50m

NAME                                   READY   AGE
statefulset.apps/postgres-postgresql   1/1     104s

※ (선택사항) 간편하게 Port Forward로 직접 접속 확인

MongoDB:

kubectl port-forward svc/mongodb 27017:27017 -n local-d

PostgreSQL:

# 클라이언트에서 직접 접속할 때는 postgres-postgresql 서비스에 포트포워딩
kubectl port-forward svc/postgres-postgresql 5432:5432 -n local-db

이후 로컬 터미널에서 접속:

MongoDB:

mongosh mongodb://reciping:reciping123@localhost:27017/reciping_db

PostgreSQL:

psql -h localhost -U reciping -d reciping_db
# Password: reciping123

3. ECR Image pull → tag 변경 → Minikube에 Image upload

기존에 CI 워크플로우로 ECR에 이미지 업로드하였는데, 편하게 이 이미지를 토대로 minikube에 pull해서 쓰겠습니다.

ECR에 로그인합니다.

aws ecr get-login-password --region ap-northeast-2 \
  | docker login --username AWS --password-stdin 892117097999.dkr.ecr.ap-northeast-2.amazonaws.com

이미지를 pull합니다.

docker pull 892117097999.dkr.ecr.ap-northeast-2.amazonaws.com/reciping-user-service:v1.0.8

로컬 테스트용 태그로 재태깅합니다.

docker tag 892117097999.dkr.ecr.ap-northeast-2.amazonaws.com/reciping-user-service:v1.0.8 user-service:local

minikube에 이미지를 올립니다.

minikube image load user-service:local

4. Minikube에 rollouts 사용을 위한 Argo Rollouts CRD 설치

공식적인 설치 명령어입니다. 이 명령어는 다음 리소스를 설치합니다.

CRDs (Rollout, AnalysisTemplate 등)
Controller (argo-rollouts-controller)
RBAC, ServiceAccount 등

kubectl create namespace argo-rollouts

kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

※ 명령어 실행 및 설치 확인까지

home@DESKTOP-0L33BAC MINGW64 ~/Desktop/groom/dev_sini/reciping-k8s-resources (feature-prod)
$ kubectl create namespace argo-rollouts
namespace/argo-rollouts created

home@DESKTOP-0L33BAC MINGW64 ~/Desktop/groom/dev_sini/reciping-k8s-resources (feature-prod)
$ kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml
customresourcedefinition.apiextensions.k8s.io/analysisruns.argoproj.io created
customresourcedefinition.apiextensions.k8s.io/analysistemplates.argoproj.io created
customresourcedefinition.apiextensions.k8s.io/clusteranalysistemplates.argoproj.io created
customresourcedefinition.apiextensions.k8s.io/experiments.argoproj.io created
customresourcedefinition.apiextensions.k8s.io/rollouts.argoproj.io created
serviceaccount/argo-rollouts created
clusterrole.rbac.authorization.k8s.io/argo-rollouts created
clusterrole.rbac.authorization.k8s.io/argo-rollouts-aggregate-to-admin created
clusterrole.rbac.authorization.k8s.io/argo-rollouts-aggregate-to-edit created
clusterrole.rbac.authorization.k8s.io/argo-rollouts-aggregate-to-view created
clusterrolebinding.rbac.authorization.k8s.io/argo-rollouts created
configmap/argo-rollouts-config created
secret/argo-rollouts-notification-secret created
service/argo-rollouts-metrics created
deployment.apps/argo-rollouts created

# 설치 확인
home@DESKTOP-0L33BAC MINGW64 ~/Desktop/groom/dev_sini/reciping-k8s-resources (feature-prod)
$ kubectl get crd | grep rollouts
rollouts.argoproj.io                   2025-08-06T11:34:22Z

5. Helm chart 수동배포로 일단 서버가 제대로 뜨는지 확인해보기

Helm 배포 명령어를 실행합니다.

helm upgrade --install user-service ./charts/reciping-user-service \
  --namespace reciping \
  --create-namespace

후에 자잘한 오류 디버깅하면 됩니다!

[reciping] 프론트단의 Route53 + S3 + CloudFront 설정하기

S_N_Y — Wed, 5 Nov 2025 05:43:50 +0900

※ 기존에 기록해둔 노션 글을 옮겨적은 것으로, 노션 템플릿에 맞게 적게된 글이라 보기 불편하실 수 있습니다.

프론트 배포하면서 딸려오는 서비스들을 배포해보겠습니다.

1. 가비아에서 산 DNS를 Route53에 연결하기

로그인 후, My가비아 → 이용중인 서비스 → 도메인 클릭 후, 이 화면 띄워놓기

호스팅 영역 생성 클릭

산 DNS 넣고 화면과 같이 설정 후, 호스팅 영역 생성

호스팅 영역 생성 완료

NS Record 부분의 값을 가비아에 다시 돌아가서 가비아 네임 서버에 입력해주어야 합니다. (아래 이미지 참조)

NS (Name Server) 레코드 : 해당 도메인의 DNS 요청을 처리하는 네입서버 주소를 지정하는 역할
⇒ 즉, 특정 도메인(reciping.kr)에 대한 트래픽을 어떤 네임서버가 처리할 것인지 결정하는 것
SOA (Start of Authority) 레코드 : 특정 DNS 존(zone)의 시작 지점이며, 해당 존을 관리하는 정보와 존의 버전 관리 정보를 제공
⇒ 각 존에 단 하나만 존재

네임서버 설정 클릭 (현재는 가비아의 네임서버가 디폴트로 관리되고 있음)

순서대로 1,2,3,4차 입력 후, 적용 클릭

2. Route 53에서 www.reciping.kr → CloudFront로 연결하는 방법

1. 호스팅 영역 > "reciping.kr" > 레코드 생성

레코드 이름: www
레코드 유형: A - IPv4 address + AWS 리소스로 트래픽 라우팅
별칭(Alias): ✅ 켜기

2. 트래픽 라우팅 대상 → 엔드포인트 선택: CloudFront 배포

드롭다운에서 너가 생성한 CloudFront 배포 선택
리전 선택은 자동으로 설정됨 (CloudFront는 글로벌 서비스라 리전 설정 없음)

3. 라우팅 정책: 단순 라우팅

Route53의 라우팅 정책 선정 기준 정리

정책 설명 사용 사례

정책	설명	사용 사례
✅ Simple	가장 기본, 1개 대상 IP/DNS만 설정	단일 ALB, 단일 서비스
Weighted	여러 대상에 트래픽 분산 (비율 설정)	A/B 테스트, Blue-Green 배포
Latency-based	리전별 응답속도 기준 분기	다중 리전 운영 시
Failover	Active-Standby 구성	장애 복구용
Geolocation	국가/지역별 라우팅	지역 맞춤 서비스
Multivalue answer	여러 IP 중 무작위 응답	간단한 부하분산 (잘 안 씀)

[ 언제 다른 라우팅 정책을 쓸 수 있을까? ]

정책	향후 활용 가능 시나리오
Weighted	실험적으로 신기능을 일부 사용자에게 제공할 때 (A/B 테스트)
Latency-based	다중 리전 서비스로 확장할 경우 (예: 글로벌 유저 확보)
Failover	장애 대비용 백업 게이트웨이 또는 ALB 구성 시

3. 프론트 이미지 빌드 후, ECR에 푸쉬하기

프론트엔드 프로젝트 루트폴더에 아래의 dockerfile과 nginx.conf 추가해두기

# 1단계: Vite로 빌드
FROM node:20-alpine AS builder
WORKDIR /app
COPY . .
RUN npm install && npm run build

# 2단계: Nginx로 정적 파일 서빙
FROM nginx:1.25-alpine
COPY --from=builder /app/dist /usr/share/nginx/html
COPY nginx.conf /etc/nginx/nginx.conf
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

worker_processes 1;

events {
  worker_connections 1024;
}

http {
  include       mime.types;
  default_type  application/octet-stream;
  sendfile        on;

  server {
    listen       80;
    server_name  localhost;

    root   /usr/share/nginx/html;
    index  index.html;

    location / {
      try_files $uri /index.html;
    }
  }
}

# 이 단계 먼저 오기 전에 node.js 설치 안 되어있으면 설치 후 작업하기
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
# 설치 확인
node -v
npm -v

# 1. 프론트 디렉토리로 이동
cd ~/Desktop/dev_sini/reciping-fe

# 2. 빌드 (최초 1회)
npm install
npm run build

# 3. Docker 이미지 빌드
docker build --no-cache --platform linux/amd64 -t reciping-FE:v1.0.0 .

# 4. ECR 태그 설정 (리포지토리명이 reciping-FE인 경우)
docker tag reciping-FE:v1.0.0 \
892117097999.dkr.ecr.ap-northeast-2.amazonaws.com/reciping-FE:v1.0.0

# 5. 이미지 푸시
docker push 892117097999.dkr.ecr.ap-northeast-2.amazonaws.com/reciping-FE:v1.0.0

[reciping] ECS(EC2, Fargate)로 백엔드 애플리케이션 배포하기 + 기본 EC2배포까지 (2)

S_N_Y — Wed, 5 Nov 2025 05:43:33 +0900

※ 기존에 기록해둔 노션 글을 옮겨적은 것으로, 노션 템플릿에 맞게 적게된 글이라 해당 링크를 통해 더 가독성있게 보실 수 있습니다.

https://www.notion.so/ECS-EC2-Fargate-EC2-2690661ce6288002b649e41cce173d12

ECS(EC2, Fargate)로 백엔드 애플리케이션 배포하기 + 기본 EC2배포까지 | Notion

1. 각각에 넣을 보안그룹 생성하기( ALB, Gateway Server, ECS )

pleasant-sand-55a.notion.site

4. ALB 생성하기

4-1) alb 생성하기

로드 밸런서 생성 클릭

ALB 생성 클릭

1번 가용영역과 2번 가용영역을 번갈아가면서 배정해야 하므로 퍼블릭 서브넷을 아래와 같이 매핑합니다.

만들어둔 alb 보안그룹 설정하고, 80과 443을 설정하되, 80으로 들어갔을 때 443으로 바로 리디렉션하는 설정을 alb 만들고 할 것이니 일단 이렇게 만들어두세요.

[ 정책 이름 ] :

최신 TLS 1.2/1.3 지원하는 ELBSecurityPolicy-TLS13-1-2-Res-2021-06 추천 (보안성 가장 좋음)

⇒ 현업에서도 많이 쓰이는 모던 보안 정책입니다.

[ 클라이언트 인증서 처리 → 상호 인증(m TLS) ] :

일반적인 웹사이트나 API 통신에서는 클라이언트 인증서는 필요 X
Mutual TLS는 금융권/내부망에서만 특수하게 사용합니다.

alb 생성 완료

4-2) 80으로 들어갔을 때 443으로 바로 리디렉션하는 설정하기

80 체크 후, 규칙 편집 클릭

기본값 체크 후, 규칙 편집 클릭

해당 화면과 같이 리디렉션으로 변경

사용자 지정 호스트, 경로, 쿼리를 사용하십시오… 체크 (= 리디렉션 대상 URL을 좀 더 정밀하게 제어할 수 있도록 도와주는 옵션)

작업(다음 수행) - 리디렉션 대상 이 HTTPS://#{host}:443/#{path}?#{query} 로 변경된 것을 볼 수 있음

5. Route 53에서 A 레코드 생성 (api.reciping.kr → ALB)

reciping.kr 클릭

레코드 생성 클릭

백엔드는 https://api.reciping.kr~ 로 갑니다. DNS→IP이니 A레코드로 설정하고, 별칭(alias) 켜주시고, 아까 만들어둔 alb도 넣어줍니다. 다 끝나면 레코드 생성 클릭

A 레코드 생성 완료

+) 게이트웨이 서버를 기본 EC2에 배포하기

⇒ 그 다음 절차는 gateway server를 EC2에 띄우는 것인데 그 과정은 다른 페이지에 따로 담았습니다.

기본 EC2 배포하기(Gateway Server)

기본 EC2 배포하기(Gateway Server) | Notion

1. EC2 키페어 만들기

pleasant-sand-55a.notion.site

6. ECS 클러스터 생성하기

클러스터 생성 클릭

기본 네임스페이스는 새 네임스페이스 생성 클릭해서 아래와 같이 만든 후, 그것으로 설정

+) 네임스페이스 설정하기

✅ [ 기본 네임스페이스 ] :

선택사항이긴 하지만, 클러스터 내부에서 서비스들을 논리적으로 그룹화하고 싶을 때 사용합니다.

향후 Prometheus, CloudWatch, Service Connect 등을 고려하면 reciping-ns 같은 네임스페이스를 만들어 두는 것도 나쁘지 않기에 만들어두겠습니다.

+) 네임스페이스의 다른 좋은 점 정리

기능	네임스페이스 사용 시 효과
서비스 격리	reciping-user-service 와 reciping-recommend-service 를 분리해서 관리 가능
Cloud Map 연동	서비스 디스커버리 이름이 recommend.reciping.local 이런 식으로 구조화 가능
Observability 향상	CloudWatch, X-Ray, Prometheus 연동 시 태깅 기준으로 분석 용이
Multi-tenant 운영 대비	나중에 하나의 클러스터에 여러 팀/서비스를 운영할 때 구조적으로 구분 가능

해당과 같이 적은 후, 네임스페이스 생성 클릭

[ 네임스페이스 이름 ] :

[프로젝트명].local 도메인은 VPC 내부 전용 용도로 AWS가 자동 인식해서 설정해줍니다.

⇒ 내부 DNS에서 user.reciping.local, event.reciping.local처럼 사용

[ 인스턴스 검색 ] :

옵션	설명	권장 여부
API 호출	서비스 디스커버리 이름으로 ECS에서 호출할 때 Cloud Map을 API 통해 조회함	기본 + 요금 없음
VPC에서 API 호출 및 DNS 쿼리	DNS 기반 + API 호출을 모두 지원함 (비용 발생)	외부 서비스가 DNS로 호출해야 할 때만 사용
퍼블릭 DNS 쿼리 포함	퍼블릭 DNS로도 외부에서 접근 가능 (비용 발생)	지금 상황에서는 불필요

[ Auto Scaling 그룹(ASG) ]

: 클러스터에 EC2 Capacity Provider로 사용할 Auto Scaling Group을 설정

⬇️ 여기서 EC2 Capacity Provider란?

EC2 인스턴스를 ECS에서 자동으로 사용할 수 있게 해주는 중개자 매개체
즉, Auto Scaling Group(ASG) 기반의 EC2 인스턴스를 ECS가 자동으로 관리하게끔 연결해주는 "다리”
ECS가 태스크를 실행해야 할 때 ASG의 용량을 보고 자동으로 EC2 인스턴스를 띄움
예) 태스크 수 증가 → Capacity 부족하면 → ASG 스케일 아웃 유도

# 구성 요소 흐름도
Auto Scaling Group (EC2 인스턴스 묶음)
     ↓ 연결
EC2 Capacity Provider
     ↓ 연결
ECS 클러스터 내 서비스

결론 : 일단 새 ASG 생성으로 자동생성

→ 이후 세밀 조절을 위해 EC2 > Auto Scaling > 생성된 그룹으로 이동해서 정책을 추가해야 합니다.

→ 예) CPU 60% 이상이면 EC2 한 대 더 생성 등

→ fargate는 ECS 서비스 > Auto Scaling 설정에서 task수를 자동 증가 정책 필요

→ 예) 예: CPU 평균 60% 이상이면 Task 수를 2 → 3으로 자동 증가

[ 컨테이너 인스턴스 AMI ]

: Amazon Linux 2 그대로 두면 ECS Agent 포함된 최적화된 AMI로 자동 선택됨

[ EC2 인스턴스 역할 ]

: 기본값 ecsInstanceRole 선택 ⇒ ECS 에이전트가 동작하고 CloudWatch, ECR 등에 접근할 권한을 가짐

[ 시작 인스턴스 수 ]

: 기본값 최소가 0으로 되어있는데 그대로 두면 ‘최초 배포 안 해도 된다’ 는 표시이니 최소 1 / 최대 2로 초기 세팅

[ SSH 키 페어 ]

: EC2 인스턴스에 접속해서 디버깅하고 싶다면 꼭 필요 ⇒ reciping-prod-ec2-key 선택

[ 루트 EBS 볼륨 크기 ]

EC2 인스턴스의 기본 디스크 공간(운영체제, 로그, 컨테이너 캐시 등 저장)
ECS에서 컨테이너를 EC2에서 실행할 경우, 도커 이미지/로그도 이 루트 볼륨에 저장됨

⇒ 대부분의 AMI에서 기본값은 30 GiB인데, 지금 MSA 서비스 여러 개 구성 예정이니 넉넉하게 50GiB로 세팅

[ 퍼블릭 IP 자동 할당 ]

: 프라이빗 서브넷에서 동작할 것이므로 끄기 선택

태그 입력 후, 생성 클릭

7. ECR 생성하기

리포지토리 생성 클릭

각 서비스별로 ecr을 만들 것임(reciping-user-service, reciping-recipe-service..) 입력 후, 생성 클릭

[ 이미지 태그 변경 가능성 ]

옵션	설명	구분 기준
Mutable (기본값)	같은 태그로 이미지를 덮어쓰기 가능 (예: latest)	개발/테스트 환경에서 많이 씀
Immutable	같은 태그로는 한 번만 푸시 가능 (덮어쓰기 불가)	실운영 배포 환경에서 선호 (보안 및 추적성 확보)

[ 암호화 설정 ]

옵션	설명	구분 기준
AES-256 (기본값)	AWS가 자동으로 암호화 관리	대부분 이걸 씀
AWS KMS	직접 생성한 KMS 키로 암호화	보안이 매우 민감한 조직에서 사용 (예: 금융, 의료)

[ 이미지 스캔 설정 ] - 푸쉬된 이미지 취약점 검사해주는 옵션

⇒ 저희는 현재 리포지토리 단위에서 구성되므로, 신경 쓰지 말고 그냥 꺼두면 됩니다.

각 서비스별로 ECR 생성 완료

8. Dockerfile 작성하기

멀티 스테이지 빌드를 이용하겠습니다. & 경량 베이스 이미지도 사용

# 1단계 : Build Stage
# 빠른 빌드에 최적화된 이미지인 openjdk:17-jdk-slim 사용, Builder 단계에서만 사용
FROM openjdk:17-jdk-slim AS builder

WORKDIR /app

# gradle 설정 복사
COPY gradlew build.gradle settings.gradle ./
COPY gradle ./gradle

# 소스 복사
COPY src ./src

# 실행 권한 부여 + 빌드
# bootJar만 빌드하여 build 전체 안 쓰고 필요한 아티팩트만 생성해서 빠르게 함
# --no-daemon 사용하여 도커 환경에서 데몬 프로세스 오류 방지
RUN chmod +x ./gradlew && ./gradlew bootJar --no-daemon

# 2단계: Runtime Stage (이 또한 경량 이미지)
# 런타임은 경량 + AWS 친화적 (ECS, EC2 AMI와 일관성 유지)
FROM amazoncorretto:17-alpine
WORKDIR /app

# 빌드된 JAR 복사
COPY --from=builder /app/build/libs/*.jar app.jar

# 도커 컨테이너 내부에서 사용하는 헬스체크용 포트 노출
EXPOSE 8080

# Spring Boot 실행
ENTRYPOINT ["java", "-jar", "app.jar"]

+) MacOS에 AWS CLI 설치

curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"
sudo installer -pkg AWSCLIV2.pkg -target /

# 설치 끝나면 아래로 확인
# 예시 출력: aws-cli/2.x.x 이런 식이면 성공
aws --version

# ECR에 로그인하기 위해 인증 정보 입력해야 함
aws configure

# 그 뒤에는 아랫 내용 입력하면 됩니다.

+) IAM에서 내 계정(내 사용자) 엑세스 키 만들기

IAM → 사용자 → 본인 계정 → 액세스키 생성 클릭 후, 이 화면이 나오는데 CLI 선택후 다음 클릭

이 페이지 벗어나면 더이상 볼 수 없으니, 저거 복사해서 메모장에 붙여넣기 하거나 .csv파일로 보관해둬야 합니다!

항목	설명	입력값
AWS Access Key ID	IAM 사용자로 받은 키	AKIA...
AWS Secret Access Key	IAM 사용자 시크릿	xxyyzz...
Default region name	서울 리전	ap-northeast-2
Default output format	그대로 엔터 쳐도 됨	json 혹은 그냥 엔터

docker desktop 실행 중인 상태로 아랫 명령어 쭉 진행합니다.

# 일단 user-service 기준으로 문서 남겨둡니다.
# 892117097999.dkr.ecr.ap-northeast-2.amazonaws.com => ecr에서 유저 서비스 url 그대로 가져오면 됩니다.
aws ecr get-login-password --region ap-northeast-2 | \
docker login --username AWS --password-stdin 892117097999.dkr.ecr.ap-northeast-2.amazonaws.com

저희는 이미지 버전을 mutable하게 가져가지 않고(lastest ❌) Immutable하게 v1.0.0 형식으로 버전관리할 예정입니다.

<주의할 점> : 과정 중에 이후의 하나의 과정이라도 실패하면 그냥 해당 ECR 삭제하고 다시 만드는 것 추천

docker build -t reciping-user-service:v1.0.0 .

# 빌드한 도커 이미지'reciping-user-service:v1.0.0'를 태깅 후, ECR에 푸쉬
docker tag reciping-user-service:v1.0.0 \
892117097999.dkr.ecr.ap-northeast-2.amazonaws.com/reciping-user-service:v1.0.0

docker push 892117097999.dkr.ecr.ap-northeast-2.amazonaws.com/reciping-user-service:v1.0.0

성공한 모습

+) 나머지 서비스들도 다 똑같은 과정으로 진행하세요.

# 1. 디렉토리 이동 (예: reciping-recipe-service-BE)
cd ~/Desktop/dev_sini/reciping-recipe-service-BE

# 2. jar 빌드
./gradlew clean bootJar --no-daemon

# 3. 도커 이미지 빌드 (캐시 없이)
docker build --no-cache --platform linux/amd64 -t reciping-recipe-service:v1.0.0 .

# 4. 태깅
docker tag reciping-recipe-service:v1.0.0 \
892117097999.dkr.ecr.ap-northeast-2.amazonaws.com/reciping-recipe-service:v1.0.0

# 5. 푸시
docker push 892117097999.dkr.ecr.ap-northeast-2.amazonaws.com/reciping-recipe-service:v1.0.0

8. 태스크 정의 생성하기

8-1) fargate 태스크 정의 예시 (reciping-user-service)

새 태스크 정의 생성 클릭

[ 운영 체제/아키텍처 ]

: Linux/X86_64 대부분 기본 설정.(ARM 기반 컨테이너가 맞을 때는 다른거 사용)

[ 태스크 크기 ]

: fargate는 EC2와 달리 조합을 미리 정해둡니다.

현업에서는 웹 서비스: 0.5 vCPU + 1GB ~ 1 vCPU + 3GB, 검색, 머신러닝 등 고성능: 2~4 vCPU + 8GB~

[ 태스크 역할 ]

: 컨테이너 내 애플리케이션이 AWS 리소스에 접근할 수 있도록 부여된 IAM Role

현업에서는 ecsTaskExecutionRole 또는 서비스 전용 Role 따로 생성해서 사용한다고 합니다.

[ 프라이빗 레지스트리 ]

: 프라이빗 레지스트리 인증을 켜면, Docker 이미지의 사용자명/비밀번호가 필요할 수 있습니다.

ECR이 아닌 타사 프라이빗 레지스트리(ex. DockerHub Pro, GitHub Container Registry 등)일 경우는 Secrets Manager를 통해 자격 증명을 받아야 하는데 ECR 사용하고 있으니 켜놓긴 하되, Secrets Manager 설정은 빈칸으로 두세요.

[ 포트 매핑 ]

: ECS에서 유저 서비스는 포트 8080로 스프링부트가 구동되고 있습니다.

[ 읽기 전용 루트 파일 시스템 ]

: 컨테이너 내의 루트 파일 시스템을 읽기 전용으로 설정할지 선택 ⇒ 스프링 부트 앱이면 읽기 전용은 체크 X

[ 리소스 할당 제한 ]

목적	CPU	Memory
소규모 API 서비스 (트래픽 적음)	0.5 vCPU	1~2 GiB
일반 SpringBoot 서비스 (유저 로그인/조회 등)	1 vCPU	2~3 GiB
대용량 또는 병렬 처리 서비스	2 vCPU	4 GiB 이상

[ 환경 변수 ]

배포 자동화 환경(Jenkins)에서 환경 변수를 주입할 거면 ECS 환경변수 설정은 생략해도 됩니다.

8-2) EC2 태스크 정의 예시 (reciping-search-service)

[ 네트워크 모드 ]

: awsvpc : ECS Task가 ENI(IP)를 직접 받아서 통신함 → 보안 그룹, IAM 관리도 쉬움

[ 작업 배치 ]

추가 X

[ 결함 주입 ]

: AWS Fault Injection Simulator (FIS)와 연동하여 장애 유도 테스트 수행 옵션이며, 보통 장애 대응 훈련, 복원력 테스트 시 QA 환경에서 사용 가능하며 현재 프로덕션 환경에선 사용 안 하므로 체크 X

9. 서비스 생성하기

9-1) fargate일 경우(예 : user-service)

서비스 생성 클릭

[ 태스크 정의 개정 ]

: 최신 개정 선택(예: :1, :2 등) → 수동 선택 가능, 일반적으로 최신 개정 선택 (기본값 유지 OK)

[ 서비스 이름 ]

: 자동으로 reciping-user-task-service-<랜덤>처럼 생성될텐데 이건 직접 reciping-user-service로 수정해야 팀 기준으로 서비스명 일관성이 유지가 되니 꼭 바꾸기

[ 컴퓨팅 구성(고급) ]

: 어떤 인스턴스에 태스크를 띄울지 ECS가 알아서 선택하는 방식 → 용량 공급자 전략 선택

( 시작 유형은 예전 방식이며, 간단하지만 오토 스케일링과 스팟 연동 등 제한)

[ 용량 공급자 전략 ]

fargate의 경우, 사용자 지정 사용(고급) 선택 ( EC2의 경우, 클러스터 기본값 사용 선택)

[ 용량 공급자 ]

메인 컨테이너를 정규 fargate에서 실행한다는 의미로 FARGATE 선택
가중치는 1 기본값 유지 (FARGATE_SPOT을 추가하려면 전략적으로 FARGATE: 1, FARGATE_SPOT: 1 같이 구성해서 비용 최적화도 가능)
⇒ 하지만 user-service처럼 항상 켜져야 하는 서비스는 FARGATE 단독이 안정적

[ 플랫폼 버전 ]

: LATEST 선택 (보안 정책상 고정 버전 사용하는 금융/대겹은 1.4.0 사용하기도 한다고 합니다.)

[ 서비스 유형 ]

: 원하는 태스크 수만큼 ECS가 유지하는 구조 (MSA 대부분이 여기에 해당) → 복제본 선택

[ 원하는 태스크 ]

: 초기에는 1개로 시작, 필요 시 오토 스케일링 설정하면 되는데 저희는 나중에 설정할 것입니다.

(실무에서는 초기 서비스에서는 1~2개 선택하고 트래픽 증가에 따라 조정한다고 합니다.)

[ 가용 영역 리밸런싱 ]

: Fargate가 AZ 불균형 발생 시 자동으로 리밸런싱 해줌 (현업에서 반드시 켜놓음)

[ 상태 검사 유예 기간 ]

: 스프링 부트 서버의 경우, 기동이 20~30초 걸린다 생각하면 30으로 설정해두기

[ 배포 유형 ]

롤링 업데이트 : 한 번에 일부 태스크를 교체하며 무중단 배포 → 규모 작을 때 적합합니다. 이거 선택
블루/그린 : 테스트 후 승인 방식 배포 → 서버가 많이 떠있으면 가능(지금은 필요X / 나중에 고려)

[ 최소 실행 작업 비율 ]

: 업데이트 도중 기존 태스크는 100% 유지, 새 태스크 배포 후 교체

[ 최대 실행 작업 비율 ]

: 최대 몇 개까지 동시 실행 가능한지 (기존 + 신규) → 기본값 200% 적용(오토 스케일링 대응 포함됨)

[ 배포 실패 감지 ]

옵션	설명
Amazon ECS 배포 회로 차단기 사용	배포 중 태스크가 unhealthy 상태에 도달하면 즉시 배포 중단	항상 ON(기본 보호 메커니즘)
실패 시 롤백	새 배포가 실패하면 이전 정상 상태로 자동 롤백	ON (중단 없는 운영을 위해)
CloudWatch 경보 사용	CloudWatch Alarm이 발생하면 배포 중단	알람 연동된 모니터링 세팅이 있는 경우만 사용 (없으면 꺼두는 게 맞습니다)

fargate가 프라이빗 서브넷에서 실행되고, ALB가 라우팅을 담당하니까 퍼블릭 IP도 꺼짐 선택

여기서 태그만 사용하겠습니다.(서비스 자동 크기 조정(오토 스케일링)같은 경우, 나중에 따로 설정할 것) alb → ecs 구조면 로드 밸런싱 옵션 사용해야 함

[reciping] ECS(EC2, Fargate)로 백엔드 애플리케이션 배포하기 + 기본 EC2배포까지 (1)

S_N_Y — Wed, 5 Nov 2025 05:43:09 +0900

※ 기존에 기록해둔 노션 글을 옮겨적은 것으로, 노션 템플릿에 맞게 적게된 글이라 해당 링크를 통해 더 가독성있게 보실 수 있습니다.

https://www.notion.so/ECS-EC2-Fargate-EC2-2690661ce6288002b649e41cce173d12

ECS(EC2, Fargate)로 백엔드 애플리케이션 배포하기 + 기본 EC2배포까지 | Notion

1. 각각에 넣을 보안그룹 생성하기( ALB, Gateway Server, ECS )

pleasant-sand-55a.notion.site

ECS - ECR 세팅과정을 담았습니다. CICD 적용 전이라 나중에 조금씩 세팅이 바뀔 수 있습니다.

1. 각각에 넣을 보안그룹 생성하기( ALB, Gateway Server, ECS )

ELB에는 NLB와 ALB 등이 있는데 ALB를 선택한 이유는 한 번 따로 찾아봐주시길 바랍니다! 외부 클라이언트 → ALB 요청을 조건에 따라 허용하는 보안그룹을 설정하겠습니다.

전체적인 흐름은 다음과 같습니다.

[클라이언트]
   ↓ 443
[ALB] ───── SG A ───────▶ 포트 8090
   ↓
[게이트웨이 EC2] ───── SG B ─────▶ 포트 8080–8093
   ↓
[ECS 서비스들] ───── SG C

1-1) ALB 보안그룹 생성

원래는 위와 같이 인바운드만 HTTP, HTTPS, 0.0.0.0/0으로 열어주고 보안 그룹 생성 클릭하나, 우리는 특별한 상황(게이트웨이 서버가 존재)이니 아웃바운드 규칙을 게이트웨이 서버 보안그룹과 연결해줍니다. → 일단 수정할건데 이렇게 두기( 인바운드도 나중에 프론트 배포 후, cloudfront IP만 허용하는 걸로 바꿀 거임 )

ALB용 보안 그룹 생성 완료

1-2) Gateway server 보안그룹 생성

Gateway server용 보안그룹은 ALB → Gateway server의 통신을 허용하는 역할이라서 ALB 보안 그룹에서 오는 트래픽만 허용하겠습니다.

일단 인바운드는 alb에서 들어오니까 이렇게 설정해놓고 아웃바운드는 ecs 보안그룹 만든 후에 다시 세팅할 것입니다.

+) 추가로 gateway에 bastion서버를 통해 jar파일 배포하고 싶으면 인바운드로 아래와 같이 추가 필요!

왜 80이 아니라 80XX(ex : 8090)를 쓰는 이유

: 운영 환경에서의 역할 구분과 포트 충돌 방지를 위해서 씁니다.

포트 번호 용도 설명

80번	공식 HTTP 표준 포트	브라우저가 기본으로 연결함 (http://example.com)
443번	공식 HTTPS 표준 포트	TLS 기반 HTTPS
80XX번	개발용/비표준 HTTP 포트	앱 내부 통신, 리버스 프록시 뒤의 서버 등

⇒ 80포트는 ALB에서 이미 점유하고 있어서 게이트웨이나 내부 서버에서는 내부 포트를 따로 둬야 함

⇒ 서비스 간 내부 라우팅은 명시적으로 포트 분리를 선호합니다.

예) 게이트웨이 → user-service: 8081, 게이트웨이 → recipe-service: 8082..

→ 이렇게 포트를 나눠야 서비스별 라우팅이 명확합니다.

[ 우리 서버 포트 참고 자료 ] 레시핑 서비스별 포트번호 정리

1-3) ECS 보안그룹 생성

ECS용 보안그룹은 Gateway Server → ECS Task의 통신을 허용하는 역할이라서 Gateway Server 보안 그룹에서 오는 트래픽만 허용하겠습니다.

인바운드는 우리 띄워진 서버들 열어줍니다. 보안 그룹 생성 클릭

ECS용 보안 그룹 생성 완료

1-4) alb, gateway 보안 그룹 다시 수정하기

alb 보안그룹 선택 후, 아웃바운드 규칙 편집 클릭

원래 있던 아웃바운드 규칙 삭제 클릭 후, 규칙 추가 클릭, 해당과 같이 입력 후 규칙 저장 클릭

alb 보안그룹 수정 완료

마찬가지로 ecs 보안그룹도 원래 있던 아웃바운드 규칙 삭제 클릭 후, 규칙 추가 클릭, 해당과 같이 입력 후 규칙 저장 클릭

gateway 보안그룹 수정 완료

결과 :

보안그룹	인바운드	아웃바운드
ALB (A)	80/443 from 0.0.0.0/0(cloudfront 적용하면 수정할 것임)	To Security Group B
Gateway (B)	8080 from SG A / SSH from SG bastion	To SG C
ECS (C)	8080 from SG B	외부 통신용 (S3 등) or 제한 가능

2. ALB에 붙일 대상그룹 생성하기

대상 그룹 생성 클릭

ALB의 트래픽을 게이트웨이 서버 인스턴스로 연결하니 반드시 인스턴스로 대상 유형을 선택합니다.

[ 프로토콜 : 포트 ] : (1) HTTPS는 ALB가 처리하고 여기선 내부 통신이므로 HTTP 선택 (내부통신은 HTTPS 불필요, ALB가 SSL 처리함) (2) 게이트웨이 서버 내부 포트인 8090 추가
[ 프로토콜 버전 ] :

버전	설명	사용 추천 상황
HTTP1	대부분의 Spring, Express, Nginx 서버는 기본적으로 HTTP/1.1	현재 환경에 가장 안정적
HTTP2	요청 다중화 지원. 하지만 서버가 지원 안 하면 연결 실패	Spring Boot, Nginx 기본은 HTTP1을 씁니다.
gRPC	gRPC 프로토콜 전용	일반 HTTP 서비스에서는 사용하지 않음

(1) 게이트웨이 서버가 HTTP로 응답하니 HTTP 로 설정 (2) ALB가 트래픽 보내는 포트(=8090)으로 검사하니 트래픽 포트 클릭

(3) 기본값으로 가져가기(실무에서는 간격을 10초로도 가져간다고는 하네요)

태그 추가후, 다음 클릭

인스턴스 선택하라고 하는데 일단 넘기고 그냥 만들어서 비정상이 뜨는 것인데요. 나중에 연결할 겁니다.

3. HTTPS 연결을 위한 ACM 인증서 발급하기

CloudFront, ALB, API Gateway 등을 사용하는 AWS 네이티브 아키텍처일 때 ACM(=SSL인증서)을 씁니다. HTTPS는 암호화된 통신이라 브라우저가 https://api.reciping.kr로 접속하면, "SSL Handshake"라는 걸 하면서 ACM을 통해 “정말 reciping.kr 도메인을 너가 소유한 거 맞는지” AWS가 검증해야 하기 때문에 씁니다. 이것은 자동으로 인증서를 갱신하고 콘솔이나 테라폼으로 관리도 가능하며, AWS 서비스들과 연동이 편하고, 인증서 프라이빗 키가 AWS 내부에서만 저장되어서 보안성이 높습니다. 그리고 퍼블릭 인증서는 공짜입니다.

3-1) 인증서 발급하기

퍼블릭 인증서 요청 (공용 인증서) 선택

(1) 전체 커버용 와일드카드 인증서 *.reciping.kr 적기 → www.reciping.kr, admin.reciping.kr 등등..다 가능 (2) 와일드 카드 적용 안 되는 reciping.kr 적기(선택) (3) 키 알고리즘은 RSA 2048 선택 → 이건 다 호환되고 가장 보편적이라 많이 사용(나머지는 미지원 가능성과 성능부담 존재)

ACM 인증서 생성 완료

3-2) Route 53에 DNS 레코드 추가하기

Route 53을 통해 도메인 소유자임을 DNS로 인증하는 과정

CNAME 이름, CNAME 값 부분 기억해두세요! → route53에 붙여넣을 것입니다.

Route53에서 만든 reciping.kr 클릭 후, 레코드 생성 클릭

레코드 이름 에 ACM( CNAME 이름 ) 붙여넣기, 값 에 ACM( CNAME 값 ) 붙여넣기 후, 레코드 생성 클릭

레코드 발급 완료

ACM으로 다시 돌아가면 상태가 발급됨 으로 바뀐 것을 알 수 있음

[reciping] 베스천 서버 세팅하기

S_N_Y — Wed, 5 Nov 2025 05:42:50 +0900

※ 기존에 기록해둔 노션 글을 옮겨적은 것으로, 노션 템플릿에 맞게 적게된 글이라 해당 링크를 통해 더 가독성있게 보실 수 있습니다.

https://www.notion.so/2690661ce628802f887de3658e79ac15

베스천 서버 세팅하기 | Notion

0. 베스천 서버란?

pleasant-sand-55a.notion.site

베스천 서버 세팅하는 과정을 담았습니다.

0. 베스천 서버란?

: 베스천 서버는 내부요소를 변경할 필요가 있거나, 접근이 필요할 때 내부(Public)와 외부(Private)를 연결해주는 서버

1. EC2 키페어 생성하기

AWS에서 모든 EC2를 생성할 때에는 키 페어를 먼저 발급해야 합니다.

키 페어 생성 클릭

키 페어 생성 완료

2. 베스천 서버를 보호해줄 보안 그룹 생성하기

: 보안규칙을 설정하지 않으면 다 접속이 가능하기 때문에 프라이빗 영역은 오직 같은 VPC 내부 요소만 접근 가능하게 만들어놓고 외부에서 퍼블릭 영역을 접근할 때, 외부에서 인증이 없어도 접근가능한 영역과 인증해야만 접근가능한 영역을 나눠서 설정해야 합니다.

보안 그룹 생성 클릭

VPC는 reciping-vpc 로 세팅

SSH접속으로만 콘솔 접속을 허용할 것이기 때문에 SSH에 대한 규칙만 정의

⇒ 일단 저희 집도 다 다르고 하니, SSH 접속 IP를 0.0.0.0/0(위치무관)으로 가져가지만 현업에서는 해당 회사 IP주소로 가져가야 합니다.

아웃바운드는 기본 설정인 모든 트래픽 그대로 설정(모든 외부로의 통신 허용 상태)

⇒ 그러나 혹시 현업에서 보안 정책이 엄격하거나, 특정 IP/도메인으로만 아웃바운드 트래픽 허용해야 할 때, NAT Gateway 없이 프라이빗 서브넷에서 아웃바운드 허용 설정이 필요한 경우 등등 특정한 상황에서는 아웃바운드 설정도 필요

보안 그룹 생성 클릭

보안 그룹 생성 완료

3. 베스천 서버를 띄울 EC2 생성하기

인스턴스 시작 클릭

프리티어 인스턴스 를 적용 & 아까 만들어둔 키 페어 등록

네트워크 설정 에서 편집 클릭 후, 해당과 같이 설정

(1) 스토리지 구성 은 어차피 베스천 서버라 터미널로만 접속할 것이기 때문에 스토리지는 크게 필요없으니 디폴트값으로 가져가기 (2) 인스턴스 시작 클릭

베스천 서버용 EC2 생성 완료

4. 베스천 서버 접속 테스트

: 주로 putty, mobax 등을 이용하는데 윈도우에서는 파워셸로 가능, 맥에서는 그냥 터미널로 가능

현재 상황 요약 :
- 퍼블릭 IP: 3.39.222.21
- Key 파일 이름: reciping-bastion-ec2-key.pem
- SSH 인바운드 규칙: 0.0.0.0/0

(1) 로컬에 .ssh 폴더 생성

mkdir -p ~/.ssh

-p는 이미 폴더가 있어도 에러 없이 무시하고 지나가게 함

(2).pem키 파일 이동

mv /Users/sini/Desktop/dev_documents/reciping-bastion-ec2-key.pem ~/.ssh/

✅ [ 맥북에서 파일 위치 확인하는 방법 ]

Finder에서 원하는 파일을 선택 후, ⌘ + Option + C 키를 누르면 해당 파일의 전체 경로가 클립보드에 복사됨

+) mv만 하면 나중에 컴퓨터 변경 시, 위험하니 백업이 필요합니다.

.pem 키 백업하는 방법(mv 명령어 이전에 실행)

# 백업할 디렉토리 만들기 (예: 데스크탑에 secure_backup 폴더)
mkdir -p ~/Desktop/secure_backup

# .ssh 디렉토리에서 베스천 키 복사
cp ~/.ssh/reciping-bastion-ec2-key.pem ~/Desktop/secure_backup/

(3) 작업 폴더 이동

cd ~/.ssh

(4) 권한 설정 (보안 경고 방지)

chmod 400 reciping-bastion-ec2-key.pem

맥이나 리눅스에서 SSH 접속할 때, 키 파일이 너무 오픈되어있어서(644권한) 보안취약점이 있다고 인식해서 접근이 안 되는 경우가 있는데 이 경우에는 파일 권한을 이런 식으로 400주면 해결됩니다.

(5) SSH 접속 시도

ssh -i reciping-bastion-ec2-key.pem ec2-user@3.39.222.21

(6)

The authenticity of host '3.39.222.21 (3.39.222.21)' can't be established.
ED25519 key fingerprint is SHA256:V1VwHN8e0Z74hDdpqm3vxZ6YbbHudtJshn7LdadpYT8.
...
Are you sure you want to continue connecting (yes/no/[fingerprint])?

이 메세지의 의미는 ED25519 fingerprint는 해당 서버의 고유한 SSH 식별자로 처음 접속할 때 항상 나오는 메세지인데 서버가 내가 만든 EC2가 맞는지 물어보는거니 yes 입력

최종 접속 성공 화면

+) 연결 해제는 ctrl + d 혹은 logout 명령어를 통해 나가기까지!

[reciping] 기본 EC2 배포하기(Gateway Server)

S_N_Y — Wed, 5 Nov 2025 05:42:25 +0900

※ 기존에 기록해둔 노션 글을 옮겨적은 것으로, 노션 템플릿에 맞게 적게된 글이라 해당 링크를 통해 더 가독성있게 보실 수 있습니다.

https://www.notion.so/EC2-Gateway-Server-2690661ce6288076a2aee25376a5a77d

기본 EC2 배포하기(Gateway Server) | Notion

1. EC2 키페어 만들기

pleasant-sand-55a.notion.site

1. EC2 키페어 만들기

reciping-vpc(애플리케이션 운영용 VPC)에 필요한 범용 prod .pem키를 발급해보도록 하겠습니다.

해당 정보 입력 후, 키 페어 생성 클릭

2. EC2 인스턴스 만들기 및 세부 설정 항목들에 관하여

‘인스턴스 시작’ 클릭

이름은 reciping-gateway-ec2-01, reciping-gateway-ec2-02로 가져가겠습니다.

[ 애플리케이션 및 OS 이미지(Amazon Machine Image) ]

Q : 여기서 AMI란?
A : AMI(Amazon Machine Image) 는 EC2 인스턴스를 실행할 때 사용하는 운영체제(OS)와 필수 소프트웨어가 미리 설치되어 있는 "템플릿 이미지" (=AMI는 “이대로 인스턴스를 부팅해라”라는 스냅샷+설정 모음집)

[ Quick Start ]

: Quick Start는 AWS에서 자주 사용하는 OS/애플리케이션 조합을 미리 골라놓은 대표적인 AMI 목록

Amazon Linux : AWS 최적화, 성능 좋고 AWS CLI 및 SSM Agent 기본 탑재
Ubuntu : 리눅스 환경, 오픈소스 친화적, 문서 많고 커뮤니티 활발
MacOS : iOS/macOS 앱 빌드(웹X), 테스트 용도(Mac 전용 인스턴스(mac1..)만 사용 가능 → 매우 고가)

✅ +) Quick Start vs Community AMI vs Marketplace

유형	설명	특징
Quick Start	AWS 공식 인기 이미지	안정성 ↑, 기본적인 구성, 초보자 추천
My AMIs	사용자가 직접 만든 이미지	재사용 목적, 커스텀 설정 가능
AWS Marketplace	서드파티 제공 이미지	상용 소프트웨어 포함 (예: Bitnami, Jenkins)
Community AMIs	누구나 올린 공개 이미지	무료 많지만 보안 위험 주의

충분히 트래픽을 감당하도록 단일 큰용량의 인스턴스 필요, VCPU 2개 / RAM 4GB로 초기 트래픽으로 설정(나중에 모니터링 후, 용량 다시 설정해야 합니다.)

[ 모든 세대 ]

: 모든 세대 옵션은 ON했을 경우 최신 세대와 예전 세대 전부를 다 보여주는데, 되도록이면 최신 세대(t3…)를 사용하는게 좋습니다. 왜냐하면 오래된 세대는 phase-out되는 경우가 있기 때문입니다.

똑같이 구성하고 인스턴스 시작 클릭 (가용영역이 2개여서 인스턴스를 reciping-private-subnet-02 로 똑같이 하나 더 만들기)

[ 퍼블릭 IP 자동 할당 ]

: 프라이빗 서브넷에서는 퍼블릭 IP가 없어야 정상이고, ALB를 통해서만 접근하게 되므로 퍼블릭 IP 필요 없음

3. 로컬 ~/.ssh에 .pem키 백업하고 백업본 따로 저장해두기

전에 베스천 서버 만들 때처럼 해주시면 됩니다.

# pem키 백업하기 (제 맥북 배경화면에 있는 dev_backup 폴더에 백업)
cp /Users/sini/Desktop/dev_documents/reciping-prod-ec2-key.pem /Users/sini/Desktop/dev_backup/

# ~/.ssh 폴더로 복사
cp /Users/sini/Desktop/dev_documents/reciping-prod-ec2-key.pem ~/.ssh/

# 퍼미션 설정 (보안 경고 방지)
chmod 400 ~/.ssh/reciping-prod-ec2-key.pem

4. 로컬에서 빌드한 JAR 파일을 Bastion 서버를 거쳐 EC2에 업로드

아마 본인 로컬 상황에 따라 여기서부터 좀 다르게 가져가실 수 있습니다.

그래서 어떤 과정인지만 알아두시고 챗지피티와 소통을..!!ㅎ

(1) application-prod.yml 설정

server:
  port: 8090

spring:
  cloud:
    gateway:
      globalcors:
        add-to-simple-url-handler-mapping: true
        corsConfigurations:
          '[/**]':
            allowedOrigins:
              - "https://www.reciping.kr" 
              - "https://reciping.kr"
            allowedMethods:
              - GET
              - POST
              - PUT
              - DELETE
              - OPTIONS
            allowedHeaders:
              - "*"
              - Authorization
              - Content-Type
            exposedHeaders:
              - Authorization
            allowCredentials: true

logging:
  level:
    com.three.recipinggatewayservicebe.jwt: DEBUG

jwt:
  secret:
    key: m5M/3YqO8kB/32Xu0/AlU8TKtsKhXHXuRAm5XGvx786uTj3+BpN1RAA65tJvbOg1pZuVG+TqMyFk2XRL3rU7HA==

server:
  port: 8090

spring:
  cloud:
    gateway:
      globalcors:
        add-to-simple-url-handler-mapping: true
        corsConfigurations:
          '[/**]':
            allowedOrigins:
              - "https://www.reciping.kr" 
              - "https://reciping.kr"
            allowedMethods:
              - GET
              - POST
              - PUT
              - DELETE
              - OPTIONS
            allowedHeaders:
              - "*"
              - Authorization
              - Content-Type
            exposedHeaders:
              - Authorization
            allowCredentials: true
      routes:
        - id: user-service
          uri: http://10.0.64.103:8080
          predicates:
            - Path=/users/**
            
logging:
  level:
    com.three.recipinggatewayservicebe.jwt: DEBUG

jwt:
  secret:
    key: m5M/3YqO8kB/32Xu0/AlU8TKtsKhXHXuRAm5XGvx786uTj3+BpN1RAA65tJvbOg1pZuVG+TqMyFk2XRL3rU7HA==

(2) [ Mac 터미널에서 해야하는 작업 (1) ]

# cd 명령어를 통해 현재 디렉토리를 해당 프로젝트 폴더로 이동
cd /Users/sini/Desktop/dev_sini/reciping-gateway-service-BE

# Gradle Wrapper (gradlew)를 실행
# 프로젝트를 새로 빌드해서 실행 가능한 .jar 파일을 생성
# /build/libs/ 디렉토리에 아래와 같은 결과물이 생깁니다.
# 예시) reciping-gateway-service-BE-0.0.1-SNAPSHOT.jar
# 기존에 var/logs..로 로컬 리눅스 폴더에 만들었기 때문에 xml쪽 빌드가 안될 것임(먼저 -x test로 테스트 없이 빌드)
./gradlew clean build -x test

3) +) 참고사항

# JAR 이름은 build.gradle에 이렇게 지정했으니
bootJar {
    archiveFileName = 'reciping-gateway.jar'
}
# 따라서 jar 파일 경로는 다음과 같을 것임
/Users/sini/Desktop/dev_sini/reciping-gateway-service-BE/build/libs/reciping-gateway.jar

(4)

[ Mac 터미널에서 해야하는 작업 ]

# scp로 jar 파일을 우선 Bastion 서버로 업로드(macOS 기준) / 베스천 서버의 퍼블릭 IP : 3.39.222.21
scp -i ~/.ssh/reciping-bastion-ec2-key.pem \
  /Users/sini/Desktop/dev_sini/reciping-gateway-service-BE/build/libs/reciping-gateway.jar \
  ec2-user@3.39.222.21:~

[ Bastion 서버에서 해야하는 작업 ]

# Bastion 서버에 ssh 접속
ssh -i ~/.ssh/reciping-bastion-ec2-key.pem ec2-user@3.39.222.21
# 베스천의 ssh폴더에 pem키 옮기기
mv ~/reciping-prod-ec2-key.pem ~/.ssh/reciping-prod-ec2-key.pem
# AWS EC2 접속용 키에 필요한 권한 설정(권한 400 주기)
chmod 400 ~/.ssh/reciping-prod-ec2-key.pem

[ Mac 터미널에서 해야하는 작업 ] - Jar 전송하기

# Gateway 1로 JAR 복사
scp -o "ProxyCommand=ssh -i ~/.ssh/reciping-bastion-ec2-key.pem -W %h:%p ec2-user@3.39.222.21" -i ~/.ssh/reciping-prod-ec2-key.pem /Users/sini/Desktop/dev_sini/reciping-gateway-service-BE/build/libs/reciping-gateway.jar ec2-user@10.0.72.75:~


# Gateway 2로 JAR 복사
scp -o "ProxyCommand=ssh -i ~/.ssh/reciping-bastion-ec2-key.pem -W %h:%p ec2-user@3.39.222.21" -i ~/.ssh/reciping-prod-ec2-key.pem /Users/sini/Desktop/dev_sini/reciping-gateway-service-BE/build/libs/reciping-gateway.jar ec2-user@10.0.83.252:~

참고 이미지 - 자르 파일 전송되는 모습

Amazon Linux (특히 Amazon Linux 2나 2023)는 기본적으로 java가 설치되어 있지 않아서 애플리케이션 서버에서 직접 수동 설치해야합니다.

sudo yum install -y java-17-amazon-corretto

혹은 아래 링크로 다운 후, 폴더를 download 파일에 넣어두기

https://corretto.aws/downloads/latest/amazon-corretto-17-x64-linux-jdk.rpm

설치중인 모습

(5)

[ gateway 서버에서 해야하는 작업 ] - Bastion ProxyJump 방식으로 Gateway 서버에 접속 후, rpm으로 설치

az-2도 똑같이 반복해주시면 됩니다.

# 게이트웨이 ec2 인스턴스에 접속 (예 : az-1)
ssh \
-o "ProxyCommand=ssh -i ~/.ssh/reciping-bastion-ec2-key.pem -W %h:%p ec2-user@3.39.222.21" \
-i ~/.ssh/reciping-prod-ec2-key.pem \
ec2-user@10.0.72.75

# rpm으로 ec2에 자바17 설치
sudo rpm -ivh ./java-17-amazon-corretto-devel-17.0.15.6-1.x86_64.rpm

# 설치 확인
java -version

# java -version 입력 시, 결과 화면
openjdk version "17.0.15" 2025-04-15 LTS
OpenJDK Runtime Environment Corretto-17.0.15.6.1 (build 17.0.15+6-LTS)
OpenJDK 64-Bit Server VM Corretto-17.0.15.6.1 (build 17.0.15+6-LTS, mixed mode, sharing)

(5)

[ Mac 터미널에서 해야하는 작업 ] - Bastion ProxyJump 방식으로 Gateway 서버에 접속

# scp로 ec2 인스턴스로 전송 (az-1)
scp \
-o "ProxyCommand=ssh -i ~/.ssh/reciping-bastion-ec2-key.pem -W %h:%p ec2-user@3.39.222.21" \
-i ~/.ssh/reciping-prod-ec2-key.pem \
./amazon-corretto-17-x64-linux-jdk.rpm \
ec2-user@10.0.72.75:~

# 게이트웨이 ec2 인스턴스에 접속 (az-1)
ssh \
-o "ProxyCommand=ssh -i ~/.ssh/reciping-bastion-ec2-key.pem -W %h:%p ec2-user@3.39.222.21" \
-i ~/.ssh/reciping-prod-ec2-key.pem \
ec2-user@10.0.72.75

# 다시 게이트웨이 서버에 로그 디렉토리 생성 및 권한 부여
sudo mkdir -p /var/log/reciping/gateway-service
sudo chown -R $(whoami) /var/log/reciping/gateway

# 게이트웨이 서버 실행
nohup java -jar ~/reciping-gateway.jar > /var/log/reciping/gateway/gateway-nohup.log 2>&1 &


# 정상실행 확인
ps -ef | grep reciping-gateway

# scp로 ec2 인스턴스로 전송 (az-2)
scp \
-o "ProxyCommand=ssh -i ~/.ssh/reciping-bastion-ec2-key.pem -W %h:%p ec2-user@3.39.222.21" \
-i ~/.ssh/reciping-prod-ec2-key.pem \
./amazon-corretto-17-x64-linux-jdk.rpm \
ec2-user@10.0.83.252:~

# 게이트웨이 ec2 인스턴스에 접속 (az-2)
ssh \
-o "ProxyCommand=ssh -i ~/.ssh/reciping-bastion-ec2-key.pem -W %h:%p ec2-user@3.39.222.21" \
-i ~/.ssh/reciping-prod-ec2-key.pem \
ec2-user@10.0.83.252

# 다시 게이트웨이 서버에 로그 디렉토리 생성 및 권한 부여
sudo mkdir -p /var/log/reciping/gateway-service
sudo chown -R $(whoami) /var/log/reciping/gateway

# 게이트웨이 서버 실행
nohup java -jar ~/reciping-gateway.jar > /var/log/reciping/gateway/gateway-nohup.log 2>&1 &

# 정상실행 확인
ps -ef | grep reciping-gateway

# +) 참고사항!
# JAR 실행 기본 명령어는 아래와 같습니다. (각 인스턴스 접속 후)
java -jar ~/reciping-gateway.jar

# => 이렇게 하면 포그라운드에서 실행돼서 터미널이 JAR 실행 화면에 고정됨. 나중에 꺼지면 앱도 종료됨.
# 그래서 이 방법 말고, 기존에 커스텀 로그 설정한 것도 있으니, 백그라운드 실행 + 로그 저장 방식으로 실행하기
nohup java -jar ~/reciping-gateway.jar > /var/log/reciping/gateway-service/gateway-nohup.log 2>&1 &

결과