[DevOps 실무] 인프라 관리의 핵심 결정 요소: Scale 전략, Tenancy 모델, 호스팅 위치 비교 분석

1. 서비스 사용량 증가에 따른 부하 해소 방법 - Scale Up, Scale Out

서비스 사용량 증가에 따른 부하 해소 방법은 크게 Scale Up, Scale Out 2가지로 나뉩니다.

 

Scale Up은 서버, DB 인스턴스의 성능을 업그레이드 해서 부하를 해소하는 방법입니다.

• AWS에서 인스턴스 유형을 small에서 large로 올려본 적 있으신가요? 그것이 Scale Up입니다.

Scale Up을 통한 서버 부하 해소

서비스 구조, 인프라의 변경 없이 높은 성능으로 업그레이드 하면 되어 적용하기가 쉬운 편입니다.

하지만 인스턴스의 성능을 무한정 업그레이드 할 수는 없기 때문에 한계도 명확한 방법입니다.

반면 Scale Out은 서버, DB 인스턴스의 성능은 그대로 두고 개수를 늘려서 부하를 해소하는 방법입니다.

• AWS에서 EC2의 Auto Scaling Group 사용한 적 있으신가요? 대표적인 Scale Out입니다.

Scale Out을 통한 서버 부하 해소

Scale Out이 잘 동작하기 위해서는 무중단배포도 같이 이뤄져야 하는데 통신 방법, 서버 인스턴스 관리 방법을 서비스 설계 단계부터 고민해야 합니다.

그렇지 않으면 [Amazon ECS] 무중단 배포 이뤄내기 - 제발 장기 실행 태스크(long running tasks)는 만들지 마세요...과 같은 고생길이 열릴 수 있습니다 ㅜ

 

2. 인스턴스 관리 방식 - Single Tenancy, Multi Tenancy

인스턴스 관리 방식은 크게 2가지로 나눌 수 있습니다.

1. 고객 별로 독립적인 인스턴스를 제공하는 Single Tenancy
2. 여러 고객이 같은 인스턴스를 사용할 수 있는 Multi Tenancy

Single Tenancy VS Multi Tenancy

 

Single Tenancy

• 장점
  • 고객마다 독릭접인 인스턴스가 제공되기 때문에 보안 문제, 성능 문제(Noisy Neighbor)가 적습니다.
  • 인스턴스를 사용하는 고객이 적다보니 배포, 중단 등의 서비스 제어가 쉬운 편입니다.
• 단점
  • 관리해야 할 인스턴스가 많아 적절한 모니터링 시스템이 필요합니다.
  • 인스턴스가 많아짐에 따라 비용도 많이 지출하게 됩니다.

Multi Tenancy

• 장점
  • 여러 고객이 같은 인스턴스를 사용하기 때문에 비용이 적게 지출됩니다.
  • Single Tenancy와 비교해서 인스턴스 수가 적어서 관리 비용이 저렴한 편입니다.
• 단점
  • 특정 고객사의 부하가 다른 고객사의 서비스 사용 품질을 저하시킬 수 있습니다.
  • 인스턴스를 사용하는 고객이 많다 보니 배포, 중단 등의 서비스 제어가 어렵습니다.

Single Tenancy, Multi Tenancy 각각의 장단점이 있습니다.

그리고 어떤 고객 서비스 안전성을 이유로 Single Tenancy를 요청할 때가 있고

어떤 고객은 비용을 이유로 Multi Tenancy를 요청하는 경우도 있습니다.

 

결국에는 두가지 방법 모두 지원할 수 있도록 시스템을 설계하는 것이 필요하죠...ㅎㅎ

3.  호스팅 위치 - cloud, on-premise

비용 얘기까지 나오니 호스팅 위치를 언급하지 않을 수 없었습니다.

 

요즘 정말 많은 서비스들이 AWS, Azure, GCP와 같은 cloud 서비스에서 개발되고 있습니다.

바로 복잡하고 많은 지식을 요구하는 인프라 관리의 비용을 덜 수 있기 때문입니다.

 

하지만 클라우드 서비스가 인프라를 대신 관리해주는 비용은 생각보다 비쌉니다...

연 단위로 클라우드 서비스를 사용하다보면 그 액수에 깜짝 놀라게 됩니다... ㅜ

• 각 조직 간의 원활한 업무 진행을 위해서 개발 스테이지, 테스트 스테이지가 있다면 비용은 더 불어납니다

비용 절감 방법을 찾아보게 되고, 더 나아가서는 on-premise로 대체할 수 없는지 고민하게 됩니다 ㅋㅋㅋ

cloud 서비스 사용과 on-premise의 장단점은 꽤나 명확합니다.

 

cloud 서비스 사용

• 장점
  • 인프라 관리를 클라우드 서비스에서 대신 해줍니다.
  • 모든 인스턴스들을 클라우드에서 관리할 수 있습니다.
• 단점
  • 몇 년만 지나도 on-premise보다 비싼 비용을 지불해야 합니다.
  • 네트워크 통신이 원활해야 한다는 조건이 붙습니다.

on-premise

• 장점
  • 장기적으로 봤을 때 cloud 서비스보다 비용이 저렴합니다.
  • 네트워크 통신 문제를 비교적 해결하기 쉽습니다(현장에 AP 추가 설치).
• 단점
  • 인프라를 관리할 수 있는 인력이 필요합니다.
  • 각 현장마다 배포된 인스턴스들을 통합 관리할 수 있는 시스템이 필요합니다.
  • 현장의 문제(대표적으로 정전)이 발생할 시 서비스

 

4. 만약 지금 서비스를 개발한다면 인스턴스들을 어떻게 관리할 거에요?

지금 서비스를 새롭게 개발하고 인스턴스들을 어떻게 관리할지 고를 수 있다면...

 

저는 Scale Out을 고려해서 Single Tenancy + on-premise 형태로 인스턴스들을 관리할 것 같습니다.

1) 성능 부하, 버그로 인한 에러 파급력을 낮추고 싶고 2) cloud 서비스의 비싼 비용을 절약하고 싶기 때문입니다.
(Scale Up을 통해서 처리할 수 있는 부하를 파악하는 것은 기본으로 깔고 갑니다...!)

 

• 제가 트위니에서 경험해봤던 인스턴스 관리 방식의 단점들을 피하고자 새로운 방법을 시도하고 싶은 걸지두...
• 박완서 작가님이 쓰신 '못 가본 길이 더 아름답다'처럼 그저 제가 경험해보지 못했기에 더 좋아보이는 걸지두ㅋㅋㅋ

여러분은 어떻게 서비스 인스턴스들을 관리하고 있으신가요?