디지털 Transformation, 데이터센터 & Cloud, 베트남

1. 전통적인 시스템 환경의 불합리성

전통적인 IT시스템은 물리적인 서버 (컴퓨팅), 네트웍 (스위치 장비), 스토리지 (DAS, SAN) 등을 발주하고, 4-6주 시간 이후에 납품 받은 후

해당 장비의 업체 엔지니어와 회사내의 IT 담당자가 함께 설치 및 설정 작업을 거쳐 운영을 시작하는 방식으로 이루어진다.

회사 내에 서버, 네트웍, 스토리지 담당 엔지니어가 있어야 운영중의 기본적인 문제를 해결하고, 대응이 되지 않을 경우 유지보수 계약이 맺어져 있는

업체를 통해 2차 기술지원을 받고, 최종적으로 해당 장비를 판매한 벤더를 통해 지원을 받는 구조로 진행된다.

현실은 대부분의 기업이 서버, 네트웍, 스토리지 담당 엔지니어를 보유하고 있지 못한 경우가 많기 때문에 장애에 대한 대응은 외부 업체에 의존할 수 밖에 없고

Time to Recover (복구에 소요되는 시간)도 상대적으로 장시간 소요된다. 또한, 서버, 네트웍, 스토리지 업체가 모두 다른 경우가 많기 때문에 문제 발생에 대해

업체간 다른 업체에 떠넘기려고 하는, 내 디바이스에는 문제가 없다라고 하여 어려움을 겪은 경우도 많이 있을 것이라고 생각한다.

2. 초기 HCI시스템의 등장

이러한 불편함과 단점을 극복하기 위해 Hyper-Converged Infrastructure (HCI) 라는 개념이 등장했다.

초기 HCI는 appliance (HCI - Appliance) 형태로 등장했는데, 하나의 업체가 특정 스펙으로 구성된 노드에 가상화에 필요한 Hypervisor와 관리소프트웨어를 먼저 탑재하고 하나의 제품으로 판매하는 방식이다.

이렇게 되면 하나의 벤더가 서버, 네트웍, 스토리지를 모두 담당하기 때문에 문제 해결에 대해 서로 떠 넘기는 단점을 극복할 수 있다. 관리의 부담이 획기적으로 줄어들고, 비용도 개별 서버, 네트웍, 스토리지를

구매하는 것에 비해 저렴했지만 많은 고객에게 채택되지는 않았다.

가장 큰 이유는 설치 및 운영되는 방식을 보면 명확히 알 수 있는데, 각 노드는 Compute (컴퓨팅, 서버 역할을 대체), 메모리, 스토리지, 네트웍 자원을 포함하고 있는데, 랙에 연결된 샤시에서 전원, 쿨링, 네트웍 연결을 제공하는 구조다. 문제는 HCI Appliance를 운영하다가 특정 노드에서 스토리지 용량 추가가 필요해졌다고 가정 해보자. 해당 하드웨어가 미리 스펙이 정해져서 나온 Appliance 방식이기에 해당 노드에 스토리지만 추가하는 것이 허용되지 않는 경우가 많았다. 방법은 새로운 노드 하나를 추가하여 클러스터를 확장하는 것인데, 스토리지 용량을 추가하기 위해 Compute, 메모리, 네트웍 자원이 낭비되는 현상이 벌어지는 것이고, 해당 노드에 필요한 라이선스 비용까지 늘어나기 때문에 고객이 받아들이기에는 불합리했다.

3. Software 기반의 HCI시스템 (HCI - Software)

Appliance 방식의 HCI 시스템의 단점을 보완하여 Software 기반의 HCI 시스템이 당연히 나왔다. Software 기반이기 때문에 유연하고, 고객이 기존에 보유하고 있던 하드웨어에 설치하여 사용할 수

있기 때문에 비용 효과적이라는 장점이 있다. Appliance 방식 대비 스토리지 추가가 필요하면, 해당 노드의 스토리지만 증설하면 되기 때문에 아주 쉽고 간편하다.

Compute, 스토리지가 공유 풀 개념으로 묶이기 때문에, 원하는 워크로드에 동적으로 원하는 만큼 할당 및 회수할 수 있기 때문에 Public Cloud의 강점을 대부분 제공한다.
(다만, 구축해놓은 Computing 용량을 넘어서 사용할 수 없기 때문에 확장성 측면이나 Time to Market 측면에서는 Public Cloud보다 부족한 건 사실이다.)

대표적인 회사로 Nutanix가 있는데, 특정 하드웨어 벤더와 채널 파트너 계약을 맺어 놓고, Nutanix의 HCI 소프트웨어를 설치하여 정해진 스펙에 맞게, 워크로드의 특성에 맞게 제품을 만들어서 판매한다.

고객에게 직접 소프트웨어를 판매하지는 않는데, 해당 하드웨어 벤더와 성능 및 기능 검증을 완료해야 할 필요가 있기 때문에 자체 정책을 가지고 서비스를 제공한다고 보면 된다.

여전히 제약이 느껴지는가? 고객은 누군가가 팔려고 하는 것을 사고 싶어하지 않는다. 사고 싶은 걸 선택하고 싶어하지.

이런 고객의 니즈에 부합하기 위해서 만들어진 것이 바로 Cloud Z Edge (HCI - 소프트웨어)다. 고객의 워크로드가 범용인지, VDI인지, 또는 고성능 3D 소프트웨어 (카티야)를 구동하는 것인지에 따라 최적화된 하드웨어
서버가 달라진다. Dell, Inspur 등에 Edge 소프트웨어를 설치하여 2주 정도 기능, 성능 검증을 테스트하면 최적의 비용으로, 최고의 성능과 유연성을 보장하는 HCI 시스템을 가질 수 있게 된다.

다시 한번 장점을 정리해보면 다음과 같다.

첫째, 빠른 배포

둘째, 저렴한 비용

셋째, 지원 및 관리 용이성

4. HCI Use Case 시나리오

첫째, 데이터센터 노후화에 따른 서버 통합에 활용
생각해보자, 데이터센터 노후화로 새로 개편을 할 때 전통적인 네트웍, 서버, 스토리지를 도입하여 구축하겠는가? HCI를 통해 워크로드를 통합하면, 사이징 및 센터 활용 측면에서 훨씬 더 효율적이다.

둘째, 지방 및 해외 지사 운영
원격 인프라 관리가 Self Service 방식의 매니지먼트 포탈로 운영되고, 컴퓨팅/네트웍/스토리지 자원이 소프트웨어 기반이기에 원격으로 관리하기에 훨씬 용이하다. 스토리지 관리, 네트웍 관리는 전문가가 없으면 정말 어려운 작업인데 소프트웨어 기반의 경우 포탈에서 비 전문가가 대부분 해결할 수 있고, 기술지원이 필요한 경우 구매한 업체의 기술지원으로 원격으로 해결할 수 있다.

셋째, 백업 및 DR의 단순화

데이터센터 운영의 단순화뿐 아니라 백업 및 DR도 아주 쉬워진다. 계속 반복하지만 복잡성이 줄어들기 때문에, 그리고 원격지에 동일한 시스템을 하나 더 운영하는 것이 기존 백업 및 DR 대비 비용 효과적이고, 쉬워진다.

넷째, VDI환경을 통한 보안성 강화
3D 렌더링을 통한 자동차, 선박 설계를 수행하는 업체들의 경우 가장 고민이 설계 도면의 외부유출 위험이다. 현재 많은 설계회사들이 개별 디자이너마다 고가의 워크스테이션을 제공하고, 카티야 등의 3D 솔루션을 통해

설계를 수행하는데 외부 유출 위협 및 워크스테이션 구매 및 유지 비용 절감을 원하는 것이 사실이다. HCI를 통해 GPU를 8개 장착한 서버 (노드)를 5개 정도 배치하고, 설계자들에게 VM을 통해 사용하도록 모니터만 제공

했더니 성능도 뛰어났고, 설계도면 유출 위험도 사라졌다. 물론 비용 절감도 이룰 수 있었다. 실제 사례이고, 본 Use Case 이후 많은 설계회사들이 Cloud Z Edge를 속속 도입하고 있다.

다섯째, 하이브리드 클라우드 시나리오
하이브리드 클라우드가 확대되고 있는 것은 모두 인지하고 있는 사실이다. 외부 유출 우려가 있는 중요데이터는 HCI에 놓고, 워크로드가 필요로 하면 추가적인 컴퓨팅 용량 및 확장성은 Public Cloud를 이용하는
하이브리드 모델이 최적의 옵션이 된다. 하지만, 복잡성에 대한 우려가 있는 것이 사실인데 HCI와 Public Cloud 연결은 Cloud Z 같은 사업자가 제공하고, 이후 방법론까지 제시하므로 경제성, 확장성, 안정성까지

얻을 수 있는 방법으로 사용되고 있다.

CIO, CDO(Chief Digital Officer), CMO (Chief Marketing Officer)가 직면하고 있는 도전은 무엇일까요?

CEO는 혁신을 요구합니다. 많은 조직에 DT(Digital Transformation) 전담조직이 만들어졌습니다.
CEO가 묻습니다. 어떻게 Digital 혁신해서 회사를 새롭게 바꾸어 낼 것이냐고?

저는 CIO, CDO, CMO에게 묻습니다. Digital Transformation을 뭐라고 생각하는지?

사실 많은 분들이 장황한 설명을 해주시지만, 명쾌하게 이해가 되지 않는 경우가 많습니다.

일단, Digital Transformation의 정의부터 내려봐야 합니다. 제가 생각하는 정의는
"Digital 기술을 활용해 Product, Service, Process, 일하는 방식, 비즈니스 모델의 변화를 통해 혁신과 변혁을 가속화 하는 것" 입니다. 

회사마다 DT를 적용하는 영역이 다를 것입니다. 고객의 산업군(제조/통신/유통/금융), 고객군 (B2B or B2C), 부서 (HR, 구매, 개발, 운영, R&D 등)에 따라 

1. 제품 및 서비스

2. 비즈니스 프로세스: Process 자동화, 최적화, 관리

3. 비즈니스 모델: Go-To-Market, 가치제안, 돈버는 방법 및 효율성 제고, SI (Project) vs Metering / Value Sharing 등

4. 비즈니스 Function: 마케팅, Operation, HR, 고객서비스 센터

5. 고객 경험 향상, 고객 니즈에 맞는 시스템/사이트 변경

6. 시스템 운영이 아닌 비즈니스를 혁신하는 Enabler로서의 IT 역할 요구

여러가지 영역 중에서 가장 자신있고, 효과가 있을 것 같은 것을 하나 선택해서 추진하여 Quick Win을 만들어낸 후, 효과 및 성과를 측정하여 CEO께 보고하고 점진적으로 확대하는 것이 가장 바람직한 접근 방법일 것 같습니다. 

DT를 위해서는 AI, Blockchain, Cloud, Data (Big Data), IoT 등의 Digital 기술의 활용이 필수적입니다. 보통 하나의 기술이 아닌 여러 기술을 융합하는 경우가 일반적이고, 효과적입니다. 

그런데, 문제가 하나 있습니다. Start-up의 경우에는 이런 다양한 Digital 기술을 Public Cloud 사업자 (AWS, Azure, Cloud Z, Google)의 Cloud 서비스를 사용하면 간단히 해결되지만, 엔터프라이즈 기업들은 오랜 기간동안 보유하고
통제하고 있던 On-premise, 가상화, 또는 Private Cloud 환경을 그대로 갖고 있고, 앞으로도 계속 유지해야 합니다.

Public Cloud의 민첩성, 확장성, 경제성의 장점을 갖고도 싶고, 중요 제조/고객/금융 데이터는 직접 보유하고 싶고,  두마리 토끼를 모두 다 가져가야 합니다. 즉, 하이브리드 클라우드가 반드시 필요해지는데, Public Cloud와 Private Cloud, 하이브리드 Cloud까지 함께 제공할 수 있어야 합니다. 

IaaS, Data Analytics, AI (객체인식), Database as a Service, Container 서비스 / Container Orchestration (Kubernetes) 등의 PaaS 서비스의 활용이 필요합니다. 

2008년 5월 7일에 제가 Helsinki School of Economics Executive MBA에 관심이 있어 참석했었는데, 

2018년 5월 10일에는 제가 선배로서 예비 후배들에게 강연을 하게 되었네요.

제가 MBA를 통해 얻은 것은 

첫째, 글로벌 학위

둘째, 마케팅, 재무, 회계, HR 등의 전문 지식 습득 및 Big Picture 보는 눈

셋째, Case study 및 토론식 수업을 통한 업무 능력 향상

넷째, Communication & Presentation Skill (영어)

다섯째, Confidence (무엇이든 할 수 있다는 자신감)

여섯째, Study, Play and precious memory
(잊을 수 없는 공부의 즐거움, 5 Quarter 종료 후 Helsinki/에스토니아/스웨덴 여행의 추억)

Aalto (구, Helsinki School of Economics), 제가 지금까지 가장 잘한 일 중의 하나 입니다. 

알리바바 창업자 "마윈, 내가 본 미래"를 읽었다. 

유투브의 마윈 인터뷰를 찾아서 들었다. 

알리바바의 비전, 마윈의 철학이 너무 좋았다. 

천하에 어려운 장사가 없게 한다. 전세계의 소규모 판매자들의 판매를 돕겠다는 선한 생각, 의지가 너무 감동적이다. 

책 중에서 좋았던 문구를 정리해봤다. 

동양의 지혜, 서양의 행동력, 세계라는 큰 시장

빨리가고 싶다면 혼자 가면 된다. 멀리가고 싶다면 여럿이 함께 가야 한다. 여럿이 함께 가려면 반드시 조직이 만들어져야 한다. 

행동은 모든 변화의 근본이다. 

성공하기 위해서는 학습능력, 자기 반성능력, 자기 변화능력, 꾸준한 실천력이 있어야 한다. 

IT는 나 중심, DT는 타인 중심이다. 다른 사람이 성공해야 내가 성공한다. 

기회란 무엇인가? 기회는 불편을 해소하는 것이다. 불편함, 불평이 있는 곳에 기회가 있다. 

지금 아니면 언제? 내가 아니면 누가? 

병균이 무섭다고 공기를 피할 수 없고, 또 이 때문에 병균과의 싸움에서 이기려는 노력을 포기할 수 없다. 

원망을 해도 소용 없으니, 원망을 하지 말고 기왕 이렇게 된거 문제를 처리해보자. 

여러분에게 맞는 사람을 찾아야지, 최고의 사람을 찾으려고 해서는 안된다. 

가장 재수없는 일은 여러분이 죽었는데 돈은 남아 있어 다른 사람이 여러분의 돈을 쓰는 것이다. 

사람이 죽을때가 되면 평생 해보지 못한 일을 후회하지, 했던 일을 후회하지 않는다. 

창업의 원칙은 내가 가장 좋아하는 일을 하고, 가장 쉬운 일에서 시작해야 한다. 

사람이 자라 어른이 되면 키만 자라는 것이 아니라 내면이 수양되고, 교양이나 지혜가 늘어야 한다. 

인생은 초콜릿 상자와 같은 거란다. 초콜릿 안에 무엇이 들어 있는지 아무도 몰라.

냉정하게 마음을 가라 앉히면 반드시 출구가 있다. 균형을 유지해야 한다. 

아마존에 근무했던 경험과 현재 알리바바와 비즈니스 파트너쉽으로 사업을 진행하면서 비슷한 듯 참 많이 다르다는 생각을 하게 된다.

쉽게 생각하면 둘 다 전자상거래를 주업으로 하는 회사다.

아마존은 온라인 소매 사업자다. 상품을 소비자에게 직접 판매한다. 상품을 공급하는 회사들의 제품에 일정 부분의 마진을 붙여서 판매하고, 해당 제품은 아마존의 거대하고 촘촘히 연결된 창고에 보관하고 직접 배송까지 진행한다. 

알리바바는 온라인 중개업체다. 구매자와 판매자를 연결하는 플랫폼을 제공한다. 알리바바는 타오바오, 티몰, 알리익스프레스 3개의 쇼핑몰 사이트를 운영한다. 

첫째, 타오바오에서는 구매자와 판매자간의 거래에 직접 관여하지 않고, 플랫폼만 제공한다. 심지어 구매자와 판매자 간의 거래에 따른 수수료도 전혀 없다. 수익모델은 타오바오 플랫폼의 검색 결과에서 상위 랭크되고자 하는 판매자로부터 광고비 개념으로 비용을 받는다. 개인 판매자 vs 개인 구매자, 중소규모 판매자 vs 개인 구매자를 위한 쇼핑몰로 팔 수 있는 제품이 있는 누구나 무료로 판매할 수 있는, 마윈 회장의 "천하에 어려운 장사가 없게 한다"라는 말을 현실화해준 서비스다. 

둘째, 티몰은 중산층 고객의 브랜드 상품 구매에 맞춘 서비스이다. 갭, 나이키, 아디다스, 삼성전자 등 브랜드 판매자가 상품을 등록하고 판매하는 쇼핑몰이다. 알리바바는 판매자로부터 매년 사용료를 받고, 예치금도 받고, 또한 거래금액 대비로 일정 부분의 커미션까지 받아 수익을 만든다. 프리미엄 쇼핑몰이라고 보면 되겠다. 중국, 홍콩, 타이완 등 중국 시장에 상품을 판매하고자 하는 글로벌 브랜드들에게 제품을 판매할 수 있는 장터를 제공하는 것이므로 충분히 얻는 수익에 비례한 비용을 지불하도록 하는 합리적인 수준의 수익을 만들어 낸다. 

셋째, 알리익스프레스는 미국, 브라질, 영국 등 중국 이외지역의 소비자가 중국 판매자로 부터 물건을 구매할 수 있도록 제공하는 쇼핑몰이다. 배송료를 전혀 받지 않고, 표기된 금액만 지불하면 된다. 몇 번 구매를 해봤는데 배송에 15일 ~ 30일정도까지 걸리긴 하지만, 제품의 품질도 괜찮고 무엇보다 너무 저렴했다. 

알리바바의 가장 큰 혁신은 알리페이 서비스를 제공한다는 것이다. 신용카드가 보편화된 우리나라는 전자상거래때 카드를 이용하면 되지만, 알리바바 이전의 중국은 신용카드 보급률이 너무 낮았고, 현금으로 오프라인 매장에서 물건을 받을 때 현금을 지급하는 방식이 일반적이었다. 신용이라는 개념이 보편화되지 않았기에, 쇼핑몰에 주문하면서 물건을 받기전에 먼저 지불하는 개념은 받아들이기 어려웠다. 마윈은 알리페이를 통해 에스크로 서비스를 제공하여 일대 혁신을 이룬다. 즉, 주문 당시에는 알리페이가 해당 금액을 보유하고 있다가, 판매자로부터 제대로된 물건을 받으면, 즉 만족하면 알리페이가 판매자에게 대금을 송금하는 신뢰시스템의 제공을 통해 알리바바가 확산되기 시작한 것이다.

플랫폼, 친숙한 듯 하지만 손에 잘 잡히지 않는 개념이다. 

우버, 에어비앤비, 배달의민족, 마이크로소프트의 윈도우, 구글의 안드로이드, 카카오톡 모두 다 플랫폼이라고 한다.

플랫폼은 공급자와 사용자를 직접 연결하여 새로운 경제적 효용과 가치를 창출하는 방식을 의미한다.

우버는 자가용을 소유한 기사 (공급자)와 차를 빨리 효율적으로 잡고자 하는 승객 (사용자)를 연결하는 플랫폼 서비스 이다. 

에어비앤비는 집을 소유한 집주인 (공급자)와 집을 저렴하고 쾌적하게 단기 임대하고자 하는 여행자 (사용자)를 연결하는 플랫폼 서비스 이다. 

배달의 민족은 음식을 판매하고자 하는 음식점 주인 (공급자)와 집에서 편안하게 음식을 배달시켜 먹고자 하는 사용자를 연결하는 플랫폼 이다.

성공적인 플랫폼에서는 아래와 같은 일이 발생한다.

첫째, 공급자와 사용자가 존재한다.

둘째, 공급자와 사용자 모두가 상호 혜택을 얻는다.

셋째, 양면시장 생성에 의해 비즈니스 모델의 혁신을 이루는데, 양면시장 형성을 위해서는 Chicken and Egg 문제가
항상 일어난다. 에어비앤비가 성공하기 위해 플랫폼에서 임대 가능한 집이 충분히 확보되지 않으면, 여행자는 에어비앤비를 사용하지 않을테니까. 그와 반대도 마찬가지다. 

넷째, 양면시장은 네트워크 효과에 의해 형성된다.

해외 법인 및 지사를 운영중인 고객은 아래와 같은 어려움을 토로하셨습니다.

첫째, 본사·해외 지사간 네트워크 속도저하

둘째, 해외 지사의 허술한 IT 보안

셋째, 글로벌 재해 복구 등의 IT 이슈를 어떻게 극복할 수 있나요?

쌍용자동차는 클라우드 제트(Cloud Z)를 통해 해외 150여개국의 해외 지사를 포괄하는 해외 영업 시스템의 네트워크 저하 및 보안 취약성의 문제를 손쉽게 해결습니다. 클라우드 제트를 통해 해외 주요 거점 4곳의 Cloud Z 데이터 센터에 웹서버를 설치한 후 최대 100Gbps의 속도의 글로벌 클라우드 전용망을 무상 이용함으로써 국가간 데이터 전송에서 발생하는 인터넷 회선의 속도 저하 문제를 해소한 것이죠. 결과적으로 기존 방식에 비해 로그인 등의 응답속도가 획기적으로 단축되어 업무 효율성이 크게 높아졌습니다.

글로벌 제조기업 K사는 클라우드 제트의 글로벌 멀티 클라우드 서비스를 제대로 활용한 사례인데, K사는 클라우드 제트를 통해 자사의 글로벌 영업관리시스템을 중국에서는 알리바바 클라우드 센터와 유럽·북미 지역 등에서는 IBM 클라우드 센터와 연결해 통합하였고, 클라우드 전용선 활용은 물론 웹 가속기까지 도입해 네트워크 속도를 크게 높였다.

또한 북한의 EMP 공격에 대한 우려가 있고, 데이터 유실에 대비한 글로벌 백업 및 해외 재해 복구 서비스의 필요성도 지속적으로 높아지고 있습니다.

서울과 홍콩, 도쿄를 연결하는 실제 서비스 사례 속에서 이미지∙동영상 등의 방대한 비정형 데이터 저장 및 백업으로 각광 받고 있는 오브젝트 스토리지와 연계한 데이터의 자동 분산 및 동기화를 제공하여 저렴한 비용으로 글로벌 백업, 글로벌 재해 복구 시스템을 구현할 수 있게 되었습니다.

클라우드 제트 포탈이 새단장을 마쳤습니다.

www.cloudz.co.kr

클라우드 제트는 고객의 다양한 니즈에 부합하기 위해 만들어졌습니다.

인프라 사용 니즈부터, 웹/WAS 서버 환경까지 운영 및 관리를 서비스 방식으로 제공하는 플랫폼부터 최종 애플리케이션을 서비스 방식으로 사용하고자 하는 니즈까지 다 부합하는 서비스를 제공하고자 하는 목적에서 시작되었습니다.

기존 포탈이 인프라 (IaaS) 밖에 담지 못했다면 새로운 포탈은 고객들의 니즈가 폭증하고 있는

소프트웨어의 빠른 배포, 빈번한 배포, 안정적인 배포를 가능하게 하는 MSA(Microservice Architecture), DevOps, Container, 그리고 Continuous Delivery를 가능하게 하는 Cloud Foundry 서비스를 포함하고 있습니다.

또한 Container 서비스 (Docker, Kubernetes)에 대한 부분도 담고 있습니다.

구슬이 서말이라도 꿰어야 보배라고 했는데, 마이크로서비스에 맞게 애플리케이션을 어떻게 신규 개발할 것인지, 기존에 있는 애플리케이션을 어떻게 클라우드에 맞게 수정할 것인지, 많은 고객들이 궁금해하고 방법에 대해 찾고 계신것을 알고 있습니다.

클라우드 제트에서는 CloudZ Labs라는 고객이 직접 클라우드 전문가들과 2-3주의 기간 동안 Hands-on하면서 설계도 하고, 개발도 해보실 수 있는 서비스를 제공하고 있습니다.

클라우드로 이전 했을 때 많은 고객들이 갖는 의문이, IaaS 서비스를 선택했더니 운영체제, 미들웨어, 데이터베이스에 대한 운영은 매니지드 서비스 파트너를 쓰거나, 직접 운영해야 하므로 기존 On-premise 대비로 했을 때 큰 효과가 많지 않더라하는 이야기를 종종 합니다. 사람의 개입을 줄이기 위해서는 자동화, Auto-provisioning 등이 도입되어야 하고 운영 서비스가 아닌 서비스 자체가 managed service로 제공되어야 하는데 PaaS (Platform as a Service)를 선택하는 이유가 바로 이 때문 입니다. 클라우드 제트는 PaaS 서비스를 다양한 방식으로 제공합니다.

Bluemix, 그리고 Open PaaS (PaaS-TA)를 통해 고객의 상황에 맞게 제공해드리는데 PaaS만 있다고 서비스가 가능한 것은 아닙니다. Service Gateway, PaaS monitoring, Redis, ELK, MariaDB 들 역시 서비스 방식으로 제공되어야 하지요. CloudZ가 자체적으로 구축/운영 중인 서비스들을 통해 상황에 따라 상용, 비용을 고려한 오픈소스 기반의 서비스 등을 통해 고객에게 맞춤형 서비스 제공이 가능합니다.

어떻게 시작해야 할지 알고 싶다면, SK주식회사 C&C의 Cloud Z Labs를 찾아주세요.

DevOps

DevOps의 정의 (Wikipedia 참조): 소프트웨어 개발자와 인프라 운영 담당자간에 소프트웨어 배포 프로세스의 자동화및 인프라스트럭처의 원활한 변경을 위해 협업 및 의사소통을 반영한 개발 환경이나 문화를 의미한다. 소프트웨어의 개발, 테스팅 및 배포를 더 빠르고, 자주, 안정적으로 하기 위해 시작되었다.

전통적인 IT 조직은 개발, 운영, 테스팅 조직이 팀으로 나뉘어져 있다. 개발자는 운영에 대한 고민없이 개발이 끝나면 단위 테스팅을 거친 후 운영조직으로 넘기고, 물론 운영조직과 통합 테스팅 과정을 거치기는 하지만 본질적으로 운영은 운영 조직의 몫으로 여기는 경우가 많다. 이런 이유로 대부분의 조직은 개발과 운영 조직의 사이가 대단히 안 좋은 경우가 많다. 하지만, DevOps는 개발, 테스팅, 운영조직간의 의사소통 및 협업을 위한 프로세스와 방법론을 제시하는데 대부분의 경우 개발/운영/테스팅이 함께 어우러져 이루어질 수 있어 효율성이 높아진다. 

DevOps 툴체인

개발,운영,테스팅 조직간의 협업, 즉 기나긴 사이클로 이루어지기 때문에 DevOps가 가능하도록 해주는 하나의 도구는 존재하지 않는다. 여러개의 도구의 집합, 소프트웨어 개발에서 배포 프로세스까지 이어지는 DevOps 툴체인이 필요하다. 

1. Code: 코드 개발 및 리뷰, 버전 콘트롤 도구 등

2. Build: Continuous Integration 도구, Jenkins

3. Test: Continuous Testing 도구, 즉 비즈니스 위험도 등에 대한 피드백 제공

4. Package: Artifact repository, 애플리케이션의 사전 배포 단계

5. Release: 변경 관리, 배포 승인 및 배포 자동화

6. Configure: 인프라 설정 및 관리, Infrastructure as Code 도구, Puppet

7. Monitor: 애플리케이션 성능 모니터링, 즉 최종 사용자 경험 관리

* Docker (containerization) 등

DevOps의 목적은 소프트웨어 배포를 더 빠르고, 자주, 안정적으로 하기 위한 환경을 제공하는 것이다. 배포 매니저는 애플리케이션 배포 자동화 및 Continuous Integration 도구를 통해 진행하는데, Continuous delivery 접근 방식을 택한다. 

Cloud Friendly, Cloud Native 등 친숙하지 않은 개념들을 많이 듣게 됩니다.

Cloud Native Application은 Cloud 환경에 최적화된 애플리케이션이라고 할 수 있는데 이것만 가지고는 어떤 의미인지 이해하기가 어렵습니다.

기업들이 Cloud를 도입하는 이유가 뭘까요? 새로운 기술, 즉 트렌드라서? 분명한 이점이 있기 때문일텐데요, 

가장 대표적으로 IT자원에 대한 자산투자를 하지 않고, 데이터센터 및 서버/운영체제/스토리지/네트웍 등의 자원에 대한 운영인력을 줄이고 컴퓨팅 자원은 필요할 때 즉각적으로 사용하고, 사용량만큼 비용을 지불할 수 있기 때문일 겁니다. Cloud도입 초기에는 인프라(데이터센터, 서버/스토리지/네트웍 등)를 빌려쓰는 IaaS로도 효과를 충분히 볼 수 있었지만, IaaS를 사용해보면 알겠지만 운영체제의 운영, 데이터베이스 운영, 네트웍 및 미들웨어 (Tomcat, Jeus 등) 운영 등 실제 애플리케이션 개발을 위한 플랫폼 운영 관련한 인력이 유지되어야 하고, 플랫폼 소프트웨어 설치/운영/모니터링 등의 업무도 그대로 남게 됨을 알 수 있습니다. 소프트웨어 개발자와 시스템 운영자는 여전히 넘을 수 없는 벽을 사이에 두고 일하게 되고, 개발자가 짠 애플리케이션은 하나의 거대한 단일 애플리케이션 (Monolithic)으로 구성되어 있어, 그중의 일부를 바꾸기 위해서는 전체 애플리케이션을 빌드하고 배포해야 하므로 배포는 자주해서는 안되는 금기시되는, 고객에게 필요한 기능도 쉽게 적용할 수 없는 상황에 처하게 됩니다. 

Cloud에 최적화된 애플리케이션은 바로 위에서 벌어지는 다양한 불합리함을 극복할 수 있게 해주는데, 가장 중요한 factor는 자동화라고 볼 수 있을 것 같습니다. 여기서, DevOps, Continuous Delivery, Micro-service, 그리고 Container 개념이 등장하게 됩니다. 

DevOps는 소프트웨어 개발자와 IT운영자간의 협업을 의미하는데, 소프트웨어 배포(Delivery)나 인프라의 변경 프로세스를 자동화하는 목적으로 합니다. 소프트웨어의 개발, 테스트와 배포를 보다 더 빠르고, 자주, 안정적으로 할 수 있는 하나의 문화라고 볼 수 있을 것 같습니다. 

Continuous Delivery는 단위 애플리케이션이 변경되어 배포되어야 할 때 시스템 정비시간을 기다릴 필요없이 배포할 수 있는 특징을 의미합니다. 배포작업은 모든 개발자 및 시스템 운영자가 부담스러워 하는 작업인데, 위험부담을 줄이고 고객의 피드백을 빠르게 적용하여 경쟁자를 압도할 수 있게 됩니다. 넷플릭스나 Amazon.com이 하루에도 수십/수백번의 배포를 할 수 있는 것도 바로 Continuous Delivery 정책을 사용하기 때문입니다. 

Microservice는 작은 서비스의 결합으로 하나의 애플리케이션을 구성하는 아키텍처 디자인 접근방식입니다. 각 서비스는 HTTP API를 통해 통신하고, 서비스별로 배포, 업그레이드, 스케일 out 및 구동될 수 있고 타 서비스와의 연결고리가 약하게 되어 있기 때문에 사용자에게 영향을 최소화 또는 없게 업데이트할 수 있습니다. 

Container는 하나의 운영체제 (물리적서버 or VM에 무관)에 서로 독립적인 파일시스템과 리소스를 갖고 있는 container로 나뉘어 동작합니다. Container의 생성 및 폐기가 가상머신에 비해 엄청 빠르게 이루어지고, 자원도 거의 사용하지 않아 고집적으로 사용할 수 있습니다. 

바로 이러한 DevOps, CD, MSA, Container 방식으로 개발된 Cloud Native Application의 구동을 가능하게 하려면 PaaS (Platform as a Service)가 필요하게 되는데, 가장 많이 사용하는 플랫폼이 바로 Cloud Foundry 입니다.