Offcanvas

개발자 / 검색|인터넷 / 오픈소스 / 통신|네트워크

기고ㅣ있는지조차 모른다, ‘웹 스케일’ 문제 파악하고 해결하는 법

2022.11.18 Scott McCarty  |  InfoWorld
여기서는 웹 스케일(Web Scale) 문제의 기원과 진화, 웹 스케일 문제가 있는지 확인하는 방법, 컨테이너 오케스트레이션이 이러한 문제를 해결하는 가장 우아한 방법인 이유를 살펴본다. 
 
ⓒGetty Images Bank

필자는 축하 카드(Greeting card) 산업에서 웹 스케일 문제의 첫 번째 전조를 봤다. 약 100년 동안 미국의 축하 카드 회사들은 ‘선물과 함께 전달될, 우편으로 보내질 또는 냉장고에 붙여질’ 카드를 제작해 판매하면서 번창했다. 그러다가 1990년대 중반 모든 것이 바뀌었다. 월드 와이드 웹(World Wide Web)이 등장한 것이다. 이에 1996년 블루 마운틴(Blue Mountain), 아메리칸 그리팅스(American Greetings), 홀마크(Hallmark) 등은 모두 전자카드를 제공하기 위해 닷컴(Dot-com) 사이트를 개설했고, 디지털 전쟁이 뒤따랐다. 

필자는 축하 카드 산업에서 일했던 적이 있다. 밸렌타인데이, 어버이날, 크리스마스는 축하 카드 회사들의 대목이었고, 비즈니스가 온라인으로 이동했을 때도 이러한 기념일은 전자카드 시장의 전쟁터였다. 최신 웹 인프라를 구축하고 새로운 디지털 비즈니스를 성사시켜야 했다(오늘날 이를 디지털 트랜스포메이션이라 부른다).

처음에는 전자카드가 무료였다. 목표는 돈을 버는 게 아니라 사용자를 유인하는 것이었다. 닷컴에서는 수백만 명의 사용자가 기업 평가 측면에서 수백만 달러의 가치가 있었다. 한동안은 상황이 좋았다. 모두가 새로운 사용자를 유인했다. 하지만 머지않아 닷컴들은 실제로 돈을 벌어야 했다. 이로 인해 문제와 기회가 생겼다.

아메리칸그리팅스닷컴(AmericanGreetings.com)이 전자카드에 비용을 청구하기 시작하자 사용자들은 돈을 내고 싶지 않았기 때문에 홀마크닷컴(Hallmark.com)으로 몰려갔다. 홀마크는 증가한 트래픽을 감당하지 못하고 다운됐다. 사람들은 여전히 전자카드를 보내고 싶었기 때문에 아메리칸그리팅스닷컴으로 돌아가 요금을 지불하고 (전자카드를) 보냈다. 

이를 통해 무엇보다도 웹 스케일 트래픽뿐 아니라 예측할 수 없는 웹 스케일 트래픽을 처리할 수 있는 역량이 경쟁 우위로 부각됐다. 그리고 여기서 배울 수 있는 비즈니스 교훈은 웹 인프라가 수익 창출에 유리하게 작용할 수 있다는 점이었다.

웹 스케일 문제의 시작
이어 말하자면 소비자들은 전자상거래라는 아이디어에 관심을 갖기 시작했고, 소규모 인트라넷과 인터넷 사이트를 구동하는 서버들이 아무도 상상하지 못한 규모로 웹 기반 트랜잭션 처리를 수행해야 했다. 기존의 서버, 네트워크 장비, 스토리지 장치, 인터넷 파이프는 트래픽을 처리할 수 없었다. 웹에서 비즈니스를 수행하는 기업들에게 최초의 웹 스케일 문제가 발생했다. 

당시에는 이 문제를 해결할 수 있는 상용 솔루션이 없었기 때문에 닷컴들은 많은 시행착오와 엄청난 고통을 겪으며 자체 솔루션을 구축해야 했다. 유능한 시스템 관리자와 개발자가 소셜 커넥션을 통해 소통하면서 웹 스케일 문제를 해결하는 방법의 모범 사례가 산업 전반에 걸쳐 수집 및 확산됐다. 물론 모든 기업에 웹 스케일 문제가 있었던 것은 아니다. 대부분은 스타트업과 닷컴 기업이었다.

웹 스케일 문제의 주류화
기업들은 온프레미스, 클라우드, 엣지에서 그리고 여러 제공업체의 플랫폼에 분산된 시스템을 가지고 있다. 또한 고객들은 실시간 정보는 말할 것도 없고 더욱더 강력하고 개인화된 애플리케이션을 요구하고 있다. 웹 스케일 문제의 범위와 맥락이 바뀌었다. 그래서 많은 측면에서 이 문제를 확인하기가 훨씬 더 어려워졌다. 다음은 자신의 비즈니스에 웹 스케일 문제가 있는지 (그리고 실제로 그 문제가 얼마나 큰지) 판단하기 위해 확인해볼 수 있는 질문 목록이다.
 
(1) 수백 또는 수천 명의 사용자가 리소스를 구매 또는 소비할 뿐만 아니라 수십 또는 수백 명의 IT 전문가가 제공되는 서비스를 지원하고 있는 양면 시장이 있는가?
(2) 시스템 부하가 단기간에 급격하게 바뀔 수 있는 시나리오가 있는가?
(3) 활용률이 대부분 낮지만 가끔 폭증하는 수백 또는 수천 개의 서버가 있는가?
(4) 수천 또는 수백만 개의 소형 기기 또는 사용자로부터 생성되는 데이터를 수집하는가?
(5) 단일 기기의 용량을 크게 초과하는 워크로드가 있는가?
(6) 수백 또는 수천 개의 서비스 또는 마이크로서비스를 개발하고 있는가?

이 가운데 ‘그렇다’라고 답한 질문이 있는가? 아니면 앞으로 3~5년 안에 ‘그렇다’라고 답하리라 생각하는가?

웹 스케일 문제를 ‘우아하게’ 해결하기
아메리칸 그리팅스에서(그리고 몇 년 후 다른 곳에서) 필자는 비용이 적게 들면서도 단순한 소프트웨어로 웹 스케일 문제를 해결했다. 당시 필자의 팀은 큰 웹 사이트를 관리하기 위해 오픈소스와 자체 개발 솔루션을 복합적으로 사용했다. 리눅스, 아파치, 자체 개발한 CF엔진(CFEngine) 복제품 등을 사용하여 약 3명의 인력(요즘에는 대부분 사이트 안정성 엔지니어라고 부를 것이다)으로 1,000개 이상의 서버와 70개 이상의 애플리케이션을 관리할 수 있었다. 

이러한 도구는 (당시로서는) 훌륭하고 최첨단이었지만 클러스터, 네트워크 종점, 애플리케이션을 정의하는 데 사용한 상위 수준의 기본 요소는 모두 (팀에서) 쉽게 만든 것이었다. 웹 스케일 애플리케이션을 상상, 정의, 구축하는 표준 방법이 없었기 때문에 그렇게 해야 했다. 각 기업은 기본 요소를 발명해야 했고, 각 팀원은 시스템을 이해하고 새 애플리케이션을 개발하거나 고장 난 애플리케이션 문제를 해결하려면 이를 배워야 했다. 

초기 웹 스케일링은 초창기 컴퓨터와 유사했다. 윈도우 또는 리눅스를 사용하는 방법을 모른다면 콜로서스(COLOSSUS) 또는 에니악(ENIAC) 같은 특정 컴퓨터를 사용하는 방법은 알고 있었다. 웹 스케일 컴퓨팅 초기에는 기본 개념(네트워킹, 로드 밸런서, 스토리지, 웹 서버 등)이 적용되긴 했지만 기존의 지식을 이식하기가 쉽지 않았다.

아메리칸 그리팅스 이후 필자는 ISP 및 웹 개발 회사에서 근무하면서 서로 다른 고객 70명의 유사한 문제를 해결했다. 이를 통해 필자는 웹 스케일 문제를 해결하는 표준 방식이 있을 수 있고, 있어야 한다는 사실을 깨달았다. 그래서 쿠버네티스(Kubernetes)가 등장했을 때 매우 기뻤다. 모든 것이 바뀌었다. 결국 표준 방식으로 웹 스케일 문제를 해결할 수 있는 방법이 있다는 사실을 알게 된 것이다. 

쿠버네티스의 필요성
개발할 때 쿠버네티스와 컨테이너는 애플리케이션을 구성하는 표준화된 방식을 지원한다. 도커파일스(Dockerfiles)/컨테이너파일스(Containerfiles)를 사용하고 깃(Git)에서 커밋하는 이 방식을 누구나 배울 수 있다. 빌드 관리를 위한 이 표준화된 언어는 인지 부하를 단순화하고, SRE가 가진 지식을 조직 내 그리고 다른 조직의 다른 시스템으로 이식할 수 있도록 한다 (즉, 새로운 직원을 채용하기가 더 쉬워진다). 또 애플리케이션을 프로덕션 환경에 투입하기 전에 테스트하기가 훨씬 더 쉬워진다.

런타임 시 쿠버네티스는 클러스터의 여러 서버 간에 애플리케이션을 이식할 수 있게 하고, 장애 조치를 관리하며, 클러스터의 로드 밸런서를 처리하고, 트래픽이 많을 때 확장하며, 클러스터나 온프레미스 등 거의 모든 곳에 배포한다. 사실 필자는 사람들이 쿠버네티스가 필요 없다고 말할 때마다 충격을 받는다. 필자의 이론은 다음과 같다. 쿠버네티스가 필요 없다고 말하는 사람들은 자신에게 웹 스케일 문제가 있다는 사실을 깨닫지 못한 것이다(그리고 그럴 가능성이 매우 높다).

쿠버네티스 프로젝트는 이를 보완하기 위해 설계된 여러 오픈소스 도구와 결합돼 기업들이 웹 스케일 요구 사항을 효과적으로 충족할 수 있도록 지원한다. 여기서 주의할 점이 있다. 필자는 ‘쉽게 충족한다’라고 이야기하진 않았다. 쿠버네티스가 쉽진 않기 때문에 쉬운 척할 생각은 없다. 하지만 웹 스케일 문제도 쉽지 않으며, 오늘날 거의 모든 사람이 이 문제를 갖고 있다. 그렇다. 쿠버네티스에는 필자가 밸렌타인데이만 되면 회사의 인프라가 망가지지 않도록 미친 듯이 애쓰던 시절에는 상상도 할 수 없었던 기능이 있다. 

* Scott McCarty는 레드햇의 RHEL 서버(RHEL Server) 부문 선임 수석 제품 관리자다. ciokr@idg.co.kr
 
CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

발행인 : 박형미 편집인 : 천신응 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.