오늘 이 시간에는 LG CNS Cloud의 도입을 통해 기존 Legacy 운영과 Cloud 운영이 어떻게 달라지는지 알아보고자 합니다. 또한, Cloud 운영을 위해 추가로 확보되어야 하는 것들이 어떤 것이 있는지 소개해 드리겠습니다.
Legacy Infra 운영의 형태
클라우드 운영을 알아보기 전에 먼저 기존 Legacy Infra 운영에 대해 간략히 살펴보겠습니다.
LG CNS의 경우 과거 e-SCM(e-Sourcing Capability Model) 및 ITIL(IT Infrastructure Library, ISO 2000)의 방법론에 따라 IT서비스 운영을 진행했습니다. 당시에도 상당한 선진모델로 불렸으며, e-SCM의 경우 2003년 Level3를 획득하고 2005년 ITO 분야에서는 세계 최초의 Level4를 획득하기도 했습니다.
위의 이미지와 같이 진단 및 컨설팅에서 설계•구축, 그리고 서비스 운영•관리와 품질개선의 테두리 안에서 전반적인 서비스가 진행되었으며, 여기서 Management만 떼어내 관리 영역을 구분하면 아래 그림의 형태로 표현할 수 있습니다.
Legacy 운영 업무의 형태는 영역별로 필요한 Activity를 가지고, 고객의 선택에 따라 업무명세를 구성하게 되는데요. 이를 통해 고객 IT서비스가 이슈 없이 운영되도록 하는 형태로 구성되어 있습니다. 이런 운영 영역에서의 다양한 영역과 Activity들을 지원하기 위한 ITSM 도구로 G-IMS를 활용해 업무 프로세스를 진행하고 있습니다.
이 Legacy 운영의 특징은 운영을 구성하는 각 요소를 Server Admin들이 프로세스에 따라 모두 처리한다는 것입니다. 이는 고객 입장에서 보면 단일 담당자가 모든 업무를 전담하고 있는 형태로 인식되어 편리할 수는 있습니다. 그러나, 담당자 입장에서는 모든 업무의 단일 창구를 맡으면서 업무 처리를 병행해야 하는 상황입니다.
이런 운영 방식은 점진적으로 업무의 효율성을 개선하고 신속한 처리를 중요시하는 요즘의 트렌드에서 봤을 때는 지속적인 투입인력 절감으로 인해 업무개선에 한계를 보이게 되는 문제점이 있습니다.
또한, H/W가 가지게 되는 수용량의 한계와 지속적인 S/W 업그레이드에 대한 발빠른 대응에 제약을 가지고 있으며, 제각기 다른 서비스 형태로 인해 인력 투입이 많이 필요하다는 문제점을 가지고 있습니다.
클라우드 서비스와 Legacy Service
클라우드 서비스는 LG CNS가 과거에 진행했던 Utility Computing(UC)이 한층 더 진화한 모델로 사용자의 측면에서 Infra의 위치나 장비의 종류보다는 서비스를 기준으로 구성되는 모델이라고 하겠습니다. 즉, 과거의 IT서비스 발전을 기준으로 본다면, M/F Server → UC → Cloud로 플랫폼이 진화하고 있으며, ‘서비스의 권력이 어디에 있는가?’ 측면에서는 H/W → 개발 → S/W → 사용자로 변화하고 있음을 볼 수 있습니다.
M/F의 경우 클라우드나 UC와 서비스 형태 측면에서는 비슷하다고 할 수 있으나, Closed Platform이며 대중화와 가격 경쟁력의 한계로 이미 시장에서는 특수 용도로만 사용되고 있습니다. 따라서 향후 추이를 모니터링 하면서 검토해도 될 것으로 판단됩니다.
좀 더 구체적으로 알아 보도록 하겠습니다.
위 그림처럼 I&O 성숙도 모델을 가지고 파악해 본다면, 기존의 Legacy는 Silo의 특성상 L3가 고도화의 한계라고 볼 수 있습니다. 물론 규모가 확보된다면 L4까지 기대할 수 있으나, 대부분의 고객 규모로는 어렵습니다.
클라우드의 경우, 처음부터 L3를 기준으로 아키텍처와 서비스를 구성하고 출발하게 되어있으며, L4를 기준으로 대부분 서비스가 런칭되고 있습니다. Legacy와 클라우드는 이처럼 출발선 자체가 달라서 Legacy를 고도화하는 것보다는 아예 클라우드로 서비스를 초기부터 고려해서 개발하거나 바로 전환하는 것이 훨씬 효율적이라 하겠습니다.
클라우드 서비스의 구성 요소
클라우드 기반 서비스 전개 모델은 아래와 같습니다.
Legacy가 IaaS 기반에서 고객 또는 S/W 개발조직이 서비스를 구성해서 Silo로 서비스하는 것에 비해 Infra 기반의 IaaS와 플랫폼 기반의 PaaS, 그리고 서비스 기반 아래의 SaaS 등 3종류의 모델을 가지고 있습니다.
IaaS가 고객의 요청에 맞게 인프라를 Shared 형태로 제공하는 것이라고 한다면, PaaS는 고객 애플리케이션의 플랫폼을 서비스 형태로 Shared 또는 Dedicated 방식으로 제공하는 것이라고 볼 수 있습니다.
SaaS는 아예 애플리케이션 서비스 자체를 Shared 또는 Dedicated 방식으로 제공하는 것이라고 볼 수 있는데요. 클라우드의 특성상 특정 고객 용도의 Appl. Platform이나 Appl. Service를 제공하는 것이 아니라, 공통적인 수요가 확보된 플랫폼이나 서비스를 공통 솔루션 형태로 제공하는 것이라고 할 수 있습니다.
그러다 보니 Legacy가 전통적인 3-Tier 모델을 바탕으로 Scale-Up을 고려해서 서비스가 디자인된다고 한다면, 클라우드는 Tier 모델에 상관없이 Scale-Out을 바탕으로 서비스가 디자인되어야 합니다.
즉, Legacy는 각 Tier 간 이중화를 고려한 Cross Connect를 고려해서 서비스가 디자인되며, 용량이 증설되어야 하는 경우, 각 Tier 내 컴퓨팅 자원을 증설하든지 아니면 Cross Connect를 증가시키면서 서버들이 연결되는 구조로 디자인됩니다. 다시 말해 내가 바라보는 Tier와 나를 바라보는 Tier만 고려해서 서비스를 구성하게 되고, 각 Tier의 분산은 H/W L4 또는 이중화 솔루션을 통해 구현하게 됩니다.
반면 클라우드는 용량 증가 시 각 Tier의 대표 VM을 복제하여 해당 Tier VM 수량을 증가시키거나, 해당 Host 내 VM의 용량을 늘리는 방식으로 증설하게 됩니다.
Host 내 Capa.를 증설하는 경우 Legacy와 별다른 차이가 없이 Resource를 증설하게 되지만, VM 수량을 증가시키는 방식으로 증설하는 경우 각 Tier가 바라보는 상위 Tier나 하위 Tier를 고려하는 것 외에, 추가로 Tier 내의 구성 VM간 자동분산을 고려한 아키텍처를 디자인해야 합니다.
이 부하분산을 고려하지 않고 서비스를 디자인하게 되면, Capa.의 급격한 변화가 발생할 때 일일이 수작업으로 상위 Tier와 하위 Tier를 연결하는 작업을 하나하나 해야 하므로 운영 효율이 급격히 떨어지게 됩니다.
클라우드에도 Virtual L4 등이 있으나, 근본적으로 각 Tier간 자동으로 부하를 분산하도록 고려하지 않는다면 Legacy 대비 효율이 우수하다고 볼 수 없으며, 이는 Infra만 클라우드로 구성되고, 서비스는 Legacy로 구성되는 기형적인 아키텍처를 가지게 됩니다.
클라우드의 특징은 Capa.가 부족한 경우, 해당 VM을 Template로 삼아 VM을 계속 찍어내면서 Capa.를 증설하고, Capa.가 넘치는 경우 VM들을 삭제하면서 Capa.를 감설하는 방식으로 서비스 Capa.를 조절하게 되는데, 이에 맞도록 각 Tier의 VM Appl.들은 서로 사용량 정보를 공유하면서 부하를 자동으로 나누어 처리하도록 디자인되어야 합니다.
이는 Infra가 아닌 Appl.단의 부하 분산 디자인 자체를 상시 서로 모니터링 하면서 부하를 나눠 갖는 상시 분산형 서비스 형태로 구성되어야 한다는 의미라고 할 수 있습니다.
4가지 전개(Deploy)모델은 각 Cloud zone을 독립적으로 구성할 것인지, 아니면 Public Cloud와 연계할 것인지에 대한 선택을 지원하기 위한 모델입니다.
Private는 당연히 해당 고객을 위한 전용 Zone을 통해 클라우드를 구성하는 것입니다. 용량 또는 이 VM의 서비스를 받아야 하는 지역(국가)를 기반으로 Public과 연동(Hybrid)하거나, 아예 해당 국가의 Public을 통해서 서비스 가능하도록 구성하는 것을 의미합니다.
클라우드는 권력의 주체가 사용자에 있다고 앞에서 언급하였습니다.
따라서, 사용자들을 지원하기 위한 5가지 특징을 가지고 있으며, 이중 N/W 접근성에 의해 4가지 전개 모델을 선택할 수 있습니다.
클라우드 자체의 특징이 필요하면, 바로 IT 자원을 공급받을 수 있는 신속한 서비스를 기반으로 하고, 자원의 VM간 공유를 통해 즉시 주고받을 수 있도록 합니다. 사용한 만큼만 과금함으로써, 사용량을 계량해서 측정할 수 있도록 빌링을 구성하게 되며, 이런 특징들은 사용자의 편의를 증가시키기 위한 서비스가 됩니다.
클라우드 서비스를 위한 운영 형태
클라우드 서비스의 운영은 Legacy와는 조금 다른 형태를 가지고 있습니다.
Legacy가 H/W 위주의 IT 자원 관리를 통해 그 상위에서 돌고 있는 서비스가 원활하게 진행되는 것을 목표로 하고 있기 때문에, Infra를 구성하고 이를 모니터링 및 관리하는 프로세스를 적용하고 있는데요. 클라우드는 관리를 위한 레이어 구성이 Legacy와는 조금 다른 형태를 보이고 있습니다.
Legacy는 위의 클라우드 관리 아키텍처에 따르면 H/W자원 Pool의 관리와 관리 플랫폼의 리포팅, 모니터링, 구성•성능관리와 하드웨어 관리까지가 운영영역이라고 볼 수 있습니다. 반면 클라우드는 포탈 및 관리 플랫폼 Layer, 가상화 Layer 및 H/W Layer로 나뉘어 운영을 관리해야 합니다.
포탈 및 관리 플랫폼 Layer는 기존 Legacy에는 존재하지 않던 Layer로 통합 클라우드 관리를 위해서는 필수적으로 필요한 영역입니다. 기존의 Infra Server Admin과는 전혀 다른 스킬 영역으로 추가적인 개발 및 Portal 운영 기술력이 필요하며, 이 부분은 추가적인 기술 습득 혹은 소싱을 통해 확보해야 합니다.
가상화 Layer는 하드웨어 자원을 실행환경 내에서 가상화하여 사용자 필요에 의해 넣고 뺄 수 있도록 자원 Pool로 구성한 것을 의미합니다. 기존 Legacy에서는 일부 자원에 대해서 한정적으로 사용이 되었을 수 있으나, 클라우드에서는 전면적으로 사용이 되어야 하며, 이를 통해 사용자는 원하는 리소스(Resource)를 직접 구성할 수 있도록 지원합니다.
기존 Legacy에서는 일부 가상화 솔루션(Vmware, MS Hyper-V, Citrix Xen)을 부분적으로 도입해서 사용하는 고객도 있었을 것입니다만, Legacy의 가상화 영역은 특정 장비에 한하며, 기능적으로는 해당 솔루션이 제공하는 기능을 사용하는 것이 전부였을 것입니다.
클라우드에서는 가상화 Layer를 전면 도입하고, 이를 통해 Compute(Server), Storage(Data), NW(Transfer) 전체 Infra 리소스를 가상화하게 되며, 이를 특정 솔루션이 아닌 공통 솔루션으로 가상화를 구현하고 관리하게 됩니다.
이를 위해 필요한 기능을 Active 하거나 추가로 구현하여 사용하게 되는데요. 일반적으로 OpenStack, CloudStack, AzureStack 등을 사용하며, LG CNS는 OpenStack을 사용하고 있습니다. H/W Layer는 그대로 Infra H/W를 의미합니다. 단, 이 H/W Layer가 Legacy와 다른 점은 가상화 Layer에 의해 벤더사와 무관하게 Resource Pool로 연결되며, 사용자는 이 H/W Layer를 벤더사에 상관없이 구현된 기능에 의해 필요한 Capa.만큼만 할당받아 사용하게 됩니다.
위 그림에서 보듯이 클라우드로의 전환은 3개의 추진원칙을 가지고 추진하게 됩니다. 고객 제공 측면의 서비스 딜리버리는 강화되게 되며, 프로세스 및 운영과 인프라 구성의 인력 수요는 제거하거나 감축하되 효율을 극대화하는 방향으로 진행하게 됩니다.
이 기준을 가지고 클라우드 Layer 측면에서 변화를 설명하도록 하겠습니다.
H/W Layer는 기존의 Legacy와 비교해서 바라볼 때 유사한 스킬과 기능이 있으나, 서비스 우선 순위가 조금 다르다고 하겠습니다. 기존의 Legacy에서 바라보는 H/W Layer는 서비스의 기본 단위로 Application이 수행되는 Base라고 할 수 있는데요. H/W Fault등의 가용성 제약이 발생했을 때 서비스 복구 및 재발 방지가 최우선 순위이고, 변경작업에 있어서 서비스 중단을 기본 전제로 하므로 사전에 고객과의 합의를 통해 개별 고객의 서비스 중요도에 따라 변경 작업을 진행하게 됩니다.
클라우드의 경우 Legacy와 서비스 우선 순위가 다른 점은 우선 H/W Fault등의 가용성 제약사항이 발생하면, 서비스 복구가 최우선 순위인 점은 유사합니다. 그러나, 복구 방식이 기존 장비의 정상화를 통한 복구가 아니라, VM의 타 Host 이관을 통한 복구라는 점이 다릅니다. Fault가 난 H/W는 자원 Pool에서 제외하게 되며, 이관을 통해 복구를 진행하고 Fault가 발생한 H/W의 원인 규명은 차순위로 충분한 시간을 두고 분석하게 되는 점이 다르다고 하겠습니다.
과거 Legacy에서의 조치 프로세스에서는 한정된 자원 내에서 장애가 발생하는 경우, 서비스의 최우선 순위에 따라 차순위 서비스를 희생해서라도 선순위 서비스를 복구하는 것이 목표였다고 하면, 클라우드에서는 차순위 서비스를 희생할 필요 없이 선순위 서비스를 자원 Pool 내의 여유 자원을 통해 복구할 수 있다는 것이 장점입니다.
H/W Infra의 복구보다 서비스의 이관을 통한 복구가 주요한 장애처리 방식이다 보니, Admin의 업무도 이에 따라 우선순위가 바뀌게 될 것이며, 극단적으로 표현한다면 장애 H/W의 우선 복구가 아니고 서비스를 이관하고, Fault가 발생한 H/W를 자원 Pool에서 제외하여 제거하는 것이 주요 업무가 될 것입니다.
즉, 주어진 자원 한계 내에서 효율성을 중시하며, 서비스의 중단을 최소화하는 방식으로 처리되던 Admin 업무가 서비스 연속성을 중시하고, VM이관 후 변경하는 방식으로 처리하되, 가상화 Layer나 포탈 및 관리 Platform Layer를 활용하여 상당 부분 자동화로 커버하게 되면서 기존의 H/W 의존적인 Admin 업무는 상당부분 줄어들게 될 것입니다.
최종적으로는 H/W나 가상화의 업무는 자동화나 OpenStack으로 커버하고 VM윗단의 OS와 Appl. Process 관리로 집중하게 됩니다. 즉, 서비스 딜리버리 측면으로 집중하게 될 것이라는 의미입니다.
위 그림에서처럼 기존 UC 방식의 운영에서 클라우드로 운영 방식이 바뀌게 되면 약 44%를 차지하는 H/W Infra 운영 인력수요를 공통 또는 전담조직으로 이관함으로써 줄일 수 있습니다. 이 경우 H/W + S/W의 조합이 얼마나 표준화되고, 자동화되는가에 따라 절감 규모가 결정됩니다.
물론 UC 이전의 Legacy는 장비까지 개별조직이 관리했기 때문에 더욱 낭비되는 인력수요가 컸다고 볼 수 있습니다. 그리고, 개별 운영조직은 이 절감된 인력 수요를 고객 측면의 서비스 딜리버리 강화에 사용하게 될 것입니다.
클라우드 서비스 운영의 미래
현재 클라우드 서비스는 계속 진화하고 있으며, LG CNS도 이에 맞추어 운영형태의 변화를 진행하고 있습니다.
기존의 Legacy 운영은 인프라 운영 조직이 전반적인 인프라 업무 전체에 대한 책임을 지고 고객대응을 통해, 말 그대로 A to Z 서비스를 진행해 왔습니다.
기존 Admin의 업무가 고객의 요구를 받아서 구현하는 형태였다면, IT서비스의 주된 권력이 인프라에서 S/W를 거쳐 사용자로 이관되는 클라우드 컴퓨팅에서는 고객의 향후 예상 업무를 먼저 파악하고 고객을 올바른 변화의 방향으로 이끌고, 사업을 신규로 확장할 수 있는 방향으로 유도하는 형태로 바뀌게 될 것입니다.
클라우드 업무 형태도 현재까지 최소한의 인원을 통해 최대한의 효율을 확보하는 효율성 극대화의 측면에서 벗어나, 지속적으로 신기술을 적용하고 Cloud IaaS, PaaS, SaaS의 적용을 통해, 선제 서비스를 구현하고, 이를 통해 신사업을 확보하고 전파하는 방향으로 바뀔 것이며, 이를 위한 최적의 운영형태로 변화해 나갈 것입니다.
지금까지 클라우드 도입에 따른 현재까지의 운영형태 변화와 향후 발전 방향을 소개해 드렸습니다. 감사합니다.
글 ㅣ LG CNS 클라우드서비스팀
