Aug 24, 2018

AWS의 클라우드 구성 오류 문제, 해법은?

Dan Swinhoe | CSO

아마존이 AWS S3 구성 오류 확률을 줄이기 위해 2가지 신규 툴, 젤코바(Zelkova)와 타이로스(Tiros)를 준비 중이다. 이는 누가 데이터와 리소스에 접근하는가와 이들이 할 수 있는 것을 한층 명확히 정의할 것이다. 이들 툴은 액세스 컨트롤을 분석하고 평가하고, 고객의 클라우드 환경의 개방성을 매핑한다.

아마존웹서비스(AWS)는 고객의 클라우드 환경의 보안을 보장하는 데 늘 문제가 있다. 구성 오류는 흔한 일이고, 이로 인해 엄청난 양의 기밀 데이터가 노출되었다. 버라이즌(Verizon), 부즈 앨런(Booz Allen), 해밀턴(Hamilton), WWE 재단(the WWE Foundation), 알터릭스(Alteryx), 전미 신용 연맹(the U.S. National Credit Federation), 호주공영방송(the Australian Broadcasting Corporation, ABC), 액센추어(Accenture) 등은 구성 오류로 정보 노출을 경험하기도 했다.

AWS가 서비스의 보안을 개선하고, 구성 오류 확률을 낮추기 위해 과거 여러 노력을 했음에도 불구하고 이런 일이 벌어진 것이다. 지난해 아마존은 AWS에 저장된 기밀 데이터를 자동으로 발견하고 보호하도록 설계된 메이시(Macie)라는 머신러닝 툴을 도입하였고 아울러 기본 암호화, 상세 인벤토리 보고서, 권한 확인 등의 새 기능들로 S3 보안을 개선하였다.

2018년 2월 페덱스(FedEx)가 여권, 운전면허증, 고객 기록 등 10만 건이 넘는 문서를 노출시켰다는 뉴스가 나온 지 며칠 후 AWS는 S3 버킷 권한 확인 서비스를 모든 이용자에게 무료로 제공했다.

AWS 심플 스토리지 서비스(Simple Storage Service, S3)는 아마존의 객체 스토리지 상품이다. 스카이하이 네트웍스에 따르면, 전체 S3 버킷의 7%가 무제한으로 공공 접근이 가능하고 35%는 암호화되지 않은 상태다. 데이터가 노출되어 방치된 최근의 사례는 50만 대가 넘는 차량 추적 장치의 로그인 암호, 2억 개의 미국 투표자 기록, 미 육군 정보부에 속한 기밀 데이터 등이 있다. 해커들은 정보를 훔칠 뿐 아니라, 랜섬웨어로 데이터를 감금하였고, 암호 화폐를 채굴하기 위해 컴퓨팅 자원을 이용한 것으로 드러났다.

젤코바와 타이로스의 기능

젤코바와 타이로스는 AWS의 오토메이티드 리즈닝 그룹(Automated Reasoning Group, ARG)에 의해 개발되었다. 이 그룹은 아마존 제품용의 인증 툴과 기법을 개발한다. 자동 추론(Automated reasoning)은 시맨틱 기반의 추론을 바탕으로 수학식을 적용하여, 간단히 말해, 특정 문제에 답변하고, 정책들이 예상대로 작용하는지 검증하는 정형적 인증 기법이다. ARG는 AWS의 보안 팀에 속하고, 2년 이상 동안 툴들을 내부적으로 개발해왔다.

2018년 6월 처음 발표된 젤코바는 자동 추론을 이용해 정책들과 이들의 미래 결과를 분석했다. IAM(Identity and Access Management), S3 및 여타 리소스 정책과 호환되고, 조직이 벤치마크를 생성할 수 있게 해주고, 현재 정책 설정의 결과를 조직에게 알려준다. 예를 들어, S3 정책에 반하여 이용될 때 무단 이용자가 버킷을 읽거나 가필할 수 있는지 알려주는 식이다.

타이로스는 고객 네트워크 사이의 연결을 매핑한다. 예를 들어, 이는 고객의 EC2 인스턴스가 인터넷에서 접근 가능한지를 알려줄 수 있다.

젤코바와 타이로스는 내부 툴로서 시작되었다. 젤코바는 S3 대시보드의 일부로서, 그리고 AWS 메이시 안에서 내부적으로 사용된다. 투자관리 회사인 브리지워터 어소시에이츠(Bridgewater Associates)는 테스트 목적으로 이들을 조기에 사용할 수 있었다.

젤코바 발표 시 브리지워터 어소시에이츠의 수석 클라우드 보안 아키텍트인 댄 피블즈는 “젤코바를 이용해 브리지워터는 정책들이 데이터 외부 유출, 구성 오류, 여타 수많은 악의적이고 우발적인 부적절한 거동을 허용하지 않음을 검증하고 보장한다”면서 “젤코바는 우리의 보안 전문가가 자신이 이해한 바를 한번 부호화하면, 이들을 여타 유관 정책들에 기계적으로 적용한다. 따라서 오류가 나기 쉽고 느린 인간의 리뷰를 피하고, 동시에 우리는 IAM 정책의 정확성과 보안에 대해 높은 확신을 가질 수 있다”고 말했다.

이들 툴 중 어느 것도 현재 공개적으로 이용할 수 없다. 브리지워터는 이들이 ‘원시 상태(raw state)’이고, 특별히 이용자 친화적이지는 않다고 말한다. 아마존은 툴의 배포나 가격에 대해 정보를 제공하기를 거절했다.

아마존의 클라우드 구성 문제
아마존, 마이크로소프트 애저 등의 클라우드 사업자는 서비스에 대해 일정 수준의 보안을 제공하고, 권장 모범 관행을 제시하지만, 이들은 공유 보안 모델 하에서 운영되므로 고객이 대부분의 부담을 떠안아야 한다. 이 부분에서 종종 문제가 발생한다. 영국(UK) MSP 클라라넷의 사이트 안정성 수석 엔지니어인 스티브 스미스는 “AWS S3 버킷에 관해 보고되는 보안 문제는 플랫폼 자체와는 거의 무관하고, 이를 이용하는 사람들과 전적으로 유관하다. 이게 최대의 약점이다”고 지적했다.

이어서 스미스는 “AWS는 수많은 초기값들을 사려 깊게 설정하여 구성을 지원한다. 현재 S3 버킷은 기본값이 ‘프라이빗(private)’으로 설정되어 있다. 그러나 유감스럽게도, 플랫폼을 사용하는 법을 모른다면 일이 잘못되기 십상이다”고 덧붙였다.

전개 및 관리 툴의 복잡성, 교육의 결여, 관리자가 제어해야 할 서비스의 지속적인 증가, 그리고 보안 팀의 시야 밖에서 클라우드 환경은 쉽게 망가질 수 있다는 사실은 데이터 유출이 흔한 문제로 지속될 수밖에 없음을 의미한다.

로그 관리 및 애널리틱스 사업자인 (그리고 AWS 고객인) 수모 로직(Sumo Logic)의 CSO인 조지 거초우는 “소비자는 공유 책임 모형(shared responsibility model)을 이해하고 데이터를 보호하는 모범 관행을 적용해야 한다”면서 “AWS는 이렇다 할 교육을 제공하지는 않는다. 그러면 소비자는 아무런 문제가 없다고 믿어버리기 쉽다”고 말했다.

이들 새로운 툴을 이용해 AWS는 인간 오류의 확률을 줄이고 데이터 누출의 개연성을 낮추려고 한다. 그러나 이들이 도움이 될까? ‘AWS 뉴욕 서밋 2018’ 중의 젤코바 및 타이로스에 관한 프리젠테이션에서 브리지워터 어소시에이츠의 보안 아키텍트인 그레그 프래스카도어는 “여기서 우리의 보안 목표는 AWS로부터 데이터가 외부로 유출되는 것을 막는 것”이라면서 “우리가 얻고자 하는 것은 우리가 배치한 보안 컨트롤들이 우리가 예상한 대로 작용하는지 검증하는 정형적 분석과 체계적인 방법론이다”고 이야기했다.

프래스카도어는 이들 툴의 사용 사례는 개별 보안 컨트롤을 검증하고, 보안 컨트롤에 관련된 벤치마크를 생성하고, 일단의 계정에 걸쳐 적절한 컨트롤을 배치하고, 검증을 자동화하고, 설계 단계에서 검증을 이행하는 것 등이 있다고 말했다. 그는 “이들 툴에서 매우 중요한 사실 하나는 설계 단계에서 검증할 수 있다는 것이다. 우리가 정말 하고 싶어 하는 것 중 하나는 실제 AWS 인프라를 변경하기 전에 보안을 검증하는 것이다. 그렇게 되면 취약점을 미리 거를 수 있다”고 말했다.

이들 신종 툴이 장점뿐 아니라 잠재적 단점 또한 있다고 경고하는 사람들도 있다. 수모 로직의 거초우는 “이들은 좋은 취지이지만, 가격이 비싸고, 정확히 구성되어야 한다. 복잡성이 늘어날 수 있고, 멀티-클라우드 또는 하이브리드 전개 시에는 효용이 없다”고 말했다.

BTB시큐리티의 최고 정보보안 고문인 매트 윌슨은 “젤코바와 타이로스는 잠재적 장점이 무수히 많다. 그러나 데이터를 조작할 줄 알아야 한다. 그렇지 않다면 별로 쓸모가 없다. 게다가 조직 내에 이를 실행하고, 출력을 분석하고, 제공된 정보에 따라 조처를 할 누군가가 있어야 한다. 고급 알고리즘과 세련된 인터페이스는 훌륭하다. 그러나 그것만으로는 충분하지 않다”고 설명했다.


원문보기

Aug 22, 2018

"마이크로서비스는 답이 아니었다"··· 세그먼트가 모놀리틱으로 돌아온 이유

Tamlin Magee | Computerworld UK

다른 많은 기업과 마찬가지로, 데이터 스타트업 세그먼트(Segment) 역시 오래된 인프라스트럭처로 인한 문제 때문에 마이크로서비스(microservice)로 눈을 돌렸다. 하지만 곧 단일 구조(monolithic) 아키텍처로 돌아오지 않으면 해결할 수 없는 복잡한 문제가 있다는 것을 깨달았다.

세그먼트의 주 고객은 타임(Time), IBM, 리바이스(Levi’s) 등이다. 이들 기업의 모든 고객 데이터를 세일즈, 애널리틱스, 헬프데스크 등에 피딩하기 전에 한 지점에 모아 볼 수 있는 서비스를 제공한다.

세그먼트의 CTO이자 공동창립자인 캘빈 프렌치-오웬은 “처음에는 단일 API와 라이브러리를 제공하고 그들이 데이터를 보내오는 식의 개발자 우선 방식을 택했다. 우리가 데이터를 모아 구성한 후 이를 적절한 스키마로 정렬하고, 고객사가 사용하는 200여 가지 이상의 툴에 이 데이터를 보냈다. 여기서 툴이란 세일즈포스 같은 세일즈 툴 일수도 있고, 젠데스크(Zendesk) 같은 고객 관련 툴, 혹은 레드시프트(Redshift)나 빅쿼리(BigQuery)같은 데이터 웨어하우스 일수도 있다”라고 말했다.

세그먼트사는 전적으로 AWS에 의존하고 있으며, ECS(Elastic Container Service)가 관리하는 1만 6000개 컨테이너가 250여 가지 마이크로서비스를 제공한다.

세그먼트는 원래 단일 구조 아키텍처를 사용했다. API가 데이터를 처리해 싱글 큐(queue)에 포워딩하면 직원이 데이터를 읽고 이벤트를 모든 서버측 ‘목적지’, 그러니까 파트너 API에 선형 체인을 통해 전송했다. 그러나 이런 방식은 이내 문제를 발생시켰다. 툴에서 서버 에러를 반송할 때의 재시도가 큐와 만나 다른 이벤트와 뒤섞이는 것이다. 이로 인해 파이프가 막히고 성능 장애로 이어졌다.

세그먼트의 소프트웨어 엔지니어 알렉스 누난은 “단일 구조에서 탈피해 마이크로서비스로 전환한 것도 이 때문이었다. 우리에게는 데이터를 수집하는 API와 라우터가 있고, 라우터는 이벤트를 목적지별 큐와 서비스로 라우팅했다. 이벤트가 발생하면 라우터가 ‘좋아, 이 이벤트는 구글 애널리틱스와 맥스 패널로 보내야겠어’라고 판단을 내리고 해당 이벤트의 카피를 2개 생성해 각각의 큐로 이를 보내는 식이었다”라고 말했다.

바람 잘 날 없었던 “마이크로서비스”의 세계
마이크로서비스 방식은 한동안 잘 돌아 가는 것처럼 보였다. 그러나 역시 문제가 발생했다. 누난의 표현을 빌리면 '마이크로서비스 세계의 더 깊숙한 곳에서 개별 파트너의 API 목적지와 서비스에 대한 새로운 타입의 큐가 형성됨'에 따라 발생했다. 결국 개발자는 모든 업데이트를 수동으로 처리해야 했고 어떤 업데이트 버전이 어디의 어느 리포(repo)에 있는지를 일일이 기억하는 것이 한계에 다다랐다.

누난은 “시간이 갈수록 개발자의 생산성이 급격히 저하됐다. 모든 것이 각기 다른 별개의 큐와 별개의 서비스, 그리고 자체적인 리포에 있었기 때문이다. 우리는 통합을 유지, 생성하기 위해 공유 라이브러리를 만들었지만 이것을 전개할 좋은 방법도, 또 제대로 테스팅할 여건도 안됐다. 공유 라이브러리를 업데이트하기에는 시간도 자원도 부족했다. 결국 구글 애널리틱스 버전만 업데이트하는 식이 됐다. 모든 라이브러리가 서로 다른 업데이트 버전을 갖게 됐다"라고 말했다.

세그먼트 팀은 파트너 API가 각각 어느 라이브러리 버전에서 구동되는지 추적하고, 그 버전 간의 차이도 기억해야 했다. 누난은 “라이브러리 관리 업무 만으로도 개발자에게 너무 큰 부담이 됐다. 꾹 참고 서비스마다 하나하나 변경할 수도 있지만 그러려면 수 일이 걸렸고, 특히 서비스 하나 하나를 테스트하고 전개하는데 여러 명의 개발자가 필요하게 됐다. 이것이 너무 큰 부담으로 작용한 끝에 결국 꼭 필요한 변경사항조차도 적용하지 않게 되는 일까지 발생했다. 모든 서비스에 아주 작은 변경사항만 적용하기 위해서도 팀 전체가 달려 들어 일주일 이상 소모해야만 했다”라고 말했다.

세그먼트의 직원은 이러한 큐를 처리하기 위해 수면 부족에 시달리는 것도 모자라, 성능 이슈에도 직면했다. 예를 들어 구글 애널리틱스와 같은 대규모 목적지의 경우 초당 수천 건에 달하는 이벤트를 처리하는 반면 하루에 수 건 이내의 이벤트만을 처리하는 곳도 있었다. 세그먼트 팀은 오토-스케일링 룰을 적용해 이러한 서비스의 수동 커스터마이징을 최소화 했지만 서비스마다 고유의 CPU 및 메모리 로드 패턴이 있었기 때문에 모든 통합에 같은 룰을 적용할 수는 없었다.

누난은 “하루에도 수십 번씩 쉴 새 없이 호출이 왔고, 직원이 일일이 개입해 이러한 서비스를 처리해야 했다. 이런 식으로 2년 넘게 마이크로서비스 방식을 이용한 결과 큐와 리포에 140여 가지 서비스를 갖게 됐지만 시스템 장애를 막는 데에만 모든 에너지를 쏟아도 역부족이었기에 그보다 더 건설적이거나 선제적인 어떤 노력도 할 수 없는 상황이었다. 이쯤 되자 한걸음 물러나 생각해 보지 않을 수 없었다. ‘대체 이 상황을 해결하려면 어떻게 해야 하지?’ 결국 인력을 추가해야 한다는 결론이 나왔지만, 그런 식으로 문제를 해결하고 싶지는 않았다”라고 말했다.

그러나 결국 세그먼트는 마이크로서비스 아키텍처가 지속 불가능하다는 결론에 다다랐다. 목적지를 추가할수록 성능 저하가 눈에 띄게 증가했고 이것은 ‘상당히 뚜렷한 경고 신호’였다. 누난은 “한창 마이크로서비스로 인한 광기가 극에 달했을 때 내가 세그먼트에 합류했다. 당시 이미 어떻게 하면 이 문제를 해결할 것인가에 대한 논의가 이루어지고 있었다”라고 말했다.
단일 구조로 돌아가다
세그먼트 팀은 마이크로서비스를 어떻게 다시 하나의 거대한 시스템으로 재설계할 것인지 방법을 찾아야 했다. 이른바 ‘신(新) 단일구조’로의 이행이었다. 결국 당시 세그먼트가 진행 중이던 ‘센트리퓨즈(Centrifuge)’ 인프라스트럭처 프로젝트를 통해 새로운 단일 구조로 이행하기로 결정됐다. 센트리퓨즈는 세그먼트 비즈니스의 핵심이라 할 수 있는 단일 이벤트 딜리버리 시스템이다.

프렌치-오웬은 “센트리퓨즈는 큐를 생성하고 실패가 발생했을 때 트래픽을 흡수하기 위한 시스템이다. 이 시스템 덕분에 우리는 여러 코드를 한 장소에 통합하고, 이를 통해 두 마리 토끼를 잡는 전략을 취하기로 했다"라고 말했다.

이를 위해 먼저 모든 목적지 코드를 하나의 리포로 통합했다. 하나의 리포에 모든 종속 항목과 테스트를 합병하는 것이었다. 서비스가 하나뿐이므로 논리적으로 당연했다. 그러나 이 과정이 대단히 복잡하고 머리 아픈 과정이었다. 누난은 "120개가 넘는 고유의 종속 항목들 각각에 대해 우리는 모든 목적지에 대한 하나의 버전을 만드는 데 집중했다. 또한 목적지를 이동하면서 사용 중인 종속 항목을 확인하고 이들을 최신 버전으로 업데이트했다. 또 목적지의 새로운 버전에서 생긴 부분을 바로 바로 수정했다"라고 말했다.

이렇게 일관성을 확보한 결과 코드베이스를 어지럽히던 혼란이 상당 부분 해소되었다. 세그먼트 팀은 또한 빠르고 쉽게 모든 목적지 테스트를 한 번에 진행할 수 있는 테스트 스위트는 개발했다. 지나치게 길고 복잡한 테스트 과정 역시 업데이트를 방해하던 주요 요소 중 하나였기 때문이다.

이처럼 목적지 코드를 단일 리포로 이동시켜 단일 서비스로 통합하자 곧바로 개발자 생산성 증대라는 성과로 이어졌다. 서비스 전개 시간도 수 분 이내로 단축됐다. 누난은 “인프라스트럭처의 가장 큰 부분을 재설계해야 했기 때문에 단일 구조로의 전환에는 상당한 시간이 걸렸다. 당연한 일이었다. 하지만 적어도 예전처럼 계속해서 고객 지원 요청이 들어오거나 하는 일은 없다. 모두가 수면 부족에 시달리지 않을 수 있게 됐다. 모든 것을 하나의 리포로 통합하고 나니 관리도 쉬워졌다”라고 말했다.

이어 "이제 공유 라이브러리에 업데이트를 생성하고 싶을 때, 엔지니어 1명이 한 시간만 투자해 테스트하고 전개할 수 있다. 우리에게는 정말 획기적인 변화였다. 처음 마이크로서비스를 채택했을 때 당시 그런 선택을 할 만한 사정이 있었다고 생각한다. 당시 팀이 처한 상황이나 겪고 있던 성능 이슈를 고려하면 최고의 선택이었다. 그러나 시간이 지날수록 마이크로서비스의 장점은 사라지고 생산성과 성능만 잡아먹게 됐다. 그래서 다시 단일 구조로 돌아온 것이다"라고 말했다.

세그먼트 사가 다른 기업에 비해 처리하는 데이터 양에서 압도적으로 많긴 하지만 비슷한 불편을 겪는 다른 기업 역시 단일 구조로 돌아오는 것이 하나의 대안이 될 수 있다. 누난도 "그런 선택을 한다고 해도 전혀 놀라운 일이 아니다"라고 말했다.

단일 구조로 돌아온 후 나아진 건 세그먼트 사 직원의 워크-라이프 밸런스 뿐 만이 아니다. 고객 역시 훨씬 일관되고 안정적인 서비스를 누릴 수 있게 됐다. 프렌치-오웬은 “모든 서비스가 한 장소에, 단일 리포에 통합됨에 따라 추가된 변경 사항이 다음 번에도 모든 서비스에 똑같이 전개될 것이라는 확신을 가질 수 있게 됐다. 덕분에 고객 역시 서비스 별로 각기 다른 버전으로 인해 발생하는 혼란이나 비일관성을 더 이상 겪지 않아도 됐다"라고 말했다. ciokr@idg.co.kr

원문보기

지금 클라우드에 쓰는 비용, 과연 합리적일까?

Scott Carey | Computerworld UK, 2018.8.21.

클라우드 컴퓨팅 혁명 초기, 사용한 만큼 돈을 낸다는 개념이 등장해 좀더 효율적인 IT소비 시대가 열리는가 기대했던 적이 있었다. 물론 실제로 IT지출 효율화에 성공한 사례도 있었고, 덕분에 매우 빠른 속도로 성장한 웹 기반 기업도 있었다. 그러나 여러 공급업체로부터 받는 서비스가 증가하며 전체 클라우드 지출 현황을 파악하지 못하는 이른바 ‘클라우드 블로트(cloud bloat)’ 위험이 있는 것도 사실이다.

퍼블릭 클라우드로 이전한다고 해서 반드시 지출이 증가한다거나, 혹은 엄청나게 비용이 절감된다는 보장은 없지만, 클라우드 서비스를 확보하고 이에 대한 비용을 지불하는 방식을 획기적으로 바꿀 것만은 분명하다. 그리고 궁극적으로는 기존의 장기 라이선싱 모델보다 비용 예측을 어렵게 만들 것이다.

예컨대, 음악 스트리밍 기업 스포티파이(Spotify)는 최근 온-프레미스 데이터센터에서 구글 클라우드 플랫폼(Google Cloud Platform, GCP)으로의 완전한 이전을 완료했다.

2018년 7월 열린 구글 클라우드 넥스트 컨퍼런스에서 이러한 이전이 비용에 어떤 영향을 미칠 것으로 보느냐는 질문에 엔지니어링 디렉터 하몬 반 알테렌은 “(비용은) 중앙 집중화된 구매에서 분산된 구매로 전환하며 주의 깊게 봐야 할 요소 중 하나다. 구매를 분산하면 누구나 지출할 수 있게 된다. 때문에, 비용에 미치는 영향은 여러 가지 요인에 따라 달라질 수 있다. 특히 최근 들어 기업 규모가 성장하고 있기 때문에, 구체적인 숫자로 답할 수 없음을 양해해 달라”고 말했다.

라이트스케일 2018 클라우드 현황 보고서(RightScale 2018 State of the Cloud report)에 따르면, 전체 기업의 81%가 멀티 클라우드 전략을 채택하고 있으며, 응답자들은 연지출의 약 30%가량이 낭비되는 것으로 파악하고 있었다. 라이트스케일 역시 낭비되는 지출이 전체의 35%에 달한다고 지적했다.

그 결과, 2018년 설문조사 응답자들은 클라우드 비용 최적화를 최우선 전략으로 꼽았다. 응답자의 58%는 이를 클라우드와 관련한 최우선순위라고 답하기도 했다. 그에 비해 사용하지 않는 워크로드를 셧다운하거나 저비용 클라우드 또는 지역을 선택하는 등, 클라우드 비용을 최적화하기 위한 자동화 정책을 실행 중인 기업은 전체 응답자 중 낮은 비중에 그쳤다.

이러한 패러다임의 전환은 전통적인 IT업체들에도 직접적인 영향을 미쳤다. 전통적인 IT업체들은 핵심 라이선스 고객들을 만족시키면서도 새로운 패러다임에 적응하고 살아남기 위해 가격 정책 설정에 고심하고 있다.

독일의 전통적인 IT업체 SAP는 지난 수년간 공공연히 이 문제를 다뤘으며, 2017년 5월에는 현대화된 가격 정책을 새롭게 내놓기도 했다.

SAP 기업개발 담당자 헤일라 자인은 당시 “디지털이 우위를 점한 애자일 세계에서 라이선싱이 유발하는 복잡성은 혁신의 길을 가로막는 요소가 된다… 우리의 목표는 좀더 예측 가능하며, 가치 단위에 연결되어 있고, 투명하며, 또한 일관된 가격 정책을 만드는 것이다”고 말했다.

이어서 “그렇다고 디바이스와 IoT, 그리고 협력 네트워크 시대에 모든 간접 접근 시나리오를 다 다룰 수 있을까? 아직은 아니다. 아직 해야 할 일이 많다. 우리는 고객에게 보다 큰 가치를 선사하기 위하여 가격 책정 시나리오를 계속해서 업데이트 해 나갈 준비가 되어있다. 하지만 적어도 가격 책정 현대화를 위해 올바른 방향으로 한 걸음을 내디뎠다고 평가하고 싶다”고 덧붙였다.

그렇다면 클라우드에 비용을 과다 지출하지 않으려면 어떻게 해야 할까?

충분히 준비하고 접근
클라우드 과다 지출을 막기 위해서는 충분히 준비하고 나서 새로운 서비스를 조달해야 한다.

클라우드 업체 뉴타닉스(Nutanix)는 자사 매거진 넥스트(Next)를 통해 아래와 같이 조언했다. “클라우드 업체를 선택하기에 앞서 해당 업체의 가격 정책 모델을 완전히 이해해야 한다. 이러저러한 API 요청이나 기타 트랜잭션 요금 등 ‘숨은’ 비용을 알고 있어야 타 업체들과 정확히 서비스를 비교하고 우리 기업의 활용사례에 가장 적합한 업체를 선택할 수 있게 된다.”

“클라우드를 사용하면서, 가장 많은 월 지출을 발생시키는 서비스가 무엇인지 파악하라. 이러한 비용을 정당화할 수 있는 사례가 있는지, 비용을 최적화할 수 있는 방법은 없는지 찾아보자. 특정 서비스를 지나치게 많이 사용하는 것은 어쩌면 애플리케이션에 코딩에러가 있기 때문일 수도 있다.

“또 클라우드 서비스를 신청하는 것은 온라인에서 마우스 클릭 몇 번으로 이뤄지는 일이라, 신청해 놓고 잊어버리고 사용하지도 않는 서비스들도 있을 수 있다. 이들 서비스로 인해 한 달에 수천 달러의 비용이 낭비되기도 한다. 이런 비사용 서비스들을 색출해 내는 것만으로도 단기간에 비용을 확 줄일 수 있다.”

뉴타닉스 역시 클라우드 비용 절감에 대해 다음과 같이 조언했다. “워크로드는 그것과 관계가 있고 책임이 있는 부서나 기능별로 배치해야 한다. 이는 서비스 요금 상환을 가능하게 할 뿐 아니라 보다 정확한 예측을 돕는다. 예산은 비즈니스 현황에 맞춰 짜이는 것이 보통이며, 아마도 해당 서비스를 사용하거나 필요로 하는 팀의 요청을 반영하고 있을 것이다. 따라서 해당 서비스를 사용하는 팀이 그러한 리소스를 최적화하고 예산 범위 내에서 관리하도록 해야 한다.”

앱티오(Apptio)의 EMEA SVP 콜린 로울랜드는 “새로 IaaS를 도입하고 퍼블릭 클라우드로 이전하기 전에 클라우드 이전에 드는 전체 비용을 꼼꼼히, 그리고 찬찬히 분석해 보아야 한다. 이전 시 기대되는 비용 절감 효과는 어느 정도고, 이전 자체에 들어가는 비용은 어느 정도인가를 따져 볼 필요가 있다”고 당부했다.
클라우드 지출 줄이기, 정확한 비용 파악에서 시작
클라우드 관리의 효율성은 결국 효율적인 현황 모니터링의 문제로 귀결된다. 무엇에 얼마를 지출하고 있는지를 모르면서 지출을 효율적으로 관리할 수는 없기 때문이다.

터보노믹(Turbonomic)의 클라우드 CTO 모르 코헨은 “인스턴스, 로드 밸런싱, SQL, 그리고 NoSQL 서비스 등, 클라우드에서 소비하고 있는 모든 서비스들을 꼼꼼히 살펴 보라. 각 서비스를 이용함으로써 발생하는 이점과 비용을 대조해 볼 필요가 있다”고 조언했다.

코헨은 “클라우드 사용 패턴이 예측 가능하며, 애플리케이션 수요가 일관된 조직에서는 이런 것들을 쉽게 계산해 볼 수 있다. 이러한 계산을 끝내고 클라우드 공급자들을 비교하여 선택하면 된다”고 이야기했다.

원문보기

Aug 17, 2018

마이크로서비스 아키텍처, 복잡성이 문제로다

IT 인프라를 애플리케이션 내 기능에 따라 별도로 쪼개 운영하는 마이크로서비스 아키텍처가 대세로 떠올랐다. 애플리케이션을 보다 빠르게 개발하고 지속적으로 성능을 향상시킬 수 있다는 점에서 각광받고 있다.

​하지만, 마이크로서비스 아키텍처를 적용하는 게 생각처럼 쉽지 않다는 목소리도 높다. 빠르고 유연한 애플리케이션을 제공하는 데만 초점을 맞추면 네트워크 정책과 보안 정책이 복잡해 질 수 있기 때문이다.

이에 어떻게 해야 애플리케이션 배포, 업그레이드 속도는 높이고 SW작동의 복잡성을 줄일 수 있을지가 성공적인 마이크로서비스 아키텍처 도입을 위한 핵심 과제로 떠올랐다.

​■대세로 떠오른 마이크로서비스 아키텍처 잘 쓰려면

​마이크로서비스 아키텍처란 애플리케이션 구성요소를 특정 목적별로 쪼갠 뒤 독립적으로 작동하도록 극소형 서비스로 만들고, 여러 극소 서비스들을 조합해 완성된 애플리케이션으로 조립하는 개발 형태를 말한다.

​과거의 서비스지향아키텍처(SOA)보다 추상화 수준을 한차원 더 세분화한 것으로 볼 수 있다.

​마이크로서비스 아키텍처 환경에서 개발조직은 각 서비스들을 전담해 지속적 통합과 지속적 개발(CI/CD)을 하게 된다. 솔루션과 IT서비스 개발속도를 높이고, 유지보수에 투입되는 공수를 줄일 수 있어 인기를 모으고 있다.
마이크로서비스 아키텍처는 레고 블록을 조립하듯 여러 서비스를 조합해 하나의 애플리케이션으로 구현

지난 2016년 9월 애플리케이션 개발 플랫폼 업체 라이트벤드가 자바가상머신(JVM) 개발자와 IT 전문가 2천151명을 대상으로 실시한 설문조사에서 응답자 30% 이상이 마이크로서비스를 현업 시스템에서 운영중이라고 답했다. 응답자 20%는 마이크로서비스 현업 시스템 적용을 심각하게 고려중이라고 답변했다. 이미 현업에서 마이크로서비스 아키텍처가 대세로 부상했음을 보여준다.

하지만 운영 환경이 늘어나면서 시스템 운영환경의 복잡성도 커지는 문제가 발생한다. 마이크로서비스 아키텍처의 최대 강점인 개발 생산성을 극대화하는 데 발목을 잡는 일이 생긴다.

이런 문제를 어떻게 해결해야 할까. 애플리케이션 플랫폼 관리 및 보안 솔루션 업체 F5네트웍스는 개발팀 요구에 맞춰 수정할 수 있는 사전 개발된 템플릿을 만들어 대응할 것을 제안한다.

이렇게 하면 사용자가 각 애플리케이션 팀에 어떤 서비스를 제공할 것인지, 어느 정도 수준의 개별 통제력을 부여할 것인지 결정할 수 있다. 또, 운영 환경의 애플리케이션 성능에 대한 가시성과 셀프 확장 옵션도 제공 가능하기 때문에, 애플리케이션 책임자와 네트워크 운영 팀 간 충돌을 없애고 각 기업이 원하는 속도와 규모로 강력한 보안, 성능 및 가용성 서비스의 이점을 더 많은 애플리케이션으로 확장해 준다는 설명이다.
Subscribe to: Posts (Atom)