[컨퍼런스] WIP 2025 : 기술의 장벽을 허무는 사람들 후기

아임웹 인프라 아키텍처

1. 트래픽 유형 및 주요 대응 대상

1) 트래픽 유형

• 디도스(DDoS) 공격
• 한정판 상품 판매
• 인플루언서 협업 이벤트
• 포털 사이트 광고
• 예약 기능을 통한 트래픽 집중
• 퀴즈 이벤트 (가장 높은 순간 트래픽 발생)

2) 아임웹 주요 고객 유형

• 기업/기관 홈페이지
• 랜딩 페이지 (이벤트 페이지 등)
• 쇼핑몰 및 커머스

2. 멀티 테넌시 환경과 노이지 네이버(시끄러운 이웃) 문제

• 멀티 테넌시 (Multi-tenancy) 기반 서비스로 여러 고객이 자원을 공유
• 특정 사이트 트래픽 폭증 시 전체 서비스 영향 → 노이지 네이버(Noise Neighbor) 문제 발생 가능
• 해결 방안: 사전 대응, 격리 서버, 트래픽 제어, 인프라 분리

3. 트래픽 대응 및 보호 체계

1) AWS WAF (웹 방화벽) 활용

• 웹 ACL로 규칙 관리
• IP셋, 정규표현식(RegEx) 패턴셋 적용
• AWS Kinesis Firehose → S3 로그 저장 → Datadog 모니터링 및 Slack 알림

2) 격리 서버 (Isolation Server)

• 트래픽 과부하 시 특정 사이트 전용 격리 서버로 분리
• 자동화된 기준 기반 전환
• Slack 명령어로 원격 제어

3) 트래픽 제어

• AWS CloudFront 지리적 제한
• Route 53 지리 기반 라우팅

4) 대기열(Queueing) 시스템

• 자체 개발, 급격한 트래픽 유입 시 트래픽 속도 조절

4. 인프라 운영 체계 (모니터링 및 증설)

1) 모니터링 요청 대응 프로세스

• 당번 제도(주 단위 담당자 운영)
• 사전 모니터링 요청 접수 → 서버/DB 증설 자동화
• 모니터링 지표 기록: 서버/DB 수량, 최대 트래픽, 인프라 영향 분석

2) 대형 이벤트(내고왕 등) 준비

목표: 서비스 무중단, 타 고객 사이트 영향 차단

대응 전략

• 코드 최소 수정
• 서버 및 로드밸런서 분리
• 전용 읽기 전용 DB 분리
• AWS ALB(로드밸런서) 프리워밍 사전 요청

모니터링 및 협업

• AWS, 세일즈, 인프라팀 협업
• 실시간 트래픽 감시, 고객사와 커뮤니케이션

5. 실제 대형 이벤트(네고왕) 대응 결과

• 순간 최대 요청: 4만 9천 건/분, 데이터 전송량: 508MB/분
• 일반 사이트 대비 10배 트래픽
• 두 차례 모두 무사고 성공적 처리
• 고객사 매출: 7일간 25억 원 기록

6. 향후 인프라 개선 방향

1) 레거시 시스템 분리 및 관측성 향상

• 모니터링/인프라 시스템 분리
• 문제 탐지, 신속 대응 체계 구축

2) 장애 대응 시간 단축 및 유연성 확보

• 장애 훈련 프로그램 도입 예정

3) 인프라 최적화 및 자동화

• 서버 그룹/DB 분리 전략 지속
• 인프라 간소화 및 자동화 진행

4) 서비스 격리 강화

• 장애 확산 방지를 위한 독립적 리소스 배정 전략

 

아임웹 데이터 플랫폼 구축기

1. 아임웹 데이터팀 현황

• 실시간 Kafka 메시지 처리량: 2.25억 건
• Kafka 메시지 용량: 637GB
• 저장 데이터 용량: 80TB (지속적 최적화 중)
• 쿼리 성능: 600만 건 데이터 리드 → 1.7초 내 응답
• 플랫폼 사용률: 전체 구성원 60% 사용

2. 데이터팀 초기 상황 (제로부터 시작)

조직/문화: 데이터 팀, 데이터 문화 모두 처음

구성원: 전원 경력 2년 미만 주니어

환경:

• 데이터 플랫폼 부재
• 분석 환경: 스테이징 DB, 맥 스튜디오 로컬 처리
• 프로덕션 DB 직접 접근, 데이터 크기 증가로 처리 한계

문제점: 데이터 거버넌스 부재, 품질 이슈, 데이터 사일로, 메타 데이터 관리 부족

3. 초기 대응 방안 및 도입 솔루션

1) KPI 중심 데이터 파이프라인

• AWS Redshift 기반 데이터 웨어하우스
• S3 메달리온 아키텍처 도입
• AWS Glue, Athena, Airflow 기반 데이터 처리 및 쿼리 환경 구축
• DataHub 통한 데이터 카탈로그/거버넌스

2) 문제 지속

• 데이터 누락, 정합성 이슈
• 변경 이력 저장 불가
• 어드민 대시보드 데이터와 분석 데이터 간 불일치
• 요청 기반 개별 파이프라인 구축으로 비효율
• 분석가 SQL 의존

4. 고도화 방향 및 CDC 기반 통합 아키텍처 구축

1) CDC (Change Data Capture) 도입

• Binlog 기반 변경 데이터 수집 (Debezium 사용)
• AWS EC2 + Kinesis + S3 + Lambda 통한 실시간 데이터 처리
• MSK (Managed Streaming for Kafka) 통한 안정적 메시징
• 전체 데이터 커버리지 확보 (DB 모든 트랜잭션 캡처)

2) 외부 이벤트 데이터 수집

• SDK 기반 외부 데이터도 MSK + S3 통합 저장

3) 데이터 레이크/웨어하우스 통합

• Databricks 기반 멀티 레이어 (Bronze, Silver, Gold)
• 데이터 엔지니어 도움 없이 분석가 직접 데이터 조회 가능
• 데이터 품질 보장, 중복·누락·순서 보장

5. 개선 효과 및 현재 한계

성과

• 전사 KPI 대시보드 안정적 제공
• 자동화된 데이터 수집·처리
• 데이터 유실 최소화
• 데이터 분석가 자율적 데이터 활용 환경 구축
• 데이터 오너십 확립 및 팀 역량 강화

남은 문제

• 여전히 어드민 대시보드 데이터와 분석 데이터 간 불일치
• 모든 데이터 요구 대응 어려움 (유연성 한계)
• 데이터 분석가의 엔지니어 의존 일부 남음

 

회고

최근 들어서 클라우드 기술을 본격적으로 공부하고 있는데, 아무리 실습을 해본다고 한들 실제 트래픽이 들어오는 것은 아니였기 때문에 와닿지는 않았었다.

이번 컨퍼런스를 통해서 비교적 작은 트래픽을 운용하던 업체가 갑작스럽게 대형 트래픽을 운반해야 될 때 참고할 수 있는 좋은 내용들을 얻을 수 있었다.

특히나 최근 준비하고 있는 AWS 자격증 문제와도 유사한 실사례들이 있어서 더 재미있게 들었던 것 같다.

나도 어서 빨리 현업에 투입돼 다양한 사례들에 맞게 아키텍처를 구성, 운용해 보는 경험을 쌓고 싶다.

요즘 중소기업 면접들과 컨퍼런스에서의 사례들을 접하면서 느끼는 게 무작정 대용량 트래픽을 다룰 수 있는 거대한 아키텍처를 짜는 것에 집중하기 보다는, 기업의 규모에 맞게 현명한 선택을 하는 것이 진정한 아키텍처이지 않을까라는 생각을 한다.

예를 들어서 온-프레미스 환경의 레거시 웹 애플리케이션을 AWS 클라우드 환경으로 마이그레이션 한다고 했을 때, 과연 L4와 L7 로드밸런서 중 어떤 것을 선택해야할까?

예전 같았으면 묻지도 따지지도 않고, L7을 선택했을 것 같은데 지금은 생각이 좀 다르다.

L7 로드밸런서의 비용이 더 비싼 부분도 한몫하고, L7 로드밸런서를 효율적으로 사용하기 위해서는 쿠키 기반 세션 등 웹 애플리케이션의 수정도 불가피하게 필요하다.

만약 고객이 안정성만 조금 더 추구하는 수준의 인프라 아키텍처를 원한다면 EC2 인스턴스에 그대로 마이그레이션을 한 뒤 앞단의 L4 로드밸런서를 배치하는 게 오히려 비용효율적이지 않을까?

두서가 길었다.

고객의 상황 혹은 나의 회사에 맞게 적절한 아키텍처를 고를 줄 아는 인프라 아키텍처가 되자.