클라우드 확장 위해 ‘서비스형 가시성’ 필요
상태바
클라우드 확장 위해 ‘서비스형 가시성’ 필요
  • 데이터넷
  • 승인 2017.07.05 17:13
  • 댓글 0
이 기사를 공유합니다

가시성 확보 못한 클라우드, 눈 감고 관리하는 것…클라우드 확장성 지원 서비스 필요
글: 제프 해리스(Jeff Harris) 익시아 솔루션 마케팅 부문 부사장

네트워크 관리자든, 보안 관리자든 CIO든 네트워크 환경에서 주요 부분을 확인하고 관리할 수 없다면 어떨까? 오늘날 애플리케이션과 워크로드를 퍼블릭 클라우드로 마이그레이션하는 기업은 이런 문제와 씨름하고 있다. 퍼블릭 클라우드 인프라는 해당 인프라 제공업체의 소유물이기 때문에 애플리케이션과 네트워크 데이터에 대한 액세스가 제한되기 마련이다. 엄청난 설치 규모, 리소스 풀 관리, 수요에 따른 지속적 구성 변화 등이 특징인 퍼블릭 클라우드에서는 가시성, 보안성, 규정 준수가 특수한 문제를 일으킨다.

지난 2월 익시아가 대기업의 고위 IT 담당자 220여 명을 대상으로 클라우드 보안에 대한 우려 수준을 조사한 결과, 응답자의 76%가 클라우드 환경의 보안 문제를 ‘매우 우려’ 또는 ‘우려’하고 있었다. 클라우드 도입에서 가장 심각한 보안 문제로 손꼽힌 것은 바로 ‘네트워크 데이터에 대한 통제력 상실(56%)’과 ‘네트워크에 대한 완벽한 가시성 확보(47%)’였다.

이것은 기존의 가시성 아키텍처가 가지는 한계 때문이다. 기존 아키텍처로는 클라우드 워크로드의 적절한 운영 및 보안 유지에 필요한 민첩성과 통찰을 얻을 수 없다. 물리적인 하드웨어와 TAP에 의존하는 온프레미스 솔루션은 기업에 설치된 네트워크가 하룻밤 사이에 극적으로 확대되거나 축소될 가능성이 거의 없다는 사실을 전제로 한다.

또한 가상 설치를 통해 과거 어느 때보다 급격한 변화가 가능해진 반면, 물리적 서버 아키텍처는 근본적인 변화 없이 그대로이다. 그러므로 가상 TAP 및 가상 패킷 브로커를 이용해 하드웨어를 소프트웨어로 전환하면서도 과거와 동일한 가시성 아키텍처를 유지할 수가 있다.

클라우드의 모호한 가시성

퍼블릭 클라우드로 이전하면 상황이 달라진다. 유연성, 민첩성, 탄력성, 신속한 수직/수평 확장성과 같은 퍼블릭 클라우드의 장점은 퍼블릭 클라우드 환경의 가시성 확보, 성능, 보안 모니터링 등에 상당한 난제를 안겨 준다. 애플리케이션 차원에서 워크로드의 동작을 독립적으로 모니터링하고 분석하는 기능이 없고, 퍼블릭 클라우드 업체에서 제공하는 성능 모니터링 도구에는 네트워크 가시성에 꼭 필요한 패킷 데이터가 포함돼 있지 않다.

제공업체의 데이터센터를 들여다 볼 수 있는 특수한 도구가 없는 네트워크 팀과 보안 팀은 눈을 감은 채 일하는 셈이고, 따라서 문제를 진단할 수도 없고 중요한 업무용 애플리케이션에 대한 위협과 공격을 신속하게 해결할 방법도 없다.

그러나 신중한 조치 없이 클라우드 데이터에 접근하는 것은 위험한 일이다. 퍼블릭 클라우드의 장점을 최대한 활용하고 완벽한 가시성으로 서버 워크로드를 파악할 수 있는 분산형 가시성 아키텍처를 얻기 위해서는 다음 두 가지의 중요한 제약을 해결해야 한다.

트래픽 캡처 및 필터링 방법

네트워크 도메인을 완벽하게 통제할 수 있는 기존 데이터센터에서는 물리적인 네트워크 TAP과 네트워크 패킷 브로커(NPB)를 삽입하는 것이 가능하다. 그러나 퍼블릭 클라우드에서는 물리적 장치를 삽입할 방법이 없다. 게다가 네트워크 도메인에 대한 통제력도 제한적이다.

데이터 과다·과소 노출 없이 확장

퍼블릭 클라우드는 피크 수요에 맞춰 확장할 수 있도록 구축돼 있다. 수요에 따라 애플리케이션을 확장하면 새로운 인스턴스가 만들어진다. 그러므로 클라우드 기반의 네트워크 가시성 솔루션이 효과를 발휘하려면 이러한 확장성에 완벽하게 적응할 필요가 있다.

전용의 소프트웨어 에이전트 하나로 패킷을 검사하는 가시성 솔루션의 경우, 확장성에 한계가 있는 것은 물론 단일 장애 지점이 생길 수 있다. 즉 정말로 필요한 것은 물리적 네트워크 가시성 기법을 클라우드 환경에 적용하는 것이 아니라 진정한 클라우드형 가시성 아키텍처이다. 또한 이 아키텍처는 IT 팀에서 복잡한 구성이나 조정 작업을 할 필요 없이 간편하게 설치돼야 한다. 다시 말해 확장 가능한 클라우드 가시성을 얻으려면 VaaS(Visibility-as-a-Service)를 구현해야 한다.

▲ VaaS 다이어그램

클라우드 들여다보기

VaaS 아키텍처를 구축하기 위한 첫 번째 단계는 서비스형 소프트웨어(SaaS) 기반의 웹 인터페이스를 통해 액세스할 수 있는 오케스트레이션 레이어를 만드는 것이다. 이 레이어에서는 클라우드를 지원하는 서비스 공급자 API와 기타 서비스를 사용하는 것이 좋다. 그러면 해당 기업에서는 더 이상 솔루션의 어떤 부분도 설치하거나 관리할 필요가 없게 된다. 이것은 클라우드 스토리지 제공업체에서 파일을 관리하고, 유지보수하고, 저장 공간을 제공하는 것과 비슷한 방식이다.

그런 다음 이 오케스트레이션 레이어를 소스 인스턴스의 클라우드 기반 센서에 연결하고, 다양한 보안·모니터링 도구의 커넥터에 연결한다. 이러한 센서와 커넥터를 가장 효율적으로 확장성 있게 설치하는 방법은 컨테이너에 넣어 해당 기업의 마이크로 서비스 워크로드 및 도구 인스턴스와 동일한 인스턴스에 내장하는 것이다. 이렇게 인스턴스에 직접 내장된 센서는 애플리케이션의 소스에서 가시성과 관련된 트래픽을 필터링한다.

소스 인스턴스에 센서를 내장하는 방법은 효율적일 뿐 아니라, 클라우드 내부의 대역폭 사용량을 최소화하는 것도 큰 장점이다. 관련된 데이터만 도구로 보내기 때문에 비용이 절약된다. 이 센서는 데이터베이스나 웹 같은 클라우드 워크로드를 오케스트레이션 레이어에 알려 준다. 기업은 이러한 메타데이터를 사용해 다양한 워크로드 유형에 적절한 도구를 연결하고, 센서와 그에 맞는 도구로 이뤄진 ‘그룹’을 구성한다.

특정 서비스의 추가 인스턴스가 나타나면 그에 따라 센서도 즉시 추가로 만들어지고, 이 센서는 보안 및 모니터링 도구의 해당 커넥터에 연결된다. 이러한 센서가 그룹에서 온라인 상태가 되면 마찬가지로 확장 가능한 컨테이너 환경에 들어 있는 해당 도구의 커넥터가 자동으로 확장된다. 이렇게 해서 수동 개입 없이도 진정한 클라우드형 탄력성이 완성된다.

수요에 따라 센서와 커넥터를 모두 확장하고 클라우드 지원 서비스를 활용할 수 있는 능력은 VaaS의 핵심이다. 이를 통해 OpEx 기반의 지능적 가시성 사용 모델을 만들고, 기업에서 사용 중인 다른 SaaS 서비스에 맞춰 조정할 수 있다.


댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.