Cloud Computing On Demand

어떤 서비스를 이용할 때 웹 사이트를 꼼꼼히 살펴보는 습관은 무척 중요합니다. 요즘 같은 시대에 웹 사이트는 단순히 마케팅의 역할을 하는 것을 넘어서 기술지원까지 넘어오기 전 고객들이 문제 해결을 할 수 있는 창구로서의 역할 뿐만 아니라 다양한 정보를 식별하고 분류하며 이해하는 주요 창구로의 역할을 추종하고 있기 때문입니다.

마이크로소프트가 클라우드 운영체제(Cloud OS)를 표방하며 강하게 드라이브하고 있는 클라우드 서비스 플랫폼 애져(Azure) 역시 마찬가지입니다. 애져는 굉장히 넓은 개념을 포괄하고 있는 서비스이기 때문에 처음 접하는 사람들은 자칫 어디서부터 시작해야 할지 당황하기 쉽습니다. 애져 공식 웹사이트(http://www.windowsazure.com/)가 게시하고 있는 컨텐츠를 잘 활용하면 어디서 어떤 정보를 먼저 찾기 시작해야 하는지 힌트를 얻을 수 있습니다. 

 
애져 웹사이트에 접속하면 그리 넓지 않은 폭을 차지하고 있는 단아한 화면과 함께 7개의 주요 메뉴가 노출됩니다. 상품 가입을 하고나서 콘솔을 이용하는 방법은 당연히 중요하겠지만 메뉴에서부터 애져가 제공하는 수많은 솔루션들 중 어떤 것이 내게 필요한 솔루션인지를 찾아나가는 방법을 먼저 알아보는 것이 순서일 것 같습니다.

애져 서비스가 제공하는 상품들에 대한 정보와 각 상품들을 어떤 영역에서 어떻게 활용하면 좋을지를 알려주는 메뉴가 첫번째에 위치한 SOLUTIONS 메뉴입니다. 이 메뉴는 하위에 몇 가지 서브 메뉴를 가지고 있는데요, 각 메뉴가 이야기하고자 하는 것이 무엇인지를 알아보도록 하겠습니다. 처음에는 이 메뉴가 왜 이렇게 구성되어 있는지 의아함을 갖고 있다가도 금새 그 방법에 공감하게 되실지도 모르겠습니다

 
상단의 Solutions 메뉴를 선택하면 하위에 4개의 서브 메뉴가 노출됩니다. 글로벌 메뉴와 동일한 이름을 가지고 있는 첫번째 서브 메뉴는 Solutions 입니다. 우측에 전개된 세부 항목을 보면 인프라스트럭쳐, 웹, 모바일 등에서부터 빅데이터, 데이터 매니지먼트 등 다양한 기술 영역에 대한 이름들이 나열되어 있습니다. 이 메뉴의 각 항목들은 해당 항목을 목적으로 하는 경우 마이크로소프트 애져의 어떤 서비스들을 이용할 수 있는지를 그룹 지어놓은 것들입니다.

 

가령 모바일 서비스 혹은 모바일 앱 개발을 하기위해서 도움이 될만한 애져 서비스를 알아보고자 Mobile 을 눌렀을 경우 Mobile Apps 라는 컨텐츠 페이지로 이동을 하게 됩니다. 이곳에서 우리는 애져가 모바일 서비스 개발을 위해 줄 수 있는 특장점과 활용 시나리오, 그리고 그 시나리오를 뒷받침 해주는 애져의 서비스들 목록을 확인해 볼 수 있습니다. 화면에 출력된 컨텐츠를 읽으며 가장 하단까지 내려가면 모바일 앱을 만들기 위해 활용할 수 있는 애져의 다양한 서비스를 확인할 수 있습니다. 

여기에 나열된 애져의 여러 서비스들이 모든 모바일 앱 개발자에게 필요한 것은 절대 아닙니다. 그렇지만 현존하는 많은 모바일 앱들은 이런 서비스를 조합하여 구현이 가능한 것들이며 애져 클라우드 서비스가 이를 제공해 주고 있다는 것을 알려줍니다. 가령 서비스 버스나 노티피케이션 허브는 앱에 기능요소로 내부 컴포넌트간 큐관리나 노티피케이션 발송 기능이 필요한 경우 활용할 수 있을 것입니다.

다시 상단 메뉴로 돌아가서 두번째 서브메뉴인 Discover 를 살펴보겠습니다. 개발자들이 많은 관심을 갖는 경우는 아니겠지만 의사결정권자나 비즈니스, 운영 업무를 하는 사람들이라면 Discover 의 내용들을 유심히 살펴볼 필요가 있습니다. Enterprise IT 와 Application Hosting 은 애져를 이용하여 해당 카테고리의 업무를 클라우드로 전환한 고객들의 이야기와 그들이 얻어낸 메리트를 쉽게 살펴볼 수 있습니다. 고객 사례의 경우 Case Studies 에서도 확인이 가능하지만 애져가 강하게 드라이브 하고 있는 Private Cloud 와 Public Cloud 간의 조화 (Hybrid Cloud) 라던가 비즈니스 어플리케이션을 어떻게 애져를 통해 서비스 하는지 사례를 통해 기업 고객들에게 보다 많은 관심을 이끌어 내고자 함이 느껴집니다.

애져 클라우드 서비스를 선택할 때 가장 많은 질문을 받게되는 부분이 아마존 AWS 와의 성능 차이, 메리트 등일 것입니다. 명실공히 클라우드 플랫폼으로 우뚝 서있는 아마존이기에 그런 비교는 당연한 것이고 애져를 씀에 있어서 명확하게 어떤 점이 강하고 약한지를 알아둘 필요가 있습니다. Discover 에서 그런 주요한 포인트를 찾아내고 애져를 어떻게 쓸 것인지 생각해볼 수 있습니다.

상단 메뉴로 돌아가 서브메뉴의 세번째인 Services 를 눌러보면 아마 대부분의 사람들이 "내가 찾던게 바로 이거야!" 할 거라는 생각이 듭니다. 소위 서버 자원과 관계된 COMPUTE 카테고리, 데이터베이스와 관계된 DATA SERVICES 카테고리, 어플리케이션 혹은 웹 사이트 개발에 도움이 될 수 있는 다양한 서비스들, 마지막으로 로드밸런싱이나 대규모 인프라 운영, 트레픽 관리를 위해 필요한 NETWORK SERVICES 등은 익숙한 개념들이고 용어들일 것입니다.

 
마지막 서브메뉴는 애져를 이용하여 서비스를 구축하고 운영하고 있는 사례들을 모아둔 Case Study 입니다. 이곳은 애져를 만족스럽게 쓰는 고객들이 마이크로소프트 애져를 통해 어떻게 시스템을 구축하고 어떤 서비스를 운영하고 있는지를 쉽게 확인하고 애져 사용에 대한 쐐기를 최종 결정을 할 수 있는 곳이기도 합니다.

기업들의 세계를 가만히 들여다보면 재미있는 습성을 가지고 있습니다. 자신과 동일한 카테고리의 산업군에 속한 주요 기업이 쓰고 있는 서비스나 솔루션이 동일 산업군의 다른 기업에서도 채택할 가능성이 높다는 것이 바로 그것입니다. 애져 웹 사이트 뿐만 아니라 많은 솔루션, 서비스 웹 사이트들이 Case Study 에 가능한 좋은 기업들로부터 컨텐츠를 받아 게시하고 싶은 이유가 여기에 있습니다. 사례를 통해 선택의 당위성을 검증하고 어떤 식으로 다른 기업들이 활용하고 있는지를 가볍게 들어보는 시간을 가져보시기 바랍니다.

마치며...
 
마이크로소프트 애져는 시장에서 괜찮은 반응을 얻고 있습니다. 마이크로소프트 답지않은(?) 기민한 움직임과 다양한 서비스들이 주는 풍요로움, 막강한 개발자 에코시스템을 기반으로 비주얼 스튜디오 등 전통적인 툴과의 매끄러운 연결성도 애져가 점점 사랑받는 이유중 하나입니다. 하지만 제대로 된 이용을 위해서 영어 웹 사이트를 써야만 하고 초기 진입시 아마존 대비 한글화된 컨텐츠를 얻기 쉽지 않다는 것이 진입 장벽이기도 합니다.

애져를 쓰기로 결정했다면 이런 어려움은 일단 감안하고 시작을 해야할 것입니다. 그럼에도 불구하고 애져는 꽤나 매력적인 서비스이고 새로운 무언가를 만들기에 좋은 플랫폼입니다. 저와 같이 하나씩 살펴보면서 애져의 세계로 푹 빠져보시는 건 어떨까요? 저도 그동안 제대로 써보지 않던 애져를 제대로 A to Z 살펴보고 파일럿 프로젝트까지 올려보고자 이 연재를 시작하고자 합니다.

 

클라우드는 그 개념이 등장한지 꽤 오랜 시간이 지났지만 여전히 명쾌한 정의를 내릴 수 있는 사람이 드물다. 그나마 가장 합리적인 정의를 내려보자면 하드웨어, 소프트웨어, 네트워크를 추상화하여(가상화) 다수의 사용자가 함께 사용할 수 있는(멀티 테넌시) 유연한 플랫폼을 일컫는 정도가 될 것 같습니다.

아마존 웹 서비스(AWS)를 비롯하여 우리나라의 SK텔레콤 T cloud biz, KT 의 uCloud 등을 통해 특정 데이터센터 기반의 서비스 인프라에 대한 클라우드 서비스는 많이 대중화가 되었습니다. 그런데 이런 인프라의 가상화가 커버하기 힘든 영역이 있으니 그것은 바로 네트워크 영역입니다. 클라우드 서비스를 사용하거나 제공하는 사람들의 공통적인 고민은 늘 네트워크로 귀결됩니다

 
네트워크는 데이터센터 내부 뿐만이 아니라 공용 인터넷 망에 대한 고민을 함께 해야 하기 때문에 어렵습니다. 아마존, SK텔레콤, KT와 같은 클라우드 사업자들이 유연한 듯 하면서도 결국 Region 이나 서비스 존에 대한 제약이 발생하는 이유는 바로 네트워크 때문이기도 합니다. 클라우드 자원과 네트워크의 이슈는 다른 포스팅에서 한번 이야기 하기로 하구요, 오늘은 보안 관점에서 클라우드 기반 보안 서비스를 이야기 해보고자 합니다.

많은 하드웨어 기반 네트워크 보안 장비를 개발하는 회사들은 최근 클라우드 기반의 서비스를 많이 출시하고 있습니다. 설치된 하드웨어를 정기적인 펌웨어 업데이트로 성능을 개선하고 업데이트 하는 것이 아니라 실시간으로 하드웨어들이 찾아내는 새로운 위험 요소들을 중앙의 분석 서버로 보내어 이슈를 확인하고 문제의 심각도에 따라 해당 하드웨어 벤더의 제품을 사용하는 전세계 유저들에게 바로 배포하는 등의 일이 바로 그것입니다. 

보안 장비 벤더들의 초기 움직임은 자사의 장비를 이용하는 고객들만을 대상으로 서비스를 제공하는 수준이었지만 최근 DDoS 방어 전문 기업인 아르보(Arbor)는 유관 업계들과 함께 클라우드 시그널링 연합(CSC)이라는 것을 구축하고 회원사의 장비를 이용하는 고객사들을 지역 단위의 네트워크로 묶어 효과적으로 DDoS 공격을 방어하고 악의적인 트레픽을 차단하는 솔루션을 내놓았습니다.
 

아르보가 이와 같은 접근 방식을 선택한 것은 DDoS 를 비롯하여 현대의 악의적인 공격들은 공격의 시작점부터 접근 루트 등을 명확하게 한정짓는 것이 힘들기 때문입니다. 공격은 악성 코드에 감염된 수십대에서 수천대, 수만대에 이르는 사용자 단말(PC, 스마트폰 등)에서 시작되고 이들이 서버를 공격하는 루트는 다양할 수 밖에 없습니다. 이런 공격을 서버 바로 앞단에서 하드웨어 장비로 막는 것은 한계가 있습니다. 하드웨어 장비들은 소화할 수 있는 트레픽의 총량이 정해져있고, 이 한계를 넘어 장비가 폭주하는 수준에 이르면 네트워크 전체의 다운을 막기 위해 바이패스(By-Pass)하는 것이 일반적입니다.

이런 현상을 막기 위해서는 공격이 시작되는 지점을 찾아서 서버 근처로 접근하지 못하도록 하는 것이 중요합니다. 이를 위해서는 전세계에 퍼져있는 공격 차단점을 확보하는 것이 중요하며 아르보는 자사와 경쟁 보안 업체들이 가지고 있는 장비를 이용하여 글로벌 풋 프린트(Foot Print)를 확보하는 방법으로 접근을 하고 있습니다. 이런 형태의 클라우드 기반 보안을 가장 진일보시켜 서비스하고 있는 곳은 사실 아카마이입니다.

 
1990년대 후반부터 아카마이가 집중해왔던 사업은 CDN(Content Delivery Network)입니다. 엔드유저에게 보다 가까운 위치에 캐시서버를 배치하여 원본 서버가 가지고 있는 컨텐츠를 보다 빠르게 전달하는 것이 CDN 의 기본 원리입니다. 사용자의 대규모 트레픽을 수용하고 서비스 하기 위해서는 전세계에 가능한 많은 서버를 배치해야 하는데, 아카마이는 CDN 을 위해 전세계에 14만대에 이르는 서버를 배치하고 서비스를 제공하고 있습니다.

아카마이가 최근 강하게 시장에 어필하고 있는 보안 상품인 코나 사이트 디펜더(KSD, Kona Site Defender)는 바로 이런 글로벌 풋 프린트를 이용한 보안 서비스입니다. 아르보와 같은 하드웨어 기반 기업들은 악성 트레픽 차단 지점을 늘리기 위해 제조사들과 연합했다면 아카마이는 단일 플랫폼 위에서 서비스를 제공하기 때문에 사용자 관점에서 더 나은 경험을 제공할 수 있다는 장점이 있습니다.

악의적인 공격을 막는 방법은 정말 다양합니다. 아르보의 CSC나 아카마이 코나 사이트 디펜더는 기본적으로 넓은 커버리지를 이용하여 악성 트레픽의 인입 자체를 막겠다는 컨셉입니다. CSC의 경우 기술적인 스펙을 조금 더 확인해봐야 겠지만, 아카마이의 경우 악성 공격으로 인해 접점의 서버가 다운되더라도 해당 지역에서 동일한 역할을 수행하는 서버가 트레픽을 분산 처리할 수 있기 때문에 가용성이 상당히 높은 것이 장점입니다
 

DDoS 와 같은 대규모 공격을 막는 또다른 방법 중 하나는 악성 트레픽 발생시 이를 처리하는 전담 서버쪽으로 데이터의 흐름을 변경한 뒤 정상적인 트레픽을 필터링해 서버로 전달하는 방법입니다. 이같은 방식의 서비스를 스크러빙(Scrubbing) 서비스라고 하고 시장에서 가장 큰 규모의 마켓을 쥐고 있는 업체가 바로 PROLEXIC 입니다. 아카마이는 최근 PROLEXIC 에 대한 인수를 발표하며 기존 코나 사이트 디펜더에 더하여 클라우드 기반 보안 시장을 수성하겠다는 의지를 표명한바 있습니다.

방화벽이나 DDoS 하드웨어를 이용한 인프라의 보호는 보안의 시작입니다. 하지만 이것 만으로는 소화할 수 없는 이슈들이 많이 있습니다. 아카마이, 아르보는 악성 공격을 근원적으로 차단하는 방법에 대한 가이드를 기업들에게 던지고 있습니다. 제대로 된 악성 공격 방어를 고민하고 있다면 이런 기업들이 제공하는 서비스의 개념을 잘 이해하는 것이 중요할 것 같습니다.

 
- NoPD - 

지난 10월 진행되었던 아마카이 Edge 2013 컨퍼런스에서 참 중요한 발표가 하나 있었다.
그동안 퍼블릭 인터넷 구간에만 한정되었던 네트워크 퍼포먼스의 최적화를
아카마이가 시스코와 함께 기업 네트워크로 확장할 수 있는 얼라이언스를 발표했기 때문.

비싼 MPLS 망이나 가속 / QoS 보장이 되지 않는 WAN 구간을 쓸 것이냐?
아니면 Cisco ASR 장비를 기반으로 아카마이의 글로벌 네트워크를 쓸 것이냐?
글로벌화를 꿈꾸는 기업들과 지사/사무소 네트워크 연결이 이슈인 요즘,
아카마이 네트워크와 시스코 어플라이언스의 조합은
엔터프라이즈들에게는 나쁘지 않은 선택이 될거라는 생각이 드네요!

물론 보안부터 시작해서 넘어야 할 산은 참 많지만
검증된 플랫폼에 살짝~ 승선하는 것은 시행착오를 줄이는 최적의 코스..!

- NoPD - 

인터넷에 연결되어 있는 컴퓨터에 쉽게 접근하기 위해 우리는 DNS 를 사용합니다. DNS 는 사람이 이해할 수 있는 체계로 된 주소를 네트워크가 이해하기 좋은 주소로 바꿔주는 역할을 합니다. 예를들어 www.naver.com 을 DNS 를 통해 조회를 하게 되면 72.247.151.60 과 같은 네트워크 주소를 돌려주게 됩니다. 이 주소를 얻기까지 많은 과정이 있지만 일단 이 포스팅의 주제는 아니므로 넘어가도록 하겠습니다 ^^

 
위의 스크린 샷처럼 1개의 IP 주소가 리턴되는 경우에는 컴퓨터나 웹 브라우저는 고민할 것 없이 해당 IP 주소를 이용해서 자원에 접근하게 될 겁니다. 그런데 만약, 대규모의 사용자 요청을 처리하기 위해서 여러대의 서버와 IP 를 이용하는 경우에는 어떤 주소값을 사용해야 할까요? 가령 아래와 같은 결과가 리턴된다면 컴퓨터나 브라우저는 어떤 IP 주소를 택하게 될까요?

 
 DNS 조회 결과를 활용하는 방법에 대해서도 RFC 표준이 존재하고 있고 IPv6 의 도입등에 따라 표준도 지속적으로 개정이 되고 있습니다. 이 말은, 운영체제에 따라서 DNS 가 A 레코드를 여러개 리턴했을 경우 활용하는 방법이 달라진다는 것을 의미합니다. 가령 윈도우XP 의 경우 굉장히 오래된 운영체제로 리턴된 여러개의 A 레코드 중에서 가장 먼저 리턴된 값을 이용하게 됩니다.

반면 윈도우Vista 라던가 윈도우7과 같은 비교적 근래에 출시된 운영체제들은 개정된 RFC 표준에 맞추어 IP 주소를 선택하게 됩니다. RFC 3484 (http://www.ietf.org/rfc/rfc3484.txt, Default Address Selection for IPv6) 는 IPv6 환경에서 주소를 선택하는 방법에 대한 가이드이지만 많은 운영체제 개발사들은 IPv4 환경에서도 이런 룰을 적용하고 있어서 한 번 읽어볼 필요가 있습니다

 
영어로 가득한 내용이라 울렁울렁 하겠습니다만, 친절한 NoPD 의 요약에 따르면 "프리픽스 부분이 가장 긴 주소를 선택한다" 라고 합니다. 왜 이런 로직을 적용하게 되었는지는 RFC 문서를 직접 읽어보시고 공유해 주시면 감사하겠습니다 ;;; 여튼, 우리가 알아야 할 중요한 내용은 근래의 운영체제들은 이 로직을 대부분 따르고 있다는 사실입니다. 마이크로소프트 테크넷 블로그에 등록된 아래 글이 그 내용을 잘 요약해 주고 있습니다. 역시 친절한 NoPD 의 발췌본을 읽어보시겠습니다 (http://blogs.technet.com/b/networking/archive/2009/04/17/dns-round-robin-and-destination-ip-address-selection.aspx)

 
특정한 도메인에 대하여 5개의 A 레코드가 리턴됐다고 했을때, 사용자의 IP 주소와 비교하여 NetMask 를 몇 비트를 사용해야 하는가가 핵심입니다. 예제는 무척 간단한 상황을 가정해서 쉽게 계산이 됩니다만 실제 상황에서는 조금 더 복잡할 수 있겠죠? IP 주소를 하나 선택하는데 있어서도 영향을 주는 것들이 무척 많습니다. DNS 관련된 이슈를 트러블 슈팅 하실 때 이런 내용도 알고 계시면 도움이 많이 될 것 같아서 공유해 봅니다. 아래의 주소들을 방문해서 보다 자세한 내용을 확인해 보시기 바랍니다.