쿠팡 개인정보 유출 이슈 이후 보안이 중요한 화제로 떠오른 요즘, 우리 회사에서도 ISMS 심사를 준비하게 되었다. 심사 조건을 충족하기 위해 새롭게 정의한 네트워크 설계도를 기준으로 개발팀 인프라 전체가 작년 말부터 조금씩 이동해왔다.
데이터팀도 그 구조에 맞춰 VPC/서브넷을 옮기고 연동이 깨지지 않도록 검증하는 역할을 맡았다. 이렇게 많은 인프라를 이동시켜 본 건 처음이라, 작업과정과 더불어 트러블슈팅 사항들을 정리했다.
작업 범위
데이터팀이 맡고 있는 인프라 중 이번에 크게 변경된 대상은 다음과 같다.
영역 | 대상 | 변경 | 핵심 리스크 | 검증 포인트 |
RDS | 분석 DB | private subnet 이동 | 다운타임/엔드포인트 | 커넥션/스케줄 재개 |
DMS | CDC 복제 | endpoint 수정 + 리로드 | 대량 리로드 부하 | 순차 리로드/정합성 |
EC2 | Redash | data VPC, private subnet + ALB | 데이터소스 연결/SG | 테스트 쿼리/권한 |
EC2 | DataHub | manage VPC, private subnet + ALB | ingestion/API/MWAA 연동 | GMS(8080) 호출/connection |
EC2 | Tableau(내부) | data VPC, internal ALB | 백업/복구 시간, 멀티노드 | topology 동일, 복구 성공 |
EC2 | Tableau(외부) | data VPC, public ALB | 다운타임 | 복구 성공 |
ECS | Kafka Consumer | EC2→Fargate 참여 | 엔드포인트 변경 | lag/offset/적재 |
이 중 RDS와 DMS 는 live 환경에서는 작업을 할 수 없기에, 새벽에 서버를 닫고 운영 DB 및 연동 서비스(MSK/DMS 등)를 한 번에 이관했다.
작업 전
인프라 이동이란 사이드 이펙트가 매우 큰 작업이기 때문에, 사전 영향도를 파악하고 꼼꼼히 정리하는데 많은 시간이 들었다.
리소스 생성/변경은 전부 terraform으로 작업했다. 기존에는 terraform으로 관리하는 리소스와 아닌 리소스가 섞여있었는데, 덕분에 거의 terraform으로 통일 되었다.
사전 확인에서 집중했던 것
•
data VPC의 public/private subnet 구성 및 internal/internet-facing ALB 생성
•
VPC 분리에 따른 피어링 생성 + 라우팅 테이블 연동
•
보안그룹 규칙 전수 조사
◦
기존엔 보안그룹에 규칙이 과하게 누적되어 어떤 소스로 실제 트래픽이 들어오는지 파악이 어려웠음
◦
사용 목적이 확실한 규칙만 남기고 정리 (ex. 22 port는 dev vpn만 남기기)
•
EC2의 접근 방식 정리(EIP/DNS/Private IP 직결 등)
◦
왜 EIP를 따로 쓰는지, DNS가 인스턴스 private IP로 붙어 있는 이유 등 히스토리 파악하고 어디서 어떻게 호출중인지 조사
RDS
RDS 작업 전에는 쓰기 작업/배치를 멈춰야 해서, Airflow에서 작업 시간대 근처 스케줄을 먼저 모두 중지했다.
메인 DB: 다중 AZ
•
다중 AZ 구성으로 바로 서브넷 이동이 안되어 복제본을 이동할 서브넷으로 생성한다음 승격시키는 방법으로 작업이 필요했음
•
이 과정 때문에 DB 엔드포인트를 직접 호출하는 서비스들은 전부 엔드포인트 변경이 필요
데이터팀 DB: 단일 AZ
•
data VPC에 private subnet group을 만들고 바로 서브넷 이동이 가능
•
단, 현재 DB의 가용영역(AZ)이 subnet group에 포함되어 있어야 이동 가능
•
이동은 10분정도 소요되었고 완료 후 미리 생성해둔 보안그룹 적용
•
이후 Airflow에서 커넥션 확인 후 중지한 스케줄 재개
DMS
DB 서브넷 이관이 완료 된 후 DMS 엔드포인트 수정해 다시 로드
원래는 기존 엔드포인트 ID를 놔둔채 값만 수정하면 binlog를 이어서 소비할 수 있지 않을까? 라고 생각했는데, dev에서 테스트해보니 엔드포인트 수정 시 다시 로드만 가능했다.
또한 모든 테이블을 한번에 다시 로드 할 경우 connection이나 DMS 클러스터 리소스 문제가 있을 수 있으므로, 중요 테이블 순서대로 순차 연결하는 방식으로 진행했다.
트러블슈팅
•
로그가 멀쩡한데 타겟에 데이터가 안들어가던 이슈
◦
엔드포인트 연결 테스트는 정상
◦
Task 실행 로그에도 에러가 없음
◦
그런데 타겟 테이블에 데이터가 제대로 안들어옴
•
원인은 endpoint의 database_name이 소문자로 적용되어 있었던 것
◦
이번 인프라 이전 작업을 하며 Terraform 통해 엔드포인트 변경을 했는데 여기에 소문자가 적용되어 값이 제대로 안들어감
•
실제 콘솔상 운영과 Terraform 코드의 이격때문에 발생한 문제로 오류 메시지가 없어 찾는데 시간이 좀 걸림
•
연결 테스트가 정상이라고 정합성이 정상은 아니며 조용한 실패도 있으니 결과 테이블의 실제 적재 상태를 반드시 확인해야 함
ECS 컨슈머
•
기존 EC2 타입으로 배포된 컨슈머를 Fargate로 전환
•
MSK도 서브넷 이동이 있었고, CDC 커넥터가 신규 생성되며 엔드포인트 변경
•
따라서 Secret Manager의 Kafka 엔드포인트를 변경하고 재배포
•
이후 컨슈머 오프셋/지연/적재 상태를 확인해 정상 동작 검증
EC2
여기가 정말 야생이었는데, EC2는 기존 서버를 그대로 옮길수 없고, 새 VPC에 동일한 서버를 다시 만들어야만 한다.
그만큼 변수가 많고, 트러블슈팅도 많이 발생했다.
VPC/서브넷/ALB/보안그룹 세트 맞추기
EC2 이관에서 제일 중요한 건 새 VPC에서 서비스가 정상적으로 통신할 수 있는 네트워크 구성을 맞춰주는 것이다.
•
Public/Private subnet 분리
•
Private subnet이 외부로 나가야 하면 NAT Gateway + route table 연결
•
필요한 VPC peering + 양쪽 route table CIDR 라우팅 반영
•
서비스 특성에 맞춰 보안그룹 규칙 재정리(필수 소스만 최소 허용)
도커 사용 서비스
기본 흐름
1.
AMI 생성
•
도커 서비스는 내리고(Down) AMI 생성해야 안정적으로 이미지 생성됨
2.
생성한 AMI로 Terraform에서 새 인스턴스/보안그룹/타겟그룹/리스너룰 생성
3.
새 인스턴스 접속 후 서비스 확인
•
docker ps / 필요 시 docker-compose up -d
4.
웹 UI 접속해 기능 확인
5.
DNS(Route53) 레코드 전환
6.
기존 리소스 destroy
Redash
•
연결 데이터소스 확인 후, 접근해야 하는 RDS 보안그룹 인바운드에 Redash 보안그룹을 source로 추가
•
데이터소스 연결 별로 테스트 쿼리 실행해 기능 검증
DataHub
DataHub는 단순히 웹이 뜨는지만 보면 안 되고, ingestion 연동이 정상인지, 또 에어플로우에서 API를 제대로 호출하는지 까지 확인해야한다.
•
ingestion 대상이 많아, 관련 DB/서비스 보안그룹 인바운드에 DataHub source를 추가
•
MWAA에서 DataHub GMS(8080 포트)로 API 호출 필요
◦
DataHub 보안그룹에 MWAA 보안그룹 8080으로 허용
◦
Airflow connection(datahub_rest_default) 엔드포인트 수정
트러블슈팅
•
커넥션 수정 후 테스트 DAG에서는 정상동작
•
운영 DAG를 돌리면 이전 주소로 호출이 지속되며 task가 쌓이면서 CPU 100% 넘어 스케줄러 죽는 현상 발생
•
결론적으로 인스턴스 재부팅으로 해결
•
커넥션만 수정하면 되는게 아니고 런타임 캐시나 프로세스 상태까지 고려해야함
Tableau
Tableau는 리소스 규모도 크고, 설치/운영 경험이 많지 않아 공식 문서를 읽으며 준비했다.
무엇보다 Tableau는 docker 기반 서비스가 아니라 AMI 방식으로 옮기기 어렵고, 자체 백업&복구 절차를 따라야 정상적으로 서버를 옮길 수 있다고 안내되어 있었다.
그래서 새 인스턴스 생성 후 태블로를 미리 설치하고 멀티 노드까지 설정을 마친 뒤 복구하는 절차로 작업을 진행했다.
작업시 고려했던 것들
•
백업 파일의 크기가 매우 큼
◦
이전 백업 기준 500G 4시간 → 이번엔 850G 7시간 소요
•
백업시 디스크 용량 3배까지 사용하기 때문에 충분한 여유공간 필요
•
전송 시간도 고려해야해서 S3 통신 속도 사전 측정
◦
약 168MiB/s
◦
예상백업 파일 크기 500G로 계산시 512,000 MiB ÷ 168 MiB/s = 3,047.6초(51분) 정도 예상했으며 실제 작업시 거의 2시간 소요
•
멀티 노드 구성이라 토폴로지(노드 프로세스) 파악후 동일하게 세팅
•
설정/드라이버/라이선스 등 수동 백업
•
백업 파일 복원에 6시간 소요 → 백업&복구 총 프로세스 17시간 정도 소요
자주 터진 문제들
AWS 서비스들과 네트워크 구조를 end-to-end로 이해하고 있지 않으면 디버깅이 어렵다. 특히 네트워크는 한 군데만 막혀도 서비스가 아예 안되기 때문에 트래픽 흐름을 따라가며 어디에서 끊겼는지 하나씩 확인해야 했다.
대표적인 케이스
•
피어링은 만들었는데 라우팅 테이블을 안 넣어서 연결이 안 됨
◦
피어링은 연결일뿐이고 실제 트래픽이 흐르려면 각 VPC의 route table에 목적지 CIDR과 peering 타깃을 정확히 넣어야함
•
보안그룹 체인이 끊김 (ALB→ 타겟 그룹 →EC2)
◦
ALB SG 인바운드만 열어서는 안 되고, EC2 SG는 소스를 ALB SG로 받아야함
•
VPN과 사내 Wi-Fi 인바운드 누락으로 특정 사용자 층이 접속 불가
이런 류의 트러블슈팅이 반복적으로 발생했다. 모든 인프라들이 이동하고 생성되다보니 사전정리를 열심히 해둬도 놓치는 부분이 조금씩 발생했다.
마치며..
이번 작업을 하면서 Terraform을 왜 쓰는지 확실히 알게 됐다. 누군가 콘솔에서 조용히 설정을 바꿔버리면 변경 사실을 놓치기 쉽고, 실수로 잘못 클릭해 중요 리소스를 삭제하는 사고도 날 수 있다.
반면 Atlantis를 통해 작업하면 변경이 Git PR로 남고 코드 리뷰도 가능해서, 어떤 값이 언제/왜 바뀌었는지 추적이 된다. 무엇보다 문제가 생겼을 때 원하는 상태로 한 번에 되돌리거나, 동일한 구성을 다시 재현할 수 있어서 운영/장애 대응 측면에서 엄청난 장점이 있다.
또 하나는 네트워크 공부가 정말 많이 됐다는 것. 이번에 직접 피어링/라우팅/보안그룹 만지면서 이론적으로 얼핏 알고 있던 개념들을 실무로 재정리 할 수 있었다.