가상화(Virtualization)는 하나의 CPU에서 동시 실행이 일어나는 것처럼 보이게 하는 확장된 개념이다.
이를 통해 자원 가상화(Resource virtualization)가 이루어진다.
가상화 기술은 컴퓨팅 리소스(하드웨어, 소프트웨어, 네트워크 등)를 여러 개의 논리적인 단위로 분할하고, 각각의 단위에 독립적인 컴퓨팅 환경을 제공한다.
이를 통해 여러 대의 가상 서버나 가상 머신을 하나의 물리적 서버에서 구동할 수 있다.
The role of virtualization in DS
가상화 기술은 모든 분산 컴퓨터 시스템에서 높은 수준의 소프트웨어에 대한 프로그래밍 인터페이스를 제공하는데 사용된다.
이를 위해 가상화는 기존 인터페이스를 확장하거나 대체하여 다른 시스템의 동작을 모방한다.
가상화 기술이 처음 도입된 이유는, 과거 레거시 소프트웨어를 고가의 메인프레임 하드웨어에서 실행할 수 있도록 하는 것이 주목적이었다.
또한, 네트워킹 기술이 보급되면서 시스템 관리자는 다양한 서버 컴퓨터를 유지하고 다양한 애플리케이션에 대한 액세스를 허용해야 했다.
이러한 경우 각 애플리케이션을 자체 가상 머신에서 실행할 수 있으며, 필요한 라이브러리와 운영 체제를 포함시켜 다른 플랫폼이나 기계와의 다양성을 줄일 수 있다.
이를 통해 리소스 사용의 최적화와 관리 용이성을 높일 수 있다.
Architectures of virtual machines
컴퓨터 시스템은 일반적으로 네 가지 유형의 인터페이스를 제공한다.
하드웨어와 소프트웨어 간의 인터페이스로, 모든 프로그램에서 호출할 수 있는 기계어 명령어와, 권한이 있는 프로그램(운영 체제)에서만 호출할 수 있는 기계어 명령어로 구성된다.
이외에도 운영 체제에서 제공하는 시스템 콜과 라이브러리 호출 등의 인터페이스가 있다.
이러한 인터페이스를 가상화하여 다른 시스템의 동작을 모방하는 것이 가상화의 핵심이다.
가상화는 두 가지 방법으로 이루어진다.
하나는 프로세스 가상 머신 방식으로, 추상적인 명령어 집합을 제공하여 응용 프로그램을 실행하는 런타임 시스템이다.
명령어는 Java 런타임 환경에서와 같이 인터프리터로 해석될 수 있으며, Windows 애플리케이션을 UNIX 플랫폼에서 실행할 때와 같이 에뮬레이터로 구현될 수도 있다.
에뮬레이터는 시스템 콜의 동작을 모방해야 하므로 일반적으로 매우 복잡하다.
다른 하나는 가상 머신 모니터(VMM) 방식으로, 원래 하드웨어를 완전히 가리는 층으로 구현된 시스템이다.
이를 통해 완전한 명령어 집합을 인터페이스로 제공하며, 다양한 운영 체제를 동시에 실행할 수 있다.
VMware와 같은 제품이 이러한 방식으로 동작한다.
VMM은 (분산)시스템의 신뢰성과 보안 측면에서 점점 더 중요해지고 있다.
완전한 응용 프로그램 및 환경을 격리할 수 있으므로, 오류 또는 보안 공격으로 인한 장애가 전체 시스템에 영향을 미치지 않도록 할 수 있다.
VMM은 하드웨어와 소프트웨어 간의 커플링을 제거하여 이식성을 크게 향상시킬 수 있다.
Clients: Networked user interfaces
클라이언트 컴퓨터의 주요 역할 중 하나는 원격 서버와 상호작용할 수 있는 수단을 제공하는 것이다.
상호작용하는 방법은 크게 두 가지로 나눌 수 있다.
첫 번째 방법은 각 원격 서비스마다 클라이언트 컴퓨터가 별도의 상대방을 가지고, 그 상대방을 통해 네트워크를 통해 서비스에 연결하는 방법이다.
예를 들어, 사용자의 PDA에서 실행되는 일정표가 원격으로 공유된 일정표와 동기화되어야 할 때, 응용 프로그램 수준의 프로토콜이 동기화를 처리한다.
이 방법은 서비스마다 개별적인 상대방을 유지해야 하므로 관리하기 번거로울 수 있다.
두 번째 방법은 클라이언트 컴퓨터에서 직접적인 원격 서비스 접근을 제공하며 편리한 사용자 인터페이스만 제공하는 방법이다.
이 경우 클라이언트 컴퓨터는 로컬 저장소가 필요하지 않은 터미널로만 사용되며, 응용 프로그램과는 독립적인 솔루션을 제공한다.
이러한 접근 방식은 모든 것을 서버에서 처리하고 저장하는 Thin-client 접근 방식으로 알려져 있다.
이 방식은 인터넷 연결성이 높아지고 휴대용 장치가 점점 더 복잡해지면서 더 많은 관심을 받고 있다.
이 방식은 서버에서 모든 작업을 처리하기 때문에, 클라이언트 컴퓨터에서는 애플리케이션을 실행할 필요가 없다.
이러한 이유로 Thin-client 접근 방식은 서버 관리가 더 간단하고, 클라이언트 컴퓨터의 높은 성능이 필요하지 않아 비용을 절감할 수 있는 장점이 있다.
Client-side SW for distribution transparency
클라이언트 소프트웨어는 UI 뿐만 아니라 로컬 처리 및 통신 기능을 포함한 많은 부분으로 구성되고, 임베디드 클라이언트 소프트웨어도 있다.
서버와 상호 작용하는 주요 임무 중 하나는 사용자가 원격 서버와 상호 작용하는 수단을 제공하는 것이다.
분산 투명성을 위해 클라이언트는 이상적으로 원격 프로세스와 통신 중임을 모르는 것이 좋다.
반면, 서버는 성능 및 정확성 이유로 분산이 종종 덜 투명하다.
엑세스 투명성은 일반적으로 서버가 제공하는 인터페이스 정의에서 클라이언트 스텁을 생성하여 처리된다.
스텁은 서버에서 제공하는 인터페이스와 동일한 인터페이스를 제공하지만, 기계 아키텍처의 차이 및 실제 통신을 숨긴다.
위치, 이동, 재위치 투명성은 클라이언트가 이미 서버에 바인딩되어 있을 때 적용된다.
클라이언트는 서버가 위치를 변경할 때 직접 알림을 받을 수 있으며, 클라이언트의 미들웨어는 사용자에게 서버의 현재 지리적 위치를 숨길 수 있다.
클라이언트 측 솔루션을 통한 복제 투명성은 복제된 서버가 있는 분산 시스템의 예로, 클라이언트 측 소프트웨어는 모든 응답을 투명하게 수집하고 클라이언트 애플리케이션에 단일 응답을 전달할 수 있다.
실패 투명성은 일반적으로 클라이언트 미들웨어를 통해 서버와의 통신 장애를 가리는 것이다.
예를 들어, 클라이언트 미들웨어는 서버에 반복적으로 연결하거나 여러 번 시도한 후 다른 서버를 시도할 수 있도록 구성할 수 있다.
Web 브라우저에서 서버에 연결하지 못하는 경우 이전 세션에서 캐시한 데이터를 반환하는 경우도 있다.
동시성 및 지속성 투명성은 클라이언트 소프트웨어에서는 덜 지원된다.
Servers: General design issues
서버를 구성하는 두 가지 방법은 반복적 서버(Iterative server)와 병행 서버(Concurrent server)이다.
반복적 서버는 서버 자체가 요청을 처리하고 필요한 경우 요청을 보낸 클라이언트에게 응답을 반환한다.
반면 병행 서버는 서버 자체가 요청을 처리하지 않고 다른 스레드나 다른 프로세스로 요청을 전달한 후 즉시 다음 요청을 기다린다.
예를 들어 멀티 스레드 서버 또는 UNIX 시스템에서는 각각의 새로운 요청마다 새로운 프로세스를 생성하는 방법도 있다.
클라이언트는 서비스의 엔드포인트(포트)를 어떻게 알 수 있을까?
전 세계적으로 잘 알려진 서비스에 대한 엔드포인트를 전 세계적으로 할당하거나 요청하는 서버의 네트워크 주소를 찾기 위해 네이밍 서비스를 사용할 수 있다.
이 경우 인터넷 할당 번호 관리 기관(IANA)에 의해 잘 알려진 엔드포인트가 지정되어 있다.
동적으로 요청에 따라 엔드포인트를 할당하는 경우, 예를 들어 시간 서버는 로컬 OS에 의해 동적으로 할당된 엔드포인트를 사용할 수 있다.
이 경우 각 서버를 실행하는 데몬이 있어 현재 각 서비스의 엔드포인트를 추적하며 잘 알려진 엔드포인트에 대한 대기를 처리한다.
서비스의 엔드포인트(포트)를 클라이언트가 어떻게 알게 되는지에 대한 문제는, 각 서비스를 별도의 서버를 통해 구현하는 것이 자원의 낭비가 될 수 있으므로, 특정 서비스와 연관된 각 엔드포인트에 대해 단일 슈퍼서버가 대기하는 것이 더 효율적인 경우가 많다.
이러한 예로는 UNIX에서의 inetd 데몬이 있다.
요청이 들어오면 데몬은 프로세스를 포크하여 요청을 처리한다.
이 프로세스는 처리가 끝난 후 종료된다.
서버를 어떻게 중단시키고 어떻게 중단시킬지에 대한 문제는 사용자가 서버를 중단하여 추가 데이터 전송을 취소하려는 경우 등이 있다.
간단한 해결책으로는, 클라이언트 응용 프로그램을 강제 종료하고 즉시 재시작하여 일어난 일을 숨기는 것이다.
그러나 이 경우 서버는 클라이언트가 충돌했을 것으로 추측하여 이전 연결을 종료할 것이다.
더 나은 방법으로는, 클라이언트와 서버가 out-of-band 데이터를 전송할 수 있는 방법을 개발하는 것이다.
Out-of-band 데이터란, 해당 클라이언트의 다른 데이터보다 먼저 처리되어야 하는 데이터를 말한다.
이를 위해 서버는 클라이언트가 out-of-band 데이터를 보내는 별도의 제어 엔드포인트를 수신 대기 상태로 두고 동시에 정상 데이터가 통과하는 엔드포인트(우선순위가 낮음)를 수신 대기 상태로 둘 수 있다.
또는 클라이언트가 원래 요청을 보내는 연결을 통해 out-of-band 데이터를 보낼 수도 있다.
TCP에서는 긴급 데이터를 전송할 수 있다.
서버의 3가지 상태 관리
서버가 클라이언트의 상태를 유지하는지 여부는 중요한 문제이다.
상태가 없는 서버(stateless server)는 클라이언트의 정보를 유지하지 않으며 클라이언트에게 정보를 알리지 않고 자신의 상태를 변경할 수 있다.
웹 서버는 대표적인 상태가 없는 서버이다.
요청을 처리한 후, 웹 서버는 클라이언트에 대한 정보를 완전히 잊어버린다.
하지만, 많은 상태가 없는 디자인에서는 서버가 실제로 클라이언트 정보를 유지한다.
이러한 정보가 손실되면 서비스 중단이 발생하지 않으며 예를 들어, 웹 서버는 모든 클라이언트 요청을 로그로 남긴다.
로그가 손실되는 경우 최적의 성능이 아닐 수는 있지만 다른 문제는 발생하지 않는다.
소프트 상태를 갖는 상태 없는 서버(stateless server with soft state)는 서버가 클라이언트를 대신하여 상태를 유지하겠다는 약속을 한다.
그러나 제한된 시간 동안만 유지한다.
예를 들어, 서버는 클라이언트에게 업데이트 정보를 제한된 시간 동안 유지하겠다는 약속을 할 수 있다.
시간 제한이 지나면 클라이언트는 업데이트를 위해 서버를 폴링해야 한다.
반면 상태를 가지는 서버(stateful server)는 클라이언트에 대한 지속적인 정보를 유지한다.
예를 들어, 파일 서버는 (클라이언트, 파일) 항목을 포함하는 테이블을 유지한다.
이러한 테이블을 사용하여 서버는 현재 파일 업데이트 권한이 있는 클라이언트를 추적할 수 있다.
이는 클라이언트가 인지하는 읽기 및 쓰기 작업의 성능을 향상시킬 수 있다.
그러나 서버가 충돌하는 경우 테이블을 복구해야 한다.
그렇지 않으면 파일에 대한 최신 업데이트를 처리할 수 없기 때문이다.
따라서 서버가 상태를 유지하면 클라이언트와 서버 간의 상호작용이 더 복잡해질 수 있지만, 일부 응용 프로그램에서는 필수적이다.
서버의 상태 유무에 대한 선택은 서버가 제공하는 서비스에 영향을 미치지 않아야 한다.
어떤 디자인을 사용하더라도 같은 서비스를 제공해야 한다.
예를 들어, 파일을 읽거나 쓰기 전에 열어야 하는 경우 상태를 가지는 서버는 열린 파일 정보를 유지하며, 상태를 가지지 않는 서버는 요청된 파일을 먼저 열고 실제 읽기 또는 쓰기 작업을 수행한 후 파일을 즉시 닫는다.
상태를 가지는 서버는 클라이언트의 이전 접근에 대한 정보를 가지고 있으면 요청에 더 효과적으로 응답할 수 있다.
상태가 없는 서버는 클라이언트가 이전 접근 정보를 추가로 보낼 수 있도록 허용한다.
웹에서 쿠키와 같은 작은 조각의 데이터를 사용하여 클라이언트 특정 정보를 서버에 제공할 수 있다.
첫 번째 클라이언트가 서버에 접근할 때, 서버는 요청된 웹 페이지와 함께 쿠키를 브라우저에 보낸다.
이후 클라이언트가 서버에 접근할 때마다 해당 서버의 쿠키가 요청과 함께 전송된다.
