[회고] 2025년 첫 커리어 1년간 한 일

개요

---

2025년 첫 커리어를 시작하고 SRE로서 회사에 기여한 일들을 정리해본다.

(그대로 옮기니까 가독성이 좀 떨어지긴 한데..ㅋㅋ 작업 관련 스레드 링크를 모두 붙였다가 이걸 이미지와 글로 풀어내려니까 어려운 점..)

 

1) 서비스 캐시 성능 향상 및 인프라 비용 절감을 위한 ElastiCache for Valkey 도입

---

| Problem

• 안정적인 서비스 운영과 성능/비용 최적화를 위해 Valkey로의 전환을 추진

| Task

• 사내 플랫폼 ElastiCache 기능 개발 및 출시
  • 사내 플랫폼 API 개발
    • boto3 API 검토 및 기존 Redis 워크플로우 기반 Valkey 생성 기능 구현
    • Engine Version 조회 API 리팩토링: Redis 5.x/6.x 지원 중단, Valkey 7.2/8.x 버전 추가
    • Parameter Group 검증 로직 개선 (Redis ↔ Valkey 전환 시 engineType 버그 수정)
  • 사내 플랫폼 UI 개발
    • ElastiCache 생성 화면에 Redis/Valkey 엔진 선택
    • 구버전(Redis 5.x, 6.x) 생성 제한 및 Valkey 버전 목록 확장
  • 오픈 공지

• Valkey 모니터링을 위해 redis exporter v1.74.0 업그레이드
• 마이그레이션 검증 및 클라이언트 호환성 테스트
  • Redis → Valkey 전환 시, 우려사항과 성능 비교에 대한 글 작성 후 전사 발표를 통한 공유
    
    • 성능 비교 테스트: https://cobinding.tistory.com/309
• 프로젝트 완성도를 위한 외부 미팅 주도
  • AWS ElastiCache Specialist와의 미팅을 통해 공식 가이드 및 베스트 프랙티스 검증
  • 당근 내 ElastiCache를 적극적으로 사용하는 팀과의 미팅을 통해 실사용 사례 및 운영 노하우 공유(/w Lani)
• 관련 운영 지원
  • 엔진 업데이트 주의사항 공유 
  • 사내 플랫폼 Redis 마이그레이션 작업
  • Redis 관련 운영 질문 & 업데이트 고려사항 등

사내 개발자들에게 Redis 엔진 업데이트 안내 및 대응 / 마이그레이션 업무 진행

 

| Impact

• ElastiCache Redis → Valkey 마이그레이션을 통해 Alpha 21.9%, Prod 20.2%의 전환율 달성. Valkey는 Redis 대비 20% 저렴하여, 현재 전체 ElastiCache 비용의 약 4% 절감 효과.
  • feature-platform 전환 사례: 대략 일 $500, 월 $15,000 절감
• Valkey 마이그레이션의 배경과 효과를 전사에 공유하고, 개발자 관점의 전환 가이드를 제공

오른쪽 가장 위에 오프라인으로 참석해서 발표한 영상..ㅎㅎ 우리 회사에서는 매주 전사적으로 기술적 이야기를 공유하는데 그 자리를 빌려 발키 소개했다. 보통은 온라인으로 참여하고 원하는 사람이나 발표자는 오프라인으로 참여한다.

 

 

 

2) 인프라 E2E 장애 모니터링 가시성 확보 1: CloudFront Additional Metrics

---

| Problem

• CloudFront는 모든 트래픽이 통과하는 첫 진입점이지만, 해당 구간의 모니터링 부재

| Task

• CloudFront 관련 모니터링 강화를 위한 Additional Metrics 활성화
• Additional Metrics 예상 비용 확인 후 적용

관련 미팅 문서를 만들었고 팀 내에 공유

| Impact

• 지금까지 모니터링 되고있지 않은 영역들(Cache Hit, Origin Latency 등)에 대한 메트릭 확보 → 확보된 지표로 CloudFront 대시보드 제작 → CloudFront 모니터링 가시화
• 개발팀의 트래픽 확인 요청 해소

처음 PromQL & Grafana를 활용해서 작업하고, 개발팀에게 공유해본 경험

 

 

3) 인프라 E2E 장애 모니터링 가시성 확보 2: CloudFront Alert 시스템 구축

---

| Problem

• CloudFront 레거시 자원 점검을 계기로 인프라 최앞단인 CloudFront 모니터링을 강화
• Anomaly Request와 403 Error Rate 얼럿을 통해 트래픽 이상 감지 체계를 구축.
• 이후 false positive를 지속적으로 개선하며, 인프라 전반의 장애 대응 역량 강화를 목표로 진행중

 

| Task

• Datadog False Alert 평가 및 정리
  • CF additional metrics 활성화 후 false alert 급증 → 레거시 자원 목록 추출 및 정리
  • DDog Alert 제거 논의

CF에 대한 Add Metrics을 활성화한 이후 Ddog 얼럿에 문제가 생겼고 이를 grafana alert rule로 풀어보는 작업으로 확장되었다.

 

• (위 결과에 따른) Grafana Alert Rule 설계 및 구현
  • Request Anomaly
    • Z-Score 기반 단기(3h)/장기(2주) 추세 반영 쿼리 직접 구현
    • 테스트 결과를 분석하며 단기 추세 계산을 24h → 8h → 3h로 최종 적용
      • 3h가 이상치 얼럿에 대한 최선의 판단이라고 결론
      • 장기 & 단기 추세 알고리즘 문서 (링크 첨부)
      • 트래픽 이상치 유효성 검증 결과 분석 문서 (링크 첨부)
    • Alert 계산 효율을 위해 특정 규모의 트래픽이 있는 Dist에 대해서만 수행하도록 하한선 설정
      • 하한선 측정 방법에 대한 문서: 위 알고리즘 문서와 동일

요렇게... PromQL로 알고리즘을 구현하고 그 얼럿 추이를 지켜본 뒤, 유효성을 검증했다. 지금은 Prod 환경에서 얼럿이 동작하고 있고, 계속해서 개선을 하다보니 쿼리가 많이 길어져서 레코딩룰로 전환하는 작업으로 이어졌다.

 

 

• 403 Error Rate
  • DDoS, Origin 권한 문제 감지

• 지속적인 False Positive 개선 (/w Hun, Aidan)
  • false positive 최소화를 위한 개선 작업
  • Alert 가독성을 위한 메시지 포맷 개선 (project_name, Distribution ID 등 정보 추가)
  • 특정 프로젝트 자원 예외처리 및 사이드이펙트 대응
  • Alert Delivery 적용하여 서비스팀 전달 체계 구축
  • HAProxy, big-picture 등 Edge Case 예외처리

 

| Impact

• DDoS 감지

실제로 DDoS 감지에 활용되고 있고 Q보다 빠르게 잡은 성과가 있었다. 🤣 DDoS 패턴이 다양해지고 있는데 여러 건 얼럿을 받아봐서 후속조치 등에 대한 고민을 하고있다.

 

• 프로모션 이벤트 감지
  • 프로모션 이벤트가 생기면 사용자가 몰리는데, 이에 대한 이상치도 감지되고 있다.
• 전사 Traffic Anomaly Detection 활용 기대
  • 지속적인 False Positive 개선을 통해 인프라 앞단(CloudFront)의 트래픽 이상 감지 체계 고도화
  • 향후 다른 레이어(istio 등)의 Anomaly Detection에도 해당 알고리즘 적용을 통한 모니터링 기대

 

4) 멀티 리전 환경에서 EC2 SSM 접근 로깅·암호화 구조 표준화

---

| Problem

• 리전별로 EC2 접근 로깅 및 암호화 설정이 서로 달라서, 리전마다 보안 설정을 확인해야 하는 비용이 발생할 수 있는 구조
• 주요 인스턴스 서버에 대한 접근 이력이 일관된 기준으로 관리되고 있지 않음

 

| Task

• 문제 발견 및 작업 직접 제안
  • EC2 기능 사내 플랫폼 오픈 준비 중 SSM KMS 설정과 세션 로그 S3 버킷이 KR 리전에만 존재하는 것 발견
  • 모든 환경/리전별 SSM 로킹 & 암호화 설정 표준화 필요성 직접 제안

• 글로벌 리전 SSM 인프라 구축
  • Alpha/Prod 환경의 글로벌 리전에 세션 로그 S3 버킷 생성
  • 리전별 KMS Key 생성
  • SSM Session에 대해 KMS 암호화 설정 적용

 

| Impact

• SSM 접근 로깅과 암호화 설정을 적용 → 환경/리전 관계 없이 접근 기록과 암호화 적용 여부가 보장되도록 인프라 구조 표준화
• 세션 로그는 개인정보·인증 정보가 포함된 보안 핵심 로그이기에, 보안팀 일부 인원만 접근 가능하도록 설정
• 해당 작업을 통해 인프라 보안, SSM Logging 역량 강화

 

5) 전사 EC2 SSM 접근 관리를 위한 공용 IAM Policy 적용 및 인프라 표준화

---

| Problem

• SSM 로깅·암호화 설정 후
  • CA 리전 인스턴스(i-056...)에서 SSM 접속 불가 문제
  • EKS 클러스터 노드 접근 불가 문제
  • 프로덕션 worker Role 권한 문제

| Task

• 미적용 Role 추출 및 문서화
  • 환경/리전별로 SSM 접근 Policy 미할당 Role 추출

• 공용 Policy 정의 및 일괄 적용
  • • 공통 Policy 에 최소 권한 원칙 적용 (KMS, S3 PutObject 등)
      • Alpha/Prod 환경의 모든 리전 Instance 관련 Role에 스크립트로 일괄 적용
• 적용 검증
  • 환경/리전별 haproxy 머신에 SSM 명령어로 접근 가능 여부 검증

 

| Impact

• 전사 인프라 모든 EC2 인스턴스에 일관된 SSM 접근 정책 적용 완료
• 신규 인스턴스 생성 시에도 동일한 Policy가 자동 적용되는 표준화된 구조 확보
• 인프라실 위클리 발표를 통해 네트워크팀, DB팀 등 SSM 사용 부서에 변경사항 공유

 

6) 플랫폼 기반 인프라 프로비저닝·운영 자동화: EC2 Instance 기능 도입

---

| Problem

• (SRE) 인스턴스 타입, 스토리지, AMI, 보안 그룹, IAM Role 설정과 SSM 접근 방법을 매번 수동으로 처리
  • 서버 스펙을 위한 커뮤니케이션 비용 증가
  • 수동으로 설정하다보니 인프라 비표준화, 보안 유의사항을 누락하기 쉬운 구조
• (개발팀) 테스트용 서버가 필요할 때마다 SRE 요청 후 대기해야 하므로 PoC 속도 저하 및 자율성 제한

| Task

• Tech Spec

테크 스펙을 작성하고 논의했다.

 

• EC2 Instance 서버 보안 강화를 위한 설정들 (w/보안팀)
  • 모든 Instance에user-data Script를 통한 CrowdStrike 강제화
  • 모든 Instance에 IMDSv2 설정 강제화
  • Security Group Inbound 제한
  • 보안상 최소 권한 부여를 위한 논의 스레드: 
• 사내 플랫폼 EC2 생성·수정·삭제 작업

| Impact

• Test용 서버를 플랫폼으로 쉽고 빠르게 생성
• 앞으로 생성되는 EC2 Instance는 CrowdStrike, IMDSv2, SSM 접근 등 보안 사항 준수 → 인프라 표준화

 

7) CloudFront SaaS Manager 도입

---

| Problem

• FE 배포된 프론트엔드 사이트의 도메인 변경 건이 필요할 때마다 개발팀 → SRE 요청
  • SRE는 사내 플랫폼 API를 통해 도메인/ACM 인증서를 직접 수정하고, 사내 플랫폼 DB 값도 별도로 수정해야 함
• 전사의 프론트엔드 배포 건수가 많아지면서 CloudFront, 서브도메인 관리 부담도 함께 증가

| Task

• 사내 플랫폼 API 구현 및 PoC 진행
  • boto3 API로 multi-tenant 생성 기능 검증 및 테스트
• 개발팀 미팅 및 요구사항 협의
  • 1차 (7/14): SaaS Manager 기능 소개 도입 가능성 논의
  • 2차 (10/23): API 스펙 및 multi-tenant 구조 논의
  • 결정 사항: FE 배포 전용 multi-tenant 1개 구성, 사내 플랫폼 즉시 도입은 보류 SRE팀 내부 검토 및 결정
• 구조 설계 재검토 및 선행 작업
  • 초기 구조 설계가 복잡해 동료와 협업하여 워크플로우 재검토
  • SaaS Manager 도입을 위한 선행 작업으로 사내 플랫폼 도메인 스코프 정리 진행
  • 도메인 스코프 정리 완료 후 CF multi-tenant 사내 플랫폼 API 스펙 재정의

| Impact

• 사내 플랫폼 StaticWebsite 도메인 스코프 정리 및 개선 완료
• PoC 기술 검토 완료, FE 배포 전체 방향성 논의로 확장

 

8) AWS 비용 이상치 탐지 시스템 구축을 통한 비용 관리

---

| Problem

• MAU 2000만, 서비스가 점점 커지고 다양한 시도를 하면서 인프라 비용 꾸준히 증가
• GCP는 비용 이상치 감지 시스템이 구축되어있지만, AWS는 수동 확인에 의존
  • 이상 비용은 운영 이슈로 이어질 수 있고, 인프라 비용 관리 관점에서 중요도가 높음.

| Task

• 출시 공지(기능, 사용법, 실제 탐지 내용)

• 프로젝트 단계
  • 중간 과정 및 의사결정에 대한 정리 문서 (문서 링크)
• Slack 채널 자동 알림

| Impact

• 결과물: threshold=$1,000이 넘는 비용 이상치에 대한 모니터링
  • 모니터링 과정을 거쳐 threshold 값 설정

• 예시 얼럿 유형:
  • 예시1(MSK 스케일업)
  • 예시2(prod---x 관련 DB 스케일업)
  • 예시3(ppxx-platform $2,000 증가)
• 얼럿 유효성이 검증되어 개발팀 온콜 멘션 그룹 활성화 계획(2026 1분기)

 

9) StaticWebsite SLI 정의 및 사내 플랫폼 대시보드 구성

---

| Problem

• StaticWebiste(R53, CloudFront, S3) 장애 감지 및 대응 체계 강화
  • 현황: CloudFront 관련 장애 발생 시 에러 조기 감지율 부족
  • 목표: 에러 캐치율 개선을 통한 장애 대응 시간 단축

| Task

• CloudFront SLI 정의를 위한 아이데이션
• CloudFront SLI Info, success_request 관련 작업 
• CloudFront 메트릭을 위한 레거시 Tag 제거 작업 
• R53 SLI 개선 작업
• 사내 플랫폼 SLI 가시화 작업
• 클라우드파트 SLI 문서 정리 작업

 

| Impact

• 사내 플랫폼 StaticWebsite 모니터링 가시화
• R53 Exporter DNS Lookup 대상 추가
• R53 Exporter 메트릭 수집 성능 개선

 

 

운영 업무

---

| 장애 대응

| Pay Oncall

• SRE 클라우드 파트 Pay 업무 온콜 담당
  • 목적: 온콜 운영 경험을 통한 Pay 업무 이해도 향상 및 파트 내 지식 공유
    • Pay 업무 사흘 간 느낀 점 회고
    • 온콜 일지

| Market Oncall

 

| 기타 운영

• 멀티 리전 Prod 환경의 KMS 삭제 및 비활성화 권한 Deny (/w Lu)
• AWS GuardDuty 비용 증가 원인 파악을 위해 비용 모니터링 Budgets 설정
• StaticWebsite 관련 도메인 변경

 

발표 및 공유

---

[25.03.07 | 인프라 위클리] 신규입사자가 느낀 개선점과 방향성 발표

[25.05.16 | 인프라 위클리] Kost Anomaly Detection 기능 소개

[25.07.18 | 인프라 위클리] CloudFront Saas Manager 기능 소개 및 협업 과정

[25.08.28 | Tech Allhands] Kontrol ElastiCache for Valkey 출시와 관련 내용

[25.12.05 | 인프라 위클리] Kontrol EC2 도입 과정 중 인프라 & 보안 개선점 소개

 

기타

---

[25.09.03] Builder's Camp 해커톤 시뮬레이션 참여