[Cloud] 멀티테넌시(Multi-tenancy) 이해하기

멀티테넌시, 아파트에 비유하면

퍼블릭 클라우드가 왜 저렴한지 궁금했던 적 있는가? 그 답의 상당 부분은 멀티테넌시(Multi-tenancy)에 있다.

 

아파트를 떠올려보자. 한 건물 안에 여러 세대(테넌트, tenant)가 산다. 건물, 배관, 엘리베이터 같은 공용 자원은 다 같이 쓰지만, 각 세대는 자기 집 안을 남이 들여다볼 수 없고 남이 마음대로 들어올 수도 없다. 퍼블릭 클라우드의 멀티테넌시도 똑같은 구조다.

 

AWS나 Azure 같은 업체의 물리 서버 한 대 위에 여러 고객(테넌트)의 가상 자원이 함께 올라가지만, 각 고객은 논리적으로 완전히 분리된 자기만의 공간을 쓴다.

---

왜 이렇게 만들었을까 — 비용 효율

고객마다 서버를 통째로 하나씩 내주면 어떻게 될까? 자원을 10%밖에 못 쓰는 고객도 서버 값을 100% 다 내야 한다. 반면 여러 고객이 물리 서버 하나를 나눠 쓰면 자원 활용률이 훨씬 올라가고, 그만큼 아낀 비용을 고객에게 저렴한 가격으로 돌려줄 수 있다.

 

클라우드가 온프레미스보다 싼 이유의 큰 부분이 바로 이 구조에서 나온다.

---

격리가 완벽하지 않으면 생기는 문제

Noisy Neighbor — 시끄러운 이웃 문제

 

아파트 옆집이 밤새 시끄럽게 파티를 하면 내 방까지 영향을 받는 것처럼, 같은 물리 서버를 쓰는 다른 테넌트가 CPU나 네트워크 자원을 갑자기 왕창 써버리면 내 서비스 성능까지 덩달아 떨어질 수 있다.

 

이걸 Noisy Neighbor 문제라고 부른다. 분명 내 자원 사용량은 그대로인데 응답 속도가 느려진다면, 옆집(다른 테넌트)이 소란을 피우고 있을 가능성이 있다.

---

격리 기술 자체의 결함이 낳는 보안 이슈

 

격리는 소프트웨어(하이퍼바이저)로 이뤄지는데, 이 격리 기술에 허점이 있으면 이론적으로 다른 테넌트의 데이터를 몰래 들여다볼 수 있는 통로가 생길 수 있다.

 

실제로 2018년에 알려진 Meltdown과 Spectre 취약점이 이 문제를 세상에 알린 대표 사례다. CPU 하드웨어 자체의 설계 결함 때문에, 이론적으로는 같은 물리 서버를 공유하는 다른 가상 머신의 메모리 내용을 엿볼 수 있는 가능성이 발견됐다. 전 세계 클라우드 업체들이 긴급하게 패치를 배포했을 만큼 파장이 컸던 사건이다.

 

이 사례는 "멀티테넌시의 보안 우려"가 막연한 걱정이 아니라 실제로 벌어질 수 있는 일임을 보여준 계기였다.

---

클라우드 업체는 어떻게 대응할까

 

이런 문제를 알기 때문에 클라우드 업체들은 격리 수준을 계속 강화해왔다. 하이퍼바이저 보안 패치는 기본이고, 더 높은 격리가 필요한 고객을 위해 물리 서버를 통째로 혼자 쓸 수 있는 전용 호스트(Dedicated Host) 옵션이나, 네트워크 수준에서 격리를 강화한 VPC(가상 사설 클라우드) 같은 선택지도 함께 제공한다.

 

즉 "무조건 싸게, 혹은 무조건 안전하게" 중 하나만 고르는 게 아니라, 상황에 따라 "이 정도 격리 수준이면 충분하다"를 직접 선택할 수 있게 만들어둔 것이다.

---

정리

멀티테넌시(Multi-tenancy) 는 아파트처럼 같은 건물(물리 자원)을 여러 세대(테넌트)가 나눠 쓰는 구조다. 덕분에 클라우드는 저렴해질 수 있었지만, 격리가 완벽하지 않으면 옆집 소음(Noisy Neighbor)이나 심하면 CPU 설계 결함(Meltdown/Spectre)처럼 실제 보안 사고로 이어질 수도 있다.

 

그래서 정말 민감한 데이터를 다룰 때는 전용 호스트처럼 격리 수준을 더 높인 옵션을 함께 고려하는 것이 실무에서의 합리적인 판단이다.