Cloud에 대한 내 생각 메모 #1

Cloud라는 단어가 내 귀에 들리기 시작하고 본격적으로 공부한 것은 2016년 여름이었다.

당시 내가 근무하던 실시간 방송 OTT 서비스 회사는 2011년도 구축한 온프레미스(on-premise) 인프라였다.  예전 OTT서비스의 클라우드 인프라 전환에 대한 글에서 약간 언급한 적이 있지만 당시 Windows Server 기반의 시스템이었기 때문에 유지보수 비용 상승과 핵심 코어 솔루션에 대한 고도화가 꼭 필요한 시점이었다.

회사 입장에서 자체적인 온프레미스(on-premise) 인프라를 운영은 회사입장에서 TCO감축에 효율성을 떨어뜨리는 부분이 상당히 많았다. 우선 규모에 따라 다를 수 있지만 항상 SE인력이 상주해야하고 필요에 따라 외주 AA나 TA들도 운영에 투입이 되어야한다.

Cloud도 물론 이 부분이 필요없다는 말은 아니다. 다만 회사 입장에서 여러 자원을 안정적이고 효율적으로 관리하는데 있어 어떠한 점 때문에 Cloud로 점점 변해가는지 또 어떤 상황에서는 Cloud전환을 다시 생각해볼 필요가 있는지 생각을 정리해보았다.

Why? Cloud?

Cloud의 가장 큰 장점은 인프라의 유연함에 있다고 생각한다. 전통적인 온프레미스 환경에서 서비스를 운영하다 보면 장비의 장애와 교체라는 지점에서 항상 대응이 빠를 수 없다. 또한 즉각적인 대처를 하기 위해 장비를 구매할 때 여러가지 보증을 포함하게 된다 하더라도 즉시 어떠한 조치를 취하기 위해서는 어쩔 수 없이 단절이라는 장애 상황과 마주하게 된다.

일반적으로 장비와 인프라는 자산에 속한다. 따라서 자산이 불가피한 상황으로 변동이 생길 경우 그 절차는 더 불필요하게 느껴진다. 예를 들어 증가하는 트레픽에 장애가 발생하여 서버를 교체한다고 가정을 해보자. 이런 상황에서 회사 내규와 체계를 기본으로 하는 회사에서는 다음과 같은 절차로 문제 해결이 진행 될 것이다.

장애인지 > 장애보고(장비대기) > 장애파악 > 대응모색 > 장비투입필요 > 보고 및 품의 진행 > 장비공수 > 장비점검(사전검사 및 셋팅) > 상면확보 > 장비 입고점검 > 투입 > 서비스 점검 > 테스트 > 서비스 정상화 > 신규장비 발주 > 보고 및 품의 > 장비도착 > 신규장비 투입 사전 점검(상면포함) > 임시장비 철거 > 신규장비 투입 > 서비스 점검 > 테스트 > 서비스 정상화

물론 위에 적은 절차가 좀 다를 수 있지만 내가 경험한 회사는 최소한 저정도의 절차와 시간이 필요했다. 장비가 해외에서 공수해야되는 경우 신규장비 수급에만 발주 후 거의 3주 ~ 한달이상이 소요된다.

장애발생 이전시점으로 서비스를 완벽한 정상화까지 되돌리기 위해 적어도 2달의 시간이 필요하다.

하지만 Cloud 환경이라고 가정해보자. 아마 위의 절차에서 2/3가 없어질 것이다. 장애인지와 동시에 추가 자원을 생성하여 배포환경에 맞추어 ECS를 셋팅하게 되고 스테이징에서 모든 테스트를 수행한다. 이 과정에서 단절은 최초 장애 시 대응한 절차로 인해 서비스는 단시간 내에 복구 되었을 것이다.

결국 사용요금으로 과금이 되므로 별도의 사용중인 인스턴스의 변화를 품의서로 관리하지 않는 이상은 장애보고와 재발방지 보고정도에서 모든 문서는 마무리 될 것이고 추가적으로 그 이상 일어날 수 있는 장애 시나리오를 더욱 고도화하여 대응을 할 수 있다.

정말 효율적인 구조라고 생각한다. 다만, Cloud환경에서 위의 상황처럼 간단하게 마무리 되기 위해서는 서비스 프레임웍이 Cloud인프라에 최적화 되어 개발되었는지 확인이 필요하고 평소 Cloud인프라에 최적화를 위해 엔지니어가 관리를 지속적으로 했다면 큰 무리없이 진행이 가능할 것이다.

현실적인 Cloud와 이상적인 Cloud?

각 서비스 또는 회사의 Legacy 시스템을 Cloud로 전환하는 과정은 그리 쉽지 않은 과정이다. 도리어 전환하는 작업이 자칫 신규 고도화 개발이나 신규 개발이 될만큼 그 수정범위가 클수도 있다. 앞서 잠시 언급했지만 Legacy 시스템이 클라우드 환경이 최적화되지 않았다고 해서 못할일은 아니다. 다만 Cloud의 최대 장점인 탄력성과 고가용성을 감안하여 빠른 이관을 하기 위해서는 전통적인 구조의 서비스구조는 말 그대로 온프레미스 구조를 그대로 Cloud로 옮기는 일밖에 되지 않는다.

어느 누구나 파워풀한 클라우드의 다양한 서비스를 쓰라고 강요하고 싶지는 않지만 적어도 위의 장애상황에서 대응하는 과정이 쉽지만은 않으며, 편하고 쉽게 쓰라고 제공하는 서비스를 사용하지 못한다면 인프라의 위치만 바뀐것 말고는 달라진게 없는 상황이 생긴다.

기획자 입장에서 인프라의 변화는 온프레미스 환경에서의 운영과 개발가능 범위보다 그 스펙트럼이 커진다고 본다. 이유인즉, 특정 데이터를 추출하거나 통계데이터 등을 조건에 맞추어 백오피스에 노출을 해야하는 과업이 발생했다고 가정해 본다면, 주로 사용했던 방법이 기존 DB에 SP(Stored Procedure)를 추가로 개발하거나 데이터의 양이 많거나 테이블간 join이 다수 발생할 경우 공수가 상당히 커지는 리스크가 발생한다.

하지만 클라우드환경에 최적화 되어 아키텍쳐가 설계되어 있다면 데이터를 굳이 직접 컨트롤하거나 운영환경의 영향도를 덜 받고 해결할 수 있는 방법이 다수 존재한다. 물론 플랫폼의 개발환경과 구조에 따라 다를 수 있지만 요즘과 같이 그로스해킹과 기획 포지션의 담당자들이 직접 데이터를 다루는 일이 빈번해지는 것에 대한 좋은 방편이 될 것이다.

Public Cloud vs Private Cloud?

클라우드 환경을 구축하거나 전환하는 방법은 크게 두가지 방향으로 나뉘게 된다. 보유중인 인프라를 그대로 유지하면서 인프라 환경을 클라우드로 운영하는 HCI(하이퍼컨버지드 인프라)기술을 바탕으로하는 Private Cloud 방식과 우리가 쉽게 접하는 AWS, Azure, TOAST 등과 같은 공개된 환경의 인프라자원을 사용하는 Public Cloud가 있다.

Public Cloud

먼저 퍼블릭한 환경의 클라우드를 언급하는 이유는 처음 클라우드라는 환경이 생겨난 이후 전체적인 IT 인프라 환경의 트랜드를 변화시켰다는 것과 많은 사람들이 알고 있는 클라우드라는 단어와 연관되어있는 것이 바로 Public Cloud이기 때문이다.

AWS이전 클라우드는 사실상 VM기반의 가상화 컴퓨터라는 개념에서 접근이 쉬웠을 수 있다. 하지만 아마존 자사의 고가용성의 인프라를 통해 일반 고객에게 서비스할 것이라는 발상은 본격적인 클라우드 시장의 서막을 열게 되었다.

사실상 IaaS(Infra as a Service)를 제외한 나머지 서비스 유형별로 봤을 때, PaaS(Platform as a Service)나 SaaS(Software as a Service)는 이미 또다른 명칭과 제품들로 서비스가 되고 있었는지 모른다. 하지만 본격적인 형태의 통합형 CSP는 아마존이 주인공이 아닐까 생각한다.

구글이나 MS의 경우 성향이 다르긴 했지만 자사의 인프라와 서비스는 엄연히 다른 영역이라는 구분이 있었고 구글의 경우 일반 사용자에게 쉽게 다가갈 수 있는 SaaS형 상품들이 다수 있었다. MS의 경우 전통적인 온프레미스 환경에서 시장의 점유율이 어느정도 있었기에 오히려 현재의 퍼블릭 클라우드와는 다소 먼거리에 있지 않았는가 생각한다.

하지만 그 예상은 오히려 기반 OS와 다양한 소프트웨어를 보유하고 있는 MS가 오히려 빠른 성장을 가져가고 있고 폐쇄적인 기업문화라는 이미지는 GitHub의 인수로 전환에 성공하게 되면서 대중적인 시장에 인지도를 다시한번 각인시킨 계기가 되지 않았나 싶다.

우선 퍼블릭 클라우드의 기본 적으로 현재 한국에서 가장 대표적으로 운영되고 있는 AWS와 Azure의 원칙에서 그 장점을 파악할 수 있다.

- AWS 백서 : docs.aws.amazon.com/whitepapers/latest/aws-overview/introduction.html?did=wp_card&trk=wp_card

Overview of Amazon Web Services - Overview of Amazon Web Services

- Azure 개요 : azure.microsoft.com/ko-kr/overview/

Azure에 대해 알아보기 | Microsoft Azure

두곳의 퍼블릭 클라우드의 개요를 살펴보면 큰틀에서는 크게 다르지 않거나 명칭만 다를 뿐 같은 서비스가 존재하기도 한다. 이는 보편적인 개발방법론과 설계를 기반으로 한 플랫폼 또는 인프라라면 그에 맞게 이관 또는 하이브리드로 운영이 가능하다는 것이다.

퍼블릭 클라우드는 여러 CSP(Cloud Service Provider)를 기반으로 교차설계가 가능하며, 기존의 온프레미스 환경과 하이브리드로 구축도 가능하다는 장점이 있다.

CSP에서 강조하는 몇가지 중 공통적으로 항상 강조하는 것이 '비용'에 대한 부분을 강조한다. 물론 사용한 만큼 또는 계약한 만큼 사용하고 비용을 지불하는 방법이기에 비용 절감이라는 키워드에는 동의한다. 다만 각 회사의 기반 시스템과 서비스 특성에 따라 오히려 퍼블릭 클라우드에서 비용이 더 발생하는 경우는 어떤 경우가 있을까? 내가 경함한 2가지의 Case에서 이러한 단점에 대해 말해보고자 한다.

Case 1. 클라우드의 특정 서비스에 반복적이고 의존적인 사용을 하는 경우

A회사는 실시간 방송신호(RTMP)를 모바일 앱으로 실시간 서비스하는 회사이다. 이 회사는 기존의 온프레미스 환경에서 자체개발한 인코더를 통해 초고화질의 영상신호를 모바일 서비스환경에 맞게 변환하고 스트리밍서버를 엣지구성하여 일반 백본망을 통해 서비스를 하고 있었다.
온프레미스 환경의 특성상 5년이 초과하는 시점까지 서비스의 리뉴얼이 없었으며, 인코더와 스트리밍서버의 업데이트 또한 없었다.

회사가 클라우드서비스로 이관을 고민하게 된 계기는 크게 3가지 이유때문이었다.

첫째, 노후 장비의 교체시점(장비와 S/W의 EOS 초과)
둘째, 고도화가 불가능한 자체 시스템(인코더, 스트리밍서버 등)에서 발생하는 장애
셋째, 서비스 스트리밍 URL의 보안이 적용되지 않아 과도한 트래픽 유발

이렇게 회사는 3가지의 문제점에서 벗어나고자 클라우드 환경으로 전환을 선택하였고, POC 진행 후 전환을 완료하였다. 전환이후 URL보안과 그동안 App 트래픽 분석에 대한 더욱 자세한 자료와 지표를 산출 할 수 있었으며, 무엇보다 장애가 하루 3~4회 있었던 것에 대비해 3개월 운영동안 단 한번에 장애가 없었다.

TCO를 제외한 모든 부분에서 우수했다. 속도, 보안, 안정성 등. 문제는 비용이었다. 기본적으로 단순한 컴퓨팅 자원만 사용하는 것이 아닌 자체적인 인코더에서 클라우드 SaaS형 인코더로 전환하면서 비용계산의 착오가 있었고, 백본망에서 CDN으로 서비스하는 것에 대한 추가비용이 발생하게 된 것이다.

기존 2,000만원이라는 IDC 상면임대료+망사용료를 훨씬 넘어서는 비용으로 돌아오게 되었다. 회사는 즉시 일부 채널에 한해 클라우드를 사용하게 되었고 대부분의 채널은 기존 인프라로 다시 전환하게 되었다.

여기서 비용적인 측면에서 발생한 문제의 원인은 한마디로 기존 온프레미스 운영비용 계약이 매우 유리한 상황이었고, SE인력에 대한 인건비는 이 비용에서 책정되지 않았다. 따라서 표면적으로 비용이 2,000만원 그리고 인건비가 400만원정도인 월비용에서 클라우드 이전 후 가변비용이 3,000만원이 넘게되는 상황이 발생하게 된 것이다.

본인은 처음 클라우드 전환을 제안할 당시 월 비용은 단순히 현재 나오고 있는 운영비용과 인건비 그리고 노후화된 서버(약 60여대)를 구입하는 자산의 영역까지 감안하여 전체 비용을 5개년으로 시뮬레이션 하였으며 그 계산에 큰 오차가 없었다. 다만 매월 청구되는 비용의 규모가 커짐에 따라 기업의 TCO가 증가한 것으로 회계상 보일 수 있다는 이유에서 다시 회귀한 경우라고 할 수 있다. 만약 장비를 구매하고 인프라를 다시 정비한다면 장비는 현물자산이며, S/W는 자체적인 솔루션이므로 이 또한 현물자산으로 처리할 수 있으므로 비용의 증가보다는 자산의 투자가 회계지표상 좋은 관점으로 바라봤기 때문이다.

현재는 국내 여러 기업에서 클라우드를 널리 사용하고 있는 상황이지만 BEP시점을 바라본다거나 당장 기업 IR측면서 좋은 지표를 유지하기 위해서는 여러가지 이유로 하이브리드형 또는 온프레미스로 회귀하는 일이 발생할 수 있다.

이번 글에서는 클라우드 이면에서 생각할 수 있는 장점과 국내 기업사정에 따른 다소 어두운 부분을 이야기 했다. 기업은 기술로 비즈니스를 하는 곳이다. 따라서 어떤것이 옳고 그르다고 판단하기는 어렵다. 이러한 트랜드의 변화는 회사 오너와 구성원간의 이해와 공감이 필요하며, 그에 따라 비즈니스의 질과 가치를 입증하는 단계에서 깊은 고민이 필요하다고 생각한다.

다음 글에서 Case 2. 최적화 되지 못한 서비스 설계를 한 경우에서 비즈니스를 벗어나 다소 고객과 기술의 관점에서 글을 이어나갈까 한다.