2026-07-02

Today

• PPT 대본 작성 및 아키텍처 한글화

Learned

1. ESO (External Secrets Operator)

• K8s 클러스터 안에서 외부 시크릿 저장소(AWS Secrets Manager, SSM 등)의 값을 자동으로 K8s Secret으로 동기화해주는 오퍼레이터
• 왜 필요: 민감값(DB 비밀번호, API 키)을 Git에 안 넣고도 pod가 쓸 수 있게
• 흐름: ExternalSecret CR 생성 → ESO가 Secrets Manager에서 값 가져옴 → K8s Secret 자동 생성 → pod에 env/volume으로 주입
• 우리 프로젝트: farmily-app-secrets ExternalSecret → farmily/prod/app Secrets Manager 참조

2. ServiceAccount (K8s)

• pod에 신원(identity)을 부여하는 K8s 리소스
• 왜 필요:
  • IRSA (IAM Roles for Service Accounts): ServiceAccount에 AWS IAM Role을 매핑 → pod가 AWS 리소스(S3, Secrets Manager 등)에 접근할 때 credential 하드코딩 없이 자동 인증
  • 권한 분리: pod마다 다른 ServiceAccount → 다른 AWS 권한 (최소권한 원칙)
• 우리 프로젝트: farmily-app ServiceAccount → eks-app-iam-role (IRSA) → Secrets Manager 읽기 권한
• ECS의 task-role과 같은 역할이지만 K8s 세계의 방식

3. IRSA (IAM Roles for Service Accounts)

• K8s ServiceAccount에 AWS IAM Role을 직접 연결하는 EKS 기능
• 왜 필요: pod가 AWS 리소스(Secrets Manager, S3, ECR 등) 접근할 때 AccessKey 하드코딩 대신 임시 토큰 자동 발급
• 동작 원리:
  1. EKS OIDC Provider가 ServiceAccount의 토큰을 발급
  2. AWS STS가 이 토큰을 검증 → IAM Role의 임시 credential 반환
  3. pod 안 AWS SDK가 자동으로 이 credential 사용
• ECS 대비: ECS는 task-role(task에 IAM Role 붙임). IRSA는 같은 개념의 K8s 버전.
• 우리 프로젝트: farmily-app SA → eks-app-iam-role / farmily-app-ai SA → eks-ai-iam-role
• 핵심: 하나의 노드에 여러 pod가 있어도 각각 다른 권한 가능 (노드 IAM Role은 공유되지만 IRSA는 pod 단위 분리)

4. STS (Security Token Service)

• AWS의 임시 보안 자격증명 발급 서비스
• 왜 필요: 영구 AccessKey 대신 수명 짧은 임시 토큰(기본 1시간)을 발급 → 유출돼도 자동 만료
• 어디서 쓰이나:
  • IRSA: pod의 ServiceAccount 토큰 → STS AssumeRoleWithWebIdentity → 임시 credential 반환 → pod가 AWS 접근
  • GHA OIDC: GitHub 토큰 → STS AssumeRoleWithWebIdentity → 임시 credential → ECR push, crane copy 등
  • Jenkins: AssumeRole → Terraform plan/apply용 임시 credential
• 핵심: 우리 CI/CD 전체가 영구 키 0개 — 모든 AWS 접근이 STS 임시 토큰 기반 (OIDC + IRSA)

5. Trust Policy의 Identity Provider (누가 이 Role을 쓸 수 있나)

• IAM Role에는 Trust Policy(신뢰 정책)가 붙어있음 = "누구한테 이 Role 쓰게 허락할 건지"
• 허락 대상(Principal)이 뭐냐에 따라 역할 종류가 갈림:

Principal (신뢰 대상)	역할 종류	예시
OIDC URL (외부 IdP)	IRSA / GHA OIDC 역할	oidc.eks.amazonaws.com/... → pod가 쓰는 Role
		token.actions.githubusercontent.com → GHA가 쓰는 Role
AWS Service	서비스 역할	ec2.amazonaws.com → EC2 인스턴스가 쓰는 Role
		lambda.amazonaws.com → Lambda 함수가 쓰는 Role
		ecs-tasks.amazonaws.com → ECS task가 쓰는 Role

• 핵심: 같은 IAM Role이라도 Trust Policy에 적힌 게 뭐냐에 따라 "누가 AssumeRole 할 수 있는지"가 결정됨
• 우리 프로젝트:
  • eks-app-iam-role → Trust: EKS OIDC URL → pod(IRSA)가 씀
  • farmily-cicd-backend-role → Trust: GitHub OIDC URL → GHA가 씀
  • ECS task-role → Trust: ecs-tasks.amazonaws.com → ECS task가 씀

6. Exploit Pattern (익스플로잇 패턴)

• 시스템의 취약점을 악용하는 구체적 공격 기법/시나리오
• 예시:
  • SQL Injection: 입력값에 SQL 삽입 → DB 탈취
  • SSRF: 서버가 내부 네트워크 요청하도록 속임 → 메타데이터(IAM credential 등) 탈취
  • Container Escape: 컨테이너 밖(호스트)으로 탈출 → 노드 장악
  • Privilege Escalation: 낮은 권한 → 높은 권한으로 상승
• 우리 프로젝트 관련: IRSA(pod 단위 권한), runAsNonRoot(conftest 정책), OIDC(임시 토큰) 등이 전부 exploit 차단을 위한 설계

7. OWASP (Open Web Application Security Project)

• 웹 애플리케이션 보안 취약점을 정리·공개하는 비영리 커뮤니티/표준
• 가장 유명한 산출물: OWASP Top 10 — 가장 흔한 웹 보안 위험 10가지 순위
  • 1위: Broken Access Control (접근 제어 실패)
  • 2위: Cryptographic Failures (암호화 실패)
  • 3위: Injection (SQL, NoSQL, OS 명령어 주입)
  • ...
• 왜 알아야 하나: 보안 면접 단골 질문 + 우리 인프라 설계의 근거
  • 예: "왜 Secrets Manager 쓰나?" → OWASP A02 (민감 데이터 평문 노출 방지)
  • 예: "왜 OIDC/임시 토큰?" → OWASP A07 (하드코딩된 credential = 인증 실패)
• OWASP Kubernetes Top 10도 있음 (K8s 특화 보안 위험)

8. 크로스 리전 쿼리 (Cross-Region Query)

• 다른 AWS 리전에 있는 리소스를 조회/접근하는 것
• 예시:
  • 서울(ap-northeast-2)에서 실행 중인 앱이 버지니아(us-east-1)의 DynamoDB 테이블 조회
  • CloudWatch Logs Insights에서 여러 리전 로그를 한 번에 검색
  • AMP Remote Write: 서울 EKS의 Prometheus가 도쿄(ap-northeast-1)의 AMP 워크스페이스로 메트릭 전송
• 문제점:
  • 레이턴시 증가: 리전 간 네트워크 왕복 (수십~수백 ms 추가)
  • 데이터 전송 비용: 리전 간 데이터 이동 시 과금 (AMP remote write 트래픽 포함)
  • 권한 설정 복잡: IAM 정책에 리전 명시 필요할 수 있음
• AMP Remote Write 크로스 리전(Seoul → Tokyo) 케이스:
  • 왜 발생: AMP(Amazon Managed Prometheus)가 서울에 없거나, 멀티 리전 통합 모니터링 시
  • 비용: 메트릭 ingestion 비용 + 리전 간 데이터 전송 비용 이중 과금
  • 대안: 같은 리전에 AMP 워크스페이스 생성 → 전송 비용 0, 레이턴시 최소
• 우리 프로젝트: 단일 리전(ap-northeast-2)에 모든 리소스 배치 → 크로스 리전 쿼리 불필요 (설계 의도)

9. ServiceMonitor (Prometheus Operator CR)

• Prometheus가 어떤 pod의 메트릭을 수집(scrape)할지 선언하는 K8s 커스텀 리소스
• 왜 필요: Prometheus에 scrape 대상을 일일이 설정 파일로 등록하는 대신, K8s 리소스로 선언하면 자동 감지
• 동작:
  1. ServiceMonitor 생성 → "이 label 가진 Service의 /metrics 엔드포인트를 긁어라"
  2. Prometheus Operator가 감지 → Prometheus 설정에 자동 추가
  3. Prometheus가 해당 pod의 메트릭 수집 시작
• 예시:

  apiVersion: monitoring.coreos.com/v1
  kind: ServiceMonitor
  metadata:
    name: farmily-app
  spec:
    selector:
      matchLabels:
        app: farmily-app    # 이 label 가진 Service 대상
    endpoints:
      - port: http
        path: /actuator/prometheus   # Spring Boot 메트릭 경로
        interval: 30s

• 핵심: pod가 뜨고 내려도 label 기반으로 자동 추적 — 수동 IP 등록 불필요
• 관련: PodMonitor(Service 없이 pod 직접 대상), PrometheusRule(알림 규칙)

10. AMP (Amazon Managed Prometheus)

• AWS 관리형 Prometheus — 서버 운영 없이 메트릭 저장·쿼리 제공
• 왜 필요: 자체 Prometheus는 스토리지 관리·HA·스케일링 부담. AMP는 AWS가 다 해줌
• 우리 구조에서의 역할: EKS 내 Prometheus가 수집한 메트릭을 remote write로 AMP에 저장 → AMG(Grafana)가 쿼리해서 시각화
• 우리 실측: farmily-ops (서울, ws-2f69639a...)

11. AMG (Amazon Managed Grafana)

• AWS 관리형 Grafana — 대시보드·시각화·알림 제공
• 왜 필요: 자체 Grafana 운영(업그레이드·인증·백업) 부담 제거. SSO 통합 간편
• 우리 구조:
  • 서울 AMG (farmily-grafana) = 일상 운영 대시보드 (CPU, 메모리, 요청 수, 에러율)
  • 도쿄 AMG (Farmily-DR-Grafana) = DR 대시보드. 서울 리전 장애 시에도 도쿄에서 메트릭 조회 가능 (크로스 리전 쿼리)

12. Remote Write (Prometheus → AMP)

• Prometheus가 수집한 메트릭을 원격 저장소(AMP)에 실시간 전송하는 메커니즘
• 왜 필요: Prometheus 로컬 스토리지는 pod 죽으면 날아감. remote write로 AMP에 영속 저장
• 우리 구조: Prometheus(EKS) → SigV4 인증(IRSA) → AMP 서울 → AMG(서울/도쿄)에서 쿼리
• SigV4: AWS 전용 서명 방식. IRSA가 발급한 credential로 AMP에 인증

13. kube-prometheus-stack

• Prometheus + Grafana + Alertmanager + 기본 ServiceMonitor 묶음 Helm 차트
• 설치하면 자동으로: K8s 핵심 컴포넌트(apiserver, kubelet, coredns, etcd 등) 14개+ ServiceMonitor 생성
• 우리 프로젝트: monitoring 네임스페이스에 설치됨 (7일 전). 기본 모니터링 커버리지 제공

14. KEDA (Kubernetes Event-Driven Autoscaling)

• 이벤트 기반 오토스케일링 — HPA보다 유연. 외부 메트릭(SQS 큐 길이, Prometheus 쿼리 등)으로 pod 수 조절
• 왜 필요: HPA는 CPU/메모리만 봄. KEDA는 "큐에 메시지 100개 쌓이면 pod 늘려" 같은 비즈니스 메트릭 기반 스케일링 가능
• 0→1 스케일링 지원 (HPA는 최소 1개 pod 필요)
• 우리 프로젝트: keda 네임스페이스에 설치됨, ServiceMonitor 2개로 메트릭 수집 중

15. Karpenter

• 노드 오토스케일링 — Cluster Autoscaler 대체. pod가 스케줄 안 되면 즉시 최적 인스턴스 프로비저닝
• 왜 필요: Cluster Autoscaler는 ASG 기반(느림, 인스턴스 타입 제한). Karpenter는 직접 EC2 API 호출 → 빠르고 유연
• 우리 프로젝트: karpenter 네임스페이스에 pod 2개 running, ServiceMonitor로 메트릭 수집 중

16. Argo Rollouts

• 점진적 배포(카나리, 블루-그린) 컨트롤러 — K8s 기본 Deployment의 rolling update보다 세밀한 트래픽 제어
• 왜 필요: "새 버전에 5%만 트래픽 보내고, 에러율 확인 후 자동 승격/롤백" 같은 안전한 릴리스
• 우리 프로젝트: argo-rollouts 네임스페이스에 설치됨, ServiceMonitor로 메트릭 수집 중 (체크리스트 [5-x] 실제 워크로드 적용은 미착수)

17. DR 페일오버 (Disaster Recovery Failover)

• 주 리전(서울) 장애 시 보조 리전(도쿄)으로 전환하는 절차
• 우리 구조에서 도쿄 AMG의 역할: 서울 전체가 죽어도 도쿄에서 서울 AMP 메트릭을 크로스 리전 쿼리 → "어디까지 죽었나" 장애 범위 판단
• 실제 서비스 페일오버(RDS, EKS 등)와는 별개 — 여기서는 관측 평면의 DR

18. stdout / stderr

• stdout (Standard Output) = 프로그램의 정상 출력 채널. echo "hello", System.out.println() 등
• stderr (Standard Error) = 프로그램의 에러/경고 출력 채널. System.err.println(), 예외 스택트레이스 등
• 왜 분리: 정상 결과와 에러를 따로 처리할 수 있음 (파이프라인에서 중요)
  • command > output.txt → stdout만 파일로, 에러는 화면에
  • command 2>&1 → stderr를 stdout으로 합침
• 컨테이너/K8s에서: pod 로그 = stdout + stderr 출력. Fluent Bit이 이걸 수집 → CloudWatch/Loki로 전송
• 우리 프로젝트: 앱이 stdout으로 찍는 로그를 CloudWatch Observability 애드온(Fluent Bit)이 수집

19. 린트 (Lint / Linter)

• 코드나 설정 파일의 문법 오류·스타일 위반·잠재적 버그를 자동으로 잡아주는 도구
• 이름 유래: 1979년 C 언어 정적 분석 도구 lint (보풀 잡는다는 의미)
• 우리 프로젝트 예시:
  • kubeconform = YAML 린트 (K8s 스키마 대비 검증)
  • conftest = 정책 린트 (OPA/rego 규칙 위반 검출)
  • SonarCloud = Java 코드 린트 (버그·취약점·코드 스멜)
  • helm lint = Helm 차트 린트 (Chart.yaml·templates 문법 검증)
• 린트 vs 테스트:
  • 린트 = 코드를 실행하지 않고 정적으로 분석 (빠름)
  • 테스트 = 코드를 실행해서 동작 확인 (느리지만 정확)
• CI에서의 역할: PR 올리면 린트 먼저 → 통과해야 리뷰/머지 가능. 사소한 실수를 사람이 잡을 필요 없게 자동화

20. Fluent Bit

• 경량 로그 수집기 — 각 노드(DaemonSet)에서 컨테이너 stdout/stderr 로그를 수집 → 외부로 전송
• 왜 필요: pod 죽으면 로그도 사라짐. Fluent Bit이 실시간으로 CloudWatch Logs에 보내서 영속 보관
• Fluentd보다 가볍고 빠름 (C언어, 메모리 ~10MB)
• 우리 프로젝트: CloudWatch Observability 애드온에 포함. 각 노드에 DaemonSet으로 실행 중

21. CloudWatch Logs (CW Logs)

• AWS 관리형 로그 저장·검색 서비스
• 역할: pod 로그(Fluent Bit 전송), Lambda 실행 로그, VPC Flow Logs 등 통합 저장
• Logs Insights로 쿼리 가능 (예: "최근 5분간 ERROR 로그 검색")
• 우리 프로젝트: EKS pod 로그 + Lambda 로그 여기에 저장됨

22. CloudWatch Metrics (CW Metrics)

• AWS 관리형 메트릭(숫자 시계열) 저장·쿼리 서비스
• 두 종류:
  • AWS 네이티브 메트릭: RDS(CPU, 커넥션 수), ALB(요청 수, 5xx), WAF(차단 수), Lambda(호출 수, 에러율) → 자동 수집
  • 커스텀 메트릭: CW Agent가 EKS 노드/pod에서 수집 (Container Insights — CPU, 메모리, 네트워크)
• AMP와의 차이: CW Metrics = AWS 네이티브 통합 + 알림. AMP = Prometheus 생태계(PromQL, Grafana)

23. CloudWatch Agent (CW Agent)

• 노드/컨테이너에서 시스템 메트릭을 수집해 CW Metrics로 보내는 에이전트
• Container Insights: pod별 CPU·메모리·네트워크·디스크 메트릭 수집
• 우리 프로젝트: CloudWatch Observability 애드온에 포함 (DaemonSet)

24. CloudWatch Alarm

• CW Metrics의 임계값 초과 감지 → 알림 트리거
• 예시: "ALB 5xx 에러율 > 5% 가 3분 연속" → ALARM 상태 → 액션 실행
• 3가지 상태: OK → ALARM → INSUFFICIENT_DATA
• 우리 프로젝트: 알람 → SNS → Lambda → Slack 전송 체인

25. SNS (Simple Notification Service)

• AWS 관리형 메시지 발행-구독(pub/sub) 서비스
• 역할: CloudWatch Alarm이 SNS 토픽에 메시지 발행 → 구독자(Lambda, 이메일, SQS 등)에게 전달
• 왜 중간에 SNS: Alarm이 직접 Slack 못 보냄. SNS가 중계해서 Lambda 호출 → Lambda가 Slack 전송
• 우리 프로젝트: alarm-to-slack Lambda가 SNS 토픽 구독

26. alarm-to-slack Lambda

• SNS에서 받은 알림 메시지를 Slack으로 변환·전송하는 Lambda 함수
• 왜 Lambda: Slack webhook 호출은 커스텀 포맷 필요 (JSON 변환). Lambda로 가공 후 전송
• 흐름: CW Alarm → SNS → Lambda → Slack #farmily-알림

27. 능동적 모니터링 vs 수동적 감지

• 능동적 모니터링 = 대시보드(AMG)를 직접 보면서 상태 확인. 사람이 주기적으로 확인
• 수동적 감지 = 알림(Alarm → Slack)이 알아서 알려줌. 문제 생기면 자동 알림
• 왜 둘 다 필요: 대시보드만 있으면 안 보고 있을 때 놓침. 알림만 있으면 전체 맥락 파악 어려움. 조합해야 완전

28. 메트릭 (Metrics)

• 시스템 상태를 나타내는 숫자 시계열 데이터 (시간 + 값)
• 로그와의 차이:
  • 로그 = "무슨 일이 일어났나" (텍스트, 이벤트 단위) — ERROR: DB connection failed at 14:30:01
  • 메트릭 = "지금 수치가 얼마인가" (숫자, 시간 흐름) — CPU: 72%, 메모리: 1.2GB, 요청 수: 150/s
• 종류:
  • 인프라 메트릭: CPU 사용률, 메모리, 디스크, 네트워크 (CW Agent가 수집)
  • 앱 메트릭: 요청 수, 응답 시간, 에러율 (Spring Actuator /metrics로 노출 → Prometheus가 수집)
  • AWS 네이티브 메트릭: RDS 커넥션 수, ALB 5xx 비율, Lambda 호출 수 (자동 수집)
• 왜 중요: 숫자니까 임계값 설정 가능 → Alarm → 자동 알림. 그래프로 트렌드 파악 가능
• 우리 프로젝트:
  • CW Metrics = AWS 네이티브 + CW Agent 커스텀
  • AMP = Prometheus가 수집한 K8s/앱 메트릭
  • 둘 다 AMG 대시보드에서 시각화

Prompt(회고)

• 이번주는 목요일이 마지막이다. 내일은 휴가이기 때문에 이제 진짜 5일정도 남았는데 남은 기간동안 열심히 발표 준비를 해보겠다.