FBI warns companies about hackers increasingly abusing RDP connections
최근 미국의 연방수사국 FBI의 인터넷 범죄수사불평센터에서는 원격데스크탑 프로토콜로 인해 온라인 상의 보안위협이 가중되고 있음을 심각하게 경고한 것으로 나타나 관련 내용을 살펴보기로 한다.
원격데스크탑 프로토콜이라 불리우는 RDP(Remote Desktop Protocol)는 지난 90년대 Microsoft社에서 개발한 독점기술로서 사용자의 컴퓨터에 원격으로 로그인하여 마우스와 키보드 입력 등 시각적 인터페이스를 통해 컴퓨터를 조종할 수 있는 기술로 알려져있다 하겠다. 이러한 원격데스크탑 기술이 가정용 컴퓨터에서는 거의 사용이 되고 있지 않으나, 기업용 네트워크를 활용하는 서버나 컴퓨터 등은 원격으로 시스템 관리자가 접근할 수 없는 경우 해당 기술을 활용해오고 있는 것으로 알려져있다 하겠다.
이러한 기술활용실태와 더불어 FBI는 지난 2016년 중반부터 원격데스크탑 연결이 가능한 컴퓨터의 수가 지속적으로 증가했음을 언급하였는데, 2016년 초기에는 약 3천 3배개여 개의 원격포트가 활성화된 9백만 대의 장치가 있음이 확인되었으며, 1년이 지난 뒤에는 해당 장치가 1.1천만 대로 증가한 것으로 나타났다고 한다.
사이버해커들 또한 이러한 원격테스크탑을 활용하는 기기의 수가 증가함에 따라 사이버공격의 주요 채널로 활용하기 시작하였으며, 지난 수 년 간 원격데스크탑 프로토콜이 연결된 컴퓨터를 통해 해커들이 네트워크를 장악하려는 시도를 이행하였다는 사실을 확인한 보안사고 보고서가 끊임없이 발생하게 되었다고 한다. 이는 현재 전 세계적으로 화제가 되고 있는 랜섬웨어를 통한 사이버공격보다 많은 수치를 기록하고 있으며, 해커들이 원격데스크탑 프로토콜을 악용해 네트워크에 침입하여 무수한 시스템과 컴퓨터를 장악하기 위해 랜섬웨어를 활용한 사례도 파악되었다고 한다.
실제 해커가 시스템이나 컴퓨터에 잠입하기 위해 활용하는 3가지 방법은 아래와 같다고 한다;
1. 시스템 관리자가 서버에 원격데스크탑 프로토콜 접근을 활성화하였으나 암호를 설정하지 않는 경우, 포트 3389에서 컴퓨터 IP주소에 접근하는 모든 사용자로 엔터키를 눌러 로그인할 수 있음
2. 로그인 자격증명을 추정해 사전 공격 방식으로 공통된 사용자명과 암호를 조합하여 조합가능한 모든 경우의 수를 대입하는 브루트 포스 공격을 시행 (brute-force attack)
3. 원격데스크탑 프로토콜에 대한 보안취약점을 노린 악성코드를 활용해 공개된 포트에 침투시킴
하지만 모든 원격데스크탑 프로토콜의 손상이 데이터 유출이나 악성 행위를 초래하지는 않는 것으로 조사되었다고는 하지만, 해킹되거나 보안성이 유출된 원격데스크탑 프로토콜은 온라인 상에서 암묵적인 거래가 이루어지고 있어 또 다른 부차적인 보안위협의 촉매제가 되고 있는 것이 아니냐는 우려도 제기되고 있는 실정이라 하겠다.
이번 FBI의 경고를 통해 기업 및 조직들이 자신들이 활용하고 있는 원격데스크탑 프로토콜 기술의 보안취약점을 인지하고 이에 대비할 수 있는 개선책이나 보완책을 시급히 마련해야 할 시기가 도래한 것으로 보인다.
원문보기
Nov 28, 2018
기업형 인공지능의 다음 단계는 자동화된 에이전트가 될 것으로 예상
Autonomous agents are the next phase of enterprise AI, claims Fetch.AI
현재 기업들이 구현해놓은 인공지능의 유용성은 비용절감과 효율성 증진을 위해 반복적인 프로세스를 자동화하는데 주 목적이 있다 볼 수 있겠다. 일례로 고객센터로 유입되는 간단한 고객문의와 스팸 필터, 그리고 사기탐지 작업을 처리하는 챗봇 등이 해당된다 볼 수 있겠는데, 이러한 유형의 작업들은 인간보다 기기가 훨씬 빠르고 효율적인 업무수행이 가능하며 실수한 내용을 학습하여 이를 수정해나갈 수 있기 때문이라 하겠다.
하지만 만일 인공지능이 협상이나 자산과 같은 데이터의 가치를 밝혀내는 복잡한 임무를 담당하게 될 수 있을까? 미국 캠브리지의 스타트업인 Fetch.AI社에 의하면, 인류가 나아가야 할 다음 방향이 다름아닌 자동화된 에이전트의 구현이라는 주장이 제기되어 관련 내용을 조사해보기로 한다.
Fetch.AI社가 개발한 인공지능은 실제 세상이 존재물들 (호텔 객실, 비행기 좌석, 물리적 통화자산 등)을 자동화된 경제적 에이전트로서 대표하며, 공개 경제 프레임워크라 불리우는 분산형 플랫폼을 통해 어떠한 인간의 개입없이 미리 정의된 상황에 의거해 최적의 결과물을 찾아내는 업무를 수행한다고 한다.
이러한 가상의 세계와 상호작용하는 에이전트들을 통해 가상 세계 내 모든 자동화 에이전트들의 집합적 지능을 전담하고 이들 사이의 각종 데이터 처리나 의사결정의 지원은 스마트 원장기술을 통해 이루어질 것으로 알려지고 있다 하겠다.
상기 Fetch.AI 플랫폼은 2019년 베타버전이 출시될 예쩡이지만, 현재 과학장비 예약 플랫폼인 Clustermarket社와의 협약을 통해 보다 빠른 출시가 이루어질 수 있을 것으로 보이며, 기존 전문화되고 값비싼 가격에 소량이 소모되던 과학 실험용 장비들이 Clustermarket社에서 제공하는 연구기관 및 기업용 플랫폼을 통해 장비와 서비스를 제공할 수 있는 온라인 마켓플레이스 형태로 활용될 것으로 알려지고 있다.
기업용 인공지능이 비용절감과 관련해 다양한 형태로 도입이 우선 이루어지는 형태가 주를 이루었으나, 이제 기업의 데이터 저장공간을 활용해 새로운 활용도를 찾게 만드는 방식으로 전환되어감에 따라 자체 플랫폼을 통해 외부 도구나 플랫폼의 도움없이도 데이터, 모델, 알고리즘을 안전하게 공유해 새로운 인사이트를 도출해낼 수 있을 길이 열리게 될 것으로 예상되고 있다 하겠다.
원문보기
현재 기업들이 구현해놓은 인공지능의 유용성은 비용절감과 효율성 증진을 위해 반복적인 프로세스를 자동화하는데 주 목적이 있다 볼 수 있겠다. 일례로 고객센터로 유입되는 간단한 고객문의와 스팸 필터, 그리고 사기탐지 작업을 처리하는 챗봇 등이 해당된다 볼 수 있겠는데, 이러한 유형의 작업들은 인간보다 기기가 훨씬 빠르고 효율적인 업무수행이 가능하며 실수한 내용을 학습하여 이를 수정해나갈 수 있기 때문이라 하겠다.
하지만 만일 인공지능이 협상이나 자산과 같은 데이터의 가치를 밝혀내는 복잡한 임무를 담당하게 될 수 있을까? 미국 캠브리지의 스타트업인 Fetch.AI社에 의하면, 인류가 나아가야 할 다음 방향이 다름아닌 자동화된 에이전트의 구현이라는 주장이 제기되어 관련 내용을 조사해보기로 한다.
Fetch.AI社가 개발한 인공지능은 실제 세상이 존재물들 (호텔 객실, 비행기 좌석, 물리적 통화자산 등)을 자동화된 경제적 에이전트로서 대표하며, 공개 경제 프레임워크라 불리우는 분산형 플랫폼을 통해 어떠한 인간의 개입없이 미리 정의된 상황에 의거해 최적의 결과물을 찾아내는 업무를 수행한다고 한다.
이러한 가상의 세계와 상호작용하는 에이전트들을 통해 가상 세계 내 모든 자동화 에이전트들의 집합적 지능을 전담하고 이들 사이의 각종 데이터 처리나 의사결정의 지원은 스마트 원장기술을 통해 이루어질 것으로 알려지고 있다 하겠다.
상기 Fetch.AI 플랫폼은 2019년 베타버전이 출시될 예쩡이지만, 현재 과학장비 예약 플랫폼인 Clustermarket社와의 협약을 통해 보다 빠른 출시가 이루어질 수 있을 것으로 보이며, 기존 전문화되고 값비싼 가격에 소량이 소모되던 과학 실험용 장비들이 Clustermarket社에서 제공하는 연구기관 및 기업용 플랫폼을 통해 장비와 서비스를 제공할 수 있는 온라인 마켓플레이스 형태로 활용될 것으로 알려지고 있다.
기업용 인공지능이 비용절감과 관련해 다양한 형태로 도입이 우선 이루어지는 형태가 주를 이루었으나, 이제 기업의 데이터 저장공간을 활용해 새로운 활용도를 찾게 만드는 방식으로 전환되어감에 따라 자체 플랫폼을 통해 외부 도구나 플랫폼의 도움없이도 데이터, 모델, 알고리즘을 안전하게 공유해 새로운 인사이트를 도출해낼 수 있을 길이 열리게 될 것으로 예상되고 있다 하겠다.
원문보기
멀티클라우드 기술개발 동향 및 실 도입 사례 분석
2018-10-10 Why should we be looking to multi-cloud?
지난 2017년 Gartner社에서 개최한 심포지엄에 참석한 AWS社의 최고경영자 Andrew Jassy씨는 단일 클라우드는 존재치 않을 것으로 예상되며, 복수의 서비스 제공방식을 취하는 대형 클라우드 기업체들은 소수에 불과하나 이러한 추세는 증가해나갈 것이라는 주장을 내세운지 1년이 지났고, 현재 이러한 예상이 적중하여 약 80퍼센트 이상의 기업체들이 멀티 클라우드 방식으로 전환하고 있음이 최근 발표된 연구보고서에 나타나 기업체들의 멀티 클라우드 도입 현황을 살펴보고자 한다.
Rightscale社에서 발간한 클라우드 실태보고서에 의하면, 전체 조사대상 기업들의 약 80퍼센트 가량이 멀티 클라우드로 전환하고 있음이 나타났으며, 이러한 주요 원인은 어플리케이션 별 가장 적합한 클라우드를 선택할 수 있는 자유권이 주어지기 때문인 것으로 나타났다고 한다. 물론 이러한 멀티 클라우드 방식이 일 단위에 기반을 둔 방식 전환을 의미하지는 않으며 클라우드를 통해 데이터를 저장하는 방식이 현재도 매우 유용하게 활용되고 있는 것으로 나타났다고 한다.
또한 지난 3년 간 서로 다른 클라우드 서비스 제공업체와 함께 1 페타바이트의 데이터를 저장하는 비용을 조사함에 있어 초기 투여비용은 AWS社에 저장하는 비용이 약 75만 달러가 발생하였으며, 저장과 복제 과정에서 약 150만 달러의 비용이 발생하였다고 한다. 여기서 단일 클라우드에 데이터를 저장한 뒤 다른 클라우드에 데이터를 복사함으로서 비용을 빠르게 낮출 수 있음이 발견되었다고 한다. 또한 Amazon社의 AWS와 Microsoft社의 Azure 서비스의 결합은 기존 AWS 보다 저렴하고 동일한 수준의 서비스를 제공할 수 있을 뿐 아니라 Wasabi 또는 Backblaze 같은 클라우드 저장서비스 제공업체들을 사용할 경우, 데이터 백업비용이 AWS를 단독으로 사용할 때와 거의 동일한 것으로 나타났다고 한다.
뿐만 아니라 클라우드 내에서 데이터를 분석하는 작업을 통해 데이터 분석에 소요되는 높은 비용소요를 낮출 수 있는 좋은 방안으로 대두되고 있는데, 이는 데이터를 클라우드로 전송한 뒤 데이터 분석을 수행하면, 데이터를 삭제하고 결과값을 유지해야하는 어플리케이션을 사용할 경우 추가적인 비용을 지불하는 과정에서 소요되는 비용지출을 막는 효과도 누릴 수 있게 된다고 한다.
위와 같은 작업을 이행한 선두적인 기업은 아마 뉴욕타임즈일 것으로 예상되고 있는데, 이들은 자신들이 보유하고 있는 신문의 이미지를 AWS로 저장시켜 모든 데이터에서 문자 인식 및 텍스트를 추출한 뒤 클라우드에 저장한 모든 이미지를 버려 유지비용을 절감시키는 작업을 이행한 것으로 나타났다고 한다.
이처럼 멀티 클라우드는 확장가능한 분석이나 컨텐츠 배포, 버스트 컴퓨팅과 같은 다양한 잠재 어플리케이션을 보유하고 있으며, 데이터의 위치나 저장비용과 같이 데이터 검색의 효율성에 일부 해결해야 할 과제들이 남아있지만, 멀티 클라우드를 통한 데이터관리에 아래 4가지 주요 원칙을 중심으로 과제를 해결해나가면 될 것으로 예상된다고 한다;
1. 모든 클라우드들은 단일 API를 보유할 것
2. 데이터를 클라우드로 전송할 때 고유의 데이터 형식을 유지할 것
3. 네트워크 대신 보유자원을 활용해 하나의 클라우드에서 다른 클라우드로 이동할 때, 데이터를 푸시하거나 멀티 클라우드를 관리할 수 있는 기능을 포함시킬 것
4. 메타데이터를 검색할 수 있게 지원할 것
상기 4가지 요소들 중 메타데이터의 검색이 가장 중요시 되고 있으며, 이는 사용 중인 모든 클라우드 전반에 걸쳐 데이터를 검색할 수 있게 해주는 환경을 제공해주기 때문이라 볼 수 있다고 한다. 이러한 환경을 통해 데이터 저장 시 태그를 지정할 경우, 정책결정이나 내용을 변경할 경우 보다 손쉬운 데이터 검색이 가능해지기 때문이라고 한다.
서비스 공급업체들 간 데이터를 저장하게되면 데이터 복원기능이 증가하고 비용도 절감되는 효과가 있으나 데이터 백업과 관련된 문제가 발생할 수 있는 바, 자신의 기업환경에 적합한 데이터 전략을 수립하여 필요한 데이터를 취급함에 있어 보다 효율적인 디지털 환경을 구축하는 탄력성을 기업들이 발빠르게 구축해야 할 것으로 예상되고 있다 하겠다.
원문보기
지난 2017년 Gartner社에서 개최한 심포지엄에 참석한 AWS社의 최고경영자 Andrew Jassy씨는 단일 클라우드는 존재치 않을 것으로 예상되며, 복수의 서비스 제공방식을 취하는 대형 클라우드 기업체들은 소수에 불과하나 이러한 추세는 증가해나갈 것이라는 주장을 내세운지 1년이 지났고, 현재 이러한 예상이 적중하여 약 80퍼센트 이상의 기업체들이 멀티 클라우드 방식으로 전환하고 있음이 최근 발표된 연구보고서에 나타나 기업체들의 멀티 클라우드 도입 현황을 살펴보고자 한다.
Rightscale社에서 발간한 클라우드 실태보고서에 의하면, 전체 조사대상 기업들의 약 80퍼센트 가량이 멀티 클라우드로 전환하고 있음이 나타났으며, 이러한 주요 원인은 어플리케이션 별 가장 적합한 클라우드를 선택할 수 있는 자유권이 주어지기 때문인 것으로 나타났다고 한다. 물론 이러한 멀티 클라우드 방식이 일 단위에 기반을 둔 방식 전환을 의미하지는 않으며 클라우드를 통해 데이터를 저장하는 방식이 현재도 매우 유용하게 활용되고 있는 것으로 나타났다고 한다.
또한 지난 3년 간 서로 다른 클라우드 서비스 제공업체와 함께 1 페타바이트의 데이터를 저장하는 비용을 조사함에 있어 초기 투여비용은 AWS社에 저장하는 비용이 약 75만 달러가 발생하였으며, 저장과 복제 과정에서 약 150만 달러의 비용이 발생하였다고 한다. 여기서 단일 클라우드에 데이터를 저장한 뒤 다른 클라우드에 데이터를 복사함으로서 비용을 빠르게 낮출 수 있음이 발견되었다고 한다. 또한 Amazon社의 AWS와 Microsoft社의 Azure 서비스의 결합은 기존 AWS 보다 저렴하고 동일한 수준의 서비스를 제공할 수 있을 뿐 아니라 Wasabi 또는 Backblaze 같은 클라우드 저장서비스 제공업체들을 사용할 경우, 데이터 백업비용이 AWS를 단독으로 사용할 때와 거의 동일한 것으로 나타났다고 한다.
뿐만 아니라 클라우드 내에서 데이터를 분석하는 작업을 통해 데이터 분석에 소요되는 높은 비용소요를 낮출 수 있는 좋은 방안으로 대두되고 있는데, 이는 데이터를 클라우드로 전송한 뒤 데이터 분석을 수행하면, 데이터를 삭제하고 결과값을 유지해야하는 어플리케이션을 사용할 경우 추가적인 비용을 지불하는 과정에서 소요되는 비용지출을 막는 효과도 누릴 수 있게 된다고 한다.
위와 같은 작업을 이행한 선두적인 기업은 아마 뉴욕타임즈일 것으로 예상되고 있는데, 이들은 자신들이 보유하고 있는 신문의 이미지를 AWS로 저장시켜 모든 데이터에서 문자 인식 및 텍스트를 추출한 뒤 클라우드에 저장한 모든 이미지를 버려 유지비용을 절감시키는 작업을 이행한 것으로 나타났다고 한다.
이처럼 멀티 클라우드는 확장가능한 분석이나 컨텐츠 배포, 버스트 컴퓨팅과 같은 다양한 잠재 어플리케이션을 보유하고 있으며, 데이터의 위치나 저장비용과 같이 데이터 검색의 효율성에 일부 해결해야 할 과제들이 남아있지만, 멀티 클라우드를 통한 데이터관리에 아래 4가지 주요 원칙을 중심으로 과제를 해결해나가면 될 것으로 예상된다고 한다;
1. 모든 클라우드들은 단일 API를 보유할 것
2. 데이터를 클라우드로 전송할 때 고유의 데이터 형식을 유지할 것
3. 네트워크 대신 보유자원을 활용해 하나의 클라우드에서 다른 클라우드로 이동할 때, 데이터를 푸시하거나 멀티 클라우드를 관리할 수 있는 기능을 포함시킬 것
4. 메타데이터를 검색할 수 있게 지원할 것
상기 4가지 요소들 중 메타데이터의 검색이 가장 중요시 되고 있으며, 이는 사용 중인 모든 클라우드 전반에 걸쳐 데이터를 검색할 수 있게 해주는 환경을 제공해주기 때문이라 볼 수 있다고 한다. 이러한 환경을 통해 데이터 저장 시 태그를 지정할 경우, 정책결정이나 내용을 변경할 경우 보다 손쉬운 데이터 검색이 가능해지기 때문이라고 한다.
서비스 공급업체들 간 데이터를 저장하게되면 데이터 복원기능이 증가하고 비용도 절감되는 효과가 있으나 데이터 백업과 관련된 문제가 발생할 수 있는 바, 자신의 기업환경에 적합한 데이터 전략을 수립하여 필요한 데이터를 취급함에 있어 보다 효율적인 디지털 환경을 구축하는 탄력성을 기업들이 발빠르게 구축해야 할 것으로 예상되고 있다 하겠다.
원문보기
Oct 22, 2018
"AMD 대 인텔" 프로세서 최강자 전쟁
Dave Stevenson | TechAdvisor
AMD와 인텔의 유서깊은 경쟁 관계는 해가 지나도 사그라질 기미가 보이질 않는다. 12nm 및 14nm 전선의 해는 이미 저물기 시작했지만, 이제는 7nm 또는 10nm 고지를 누가 먼저 선점하는가를 놓고 경쟁하고 있다. 둘 가운데 먼저 선점하는 쪽이 엄청난 이점을 가져가기 때문이다. 아마도 내년쯤이면 이 경쟁의 승자를 알 수 있을 듯하다.
10여 년 전, 인텔과 AMD는 명실공히 세계의 정상에 서 있었다. 노트북이 있는 곳이면 어디서나 인텔 고유의 로고를 볼 수 있었고, 2006년 그래픽 실력자인 ATI를 인수한 AMD는 밝은 미래가 보장된 것처럼 보였다. 하지만 자만했던 탓일까? 두 기업은 세월의 변화를 기대만큼 제대로 쫓아가지 못했다.
IT 산업의 지평이 빠르게 변하고 있음에도 불구하고, 모바일 컴퓨팅으로의 전환이 느렸던 두 기업 탓에 다른 소규모 칩 제조업체들(가장 대표적으로는 ARM이 있지만 그 외에도 VIA, 퀄컴 등)이 새로운 시장의 상당 부분을 장악할 수 있게 되었다.
몇 년 전까지 다소 어두웠던 전망을 떨쳐 버리고 게이밍 PC가 부활하고 있는 가운데 노트북 선택지는 그 어느 때보다 더 다양해졌고, 이제는 오히려 태블릿 시장이 약세를 보이고 있는 상황이다.
AMD와 인텔 프로세서의 현 주소
2018년도 이제 마무리 단계에 접어들어가는 가운데, 얼마 전 인텔이 9세대 프로세서를 발표했다. 8세대 커피 레이크보다 한 단계 업그레이드 된 것은 사실이지만, 그렇다고 비약적으로 개선된 점이 보이지도 않는다. 미드 레인지 제품군으로부터 하이퍼스레딩을 배제하고, 소비자 데스크톱 프로세서의 가장 최상급 제품군에 9세대 i9을 포함시킨 선택이 눈에 띈다.
AMD의 라이젠 2(Ryzen 2) 제품군은 올해 초에 엄청난 강세를 보였으며 아직까지도 인텔의 최상급 제품에 대항해 강력한 경쟁력을 자랑하고 있다. 물론 싱글 코어 부문에서는 인텔에게 처참하게 밀리고 있지만 말이다(이 점에 대해서는 이견의 여지가 없을 것이다).
하지만 인텔이 싱글 코어 부문에서 AMD보다 앞선 것은 어제 오늘 일은 아니다. 게다가 AMD는 매우 훌륭한 에어쿨러와 CPU를 함께 제공하며, 코드당 훨씬 더 나은 가치 제안을 제공한다. AMD 프로세서는 결코 느리다고 할 수 없으며, 매우 무거운 워크로드도 쉽게 처리할 수 있다. 비록 인텔이 시장에서 AMD보다 선방하고 있는 것은 사실이지만, 여기에는 그만큼의 비용이 따른다.
현실적으로 봤을 때, 인텔이 싱글 코어 성능에서 보이는 강세는 전체적으로 보면 큰 차이를 만들어 내지는 못하겠지만 그럼에도 불구하고 인텔이 이 분야에서 강세를 보이는 것은 사실이다.
AMD의 라이젠 3가 내년 초에 출시될 예정이지만, 정작 인텔과 AMD의 다음 대규모 격전지는 10nm 또는 7nm 기술이 될 것이다. AMD와 인텔 모두 소규모 나노 아키텍처에서 안정적인 칩을 생산하기 위해 서두르고 있으며, 먼저 이 분야를 선점한 쪽이 막대한 이점을 갖게 될 것이다.
인텔과 AMD의 경쟁이 중요한 이유
인텔과 AMD의 경쟁이 중요한 이유는 전통적인 노트북이나 PC를 구매하려면 여전히 소비자들에게는 AMD와 인텔 프로세서 외에는 선택지가 없기 때문이다. 하지만 PC가 소비자 시장에서 다소 슬럼프를 겪는다고 해서 인텔이나 AMD가 망할 것이라고 생각해서는 곤란하다. 당연한 얘기지만 인텔은 PC나 노트북 프로세서 외에도 많은 수입원을 확보하고 있다.
인텔은 그 외에도 그래픽 프로세서, 유/무선 네트워크 어댑터, 서버 및 워크스테이션 프로세서와 부품들, 셋톱 박스 부품 등을 생산한다. 스마트폰 중에도 상당수가 인텔 칩을 사용한다. 아이폰 X 가운데 일부 모델들은 인텔 모뎀을 사용하기도 한다.
AMD는 인텔보다는 다소 규모가 작은 업체다. 인텔의 경우 미국 외에도 아일랜드, 이스라엘, 중국 등지에 있는 생산 공장에서 자체 칩을 생산하는 반면, AMD는 2009년 마지막 남은 공장조차도 매각했다. 현재는 ARM, VIA, 미디어텍(MediaTek) 등의 기업과 마찬가지로 칩 설계는 AMD가 하고, 생산은 아웃소싱하고 있다. 마이크로프로세서 생산에는 엄청나게 많은 비용이 들어가기 때문이다.
두 업체가 걸어온 길
두 기업 모두 긴 혁신의 역사를 가지고 있다. 인텔은 1974년 8080 프로세서를 탄생시키며 x86 프로세서의 기반을 닦았다. 이는 지금으로부터 30여 년 전에 데스크탑 PC의 기반을 마련하는 역할을 했다.
인텔은 영리한 마케팅을 하기로 유명한 기업이기도 하다. 2000년대 중반에 저전력 프로세서와 무선 칩, 그리고 모바일 칩셋이라는 구성으로 출시된 인텔의 센트리노 플랫폼은 배터리 수명을 비약적으로 늘린, 데스크톱 클래스의 컴퓨팅 파워를 자랑하는 칩이라는 명성을 얻으며 시장을 휩쓸었다. X86 브랜드에서 '펜티엄'으로의 전환 역시 인텔의 똑똑한 PR 역량을 여실히 보여준 사례다.
엄청난 자금력과 기발한 발상으로 경쟁업체를 압도하는 인텔 마케팅부의 화려한 경력은 그 이후로도 계속된다. 인텔의 울트라북 트레이드마크가 성공한 것은 사실 마이크로소프트의 윈도우 8의 공이 작지 않았지만, 그렇다고 해서 소비자들이 원하는 것은 클럭 주파수나 어려운 기계가 아니라 간편하고 단순한 브랜드라는 것을 간파한 인텔 마케팅의 승리가 거저 얻어진 것은 아니었다.
한편, AMD는 예전에도 지금도 일종의 아웃사이더와 같은 포지션을 유지하고 있다. 마케팅 컨설턴트 업체 머큐리 리서치(Mercury Research)의 보고서에 따르면, AMD의 시장 점유율은 지난 2006년 22% 가량이었으며 현재는 콘솔 시장에서의 강세 덕분에 약 17% 정도를 유지하고 있다. 엑스박스 원과 플레이스테이션 4 모두 커스텀 8 코어 AMD '재규어' 프로세서를 채택하고 있다.
AMD가 가장 최근 시행한 대규모 혁신은 아마도 2006년 GPU 제조업체인 ATI를 인수한 일일 것이다. 56억 달러에 ATI를 인수한 AMD는 이제 통합 그래픽 칩(integrated graphics chips, CPU와 GPU가 하나의 칩에 병합됨)을 제조할 수 있다는 점에서 인텔과 어깨를 나란히 하게 됐다.
그 결과 그래픽 마력은 떨어지지만 전력 소비와 열 출력을 크게 줄일 수 있었다. 이제 그 자체로 엄청난 마력을 자랑하는 그래픽 카드의 시대는 갔다는 것을, 그리고 실리콘의 미래가 컴퓨팅 파워의 증가만큼이나 전력 소모량과 크기를 줄이는 데 있다는 사실을 AMD는 일찌감치 간파했다. 실제로 오늘날 대부분의 사용자는 모바일 기기를 선택할 때 '더 빠른 것' 보다 '더 오래 가는 것'을 선택한다.
두 업체의 잘못된 행보
표면적으로만 보면, AMD와 인텔 모두 모바일 기기 시장이 폭발적으로 증가하는 상황에서 각자 사용자들의 요구사항을 충족시킬 준비가 되어 있는 것으로 보인다. 데스크톱 PC 시장이 침체기에 접어들고, 노트북 판매량은 증가했으며, 모바일 폰은 혁신이 절실한 상황이었다.
인텔은 이미 노트북용 센트리노 플랫폼으로 높은 평가를 받고 있는 상황이었으며, AMD의 튜리온(Turion)은 큰 차이로 2등인 상황에서 두 기업 모두 모바일이 시장의 미래가 될 것이라는 전망 하에 본격적인 경쟁 체제에 돌입했다.
초반은 인텔이 강세를 보였다. 혹시 '넷북'을 기억하는가. 넷북이란 게 세상에 나오기 전에는 500달러 이하의 가격대에서 노트북을 구매하기 위해서는 속도나 크기나, 배터리 수명도 어느 정도 포기해야만 했다.
영국에서 2007년 발매된 아수스 이 PC 700(Asus Eee PC 701) 같은 모델은 260달러 이하의 가격에 무게는 1kg 미만이었으며 LAN 게임 같은 것은 어려울 지 몰라도 기본적인 업무용 애플리케이션을 무리 없이 구동할 수 있었다. 무엇보다 (가장 중요한 것은) 웹 브라우저에서 애플리케이션을 구동할 수 있었다는 사실이다.
이와 같은 모델에는 어떤 프로세서가 사용됐을까. 바로 셀러론(Celeron)의 초 저전력 버전 프로세서였다.
넷북은 엄청난 상업적 성공을 거두었으며 인텔에서는 아톰(Atom) 프로세서를 내놓았다. 아톰 프로세서는 인텔의 실리콘 가운데 가장 싼 가격의 제품이었다. 초창기 아톰 CPU는 1,000개 묶음을 30달러 미만의 비용으로 구매할 수 있었으며 이런 가격 경쟁력 덕분에 넷북은 몇 년간 시장을 지배할 수 있었다. 이는 모두 소비자들이 작으면서도 값 싼 컴퓨터를 원했고, 모바일 프로세서 제조에서 풍부한 경험을 지닌 인텔이 이런 수요를 완벽하게 충족했기 때문이었다.
인텔에게 재앙은 태블릿이라는 모습으로 찾아왔다. 2008년 스티브 잡스는 "500달러 미만의 가격은 500달러 미만의 퀄리티 밖에 내지 못한다"고 말했으며, 2010년 1세대 아이패드를 출시하면서는 "넷북은 다른 기기보다 잘 난 것이 하나도 없다"고 말하기도 했다. 애플의 COO인 팀 쿡도 이에 동의하며 "넷북은 훌륭한 소비자 경험을 제공하지 못한다"고 말했다. 그렇게 아이패드의 시대가 도래했다.
인텔이나 AMD의 문제는 소비자의 선호도나, 모바일 기기의 강세를 점치지 못한 것이 아니었다. 문제는 폼 팩터였다. 아이패드는 2010년 첫 출시 당일에 무려 30만 대가 팔렸다. 전통적 폼 팩터의 노트북과 넷북, 전통적인 데스크톱 운영체제와 전통적인 x86 하드웨어를 채택한 인텔과 AMD는 잘못된 줄에 선 것이다.
사실 인텔, 마이크로소프트, 그리고 HP 모두 아이패드가 나오기 수 년 전에 이미 태블릿 제품을 출시해 보려고 노력했었다. 하지만 키보드와 마우스에 최적화 된 윈도우 운영체제와 짧은 배터리 수명, 그리고 두텁고 무거운 하드웨어 때문에 아무도 이들 기업의 태블릿을 사용하려 하지 않았다.
인텔이나 AMD가 곤란을 겪은 이유는 아이패드, 그리고 그 뒤를 이어 소니, 삼성 등에서 출시한 다른 태블릿들이 프로세서를 필요로 하지 않았기 때문이 아니라, 다르고 새로운 종류의 프로세서를 필요로 했기 때문이었다. SoC(system on chip)의 세계에서는 컴퓨터의 모든 기능이 단 하나의 칩에 내장되어 있었으며 이 분야는 이미 영국의 프로세서 기업 ARM이 꽉 쥐고 있었다.
ARM의 프로세서는 인텔이나 AMD 등이 선호하던 전통적인 칩과는 완전히 구조가 달랐다. ARM의 RISC(Reduced Instruction Set Computing) 프로세서는 x86 프로세서보다 구조적으로 훨씬 단순했으며, 이로 인해 비용도 전력 소모량도 더 적었다. 아이패드를 비롯한 후속 태블릿들이 시장을 장악해 나가면서 AMD와 인텔은 '버스를 놓친 게 아니냐'는 지적도 나왔다.
그렇게 2015년이 되자 넷북은 완전히 사망 선고를 받았고, 노트북보다 더 긴 배터리 수명과 더 싼 비용을 자랑하는 고성능 태블릿이 시장을 장악하게 됐다.
그 이후 x86 하드웨어의 오랜 우방이었던 마이크로소프트조차도 이 당시에는 인텔과 AMD를 등질 수 밖에 없었다. 2012년 출시된 윈도우 RT는 ARM 칩을 사용한 기기에서 구동이 가능한 최초의 윈도우 버전이었다. 이로써 마이크로소프트는 (최소한 이론적으로는) 저가형 태블릿 시장으로 갈 수 있는 길을 트게 된 것이며 동시에 인텔 입장에서는 한층 더 숨통을 조이는 선택이 되었다.
하지만 윈도우 RT 플랫폼은 결국 완전히 실패하고 말았다. 2013년 마이크로소프트는 판매되지 않은 윈도우 RT 기기들로 인해 9억 달러 규모의 감가상각을 감수해야 했다. 마이크로소프트 CFO 에이미 후드는 "우리는 분발해야 한다. 특히 모바일 기기 분야에서 말이다"고 말했지만 사실 이는 '분발' 정도로는 어림도 없을 만큼의 큰 손해였다.
2018년 현재, 시장에서는 아수스 노바고(Asus NovaGo)와 같은 퀄컴 프로세서를 장착한 윈도우 10 노트북이 팔리고 있다. 물론 인텔도 마이크로소프트에만 희망을 걸고 있지는 않다. 오늘날 인텔은 웨어러블과 같은 새로운 IT 분야로 시선을 돌리고 있다. 또 에어로 컴퓨트 보드(Aero Compute Board)와 리얼 센스(RealSense) 카메라를 통합하는 등 드론 분야에도 발을 담그고 있다. 태블릿, 웨어러블 및 울트라-포터블 컴퓨팅 세계에 비교적 늦게 진입했지만 인텔은 여전히 엄청난 저력을 보유한 채 추격하고 있다.
미래의 새로운 전장은 ‘게이밍 PC’
게임 산업은 매년 영국 경제에서 약 20억 파운드 규모를 차지한다. 그리고 게이밍 PC 분야에서 지배적인 위치를 차지하고 있는 것은 인텔이 아니라 AMD이다. 인텔 역시 3D 그래픽 칩을 생산하고 있기는 하지만 주 전공은 통합 그래픽 칩이다.
통합 그래픽 칩은 랩탑에 이상적이다. 통합 그래픽 프로세서를 사용하면 노트북 가격을 저렴하게 유지하면서도 전력 소모량을 줄일 수 있으며, 일반적인 생각과 달리 충분한 3D 프로세싱 파워를 제공할 수도 있다.
그러나 최신 게임을, 최신 콘솔이 민망해 질 정도의 고사양 그래픽으로 플레이 하고 싶다면 답은 언제나 독립적인 그래픽 카드를 사용하는 것이었으며 AMD는 바로 이 분야에서 앞서 나가고 있다.
현재 AMD는 저사양 수동 냉각형 카드에서부터 약 600달러 가량의 최신 RX Vega 64 카드에 이르기까지 다양한 범주의 옵션을 제공하고 있다. AMD는 독립 그래픽 카드 외의 다른 분야에서도 충분히 강세를 보이고 있다.
엑스박스 원, 플레이스테이션 4 외에 닌텐도 Wii U 역시 AMD의 GPU를 사용한다. AMD는 태블릿이나 하이브리드 같은 플랫폼 개발에서는 약세를 보일지 몰라도 많은 게이머들에게는 엄청난 찬사를 받고 있다.
인텔과 AMD CPU, 최종 선택은
데스크톱 PC를 조립하려 할 경우, AMD와 인텔 사이의 고민은 그 어느 때보다 첨예할 수 밖에 없다. 고려해야 할 요소도 무척 많다. 유명 온라인 유통 업체는 하나 같이 수백 가지의 CPU 선택지를 제공하고 있다. 예산이 한정적인 사용자라면 저가형 CPU 모델에서는 AMD가 확실한 강세를 보이고 있다. 그렇다고 해서 AMD가 하이엔드 제품을 내놓지 않는 것은 아니다. AMD의 라이젠 프로세서는 스레드리퍼(Threadripper)와 마찬가지로 인텔 CPU의 아성에 도전할 수 있는 수작이다.
지난 4월 19일 라이젠 2를 출시하면서 AMD는 이제 인텔의 최상위급 프로세서와 직접적으로 경쟁할 수 있는 칩 개발에 착수했다. 라이젠 2700x는 훨씬 더 저렴하면서도 뛰어난 스톡 쿨러(stock cooler)로 8700k와 직접적으로 경쟁할 예정이다. 현재 데스크톱 PC를 조립중인 독자가 있다면 꼭 한번 고려해 보기를 추천한다.
한편 기존에 인텔 CPU를 사용 중이면서 업그레이드를 고려하는 사용자의 경우 새로운 메인보드와 칩셋, 그리고 소켓으로 바꿔야 한다는 것 때문에 AMD로 건너가는 것이 망설여 질 수 있다. 인텔은 앞으로도 시장에 대한 지배력을 한동안 지속해 나갈 것으로 보이며 미드 레인지 및 하이 엔드 프로세서의 경우 엄청나게 다양한 선택지가 존재한다. 일상적인 컴퓨팅 작업을 위해서는 코어 i5 만으로도 충분할 수도 있다(현재 이 부문에서 최강자는 6코어 i5-8600K이다).
라이젠 5는 비슷하거나 더 적은 가격에 똑같이 6코어를 제공하며 인텔에 도전장을 내밀고 있다. 대부분 사용자가 그래픽 카드에서 아낀 돈으로 미드 레인지 CPU를 선택하는 상황에서는 AMD가 확실히 강점을 가질 수 있을 것이다.
절대 다수의 게이머들이 아직도 멀티코어 프로세서, 그 가운데서도 특히 4코어 이상 프로세서의 이점을 완전히 누리지 못하고 있다. 그러나 최신 미드 레인지 칩을 선택한다면 2개의 엑스트라 코어를 무료로 제공받게 되는 것이며 앞으로 출시될 게임들은 이런 프로세서를 필요로 하게 될 것이다. editor@itworld.co.kr
원문보기
AMD와 인텔의 유서깊은 경쟁 관계는 해가 지나도 사그라질 기미가 보이질 않는다. 12nm 및 14nm 전선의 해는 이미 저물기 시작했지만, 이제는 7nm 또는 10nm 고지를 누가 먼저 선점하는가를 놓고 경쟁하고 있다. 둘 가운데 먼저 선점하는 쪽이 엄청난 이점을 가져가기 때문이다. 아마도 내년쯤이면 이 경쟁의 승자를 알 수 있을 듯하다.
10여 년 전, 인텔과 AMD는 명실공히 세계의 정상에 서 있었다. 노트북이 있는 곳이면 어디서나 인텔 고유의 로고를 볼 수 있었고, 2006년 그래픽 실력자인 ATI를 인수한 AMD는 밝은 미래가 보장된 것처럼 보였다. 하지만 자만했던 탓일까? 두 기업은 세월의 변화를 기대만큼 제대로 쫓아가지 못했다.
IT 산업의 지평이 빠르게 변하고 있음에도 불구하고, 모바일 컴퓨팅으로의 전환이 느렸던 두 기업 탓에 다른 소규모 칩 제조업체들(가장 대표적으로는 ARM이 있지만 그 외에도 VIA, 퀄컴 등)이 새로운 시장의 상당 부분을 장악할 수 있게 되었다.
몇 년 전까지 다소 어두웠던 전망을 떨쳐 버리고 게이밍 PC가 부활하고 있는 가운데 노트북 선택지는 그 어느 때보다 더 다양해졌고, 이제는 오히려 태블릿 시장이 약세를 보이고 있는 상황이다.
AMD와 인텔 프로세서의 현 주소
2018년도 이제 마무리 단계에 접어들어가는 가운데, 얼마 전 인텔이 9세대 프로세서를 발표했다. 8세대 커피 레이크보다 한 단계 업그레이드 된 것은 사실이지만, 그렇다고 비약적으로 개선된 점이 보이지도 않는다. 미드 레인지 제품군으로부터 하이퍼스레딩을 배제하고, 소비자 데스크톱 프로세서의 가장 최상급 제품군에 9세대 i9을 포함시킨 선택이 눈에 띈다.
AMD의 라이젠 2(Ryzen 2) 제품군은 올해 초에 엄청난 강세를 보였으며 아직까지도 인텔의 최상급 제품에 대항해 강력한 경쟁력을 자랑하고 있다. 물론 싱글 코어 부문에서는 인텔에게 처참하게 밀리고 있지만 말이다(이 점에 대해서는 이견의 여지가 없을 것이다).
하지만 인텔이 싱글 코어 부문에서 AMD보다 앞선 것은 어제 오늘 일은 아니다. 게다가 AMD는 매우 훌륭한 에어쿨러와 CPU를 함께 제공하며, 코드당 훨씬 더 나은 가치 제안을 제공한다. AMD 프로세서는 결코 느리다고 할 수 없으며, 매우 무거운 워크로드도 쉽게 처리할 수 있다. 비록 인텔이 시장에서 AMD보다 선방하고 있는 것은 사실이지만, 여기에는 그만큼의 비용이 따른다.
현실적으로 봤을 때, 인텔이 싱글 코어 성능에서 보이는 강세는 전체적으로 보면 큰 차이를 만들어 내지는 못하겠지만 그럼에도 불구하고 인텔이 이 분야에서 강세를 보이는 것은 사실이다.
AMD의 라이젠 3가 내년 초에 출시될 예정이지만, 정작 인텔과 AMD의 다음 대규모 격전지는 10nm 또는 7nm 기술이 될 것이다. AMD와 인텔 모두 소규모 나노 아키텍처에서 안정적인 칩을 생산하기 위해 서두르고 있으며, 먼저 이 분야를 선점한 쪽이 막대한 이점을 갖게 될 것이다.
인텔과 AMD의 경쟁이 중요한 이유
인텔과 AMD의 경쟁이 중요한 이유는 전통적인 노트북이나 PC를 구매하려면 여전히 소비자들에게는 AMD와 인텔 프로세서 외에는 선택지가 없기 때문이다. 하지만 PC가 소비자 시장에서 다소 슬럼프를 겪는다고 해서 인텔이나 AMD가 망할 것이라고 생각해서는 곤란하다. 당연한 얘기지만 인텔은 PC나 노트북 프로세서 외에도 많은 수입원을 확보하고 있다.
인텔은 그 외에도 그래픽 프로세서, 유/무선 네트워크 어댑터, 서버 및 워크스테이션 프로세서와 부품들, 셋톱 박스 부품 등을 생산한다. 스마트폰 중에도 상당수가 인텔 칩을 사용한다. 아이폰 X 가운데 일부 모델들은 인텔 모뎀을 사용하기도 한다.
AMD는 인텔보다는 다소 규모가 작은 업체다. 인텔의 경우 미국 외에도 아일랜드, 이스라엘, 중국 등지에 있는 생산 공장에서 자체 칩을 생산하는 반면, AMD는 2009년 마지막 남은 공장조차도 매각했다. 현재는 ARM, VIA, 미디어텍(MediaTek) 등의 기업과 마찬가지로 칩 설계는 AMD가 하고, 생산은 아웃소싱하고 있다. 마이크로프로세서 생산에는 엄청나게 많은 비용이 들어가기 때문이다.
두 업체가 걸어온 길
두 기업 모두 긴 혁신의 역사를 가지고 있다. 인텔은 1974년 8080 프로세서를 탄생시키며 x86 프로세서의 기반을 닦았다. 이는 지금으로부터 30여 년 전에 데스크탑 PC의 기반을 마련하는 역할을 했다.
인텔은 영리한 마케팅을 하기로 유명한 기업이기도 하다. 2000년대 중반에 저전력 프로세서와 무선 칩, 그리고 모바일 칩셋이라는 구성으로 출시된 인텔의 센트리노 플랫폼은 배터리 수명을 비약적으로 늘린, 데스크톱 클래스의 컴퓨팅 파워를 자랑하는 칩이라는 명성을 얻으며 시장을 휩쓸었다. X86 브랜드에서 '펜티엄'으로의 전환 역시 인텔의 똑똑한 PR 역량을 여실히 보여준 사례다.
엄청난 자금력과 기발한 발상으로 경쟁업체를 압도하는 인텔 마케팅부의 화려한 경력은 그 이후로도 계속된다. 인텔의 울트라북 트레이드마크가 성공한 것은 사실 마이크로소프트의 윈도우 8의 공이 작지 않았지만, 그렇다고 해서 소비자들이 원하는 것은 클럭 주파수나 어려운 기계가 아니라 간편하고 단순한 브랜드라는 것을 간파한 인텔 마케팅의 승리가 거저 얻어진 것은 아니었다.
한편, AMD는 예전에도 지금도 일종의 아웃사이더와 같은 포지션을 유지하고 있다. 마케팅 컨설턴트 업체 머큐리 리서치(Mercury Research)의 보고서에 따르면, AMD의 시장 점유율은 지난 2006년 22% 가량이었으며 현재는 콘솔 시장에서의 강세 덕분에 약 17% 정도를 유지하고 있다. 엑스박스 원과 플레이스테이션 4 모두 커스텀 8 코어 AMD '재규어' 프로세서를 채택하고 있다.
AMD가 가장 최근 시행한 대규모 혁신은 아마도 2006년 GPU 제조업체인 ATI를 인수한 일일 것이다. 56억 달러에 ATI를 인수한 AMD는 이제 통합 그래픽 칩(integrated graphics chips, CPU와 GPU가 하나의 칩에 병합됨)을 제조할 수 있다는 점에서 인텔과 어깨를 나란히 하게 됐다.
그 결과 그래픽 마력은 떨어지지만 전력 소비와 열 출력을 크게 줄일 수 있었다. 이제 그 자체로 엄청난 마력을 자랑하는 그래픽 카드의 시대는 갔다는 것을, 그리고 실리콘의 미래가 컴퓨팅 파워의 증가만큼이나 전력 소모량과 크기를 줄이는 데 있다는 사실을 AMD는 일찌감치 간파했다. 실제로 오늘날 대부분의 사용자는 모바일 기기를 선택할 때 '더 빠른 것' 보다 '더 오래 가는 것'을 선택한다.
두 업체의 잘못된 행보
표면적으로만 보면, AMD와 인텔 모두 모바일 기기 시장이 폭발적으로 증가하는 상황에서 각자 사용자들의 요구사항을 충족시킬 준비가 되어 있는 것으로 보인다. 데스크톱 PC 시장이 침체기에 접어들고, 노트북 판매량은 증가했으며, 모바일 폰은 혁신이 절실한 상황이었다.
인텔은 이미 노트북용 센트리노 플랫폼으로 높은 평가를 받고 있는 상황이었으며, AMD의 튜리온(Turion)은 큰 차이로 2등인 상황에서 두 기업 모두 모바일이 시장의 미래가 될 것이라는 전망 하에 본격적인 경쟁 체제에 돌입했다.
초반은 인텔이 강세를 보였다. 혹시 '넷북'을 기억하는가. 넷북이란 게 세상에 나오기 전에는 500달러 이하의 가격대에서 노트북을 구매하기 위해서는 속도나 크기나, 배터리 수명도 어느 정도 포기해야만 했다.
영국에서 2007년 발매된 아수스 이 PC 700(Asus Eee PC 701) 같은 모델은 260달러 이하의 가격에 무게는 1kg 미만이었으며 LAN 게임 같은 것은 어려울 지 몰라도 기본적인 업무용 애플리케이션을 무리 없이 구동할 수 있었다. 무엇보다 (가장 중요한 것은) 웹 브라우저에서 애플리케이션을 구동할 수 있었다는 사실이다.
이와 같은 모델에는 어떤 프로세서가 사용됐을까. 바로 셀러론(Celeron)의 초 저전력 버전 프로세서였다.
넷북은 엄청난 상업적 성공을 거두었으며 인텔에서는 아톰(Atom) 프로세서를 내놓았다. 아톰 프로세서는 인텔의 실리콘 가운데 가장 싼 가격의 제품이었다. 초창기 아톰 CPU는 1,000개 묶음을 30달러 미만의 비용으로 구매할 수 있었으며 이런 가격 경쟁력 덕분에 넷북은 몇 년간 시장을 지배할 수 있었다. 이는 모두 소비자들이 작으면서도 값 싼 컴퓨터를 원했고, 모바일 프로세서 제조에서 풍부한 경험을 지닌 인텔이 이런 수요를 완벽하게 충족했기 때문이었다.
인텔에게 재앙은 태블릿이라는 모습으로 찾아왔다. 2008년 스티브 잡스는 "500달러 미만의 가격은 500달러 미만의 퀄리티 밖에 내지 못한다"고 말했으며, 2010년 1세대 아이패드를 출시하면서는 "넷북은 다른 기기보다 잘 난 것이 하나도 없다"고 말하기도 했다. 애플의 COO인 팀 쿡도 이에 동의하며 "넷북은 훌륭한 소비자 경험을 제공하지 못한다"고 말했다. 그렇게 아이패드의 시대가 도래했다.
인텔이나 AMD의 문제는 소비자의 선호도나, 모바일 기기의 강세를 점치지 못한 것이 아니었다. 문제는 폼 팩터였다. 아이패드는 2010년 첫 출시 당일에 무려 30만 대가 팔렸다. 전통적 폼 팩터의 노트북과 넷북, 전통적인 데스크톱 운영체제와 전통적인 x86 하드웨어를 채택한 인텔과 AMD는 잘못된 줄에 선 것이다.
사실 인텔, 마이크로소프트, 그리고 HP 모두 아이패드가 나오기 수 년 전에 이미 태블릿 제품을 출시해 보려고 노력했었다. 하지만 키보드와 마우스에 최적화 된 윈도우 운영체제와 짧은 배터리 수명, 그리고 두텁고 무거운 하드웨어 때문에 아무도 이들 기업의 태블릿을 사용하려 하지 않았다.
인텔이나 AMD가 곤란을 겪은 이유는 아이패드, 그리고 그 뒤를 이어 소니, 삼성 등에서 출시한 다른 태블릿들이 프로세서를 필요로 하지 않았기 때문이 아니라, 다르고 새로운 종류의 프로세서를 필요로 했기 때문이었다. SoC(system on chip)의 세계에서는 컴퓨터의 모든 기능이 단 하나의 칩에 내장되어 있었으며 이 분야는 이미 영국의 프로세서 기업 ARM이 꽉 쥐고 있었다.
ARM의 프로세서는 인텔이나 AMD 등이 선호하던 전통적인 칩과는 완전히 구조가 달랐다. ARM의 RISC(Reduced Instruction Set Computing) 프로세서는 x86 프로세서보다 구조적으로 훨씬 단순했으며, 이로 인해 비용도 전력 소모량도 더 적었다. 아이패드를 비롯한 후속 태블릿들이 시장을 장악해 나가면서 AMD와 인텔은 '버스를 놓친 게 아니냐'는 지적도 나왔다.
그렇게 2015년이 되자 넷북은 완전히 사망 선고를 받았고, 노트북보다 더 긴 배터리 수명과 더 싼 비용을 자랑하는 고성능 태블릿이 시장을 장악하게 됐다.
그 이후 x86 하드웨어의 오랜 우방이었던 마이크로소프트조차도 이 당시에는 인텔과 AMD를 등질 수 밖에 없었다. 2012년 출시된 윈도우 RT는 ARM 칩을 사용한 기기에서 구동이 가능한 최초의 윈도우 버전이었다. 이로써 마이크로소프트는 (최소한 이론적으로는) 저가형 태블릿 시장으로 갈 수 있는 길을 트게 된 것이며 동시에 인텔 입장에서는 한층 더 숨통을 조이는 선택이 되었다.
하지만 윈도우 RT 플랫폼은 결국 완전히 실패하고 말았다. 2013년 마이크로소프트는 판매되지 않은 윈도우 RT 기기들로 인해 9억 달러 규모의 감가상각을 감수해야 했다. 마이크로소프트 CFO 에이미 후드는 "우리는 분발해야 한다. 특히 모바일 기기 분야에서 말이다"고 말했지만 사실 이는 '분발' 정도로는 어림도 없을 만큼의 큰 손해였다.
2018년 현재, 시장에서는 아수스 노바고(Asus NovaGo)와 같은 퀄컴 프로세서를 장착한 윈도우 10 노트북이 팔리고 있다. 물론 인텔도 마이크로소프트에만 희망을 걸고 있지는 않다. 오늘날 인텔은 웨어러블과 같은 새로운 IT 분야로 시선을 돌리고 있다. 또 에어로 컴퓨트 보드(Aero Compute Board)와 리얼 센스(RealSense) 카메라를 통합하는 등 드론 분야에도 발을 담그고 있다. 태블릿, 웨어러블 및 울트라-포터블 컴퓨팅 세계에 비교적 늦게 진입했지만 인텔은 여전히 엄청난 저력을 보유한 채 추격하고 있다.
미래의 새로운 전장은 ‘게이밍 PC’
게임 산업은 매년 영국 경제에서 약 20억 파운드 규모를 차지한다. 그리고 게이밍 PC 분야에서 지배적인 위치를 차지하고 있는 것은 인텔이 아니라 AMD이다. 인텔 역시 3D 그래픽 칩을 생산하고 있기는 하지만 주 전공은 통합 그래픽 칩이다.
통합 그래픽 칩은 랩탑에 이상적이다. 통합 그래픽 프로세서를 사용하면 노트북 가격을 저렴하게 유지하면서도 전력 소모량을 줄일 수 있으며, 일반적인 생각과 달리 충분한 3D 프로세싱 파워를 제공할 수도 있다.
그러나 최신 게임을, 최신 콘솔이 민망해 질 정도의 고사양 그래픽으로 플레이 하고 싶다면 답은 언제나 독립적인 그래픽 카드를 사용하는 것이었으며 AMD는 바로 이 분야에서 앞서 나가고 있다.
현재 AMD는 저사양 수동 냉각형 카드에서부터 약 600달러 가량의 최신 RX Vega 64 카드에 이르기까지 다양한 범주의 옵션을 제공하고 있다. AMD는 독립 그래픽 카드 외의 다른 분야에서도 충분히 강세를 보이고 있다.
엑스박스 원, 플레이스테이션 4 외에 닌텐도 Wii U 역시 AMD의 GPU를 사용한다. AMD는 태블릿이나 하이브리드 같은 플랫폼 개발에서는 약세를 보일지 몰라도 많은 게이머들에게는 엄청난 찬사를 받고 있다.
인텔과 AMD CPU, 최종 선택은
데스크톱 PC를 조립하려 할 경우, AMD와 인텔 사이의 고민은 그 어느 때보다 첨예할 수 밖에 없다. 고려해야 할 요소도 무척 많다. 유명 온라인 유통 업체는 하나 같이 수백 가지의 CPU 선택지를 제공하고 있다. 예산이 한정적인 사용자라면 저가형 CPU 모델에서는 AMD가 확실한 강세를 보이고 있다. 그렇다고 해서 AMD가 하이엔드 제품을 내놓지 않는 것은 아니다. AMD의 라이젠 프로세서는 스레드리퍼(Threadripper)와 마찬가지로 인텔 CPU의 아성에 도전할 수 있는 수작이다.
지난 4월 19일 라이젠 2를 출시하면서 AMD는 이제 인텔의 최상위급 프로세서와 직접적으로 경쟁할 수 있는 칩 개발에 착수했다. 라이젠 2700x는 훨씬 더 저렴하면서도 뛰어난 스톡 쿨러(stock cooler)로 8700k와 직접적으로 경쟁할 예정이다. 현재 데스크톱 PC를 조립중인 독자가 있다면 꼭 한번 고려해 보기를 추천한다.
한편 기존에 인텔 CPU를 사용 중이면서 업그레이드를 고려하는 사용자의 경우 새로운 메인보드와 칩셋, 그리고 소켓으로 바꿔야 한다는 것 때문에 AMD로 건너가는 것이 망설여 질 수 있다. 인텔은 앞으로도 시장에 대한 지배력을 한동안 지속해 나갈 것으로 보이며 미드 레인지 및 하이 엔드 프로세서의 경우 엄청나게 다양한 선택지가 존재한다. 일상적인 컴퓨팅 작업을 위해서는 코어 i5 만으로도 충분할 수도 있다(현재 이 부문에서 최강자는 6코어 i5-8600K이다).
라이젠 5는 비슷하거나 더 적은 가격에 똑같이 6코어를 제공하며 인텔에 도전장을 내밀고 있다. 대부분 사용자가 그래픽 카드에서 아낀 돈으로 미드 레인지 CPU를 선택하는 상황에서는 AMD가 확실히 강점을 가질 수 있을 것이다.
절대 다수의 게이머들이 아직도 멀티코어 프로세서, 그 가운데서도 특히 4코어 이상 프로세서의 이점을 완전히 누리지 못하고 있다. 그러나 최신 미드 레인지 칩을 선택한다면 2개의 엑스트라 코어를 무료로 제공받게 되는 것이며 앞으로 출시될 게임들은 이런 프로세서를 필요로 하게 될 것이다. editor@itworld.co.kr
원문보기
Sep 28, 2018
韓클라우드 군침흘리는 美기업들…'데이터주권' 침탈 우려
美 '해외정보감시법 702조' 상원 통과에 따른 파장
美정보기관 영장없이 외국인 데이터기록 조회가능
미국 정보기관이 영장없이 외국인의 데이터기록을 볼 수 있도록 미국의 법이 개정되면서 아마존과 마이크로소프트(MS), 구글 등 미국기업의 클라우드 서비스를 이용하는 한국기업들의 데이터주권이 침해당할 수 있다는 우려가 제기되고 있다.
지난 1월 미국 상원은 미국 영토밖 외국인의 통신기록을 영장없이 조회할 수 있는 '해외정보감시법(FISA) 702조'를 통과시켰다. 'FISA 702조'는 미 국가안보국(NSA)이 테러 용의자 등 외국인이 국외에서 주고받은 이메일과 이동전화 통화·메시지 등을 영장없이 수집할 수 있도록 하고 있다. 즉, 미국 정보기관이나 수사기관은 한국인의 동의없이 데이터기록을 감청할 수 있는 것이다.
이 법이 시행됨에 따라 아마존이나 구글 등 미국기업들은 미국 정보기관이 요청하면 언제든지 외국인의 데이터기록을 제공해야 한다. 문제는 아마존이나 구글의 클라우드 서비스를 이용하는 국내기업들도 예외가 아니라는 점이다.
최근 정부는 데이터경제 활성화 차원에서 공공부문의 클라우드 시장까지 민간에 개방하기 위해 제도개선을 추진하고 있다. 이 민간기업에 미국 IT기업들도 포함돼 있다. 미국 정보기관이 자국의 IT기업을 압박해 한국기업의 데이터기록을 조회해도 이를 막을 길이 없다. 국내 기업들의 경영활동에 관한 모든 데이터가 고스란히 미국 정보기관에 넘어갈 수 있다는 얘기다.
업계 한 관계자는 "이 법에 따라 미국 국가안보국이나 연방수사국은 구글 등 자국 사업자들에게 외국인이 국외에서 주고받은 이메일과 이동전화 메시지 등에 대한 정보를 요청할 수 있다"면서 "데이터주권 침탈 우려가 큰 만큼 이에 대해 대비해야 한다"고 강조했다.
최근 과학기술정보통신부가 한미 자유무역협정(FTA) 재협상 과정에서 제기될 수 있는 클라우드 관련 정보보호 기준고시에 대한 설문조사를 진행한 것도 이와 무관하지 않다. 정부는 미국이 자국 기업을 위해 한국 클라우드 시장개방을 요구할 것에 대비하기 위해 최근 업계와 간담회도 마련해 의견을 청취했다.
현재 클라우드 시장1위는 아마존으로, 전세계의 33%를 차지하고 있다. MS가 13%로 그 뒤를 잇고 있다. 구글은 6%로 3위를 차지하고 있다. 이 3개사 점유율을 합치면 전체의 약 52%에 달한다. 특히 아마존과 MS는 국내에 데이터센터를 보유하고 있어, 국내 공공시장 진출이 가능한 상황이다.
美정보기관 영장없이 외국인 데이터기록 조회가능
미국 정보기관이 영장없이 외국인의 데이터기록을 볼 수 있도록 미국의 법이 개정되면서 아마존과 마이크로소프트(MS), 구글 등 미국기업의 클라우드 서비스를 이용하는 한국기업들의 데이터주권이 침해당할 수 있다는 우려가 제기되고 있다.
지난 1월 미국 상원은 미국 영토밖 외국인의 통신기록을 영장없이 조회할 수 있는 '해외정보감시법(FISA) 702조'를 통과시켰다. 'FISA 702조'는 미 국가안보국(NSA)이 테러 용의자 등 외국인이 국외에서 주고받은 이메일과 이동전화 통화·메시지 등을 영장없이 수집할 수 있도록 하고 있다. 즉, 미국 정보기관이나 수사기관은 한국인의 동의없이 데이터기록을 감청할 수 있는 것이다.
이 법이 시행됨에 따라 아마존이나 구글 등 미국기업들은 미국 정보기관이 요청하면 언제든지 외국인의 데이터기록을 제공해야 한다. 문제는 아마존이나 구글의 클라우드 서비스를 이용하는 국내기업들도 예외가 아니라는 점이다.
최근 정부는 데이터경제 활성화 차원에서 공공부문의 클라우드 시장까지 민간에 개방하기 위해 제도개선을 추진하고 있다. 이 민간기업에 미국 IT기업들도 포함돼 있다. 미국 정보기관이 자국의 IT기업을 압박해 한국기업의 데이터기록을 조회해도 이를 막을 길이 없다. 국내 기업들의 경영활동에 관한 모든 데이터가 고스란히 미국 정보기관에 넘어갈 수 있다는 얘기다.
업계 한 관계자는 "이 법에 따라 미국 국가안보국이나 연방수사국은 구글 등 자국 사업자들에게 외국인이 국외에서 주고받은 이메일과 이동전화 메시지 등에 대한 정보를 요청할 수 있다"면서 "데이터주권 침탈 우려가 큰 만큼 이에 대해 대비해야 한다"고 강조했다.
최근 과학기술정보통신부가 한미 자유무역협정(FTA) 재협상 과정에서 제기될 수 있는 클라우드 관련 정보보호 기준고시에 대한 설문조사를 진행한 것도 이와 무관하지 않다. 정부는 미국이 자국 기업을 위해 한국 클라우드 시장개방을 요구할 것에 대비하기 위해 최근 업계와 간담회도 마련해 의견을 청취했다.
현재 클라우드 시장1위는 아마존으로, 전세계의 33%를 차지하고 있다. MS가 13%로 그 뒤를 잇고 있다. 구글은 6%로 3위를 차지하고 있다. 이 3개사 점유율을 합치면 전체의 약 52%에 달한다. 특히 아마존과 MS는 국내에 데이터센터를 보유하고 있어, 국내 공공시장 진출이 가능한 상황이다.
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시큐리티의 최고 정보보안 고문인 매트 윌슨은 “젤코바와 타이로스는 잠재적 장점이 무수히 많다. 그러나 데이터를 조작할 줄 알아야 한다. 그렇지 않다면 별로 쓸모가 없다. 게다가 조직 내에 이를 실행하고, 출력을 분석하고, 제공된 정보에 따라 조처를 할 누군가가 있어야 한다. 고급 알고리즘과 세련된 인터페이스는 훌륭하다. 그러나 그것만으로는 충분하지 않다”고 설명했다.
원문보기
아마존이 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시큐리티의 최고 정보보안 고문인 매트 윌슨은 “젤코바와 타이로스는 잠재적 장점이 무수히 많다. 그러나 데이터를 조작할 줄 알아야 한다. 그렇지 않다면 별로 쓸모가 없다. 게다가 조직 내에 이를 실행하고, 출력을 분석하고, 제공된 정보에 따라 조처를 할 누군가가 있어야 한다. 고급 알고리즘과 세련된 인터페이스는 훌륭하다. 그러나 그것만으로는 충분하지 않다”고 설명했다.
---------------------------------------------------------------
클라우드 3사 경쟁 인기기사
->퍼블릭 클라우드 3대 업체 비교 'AWS·애저·구글의 장단점은?'
-> 블로그 | 애저 클라우드의 부상과 AWS에 대한 불안감
-> 아마존, 구글 이어 MS도 가격 인하··· 클라우드 서비스 저가 경쟁 본격화
-> 불붙은 IaaS 가격 인하 전쟁, 얼마나 더 내려갈까?
->"진짜 클라우드 강자는 마이크로소프트다, 오라클은···"
->AWS·MS·구글의 '3사 3색' 클라우드 전략
->‘아마존 vs. 랙스페이스 vs. MS vs. 구글’ 클라우드 최후의 승자는?
---------------------------------------------------------------
클라우드 3사 경쟁 인기기사
->퍼블릭 클라우드 3대 업체 비교 'AWS·애저·구글의 장단점은?'
-> 블로그 | 애저 클라우드의 부상과 AWS에 대한 불안감
-> 아마존, 구글 이어 MS도 가격 인하··· 클라우드 서비스 저가 경쟁 본격화
-> 불붙은 IaaS 가격 인하 전쟁, 얼마나 더 내려갈까?
->"진짜 클라우드 강자는 마이크로소프트다, 오라클은···"
->AWS·MS·구글의 '3사 3색' 클라우드 전략
->‘아마존 vs. 랙스페이스 vs. MS vs. 구글’ 클라우드 최후의 승자는?
---------------------------------------------------------------
원문보기
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
원문보기
다른 많은 기업과 마찬가지로, 데이터 스타트업 세그먼트(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여 가지 서비스를 갖게 됐지만 시스템 장애를 막는 데에만 모든 에너지를 쏟아도 역부족이었기에 그보다 더 건설적이거나 선제적인 어떤 노력도 할 수 없는 상황이었다. 이쯤 되자 한걸음 물러나 생각해 보지 않을 수 없었다. ‘대체 이 상황을 해결하려면 어떻게 해야 하지?’ 결국 인력을 추가해야 한다는 결론이 나왔지만, 그런 식으로 문제를 해결하고 싶지는 않았다”라고 말했다.
그러나 결국 세그먼트는 마이크로서비스 아키텍처가 지속 불가능하다는 결론에 다다랐다. 목적지를 추가할수록 성능 저하가 눈에 띄게 증가했고 이것은 ‘상당히 뚜렷한 경고 신호’였다. 누난은 “한창 마이크로서비스로 인한 광기가 극에 달했을 때 내가 세그먼트에 합류했다. 당시 이미 어떻게 하면 이 문제를 해결할 것인가에 대한 논의가 이루어지고 있었다”라고 말했다.
---------------------------------------------------------------
프로그래밍 인기기사
-> 개발자를 미치게 하는 10가지 프로그래밍 언어
-> 프로그래밍의 미래는? 9가지 예측
-> 21세기 개발자들을 괴롭히는 12가지 윤리적 딜레마
-> 상승가도 달리는 프로그래밍 언어 10선
-> '커피, 보석, 달 등에서 유래한' 프로그래밍 언어 이름 13
-> 개발자 경력에 '가산점' 될 6가지 새로운 언어
-> 프로그래머 생산성을 떨어뜨리는 15가지
-> 개발자들의 8가지 직업병, 혹시 당신도?
---------------------------------------------------------------
단일 구조로 돌아가다프로그래밍 인기기사
-> 개발자를 미치게 하는 10가지 프로그래밍 언어
-> 프로그래밍의 미래는? 9가지 예측
-> 21세기 개발자들을 괴롭히는 12가지 윤리적 딜레마
-> 상승가도 달리는 프로그래밍 언어 10선
-> '커피, 보석, 달 등에서 유래한' 프로그래밍 언어 이름 13
-> 개발자 경력에 '가산점' 될 6가지 새로운 언어
-> 프로그래머 생산성을 떨어뜨리는 15가지
-> 개발자들의 8가지 직업병, 혹시 당신도?
---------------------------------------------------------------
세그먼트 팀은 마이크로서비스를 어떻게 다시 하나의 거대한 시스템으로 재설계할 것인지 방법을 찾아야 했다. 이른바 ‘신(新) 단일구조’로의 이행이었다. 결국 당시 세그먼트가 진행 중이던 ‘센트리퓨즈(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 서비스 등, 클라우드에서 소비하고 있는 모든 서비스들을 꼼꼼히 살펴 보라. 각 서비스를 이용함으로써 발생하는 이점과 비용을 대조해 볼 필요가 있다”고 조언했다.
코헨은 “클라우드 사용 패턴이 예측 가능하며, 애플리케이션 수요가 일관된 조직에서는 이런 것들을 쉽게 계산해 볼 수 있다. 이러한 계산을 끝내고 클라우드 공급자들을 비교하여 선택하면 된다”고 이야기했다.
원문보기
클라우드 컴퓨팅 혁명 초기, 사용한 만큼 돈을 낸다는 개념이 등장해 좀더 효율적인 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를 도입하고 퍼블릭 클라우드로 이전하기 전에 클라우드 이전에 드는 전체 비용을 꼼꼼히, 그리고 찬찬히 분석해 보아야 한다. 이전 시 기대되는 비용 절감 효과는 어느 정도고, 이전 자체에 들어가는 비용은 어느 정도인가를 따져 볼 필요가 있다”고 당부했다.
---------------------------------------------------------------
클라우드 ROI 인기기사
-> 클라우드의 실질적인 비용 이점과 숨은 비용
-> 클라우드·SaaS 업체와의 계약 '조목조목 협상 가이드'
-> ‘이런 항목도 있었네?’ • • • 클라우드 숨은 비용 대비하기
-> 클라우드 컴퓨팅의 실제 비용에 대한 준비
-> 사용량 기반 클라우드 서비스 요금의 진실
---------------------------------------------------------------
클라우드 지출 줄이기, 정확한 비용 파악에서 시작클라우드 ROI 인기기사
-> 클라우드의 실질적인 비용 이점과 숨은 비용
-> 클라우드·SaaS 업체와의 계약 '조목조목 협상 가이드'
-> ‘이런 항목도 있었네?’ • • • 클라우드 숨은 비용 대비하기
-> 클라우드 컴퓨팅의 실제 비용에 대한 준비
-> 사용량 기반 클라우드 서비스 요금의 진실
---------------------------------------------------------------
클라우드 관리의 효율성은 결국 효율적인 현황 모니터링의 문제로 귀결된다. 무엇에 얼마를 지출하고 있는지를 모르면서 지출을 효율적으로 관리할 수는 없기 때문이다.
터보노믹(Turbonomic)의 클라우드 CTO 모르 코헨은 “인스턴스, 로드 밸런싱, SQL, 그리고 NoSQL 서비스 등, 클라우드에서 소비하고 있는 모든 서비스들을 꼼꼼히 살펴 보라. 각 서비스를 이용함으로써 발생하는 이점과 비용을 대조해 볼 필요가 있다”고 조언했다.
코헨은 “클라우드 사용 패턴이 예측 가능하며, 애플리케이션 수요가 일관된 조직에서는 이런 것들을 쉽게 계산해 볼 수 있다. 이러한 계산을 끝내고 클라우드 공급자들을 비교하여 선택하면 된다”고 이야기했다.
원문보기
Aug 17, 2018
마이크로서비스 아키텍처, 복잡성이 문제로다
IT 인프라를 애플리케이션 내 기능에 따라 별도로 쪼개 운영하는 마이크로서비스 아키텍처가 대세로 떠올랐다. 애플리케이션을 보다 빠르게 개발하고 지속적으로 성능을 향상시킬 수 있다는 점에서 각광받고 있다.
하지만, 마이크로서비스 아키텍처를 적용하는 게 생각처럼 쉽지 않다는 목소리도 높다. 빠르고 유연한 애플리케이션을 제공하는 데만 초점을 맞추면 네트워크 정책과 보안 정책이 복잡해 질 수 있기 때문이다.
이에 어떻게 해야 애플리케이션 배포, 업그레이드 속도는 높이고 SW작동의 복잡성을 줄일 수 있을지가 성공적인 마이크로서비스 아키텍처 도입을 위한 핵심 과제로 떠올랐다.
■대세로 떠오른 마이크로서비스 아키텍처 잘 쓰려면
마이크로서비스 아키텍처란 애플리케이션 구성요소를 특정 목적별로 쪼갠 뒤 독립적으로 작동하도록 극소형 서비스로 만들고, 여러 극소 서비스들을 조합해 완성된 애플리케이션으로 조립하는 개발 형태를 말한다.
과거의 서비스지향아키텍처(SOA)보다 추상화 수준을 한차원 더 세분화한 것으로 볼 수 있다.
마이크로서비스 아키텍처 환경에서 개발조직은 각 서비스들을 전담해 지속적 통합과 지속적 개발(CI/CD)을 하게 된다. 솔루션과 IT서비스 개발속도를 높이고, 유지보수에 투입되는 공수를 줄일 수 있어 인기를 모으고 있다.
마이크로서비스 아키텍처는 레고 블록을 조립하듯 여러 서비스를 조합해 하나의 애플리케이션으로 구현
지난 2016년 9월 애플리케이션 개발 플랫폼 업체 라이트벤드가 자바가상머신(JVM) 개발자와 IT 전문가 2천151명을 대상으로 실시한 설문조사에서 응답자 30% 이상이 마이크로서비스를 현업 시스템에서 운영중이라고 답했다. 응답자 20%는 마이크로서비스 현업 시스템 적용을 심각하게 고려중이라고 답변했다. 이미 현업에서 마이크로서비스 아키텍처가 대세로 부상했음을 보여준다.
하지만 운영 환경이 늘어나면서 시스템 운영환경의 복잡성도 커지는 문제가 발생한다. 마이크로서비스 아키텍처의 최대 강점인 개발 생산성을 극대화하는 데 발목을 잡는 일이 생긴다.
이런 문제를 어떻게 해결해야 할까. 애플리케이션 플랫폼 관리 및 보안 솔루션 업체 F5네트웍스는 개발팀 요구에 맞춰 수정할 수 있는 사전 개발된 템플릿을 만들어 대응할 것을 제안한다.
이렇게 하면 사용자가 각 애플리케이션 팀에 어떤 서비스를 제공할 것인지, 어느 정도 수준의 개별 통제력을 부여할 것인지 결정할 수 있다. 또, 운영 환경의 애플리케이션 성능에 대한 가시성과 셀프 확장 옵션도 제공 가능하기 때문에, 애플리케이션 책임자와 네트워크 운영 팀 간 충돌을 없애고 각 기업이 원하는 속도와 규모로 강력한 보안, 성능 및 가용성 서비스의 이점을 더 많은 애플리케이션으로 확장해 준다는 설명이다.
하지만, 마이크로서비스 아키텍처를 적용하는 게 생각처럼 쉽지 않다는 목소리도 높다. 빠르고 유연한 애플리케이션을 제공하는 데만 초점을 맞추면 네트워크 정책과 보안 정책이 복잡해 질 수 있기 때문이다.
이에 어떻게 해야 애플리케이션 배포, 업그레이드 속도는 높이고 SW작동의 복잡성을 줄일 수 있을지가 성공적인 마이크로서비스 아키텍처 도입을 위한 핵심 과제로 떠올랐다.
■대세로 떠오른 마이크로서비스 아키텍처 잘 쓰려면
마이크로서비스 아키텍처란 애플리케이션 구성요소를 특정 목적별로 쪼갠 뒤 독립적으로 작동하도록 극소형 서비스로 만들고, 여러 극소 서비스들을 조합해 완성된 애플리케이션으로 조립하는 개발 형태를 말한다.
과거의 서비스지향아키텍처(SOA)보다 추상화 수준을 한차원 더 세분화한 것으로 볼 수 있다.
마이크로서비스 아키텍처 환경에서 개발조직은 각 서비스들을 전담해 지속적 통합과 지속적 개발(CI/CD)을 하게 된다. 솔루션과 IT서비스 개발속도를 높이고, 유지보수에 투입되는 공수를 줄일 수 있어 인기를 모으고 있다.
지난 2016년 9월 애플리케이션 개발 플랫폼 업체 라이트벤드가 자바가상머신(JVM) 개발자와 IT 전문가 2천151명을 대상으로 실시한 설문조사에서 응답자 30% 이상이 마이크로서비스를 현업 시스템에서 운영중이라고 답했다. 응답자 20%는 마이크로서비스 현업 시스템 적용을 심각하게 고려중이라고 답변했다. 이미 현업에서 마이크로서비스 아키텍처가 대세로 부상했음을 보여준다.
하지만 운영 환경이 늘어나면서 시스템 운영환경의 복잡성도 커지는 문제가 발생한다. 마이크로서비스 아키텍처의 최대 강점인 개발 생산성을 극대화하는 데 발목을 잡는 일이 생긴다.
이런 문제를 어떻게 해결해야 할까. 애플리케이션 플랫폼 관리 및 보안 솔루션 업체 F5네트웍스는 개발팀 요구에 맞춰 수정할 수 있는 사전 개발된 템플릿을 만들어 대응할 것을 제안한다.
이렇게 하면 사용자가 각 애플리케이션 팀에 어떤 서비스를 제공할 것인지, 어느 정도 수준의 개별 통제력을 부여할 것인지 결정할 수 있다. 또, 운영 환경의 애플리케이션 성능에 대한 가시성과 셀프 확장 옵션도 제공 가능하기 때문에, 애플리케이션 책임자와 네트워크 운영 팀 간 충돌을 없애고 각 기업이 원하는 속도와 규모로 강력한 보안, 성능 및 가용성 서비스의 이점을 더 많은 애플리케이션으로 확장해 준다는 설명이다.
Jul 27, 2018
AWS도 ‘프라이빗 클라우드’ 전략 시동?
2018.07.20 10:05:20 / 백지영 jyp@ddaily.co.kr
아마존웹서비스(AWS)가 최근 '스노우볼 엣지(Snowball Edge)'에서 구동 가능한 EC2 인스턴스를 출시해 관련 업계의 이목이 집중되고 있다.
스노우볼 엣지는 기존 온프레미스 데이터센터 혹은 시스템에서 아마존 클라우드 환경으로 이전이 용이하도록 만든 로컬 스토리지 어플라이언스다. AWS 람다와 그린그래스 기능이 탑재돼 있어 데이터 수집 및 처리에 적합하며 최대 100테라바이트(TB)까지 지원한다.
AWS가 스노우볼 엣지에서 구동할 수 있는 컴퓨팅 서비스 EC2 인스턴스를 출시하면서 프라이빗 클라우드로의 전략 확대에 관심이 쏠리고 있다. 그동안 AWS는 퍼블릭 클라우드 서비스 시장의 최강자로 자리매김했지만, 업계에서 강조하는 하이브리드 클라우드 시장에선 소극적인 모습을 보였다.
물론 그동안 VM웨어 등과 업체와 하이브리드 클라우드 서비스 형태인 ‘VM웨어 클라우드 온 AWS(VMware Cloud on AWS)와 같은 서비스도 출시했지만 아직 초기 단계다. AWS가 스노우볼 엣지와 같은 어플라이언스를 기반으로 본격적인 프라이빗 클라이빗 및 하이브리드 클라우드 대응에 나설지가 관전 포인트다.
AWS에 따르면 각각의 스노우볼 엣지는 1.8 GHz의 인텔 제온 D CPU에 탑재돼 총 24개의 가상CPU(vCPU)와 32 GiB 램을 돌릴 수 있다.
이번에 출시된 새로운 스노우볼 엣지(sbe) 인스턴스는 총 6개다 1vCPU와 1GiB 메모리를 제공하는 sb21.small부터 16개 vCPU와 32 GiB 메모리를 제공하는 sbe1.4xlarge까지 다양하다.
AWS가 그동안 큰 주목을 받지 못했던 스노우볼 엣지의 EC2 전용 인스턴스를 출시하면서 예상되는 시나리오는 우선 전통적인 데이터 처리를 스노우볼 엣지에서 하고 이를 AWS이나 타사 클라우드로 이전시키는 역할이다. 비싼 WAN 비용과 네트워크 지연을 줄이고 빅데이터나 IoT 등을 위한 데이터 전처리를 빠르게 해주는 것이다.
또 다른 시나리오는 흩어져 있는 PC와 서버를 원격으로 관리하는 역할이다. AWS의 제프 바 최고 에반젤리스트는 블로그를 통해 “sbe 인스턴스가 온프레미스의 산업용 PC를 중앙에서 관리하기 원하는 IT관리자들의 요구사항을 충족시킬 수 있을 것으로 기대한다”고 설명한 바 있다.
특히 이번 발표가 최근 AWS의 네트워킹 스위치 판매와도 관련이 있을지 주목된다. AWS가 기존 고객에게 저가형 화이트박스 네트워킹 스위치를 판매한다는 소식이 흘러나오면서 지난주 시스코 등 네트워크 장비업체의 주가가 급락했다. AWS이나 구글과 같은 대형 인터넷 서비스 기업은 서버부터 네트워크 장비, 심지어 자체 반도체칩까지 직접 개발하고 있는 상황인만큼, 이번 스노우볼 엣지를 통해 향후 어떠한 전략을 구사할지 주목된다.
아마존웹서비스(AWS)가 최근 '스노우볼 엣지(Snowball Edge)'에서 구동 가능한 EC2 인스턴스를 출시해 관련 업계의 이목이 집중되고 있다.
스노우볼 엣지는 기존 온프레미스 데이터센터 혹은 시스템에서 아마존 클라우드 환경으로 이전이 용이하도록 만든 로컬 스토리지 어플라이언스다. AWS 람다와 그린그래스 기능이 탑재돼 있어 데이터 수집 및 처리에 적합하며 최대 100테라바이트(TB)까지 지원한다.
AWS가 스노우볼 엣지에서 구동할 수 있는 컴퓨팅 서비스 EC2 인스턴스를 출시하면서 프라이빗 클라우드로의 전략 확대에 관심이 쏠리고 있다. 그동안 AWS는 퍼블릭 클라우드 서비스 시장의 최강자로 자리매김했지만, 업계에서 강조하는 하이브리드 클라우드 시장에선 소극적인 모습을 보였다.
물론 그동안 VM웨어 등과 업체와 하이브리드 클라우드 서비스 형태인 ‘VM웨어 클라우드 온 AWS(VMware Cloud on AWS)와 같은 서비스도 출시했지만 아직 초기 단계다. AWS가 스노우볼 엣지와 같은 어플라이언스를 기반으로 본격적인 프라이빗 클라이빗 및 하이브리드 클라우드 대응에 나설지가 관전 포인트다.
AWS에 따르면 각각의 스노우볼 엣지는 1.8 GHz의 인텔 제온 D CPU에 탑재돼 총 24개의 가상CPU(vCPU)와 32 GiB 램을 돌릴 수 있다.
이번에 출시된 새로운 스노우볼 엣지(sbe) 인스턴스는 총 6개다 1vCPU와 1GiB 메모리를 제공하는 sb21.small부터 16개 vCPU와 32 GiB 메모리를 제공하는 sbe1.4xlarge까지 다양하다.
AWS가 그동안 큰 주목을 받지 못했던 스노우볼 엣지의 EC2 전용 인스턴스를 출시하면서 예상되는 시나리오는 우선 전통적인 데이터 처리를 스노우볼 엣지에서 하고 이를 AWS이나 타사 클라우드로 이전시키는 역할이다. 비싼 WAN 비용과 네트워크 지연을 줄이고 빅데이터나 IoT 등을 위한 데이터 전처리를 빠르게 해주는 것이다.
또 다른 시나리오는 흩어져 있는 PC와 서버를 원격으로 관리하는 역할이다. AWS의 제프 바 최고 에반젤리스트는 블로그를 통해 “sbe 인스턴스가 온프레미스의 산업용 PC를 중앙에서 관리하기 원하는 IT관리자들의 요구사항을 충족시킬 수 있을 것으로 기대한다”고 설명한 바 있다.
특히 이번 발표가 최근 AWS의 네트워킹 스위치 판매와도 관련이 있을지 주목된다. AWS가 기존 고객에게 저가형 화이트박스 네트워킹 스위치를 판매한다는 소식이 흘러나오면서 지난주 시스코 등 네트워크 장비업체의 주가가 급락했다. AWS이나 구글과 같은 대형 인터넷 서비스 기업은 서버부터 네트워크 장비, 심지어 자체 반도체칩까지 직접 개발하고 있는 상황인만큼, 이번 스노우볼 엣지를 통해 향후 어떠한 전략을 구사할지 주목된다.
Subscribe to:
Posts (Atom)