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.

이식성

IDG 블로그 | 서버리스 컴퓨팅의 진정한 가치

서버리스 컴퓨팅에 대해 들어본 적이 있는가? 무슨 이야기를 들었든 서버가 없는 것은 절대 아니다. 특정 작업을 완료하는 데 필요한 백엔드 서버의 배치를 자동화한 것일 뿐이다. 지금은 컨테이너부터 전통적인 개발 시스템까지 수많은 종류의 서버리스 시스템이 있다. 이들 모두가 내세우는 것은 한 가지, 필요할 때 서버를 구성하지 않고도 수직 수평 확장을 자동으로 수행한다는 것이다.   개발자는 애플리케이션을 실행하기 전에 얼마나 많은 스토리지와 서버를 배치해야 할지 가늠할 필요가 없다. 서버리스 시스템이 대신 결정하고, 런타임에 필요한 자원을 할당하고, 더 이상 필요없을 때는 배치를 해제한다. 서버리스의 핵심 가치는 자동화이다. 얼마나 많은 자원이 필요할지 파악하느라 애쓸 필요가 없다. 너무 많은 자원을 배치하거나 혹은 사용이 끝난 자원을 회수하는 걸 잊어버리면, 월말에 엄청난 클라우드 비용 고지서를 받게 된다. 너무 적은 자원을 배치하면 서비스를 개설하고 얼마 후 애플리케이션이 제대로 동작하지 못하는 것을 지켜봐야 한다.  필자는 개인적으로 자원이 남는 편이었으며, 그때마다 인간인 필자에게 필요한 자원을 선택하도록 한 클라우드 서비스 업체에 화를 냈다. 사용자가 틀릴 수 있다는 문제가 아니다. 얼마나 틀리느냐의 문제이다. 그래서 필자는 서버리스 컴퓨팅 개념을 좋아한다. 고객사가 필요한 자원을 정확하게 파악하고 있는 것이 아니라면, 필요한 용량을 추정하려 애쓰는 것보다 전혀 새로운 클라우드 네이티브 애플리케이션으로 가는 것이 더 안전하다. 게다가 용량은 계속 늘리고 바꿀 수 있다. 필자는 여기에 서버리스 컴퓨팅의 진정한 가치가 있다고 생각한다. 물론 서버리스가 직접 자원을 할당하는 것보다 비싸다는 반론이 있다. 사실이다. 하지만 이런 비교는 사용자가 최적의 자원 구성을 선택하고, 정확한 시간, 정확한 상황에 자원을 할당하고 회수하는 것을 전제로 한다. 누군가는 이렇게 할 수 있을지 모르지만, 대부분은 그렇지 못하다. 이외에도 서버리스 컴...

서버리스 자동화 이식성 2021.12.13

멀티클라우드 정책 및 프로세스 이식성을 위한 OPA 활용

멀티클라우드 전략이 완전한 주류로 부상함에 따라 기업과 개발팀은 여러 클라우드 환경에 걸친 일관성있는 접근 방법을 찾아야 한다. 멀티클라우드 자체는 보편적이다. 클라우드를 사용하는 기업 중 거의 전부인 93%가 멀티클라우드 전략을 두고 있다. 즉, 아마존 웹 서비스, 구글 클라우드 플랫폼 또는 마이크로소프트 애저와 같은 퍼블릭 클라우드 서비스 업체를 두 곳 이상 사용한다. 또한 이들 기업 중 87%는 퍼블릭 클라우드와 온프레미스 클라우드 환경을 혼합한 하이브리드 클라우드 전략을 시행 중이다.    기업이 애초에 클라우드로 전환하는 주된 이유는 성능과 가용성, 확장성, 그리고 컴퓨팅, 스토리지, 네트워크, 데이터베이스 기능의 비용 효율성을 개선하는 데 있다. 그 이후 주로 업체 종속을 피하기 위한 이유로 멀티클라우드 전략을 도입한다.  그러나 멀티클라우드는 최초의 클라우드 네이티브 논리에서 확장된 또 다른 매력적인 가능성을 제시한다. 바로 클라우드 컴퓨팅 아키텍처를 추상화해서 클라우드 서비스 업체 간에 자동으로, 단절 없이(또는 신속하게) 이식해 성능, 가용성, 비용 절감을 극대화하거나 서비스 업체 한 곳이 다운되더라도 업타임을 유지할 수 있는 역량이다. 쿠버네티스와 같이 AWS, GCP, 애저, 프라이빗 클라우드를 불문하고 어느 환경에서나 동일하게 실행되는 플랫폼을 보면 기업이 이와 같은 멀티클라우드 이식성을 달성하는 방법을 어느 정도 알 수 있다.  그러나 명쾌한 이론과 달리, 실제 환경에서의 멀티클라우드 이식성은 복잡한 문제다. 서비스 업체별 기능, API, 이식하기 어려운 데이터 레이트와 같은 종속성으로 인해 진정한 애플리케이션 및 워크로드 이식성을 달성하려면 복잡한 과정이 필요하다. 실제로 멀티클라우드 이식성은 조직이 여러 클라우드 환경 간에 일관성을 달성해야만 제대로 구현된다. 이를 위해 기업에는 여러 솔루션과 클라우드, API에 걸쳐 작동하면서 클라우드 네이티브 비즈니스 간에 기술과 사람, 프로세스를 손쉽게...

정책 OPA 클라우드네이티브 2020.12.14

IDG 블로그 | 컨테이너가 정말로 좋은 선택일까?

451 리서치의 최신 보고서에 따르면, 애플리케이션 컨테이너 시장은 2016년 7억 6,200만 달러 규모에서 2020년에는 27억 달러 규모로 성장한다. 전체 클라우드 기술 시장에서는 작은 비중에 불과하지만, 애플리케이션 컨테이너는 2020년 40%의 높은 성장률을 기록할 것이다.   이런 성장에는 과대 포장과 실질적인 수요, 그리고 선도업체에서 이룬 약간의 성공이 뒤섞여 있다. 클라우드 컴퓨팅 기술 스택에는 컨테이너가 유효한 곳이 많다. 다시 말해, 컨테이너는 애플리케이션을 클라우드로 옮기거나 클라우드에서 완전히 새로운 애플리케이션을 구축할 때 직면하는 핵심 문제를 해결한다. 바로 이식성과 확장성, 개방성, 일관성이다. 하지만 컨테이너가 모든 문제의 해법은 아니다. 컨테이너와 컨테이너 오케스트레이션(쿠버네티스)의 가장 큰 문제는 이 기술을 잘못 적용하는 것이다. 세 가지 문제를 살펴보자. 1. 애플리케이션 아키텍처가 핵심이다. 컨테이너에 코드를 넣고 실행하는 것은 어렵지 않다. 하지만 컨테이너는 애플리케이션 아키텍처가 컨테이너를 염두에 두고 설계되었거나 컨테이너에 맞춰 변경되었을 때 가장 잘 동작한다. 컨테이너는 본질적으로 분산 처리 지향적이다. 최적의 방식으로 컨테이너를 사용하기 위해서는 보통 애플리케이션을 변경하거나 분해할 수 있어야 한다. 게다가 애플리케이션이 데이터와 긴밀하게 묶여 있다면, 애플리케이션에서 데이터를 분리하지 않는 한 컨테이너로 성공하기 어렵다. 2. 컨테이너는 전통적인 애플리케이션 개발보다 비용이 더 많이 든다. 컨테이너 기술을 활용하기 위해 필요한 애플리케이션의 변경은 이른바 “컨테이너세(Container Tax)”의 일부이다. 애플리케이션을 컨테이너에 맞춰 수정하거나 컨테이너 지향적인 새 애플리케이션을 구축하는 데 드는 추가 비용이다. 정확한 숫자를 계산하기는 어렵지만, 필자의 경험상 평균 35%는 더 든다. 물론 35%의 추가 비용은 컨테이너를 통해 얻는 이식성과 확장성, 민첩성으로 보상된다. 기업마다 환경...

확장성 컨테이너 오케스트레이션 2020.02.26

IDG 블로그 | 서버리스 컴퓨팅의 어두운 뒷면 : 제한적인 이식성

라이트스케일(Rightscale)의 2018년 클라우드 현황 보고서에 따르면, 서버리스 컴퓨팅은 가장 급성장한 클라우드 서비스로, 약 75%의 성장률을 기록했다. 이는 많은 기업이 서버리스 시스템을 사용하는 편리함을 선호한다는 것을 의미한다. 하지만 단점은 퍼블릭 클라우드의 서버리스 시스템에 구축한 애플리케이션은 쉽게 다른 클라우드로 옮길 수 없다는 것이다. 왜 이럴까? 서버리스 개발 플랫폼이 기업의 서버리스 코드를 호출하는 방식은 다양할 수 있다. 그리고 이 방식은 퍼블릭 클라우드마다 다르다. 클라우드 기반 서버리스 시스템에서 애플리케이션을 개발하는 대부분 개발자는 자신이 작성한 코드를 퍼블릭 클라우드 서비스 업체의 네이티브 API와 밀접하게 연동한다. 이런 작업 방식은 한 번 사용한 코드를 다른 플랫폼으로 이전하는 것을 어렵게, 혹은 불가능하게 만든다. 요점은 클라우드 네이티브 서버리스 시스템 상에 애플리케이션을 구축하면, 다른 클라우드 서비스 업체나 다시 온프레미스 시스템으로 옮기는 것은 모두 어렵다. 서버리스 시스템 사용이 어렵다는 말이 아니다. 서버리스 시스템은 매우 편하다. 하지만 점점 더 많은 기업이 클라우드 서비스 업체와 애플리케이션 개발 및 배치 플랫폼을 고를 때 가장 빠르고 저렴하고 편리한 곳을 선호하면서 이식성을 요구한다. 이 경우 이식성은 저주받을 것이 된다. 물론 컨테이너 활용이 폭증하고 있고, 컨테이너의 이점 중 하나는 이식성이다. 하지만 여기에는 추가 작업이 필요하며, 효율성을 염두에 둔 컨테이너 아키텍처를 이용해 구축해야 한다. 다시 말해, 대부분 개발자가 이식성이라는 이점을 보고 컨테이너를 선택하지만, 실제로는 원래 플랫폼 외에 다른 어떤 곳으로도 절대 옮기지 않는다. 이 모든 것이 의미하는 것은 다음과 같이 정리할 수 있다. - 대부분 기업에서 편의성과 속도, 즉 더 빠른 배치 사이클과 더 낮은 비용이 이식성을 이겼다. 새로울 것 없는 일이다. 과거 시장을 선도했던 모든 독점 데이터베이스와 프로그래밍 언어, 플랫폼...

컨테이너 네이티브 서버리스 2019.01.30

IDG 블로그 | 클라우드 이식성이 불가능한 이유

이식성(Portability)이란 애플리케이션을 한 호스팅 환경에서 다른 호스팅 환경으로 옮길 수 있다는 것을 의미한다. 여기에는 한 클라우드에서 다른 클라우드로, 즉 AWS에서 마이크로소프트 애저로 옮기는 것도 포함된다. 이렇게 애플리케이션을 한 플랫폼에서 다른 플랫폼으로 이식하는 데 필요한 작업은 구체적인 환경에 따라 달라진다. 컨테이너는 이런 이식을 한층 쉽게 만들어주는 기술의 하나로 여겨진다. 애플리케이션과 운영체제로 하나의 묶음으로 캡슐화해 도커나 쿠버네티스 같은 컨테이너 표준을 지원하는 플랫폼에서 구동할 수 있기 때문이다. 하지만 컨테이너가 만병통치약은 아니다. 실제로 애플리케이션 이식은 컨테이너이건 아니건 서로 다른 환경의 호환성 문제를 처리하기 위해 엄청난 양의 계획 작업이 필요하다. 컨테이너 기술을 사용한다고 플랫폼에서 플랫폼으로, 클라우드에서 클라우드로 컨테이너화된 애플리케이션의 이식을 보장받지는 못한다. 예를 들어, 리눅스용 컨테이너화된 애플리케이션을 윈도우로 이식할 수는 없다. 컨테이너는 운영체제와 애플리케이션을 하나로 묶는 멋진 방법임이 틀림없다. 컨테이너 기술을 활용하면 한층 개선된 이식성 역량을 얻을 수 있다. 많은 사람들이 믿는 것처럼 “어떤 플랫폼에서 어떤 플랫폼으로도 이식할 수 있는 역량”을 주지는 않는다. 물론 기업에 이식성은 중요하다. 그리고 이식은 언제나 할 수 있다. 필요한 것은 처음 애플리케이션을 만들 때와 비교할만한 엄청난 계획 작업이다. 충분한 시간과 돈만 있다면, 모든 애플리케이션을 이식할 수 있다는 것이 부정할 수 없는 사실이다. 여기서 중요한 것은 플랫폼 간의 이식에 필요한 작업을 최소화할 수 있도록 애플리케이션을 만들거나 크로스 플랫폼 애플리케이션 호환성을 제공하는 데 도움이 되는 기술을 이용하는 것이지만, 어디까지나 공식의 일부에 불과하다. 따라서 이식성은 이진법적인 것이 아니다. 즉 되고 안되고의 문제가 아니다. 대답은 회색 영역에 속한다. 많은...

포팅 이식성 2018.01.22

IDG 블로그 | 컨테이너 이식성의 진정한 의미와 호환성 계획

이식성과 호환성은 같은 말이 아니다. 이식성은 비즈니스의 문제이고 호환성은 기술 문제이다. 컨테이너는 이식성(Portability)과 민첩성을 보장하겠다고 약속한다. 애플리케이션을 개발자의 노트북에서 내부 데이터센터로 옮기고, 별다른 수고없이 외부의 서로 다른 클라우드 서비스 업체로 옮길 수 있다고 한다. 컨테이너는 새로운 맞춤형 소프트웨어 버전을 구성해 얼마 전에 계약한 납품 기일을 신속하게 맞출 수 있도록 해주고, 심지어 고객에게 셀프 서비스도 제공할 수 있다. 컨테이너는 가상머신보다 더 빨리 시작하고, 더 쉽게 옮길 수 있다. 그렇지 않은가? 목표인 것은 맞지만, 이식성과 호환성은 같은 것이 아니다. 이식성은 비즈니스 문제이고, 호환성은 기술 문제이기 때문이다. 이식성은 서로 다른 환경에서 호환성을 계획해야만 구현할 수 있다. 컨테이너를 도입하는 것만으로는 애플리케이션의 호환성을 보장받지 못한다. 왜 그럴까? 컨테이너는 애플리케이션과 그 애플리케이션의 모든 운영체제 의존 요소를 패키징하는 세련된 방법일 뿐이기 때문이다. 즉 이식성을 제대로 구현하기 위해서는, 그리고 궁극적으로 비즈니스의 민첩성을 구현하기 위해서는 계획이 필요하다. 여기서는 성공적인 이식성을 구현하기 위한 즉각적인 방안을 소개한다. 1. 표준 운영 환경 이 환경에는 컨테이너 호스트, 컨테이너 이미지, 컨테이너 엔진, 컨테이너 오케스트레이션이 포함되어 있어야 한다. 이 모든 구동부는 정렬되고 표준화되어야 하며, 함께 버전을 맞추고 테스트한 것이어야 한다. 업그레이드 역시 하나의 유닛으로 함께 계획해야 하는데, 이들 요소 간의 상호 의존성이 크기 때문이다. 인프라의 정합성은 컨테이너를 구축하거나 실행하는 모든 환경에서 보장되어야 하며, 개발자의 노트북, 테스트 서버, 가상머신 역시 마찬가지이다. 표준 운영 환경에서는 항상 똑같이 테스트하고 인증 받은 요소를 모든 곳에서 사용할 것을 권장한다. 2. 표준 애플리케이션 정의 애플리케이션 정의에 있어서는 ...

호환성 컨테이너 이식성 2017.09.12

IDG 블로그 | 클라우드 이식성, “아직은 공상과학 SF에 불과”

언제쯤 워크로드를 아무런 수정도 없이 퍼블릭 클라우드 간에 옮길 수 있을까? 금방은 힘들 것으로 보인다. 기업은 클라우드의 이식성을 원한다. 이유는 퍼블릭 클라우드 서비스 업체가 ‘막 나가는’ 경우를 피하기 위해서이다. 계속 질 나쁜 서비스를 제공한다거나 성능 문제, 아니면 서비스 요금을 터무니없이 올리는 등의 경우를 생각하는 것이다. 필자와 이야기를 나눈 많은 CIO가 “선택권을 가질 필요가 있다. 선택권은 영향력을 의미한다”라고 말했다. 제대로 된 선택권을 가지기 위해서는 애플리케이션과 데이터를 포함한 워크로드를 쉽게 이전할 수 있어야 한다. 코드를 이전하고 데이터를 이전하는 것은 새로운 클라우드 플랫폼에서의 재컴파일과 환경 설정, 테스트를 의미한다. 하지만 이런 것이 쉬웠던 적은 없다. 실제로 애플리케이션과 데이터를 퍼블릭 클라우드로 이식하려면, 일부 클라우드 네이티브 기능을 활용할 수 있도록 리팩터링해야만 한다. 클라우드 네이티브 서버와 스토리지를 돌려야 하고 클라우드 네이티브 보안과 거버넌스를 활용해야 한다. 클라우드 네이티브 서비스를 활용하지 않는다면, 클라우드를 이용할 이유도 없어진다. 워크로드 비용을 더 많이 내거나 비즈니스의 요구조건을 만족하지 못할 것이기 때문이다. 물론 클라우드 네이티브한 환경은 좋은 것이다. 하지만 이식성을 크게 제한한다. 한 퍼블릭 클라우드 서비스 상의 클라우드 네이티브 서비스는 다른 퍼블릭 클라우드 상에서는 새로운 클라우드 네이티브 서비스로 작성해야만 한다. 이들은 서로 호환되지 않으며, 설령 모든 것을 옮길 수 있다해도 엄청난 시간과 비용이 들 것이다. 때문에 실용적인 관점에서는 이식할 수 있다고 생각하기 어렵다. 물론 많은 기업이 신기술의 구원을 기대하고 있다. 예를 들어 컨테이너라든가 서버리스 컴퓨팅 등이다. 서버리스 컴퓨팅이 새로운 애플리케이션에 좋다고 하지만, 이는 서버리스 아키텍처에 맞춰 처음부터 설계해야 한다는 의미이다. 여기에 퍼블...

컨테이너 이전 클라우드 2017.07.17

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

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

Copyright © 2022 International Data Group. All rights reserved.