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.

멀티클라우드

멀티클라우드 컨테이너 개발 플랫폼 8대 공급업체 및 선정 이유 : 포레스터 리서치

Forrester Research는 고객 분석 기술에 대한 29가지 기준 평가에서 가장 뛰어난 8개 업체(Canonical, D2iQ, Google, Mirantis, Platform9 Systems, Rancher, Red Hat-IBM, VMware)를 선정하고, 이들 업체를 연구 및 분석한 후 점수로 평가했습니다. 이 보고서는 각 공급업체를 측정한 방법을 설명하고 인프라 및 운영 전문가가 요구 사항에 맞는 업체를 선정할 수 있도록 지원합니다. <15p> 주요 내용 - 개발 경험, 운영 및 통합에서 차별화되는 공급업체 - Red Hat-IBM, Google, Rancher - VMware, D2iQ, Platform9 Systems - Mirantis, Canonical

멀티클라우드 컨테이너 포레스터 2021.04.14

"멀티클라우드에 범용성이란 없다" 그렇다면 해결책은?

멀티클라우드를 현실화할 때 필요한 ‘최소 공통 분모’ 범용 서비스는 아마도 클라우드 업체들이 혁신을 멈출 때에야 가능할 것이다. 필자가 오래 전부터 거듭 강조해 온 이야기다. 많은 업체가 여러 클라우드에서 워크로드를 실행하는 기능 판매에 열을 올리지만, 실제로는 업체마다 경쟁 클라우드에서는 쓸 수 없는 네이티브 서비스가 있다. 일종의 ‘불편한 진실’이다. 이 진실은 갈수록 더 확고해지고 있다.   마이크로소프트, 구글, 아마존 또는 알리바바가 하는 일을 대충만 훑어봐도 범용 서비스 같은 것은 없다는 것을 알 수 있다. 그렇다면 멀티클라우드가 완전히, 전적으로 죽었다는 뜻일까? 아니다. 몽고DB를 비롯한 여러 업체는 멀티클라우드가 죽지 않았다고 강하게 주장하는 중이다.   클라우드에는 범용이 없다 먼저, 워크로드가 업체를 가리지 않고 여러 클라우드에서 마법처럼 작동한다는 꿈에 대해 말해보자. 분석가 코리 퀸은 회의적이다. 코리는 이 개념에 다음과 같은 우려를 표했다. “모든 클라우드 제공업체 또는 기업의 자체 데이터센터에서 쉽고 매끄럽게 실행 가능한 워크로드를 구축한다는 개념은 분명 매력적이다. 그러나 그 현실성 수준은 개발자에게 “버그가 없는 코드를 쓰라”고 말하는 것, 또는 물리 모델 관점에서 분명 존재해야 하는 ‘구형 소(spherical cow)’를 정말 찾으려고 애쓰는 것과 비슷하다. 보기보다 훨씬 더 어렵다.” 소프트웨어(클라우드도 마찬가지)는 그런 식으로 움직이지 않는다. 여러 클라우드 업체의 노력 덕분에 컴퓨팅 및 스토리지 같은 클라우드 서비스는 서로 똑같이 닮아가는 것이 아니라 혁신적인 차별화 기능을 덧붙이고 있으며, 그에 따라 최소 공통 분모라는 우주는 계속 축소되는 중이다. 예를 들어 스토리지만큼 범용적인 것이 있을까? 물론 거의 모든 클라우드가 객체 스토리지나 블록 스토리지 같은 용어를 얘기하고 있다. 그러나 더 깊이 들어가서 예를 들어 구글이 스토리지를 구축하는 방식을 보면 갑자기 똑같아 보이지 않는다. 구글은...

멀티클라우드 마이크로서비스 2021.04.12

IDG 블로그 | 멀티클라우드 아키텍처 3대 실수

멀티클라우드 아키텍처의 최적화는 쉽게 말해, 비용을 최적화하는 것은 물론, 비즈니스 요구사항에 맞춰 아키텍처를 최적화할 수 있도록 기술을 구성하는 역량이다. 클라우드 기술에 사용하는 비용 한푼 한푼이 극대화된 가치로 비즈니스로 되돌아오도록 하는 것이다.   사실 온전히 최적화된 클라우드 아키텍처는 드물다. 필자는 주된 원흉으로 복잡성에 대한 편향을 지적한 바 있다. 하지만 근본 원인은 배치와 운영이 이루어진 다음에야 아키텍처 최적화에 관해 생각하기 때문이다. 사실 그때는 너무 늦다. 그렇다면, 멀티클라우드 아키텍처는 어떨까? 온전히 최적화되지 못하는 상태에 이르지 못하는 주된 원인은 무엇일까? 세 가지 주된 원인과 그 해법을 소개한다. 너무 많은 기술을 이용한다. 과잉은 복잡성의 사촌이다. 멀티클라우드 아키텍트와 개발팀은 종종 가능한 한 많은 기술을 멀티클라우드에 넣으려 애쓰곤 하는데, 주로 ‘구체화할 수도 있는’ 모든 종류의 요구사항에 대응하는 식이다. 필요한 것은 하나의 서비스 거버넌스 기술일 텐데, 세 가지를 사용한다. 스토리지 서비스도 하나면 충분한데, 일곱 가지를 사용한다. 결국은 더 많은 비용을 들이고도 비즈니스는 추가 가치를 얻지 못한다. 모든 아키텍트는 아직 도달하지 않은 미래를 대비해 아키텍처를 구축하기 때문에 매우 어려운 문제이다. 아키텍트는 내장 미러링 기술을 갖춘 데이터베이스를 선택하는데, 나중에 완전히 분산된 데이터베이스 환경으로 이전할 수도 있기 때문이다. 하지만 몇 년은 뒤의 일이다. 따라서 데이터베이스의 종류는 정말로 충분한 이유가 없다면 2~4개 정도이다. 최적화된 상태에 근접하기 위해서는 ‘최소한의 실행 가능성’에 맞춰 구축해야 한다는 것을 잊지 말기 바란다. 구체적인 요구사항에 맞춰 구축하지 않는다. 요구사항이란 엄격하고 구체적이며 즉각적인 것으로, 이해하기도 쉽다. 주로 멀티클라우드 아키텍처가 어떤 것이 될지 결정하기 때문이다. 실제로 요구사항이 아키텍처가 해결해야 하는 문제의 패턴을 개략적으로 그려준다....

멀티클라우드 아키텍처 최적화 2021.04.12

IDG 블로그 | 멀티클라우드 배치를 망치는 확실한 방법 3가지

플렉세라(Flexera)의 보고서는 멀티클라우드 배치가 점점 퍼블릭 클라우드 서비스 업체 간의 경쟁이 되고 있음을 보여준다. 응답 기업 중 50%는 중요한 워크로드를 AWS에, 41%는 애저에, 22%는 구글 클라우드에 배치했다고 답했다. 2020년 폭발적인 성장 속에서 흔한 일이었으며, 올해 역시 이런 성장세가 계속될 것이다. 솔직히 말해 필자는 어느 업체가 경쟁에서 이겨 최고의 퍼블릭 클라우드 서비스 업체가 되는지에 관심이 없다. 기업이 비즈니스 문제를 해결할 수 있도록 이들 클라우드를 얼마나 잘 이용하는지가 더 중요하다.   기업이 멀티클라우드를 선택하는 것은 종속성을 피하려는 것보다는 애플리케이션을 구축하고 클라우드로 마이그레이션하는 데서 선택권을 가지려는 이유가 크다. 대부분 기업은 두 곳 이상의 퍼블릭 클라우드를 사용하는데, 바로 멀티클라우드이다. 하지만 다음에 소개하는 세 가지 권장사항을 지키지 않으면, 멀티클라우드 배치에 실패할 수도 있다. 크로스 클라우드 툴을 선택한다. 멀티클라우드 솔루션을 구축할 때 최악의 선택은 각각의 클라우드 내에 있는 사일로 툴과 기술을 이용하는 것이다. 보안, 거버넌스, 운영 툴 등도 포함된다. 이런 선택의 결과는 각 퍼블릭 클라우드용 툴이다. 이 모든 툴을 클라우드옵스팀에 넘겨주면, 최소한 9가지 이상의 툴을 다루어야 한다. 툴마다 요구하는 기술과 훈련도 다르다. 복잡성이란 보통 최종 멀티클라우드 배치 환경이 현실적으로 운영할 수 있는 상태가 아니라는 의미이다. 여러 클라우드에 걸쳐서 동작하는 공통 툴을 찾아야만 한다. 클라우드 추가에 따르는 비용을 이해한다. 두 가지 퍼블릭 클라우드를 지원한다면, 하나 더 추가한다고 해도 비용이 같아야 한다. 하지만 그렇지 않다. 이때 비용은 특정 퍼블릭 클라우드로 무엇을 하느냐에 따라 달라진다. 만약 애플리케이션과 연결된 데이터베이스를 한 클라우드에 100개, 또 한 클라우드에 150개를 두고 있는데, 여기에 단 5개의 애플리케이션을 위한 퍼블릭 클라우드를 ...

멀티클라우드 크로스클라우드 2021.03.29

성숙기 들어선 클라우드 세계의 새로운 문제점 7가지

일찌기 한 현명한 클라우드 설계자는 “나에게는 99가지 문제가 있지만 클라우드는 거기에 끼지도 못한다”는 말을 했다. 클라우드가 등장하면서 애플리케이션과 서비스의 대규모 운영이 훨씬 더 쉬워졌다. 그러나 클라우드 컴퓨팅에도 나름의 문제는 있다.   온프레미스 시절에는 코드 일부에 문제가 있어도 ‘고작해야’ 성능 저하나 중단을 초래했을 뿐이다. 지금은 버그가 있으면 AWS가 사용자의 주머니를 뒤진 다음 거꾸로 매달아 마지막 동전 하나까지 탈탈 털어내 가져간다고 할 만큼의 비용이 발생한다.   아마존 키네시스나 애저 코스모스 DB 또는 구글 클라우드 빅테이블을 사용하기는 아주 쉽다. 그러나 호텔 캘리포니아의 가사처럼 언제든 체크아웃할 수는 있을지 몰라도 절대로 클라우드를 떠날 수는 없을 것이다. 순수 인프라 서비스 비용은 시간이 지나면서 하락했지만, 클라우드 제공업체의 전반적인 가격은 별다른 변화가 없다(납득할 수도 없다).   게다가 복잡한 것도 많고 안정적으로 안전하게 유지해야 하는 인스턴스도 넘쳐난다. 쿠버네티스 구성은 또 왜 이렇게 긴 것일까?   말하자면 끝도 없다. 그래서 인터넷에서 가장 중요한 클라우드 기반 서비스를 책임지는 담당자들이 그동안 어떤 문제에 직면했고 그 문제를 어떻게 해결하거나 완화했는지를 물었다.   비용 관리 한때 AWS가 저렴하다고 생각했던 시절이 있었다. 코베오(Coveo)의 공동 창업자이자 기술 부문 선임 부사장인 마크 샌패콘은 “온프레미스에 실제로 존재하는 하드웨어가 있다면 그 하드웨어를 사용한다. 돈을 주고 구매한 내 것이고, 전기료도 내가 내고, 원하는 만큼 사용할 수 있기 때문”라고 말했다.    샌패콘은 이어 “그러나 200명 이상의 개발자가 있는 코베오 같은 기업에서는 새 전화기나 책상 또는 의자를 구매할 때도 회사 정책에 따라 승인을 받아야 한다. 하지만 직원들은 이 정책을 무시하고 AWS 콘솔로 들어가서 시간당 25달러가 청구되는 새 머신을 가동하고...

규정준수 깃옵스 멀티클라우드 2021.03.24

IDG 블로그 | 클라우드 개발 툴과 인프라를 고르는 법

툴과 기술은 기술 솔루션을 구성하는 것으로, 무엇인가를 구축하고 자원을 이용하고 인프라를 사용하는 방법을 결정한다.  최근 필자는 툴이나 기술을 잘못 선택해 실패한 프로젝트를 여러 건 봤다. 우리는 이 문제를 몇 년째 다루고 있지만, 지금까지도 해법을 찾지 못한 상태이다. 게다가 상황은 점점 더 나빠지고 있다.   현실은 모든 것이 변하고 있기 때문이다. 최근 개발, 테스트, 배치 영역에 새로 들어오는 기술과 툴은 처음 적용하는 것이라 어떤 툴과 기술을 골라야 할지 실마리가 거의 없다. 다시 말해, 위험을 줄일 수 있는 방법이 없다. 여기 몇 가지 조언을 소개한다. 너무 앞서거나 뒤처지지 않는다. 개발 세계에 있는 사람 대부분은 툴과 플랫폼, 기타 기술에 너무 큰 비중을 둔다. 개발자가 무엇을 왜 구축해야 하는지 알기도 전에 툴과 기술이 선택된다. 반대로, 어떤 사람은 너무 기다린다. 설계의 중요한 부분에 영향을 미치는 약간의 알지 못한 제약을 찾는 데 너무 많은 시간을 들인다. 예를 들어, 원래 목표로 했던 데이터베이스가 지원되지 않는 등의 상황을 걱정하는 것이다. 위험을 줄이거나 제거하기 위해 툴과 기술은 적절한 순서에 따라 선택해야 한다. 비즈니스를 이해한다. 개발이나 인프라를 특정 솔루션 업체에 맞춰 표준화했는데, 그 솔루션 업체가 “망했다”는 악몽 같은 이야기를 종종 듣는다. 해당 업체가 더 큰 업체에 인수되면서 지원이 끊어지거나 더 이상 사용할 수 없게 되는 상황이다. 이런 상황에서 할 수 있는 것은 많지 않다. 하지만 이런 상황이 발생하면 어떤 보호 방안이 있는지 솔직하게 물어볼 수는 있다. 만약 솔루션 업체의 사업이 중단되면, 소스 코드에 대한 권리를 고객사가 갖거나 다른 툴과 기술로 이전하는 비용을 솔루션 업체가 지불하는 계약 조건을 본 적이 있다. 또 하나의 전략은 오픈소스이다. 단지 코드만 액세스하는 것이 아니라 같은 오픈소스 시스템을 판매하고 지원하는 다른 업체도 이용할 수 있다.  마지막으로 ...

멀티클라우드 복잡성 선택 2021.03.22

하이브리드 클라우드 플랫폼의 이점 - 한국 기업의 관점

이상적인 플랫폼이라면 소규모 개발 팀 및 조직뿐 아니라, 대규모 엔터프라이즈 비즈니스에도 맞게 규모를 조정하고 이들 모두를 지원할 수 있어야 합니다. 그리고 세계 도처에 있는 데이터센터에 배포할 수 있어야 합니다. 하이브리드 멀티클라우드 환경의 이점을 실현하는 데 도움이 되는 클라우드 관리 플랫폼을 구축하기 위한 다섯 가지 주요 단계를 정의했습니다. 이를 위해 클라우드 선도 그룹에 속한 기업들이 경쟁 우위를 달성하기 위해 조직 내에 멀티클라우드 플랫폼을 위한 전략을 세우고, 이를 설계, 이전, 구축, 관리하는 방식을 알아보았습니다.   <20p> 주요 내용 - 전략 수립: 운영 모델과 비즈니스 트랜스포메이션 연계 - 설계: 멀티클라우드 관리 및 트랜스포메이션 여정 개발 - 이전: 하이브리드 클라우드 플랫폼으로 이동 - 구축: 효과적인 클라우드 관리로 우수한 성과 실현 - 관리: 비즈니스 트랜스포메이션 본격화

하이브리드 멀티클라우드 디지털트랜스포메이션 2021.03.15

IDG 블로그 | 멀티클라우드 아키텍처 분해의 단순화

아키텍처란 주장과 같다. 모두가 자신만의 편견을 기반으로 한 각자의 주장이 있다. 어떤 아키텍처는 오픈소스 솔루션만을 사용할 것으로 고집하고, 특정 퍼블릭 클라우드나 데이터베이스를 고집하기도 한다. 이들 편향성은 종종 어떤 솔루션을 채택하고, 그 선택이 얼마나 좋고 나쁜지를 결정하는 동인이 된다. 문제는 이런 편견을 기반으로 구성요소나 기술을 선택하면, 흔히 비즈니스의 핵심 요구사항을 더 잘 만족하는 기술을 고려하지 않는다는 것이다. 비슷하기는 하지만 절대 100% 최적화되지 않는 아키텍처는 이렇게 만들어진다.    최적화란 비용은 최소로 유지하면서 효율은 극대화하는 것을 말한다. 똑같은 문제를 10명의 클라우드 아키텍트에게 풀어보라고 하면, 10가지 서로 다른 해법이 나오는 것은 물론, 비용도 많으면 1년에 수백만 달러까지 차이가 날 것이다. 게다가 이 10가지 해법은 어쨌든 돌아간다. 최적화가 덜 된 아키텍처라도 기술 계층의 형식으로 비용을 투여하면 성능이나 탄력성, 보안 등의 문제를 완화할 수 있다. 이들 모든 계층은 완전히 최적화된 멀티클라우드 아키텍처와 비교해 10배나 많은 비용이 든다.  그렇다면 최적화된 멀티클라우드 아키텍처를 어떻게 구축할 것인가? 멀티클라우드 아키텍처 분해가 최상의 접근 방법이다. 새로운 문제를 해결하는 데 오래 전부터 사용하던 기법이다. 모든 계획된 솔루션을 기능 단위로 분해하고, 각각을 자체 이점으로 평가해 핵심 구성요소가 최적인지를 알아보는 방법이다. 예를 들어, 도입할 계획인 데이터베이스 서비스만 보는 것이 아니라 해당 데이터베이스 서비스의 구성 요소, 즉 거버넌스와 데이터 보안, 데이터 복구, I/O, 캐싱, 롤백 등을 살펴본다. 데이터베이스만 괜찮은 것이 아니라 서브시스템까지 잘 맞도록 하는 것이다. 간혹 서드파티 제품이 더 나을 때도 있다. 컴퓨트, 스토리지, 개발, 운영 등의 각 구성요소를 해부해 핵심 문제를 해결할 수 있는지, 멀티클라우드 아키텍처의 사용례를 제대로 지원할 ...

멀티클라우드 아키텍처 분해 2021.03.08

IDG 블로그 | 앱 하나를 여러 클라우드에 분산하면 생기는 3가지 문제

분산 애플리케이션을 여러 퍼블릭 클라우드 서비스 업체에서 구동하기 전에 이런 구성의 많은 단점과 적은 기회를 잘 이해해야 한다. 필자는 수년 동안 분산 애플리케이션을 구축했다. 단순화해서 말하자면, 애플리케이션과 데이터를 부분 부분으로 나눠서 최고의 성능과 안정성을 제공하는 플랫폼에서 구동하는 것이다.  과거에는 애플리케이션을 x86 서버 같은 좀 더 작은 하드웨어 플랫폼에 배치했다. 그런데 분산 배치가 필요해졌다. 분산 처리를 사용하면서 더 큰 처리 부하로 확장할 수 있게 됐고, 액티브/액티브 페일오버 시스템을 구성해 한 시스템에서 장애가 생기면 다른 시스템이 즉각 백업할 수 있도록 했다.   이런 작업이 퍼블릭 클라우드가 등장하면서 대부분 필요없어 졌다. 퍼블릭 클라우드는 테넌트 관리를 통해 시스템 분산을 수행하고, 실질적으로 어떤 플랫폼, 어떤 플랫폼 구성도 구성할 수 있기 때문에 확장성과 복구성을 제공한다. 이를 인트라클라우드(Intracloud)라고 한다. 이제 멀티클라우드가 중요해졌고, 필자도 이와 관련된 질문을 많이 받는다. 애플리케이션이나 애플리케이션 데이터의 일부를 다른 클라우드 브랜드에 배치해야 하는 이유가 있는가? 만약 있다면, 이상적인 방법은 무엇인가? 이런 질문에 대답하는 가장 좋은 방법은 예제를 살펴보는 것이다. 유통 매장의 영업 애플리케이션이 있는데, 사용자 인터페이스 부분은 AWS에서, 데이터베이스는 구글에서, 핵심 거래 처리 시스템은 애저 클라우드에서 구동한다고 생각해보자. 여기서 좀 더 쪼개서 애플리케이션의 일부는 온프레미스에서도 구동한다. 이런 환경 구성을 만들어낼 수는 있다. 하지만 실행 가능성부터 장기적인 운영, 복잡성, 비용 등에 우려를 제기하지 않을 수 없다. 보안은 말할 것도 없다. 다시 말해, 할 수 있다고 꼭 해야 하는 것은 아니다. 필자가 지난 몇 년 동안 이런 종류의 아키텍처 몇 가지를 구축하며 알아낸 것은 다음과 같다.   지연이 값비싼 문제가 될 수 있다. 한 퍼...

크로스클라우드 인트라클라우드 멀티클라우드 2021.03.03

글로벌 칼럼 | 클라우드에서 오픈소스의 진정한 가치

클라우드에서 오픈소스를 구동한다고 해서 업체 종속을 막아줄 것이라 생각한다면, 오산이다. 하지만 오픈소스는 분명 개발자에게 자유와 독립을 가져다준다. 최근 IBM의 후원으로 오릴리 미디어가 진행한 설문조사인 ‘클라우드 시대 오픈소스의 가치’에는 희망적인 생각이 가득하다. 예를 들어, 3,400명 이상의 응답자 중 70%가 오픈소스 기반의 클라우드 서비스 업체를 더 선호한다고 답했다. 오픈소스 지지자에게는 대단한 수치이다. 하지만 ‘오픈소스 기반’이 어떤 의미인지를 물어보면, 사정이 달라진다. 결국 현존하는 모든 소프트웨어 제품은 오픈소스를 기반으로 하기 때문이다. 그리고 79%의 응답자는 클라우드에서 업체 종속을 방지하기 위해 오픈소스로 전환했다고 답했다. 이 이야기도 여러 가지 이유로 다소 우스꽝스러운 것이 사실이다.   이렇게 오픈소스에 우호적인 응답 이면에 한 가지 눈에 띄는 사실이 있다. 클라우드 전문 기술 솔루션은 개발자가 코드를 더 빨리 출하하는 데 도움이 되지만, 오픈소스 기술은 개발자가 특정 클라우드 서비스 업체와 독립적으로 자신의 경력을 쌓을 수 있도록 해준다. 다시 말해, 오픈소스는 궁극적인 경력 관리 기술이다.   오픈소스의 마법 같은 현실주의 그렇다면, 미신으로 돌아가 보자. 우선, 약 55%의 응답자가 ‘단일 클라우드 서비스 업체에 특화된 클라우드 컴퓨팅 기술을 배우는 것은 경력 성장을 제한한다”고 답했지만, 모든 개발자 대부분이 정확하게 이렇게 한다. 이유는 대부분 기업이 클라우드 서비스 업체 한 곳에 중점을 두기 때문이다. 물론, 많은 기업이 결국에는 서로 다른 애플리케이션이나 인프라를 다양한 클라우드 서비스 업체로부터 사용한다. 하지만 필자는 ‘어쩌다 보니 멀티클라우드’이지 ‘의도한 멀티클라우드’라고 생각하지 않는다. 의도한 멀티클라우드도 있지만, 매우 드물다. 전임 시트릭스 부사장 크리스티안 레일리가 말했듯이 “언제나 그렇듯 문제는 대체 가능성의 부족이다. 대체 가능성은 매출을 끌어올리지 않는다. 서비스 ...

경력개발 업체종속성 멀티클라우드 2021.02.23

IDG 블로그 | 멀티클라우드 아키텍처에 반드시 있어야 하는 3가지

대부분 클라우드 아키텍트는 자신이 사는 세상이 갑자기 이기종 환경이 되었다는 것을 알게 된다. 한때는 퍼블릭 클라우드 서비스 업체 한 곳에만 집중할 수 있었는데, 지금은 혼합체 안에 최소한 서너 곳의 퍼블릭 클라우드가 있다. 이에 따라 아키텍처 패턴은 인트라 클라우드(Intra Cloud)에서 인터 클라우드(Inter Cloud)로 바뀌었는데, 바로 복잡성과 위험성이 도사리고 있는 지점이다.   결과적으로 아키텍트라면, 필자를 포함해 모두가 대다수 기반 서비스를 포괄할 수 있도록 확인하는 과정을 함께 마련하고 있다. 마치 비행사가 비행 전 점검 목록을 사용하는 것 같다. 여기에는 크로스 클라우드 거버넌스와 보안, 운영 등등이 포함되어 있다. 하지만 성공적인 멀티클라우드를 위해 필수적인 몇 가지를 빠뜨리곤 하는데, 가장 중요한 세 가지를 소개한다. 중앙집중화된 크로스 클라우드 사용자 계정 관리. 멀티클라우드를 제대로 구현하려면, 퍼블릭 클라우드 서비스 업체의 그룹을 가능한 한 하나의 클라우드로 취급해야 한다. 공통의 사용자 관리 계층이 있어서 각 클라우드와 이른바 ‘네이티브’하게 상호작용하는 단일 제어점에서 사용자 계층을 추가하고 삭제하고 변경할 수 있어야 한다.  중앙집중화된 계정 관리는 사용자 관리를 한층 덜 번거롭게 만드는 것 외에도 각 클라우드 서비스 업체에 보여주는 ID를 일관성 있게 만들어 보안도 개선한다. IDAM 시스템도 한층 더 일관성을 갖게 되며, 이에 따라 클라우드 보안 역시 좀 더 안전해진다. 크로스 클라우드 자원 관리. 이 범주는 AI옵스 툴, 클라우드 관리 플랫폼 툴 등 스토리지나 컴퓨트, 프로비저닝 같은 자원 사용을 모니터링하는 어떤 것도 될 수 있다. 특히 중요한 것은 자동화된 디프로비저닝(Deprovisioning)으로 사용하지 않는 자원을 자원 풀로 되가져오는 것이다. 퍼블릭 클라우드 서비스 업체가 이런 자원에 과금하는 것을 막을 수 있다. 필자는 엄청난 양의 클라우드 자원을 할당하고는 중단하지 않아 ...

멀티클라우드 아키텍처 일관성 2021.02.15

글로벌 칼럼 | 멀티클라우드 '관리 복잡성' 해법은 네트워킹 소프트웨어

복수의 퍼블릭 클라우드에서 애플리케이션을 배포, 운영하는 것은 오늘날 IT 리더의 가장 큰 숙제다. 이런 작업에 어려움을 겪고 있다면 네트워킹 소프트웨어로 눈을 돌릴 필요가 있다.   애플리케이션을 클라우드 인프라로 전환하려면 확장성과 성능 그리고 무엇보다 자동화를 고려해야 한다. 문제는 이 모두를 만족하기가 쉽지 않다는 사실이다. 인프라에 대한 가시성이 제한되고 IaaS 플랫폼마다 독자적인 네트워킹과 보안 제어 기술을 사용하기 때문이다. 이런 독자 기술 때문에 멀티클라우드 운영 작업에 수작업이 많아지고 업무 시간도 늘어나게 된다. 그래서 결국 IT팀은 애플리케이션 성능 문제를 신속하게 해결하지 못하고 외부 공격에 대응하거나 비용을 줄이는 데도 어려움을 겪는다. IaaS 리소스의 민첩성과 물리 네트워크의 보안과 관리, 제어 편의성을 결합하는 새로운 해법이 필요한 이유다. 필자가 생각하는 대안은 네트워킹 소프트웨어다. 이런 소프트웨어를 멀티클라우드 인프라에 설치하면 클라우드 네이티브 성능을 활용해 강화된 보안과 가시성, 제어 기능을 사용할 수 있다. IT팀이 자동화를 통해 클라우드 기반 애플리케이션을 빠르게 배포하고, 각 클라우드 업체가 제공하는 네이티브 툴을 추상화해 관리할 수 있다.   멀티클라우드에 대한 필요 멀티클라우드는 여전히 매력적이다. 그러나 각 클라우드 업체마다 상이한 애플리케이션 성능과 혜택을 제공하고 개발 생태계는 종종 특정한 기업 요구에 최적화되기도 한다. 더구나 일부 애플리케이션은 보안과 다른 이유로 클라우드에서 운용할 수 없어, 기업의 온프레미스 데이터센터도 앞으로 계속 존재할 것이다. 그 결과 IT 조직은 애플리케이션에 따라 가장 적합한 플랫폼에서 운용할 수 있도록 다양한 프라이빗 클라우드와 퍼블릭 클라우드, SaaS 플랫폼을 모두 관리해야 하고, 동시에 사용자에게 최고 수준의 경험을 제공하는 어려운 과제에 직면해 있다.   멀티클라우드 네트워킹의 어려움 클라우드 업체는 기본적으로 보안, 네트워킹, M...

멀티클라우드 관리복잡성 네트워킹소프트웨어 2021.02.04

애플리케이션 현대화 시간을 단축하는 방법

오늘날 기업들은 퍼블릭 클라우드로의 마이그레이션과 별도로 애플리케이션을 현대화하고 싶어합니다. 온프레미스 솔루션과 클라우드 기반 솔루션이 혼합된 마이그레이션을 원하기도 하지요. 또한 기업은 멀티 클라우드를 사용할 수 있기를 원합니다. 플랫폼에 구애받지 않는 애플리케이션을 조율하기 위한 사실상의 표준이 된 Kubernetes에 대해 살펴보시고, 애플리케이션 현대화에 드는 시간을 단축하는 방법을 알아보세요. <19p> 주요 내용 - 인프라와 애플리케이션의 분리를 통한 빠른 애플리케이션 현대화 - 클라우드팀 분리: pod 및 서비스 프록시 활용  - Istio 제로 트러스트 보안 및 클라우드 보증 현대화를 활용한 마이크로서비스 및 수명 주기 관리  - 선언적 구성 모델 및 Kubernetes

이스티오 하이브리드 멀티클라우드 2021.02.02

Anthos - 하이브리드 멀티 클라우드 애플리케이션 관리를 위한 최고의 플랫폼

엔터프라이즈 애플리케이션은 견고하고 복잡하며 구축 및 유지 관리 비용이 많이 들 수 있습니다. 이러한 문제를 해결하기 위해 Google Cloud는 Anthos를 개발했습니다. 기존 앱을 현대화 하고 싶으십니까? 클라우드 네이티브 앱을 구축하고 싶으십니까? 두 경우 모두 Anthos가 해답입니다. 이 백서를 읽고 Anthos 플랫폼의 각 계층을 자세히 살펴보시고, 클라우드 시대를 위한 애플리케이션 현대화를 간단하고 안전하며 비용 효율적으로 하는 방법을 알아보세요. <41p> 주요 내용 - Anthos GKE를 통한 컨테이너 조정 및 관리 - Anthos Config Management를 활용한 정책 설정 - Anthos Service Mesh를 통한 서비스 모니터링 및 관리 - Cloud Run for Anthos로 실현되는 모든 환경의 서버리스화 - Anthos용 애플리케이션 개발 - Anthos 및 GitOps를 사용한 안전한 소프트웨어 플랫폼 설계

안토스 하이브리드 멀티클라우드 2021.02.02

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

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

Copyright © 2022 International Data Group. All rights reserved.