<< 1. 문제정의 >> 기존 클라우드 환경에서는 트래픽 증가에 따라 자동으로 자원을 확장하는 기술이 중요해지고 있습니다. AWS의 ASG(Auto Scailing Group)와 같은 VM 자동 프로비저닝 기술과 달리 OpenStack 환경에서는 이러한 자동화 기능이 부족했습니다. 따라서 저희는 OpenStack 기반 환경에서 VM 오토스케일링을 구현하고, 보안·모니터링·백업까지 포함한 실제 운영 가능한 클라우드 인프라 구축을 목표로 프로젝트를 진행했습니다.

<< 2. 아키텍처 >> 저희 팀의 클라우드 인프라 아키텍처에 대해 잠시 소개드리겠습니다.

이 아키텍쳐 그림은 draw.io 사이트를 통해 직접 설계하여 누구나 직관적으로 이해할 수 있도록 하였습니다. 첫 번째, 네트워크입니다. 팀 클로버에서는 제로티어 사설망 구축을 통해 네트워크를 구성하였는데, 제로티어 네트워크 대역을 서브네팅하여 퍼블릭과 프라이빗 대역으로 나누어 사용하였습니다. 퍼블릭은 vm 3대, 프라이빗은 vm 6대를 배치하여 사용하였습니다. 오픈스택은 VM 생성을 위한 내부 사설망을 추가하여 오픈스택 서버 내 사설망이 따로 존재하고, 백업에서는 AWS S3를 연결하여 최소한의 비용으로 어떤 상황에서도 데이터가 사라지지 않을 수 있도록 구성하였습니다.

두 번째, 외부 사용자 접근입니다. 외부 사용자는 수근 클라우드를 통하여, 접속하게 되는데, 클라우드플레어 터널을 통하여 보안관문을 들어오게 됩니다. 각각의 관문은 분산 서비스 공격, 특정 포트 차단, 무차별 대입공격, 기타 커스텀 룰셋을 통한 필터링 등등에 대한 로그를 수집하여 elk 스택에서 실시간 시각화 구축이 가능하도록 구현하였습니다. 실제 보안 테스트 과정은 데모영상에 이어서 설명드리겠습니다. 이후 외부 사용자는 haproxy서버의 간단한 L7 로드밸런싱으로 트래픽이 분산된 각각의 웹 노드에 접속합니다.

세 번째, 관리자 접근입니다. 내부 관리자는 성웅 클라우드를 통하여 접속하게 됩니다. 이때, cloudflare에서 관리자 전용 인증 허가를 받아 파이썬 웹 플라스크로 구성된 관리자 페이지에 들어오게 됩니다. 파이썬 웹 플라스크를 사용한 이유는 하나의 탭에서 다양한 대시보드 그리고, 실시간 헬스 체크와 같은 기능과 동작을 구현할 수 있기 때문입니다. 우선 오픈스택 탭입니다. 오픈스택은 새 탭으로 열리도록 구성했습니다. 오픈스택은 화면 구성이 복잡하고 넓은 작업 공간이 필요한 관리 페이지이기 때문에, 독립된 탭에서 사용하는 것이 더 효율적이라고 판단했습니다. 인스턴스와 네트워크를 볼 때 잠시 접속하여 확인하곤합니다. 다음으로, 그라파나에 노드익스포터 메트릭을 나타낸 대시보드에선 각 노드의 리소스를 확인할 수 있고, 마찬가지로 캐드바이저 메트릭을 시각화한 대시보드에선 컨테이너의 메모리사용량, CPU 모니터링 등을 확인할 수 있습니다. 외부 사용자 전용을 위한 키바나 대시보드 확인 또한 가능합니다. 그리고 민감정보를 보관하는 중앙처리 서버로는 하시코프 볼트를 사용하였습니다. 마지막으로, 미니오를 이용하여, 크론탭을 통해 도커 컨테이너를 백업하여 매일 오후 5시 50분마다 백업 파일을 저장하였고, 실제로 꺼내와서 다운로드 하는 것 또한 가능합니다. 실제 관리자페이지는 데모영상에 이어서 설명드리겠습니다.

<< 3. 오토스케일링 기능 >> 다음으로 저희 프로젝트의 핵심 기능인 VM 오토스케일링 기능에 대해 설명드리겠습니다. 기존 OpenStack 환경에서는 사용자가 직접 인스턴스를 생성하고 관리해야 하기 때문에, 트래픽 증가 상황에 대한 빠른 대응이 어려웠습니다. 저희는 이를 개선하기 위해 메트릭 모니터링 기반의 오토스케일링 구조를 구현하였습니다. 먼저 Prometheus는 Node Exporter와 cAdvisor를 통해 노드와 내부 컨테이너의 메트릭을 수집하고, Pull 방식을 통해 시계열 데이터베이스에 저장합니다. rule.yml 파일에 설정한 수치를 초과하면 Alertmanager가 Discord Bot으로 알림을 전달합니다. 알림 발생 후 Cooldown 상태와 현재 인스턴스 상태를 확인하고, 클라우드 서버 내 조건 충족 시 Ansible Playbook을 실행합니다. 그 후 오픈스택 API는 reconsile.yml 파일을 통해 VM 생성, Floating IP 할당과 Cloud-init 기반 초기 설정을 통해 도커 설치와 Docker Swarm Worker Join까지의 과정을 자동으로 수행합니다.
저희는 또한 반복적인 요청에 불필요한 VM을 중복하여 생성하지 않도록 구현했습니다. 이렇게 생성된 VM은 HAProxy를 통해 증가한 트래픽을 분산 처리합니다. 실제 동작 과정은 데모 영상에서 보여드리겠습니다.

<< 데모영상 실행 >> (((영상))) [데모영상-관리자페이지] 내부 관리자를 위한 관리자페이지인 성웅클라우드로 접속해보겠습니다. 모든 VM을 실시간으로 헬스체크하여 조회를 할 수 있는데요. 새로고침을 통해서도 볼 수 있습니다. 이외 최근 접속 유저, 실시간 접속 로그 또한 확인 가능합니다. 이름은 admin, 복사해둔 비밀번호를 가져오겠습니다. 호라이즌 대시보드입니다. 인스턴스에 관한 간략한 요약 정보 등이 있구요. 네트워크토폴로지의 어떠한 라우터에 즉, 서버 내 사설망에 하나의 인스턴스가 등록되어있는 모습을 확인할 수 있습니다. 자세히 보기를 눌러보겠습니다. 오전 8시 5분에 생성된 인스턴스인데요, 디스코드 알람을 보니 생성시간과 거의 일치한 오전 8시 5분에 알람이 보이네요. 다음은 모니터링에 관하여 간략하게 말씀드리겠습니다. 노드익스포터를 사용했습니다. 웹서버는 노드01과 02 2가지입니다. cpu사용량, 대기열 큐에 관한 내용이네요. 이번엔 캐드바이저입니다. 메모리 사용량, cpu사용량 등이 보입니다. RX, TX에 대해서도 조회가 가능합니다. 외부사용자 접근 시 보안에 관한 7월 10일 키바나 대시보드 자료입니다. 관문 유형별 퍼센트 원형 파이그래프와 로그 유형별 개수 막대 그래프와, 누가 가장 많이 접속하였는지에 관한 top5 ip조회 등 3가지 자료를 준비해보았습니다. 다음은 하시코프 볼트입니다. 어떠한 민감정보를 한 서버에 모두 보관하는 용도로 사용합니다. 예를 들어서, 어떤 토큰 혹은 API 값 등을 조회할 수 있습니다. 마지막으로 미니오입니다. 7월 3일부터 매일 오후 5시 50분마다 주기적으로 미니오 백업 서버에 컨테이너 파일을 저장하여 보관하고 있습니다.

[데모영상-백업테스트] 다음으로 백업 및 재해복구 구성에 대해 설명드리겠습니다. 먼저 Docker Swarm으로 운영되는 각 노드의 데이터를 안정적으로 관리하기 위해 NFS 기반 공유 스토리지를 구성하였습니다. 각 Worker Node는 Storage 서버의 NFS 공유 폴더를 마운트하여 동일한 데이터를 바라보도록 구성하였고, 이를 통해 노드별 데이터 불일치를 방지하고 중앙 관리가 가능하도록 하였습니다. 이후 저장된 데이터는 자동화 스크립트를 통해 압축 후 MinIO Object Storage에 업로드됩니다.

MinIO를 사용한 이유는 객체 기반 저장 방식으로 파일 검색과 관리가 용이하고, GUI 환경을 통해 백업 데이터를 쉽게 확인할 수 있기 때문입니다. 마지막으로 MinIO의 데이터를 AWS S3로 전달하여 외부 저장소에 이중 백업을 구성하였습니다. NFS와 MinIO는 동일한 ZeroTier 네트워크 내부에 존재하기 때문에, 네트워크 장애 상황까지 고려하여 별도의 AWS S3에 백업본을 보관하도록 설계했습니다. 전체 백업 과정은 스크립트와 Cron Job을 통해 매일 오후 5시 50분 자동 실행되도록 구현하였습니다.

[데모영상-보안테스트]

1관문입니다. k6를 이용해 UFW 방화벽에 10초 동안 최대 500명의 가상 사용자가 접속하는 부하 테스트를 수행했습니다. 총 2만 1천여 건의 요청이 모두 정상 처리되었고, 요청 성공률 100%, 실패율 0%를 기록하여 부하 상황에서도 안정적으로 동작함을 확인했습니다."

2관문입니다. fail2ban을 통해 비밀번호를 3번 틀리면, 영상과 같이 밴을 당합니다. 연결할 수 없게 됩니다. Rate Limit은 일정 시간 동안 허용되는 요청 수를 제한하여, 브루트포스 무차별 대입을 방어합니다. 밴 타임은 1시간이며, 로그 보여드리면서 넘어가겠습니다.

3관문입니다. k6를 이용해 WAF 환경에서 최대 500명의 가상 사용자로 부하 테스트를 진행했습니다. 약 19,800건의 요청이 모두 정상 처리되었으며, 성공률은 100%, 실패율은 0%를 기록했습니다. sql 인젝션과 XSS 공격도 403차단하였습니다.

4관문입니다. 서버에서 일어나는 시스템 이벤트 등을 기록하는 auditd(오딧디) 프로그램입니다. 무단 변경을 추적할 수 있습니다.

[데모영상-오토스케일링]

k6으로 동시접속자 1500명이 3분 20초동안 방문해 있다고 가정하여, 부하테스트를 걸어보았습니다. 1500명이 다다를때쯤 실시간 메트릭 수집 결과가 변동하여, 왼쪽 상단 캐드바이저는 부하를 알리는 트래픽 그래프가 상승하기 시작하고, 오른쪽 상단 노드익스포터에서는 cpu는 28.2%, 대기열큐는 109%를 보입니다. 오른쪽하단의 알람 매니저에서는 이러한 정보가 pending 되어 5초 동안 cool down하며 기다리다가 node01, node02 두 곳에서 모두 CPU 사용률 20%가 초과되었다는 알람을 전송합니다. 다음은 오픈스택 서버입니다. 디스코드를 수신하는 중계 역할의 컨트롤 서버에서 앤서블 플레이북으로, 오픈스택 내의 쉘스크립트를 실행하여, 오픈스택 서버에서 VM 인스턴스를 생성하기 시작합니다. 자동화이므로 tail을 찍어 실시간 로그를 찍으며 조회하면, 다음과 같이 node-vm-01이 생성되는 과정을 알 수 있습니다. 자동으로 floating ip도 부여되고 cloud-init 또한 정상적으로 수행됩니다. 알람으로 전송된 cpu 부하 게이지는 20%정도이므로 플레이버 중에서 비교적 작은 worker-small보냅니다. docker service ls를 반복적으로 찍으며, 도커 컨테이너에서 node-vm-01이 내부적으로 swam join 되어 컨테이너에 편입된 것을 확인하였습니다. 이후 다시 왼쪽 상단 캐드바이저를 확인해보니 트래픽 그래프가 서서히 내려가며 오른쪽 상단 노드익스포터에서 CPU가 28.2%에서 1.5%로 감소하였고, 대기열큐는 109%에서 1.5%로 감소하였음을 확인할 수 있습니다. 이로써 오토스케일링 과정이 정상 작동함을 알 수 있었습니다.

<< 한계 >>

• 제공할 서비스의 보안(서버의 비밀번호 등등?)
• 제로티어의 네트워크의 딜레이?