이야기는 돌고 돌아 시작한다.
당신은 AWS 월드에 살고 있다. 처음에는 땅 소유의 개념이 없어 극악무도한 세상의 위험에 노출되어있다. 마치 드넓은 평지 중앙에 서서 어디에서 접근할지 모르는 대상으로 부터 위협을 느끼고 있다.
VPC를 허하노라
AWS 월드에 새로운 통치자가 나타나 "주민들의 사유지"를 인정해주기로 약속을 했다. 이 약속을 VPC라고 불러본다. VPC에는 다음과 같은 규칙을 함께 한다 (순서에 주의) :
- 사유지 내의 구획 나누기 (서브넷)
- 분양 받은 사유지 내에 담장을 쳐서 여러 구획으로 나눌 수 있음 (서브넷)
- 교통 규칙 설정 (라우팅 테이블)
- 각 구획(서브넷)의 트래픽이 어디로 가야할지 교통 규칙을 직접 만듬
- 예)
- 퍼블릭 구획(서브넷) : 외부 도로(인터넷)와 직접 연결된 정문(인터넷 게이트웨이)이 있는 구획
- 프라이빗 구획(서브넷) : 외부와 차단된 안전한 내부 구획. 후문(NAT 게이트웨이)를 통해서만 밖으로 나감
- 나만이 주소(IP) 체계 설정
- 내 사유지 안에서는 어떤 주소(IP 대역)를 사용할지 직접 결정
- 다른 사람의 사유지와 이 주소가 겹쳐도 전혀 상관 없음 (격리)
- 사유지로 출입 통제 (보안 그룹, NACL)
- 각 건물(인스턴스)의 출입문과 각 구획(서브넷)의 경계선에 누가 드나들 수 있는지 철저히 통제
AWS 월드의 통치자에게 외화 달러를 지불하고 나만의 사유지(VPC)를 구성했다. 구획을 나누고 프라이빗한 깊숙한 곳에 소중한 보물(애플리케이션, 데이터베이스)들을 가득 채워넣었다. 튼튼한 담장과 성벽(보안 그룹, NACL)을 구축하여 외부의 위협으로 부터 나를 지킬 수 있을것 같다.
치명적인 문제
하지만, 예상치 못한 치명적인 문제가 발생했다.
성 안의 보물들을 점검하고 관리해야 하는 이 땅의 주인이자 설계자인 나 자신조차 이 프라이빗한 공간에 들어갈 방법이 없어진 것이다. 너무나 완벽하게 외부 도로(인터넷 게이트웨이)와의 연결을 차단한 나머지, 내가 들어갈 길마저 사라져 버렸다.
이 아이러니한 딜레마를 어떻게 해결해야 할까? 외부의 위협은 완벽하게 막아내면서, 오직 허가된 나만이 안전하게 내부로 들어갈 수 있는 특별한 장치가 필요하다.
여기서 우리는 역사 속 요새 건축가들의 지혜를 빌려온다. 그들은 성벽보다 더 바깥쪽, 즉 가장 위험한 최전선에 특별한 구조물을 세웠다. 적의 공격을 가장 먼저 온몸으로 받아내면서, 동시에 성 내부로 통하는 안전한 경로를 확보하는 강력한 방어 거점. 바로 배스천(Bastion)이다.
우리의 VPC 설계에서도 이와 동일한 전략을 사용한다. 가장 위험한 곳, 즉 인터넷과 직접 맞닿아 있는 퍼블릭 구획(서브넷)에 특별한 서버를 하나 세운다. 이 서버는 해커들의 공격을 막아낼 최전방 요새이자, 관리자인 우리가 내부로 진입하기 위한 유일한 교두보가 된다.
이것이 바로 배스천 호스트(Bastion Host)다.
배스천 호스트(Bastion Host)
배스천 호스트는 역사 속 배스천처럼, 그 아키텍처에서 가장 강력하게 보안이 강화된(Hardened) 지점이어야 한다. 불필요한 모든 문(포트)은 닫아 잠그고, 오직 우리의 신원을 확인할 수 있는 암호(SSH Key)를 가진 사람만이 이 요새의 문을 통과할 수 있다.
일단 이 안전한 배스천 요새 안에 발을 들여놓으면, 우리는 비로소 그곳을 경유하여 프라이빗 구획에 있는 우리의 소중한 자산들에게 안전하게 다가갈 수 있게 되는 것이다.
결국 배스천 호스트는 단순히 서버 한 대를 지칭하는 이름이 아니다. 그것은 가장 위험한 곳에 가장 강력한 방패를 둔다는 클라우드 보안의 핵심적인 전략(Strategy)이자 철학(Philosophy)이다.
우리가 VPC라는 나만의 영토를 얻었을 때, 그 경계선을 어떻게 지킬 것인지에 대한 가장 첫 번째 대답이 바로 배스천 호스트 아키텍처인 셈이다. 이 최전방의 작은 요새 하나가, 그 뒤에 있는 광활한 프라이빗 왕국의 평화와 안전을 보장하는 첫걸음이 된다. 다음에 당신이 VPC를 설계할 때, 첫 번째 배스천은 어디에 얼마나 튼튼하게 세울지 고민해야한다.
실무에서의 활용
최근 우리 서버의 메모리 사용량이 배포 이후에 점차 증가하면서 특정 인스턴스의 메모리가 굉장히 높게 유지되는 현상(메모리 누수)을 확인했다. 지연 로딩으로 인해 점차 메모리가 증가하는 것은 이해할 수 있지만 GC가 수행되어도 제거되지 않는 메모리들의 원인을 파악해보고 싶었다.
간단한 방법은 인스턴스를 OS레벨로 접근해서 힙덤프를 하고 해당 파일들을 나의 로컬로 전송하여 분석하는 방법이다. 여기서 들었던 의문점은 "어떻게 OS레벨에 접근하고 이 파일을 나의 로컬로 가져올것인가?" 였다.
[방법1] 배스천 호스트 사용
여기에서의 전통적인 해결책은 배스천 호스트를 이용해서 OS 쉘에 접근하는것이다. 아래는 Gemini를 제시한 방법을 첨부하였다.
사전 준비 사항 :
실행 단계 :
[방법2] AWS System Manager (SSM) Session Manager 사용
다음은 AWS환경에서 권장되는 방법으로 SSH 키나 배스천 호스트 구성없이, IAM 권한만으로 안전하게 접속하여 작업을 수행할 수 있는 방법이다:
사전 준비 사항 :
실행 단계 :
마무리
메모리 누수와 같은 까다로운 이슈는 개발자의 로컬 환경에서 해결하기란 거의 불가능에 가깝다. 실제 운영 환경의 복잡한 트래픽과 데이터 속에서만 드러나는 문제를 재현하기 어렵기 때문이다. 바로 프로덕션 서버에서 진행해야 한다.
이 글에서는 그 프로덕션 서버가 올라가 있는 EC2 인스턴스의 OS 레벨로 접근하기 위한 통로, 배스천 호스트를 이해하기 위해 VPC라는 개념부터 이해하였다.
힙 덤프는 실행 순간의 메모리 상태를 그대로 스냅샷으로 만들어 복제하는 강력한 도구이지만, 그만큼 신중하게 다뤄야 한다. 덤프 파일은 애플리키에션이 사용하는 메모리 크기만큼, 때로는 수십 기가바이트(GB)에 달하는 거대한 파일로 생성되기 때문이다. 이 작업이 실행되는 동안 애플리케이션의 성능에 영향을 줄 수 있으며, EC2 인스턴스의 디스크 공간을 순식간에 고갈시킬 수도 있다.
그래서 다음과 같은 계획을 세우고 있다 :
- 리허설은 필수 : 먼저 운영 환경과 최대한 유사하게 구성된 스테이징 서버에서 힙덤프 생성 및 전송 과정을 여러 번 테스트하며 전체 소요시간과 시스템 부하를 측정한다.
- D-Day는 새벽에 : 실제 운영 환경에서의 작업은 사용자가 가장 적은 새벽 시간대를 D-Day로 잡는다. 예상치 못한 문제가 발생하더라도 서비스 영향을 최소화하기 위함이다.
이 처럼 클라우드 아키텍처를 이해하는 것은 단순히 서비스의 기능을 아는 것을 넘어, 실제 장애 상황에서 어떤 도구를, 언제, 그리고 '어떻게' 안전하게 사용할 것인지 계획해야한다.
레퍼런스
- How to Record SSH Sessions Established Through a Bastion Host | Nicolas Malaval (2016, AWS Blog)
