Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.

마이그레이션

멀티 클라우드에 대한 기업용 가이드

멀티 클라우드 플랫폼에 기반하여 미래에 대비한 멀티 클라우드 운영 모델은 최소한의 리스크로 현대화하기 위한 가장 효율적이고 비용 효과적인 방식입니다. 클라우드를 활용하여 애플리케이션을 빠르게 마이그레이션하고, 수요에 따라 리소스를 확대하거나 축소하며, 분산된 작업 이니셔티브를 위한 리소스를 제공하고, 애플리케이션 현대화 전략을 주도할 수 있습니다. 기업을 위한 멀티 클라우드 가이드는 기업이 효과적인 멀티 클라우드 전략으로부터 기대할 수 있는 가치를 이해하도록 돕기 위해 구성되었습니다. 주요 멀티 클라우드 사용 사례 및 서비스 모델, 성공을 위한 가장 일반적인 당면 과제를 소개합니다. 이를 바탕으로 멀티 클라우드에 대한 이상적인 접근방식과 선택, 속도, 제어에 달려 있는 성공적인 멀티 클라우드 운영 모델을 구현하는 데 조직에 필요한 것이 무엇인지 알아봅니다. <27p> 주요 내용 - 멀티 클라우드를 사용해야 하는 이유 - 멀티 클라우드 당면 과제 - 이상적인 멀티 클라우드 환경 - 새로운 접근 방식: 클라우드 운영 모델 - 진정한 멀티 클라우드 운영 모델을 구현하는 방법

멀티클라우드 현대화 마이그레이션 6일 전

오픈소스계 유니콘 코크로치DB, 마이그레이션 도구 ‘몰트’ 및 ‘서버리스’ 기능 추가 

구글 출신 직원들이 모여 만든 기업으로 유명한 코크로치 랩스(Cockroach Labs)가 분산형 SQL 데이터베이스 ‘코크로치DB(CockroachDB)’에 데이터베이스 마이그레이션 툴 ‘몰트(Molt)’를 추가했다고 21일 밝혔다. 또한 서버리스 제품도 함께 공개했다.  코크로치 랩스는 오픈소스 기술이면서 재해 발생 시 복원력이 뛰어난 데이터베이스 코크로치DB를 만들어 인기를 끌고 있다. 몰트라는 단어는 원래 탈피 혹은 털갈이라는 뜻을 가지면서 기업에서 신입사원 오리엔테이션(Model for Optimal Learning and Transfer의 약자)을 할 때 쓰는 용어이기도 하다. 코크로치 랩스는 몰트로 마이그레이션에서 발생하는 여러 장애물을 줄일 수 있다고 보고 있다. 특히 몰트는 스키마 컨버젼 툴(schema conversion tool)을 지원하는데, 사용자는 이 도구로 기존 데이터베이스와 코크로치DB 사이의 호환성 문제를 확인하고 고칠 수 있다.  데이터베이스 마이그레이션은 많은 시간과 노력이 필요한 작업이다. 그래서 기업은 호환성 및 데이터 간 불일치 등의 문제를 해결하는데 많은 자원을 투자하곤 한다. 실제로 시장조사업체 가트너는 데이터 마이그레이션 중 83%는 실패하거나 예산이나 일정 문제를 맞닥뜨린다고 설명했다. 또 다른 분석 기관 불로어 그룹(Bloor Group)이 펴낸 보고서도 데이터 마이그레이션 프로젝트 80%가 마감 일정이나 예산을 맞추지 못한다고 지적했다.  그 외에도 코크로치 랩스는 ‘코크로치DB 서버리스’를 공식 출시했다. 코크로치DB 서버리스는 주문형 관계형 데이터베이스로 포스트그레SQL 인터페이스를 이용하고, 사용량 기반으로 서비스를 확장하고 요금을 책정하는 것이 특징이다. 또한 데이터베이스 운영의 어려움과 예산을 줄이는데 도움을 줄 수 있도록 커맨드라인 인터페이스(CLI) 같은 개발자 도구와 포스트그레SQL 객체 관계형 매퍼(ORM) 소프트웨어를 제공한다. ORM은 객체 지향 패러다임을 ...

오픈소스 코크로치 DB 2022.09.22

“마이크로소프트 365도 옮겼다” 윈도우 앱을 컨테이너로 옮기는 방법

마이크로소프트 플랫폼 상에서 구축 작업을 하는 개발자라면 누구나 알고 있는 오랜 격언은 “어떤 마이크로소프트 제품이 전성기를 맞이할 준비가 되었는지 파악하려면, 그 제품이 마이크로소프트의 주력 애플리케이션이나 서비스에 사용되는지 여부를 보면 알 수 있다”는 것이다.  즉, 올리언스(Orleans) 분산 애플리케이션 프레임워크는 헤일로(Halo)의 대부분을 구동했을 때, 플루이드 프레임워크(Fluid Framework)는 팀즈(Teams) 내에 들어갔을 때 등등이 본격적으로 사용할 때가 되었다는 의미이다. 최근에 승인 도장을 받은 서비스는 애저 쿠버네티스 서비스(Azure Kubernetes Service, AKS) 상의 윈도우 컨테이너다. 마이크로소프트는 코로나19 대유행에 따른 급속한 업무 패턴의 변화를 고려한 확장성 및 유연성 제고를 위해 마이크로소프트 365 플랫폼의 대부분을 AKS로 옮기는 작업에 지난 1년 정도를 보냈다.       마이크로소프트 365, 클라우드 네이티브 컨테이너로 이전 마이크로소프트 365 규모의 서비스를 컨테이너로 옮기는 과정은 복잡했다. 오피스 온라인(Office Online) 단일 테넌트 시스템을 멀티 테넌트 가상화 아키텍처로 옮기는 일은 특히 CI/CD로의 이전을 동반한 경우 충분히 어려웠다. 제일 먼저 이전한 것은 컨테이너로의 이전에 필요한 아키텍처 개선의 많은 부분이었다. 무엇보다도 애플리케이션 VM에서 마이크로소프트 그래프(Microsoft Graph)로 옮기는 것이 중요했다. 그러나 많은 서비스, 특히 테넌트를 구성하는 서비스와 시스템 사이의 네트워킹을 지원하고 가용성을 관리하는 용도의 서비스는 여전히 커스텀 방식이었다.  이 접근법은 일관성 부재로 이어졌다. 애플리케이션 빌드는 특정 플랫폼을 목표로 해야 했다. 그 결과, 아키텍처의 비효율성이 발생했다. 서로 다른 VM을 호스팅하려면 서로 다른 서버 종류가 필요했기 때문이다. 마이크로소프트 365 서비스를 호스팅한 ...

마이크로소프트365 마이그레이션 리팩터링 2022.08.22

블로그 | 클라우드 비용이 전통 시스템을 앞지를 때 생기는 일

필자는 2020년에 클라우드 비용이 전통적인 시스템 비용보다 커질 것이라고 예측한 바 있는데, 지금이 바로 그 시점이다. 퍼블릭 클라우드 서비스에 대한 지출이 또 하나의 이정표에 도달했는데, IDC의 최근 보고서는 2022년 1분기 기업의 클라우드 컴퓨팅 지출이 전년 동기 대비 17.2% 증가한 183억 달러에 이르렀다고 밝혔다.   이 수치는 공유 인프라와 전용 인프라를 포함한 것이다. 하지만 성장의 주된 동력은 퍼블릭 클라우드 서비스에 대한 지출로, 전체의 68%인 125억 달러를 기록했다. 2021년 1분기와 비교해 15.7%가 증가했다. 이 수치는 올해 클라우드 컴퓨팅 서비스에 대한 지출이 전통적인 IT 하드웨어를 추월했다는 것을 의미한다. IDC의 이번 보고서는 여러 가지 이유로 흥미롭다. 첫째, 애플리케이션과 데이터의 클라우드 마이그레이션을 주저하는 기업을 당혹스럽게 만들지도 모른다. 요즘은 모든 투자가 클라우드에 집중된다. 따라서 전통적인 시스템을 많이 보유하고 있을수록 레거시 플랫폼에 대한 연구개발 혁신의 혜택을 기대하는 것이 과거와 같은 속도로 이뤄지지는 않을 것이다. 필자의 클라우드로의 이전이 불가피하다는 것을 여러 번 지적했다. 그리고 새로운 보고서는 전통적인 데이터센터 기술을 고수하는 기업에는 위험성이 점점 커지기만 한다는 것을 보여준다. 이들 기업도 결국은 클라우드로 이전하게 될까? 만약 그렇게 된다면, 비즈니스 요구보다는 시장에 대한 우려 때문일 것이다. 시장에 대한 우려 때문에 이전한다면, 위험성도 커진다. 잘못된 이유로 잘못된 속도로 이전하는 기업은 생각보다 성공하기가 어렵다는 것을 알게 될 것이다. 둘째, 리서치 회사에 따라 다르지만, 2022년 현재 기업은 30~45%의 워크로드와 데이터를 클라우드로 이전했다. 만약 클라우드 지출이 전통적인 기술 지출을 추월했다면, 이들 비용은 새로운 클라우드 워크로드를 지원하는 데 사용됐을 것이다. IT 예산의 절반 이상을 클라우드에 사용하는데, 클라우드로 이전한 애플리케...

퍼블릭클라우드 마이그레이션 예산 2022.07.11

블로그 | 앱 현대화, 필수 점검 목록을 의심하자

애플리케이션 현대화를 정의해 달라고 하면, 사람마다 대답이 다르다. 하지만 모두가 동의하는 내용을 일반화해 보면, “애플리케이션 현대화는 비즈니스를 운영하는 기존 애플리케이션과 데이터 세트를 가져다 더 유용하고 생산적이고, 사용자, 특히 고객에게 더 매력적으로 만드는 것”을 말한다. 고객 경험을 개선하는 역량은 비즈니스를 촉진한다.   일부는 애플리케이션 현대화를 “호박에 줄 긋기”로 보기도 하지만, 그런 목적은 아니다. 애플리케이션 현대화는 현대적으로 보이도록 만드는 것이면 안 된다. 애플리케이션이 실제로 현대적인 것이 되어야 한다. 애플리케이션 현대화는 내부 아키텍처와 퍼블릭 클라우드 플랫폼 인프라, 애플리케이션 기능, 구현 기술의 현대화는 물론, 사용자와 기계 간의 인터페이스의 변화를 의미한다. 또한 전통적인 폭포수 방식 개발 과정을 애자일 및 데브옵스로 바꾸는 것도 필요하다. 귀중한 레거시 애플리케이션을 개선해 퍼블릭 클라우드로 이전한다는 것은 좋은 생각이지 않은가? 물론이다. 하지만 개발자와 클라우드 아키텍트가 끝없는 점검 목록으로 현대화에 접근하는 경우가 많다. 때로 이 점검 목록이 너무 지나쳐 비즈니스 가치라는 현대화 프로젝트의 목표와 목적을 놓치고 만다. 프로세스부터 방법론까지 애플리케이션 현대화에 대한 정보는 차고 넘친다. 그리고 많은 개발팀이 레거시 애플리케이션을 정말로 현대적으로 만들어 준다는 점검 목록을 하나하나 표시하는 것으로 현대화를 시도한다. 컨테이너화, 마이크로서비스, 데이터 증강, 내부 아키텍처 증강 등등 유행하는 개념을 추구하는데, 이런 개념은 종종 대규모 수술을 필요로 한다. 그리고 그저 체크박스에 표시하기 위해 수많은 복잡성을 감당하고 그에 따른 비용을 들이다 보면, 애플리케이션 자체를 위험에 빠뜨릴 수도 있다. 두 가지 실용적인 문제를 생각해 보기 바란다. 첫째, 원조 레거시 애플리케이션을 버리고 새로 시작하는 것이 더 말이 되는 티핑 포인트가 있다. 필자는 항상 고쳐 쓰는 것을 선호한다. 하지만 새로...

마이그레이션 현대화 마이크로서비스 2022.06.27

블로그 | 클라우드 마이그레이션이 지체되는 이유

클라우드 마이그레이션이 일시적으로 둔화될 수 있는 이유가 3가지 정도 있다. 근거로 댈 만한 데이터는 없다. 그래서 잘해야 그동안의 경험을 바탕으로 한 주장에 불과하다. 하지만 이런 결과를 낳을 수 있는 일부 데이터를 최근에 봤다. 그리고 현재 시장의 성숙도를 고려하면 충분히 말이 된다.   첫째, 코로나19 팬데믹으로 촉발된 클라우드로의 정신없는 질주가 계속될 수는 없다. 기업 활동이 제약을 받는 시기에 클라우드 도입이 둔화될 것이라 생각한 사람도 있었지만, 결과는 그 반대였다. 물리 데이터센터는 봉쇄 기간에 접근도 할 수 없었지만, 퍼블릭 클라우드는 팬데믹에 거의 끄떡없다는 것을 증명했다. 이런 장점과 원격 근무 지원의 폭발적인 증가가 합쳐져 많은 정부기관과 글로벌 2,000대 기업이 클라우드를 본격적으로 도입했다. 하지만 이 속도를 영원히 유지할 수는 없다. 그래서 팬데믹 이전 속도로 돌아가기 위해 마이그레이션 프로젝트를 연기하는 기업이 증가하고 있다. 이런 현상은 바람직하다. 보통 속도를 추구하다 보면, 치밀한 계획과 베스트 프랙티스가 뒷전이 되기 때문이다. 예를 들어, 많은 기업이 리프트 앤 시프트 방식으로 급하게 이전한 애플리케이션을 다시 손봐야만 할지도 모른다. 이런 애플리케이션은 새로운 퍼블릭 클라우드 플랫폼에 최적화되지 않았으며, 비용도 많이 들고 안정성도 떨어진다. 둘째, 클라우드 기술 인력이 부족하다. 이렇게까지 기술 인력이 부족한 적은 없었다. 기업과 정부기관이 클라우드 마이그레이션을 얼마나 진행할지는 기술 인력을 얼마나 확보하느냐에 따라 결정될 정도이다. 클라우드로의 이전 속도가 인력의 수에 의해 결정된다는 보고서가 계속 나오고 있다. 인력 수요는 여전히 공급을 웃돌고, 이는 분명 클라우드 마이그레이션 속도가 둔화되는 이유가 될 것이다. 셋째, 이전하기 쉬운 워크로드는 이미 이전했다. 낮은 곳에 달린 열매는 이미 다 따먹은 셈이다. LAMP 기반 애플리케이션과 데이터처럼 퍼블릭 클라우드에서 유사한 기술과 서비스를 쉽게 ...

마이그레이션 인력부족 팬데믹 2022.06.20

AWS, 메인프레임 마이그레이션 서비스 정식 출시

AWS가 메인프레임 사용 기업의 앱을 클라우드로 이전할 수 있도록 지원하는 서비스 AWS 메인프레임 모더나이제이션(AWS Mainframe Modernization) 서비스를 정식 출시했다. 지난 해 11월부터 프리뷰 상태로 공개된 이 서비스는 메인프레임 애플리케이션의 클라우드 마이그레이션을 관리하는 툴과 인프라, 소프트웨어를 제공한다.   기업은 AWS가 제공하는 툴을 이용해 코볼 같은 개발 언어로 작성된 워크로드를 리팩터링할 수 있으며, 아니면 기존 워크로드를 그대로 유지하면서 최소한의 코드 변경으로 AWS로 플랫폼만 바꿀 수도 있다. 매니지도 런타임 환경은 이전한 애플리케이션을 실행하는 데 필요한 컴퓨트, 메모리, 스토리지를 제공하며, 용량 프로비저닝이나 보안, 로드밸런싱, 확장, 애플리케이션 상태 모니터링 등의 세부 운영은 자동화된다. 이 서비스를 위한 AWS 마이그레이션 허브는 한 지점에서 AWS와 파트너 서비스 전반에 걸쳐 애플리케이션 마이그레이션의 진행 상태를 추적할 수 있다. 파트너로는 액센츄어, DCX 테크놀로지, 타타, 아토스, 마이크로 포커스, 인포시스 등이 참여한다. 참고로 AWS 외에도 구글 클라우드와 마이크로소프트 애저 등이 메인프레임 현대화 서비스를 제공한다. 하지만 메인프레임 기반의 기업이 모두 클라우드를 원하는 것은 아니다. 이런 기업을 위해 IBM 역시 메인프레임과 관련 생태계를 꾸준히 개선하고 있다. 지난 4월 IBM은 AI나 보안, 하이브리드 클라우드, 오픈소스 등 현대 기업의 요구사항을 초점을 맞춘 z16 메인프레임을 발표했다. 특히 텔럼(Telum) 프로세서에 AI 가속기를 탑재해 하루 3,000억 건의 추론을 수행할 수 있도록 관련 기능을 강화했다. 용량과 암호화 기능을 강화해 미션 크리티컬 애플리케이션을 안전하게 구동하는 한편, 퍼블릭 클라우드 서비스도 이용할 수 있도록 했다. 이런 성능과 확장성으로 하이브리드 클라우드 환경에서 메인프레임의 활용도를 높였다.  AWS의 새 서비스 요금제는...

메인프레임 마이그레이션 AWS 2022.06.10

블로그 | 레거시 시스템도 멀티클라우드의 일부라야 한다

멀티클라우드 전략 계획 회의가 한창이다. 네트워크 담당자도 참여하고 클라우드 데이터베이스팀, 클라우드 보안팀, 심지어 핀옵스 담당자까지 참여했다. 그런데 아무도 기존 메인프레임이나 다른 구형 시스템을 유지하는 일은 맡으려 하지 않는다. 이유가 무엇일까?   차세대 클라우드 시스템 구축에 초점을 맞춘 기업은 전통적인 시스템을 포함하지 않으려 한다. 여기서 ‘전통적’이라는 말은 현재 데이터센터에 있는 시스템 대부분이며, 보통 핵심 비즈니스 시스템의 60~80%를 차지한다. 경영진이 일부러 IT의 개입을 막았다고 생각하지는 않는다. 그보다는 멀티클라우드라는 것이 충분히 복잡하다는 사실을 반영한 것이라고 본다. 구형 시스템까지 계획에 포함해 더 복잡하게 만들어서는 곤란하다는 것이다.  하지만 한편으로 기업은 레거시 시스템의 일부 데이터를 가져다 새로운 클라우드 기반 시스템에서 사용하고 싶을 것이다. 그 방식은 느슨하게 연결된 통합으로, 대부분 멀티클라우드 운영 환경 밖에서 이루어질 것이다. 멀티클라우드가 복잡한 분산 아키텍처라는 것을 고려하면, 필자 역시 멀티클라우드 계획에서 복잡성을 조금은 줄여야 한다는 것은 알고 있다. 하지만, 이런 접근 때문에 클라우드 기반 시스템에 새로 구축하는 보안, 데이터 관리, 운영, 거버넌스 인프라를 이용할 수 있는 큰 기회를 놓칠 수도 있다.  필자의 주장은 코어 시스템을 클라우드에서 관리할 때 레거시 시스템도 포함하라는 것이다. 여기에는 보안과 운영, 거버넌스의 업데이트와 업그레이드도 포함되며, 이들 크로스 클라우드 서비스를 레거시 시스템에도 적용해야 한다. 이 방법은 몇 가지 중요한 역할을 한다. 첫째, 클라우드와 레거시 시스템 양쪽 모두에 동일한 접근법과 툴을 사용하기 때문에 운영이 단순해진다. 예를 들어, IAM 시스템을 업그레이드해 클라우드와 레거시 시스템 모두를 포괄하는 디렉토리 서비스를 추가할 수 있다. 이를 통해 클라우드와 비 클라우드 모든 시스템에 일관성 있는 단일 인증 서비스...

멀티클라우드 레거시 마이그레이션 2022.06.07

글로벌 칼럼 | 멀티클라우드의 복잡성 문제를 위한 3가지 고려사항

버타나 리서치의 최근 설문 조사에 따르면, 82%의 응답자가 멀티클라우드 전략을 이용하고 78%가 워크로드를 세 곳 이상의 퍼블릭 클라우드 서비스에 배치한다. 총 59%의 응답자가 자사 워크로드의 절반 이상을 멀티클라우드 배치의 일환으로 퍼블릭 클라우드에 두고 있다. 마지막으로 51%의 응답자는 2022년에 지원하는 퍼블릭 클라우드 인스턴스의 수를 늘릴 계획이며, 35%는 다섯 곳 이상의 클라우드 플랫폼을 사용할 계획이라고 답했다.   최근 몇 년 동안 멀티클라우드의 증가세를 지켜봐 온 필자로서는 이번 설문조사 결과가 그리 놀랍지는 않다. 오히려 흥미로운 것은 63%의 응답자가 마이그레이션, 클라우드 비용 최적화, 통합 성능 모니터링, 애플리케이션 성능 관리, 클라우드 인프라 모니터링을 위해 최소한 다섯 가지 이상의 별도 툴을 이용한다는 부분이다. 이 가운데 83%는 이들 툴에서 나오는 데이터를 수작업을 통합한다. 별도의 데이터베이스, 심지어 스프레드시트 같은 것을 사용하는 것으로 보인다. 많은 기업이 이들 툴을 서로 격리된 상태에서 운영한다. 단 17%만이 툴의 데이터를 자동으로 통합한다고 답했다. 필자는 리서치 회사의 데이터를 신봉하는 사람은 아니다. 하지만 이번 조사의 데이터는 예외로 할 만하다. 첫째, 멀티클라우드의 복잡성이 현실적인 문제라는 점을 증명했다. 둘째, 멀티클라우드 배치를 전후로 마이그레이션의 복잡성에 특별한 주의를 기울여야 한다는 것을 다시 한 번 확인했다. 마지막으로 운영 툴의 통합이 제대로 이뤄지지 않고 있다는 사실을 보여준다. 사일로 방식으로 툴을 배치해서 해결할 수 있는 복잡성 문제는 거의 없다. 그저 비용과 위험성만 키울 뿐이다. 필자가 멀티클라우드 복잡성에 대한 또 하나 이야기하고 싶은 부분이 이것이다. 멀티클라우드 배치 전에 몇 가지 추가 계획을 세우면 불필요한 복잡성을 피하고 성공을 보장할 수 있을 것이다. 다음 세 가지를 고려하기 바란다. 더 복잡한 것을 만들어 아키텍처의 복잡성을 해결할 수는 없다. 단...

멀티클라우드 복잡성 마이그레이션 2022.05.30

글로벌 칼럼 | 클라우드와의 작별에 대해 생각하기

시작은 은행 IT 전략 담당자들의 대대적인 발표였다. “클라우드가 우선이다!” 전문가 부서는 시간을 끌기를 원하지 않았다. 많은 인력과 예산이 투입되어 12개월 이내에 수많은 은행 프로세스를 지원하게 될 클라우드 지원 커뮤니케이션 솔루션이 개발된다.  그런데 솔루션을 라이브로 올리기 직전, 은행의 아웃소싱 임원이 제품 책임자에게 출구 개념에 대해 묻자 다들 어리둥절한 표정을 짓는다. 그런 게 왜 필요한가? 클라우드 서비스 업체는 미국의 3대 업체 중 하나이고, 파산할 일은 결코 없다. 데이터센터 중 한 곳에 장애가 발생해도 해당 업체의 다른 데이터센터로 전환하면 된다. 이 고가용성이 바로 애초에 클라우드 솔루션을 선택한 이유다.    이 이야기의 전개를 다음과 같이 가정해 보자.  아웃소싱 담당자는 규정에 따른 의무 사항인 출구 개념을 고집했고, 이 논의는 결국 처음으로 되돌아가서 프로젝트를 다시 고려하고 마침내 완전히 다시 설계하는 결과로 이어졌다. 다른 은행과 보험사의 경우를 보면 알 수 있듯이, 드문 사례가 아니다. IT와 전문가 부서는 일반적으로 최신 클라우드 애플리케이션이 제공하는 가능성과 사용례를 최대한 신속하게, 최대한 많이 사용하고 고객에게 전달하고자 한다.  기술적인 어려움과 우려는 뒷전이 되고, 분위기에 휩쓸려 코드는 빠르게 확장되고 데이터 보호와 규정에 대한 생각은 저 멀리 밀려난다. 치명적인 실수다. 특히 은행과 보험사는 클라우드에서 무엇이 허용되고 금지되는지를 면밀하게 살펴봐야 한다. 또한 클라우드가 불필요하게 될 때 어떻게 빠져나올 것인가? 답하기 쉽지 않은 질문이다.    클라우드 “비상구”는 의무 사항  앞서 언급한 사례에서 관건은 출구 개념을 제시할 수 있어야 한다는 요구사항이다. 독일연방금융감독청의MaRisk AT 9 아웃소싱 규정에 따르면, 은행은 의도적이거나 예상된 중대한 아웃소싱 중단에 대비해야 할 의무가 있다. 반면 의도하지 않고 예상하지도 ...

출구전략 규제 마이그레이션 2022.04.18

블로그 | 클라우드 프로젝트를 망치는 데이터

데이터 전송은 클라우드 마이그레이션에서 가장 쉬운 부분처럼 보인다. 결국, 애플리케이션을 이전하는 것이 가장 고통스러운 부분이다. 데이터 복제와 이전은 간단해야 하며, 애플리케이션과 데이터 마이그레이션의 마지막 단계에 수행한다. 그렇지 않은가?   IT 부서의 많은 이들이 데이터가 가장 중요한 비즈니스 자산이라고 말한다. 하지만 그들이 보유한 데이터의 현재 상태를 보면, 그 말이 믿기지 않을 것이다. SSOT(Single Source of Truth)도 없고, 복제가 데이터 관련 문제를 해결하는 가장 일반적인 방법이다. 또한 데이터를 적절히 분류하지도 않고 데이터 통합도 되어 있지 않거나 복잡성만 추가한 경우가 많다. 데이터 관리와 보안도 흐리멍덩하다. 그렇다면 문제는? 이 엉망진창 데이터를 모두 클라우드로 이전하겠다는 것이다. 그런데, 클라우드는 아무것도 고쳐주지 않는다. 기존 데이터 문제를 그대로 호스팅하는 또 하나의 플랫폼일 뿐이다. 게다가 스토리지와 데이터베이스를 마우스 클릭 한 번으로 더 쉽게 할당한다는 점에서 문제는 더 나빠지기 쉽다. 이제 어리석은 짓을 클라우드에서 더 빨리 더 저렴하게 할 수 있다. 이런 문제를 피할 수 있는 몇 가지 가능성을 소개한다. 클라우드 옮기면서 데이터를 고친다. 다시 말하지만, 클라우드는 데이터를 고쳐주지 않는다. 온프레미스의 엉망진창 데이터는 클라우드의 엉망진창 데이터가 될 뿐이다. 문제를 찾아 바로잡을 수 있는 최선의 시간은 클라우드에 데이터를 재배치하기 전이다. 왜냐하면, 마이그레이션을 진행하면서 이미 데이터 사용에 혼란이 생겼기 때문이다. 이 단계를 빠뜨린 기업은 애플리케이션을 클라우드로 이전해 데이터와 연결하려고 할 때 문제에 부딪히기 마련이다. 온프레미스에서 동작했으니 클라우드에서도 동작하리라 생각할지 모르지만, 그렇지 않다. 대부분 기업은 최소한 일부 데이터 문제는 애플리케이션이 정상 동작하기 전에 고쳤어야 한다는 것을 알게 된다. 만약 애플리케이션을 컨테이너나 서버리스 등으로 이전해 ...

마이그레이션 데이터 SSOT 2022.03.23

IDG 블로그 | 클라우드 마이그레이션에는 6R 이상이 필요하다

클라우드 마이그레이션의 카테고리는 6R(Retire, Retain, Replace, Rehost, Re-platform, Refactor)이다. 필자도 6R이 어디서 어떻게 시작됐는지는 모르지만, 클라우드 마이그레이션 프로젝트의 발표자료에서 이런 저런 형태로 볼 수 있다.   6R이 중요한 이유는 단순하다. 기업은 워크로드가 있고, 이들 워크로드는 보통 애플리케이션 및 관련 데이터가 클라우드에 있지 않다. 그리고 기업은 이들 워크로드가 앞으로 어떻게 될지를 카테고리로 나누고자 한다. 이런 맥락에서 6R은 다음과 같은 의미를 갖는다.   Retire : 워크로드를 완전히 제거하거나 수명을 끝낸다. Retain : 현재 상태로 유지한다. Replace : SaaS 시스템이나 다른 유사한 대체제를 찾는다. Rehost : 들어서 옮긴다. 즉 별다른 수정없이 그대로 클라우드로 옮긴다. 예를 들어, 온프레미스 리눅스 환경을 클라우드 리눅스 환경으로 옮기는 식이다. 필자는 리호스트를 리팩터링과는 다르게 보는데, 리호스팅에서 애플리케이션은 클라우드에서 구동될 뿐, 클라우드 네이티브 서비스를 이용하지는 않는다. Replatform : 이전하고자 하는 클라우드에서 기존 플랫폼과 유사한 대체재를 찾을 수 없다면, 새로운 플랫폼으로 이전한다. 예를 들어, 리눅스를 윈도우로 바꾸는 식이다. 간혹 새로운 데이터베이스나 기타 플랫폼을 변경하기도 한다. 이 때문에 워크로드는 새로운 플랫폼에 맞도록 수정해야 하지만, 클라우드 네이티브 서비스를 반드시 이용해야 하는 것은 아니다. Refactor : 워크로드를 대폭 수정해 클라우드 보안이나 거버넌스, 모니터링, 감사 등 클라우드 네이티브 기능의 이점을 이용할 수 있도록 한다. 물론, Replace 대신 Repurchase를 넣을 수도 있고, 정의가 조금 다른 경우도 있다. 자신이 알고 있는 내용과 약간 차이가 있더라도 오늘의 주제에는 큰 문제가 되지 않는다. 기업은 수백 수천의 워크로드를 보고 6R 중...

마이그레이션 리호스팅 리팩터링 2022.01.12

"포스트그레SQL은 EDB와 함께" EPAS 기반의 오픈소스 DBMS 도입 전략과 국내 사례 - IDG Summary

오픈소스 DBMS로 마이그레이션하기 위해 기업은 적용 방식과 솔루션을 선택하고 애플리케이션 개발 시 유의 사항 등을 고려해야 한다. 많은 기업이 포스트그레SQL을 선택하고 EDB와 함께 마이그레이션하는 데에는 그만한 이유가 있다. 포스트그레SQL을 기반으로 기업 사용자의 어려움을 해결하는 데 초점을 맞춘 EPAS의 특징과 사례를 알아보자.   주요 내용  - 오픈소스 DBMS 도입, 대세로 자리잡다 - 오픈소스 DBMS 마이그레이션, 솔루션과 서비스 선택이 중요  - 마이그레이션을 위한 최고의 해답, EDB  - 카카오뱅크, EPAS 도입으로 안정성과 고가용성 확보  - KT, IT 비용 절감과 대외 사업 추진 효과

오픈소스 포스트그레SQL 마이그레이션 2022.01.11

공급난 타격의 전방위적 여파 "모든 워크로드가 클라우드로"

메시지 서비스 업체 인터롭 테크놀로지(Interop Technologies)는 고객에 서비스를 제공하고 자체 백오피스 시스템을 운영하는 용도로 3곳의 데이터센터를 소유하고 있다. 사용자 사이트에 있는 턴키 하드웨어/소프트웨어 솔루션을 판매하는 것도 인터롭의 업무다. 그러나 팬데믹이 초래한 하드웨어 공급난, 특히 서버와 스토리지의 공급 부족으로 인터롭은 사업에 심각한 타격을 입었다. 이 업체의 인프라 부문 이사 조슈아 콜라조는 “조달 부문을 들여다보면 여기도 저기도 온통 재고가 없어 처리하지 못한 이월 주문뿐”이라고 표현했다. 팬데믹 이전까지 이 업체는 많은 기회를 빠르게 잡을 수 있었다. 그러나 콜라조는 “그것은 이제 먼 과거의 이야기가 되었다. 애드호크로 대표되는 즉석 시스템은 도도새처럼 멸종한 것이나 마찬가지”라고 말했다. 인터롭은 계절성 공급망 붕괴에 적응하는 중이다. 특히 그 중에서도 연말 특수에 적응하는 중이었다. 그러나 현재는 움직임이 없이 멈춘 부문이 훨씬 많다.   주문량이 많을수록 문제는 커진다. 상자 2, 3개가량만 필요한 기업에 작은 시스템을 프로비저닝하는 데에는 보통 1개월이 걸렸지만, 콜라조는 “20, 30, 50개의 상자가 필요한 주문은 6개월을 기다려야 한다. 9~18개월이 걸리는 프로젝트를 고려하면 여기에 6개월을 더해야 하고, 상황이 더 어려워진다”고 설명했다.   워크로드를 클라우드로 옮기기 인터롭은 핵심 서비스를 프라이빗 데이터센터에서 클라우드로 옮기는 것을 이전부터 고려했지만 실행하기는 쉽지 않았다. 클라우드 제공업체는 메시지 서비스에 최적화되지 않았고, 인프라를 인터롭 자체 운영할 경우 유연성이 훨씬 컸기 때문이다. 콜라조는 “전체 스택을 직접 제어하면 아마존 로드 밸런싱보다 선택지가 조금 더 늘어난다. 아마존은 자신만의 방식이 있고, 모든 것을 클라우드 업체의 역량에 맞춰 조절해야 한다는 것이 단점”이라고 꼬집었다. “(그래서)시스템을 퍼블릭 클라우드에 넣을 수 있는 확실한 리팩터링 툴을 찾...

하이퍼스케일 클라우드 마이그레이션 2021.12.21

IDG 블로그 | AI는 클라우드 마이그레이션을 막지 못한다

데이터센터 인력에 관한 새로운 설문조사에 따르면, AI가 당장 데이터센터의 인력 부족 문제를 해소하는 데 도움이 될 것으로 보이지는 않는다. 대형 데이터센터 관리자와 운영자 중 약 50%는 기술 인력을 구하기 어렵다고 답했는데, 2018년의 38%에서 크게 증가한 수치이다. 응답자 4명 중 3명은 AI 기반 기술이 언젠가는 데이터센터에 필요한 인력을 줄여줄 것으로 본다. 하지만, 이런 변화가 일어나는 것은 5년 후에나 가능할 것이라고 답했다.    현재 일어나고 있는 변화를 살펴보자. 코로나19 팬데믹으로 데이터센터의 안정성이 큰 문제가 됐다. 봉쇄와 차단, 그리고 초기에는 일부 직원의 건물 진입 거부 등으로 많은 데이터센터 인력이 시스템에 접근하지 못해 가장 기본적인 운영 작업도 못하는 경우가 발생했다. 대부분 기업은 원래 계획했던 퍼블릭 클라우드 마이그레이션에 속도를 냈다. 하지만 아무리 서두른다고 해도 대부분 기업의 퍼블릭 클라우드 마이그레이션이 반환점을 도는 데만 몇 년은 걸릴 것이다. 데이터센터의 기술 인력도 충분하지 않은데, 클라우드로의 이전도 원하는 만큼 빨리 진행할 수 없다. 그렇다면, 앞으로 나아갈 수 있는 선택지는 무엇일까? 일부 팩션은 AI를 구세주로 밀고 있다. 좀 더 효과적인 데이터센터 운영에 초점을 맞춘 새로운 툴이 더 적은 인력으로 더 안정적인 운영이 가능한 새로운 데이터센터 모델을 구현할 수 있도록 해준다는 주장이다. 이들 툴은 클라우드 마이그레이션 전에 문제를 해결하거나 경우에 따라서는 퍼블릭 클라우드보다 더 저렴한 선택지를 제공할 수도 있다. 하지만 현실은 늘 계획대로 안되기 마련이다. 보고서에 나타나듯이, 대부분 데이터센터 운영자는 5년 내에는 AI가 사람의 운영 부담을 덜어줄 것이라 기대하지 않는다. 필자가 지난 30년 간의 기술 도입 패턴을 기반으로 예측하자면, 7~9년은 걸릴 것이다. 그렇다면, 5년 혹은 9년 후 데이터센터 모델의 가장 큰 문제는 무엇일까? 지금은 R&D ...

마이그레이션 자동화 AI 2021.10.13

클라우드 제공업체에 확인해봐야 할 8가지 질문

기업들은 클라우드의 힘을 빌려 고객, 파트너, 직원들과 연결하는 방법을 재정의하고, 디지털 제품과 서비스를 활용하여 새로운 기회를 창출하려고 애쓰고 있습니다. 제대로 된 클라우드 제공업체라면, 사용자가 변화에 신속하게 대응할 수 있게끔 규모를 조절하고, 회복력을 높이며, 비용을 줄이고, 하이브리드 또는 멀티클라우드 전략으로 어디에나 배포할 수 있도록 지원해 주어야 합니다. 모든 조직이 저마다의 혁신 전략을 수립하지만, 각 과정마다 클라우드로 향하는 수많은 경로를 지원하는 폭 넓은 서비스가 필요합니다. 다음 8가지 질문을 통해 클라우드 제공업체가 귀사 비즈니스의 디지털 트랜스포메이션을 이끌 수 있는 역량을 갖추었는지 확인해 보십시오. <8p> 주요내용 - 실행 가능한 애플리케이션의 종류 - 클라우드 마이그레이션에 필요한 사항 - 데이터 관리 서비스 - 하이브리드 클라우드 옵션 - 비용 가시성 - 인텔리전스와 분석

클라우드 마이그레이션 하이브리드 2021.10.06

IDG 블로그 | 클라우드옵스의 벽에 부딪혔을 때 해야 할 일

신임 CIO의 수요일 아침 9시. IT 운영 책임자와 긴급 줌 회의를 갖는다. 화면에 나타난 얼굴은 침울한 표정이며, 이유는 회의의 목적을 설명하면서 분명해진다. IT 운영팀은 올해 100만 달러의 예산을 받았는데, 예기치 않은 비용 때문에 40만 달러를 초과 사용해야 할 것으로 보인다. 최근 퍼블릭 클라우드로 이전한 일군의 애플리케이션과 데이터베이스를 운영하는 데 필요한 운영 인력과 툴 때문이다.   무슨 일이 일어난 것일까? ‘클라우드옵스의 벽(Cloudops wall)’에 부딪힌 것으로 보인다. 클라우드에 배치한 시스템 운영 비용을 20~30% 낮게 잡은 것이다. 많아도 온프레미스 시스템보다 10% 더 잡은 정도일 것이다. 실제로 업계에서는 운영 비용이 줄어들 것이라고 말한다. 하지만 현실은 몇 가지 일이 일어나기 마련이다. 첫째, 코로나19 팬데믹으로 많은 기업이 다음에 이전할 계획이었던 시스템을 클라우드로 옮겼다. 처음에 옮기지 않은 것은 더 복잡하고 설계도 좋지 않았기 때문이다. 게다가 이들 시스템은 새로운 방식으로 동작한다. 예를 들어, 데이터를 소비하는 클라우드 기반 데이터베이스는 같은 데이터센터에 있는 전통적인 데이터베이스와는 다르다. 둘째, 클라우드 마이그레이션이 속도전으로 이루어졌기 때문에 많은 실용적인 단계를 압축하거나 건너뛰었다. 클라우드 네이티브 서비스를 이용하는 데 필요한 리팩터링이나 일부 이전 시스템의 컨테이너화도 빼먹고 더 빠르고 저렴한 리프트 앤 시프트 프로세스를 선택했다. 마지막으로, 가장 중요한 문제는 회사 내의 누구도 이런 종류의 시스템을 대상으로 클라우드옵스를 수행해 본 적이 없다는 것이다. 예를 들어, 메인프레임 기반 시스템을 퍼블릭 클라우드 이전하는 것은 조금 더 현대적인 LAMP 스택을 이전하는 것과는 아주 다르다. 이런 기술력이 없다 보니, 계획 수립의 대부분이 어림짐작으로 이루어질 수밖에 없다. 클라우드옵스의 벽 문제를 바로잡는 몇 가지 방법을 소개한다. 첫째, 클라우드로 이전할 때 리팩...

클라우드옵스 리팩터링 최적화 2021.09.15

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

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

Copyright © 2022 International Data Group. All rights reserved.