2026-06-10

Today

• 오늘은 휴가여서 교육장 출근은 하지 않았다 하지만 오전 10시에 멘토링이 있어 집에서 참여하였다. 멘토링을 하면서 궁금한점에 대해 작성한다.

Learned

DMS 프로시저 전환

• DMS는 데이터(row)만 마이그레이션 — Stored Procedure, Trigger, Function, View 등 DB 오브젝트 로직은 옮기지 않음
• "프로시저 전환" = 소스 DB의 저장 프로시저를 타겟 DB에 맞게 수동 재작성·이식하는 작업
• 동종 DB: mysqldump --routines로 추출 후 import
• 이종 DB: AWS SCT(Schema Conversion Tool)로 자동 변환 시도 → 실패분 수동 재작성
• 탈프로시저 전략: 프로시저 로직을 애플리케이션 레이어(Spring Service 등)로 이관하는 리팩토링도 선택지

Failover

• 정의: Primary 장애 시 Standby로 자동 전환하는 메커니즘
• RDS Multi-AZ: Primary 장애 → DNS 엔드포인트가 Standby를 가리킴 (60~120초)
• ECS + ALB: 헬스체크 실패 → 태스크 제거 → 새 태스크 기동, Multi-AZ면 다른 AZ가 처리
• Route 53: Health check 기반 DNS Failover (리전 단위)
• 구분: Failover(전환 동작) vs HA(설계 목표, 다운타임 최소화) vs DR(리전 단위 재해 복구)

AWS FIS (Fault Injection Service)

• 정의: 의도적으로 장애를 주입해서 시스템 복원력(Resilience)을 테스트하는 카오스 엔지니어링 서비스
• 할 수 있는 것: EC2/ECS 인스턴스 종료, 네트워크 지연/차단, RDS failover 강제, AZ 장애 시뮬레이션, EKS Pod 삭제
• 구성 요소: Experiment Template(시나리오) + Action(장애 종류) + Target(대상) + Stop Condition(안전장치)
• 용도: Multi-AZ failover 검증, 모니터링 알람 동작 확인, 오토스케일링 테스트, 앱 푸시알림 발송 경로 복원력 검증
• 푸시알림 테스트: FCM/APNs 자체는 못 건드리지만, 발송 경로(ECS 워커, 네트워크, SQS)에 장애 주입하여 재시도·DLQ·유실방지 검증 가능

AIOps (Artificial Intelligence for IT Operations)

• 정의: AI/ML을 활용해 IT 운영을 자동화·지능화하는 것
• 핵심 기능:
  • 이상 탐지 (Anomaly Detection): 정상 패턴 학습 → 벗어나면 알림
  • 이벤트 상관분석 (Correlation): 수백 개 알람을 하나의 근본 원인으로 묶음
  • 근본 원인 분석 (RCA): 장애 원인 자동 추론
  • 예측 (Predictive): 장애 발생 전 예측
  • 자동 복구 (Auto-remediation): 감지 → 판단 → 조치 자동화
• 기존 운영과 차이: 임계값 기반 알람 → ML 기반 이상 패턴 탐지, 수동 로그 분석 → 자동 상관분석·RCA
• AWS 서비스: CloudWatch Anomaly Detection, DevOps Guru, EventBridge + Lambda, Bedrock(LLM 기반 로그 해석)
• Farmily 적용: CloudWatch → Bedrock/Anomaly Detection → EventBridge → Lambda 자동 대응 → Slack 통보

관찰성 도구 — Grafana / Prometheus / AMP / AMG

• Grafana·Prometheus는 오픈소스 (AWS 제품 아님). AWS는 그걸 "돌리는 장소"일 뿐
• 셀프호스팅(ECS에 직접 컨테이너 설치) vs 관리형(AMG/AMP = AWS가 설치·패치·운영 대행)
• Prometheus = 긁어와 저장(pull/scrape, stateful 시계열 DB) / Grafana = 시각화(저장 안 함, 데이터소스 뷰)
• AMP = Amazon Managed Prometheus(관리형 저장소) / AMG = Managed Grafana(화면은 오픈소스 Grafana와 동일, 로그인만 SSO)
• Grafana는 CloudWatch + Prometheus를 동시 데이터소스로 연결 가능

CloudWatch vs 앱 계측(Instrumentation)

• CloudWatch = 인프라 겉(CPU·메모리·ALB 5xx), AWS가 자동 제공
• 앱 계측 = 앱 속(API별 처리시간·DB풀·JVM) — Spring Micrometer → /actuator/prometheus 노출
• FIS failover 관찰은 CloudWatch면 충분 / 앱 계측은 앱팀 코드 수정 필요 → 나중

Prometheus와 쿠버네티스

• Prometheus는 K8s 전용 아님 — 2012 SoundCloud제, K8s(2014)보다 먼저 나온 범용 도구
• 같은 CNCF 가족 + K8s 동적환경(Pod 자동발견) 궁합 + kube-prometheus-stack 표준 → "K8s 도구"처럼 보일 뿐
• ECS는 궁합이 번거로움(사이드카·ECS SD) → 관리형으로 우회 / EKS는 셀프호스팅이 표준

IaC 드리프트 vs 언매니지드 (콘솔 작업 안전 기준)

• 드리프트 = Terraform이 아는 리소스가 코드와 어긋남 (plan에 뜸)
• 언매니지드 = Terraform이 모르는 새 리소스 (plan에 안 뜸, 드리프트 아님)
• 기존 리소스 참조=안전 / 수정=드리프트 (예: prod-alb에 콘솔로 listener 추가 = 위험)
• 전부 새 리소스로 만들고 기존 건 참조만 하면 드리프트 0 가능 → 나중에 terraform import로 코드화

FIS 심화 (우리 환경 적용)

• FIS 모니터링 3층: Steady State(정상기준) / Stop Condition(피해 임계 시 자동 중단) / 복원 관찰
• ⚠️ RDS failover 액션 차이: Aurora=aws:rds:failover-db-cluster, RDS 인스턴스=aws:rds:reboot-db-instances(forceFailover) — 우리는 postgres 인스턴스라 후자
• prod만 failover 검증 가능(multi_az=true·num_cache=2), dev는 단일 AZ라 불가
• 관찰성 EKS 재사용: 대시보드(JSON)·앱계측·AMP·PromQL은 넘어감 / 수집기(ECS 사이드카→kube-prometheus-stack)만 교체 → "ECS 관리형 → EKS 셀프호스팅" 모더나이제이션

7R / AWS Transform (멘토 자료)

• Farmily 7R = Replatform 주력(VM→ECS 컨테이너, 자체DB→RDS) + 일부 Refactor(Lambda 크롤러). Rehost 건너뛰고 바로 컨테이너화
• AWS Transform = 7R/현대화를 AI 에이전트로 자동화하는 통합 서비스(MGN·DMS·App2Container를 오케스트레이션)