하이퍼 바이저

하이퍼바이저(hypervisor)는 호스트 컴퓨터에서 다수의 운영 체제(operating system)를 동시에 실행하기 위한 논리적 플랫폼(platform)을 말한다. 가상화 머신 모니터(virtual machine monitor, 줄여서 VMM)라고도 부른다.

 위키 백과에 따르면 하이퍼 바이저란 서버 가상화를 위한 일종의 소프트웨어라고 볼 수 있을 것 같습니다.

이러한 하이퍼 바이저는 두가지로 나뉩니다.

Hyperviseur.png

1. Type1 : native(bare metal) 방식

 : 운영체제가 하드웨어위에 직접 올라가듯이, 하이퍼 바이저가 하드웨어 위에 직접 올라가서 실행됩니다. 이 때 게스트 운영체제는 하이퍼 바이저 바로 위에서 2번째 수준으로 실행됩니다. 

장점

 : Host OS가 존재하지 않아서 리소스를 절약할 수 있습니다.
 : 호스트형 가상화 방식보다 오버헤드가 적다.

단점

 : 자체적인 관리 기능이 없어서, 별도의 관리 콘솔이나 관리 컴퓨터가 필요하다는 단점.

2. Type2 : hosted 방식

: 하이퍼바이저가 일반 프로그램처럼 host OS위에서 실행되며, 게스트 운영체제는 하이퍼 바이저 위에서 3번째 수준으로 실행됩니다. 


서버가상화의 도입 요인

  • 하드웨어 능력의 확대로 한 컴퓨터에서 동시에 작업할 수 있는 양이 증가하였다.
  • 서버를 통합하여 비용이 줄고 관리를 간소화하였다.
  • 서버 저장소나 렌더 저장소 같은 대규모 멀티프로세서와 클러스터 장비를 제어할 필요가 있었다.
  • 하이퍼바이저 아키텍처로 인해 보안성, 신뢰성, 장비의 독립성이 증가하였다.
  • 특정한 운영 체제에 의존적인 응용 프로그램을 다른 하드웨어나 운영 체제 환경에서 실행시킬 필요가 있었다.


서버 가상화

 : 낭비되는 서버 자원을 유연하게 사용하기 위해 탄생
 : 인프라 확장을 매우 쉽고 반환하기도 쉽다.
 : 사용량을 예측할 수 없고 사용량의 증감폭이 큰데, 물리서버로 구축하는 것은 한계가 존재

가상 머신의 정의

: 가상 컴퓨터 시스템을 의미

: 내부에 운영체제와 애플리케이션을 갖춘 완전히 분리된 소프트웨어 컨테이너

: 가상화 대상

: 서버, 스토리지, 네트워크, 앱...

가상 머신의 역할

: 단일 서버에서 하나 이상의 가상 시스템과 다수의 운영체제 및 애플리케이션을 실행할 수 있게됨

: 하이퍼 바이저를 이용

: 하이퍼 바이저 위에서 동작하는 운영체제의 기본단위를 가상머신이라고 부름


주요 속성

: 파티셔닝
: 하나의 물리적 시스템에서 여러 운영 체제 실행
: 가상머신 간에 시스템 리소스 분배

: 분리성
: 하드웨어 수준에서 장애 및 보안 분리성 제공
: 고급 리소스 제어로 성능 유지

: 캡슐화
: 가상 머신의 전체 상태를 파일에 저장
: 파일을 이동하고 복사하는 것처럼 손쉽게 가상 머신을 이동 및 복사

: 하드웨어 독립성
: 원하는 물리적 서버로 원하는 가상 머신을 프로비저닝 또는 마이그레이션

서버 통합

: 필요한 서버 수를 줄이고, 리소스 사용량을 극대화 시킨다
: 서버 가상화를 통해 서버통합을 이루어 효율성을 높이고 비용을 절감

클라우드 컴퓨터와 다른 개념

: 클라우드 컴퓨터는 가상화를 통해 인터넷으로 공유 컴퓨팅 리소스를 온디맨드로 제공하는 것을 의미


가상화의 유형

: 서버 가상화

: 네트워크 가상화

: 물리적 네트워크를 소프트웨어로 완벽하게 재현

: 논리적 네트워킹 디바이스 및 서비스(논리적 포트, 스위치, 라우터, 방화벽, 로드 밸런싱장치, VPN 등) 을 제공

: 물리적 네트워크와 동일한 기능 및 성능을 보장하면서, 가상화 운영 이점과 하드웨어 독립성을 제공

: 데스크톱 가상화


장단점

: CPU 활용, 메모리, 디스크라는 관점에서 가상화의 한계와 현실을 인지해야함.

: 장점

: 시스템을 더 빠르게 재구축할 수 있음

: 오래된 서버를 새것처럼 쓸 수 있음

: 고려할 점

: CPU, 코어, RAM, 디스크 공간의 한계 고려

: SQL서버에 시스템, 데이터, 로그 공간을 어떻게 별도로 할당할지?

: 백업과 복구 고려( 이부분은 레거시 시스템보다 더 유연)

: 즉, 하드웨어, 저장소, 하이퍼바이저 기술에 따라 달라짐.


최근 컨테이너 기술기반의 도커가 주목받고 있습니다. 

기존의 서버 가상화 기술보다 자원관리 측면에서 효율이 더 좋기 때문인데요.

관심있으신 분들을 위해 제가 공부하고 있는 것들을 두서없이 나열해보고자 합니다!


아직 학기 중이라서 나중에 시간이 된다면 체계적으로 올려보도록 하겠습니다.


아래 URL을 따라 학습하였습니다!

1. 도커란?

2. 윈도우에서 도커 설치 가이드


* 아래 사진은 도커에서 Apache 이미지를 검색하고 다운 받는 것을 보여줍니다.


도입

SK Tech에서 교육과정을 이수하는 중 Nodejs 서버를 구축하게 되었는데요.

CRUD에 충실한 간단한 서버이지만, 단순 ec2 서버에서 AWS 아키텍처를 적용했을 떄 

  • 현재 서비스 구성의 제한(limit)이 어떻게 변하고
  • 부하의 허용치가 어떻게 변하고
  • 병목 지점이 있다면 해소되는지

를 측정하기 위해 서버 부하테스트를 진행하기로 했습니다.

테스트 도구

선택의 기준은 다음과 같습니다.

* 제 능력상 사용할 수 있는지

* 빠르게 사용가능한지

* 모니터링이 되는지

부하 테스트기

1. ApacheBench (http://httpd.apache.org/docs/2.2/en/programs/ab.html): 아파치에서 기본적으로 제공하는 기능으로 HTTP 웹서버의 성능을 측정할 때 자주 사용하는 도구이고, 간단하기 떄문에 사용해보도록 하겠습니다.

2. Goad (https://goad.io/): "AWS Lambda 를 활용하여 부하를 분산 생성하여 테스트를 수행하는 오픈 소스 툴로서 Go 언어로 개발 되었습니다. 실제 AWS 의 이점과 AWS Lambda 의 강력함을 잘 활용한 툴 입니다." 라고 설명이 되어 있지만, 명확한 DOCUMENT도 없고 기술지원이 잘 되고 있지 않아서, 제 능력상 배제하였습니다. 

3. JMeter (http://jmeter.apache.org/): 1998 년 부터 시작된 프로젝트로서 오랫동안 기능 강화를 지속해오고 있는 Java 기반의 부하 테스트 툴 입니다. HTTP 뿐만 아니라 다양한 프로토콜을 지원하며, 많은 기능을 가진 GUI 를 제공 합니다. 

모니터링 도구

1. AWS EC2 상에 서버가 있기 때문에 Elastic Search를 사용할 것입니다

Elastic Search : Amazon Elasticsearch Service를 사용하면 손쉽게 Elasticsearch를 배포, 운영 및 확장하여 로그 분석, 전체 텍스트 검색, 애플리케이션 모니터링 등을 수행할 수 있습니다. Amazon Elasticsearch Service는 Elasticsearch의 간편한 API 및 실시간 기능과 더불어 프로덕션 워크로드에 필요한 가용성, 확장성, 보안성을 제공하는 완전 관리형 서비스입니다.

추가 소프트웨어를 설치할 필요 없이 자동으로 EC2 인스턴스를 모니터링합니다.

  • Amazon EC2 인스턴스에 대한 기본 모니터링: 사전 선택한 지표 7개를 5분 간격으로, 그리고 상태 확인 지표 3개를 1분 간격으로 모니터링합니다. 추가 비용은 없습니다.
  • Amazon EC2 인스턴스에 대한 세부 모니터링: 기본 모니터링에서 사용 가능한 모든 지표를 1분 간격으로 확인합니다. 추가 비용이 발생합니다. 인스턴스에 대한 세부 모니터링을 활성화하면 Amazon EC2 AMI ID 및 인스턴스 유형별로 데이터를 집계할 수 있습니다.
Auto Scaling 또는 Elastic Load Balancing을 사용할 경우 기본 모니터링을 선택하든, 세부 모니터링을 선택하든 관계없이 Amazon CloudWatch에서는 Auto Scaling 그룹 및 Elastic Load Balancer에서 집계한 Amazon EC2 인스턴스 지표도 제공합니다. 모니터링 데이터는 AWS 리소스가 종료된 경우에도 2주 동안 보관됩니다. 따라서 관심 있는 이전 이벤트의 지표를 빠르게 다시 살펴볼 수 있습니다. 기본 모니터링은 모든 Amazon EC2 인스턴스에 대해 자동으로 활성화되어 있으므로 AWS Management Console의 Amazon EC2 탭 또는 Amazon CloudWatch 탭을 통하거나 Amazon CloudWatch API를 사용하여 이러한 지표에 액세스할 수 있습니다.

프로 파일링 도구



테스트 단계

load-test-image001

aws에서는 위와 같은 그림의 부하 테스트 과정을 선호 합니다. 과정은 다음과 같습니다.

  1. 최초 ‘WEB’ 을 출력하는 웹 페이지를 대상으로 동시 연결성에 대한 테스트 수행 → 결과 평가→최적화 진행 (Client →Web Server)
  2. 웹 서버를 통해 애플리케이션 서버에서 넘겨 받은 ‘APPLICATION’ 을 출력하는 웹 페이지를 대상으로 동시 연결성에 대한 테스트 수행→ 결과 평가 → 최적화 진행 (Client →Web Server → App Server – w/o Logic)
  3. 데이터베이스에서 최소한의 쿼리 결과를 전달 받아 출력하는 웹 페이지를 대상으로 동시 연결성에 대한 테스트 수행 →결과 평가 → 최적화 진행
    (Client →Web Server → App Server – w/o Logic → Database)
  4. 3-tier 스택 전체를 대상으로 애플리케이션 로직이 적용된 페이지에 동시 연결성에 대한 테스트 수행 → 결과 평가 → 최적화 진행
    (Client → Web Server → App Server – with Logic →Database)
  5. 4번을 기반으로 다양한 시나리오를 지정하여 테스트 수행 → (얻고자 하는 지표 기준에 대해서) 결과 평과 → 최적화 진행


위의 단계에 기반하여 테스트를 진행해보도록 하겠습니다

테스트

환경

ec2 t2.micro 환경에서 테스트 하였습니다.


Family
Type
vCPUs 
Memory (GiB)
Instance Storage (GB) 
EBS-Optimized Available 
Network Performance 
IPv6 Support 
       


General purpose
t2.micro
Free tier eligible
1
1
EBS only
-
Low to Moderate
Yes



<참고 사이트>

http://bcho.tistory.com/787

https://aws.amazon.com/ko/blogs/korea/how-to-loading-test-based-on-aws/



+ Recent posts