[DevOps 실무] 클라우드 vs 온프레미스: 인프라 관리 전략 비교 (Multi/Single Tenancy 장단점 분석)

이전에 인프라 관리의 핵심 결정 요소들을 공부했습니다.
다음 단계로 각각의 요소들을 혼합해서 인프라를 관리 방안을 구상하고 장단점과 조직에 필요한 기술 및 인력을 알아보겠습니다.

 

제가 준비한 인프라 관리 방안은 다음과 같습니다.

1. Multi Tenancy + Cloud Hosting
2. Single Tenancy + Cloud Hosting
3. Single Tenancy + On-premise Hosting

이제부터 각 방안들을 알아볼까요?

---

1. Multi Tenancy + Cloud Hosting

많은 SaaS가 차용하고 있는 Multi Tenancy + Cloud Hosting 방식의 장단점은 다음과 같습니다.

장점

• 저렴한 비용: 모든 사용자가 동일한 인프라를 공유하므로 서버 비용이 절감됩니다.
• 빠른 배포 속도: Single Tenancy에 비교해서 배포 대상인 인프라 수가 적어서 비교적 배포가 빠릅니다.
• 유지보수 용이: 관리해야 할 형상, 인스턴스가 한정되어 있기 때문에 적은 인원으로 빠르게 인프라 문제에 대응할 수 있습니다.

단점

• 데이터 격리 문제: 악의적인 사용자가 다른 사용자의 정보에 접근하지 못하도록 막아야 합니다.
• Noisy Neighbor 문제: 특정 사용자의 과도한 요청이 다른 사용자의 서비스 품질을 저해하는 현상을 막아야 합니다.
• 커스터마이징의 어려움: 동일한 SW를 사용하기 때문에 고객사 별로 다른 요구사항을 충족시키기 어렵습니다.
• 개인정보보호 문제: EU의 경우 GDPR, 미국은 주 별로 다른 개인정보보호 법제를 준수해야 합니다.

위의 단점들을 극복하기 위해 다음과 같은 해결책을 고려할 수 있습니다.

단점	해결책
데이터 격리 문제	1. 사용자 별로 데이터의 접근 권한을 설정할 수 있는 접근 권한 제어 모델을 사용합니다.     - ABAC, RBAC 2. 암호화를 통해 인증된 사용자만 데이터를 읽을 수 있도록 합니다.
Noisy Neighbor 문제	1. 사용자 별로 서버 인스턴스의 CPU/메모리 사용량을 제한할 수 있는 기능을 제공합니다.     - DB 샤딩, 사용자 별 인스턴스 할당, 컨테이너를 이용한 사용자 격리 2. 갑작스럽게 요청량이 급증했을 때를 대비해서 오토 스케일링 기술을 준비합니다.
커스터마이징의 어려움	설정값을 통해서 사용자 별로 다른 UI, 기능을 제공할 수 있도록 서비스를 설계합니다.
개인정보보호 문제	사용자에 따라서 데이터 저장 장소와 방식을 다르게 설정할 수 있도록 서비스를 설계합니다.

 

조직이 갖춰야 할 역량

• 여러 기술적인 문제들을 해결할 수 있는 역량을 가진 서비스 개발 부서
• 서비스의 이슈를 미리 파악할 수 있도록 충분한 테스트 수행 및 대응 방안 마련

해결책들을 보시면 주로 서비스에 기능을 추가하거나 설계에 녹여야 하는 것들입니다.

문제 해결을 위해서는 서비스 개발 부서의 기술적인 역량이 필요한 것이죠.

 

그렇다고 모든 문제를 해결해야만 서비스를 출시할 수 있는 것은 아닙니다.

발생 가능한 문제를 미리 식별하고 어떻게 대응할지 준비할 수 있다면 더 이상 문제가 아닙니다.

 

만약 서비스 개발 부서의 자원이 충분하지 않은 상황에서 위의 문제들을 겪고 있다면 2, 3 방안을 고민해 볼 수 있을 것 같습니다.

 

2. Single Tenancy + Cloud Hosting

Single Tenancy + Cloud Hosting 방식의 장단점은 다음과 같습니다.

 

장점

• 완전한 데이터 격리: 사용자 별로 다른 인스턴스가 배정되기 때문에 다른 사용자의 데이터에 접근할 수 없습니다.
• Noisy Neighbor 문제 해결: 다른 사용자로 인해 서비스 품질이 저해될 일이 없습니다.
• 커스터마이징 용이: (비교적) 사용자 별로 형상을 다르게 관리하기 쉽습니다.
• 개인정보보호 규제 준수 용이: 사용자 별로 데이터 저장 장소와 방식이 다르기 때문에 규제 준수가 용이합니다.

 

단점

• 비싼 비용: 서비스 운영을 위해 필요한 인스턴스 수가 많아지다 보니 서버 비용이 늘어납니다.
• 유지보수 복잡도 증가: 관리해야 할 인스턴스 수가 많기 때문에 다.
• 느린 배포 속도: Multi Tenancy에 비해서 배포해야 하는 인스턴스 수가 많다보니 배포 속도가 느립니다. 버전 분기 문제로도 이어질 수 있습니다.
• +++CSP 차원의 한계: CSP도 인스턴스를 무한정 제공할 수는 없습니다. 어느 순간이 오면 Single Tenancy 체제를 유지하는 것이 불가능할 수 있습니다.

위의 단점들을 극복하기 위해 다음과 같은 해결책을 고려할 수 있습니다.

단점	해결책
비싼 비용	해결할 수 없습니다 ㅜ
유지보수 복잡도 증가	1. Infra as Code(IaC) 도구를 활용해서 인프라를 체계적으로 관리합니다. 2. 여러 인스턴스에 분산되어 있는 로그, 메트릭을 통합 관리합니다.     - Prometheus + Thanos ✔ 높은 숙련도의 인프라 관리 기술을 요구하게 되어 SRE 팀이나 DevOps 팀이 필요해집니다.
느린 배포 속도	Kubernetes와 같은 오케스트레이션 도구와 CI/CD 도구를 적극적으로 활용합니다.     - Jenkins, OpenShift

 

조직에서 갖춰야 할 역량

• 방대해지는 인프라를 효율적으로 관리할 수 있는 SRE/DevOps팀
• 빠른 대응을 위한 on-call 제도 도입 및 체계 마련

 

서비스 개발 부서 입장에서 데이터 격리 문제, Noisy Neighbor 문제의 우선 순위가 낮아지기 때문에 다른 비즈니스 요구사항 만족에 집중할 수 있습니다.

 

하지만 관리해야 할 인프라가 많아지다보니 서비스 개발 부서에서 모두 대응하기 어려워집니다.

인프라를 전문적으로 관리할 수 있는 인력이 필요해지는 것이죠.

 

빠른 이슈 대응을 위해서는 서비스 개발 부서가 인프라 관리 부서의 소통이 긴밀하게 이뤄져야 합니다.

on-call 제도를 도입하는 등의 체계 마련이 필요합니다.

3. Single Tenancy + On-premise Hosting

Single Tenancy + On-premise Hosting 방식의 장단점은 다음과 같습니다.

 

장점

• 높은 자유도를 가진 인프라 설계: 서버 컴퓨터를 원하는 성능으로 맞출 수 있고, 필요하다면 네트워크 토폴로지도 설계할 수 있습니다.
• Noisy Neighbor 문제 해결: 다른 사용자로 인해 서비스 품질이 저해될 일이 없습니다.
• 장기적 비용 절감: 클라우드 서비스 사용료가 없기 때문에 시간이 지날수록 비용이 절감되는 효과가 있습니다.
• 물리적 데이터 격리: 데이터가 현장에 저장되기 때문에 개인정보 보호 규제로부터 자유롭습니다.

 

단점

• 초기 인프라 구축 비용: 서버 컴퓨터를 현장에 설치해야 하고, 현장의 네트워크 정책도 이해해야 합니다.
• 매우 높은 유지보수 복잡도: Single Tenancy라서 유지보수가 어려운 것에 더하여, 현장에서만 조치할 수 있는 문제들도 발생합니다.
• 매우 느린 배포 속도: 인프라가 현장에 있다보니 서비스 배포 속도가 더욱 느려집니다.

단점	해결책
초기 구축 비용	1. 컨테이너를 이용해서 서비스를 패키징하여 쉽게 설치할 수 있도록 합니다. 2. 현장 네트워크 정책에 알맞게 서버를 설치합니다. ✔ 높은 수준의 인프라 지식이 필요해집니다.
매우 높은 유지보수 복잡도	1. 원격으로 접속할 수 있는 프록시 서버와 정전이 나더라도 대응할 수 있는 백업 전원 장치를 준비합니다. 2. 여러 현장에 분산되어 있는 서버 컴퓨터들을 통합 관리합니다.     - AWS Systems Manager ✔ 다양한 문제에 대응할 수 있는 높은 숙련도의 필드 엔지니어팀이 필요해집니다.
느린 배포 속도	여러 현장의 서비스 배포 주기를 체계적으로 관리합니다.     - ex) 버전 분기 문제를 최소화 하기 위해 새로운 버전이 배포될 시 2주 이내에 모든 현장에 배포합니다.

 

조직에서 갖춰야 할 역량

• 방대해지는 인프라를 효율적으로 관리할 수 있는 SRE/DevOps팀
• 빠른 대응을 위한 on-call 제도 도입 및 체계 마련
• 현장에서 발생하는 인프라 문제에 대응할 수 있는 시스템 엔지니어팀 혹은 높은 숙련도의 필드 엔지니어팀

장기적인 비용 절감 효과를 누리기 위해서는 인프라 및 현장 대응을 위해 추가된 부서가 가성비 높게 동작해야 합니다.

• 자칫하면 클라우드 비용보다 인건비를 더 많이 지불해야 할 수도 있습니다.

4. 무엇을 선택해야 하죠?

사실 1, 2, 3 방안은 상호배타적인 방식이 아닙니다.

 

1을 선택했더라도 나중에 2, 3이 필요해지면 2, 3을 선택할 수 있습니다.

혹은 특정 기능에 대해서만 Single Tenancy와 On-premise 호스팅을 적용할 수도 있습니다.

• 모든 것은 trade-off라는 점을 명심합시다!

 

다만 내가 속한 조직이 각 방식의 단점들을 극복하고 장점들을 취할 수 있는지가 중요합니다.

 

예를 들어서 서비스 개발팀의 리소스가 부족한 상황에서 SRE/DevOps팀의 리소스가 충분하다면 2안이 좋을 선택일 수 있습니다.

만약 조직의 SRE/DevOps팀과 필드 엔지니어팀의 리소스가 모두 충분하다면 3안도 좋은 선택이 됩니다.

 

그렇지만 단순히 클라우드 서비스 비용이 너무 비싸서, Noisy Neighbor 문제를 해결하기 어려워서 2안과 3안을 선택한다면...

• 도망쳐서 도착한 곳에 낙원이란 있을 수 없는 거야 - 베르세르크

 

+++ 기본적으로 버그는 해결된 상태로 배포되어야 합니다

혹시 서비스 버그가 퍼지는 것을 막기 위해서 Single Tenancy 혹은 On-premise를 고민하셨나요?

• 저는 그랬거든요…

서비스 버그는 그 자체로 문제인 것 입니다.

Tenancy나 호스팅 위치는 서비스 버그 문제를 해결하는데 큰 도움이 되지 않습니다.

 

Single Tenancy, On-premise를 적용한 상황에서 심각한 버그가 발생한다면 오히려 대응이 어려워질 것입니다.

• Single Tenancy라서 핫픽스를 적용하기 위해서는 여러 인스턴스들을 대상으로 배포가 이뤄져야 합니다.
• on-premise 환경이기 때문에 여러 문제로 핫픽스가 정상적으로 이뤄지지 않을 수도 있습니다.

🎁 함께 보면 좋은 글들 🎁

• [DevOps 실무] 인프라 관리의 핵심 결정 요소: Scale 전략, Tenancy 모델, 호스팅 위치 비교 분석
• CI/CD 툴이 뭘까? - 주니어 개발자의 오해
• terraform 리뷰 - terraform 진짜 쓸만한가...?