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

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 서비스의 활용이 필요합니다. 

CloudZ는 고객의 니즈에 가장 잘 부합하는 Cloud 서비스를 지향 합니다.

여러 산업계의 고객들이 Cloud를 사용 중인데, 그중 게임사 고객들이 겪고 있는 어려움은 비슷했습니다.

"게임 출시를 한국, 아시아, 유럽, 미주 등 다양한 지역에서 여러개의 언어로 출시를 하는데, 글로벌 인프라 운영/유지보수, QA (품질 테스트), 마케팅 등을 수행할 전문 인력이 없다. 또한, 글로벌 운영 시 네트웍 비용이 많이 발생한다. 모바일 게임이 많기 때문에 구글 플레이스토어, 애플 앱스토어에서 상위에 랭크될 수 있는 방법을 알고 싶다."

이러한 고객의 니즈에 부합하는 "게임정글에서 생존하는 법" 이라는 주제로 2018년 4월 4일, 오후 3시부터 판교 스타트업캠퍼스 다목적홀에서 세미나를 개최합니다. SK주식회사 C&C, IGS, 굿어스가 함께 진행합니다.

www.cloudz.co.kr 페이지를 방문하시면, 참가신청 페이지가 있습니다.

참석하셔서 인사이트 얻으시고, 사업에 도움이 되면 좋겠습니다.

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

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

둘째, 해외 지사의 허술한 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 입니다. 

모든 기술은 진화한다.

물리적인 서버, 가상화, 그리고 Infra Cloud (IaaS), 그리고 PaaS (Platform as a Service)로 진화하더니 이제는 Container로 ... 

오늘은 Container에 대한 이야기를 좀 해보려고 한다. 

가장 대표적인 회사가 Docker라고 생각할 것이고, Docker는 CaaS (Container as a Service)를 제공하는 회사이다. 

Container는 VM (Virtual Machine)과 달리, 운영체제를 전부 포함하고 있지 않고 소프트웨어가 동작하는데 꼭 필요한 코드, 런타임, 시스템도구, 시스템 라이브러리와 설정값을 갖고 있다. 리눅스와 윈도우 기반 앱으로 동작하고, 어떤 환경에 배포되더라도 항상 동일한 동작을 한다. Container는 주변 환경과 소프트웨어를 격리시켜주므로 개발, 스테이징 환경 등의 차이에 무관하게 동작한다. VM 대비로 훨씬 적은 자원/공간을 점유하고, 일반적으로 수십 메가바이트 규모이며 대부분 즉시 (초단위로) 구동된다. 

VM (Virtual Machine)은 물리적 하드웨어를 추상화한것으로 봐야하는데, 하이퍼바이저를 통해 하나의 하드웨어에 여러개의 VM을 구동하는 방식이다. 각 VM은 운영체제를 다 설치해야하고 여러개의 애플리케이션과 라이브러리 등을 설치해야 하기 때문에 수십 기가바이트 규모로, 부팅에 오랜 시간이 소요된다. 

일단 container를 사용하고자 마음 먹으면, container를 스케쥴링하고 관리하는 솔루션이 필요하게 된다. 바로 이 역할을 하는 것이 Orchestration 도구인데, 가장 일반적으로 많이 알려진 것이 Kubernetes와 Docker Swarm이다. 그 중에서 완성도가 높고 확장성이 있는 솔루션이 바로 Kubernetes이고, 오픈소스라는 것이 특징이다. (구글이 만들었다.)

개중에는 Docker와 Kubernetes를 비교하는 경우가 있는데, Docker는 orchestration만 제공하는 것이 아닌 훨씬 많은 것을 제공하므로 Docker Swarm과 대응하는 솔루션임을 꼭 기억하자. Docker Swarm은 아직은 좀 더 성숙할 시간이 필요하다고 생각한다. 

Kubernetes에 대해서는 조금씩 자세히 알아보도록 하겠다.