19. Networks and Distributed Systems

분산형 시스템은 메모리나 클락을 공유하지 않는 프로세스의 모임이다. 각 노드는 각 로컬 메모리를 갖고 있으며 이 노드는 여러 네트워크 (고속 버스 같은) 를 통해 통신한다. 이는 매우 중요해져 가고 있으며 조직 내 파일에 대한 투명한 접근을 제공하는 것, 대형 클라우드 파일/사진 저장 서비스/대형 데이터셋의 트렌드 분석/과학적 데이터의 병렬 처리 등에 쓰인다. 분산 시스템의 가장 기본적 예는 인터넷일 것이다.

19.1. Advantages of Distributed Systems

분산형 시스템은 통신 네트워크로 느슨하게 상호 연결된 노드의 집합이다. 분산형 시스템 내 특정한 노드의 관점에서 나머지 노드와 그들의 자원은 원격이고, 자신의 자원은 로컬이다. 분산형 시스템 내 노드는 다양한 크기와 기능을 가진다. 작은 마이크로프로세서, 개인 컴퓨터, 대형 범용 컴퓨터 시스템. 이 프로세스들은 프로세서, 사이트, 머신, 호스트 등으로 불릴 수 있다. 대개 기계의 위치를 사이트, 노드를 사이트의 특정한 시스템으로 이야기한다. 노드는 클라이언트-서버 형태로, 피어-피어 형태로, 또는 그 혼합으로 존재할 수 있다. 클라이언트-서버 형태에서는 한 사이트에 한 노드가 있으며, 서버는 다른 노드에 대한 자원을 갖고 클라이언트는 이를 사용한다. 피어-피어 설정에서는 클라이언트나 서버가 없다. 그 대신 노드는 동일한 책임을 공유하고 각자가 클라이언트/서버로 동작한다. 여러 사이트가 다른 사이트에 통신 네트워크로 연결되어 있다면 여러 사이트의 사용자가 정보 교환의 기회를 갖는다. 저수준에서, 시스템간엔 메시지가 패싱된다, 마치 단일 컴퓨터에서 프로세스간 메시지가 패싱되는 것처럼. 메시지가 패싱될 때, 독립된 시스템 내에서 고수준 기능은 분산형 시스템분산형 시스템은 통신 네트워크로 느슨하게 상호 연결된 노드의 집합이다. 분산형 시스템 내 특정한 노드의 관점에서 나머지 노드와 그들의 자원은 원격이고, 자신의 자원은 로컬이다. 분산형 시스템 내 노드는 다양한 크기와 기능을 가진다. 작은 마이크로프로세서, 개인 컴퓨터, 대형 범용 컴퓨터 시스템. 이 프로세스들은 프로세서, 사이트, 머신, 호스트 등으로 불릴 수 있다. 대개 기계의 위치를 사이트, 노드를 사이트의 특정한 시스템으로 이야기한다. 노드는 클라이언트-서버 형태로, 피어-피어 형태로, 또는 그 혼합으로 존재할 수 있다. 클라이언트-서버 형태에서는 한 사이트에 한 노드가 있으며, 서버는 다른 노드에 대한 자원을 갖고 클라이언트는 이를 사용한다. 피어-피어 설정에서는 클라이언트나 서버가 없다. 그 대신 노드는 동일한 책임을 공유하고 각자가 클라이언트/서버로 동작한다. 여러 사이트가 다른 사이트에 통신 네트워크로 연결되어 있다면 여러 사이트의 사용자가 정보 교환의 기회를 갖는다. 저수준에서, 시스템간엔 메시지가 패싱된다, 마치 단일 컴퓨터에서 프로세스간 메시지가 패싱되는 것처럼. 메시지가 패싱될 때, 독립된 시스템 내에서 고수준 기능은 분산형 시스템을 아우르도록 확장된다. 이에는 파일 저장소, 애플리케이션 실행, 원격 프로시저 호출 등이 있다. 분산형 시스템을 만드는 이유는 세 가지가 있다: 자원 공유, 연산 속도 증가, 가용성.

19.1.1. Resource Sharing

여러 다른 사이트 (다른 용량의)가 서로 연결되었을 때는 한 사이트의 사용자가 다른 사이트의 자원을 쓸 수 있다. 분산형 시스템에서 자원 공유는 원격 사이트의 파일을 공유하고, 분산 데이터베이스의 정보를 처리하고, 원격 사이트의 파일을 출력하고, 슈퍼컴퓨터나 그래픽 처리 유닛(GPU)같은 원격 특수 하드웨어 기기를 사용하고, 다른 동작 등을 한다.

19.1.2. Computation Speedup

특정한 계산이 병렬로 동작할 수 있는 부분계산으로 분할될 수 있다면, 분산형 시스템은 이를 여러 사이트에 부분계산을 분배할 수 있다. 이는 계산 가속을 제공한다. 이는 대형 데이터 셋에 대한 대형 프로세싱을 할 때 유용하다. 특정 사이트가 요청으로 과부하되었을 때 이 일부는 부하가 덜 걸린 사이트로 이동되어 부하 분산이 될 수 있다. 이는 분산형 시스템에서 흔하다.

19.1.3. Reliability

분산형 시스템에서 한 사이트가 실패하면 다른 사이트들은 동작을 계속해서 시스템의 신뢰도를 높일 수 있다. 시스템이 복수의 대형 범용 컴퓨터로 이루어졌다면 이 중 하나의 고장이 나머지에 영향을 미치면 안 된다. 하지만, 시스템이 여러 종류의 기기로 이루어졌는데 이 중 하나가 결정적인 기능을 한다면, 하나의 고장이 전체 시스템의 동작을 멈출 수 있다. 이 때 충분한 중복이 있다면 시스템은 노드 일부가 실패해도 동작을 계속할 수 있다. 노드나 사이트의 실패는 시스템에 의해 발견되어야 하며 적절한 동작을 통해 실패로 인해 복구되어야 한다. 시스템은 그 사이트의 서비스를 계속 써서는 안 된다. 실패한 사이트의 기능이 다른 사이트에분산형 시스템에서 한 사이트가 실패하면 다른 사이트들은 동작을 계속해서 시스템의 신뢰도를 높일 수 있다. 시스템이 복수의 대형 범용 컴퓨터로 이루어졌다면 이 중 하나의 고장이 나머지에 영향을 미치면 안 된다. 하지만, 시스템이 여러 종류의 기기로 이루어졌는데 이 중 하나가 결정적인 기능을 한다면, 하나의 고장이 전체 시스템의 동작을 멈출 수 있다. 이 때 충분한 중복이 있다면 시스템은 노드 일부가 실패해도 동작을 계속할 수 있다. 노드나 사이트의 실패는 시스템에 의해 발견되어야 하며 적절한 동작을 통해 실패로 인해 복구되어야 한다. 시스템은 그 사이트의 서비스를 계속 써서는 안 된다. 실패한 사이트의 기능이 다른 사이트에 의해 대체될 수 있다면 시스템은 기능의 이전이 올바르게 일어남을 보장해야 한다. 또한, 고장난 사이트가 복구되면, 메커니즘은 그것을 원래 시스템으로 매끄럽게 통합해야 한다.

19.2. Network Structure

분산형 시스템의 역할과 타입을 완전히 이해하기 위해서는, 이를 연결하는 네트워크를 이해해야 한다. 네트워크에는 두 가지 종류가 있다: 지역 네트워크(LAN)과 광역 네트워크(WAN). 이 둘의 핵심적 차이는 지리적으로 어떻게 분배되었는지이다. 지역 네트워크는 작은 영역에 분산된 호스트로 이루어져 있으며 광역 네트워크는 넓은 영역에 분산된 시스템들로 이루어져 있다. 이 차이는 통신 네트워크의 속도와 신뢰성에 변화를 주고, 분산형 시스템 설계에 나타난다.

19.2.1. Local-Area Networks

LAN은 작은 지리적 영역을 커버하도록 설계되었으며 사무실이나 가정 환경에 일반적으로 사용된다. 시스템 내 모든 사이트는 서로 가까우며 통신 연결은 WAN에 비해 속도가 빠르고 오류율이 낮다. 일반적 LAN은 서로 다른 컴퓨터들, 여러 공유 주변 기기, 다른 네트워크에 대한 접근을 제공하는 여러 라우터 등으로 이루어진다. 이더넷이나 WiFi는 LAN을 만드는 데 있어 주로 쓰인다. 무선 접근 지점은 기기와 LAN을 무선으로 연결하고 자체로는 라우터일 수도 있고 아닐 수도 있다. 이더넷 네트워크는 컴퓨터나 주변 기기들이 모바일이 아닌 비지니스나 조직에서 쓰인다. 이는 다중접근 버스이므로 중앙 제어장치가 없으며 새 호스트가 네트워크에 쉽게 추가될 수 있다. 이 프로토콜은 IEEE 802.3 표준에 의해 정의된다. 이더넷 스피드는 꼬임쌍선 케이블을 쓴다. WiFi는 범용적이고 전통적인 이더넷 네트워크를 보충하거나 그 자체로 존재한다. WiFi는 물리적 케이블 없이 네트워크를 만들 수 있게 해 준다. 각 호스트는 무선 수신기/발신기를 가져 네트워크에 참여한다. 이 프로토콜은 IEEE 802.11 표준에 의해 정의된다. 이는 가정과 비즈니스에서 널리 쓰이며, 도서관, 인터넷 카페, 버스나 비행기 등에서도 쓰인다.

19.2.2. Wide-Area Networks

1968년부터 인터넷(월드 와이드 웹)이 수많은 컴퓨터 시스템으로 이루어진 전세계 네트워크로 세워졌다. WAN의 사이트는 넓은 지역에 물리적으로 분산되어 있다. 연결은 전화선, 전용선, 광 케이블, 마이크로파 연결, 전파, 위성 채널 등으로 이루어진다. 이 통신 연결은 라우터에 의해 제어되며 이 라우터들은 트래픽을 다른 라우터나 네트워크로 향하게 하고, 다른 사이트로 정보를 전송한다. 회사는 보안, 성능, 신뢰성을 높이기 위해 전용 WAN을 쓸 수도 있다. WAN은 대개 LAN보다 느리지만, 주요 도시를 연결하는 기간망 WAN 연결은 광 케이블을 써서 빠를 수도 있다. 속도를 느리게 하는 주요 원인은 로컬 인터넷 서비스 제공자(ISPs)이다. WAN 연결의 속도는 계속해서 빨라지고 있다. WAN과 LAN은 상호 연결되어 있으므로 어디에서 시작되고 어디에서 끝나는지를 이야기하기는 힘들다.

19.3. Communication Structure

내부 동작을 알아보자.

19.3.1. Naming and Name Resolution

네트워크 통신의 첫 번째 이슈는 네트워크 내 시스템의 이름 구분이다. 원격 시스템 내 프로세스는 네트워크 내 유일한 이름인 호스트명, 호스트 내의 프로세스 식별자나 다른 유일한 숫자인 식별자의 쌍으로 구성된다. 사람에게는 이름이 더 쉽지만 컴퓨터에게는 번호가 더 편리하다. 그래서 호스트명을 네트워킹 하드웨어에서 도착 시스템을 묘사하는 호스트 ID해소하는 메커니즘이 있어야 한다. 이는 이름-주소 바인딩과 비슷하다. 두 가지 가능성이 있는데, 첫 번째는 모든 호스트가 네트워크 내 도달 가능한 다른 호스트들의 모든주소와 이름을 담은 데이터 파일을 갖고 있는 경우이다. 이 문제는 네트워크에서 호스트를 추가하거나 더하면 모든 호스트를 업데이트해야 한다는 것이다. 두 번째는 네트워크 내 시스템에 정보를 분산하는 것이다. 이 때 네트워크는 정보를 분배하고 가져올 수 있는 프로토콜을 사용해야 한다. 인터넷은 도메인 명 시스템(DNS)를 쓴다. DNS는 호스트의 명명 구조를 특정하고, 이름-주소 변환도 특정한다. 인터넷의 호스트는 IP 주소로 알려진 이름으로 논리적으로 주소화된다. 일반적으로, 시스템은 호스트명 컴포넌트를 역순으로 조사해 주소를 판정한다. 각 컴포넌트는 이름 서버(시스템 내 프로세스)를 가지며 이는 이름을 받아 그 이름에 대한 이름 서버의 주소를 반환한다. 마지막에, 호스트의 이름 서버가 접속되고 호스트 ID가 반환된다. 이는 비효율적으로 보일 수 있지만, 각 호스트는 접속했던 IP 주소를 캐싱해 속도를 높인다. 물론 이 캐시의 내용은 이름 서버가 이동되거나 주소가 바뀌었을 경우 업데이트되어야 한다. 이 프로토콜은 매우 중요해서 여러 번 최적화되고 보안이 추가되었다. 이 때 1차 서버의 내용물을 중복시키는 백업 이름 서버도 둔다. 도메인명 서비스가 소개되기 전에는 인터넷의 모든 호스트는 각 호스트의 주소와 이름들을 담은 파일의 복제를 담아야 했다. 이 파일에 대한 모든 변경은 한 사이트에 등록되었으며 주기적으로 모든 호스트는 그 사이트로부터 업데이트된 파일을 복사해야 했다. 도메인명 서비스에서는 각 이름서버 사이트가 그 도메인에 대한 호스트 정보를 업데이트할 책임을 진다. 일반적으로, 운영 체제는 프로세스로부터 호스트명, 식별자로 가는 메시지를 받아 그 메시지를 적절한 호스트로 전송할 책임이 있다. 도착지 호스트의 커널은 그 메시지를 식별자로 명명된 프로세스로 전송할 책임이 있다.

19.3.2. Communication Protocols

통신 네트워크를 디자인할 때는 느리고 에러에 취약한 환경에서 통신하는 비동기 동작을 조정하는 복잡성에 대처해야 한다. 또한, 네트워크 내 시스템은 호스트명, 네트워크 내 존재하는 호스트, 연결 수립 등을 정하는 프로토콜의 집합들과 합의하여야 한다. 이 때 설계 문제는 여러 층으로 문제를 분할해 단순화할 수 있다. 시스템 내 각 층은 다른 시스템의 동일한 층과 통신한다. 각 층은 각 프로토콜을 갖고 층간 일어나는 통신은 특정한 프로토콜을 사용한다. 이 프로토콜은 하드웨어나 소프트웨어로 구현될 수 있다. ISO는 네트워크의 여러 층을 묘사할 때 개방형 시스템 상호 연결(OSI) 모델을 정의하였다.

  • 레이어 1: 물리적 레이어. 이는 비트 스트림의 물리적 전송의 기계적/전기적 세부 사항을 다룬다. 통신하는 시스템은 이진 0, 1의 전기적 표현식이 맞아야 하고, 데이터가 전기적 신호의 스트림으로 전송될 때 수신자는 이를 바이너리 데이터로 표현할 수 있어야 한다. 이는 하드웨어나 네트워크 기기로 구현되며 비트 전송을 맡는다.
  • 레이어 2: 데이터 링크 레이어. 이는 프레임, 패킷의 고정 길이 부분을 맡으며, 물리적 레이어에서 발생할 수 있는 오류 감지와 복구를 맡는다. 이는 물리적 주소간 프레임을 전송한다.
  • 레이어 3: 네트워크 레이어. 이는 메시지를 패킷으로 분해해 논리적 주소간 연결을 제공하고 통신 네트워크간 패킷을 라우팅하고 나가는 패킷의 주소를 다루고 들어오는 패킷의 주소를 복호화하고 부하 레벨을 변경하는 적절한 반응에 대한 라우팅 정보를 유지한다. 라우터는 이 층에서 동작한다.
  • 레이어 4: 전송 레이어. 노드간 메시지를 전송하고 패킷 순서를 다루고 혼잡을 막기 위해 흐름을 제어한다.
  • 레이어 5: 세션 레이어. 이는 세션을 구현하고 프로세스간 통신 프로토콜을 맡는다.
  • 레이어 6: 표현 레이어. 네트워크 내 여러 사이트간 포맷의 차이를 해결한다. 문자 전환이나 반이중-전이중 방식간 차이 등.
  • 레이어 7: 애플리케이션 레이어. 사용자간 상호 작용을 맡는다. 파일 전송, 원격 로그인 프로토콜, 전자 메일, 분산형 데이터베이스 스키마 등.

이를 요약하면 데이터의 물리적 흐름을 보이는 협업하는 프로토콜인 OSI 프로토콜 스택이 된다. 논리적으로는 프로토콜 스택 내 레이어는 다른 시스템의 같은 층과 통신하지만, 물리적으로는 애플리케이션 레이어나 그 위에서 메시지가 출발해서 차례차례 더 낮은 레벨로 지나간다. 각 층은 메시지를 수정할 수 있으며 수신측의 같은 레이어에 대한 메시지-헤더 데이터를 포함할 수 있다. 끝내, 메시지는 데이터-네트워크 레이어에 도착하고 복수의 패킷으로 전환된다. 대상 시스템의 데이터-링크 레이어는 이를 받아 메시지는 프로토콜 스택으로 상향 전송된다. 이는 분석되고, 수정되고, 헤더가 벗겨진다. 이는 받는 프로세스의 애플리케이션 레이어에 마지막으로 도착한다. OSI 모델은 최근엔 잘 쓰이지 않으며 요즘은 TCP/IP 모델이다. 이는 OSI 모델보다 더 층수가 적다. 이는 각 레이어에 여러 기능이 복합되어 있다. TCP/IP 애플리케이션 레이어는 인터넷에서 널리 쓰이는 여러 프로토콜을 식별한다. 전송 레이어는 연결할 수 없는 유저 데이터그램 프로토콜(UDP)와 연결 위주의 전송 제어 프로토콜(TCP)을 식별한다. 인터넷 프로토콜(IP)는 IP 데이터그램 또는 패킷을 인터넷을 통해 라우팅한다. TCP/IP 모델은 링크나 물리적 레이어를 공식적으로 식별하진 않는다. 현대 통신 프로토콜의 설계와 구현에서 보안은 중요한 고려 사항이다. 강한 인증과 암호화는 안전한 통신에 필요하다. 강한 인증은 통신의 수신자/발신자를 검증한다. 암호화는 통신의 내용을 도청자로부터 보호한다. 약한 인증과 평문 통신은 여러 이유로 널리 쓰이는데, 많은 경우 성능, 단순성, 효율성이 보안보다 중요할 수도 있기 때문이다. 또한, 존재하는 인프라에 보안을 더하는 것이 어렵고 복잡하기도 하다. 강한 인증은 다단계 핸드셰이크 프로토콜이나 인증 기기를 필요로 해서 프로토콜에 복잡성을 더한다. 이에 현대 CPU는 암호화 가속 명령어를 포함해 암호화를 효율적으로 수행해서 시스템 성능이 저하되지 않도록 한다. 장거리 통신은 양 끝을 인증하고 가상 전용 네트워크 내 패킷 스트림을 암호화해 안전하게 이루어질 수 있다. LAN 통신은 대부분 사이트에서 암호화되지 않으나, NFSv4같은 프로토콜은 LAN 보안에서도 강한 인증과 암호화를 제공한다.

19.3.3. TCP/IP Example

TCP/IP 프로토콜 스택에서 이름 해결을 알아보자. TCP/IP에서 각 호스트는 이름과 연관된 IP 주소를 갖고 있다. 이 문자열은 반드시 유일해야 하고 이름공간이 관리되고 분리될 수 있어야 한다. 이 이름을 계층적이고, 호스트명과 호스트가 관련된 조직을 묘사한다. 호스트명은 네트워크명과 호스트명으로 분리된다. 이 비율은 네트워크 크기에 따라 다르다. 인터넷 관리자가 네트워크 번호를 할당하면 그 번호의 사이트는 호스트 ID를 할당할 수 있다. 전송 시스템은 라우팅 테이블을 체크해 라우터를 위치시켜 프레임을 전송한다. 이는 시스템 관리자에 의해 직접 관리되거나 경계 게이트웨이 프로토콜(BGP)같은 여러 라우틸 프로토콜 스택에서 이름 해결을 알아보자. TCP/IP에서 각 호스트는 이름과 연관된 IP 주소를 갖고 있다. 이 문자열은 반드시 유일해야 하고 이름공간이 관리되고 분리될 수 있어야 한다. 이 이름을 계층적이고, 호스트명과 호스트가 관련된 조직을 묘사한다. 호스트명은 네트워크명과 호스트명으로 분리된다. 이 비율은 네트워크 크기에 따라 다르다. 인터넷 관리자가 네트워크 번호를 할당하면 그 번호의 사이트는 호스트 ID를 할당할 수 있다. 전송 시스템은 라우팅 테이블을 체크해 라우터를 위치시켜 프레임을 전송한다. 이는 시스템 관리자에 의해 직접 관리되거나 경계 게이트웨이 프로토콜(BGP)같은 여러 라우팅 프로토콜에 의해 이주된다. 라우터는 호스트 ID의 네트워크 파트를 사용해 전송 네트워크로부터 패킷을 받아 수신 네트워크로 이동시킨다. 이는 완전 메시지일 수도 있고 메시지의 일부분일 수 있다. 이 경우 메시지가 재구성되기 위해서는 더 많은 패킷이 필요하다. 네트워크 내에서 패킷이 어떻게 발신자에서 수신자로 이동하는가? 각 이더넷 기기는 매체 접근 제어(MAC) 주소라는 유일한 바이트 번호를 갖고 있으며 이것이 주소에 할당된다. LAN 내의 두 기기는 이 번호로 상호 통신한다. 시스템이 데이터를 다른 시스템으로 전송할 필요가 있다면 네트워킹 소프트웨어는 도착 시스템의 IP 주소를 담은 주소 결정 프로토콜(ARP)를 생성한다. 이는 이더넷 네트워크 내 다른 모든 시스템으로 방송된다. 이는 특별한 네트워크 주소를 사용해 모든 호스트가 패킷을 받아 처리해야 한다는 신호를 보낸다. 이는 다른 네트워크간 라우터로 재전송되진 않기 때문에 로컬 네트워크 내 시스템들만이 이를 받는다. ARP 요청과 IP 주소가 맞는 시스템만이 MAC 주소에 반응해 쿼리를 발신한 시스템으로 재전송한다. 시스템에 대한 접근이 주어진 시간 내 필요해지지 않는다면 엔트리는 캐시로부터 제거된다. 이 경우 네트워크 내 호스트는 잊혀진다. 이더넷 기기가 호스트 ID와 주소를 받고 나면 통신이 시작된다. 프로세스는 통신할 호스트의 이름을 특정할 수 있다. 네트워킹 소프트웨어는 그 이름을 받아 DNS 룩업이나 전송이 저장될 수 있는 hosts의 엔트리 등을 통해 대상의 IP 주소를 판정한다. 메시지는 애플리케이션 레이어로부터 전송되어 소프트웨어 레이어를 타고 하드웨어 레이어까지 간다. 하드웨어 레이어에서 패킷은 시작 부분에 이더넷 주소를 담고 끝부분에는 패킷 손상을 감지하는 체크섬을 포함한다. 이는 이더넷 기기에 의해 네트워크에 위치한다. 퍀시의 데이터 부분은 원본 메시지의 데이터 일부나 전부를 담을 수 있으나 메시지를 담은 상위 레벨 헤더를 담을 수 있다. 즉, 원본 메시지의 모든 파트는 발신지로부터 수신지로 보내져야 하고, 데이터링크 레이어 위의 모든 헤더는 이더넷 패킷 데이터에 포함된다. 발신지와 도착지가 같은 로컬 네트워크에 있으면 시스템은 ARP 캐시를 써서 호스트의 이더넷 주소를 찾고 와이어에 패킷을 위치시킬 수 있다. 이후 수신 이더넷 기기는 패킷의 주소를 받아 패킷을 읽어 프로토콜 스택에 보낸다. 네트워크 내 도착 시스템이 발신 시스템과 다르면 발신 시스템은 네트워크 내 적절한 라우터를 찾아 패킷을 그 쪽으로 보낸다. 이는 ARP 캐시를 체크해 도착지의 이더넷 넘버를 찾고 패킷을 그 호스트에 보낸다. 이 모든 전송 중에서, 데이터 연결 레이어 헤더는 다음 라우터의 이더넷 주소가 사용됨에 따라 바뀔 수 있으나, 패킷의 다른 헤더는 패킷이 수신되고 프로토콜 스택에 의해 처리되어 수신 프로세스의 커널에 전송될 때까지 유지된다.

19.3.4. Transport Protocols UDP and TCP

특정한 IP 주소 호스트가 패킷을 받으면 이는 올바른 대기 프로세스로 전달되어야 한다. 전송 프로토콜 TCP와 UDP는 포트 번호를 이용해 발신/수신 프로세스를 식별한다. 단일 IP 주소를 가진 호스트는 각 서버 프로세스가 다른 포트 번호를 가진다면 여러 서버 프로세스를 구동시키고 패킷을 대기할 수 있다. 널리 알려진 포트 번호는 FTP(21), SSH(22), SMTP(25), HTTP(80) 등이다. 전송 레이어는 네트워크 패킷을 동작 중인 프로세스에 연결하는 것 이상을 한다. 이는 네트워크 패킷 스트림에 신뢰성을 더할 수 있다.

19.3.4.1. User Datagram Protocol

전송 프로토콜 UDP는 IP에 포트 번호만 추가했을 뿐이다. UDP 헤더는 발신 포트 번호, 수신 포트 번호, 길이, 체크섬만을 포함한다. 패킷은 UDP를 통해 도착지에 빨리 도착할 수 있다. 하지만, 네트워크 스택 내 저층에 도착한다는 보장이 없기 때문에 패킷은 유실될 수 있다. 패킷은 발신자에 고장난 채로 도착할 수 있다. 이를 감지해 제어하는 것은 애플리케이션의 몫이다. 클라이언트는 서버에 정보에 대한 요청을 보낸다. 서버는 4개의 데이터그램이나 패킷으로 클라이언트에 반응한다. 이 때 한 패킷이 유실되면 클라이언트는 3개의 패킷으로 작업을 하거나 애플리케이션에 프로그래밍된 로직으로 유실된 패킷을 요청한다. 즉, 네트워크에 의해 신뢰도가 보장되기 원한다면 다른 전송 프로토콜을 써야 한다.

19.3.4.2. Transmission Control Protocol

TCP는 신뢰성 있고 연결 지향적 전송 프로토콜이다. 포트 번호를 특정해 다른 호스트간 수신/발신 프로세스를 특정하는 것 이외에도, TCP는 호스트의 발신 프로세스가 다른 호스트의 수신 프로세스에 바이트 스트림을 순서대로, 방해 없이 전송할 수 있게 하는 추상화를 제공한다. 이는 다음과 같이 이루어진다.

  • 호스트가 패킷을 전송할 때 수신자는 확인 패킷(ACK)를 보내 패킷을 받았음을 발신자에 알려야 한다. 타이머가 지나기 전 ACK를 받지 못하면 발신자는 패킷을 재전송한다.
  • TCP는 모든 패킷의 TCP 헤더에 순차 번호를 도입한다. 이는 수신자에 프로세스에 데이터를 보내기 전 패킷을 순서화할 수 있게 하고 바이트 스트림으로부터 패킷이 유실되었는지를 알게 한다.
  • TCP 연결은 발신자와 수신자간 제어 패킷의 연결로 시작되며 제어 패킷이 연결을 끊어야 할 때 적절하게 닫힌다. 이 제어 패킷은 발신자와 수신자가 상태를 세팅하고 제거할 수 있게 한다.

TCP 명세에서 모든 패킷에 ACK를 보낼 필요는 없고 패킷 시리즈에 대한 ACK를 보낼 수도 있다. TCP는 패킷의 흐름을 제어 흐름혼잡 제어로 조절할 수 있다. 제어 흐름은 발신자가 수신자의 용량을 초과하지 않게 한다. 혼잡 제어는 발신자와 수신자간 네트워크의 상태를 근사한다. 라우터가 패킷으로 과부하되면 이는 패킷을 떨어트린다. 이는 ACK 타임아웃을 야기해 네트워크에 패킷이 포화되게 한다. 이를 막기 위해 발신자는 누락된 패킷에 대한 연결을 모니터링해 얼마나 많은 패킷이 확인되지 않았는지를 체크한다. 너무 많은 패킷이 누락되면 발신자는 보내는 속도를 감소시킨다. TCP같은 신뢰성 있는 전송 프로토콜을 사용함으로써 분산 시스템은 별도 로직 없이 순서를 벗어나거나 유실된 패킷이 없게 한다. TCP는 UDP보다 느리다.

19.4. Network and Distributed Operating Systems

네트워크 운영 체제는 분산형 운영 체제에 비해 구현하기 쉬우나 접근하고 사용하기는 어렵다.

19.4.1. Network Operating Systems

네트워크 운영 체제는 사용자가 적절한 원격 기기에 로그인하거나 원격 기기로부터 각자 기기에 데이터를 전송함으로써 원격 소스에 접근할 수 있는 환경을 제공한다. 모든 범용 운영 체제와 임베디드 운영 체제는 네트워크 운영 체제이다.

19.4.1.1. Remote Login

네트워크 운영 체제의 중요 기능은 원격 로그인이다. 인터넷은 이를 위해 ssh를 제공한다.

19.4.1.2. Remote File Transfer

네트워크 운영 체제의 또 다른 핵심 기능은 기기간 원격 파일 전송이다. 이 때 각 컴퓨터는 각자의 파일 시스템을 유지한다. 이 때 통신은 단방향이며 각각이다. 인터넷은 sftp나 ftp를 통해 이 전송 메커니즘을 제공한다.

19.4.1.3. Cloud Storage

클라우드 저장소 애플리케이션은 사용자들이 FTP처럼 파일을 전송할 수 있도록 한다. 사용자들은 클라우드 서버에 파일을 업로드할 수 있고 로컬 컴퓨터에 다운로드할 수 있고 웹 링크나 다른 공유 메커니즘을 통해 다른 사용자들과 파일을 공유할 수 있다. 중요한 점은 이들이 사용자에게 패러다임을 바꾸도록 요구했다는 점이다. SSH 사용자의 세션에 대한 이해 등. 이를 해결하기 위해 분산형 운영 체제가 설계되었다.

19.4.2. Distributed Operating Systems

분산형 운영 체제에서 사용자는 로컬 자원에 접근하는 것과 같은 방식으로 원격 자원에 접근한다. 한 사이트에서 다른 사이트로의 데이터와 프로세스 이주는 분산형 운영 체제의 제어 아래에서 이루어진다. 시스템의 목표에 따라, 이는 데이터 이주, 계산 이주, 프로세스 이주, 이의 혼합 등을 할 수도 있다.

19.4.2.1. Data Migration

사이트 A의 접속자가 B의 파일을 접근하려 할 때 데이터 이주의 한 가지 접근법은 전체 파일을 사이트 A로 이동시키는 것이다. 파일이 수정되거나 한 채 파일 접근이 끝나면 파일의 복제가 B로 재전송된다. 이는 자동 FTP로 볼 수 있다. 그러나 너무 비효율적이다. 다른 접근법은 파일에서 필요한 부분만 사이트 A로 보내는 것이다. 다른 부분이 필요해지면 다른 전송이 수행된다. 사용자가 파일에 대한 접근을 더 이상 원치 않으면 수정된 부분이 B로 재전송된다. 많은 분산형 운영 체제는 이를 채택한다. 어쨌든 데이터 이주는 한 사이트에서 다른 사이트로의 전송 이상을 한다. 시스템은 두 사이트가 호환이 안 되면 데이터 번역도 해야 한다.

19.4.2.2. Computation Migration

어떤 환경에서는 시스템간 연산을 전송할 수 있는 연산 이주를 필요로 한다. 데이터를 전송하는 데 걸리는 시간이 원격 명령어를 실행하는 시간보다 더 길다면 원격 명령어를 써야 할 것이다. 프로세스 P가 사이트 A의 파일에 접근하려 할 때는 RPC를 보내 사이트 A에서 결과를 받고 반환받을 수도 있고 P가 사이트 A에 메시지를 보내서 사이트 A에서 생성된 프로세스가 작업을 완수하고 이 결과를 메시지로 다시 보낼 수도 있다.

19.4.2.3. Process Migration

연산 이주의 논리적 확장은 프로세스 이주이다. 프로세스가 실행될 때, 항상 그것이 시작된 사이트에서 실행되는 것은 아니다. 전체 프로세스나 그 일부분은 다른 사이트에서 실행될 수 있다. 이는 다음의 이유들 때문일 수 있다.

  • 부하 분산
  • 계산 가속
  • 하드웨어 선호
  • 소프트웨어 선호
  • 데이터 접근

컴퓨터 네트워크에서 프로세스를 이동하기 위해서는 두 가지의 상호보완적인 기법을 쓴다. 첫째로, 컴퓨터는 프로세스가 클라이언트로부터 이주한다는 사실을 숨기려 한다. 그러면 클라이언트는 이주를 위해 프로그램을 명시적으로 코드할 필요가 없다. 이는 동일성을 가진 시스템간 부하 분산과 계산 가속을 위해 주로 쓰인다. 프로그램을 원격으로 실행하기 위한 사용자 입력이 필요없기 때문이다. 다른 방법은 사용자에게 프로세스가 이주해야 할지를 특정하게 하는 것이다. 이는 프로세스가 하드웨어나 소프트웨어 선호를 위해 이동해야 할 때 차용된다. 월드 와이드 웹은 분산형 컴퓨팅 환경의 많은 부분을 갖고 있다. 이는 데이터 이주와 계산 이주, 프로세스 이주를 모두 제공한다. 네트워크 운영 체제는 이 특성을 모두 제공하나 분산형 운영 체제는 이를 흠결 없이 쉽게 접근할 수 있게 한다.

19.5. Design Issues in Distributed Systems

분산형 시스템의 설계자는 여러 설계 난점을 겪어야 한다. 시스템은 실패에 견딜 수 있을 정도로 강건해야 한다. 시스템 사용자는 파일 위치나 사용자 이동을 투명히 볼 수 있어야 한다. 시스템은 더 많은 계산량, 더 많은 저장소, 더 많은 사용자에 대해 확장 가능해야 한다. 이를 다뤄보자.

19.5.1. Robustness

분산형 시스템은 하드웨어 실패의 다양한 형태를 맞닥뜨릴 수 있다. 링크, 호스트, 사이트, 메시지 유실이 흔한 형태이다. 시스템이 강건하기 위해서는 이 실패들을 감지해 시스템을 재설정해 연산이 지속될 수 있도록 하고 실패가 고쳐지면 이를 복구해야 한다. 시스템은 고장 방지여야 하며 특정한 실패의 수준에 대응해 평상시대로 기능할 수 있어야 한다. 고장 방지의 정도는 분산형 시스템의 설계와 특정한 실패에 의존한다. 고장 방지가 더 될수록 좋다. 이에는 통신 실패, 기계 고장, 저장소 크래시, 저장소 미디어 쇠퇴 모두 대처되어야 한다. 고장 방지 시스템은 실패가 일어났을 때 성능이 저하된 채로라도 계속 동작해야 한다. 이 성능 저하는 성능, 기능 모두를 의미할 수도 있다. 그러나 이를 야기한 실패에 비례해야 한다. 한 컴포넌트가 중단된다고 망가지는 시스템은 고장 방지가 아니다. 이는 어렵고, 구현하기 비용이 많이 든다. 네트워크 레이어에서는 여러 중복 통신 경로나 라우터/스위치같은 네트워크 기기가 통신 고장을 막기 위해 필요하다. 저장소 실패는 운영 체제, 애플리케이션, 데이터의 손실을 불러올 수 있으므로 실패시 자동적으로 대체되는 하드웨어 컴포넌트를 포함해야 한다. RAID 시스템은 하나 이상의 저장소 기기가 실패하더라도 데이터에 대한 연속된 접근이 가능케 한다.

19.5.1.1. Failure Detection

공유 메모리가 없는 환경에서는 링크 실패, 사이트 실패, 호스트 실패, 메시지 손실을 구별할 수 없다. 이 중 무언가가 발생했다는 것만 알 수 있을 뿐이다. 실패가 감지되면 적절한 동작이 취해져야 한다. 어떤 동작이 적절한지는 애플리케이션에 따라 다르다. 연결과 사이트 실패를 감지하기 위해서는 하트비트 과정을 쓴다. 이는 사이트 A와 B간에 주기적으로 메시지를 보내서 상태를 확인하는 방법이다. 한 메시지에 대한 반응이 없을 때 다른 메시지를 다른 루트로 보내서 응답하면 첫 번째 루트가 고장난 것이다.

19.5.1.2. Reconfiguration

A가 실패를 감지했다면 시스템이 재설정하고 동작을 평소대로 할 수 있는 프로시져를 시작해야 한다. A에서 B로의 직접 연결이 실패했다면 정보는 시스템 내 모든 사이트로 전달되어 루팅 테이블이 그에 따라 업데이트되어야 한다. 시스템이 사이트가 고장났다고 믿게 된다면 시스템 내 모든 사이트가 이를 공지받고 고장난 사이트의 서비스를 쓰지 않도록 해야 한다. 고장난 사이트가 어떤 활동의 중심 제어자라면 새 제어자를 뽑아야 한다. 사이트가 실제로 고장난 게 아니라면 두 사이트가 제어자가 되는 좋지 않은 경우가 될 수도 있는데 네트워크가 분할되어 있으면 이들이 충돌날 수도 있다.

19.5.1.3. Recovery from Failure

실패한 링크나 사이트가 복구되면 이는 매끄럽게 시스템에 통합되어야 한다. A와 B 사이의 링크가 실패하면, 이것이 복구되면 A와 B 모두 공지를 받아야 한다. 이는 하트비트 과정을 반복해서 이루어질 수 있다. 사이트 B가 고장났다가 복구되면 모든 사이트에 이를 공지해야 한다. 사이트 B는 다른 사이트로부터 그 로컬 테이블을 업데이트했다는 정보를 받아야 할 수 있다. 사이트가 고장난 게 아니라 접속 불가능할 뿐이더라도 이 정보를 받을 필요는 있다.

19.5.2. Transparency

분산형 시스템 내의 복수의 프로세서와 저장소 기기를 사용자들에게 투명하게 만드는 것은 많은 설계자들에게 핵심 난관이다. 이상적으로 분산형 시스템은 사용자들에게 전통적인 중앙 집중적 시스템처럼 보여야 한다. 투명한 분산형 시스템의 사용자 인터페이스는 로컬과 리모트 자원을 구분하지 말아야 한다. 즉, 사용자는 원격 자원을 로컬처럼 접근할 수 있어야 하며 분산형 시스템은 자원을 배치하고 적절한 상호작용에 배치할 수 있어야 한다. 투명성의 다른 관점은 사용자 이동이다. 사용자가 특정 기기에 로그인하는 것을 강제하는 것이 아니라 시스템 내 다른 기기로 이주할 수 있도록 하는 것은 편리할 것이다. 투명 분산 시스템은 사용자 이동을 사용자 환경을 로그인하는 곳으로 이주함으로써 이를 이룬다. LDAP같은 프로토콜은 로컬, 원격, 모바일 유저에 대한 인증 시스템을 제공한다. 인증이 끝나면 데스트톱 가상화 같은 설비가 그들의 원격 설비에서 데스크탑 세션을 볼 수 있게 한다.

19.5.3. Scalability

다른 이슈는 확장성으로 시스템이 서비스 부하 증가에 대처할 수 있게 하는 능력이다. 시스템은 자원이 제한적이므로 부하가 커지면 포화될 수 있다. 이는 상대적인 특성이지만 정확히 측정될 수 있다. 확장 가능한 시스템은 아닌 것에 비해 부하 증가에 대해 유연하게 대처한다. 성능 저하는 적절하게 일어난다. 자원 포화는 더 늦게 일어난다. 완벽한 설계로도 부하가 너무 커지면 감당할 수 없다. 자원 추가가 이 문제를 풀 수는 있지만, 자원에 대한 부하를 추가할 수도 있고 시스템을 재설계해야 할 수도 있다. 분산형 시스템에서는 매끄러운 상방향 확장은 매우 중요하다. 즉, 확장 가능한 설계는 많은 서비스 부하를 견딜 수 있어야 하고, 사용자 커뮤니티의 증가, 추가 자원의 간단한 통합을 할 수 있어야 한다. 확장성은 고장 대처에도 관계가 있다. 과부하된 컴포넌트는 마비되어 고장날 수 있다. 고장난 컴포넌트에서 부하를 백업으로 이동시키는 것은 나머지를 포화시킬 수 있다. 정점 부하를 다루려면 여유 자원을 가지는 것이 필수적이다. 즉, 분산 시스템에서 복수의 자원은 시스템에 고장 대처와 확장성을 증가시켜 주는 내재적 장점이 있다. 그러나, 부적절한 설계는 이 잠재력을 흐릴 수 있다. 설계에 대한 고장 대처와 확장성 고려는 제어와 데이터의 분배에 대한 설계를 나타낸다. 확장성은 효율적인 저장소와도 관계가 있다. 예를 들어, 많은 클라우드 저장소는 저장소를 아끼기 위해 압축중복 제거를 수행한다. 이는 모두 파일 레벨이나 블록 레벨에서 쓰이며 같이 쓰일 수 있다. 이는 분산형 시스템에서는 사용자가 명령어를 따로 할 필요 없이 자동적으로 이뤄진다.

19.6. Distributed File Systems

분산형 컴퓨팅의 중요한 용례는 분산형 파일 시스템(DFS)이다. 서비스는 클라이언트에 특정한 기능을 제공하기 위해 기기에서 동작하는 소프트웨어이다. 서버는 단일 기기에서 동작하는 서비스 소프트웨어이다. 클라이언트클라이언트 인터페이스로 서비스를 구동하는 프로세스이다. 기기간 상호 작용을 정의하는 저수준 인터페이스는 기기간 인터페이스라 한다. 파일 시스템은 파일 서비스를 클라이언트에게 제공하고, 클라이언트 인터페이스는 기본적 파일 동작으로 형성된다고 볼 수 있다. 파일 서버를 제어하는 1차 하드웨어 컴포넌트는 로컬 2차 저장소 기기로 파일들이 저장되고 클라이언트의 요청에 의해 꺼내질 수 있다. 분산형 파일 시스템은 클라이언트, 서버, 저장소 기기가 분산형 시스템 내 기기에 분산된 파일 시스템이다. 이에 따라, 서비스 활동은 네트워크를 통해 이루어진다. 중앙화된 단일 데이터 저장소 대신, 시스템은 대개 복수의 독립된 저장소 기기를 가진다. 분산형 파일 시스템의 구체적 설정과 구현은 시스템에 따라 다르다. 어떤 설정에서는 서버는 특정한 기기에서 동작하기도 한다. 어떨 때는 기기가 서버이면서 클라이언트일 수 있다. 분산형 파일 시스템의 고유 특성은 시스템 내 클라이언트와 서버의 다양성과 자율성이다. 이상적으로, 분산형 파일 시스템은 클라이언트로부터 전통적, 중앙화된 파일 시스템으로 보여야 한다. 투명한 분산형 파일 시스템의 사용자 인터페이스는 로컬과 리모트 파일을 구분하지 말아야 한다. 투명 분산형 파일 시스템은 사용자 이동을 사용자 환경을 로그인하는 곳으로 이주함으로써 이를 이룬다. 분산형 파일 시스템의 가장 중요한 성능 지표는 서비스 요청을 만족하는 데 걸리는 시간이다. 전통적인 시스템에서는 이는 저장소 접근 시간과 CPU 처리 시간으로 이루어진다. 분산형 파일 시스템에서는 원격 접근이 분산 구조와 관련된 추가 오버헤드를 가진다. 이는 요청을 서버에 전달하고 네트워크를 통해 클라이언트로 응답하는 데 걸리는 시간이다. 통신 프로토콜 소프트웨어를 계산하는 CPU 오버헤드도 있다. 이러한 분산형 파일 시스템의 성능은 분산형 파일 시스템의 투명도의 다른 관점으로도 볼 수 있다. 즉, 이상적인 분산형 파일 시스템의 성능은 전통적 파일 시스템의 그것과 비슷해야 한다. 분산형 파일 시스템의 기본적 구조는 그 궁극적 목표에 달렸다. 널리 쓰이는 두 개의 구조적 모델은 클라이언트-서버 모델클러스터-기반 모델이다. 클라이언트-서버 구조의 목표는 클라이언트간 투명한 파일 공유가 마치 로컬 기기에서 이루어지는 것처럼 하는 것이다. 분산형 파일 시스템 NFS나 OpenAFS가 그 예다. NFS는 UNIX 기반 분산형 파일 시스템의 예이다. 많은 데이터 셋에서 많은 애플리케이션이 큰 확장성과 가용성과 함께 병렬로 구동되어야 한다면, 클러스터 기반 모델이 더 적합하다. 두 예제는 Google 파일 시스템과 오픈 소스 HDFS이다.

19.6.1. The Client-Server DFS Model

클라이언트-서버 모델에서 서버는 부착된 저장소에 파일과 메타데이터를 저장한다. 시스템에서, 하나 이상의 서버는 다른 파일들을 저장하는 데 쓰일 수 있다. 클라이언트는 네트워크를 통해 서버에 연결되고 분산형 파일 시스템 내 파일에 대한 접근을 NFS와 같은 프로토콜을 통해 서버에 접속해서 요청할 수 있다. 서버가 인증에 대한 책임이 있으면 요청한 파일 허가를 체크하고 요청한 클라이언트에 파일 전송을 맡는다. 클라이언트가 파일을 수정하면 클라이언트는 이 변경을 서버에 전송해야 한다. 클라이언트와 서버의 파일 버전은 네트워크 트래픽과 서버의 부하를 가능한 작게 만드는 선에서 일관적으로 유지되어야 한다. 네트워크 파일 시스템(NFS) 프로토콜은 초기에는 서버 고장이 난 경우 빠르고 간단한 복구만을 목표로 했다. 이를 위해 상태가 없도록 설계되었다. 즉, 어떤 클라이언트가 어떤 파일을 접근하는지 몰랐다. 즉, 클라이언트의 파일 동작에 문제가 있어도 동작은 서버 크래시와 똑같이 동작하였다. Andrew 파일 시스템(OpenAFS)은 확장성을 염두에 두고 만들어졌다. 이는 서버가 가능한 많은 클라이언트를 지원하도록 설계된 프로토콜이다. 즉, 서버에 대한 요청과 트래픽을 최소화하도록. 클라이언트가 파일을 요청하면 파일의 내용이 서버로부터 다운로드되고 클라이언트의 로컬 저장소에 저장된다. 파일에 대한 업데이트는 파일이 닫힐 때 서버에 보내지는데, 파일의 새 버전은 파일이 열릴 때 클라이언트에 보내진다. 비교해서, NFS는 읽기/쓰기 요청을 클라이언트가 파일을 쓴 것처럼 서버에 보낸다. OpenAFS와 AFS 모두 로컬 파일 시스템으로 쓸 수도 있다. NFS 파일 시스템에서 하드 드라이브 파티션을 포맷하지는 않을 수 있지만, 서버에서는 선택한 로컬 파일 시스템의 파티션을 포맷해 분산형 파일 시스템에 공유 디렉토리를 내보낼 수 있다. 클라이언트에서는 내보내진 디렉토리를 파일 시스템 트리에 부착하기만 하면 된다. 이 방법으로, 분산형 파일 시스템은 로컬 파일 시스템의 책임으로부터 분리되고 분산된 작업에 집중할 수 있다. 분산형 파일 시스템 클라이언트-서버 모델은, 설계상으로, 서버가 고장나면 단클라이언트-서버 모델에서 서버는 부착된 저장소에 파일과 메타데이터를 저장한다. 시스템에서, 하나 이상의 서버는 다른 파일들을 저장하는 데 쓰일 수 있다. 클라이언트는 네트워크를 통해 서버에 연결되고 분산형 파일 시스템 내 파일에 대한 접근을 NFS와 같은 프로토콜을 통해 서버에 접속해서 요청할 수 있다. 서버가 인증에 대한 책임이 있으면 요청한 파일 허가를 체크하고 요청한 클라이언트에 파일 전송을 맡는다. 클라이언트가 파일을 수정하면 클라이언트는 이 변경을 서버에 전송해야 한다. 클라이언트와 서버의 파일 버전은 네트워크 트래픽과 서버의 부하를 가능한 작게 만드는 선에서 일관적으로 유지되어야 한다. 네트워크 파일 시스템(NFS) 프로토콜은 초기에는 서버 고장이 난 경우 빠르고 간단한 복구만을 목표로 했다. 이를 위해 상태가 없도록 설계되었다. 즉, 어떤 클라이언트가 어떤 파일을 접근하는지 몰랐다. 즉, 클라이언트의 파일 동작에 문제가 있어도 동작은 서버 크래시와 똑같이 동작하였다. Andrew 파일 시스템(OpenAFS)은 확장성을 염두에 두고 만들어졌다. 이는 서버가 가능한 많은 클라이언트를 지원하도록 설계된 프로토콜이다. 즉, 서버에 대한 요청과 트래픽을 최소화하도록. 클라이언트가 파일을 요청하면 파일의 내용이 서버로부터 다운로드되고 클라이언트의 로컬 저장소에 저장된다. 파일에 대한 업데이트는 파일이 닫힐 때 서버에 보내지는데, 파일의 새 버전은 파일이 열릴 때 클라이언트에 보내진다. 비교해서, NFS는 읽기/쓰기 요청을 클라이언트가 파일을 쓴 것처럼 서버에 보낸다. OpenAFS와 AFS 모두 로컬 파일 시스템으로 쓸 수도 있다. NFS 파일 시스템에서 하드 드라이브 파티션을 포맷하지는 않을 수 있지만, 서버에서는 선택한 로컬 파일 시스템의 파티션을 포맷해 분산형 파일 시스템에 공유 디렉토리를 내보낼 수 있다. 클라이언트에서는 내보내진 디렉토리를 파일 시스템 트리에 부착하기만 하면 된다. 이 방법으로, 분산형 파일 시스템은 로컬 파일 시스템의 책임으로부터 분리되고 분산된 작업에 집중할 수 있다. 분산형 파일 시스템 클라이언트-서버 모델은, 설계상으로, 서버가 고장나면 단일 장애점이 될 수 있다. 컴퓨터 클러스터링은 중복 컴포넌트를 쓰고 실패가 발견되었을 때 동작하는 컴포넌트로 이를 위임해 서버 동작을 계속하는 클러스터링 법으로 이를 대처할 수 있다. 추가로, 서버는 데이터나 메타데이터에 대한 요청에 대한 병목이 되므로 확장성과 대역폭에 문제가 될 수 있다.

19.6.2. The Cluster-Based DFS Model

데이터의 양과, 입출력 부하, 프로세싱이 증가하면 분산형 파일 시스템은 실패에 대처할 수 있어야 하고 확장 가능해야 한다. 큰 병목은 용납될 수 없고 시스템 컴포넌트 실패는 예측 가능해야 한다. 클러스터 기반 구조는 이를 위해 설계되었다. 이로는 Google 파일 시스템(GFS)이나 Hadoop 분산 파일 시스템(HDFS)이 있다. 복수 클라이언트는 네트워크를 통해 마스터 메타데이터 서버와 파일 조각을 들고 있는 여러 데이터 서버에 연결된다. 메타데이터 서버는 어떤 데이터가 파일의 어떤 조각을 들고 있는지와 디렉토리/파일에 대한 전통적인 계층적 매핑을 유지한다. 각 파일 조각은 데이터 서버에 저장되어 컴포넌트 실패에 대한 보호와 데이터에 대한 빠른 접근을 위해 특정한 숫자만큼 복제된다. 파일에 접근하기 위해, 클라이언트는 메타데이터 서버에 접속해야 한다. 메타데이터 서버는 요청한 파일 조각을 들고 있는 데이터 서버를 클라이언트에 반환한다. 클라이언트는 가장 가까운 데이터 서버에 연결해 파일 정보를 받는다. 파일의 서로 다른 부분은 서로 다른 데이터 서버에 저장되어 있을 경우 병렬로 읽기/쓰기될 수 있다. 메타데이터 서버는 전체 프로세스 동안 한 번만 접속되면 된다. 그러므로 메타데이터 서버는 성능 병목이 잘 되지 않는다. 메타데이터 서버는 데이터 서버에 파일 조각을 분배하고 균형 맞추는 것도 맡는다. GFS의 설계는 4가지의 메인 관찰로부터 시작되었다:

  • 하드웨어 컴포넌트 고장은 흔한 것이기 때문에 일상적으로 예측되어야 한다.
  • 시스템 내 저장되는 파일은 매우 크다.
  • 대부분의 파일은 존재하는 파일을 덮어씌우는 게 아니라 파일 끝에 새 데이터를 추가함으로써 변경된다.
  • 파일 시스템 API와 애플리케이션을 재설계하는 것은 시스템의 유연성을 높인다.

GFS 이후 Google은 MapReduce라는 모듈화된 소프트웨어 층을 개발하였다. 이는 대용량 병렬 계산을 더 쉽게 하고 저층 파일 시스템의 이득을 누리게 한다. 이후, Hadoop이 생겨났으며, 이는 분산형 컴퓨팅 환경에서 큰 데이터 셋을 처리할 수 있도록 하였다. 이는 빅 데이터 프로젝트를 할 수 있게 하였다.

19.7. DFS Naming and Transparency

명명은 논리적 오브젝트와 물리적 오브젝트간 매핑이다. 사용자는 파일을 텍스트 이름으로 찾고 이는 디스크 블록으로 매핑되는 저수준 숫자 식별자로 매핑된다. 이는 사용자에게 디스크 파일의 내부 구현을 숨긴다. 투명한 분산형 파일 시스템에서는 새 추상화 레이어가 추가된다: 네트워크의 어디에 파일이 위치했는지를 숨기는 것이다. 전통적 파일 시스템에서는 명명의 범위는 디스크 내 주소에 대한 매핑이다. 분산형 파일 시스템에서는 이는 파일이 어느 디스크에 저장되어 있는지에 대한 특정한 기기를 가리키는 것까지로 확장된다. 이는 한 발 더 나아가 파일 복제를 가능케 한다. 파일 명이 주어지면, 매핑은 파일의 복제가 있는 위치들의 집합도 반환한다. 이 추상화에서, 여러 복제와 그 장소는 숨겨진다.

19.7.1. Naming Structure

분산형 파일 시스템에서 이름 매핑에 대해 2가지 관계된 개념을 구분지어야 한다.

  • 장소 투명성. 파일의 물리적 저장소 위치를 드러내지 않는 것.
  • 장소 독립성. 파일의 물리적 저장소 위치가 바뀌어도 파일의 이름이 바뀌지 않는 것.

이는 모두 명명의 수준과 관계가 있다. 장소 독립적인 명명은 동적 매핑이다. 그러므로, 장소 독립성은 장소 투명성보다 더 강하다. 실제로, 대다수의 분산형 파일 시스템은 사용자 수준ㅇ 이름엔 장소 투명성 매핑을 쓴다. 어떤 것은 파일의 위치를 자동적으로 옮기는 파일 이주를 통해 장소 독립성을 얻는다. 장소 독립성, 정적 장소 투명성을 구분짓는 몇 개의 관점은 다음과 같다:

  • 장소 독립성에 의해 데이터를 위치와 독립시키는 것은 파일에 대한 추상화를 개선시킨다. 파일명은 파일 위치가 아닌 파일의 가장 중요한 특성들을 갖고 있어야 한다. 위치 의존적인 파일들은 특정한 저장소 위치에 부착되지 않은 논리적 데이터 컨테이너로 볼 수 있다. 정적 위치 투명성만이 지원된다면, 파일명은 특정한 (비록 숨겨졌을지언정) 물리적 디스크 블록의 집합을 나타낼 것이다.
  • 정적 위치 투명성은 사용자들에게 데이터를 공유하는 편리한 방법을 제공한다. 사용자들은 단순히 이름을 위치-투명적인 방식으로 로컬 파일인 것처럼 명명해 원격 파일을 공유한다. Dropbox나 다른 클라우드 기반 저장소가 이렇게 동작한다. 장소 독립성은 데이터 오브젝트와 함께 저장소 공간 자체를 공유하도록 유도한다. 파일이 이동될 수 있으면, 전체 시스템별 저장소 공간은 단일 가상 자원처럼 보인다. 가능한 이득은 시스템을 통틀어 저장소의 활용을 균형 맞추는 것이다.
  • 저장소 독립성은 저장소 기기 계층과 컴퓨터 내 구조로부터 명명 계층을 분리한다. 반면, 정적 저장소 투명성이 사용된다면 이름이 투명할지라도 컴포넌트 유닛과 기기간 대응을 쉽게 노출시킬 수 있다. 기기들은 명명 구조와 비슷한 패턴으로 구조화된다. 이 설정은 시스템의 아키텍쳐를 불필요하게 제한시킬 수 있으며 다른 고려 사항과 충돌할 수 있다. 루트 디렉토리를 담당하는 서버는 명명 계층에 의해 강제되어 탈중앙화 가이드라인에 모순되는 구조의 예이다.

이름과 장소의 분리가 끝나면, 클라이언트는 원격 서버 시스템의 파일을 접근할 수 있다. 이 클라이언트는 디스크 없이 서버에 의존해 운영 체제 커널을 포함한 모든 파일을 제공할 수 있다. 하지만 부트 과정에는 특별한 프로토콜이 필요하다. 디스크 없는 워크스테이션에서 커널을 얻어오려면 클라이언트의 ROM에 있는 특별한 부트 프로토콜이 가동되어 네트워크를 가능케 하고 특정 위치에 있는 특별한 파일(커널이나 부트 코드)를 가져온다. 커널이 네트워크에 복제돼 로드되면 분산형 파일 시스템은 다른 운영 체제 파일을 사용 가능하게 한다. 무디스크 클라이언트의 이득은 여러 가지일 수 있는데 저비용, 고편의성 등이다. 단점은 부트 프로토콜의 복잡도 증가와 로컬 디스크 대신 네트워크를 사용함으로 인한 성능 저하이다.

19.7.2. Naming Schemes

분산형 파일 시스템을 명명하는 3가지 메인 접근법이 있다. 가장 간단한 방법은 파일은 호스트명과 로컬 이름의 조합으로 명명되어 유일한 시스템별 이름을 얻는다. Internet URL은 이 바법을 쓴다. 이는 장소 투명하거나 장소 독립적이지 않다. 분산형 파일 시스템은 독립적인 컴포넌트 유닛으로 구성되어 각각은 그 자체로 전체 전통적 파일시스템이기 때문이다. 컴포넌트 유닛은 독립적으로 남아서가지 메인 접근법이 있다. 가장 간단한 방법은 파일은 호스트명과 로컬 이름의 조합으로 명명되어 유일한 시스템별 이름을 얻는다. Internet URL은 이 방법을 쓴다. 이는 장소 투명하거나 장소 독립적이지 않다. 분산형 파일 시스템은 독립적인 컴포넌트 유닛으로 구성되어 각각은 그 자체로 전체 전통적 파일시스템이기 때문이다. 컴포넌트 유닛은 독립적으로 남지만 원격 파일을 참조하는 방법은 제공된다. 두 번째 방법은 네트워크 파일 시스템에서 널리 쓰이는데, 네트워크 파일 시스템은 원격 디렉토리를 로컬 디렉토리에 부착해 일관성 있는 디렉토리 트리의 모습을 제공한다. 최초의 네트워크 파일 시스템은 이미 마운트된 원격 디렉토리만을 투명하게 접근할 수 있도록 하였다. 자동 마운트 특성의 출현은 마운트 포인트 테이블과 파일 구조명에 기반해 필요에 따라 마운트될 수 있도록 하였다. 컴포넌트는 투명한 공유를 지원하도록 통합되지만, 이 통합은 제한적이며 균일하지 않다. 각 기기는 그 트리에 다른 리모트 디렉토리에 부착될 수 있기 때문이다. 결과 구조는 가변적이다. 세 번째 접근법으로는 컴포넌트 파일 시스템간의 완전한 통합을 얻을 수 있다. 이 때 단일 전역 이름 구조가 시스템 내 모든 파일을 망라한다. 이상적으로, 통합된 파일시스템 구조는 전통적인 파일시스템의 구조와 같다. 하지만 실제로, 많은 특별한 파일은 이 목표를 이루기 어렵게 만든다. 이름 구조를 평가하기 위해서는, 그 관리적 복잡도를 살펴봐야 한다. 가장 복잡하고 가장 유지보수하기 어려운 구조는 네트워크 파일 시스템 구조이다. 로컬 디렉토리의 어디에도 원격 디렉토리가 부착될 수 있기 때문에, 결과 구조는 매우 비구조화될 수 있다. 서버가 사용 불가능해지면, 다른 기기의 임의의 디렉토리 집합이 사용 불가능해질 수 있다. 또한, 별도의 승인 메커니즘이 어떤 기기가 트리에 어떤 디렉토리를 부착할지를 제어한다. 그러므로, 사용자는 한 클라이언트의 원격 디렉토리 트리에 접근할 수 있어야 하지만 다른 클라이언트에 대한 접속은 거부되어야 한다.

19.7.3. Implementation Techniques

투명한 명명의 구현은 파일명의 연관된 장소에 대한 매잎을 필요로 한다. 이 매핑을 관리할 수 있게 하려면 파일의 집합을 컴포넌트 유닛으로 통합해 단일 파일 기반이 아닌 컴포넌트 유닛 기반 매핑을 제공해야 한다. 이 통합은 관리의 목적도 수행한다. UNIX형 시스템은 계층적 디렉토리 트리를 써서 이름-장소 매핑을 제공하고 파일을 디렉토리로 재귀적으로 통합한다. 이 중대한 이름 정보의 가용성을 증대시키기 위해, 복제, 로컬 캐싱, 또는 그 둘을 모두 제공할 수 있다. 장소 독립성은 매핑이 시간에 따라 바뀔 수 있음을 의미한다. 그러므로, 매핑을 복제하는 것은 간단하지만 정보의 일관성 있는 업데이트는 불가능하게 한다. 이를 극복하기 위해, 저수준의 장소 독립적 파일 식별자를 도입할 수 있다. 텍스트 파일명은 저수준 파일 식별자로 매핑되어 파일이 어떤 컴포넌트 유닛에 속하는지를 가리킨다. 이 식별자는 여전히 장소 독립적이다. 이는 복제되어 컴포넌트 유닛이 병합되더라도 무효화되지 않고 자유롭게 캐싱될 수 있다. 피할 수 없는 비용은 컴포넌트 유닛을 장소로 매핑하고 단순하지만 일관적인 업데이트 메커니즘을 요구하는 두 번째 층의 매핑에 대한 필요이다. UNIX형 디렉토리 트리를 이러한 저수준의 장소독립적 식별자를 통해 구현하는 것은 컴포넌트 유닛 통합에 대해 전체 계층이 불변이 되도록 하였다. 바뀌는 것은 컴포넌트 유닛 장소 매핑 뿐이다. 저수준 식별자를 구현하는 범용적인 방법은 구조화된 이름을 쓰는 것이다. 이 이름들은 2부분을 가진 비트 문자열이다. 첫 번째 부분은 파일이 속하는 컴포넌트 유닛을 식별한다. 두 번째 부분은 유닛 내 특정한 파일을 식별한다. 더 많은 파트가 있는 변종도 가능하다. 구조화된 이름의 불변성은 이름의 부분 각각이 유일하려면 다른 부분이 바뀌지 않아야 한다는 것이다. 이 때 충분히 많은 비트를 추가해 이미 사용중인 이름을 재사용하지 않도록 할 수 있다. 또는 이름의 일부분에 타임스탬프를 추가하는 방법도 있다. 이 과정을 바라보 또 다른 관점은 장소 투명적 시스템을 갖고 장소 독립적 명명 방식을 제공하는 또 다른 추상화 층을 제공한다는 것이다.

19.8. Remote File Access

원격 파일에 대한 접근을 요청하는 사용자를 고려해 보자. 파일을 저장하는 서버는 명명 방식에 의해 찾아내어지고, 실제 데이터 전송이 일어나야 한다. 이를 이루는 한 가지 방법은 원격 서비스 메커니즘을 통한 것이다. 이는 접근 요청이 서버에 도착하면 서버 기계가 접근을 수행하고 이 결과가 사용자로부터 다시 전달되는 것이다. 이는 원격 프로시저 호출로 흔히 구현된다. 전통적 파일 시스템에서의 디스크 접근 법과 분산형 파일 시스템의 원격 서비스 방법의 직접 대응 관계가 존재한다: 원격 서비스 방식을 쓰는 것은 각 접근 요청에 대해 디스크 접근을 수행하는 것과 비슷하다. 원격 서비스 메커니즘에 대해 합당한 성능을 보장하기 위해, 캐싱을 할 수 있다. 전통적 파일 시스템에서는 캐싱의 이유는 디스크 입출력을 줄이는 것이지만 분산형 파일 시스템에서는 네트워크 트래픽과 디스크 입출력을 모두 줄이려는 것이다. 이제 분산형 파일 시스템에서의 캐싱을 알아보고 기본적 원격 서비스 패러타임과 비교해 보자.

19.8.1. Basic Caching Service

캐싱의 개념은 간단하다. 접근 요청을 만족시켜야 하는 데이터가 캐시되지 않았으면 데이터의 복제가 서버로부터 클라이언트 시스템에 도달한다. 접근은 캐싱된 복제에 수행된다. 발상은 캐시 내 최근에 접근된 디스크 블록을 유지해 같은 정보에 대한 반복적 접근이 추가 네트워크 트래픽 없이 로컬하게 다뤄지는 것이다. 대체 정책 (예를 들어 최소 최근 사용 알고리즘)은 캐시 크기를 제한시킨다. 접근과 서버의 트래픽 사이 직접적 대응 관계는 없다. 파일은 서버 기기 내 존재하는 하나의 마스터 카피로 식별되지만, 파일의 복제는 다른 캐시들에 분산되어 있을 수 있다. 캐싱된 카피가 수정되면, 이 변경은 마스터 카피에 반영되어 관련 있는 일관성을 보존해야 한다. 캐싱된 카피를 마스터 파일과 일관성 있게 유지하는 문제는 캐시 일관성 문제이다. 분산형 파일 시스템 캐싱은 네트워크 가상 메모리에 캐싱될 수 있다. 이는 요구에 따라 페이징되는 가상 메모리와 비슷하게 동작하나, 보조 기억 장치는 대개 로컬 디스크가 아닌 원격 서버이다. 네트워크 파일 시스템은 교환 공간을 원격으로 마운트되도록 하여, 성능 저하는 있더라도 가상 메모리를 네트워크에 구현할 수 있도록 한다. 분산형 파일 시스템 내 캐시된 데이터의 단위는 파일 블록에서 전체 파일일 수 있다. 보통 단일 접근을 충족하기 위한 것보다 더 많은 데이터가 캐시되어, 캐시된 데이터로부터 많은 접근이 이뤄질 수 있도록 한다. 이는 디스크 미리 읽기와 비슷하다. 큰 조각으로 캐시되기도 하고 클라이언트의 요구에 따라 각 블록이 캐싱을 지원하기도 한다. 캐싱 유닛을 증가시키는 것은 명중율을 증가시키지만, 각 빗맞음이 더 많은 데이터의 전송을 요구하므로 빗맞음 패널티도 증가시킨다. 이는 잠재적으로 일관성 문제를 증가시키기도 한다. 캐싱의 단위를 선택하는 것은 네트워크 전송 유닛이나 원격 프로시져 호출 프로토콜 서비스 단위 같은 매개변수에 대한 고려도 포함한다. 네트워크 전송 단위는 1.5KB로, 캐시 데이터 단위가 더 크면 전송을 위해 분해되어야 하고 수신을 위해 재구성되어야 한다. 블록 크기와 전체 캐시 크기는 블록 캐싱 방식에서 중요하다. UNIX류 시스템에선 보통 블록 크기는 4KB/8KB이다. 큰 캐시(1MB 이상)에서는 큰 블록 크기(8KB)가 낫다. 더 작은 캐시에서는 큰 블록 크기는 이득이 없다. 캐시 내 블록 수가 적어지고 명중률이 낮아지기 때문이다.

19.8.2. Cache Location

캐시된 데이터는 디스크나 메인 메모리 중 어디에 저장되어야 할까? 디스크 캐시는 메인 메모리 캐시에 대한 분명한 이점이 있다: 신뢰성 있다. 캐시된 데이터에 대한 수정은 캐시가 휘발성 메모리에 있으면 크래시되면 날아간다. 캐시된 데이터가 디스크에 존재하면, 복구 중에도 그대로 있을 것이므로, 다시 가져올 필요가 없다. 하지만 메인 메모리 캐시도 몇 가지 장점이 있다.

  • 워크스테이션이 디스크 없이 존재할 수 있다.
  • 디스크에 캐싱된 데이터를 가져오는 것보다 메인 메모리에서 가져오는 것이 빠르다.
  • 메모리는 더 커지고 싸지고 있다. 이로 인한 성능 가속의 이점은 디스크 캐시의 장점을 뛰어넘는다.
  • 서버 캐시는 사용자 캐시가 어디에 있든 메인 메모리에 있다. 사용자 기기에서도 메인 메모리 캐시를 쓰면 서버와 사용자에 대해 단일 캐시 메커니즘을 쓸 수 있다.

많은 원격 접근 구현은 캐싱과 원격 서비스의 혼합으로 생각될 수 있다. 네트워크 파일 시스템은, 원격 서비스 기반 구현이나 성능을 위한 클라이언트 그리고 서버단 메모리 캐싱을 통해 보강되었다 볼 수 있다. 즉 이 두 방법을 평가하려면, 둘 중 무엇이 강조되었는지를 평가해야 한다. NFS 프로토콜과 대다수의 구현은 디스크 캐싱을 제공하지 않는다.

19.8.3. Cache-Update Policy

수정된 데이터 블록을 서버의 마스터에 다시 쓰는 정책은 시스템의 성능과 신뢰성에 핵심적인 영향을 미친다. 가장 간단한 방법은 데이터가 캐시에 자리잡으면 가능한 빨리 디스크에 이를 쓰는 것이다. 이런 라이트-스루 정책의 이점은 신뢰성이다: 클라이언트 시스템이 크래시되어도 거의 정보가 손실되지 않는다. 하지만, 이 정책은정보가 서버에 전송되기 전까지 각 쓰기 접근에 대한 대기를 요구하며 쓰기 성능은 낮아진다. 라이트 스루 캐싱은 쓰기 접근에 원격 서비스를 쓰고 읽기 접근을 위해서만 캐싱을 이용하는 것과 같다. 대안은 지연된 쓰기 정책(라이트-백 캐싱)으로, 마스터 복제에 대한 업데이트를 지연시키는 것이다. 수정 사항이 캐시에 쓰여지고 이후에 서버를 통해 쓰여진다. 이 정책은 라이트-스루에 비해 두 가지 이점이 있다. 첫 번째로 쓰기가 캐시에 이뤄지므로 쓰기 접근이 더 빨리 끝난다. 둘째로, 쓰기가 반영되기 전 덮어쓰기가 되더라도 가장 마지막 업데이트만이 반영된다. 불운하게도, 지연된 쓰기 방식은 신뢰성 문제를 일으키는데, 사용자 기기가 크래시되면 쓰이지 않은 데이터는 유실되기 때문이다. 지연된 쓰기 정책의 변종들은 수정된 데이터 블록이 서버에 언제 플러시되느냐에 따라 달라진다. 한 대안은 블록이 클라이언트의 캐시로부터 꺼내질 때 이를 플러시하는 것이다. 이는 좋은 성능을 낼 수 있지만, 클라이언트의 캐시에 있는 어떤 블록들은 서버에 쓰여지기 전에 오랜 기간 동안 남아있을 수 있다. 이 대안과 라이트-스루 정책간 절충은 정해진 시간마다 캐시를 스캔해 가장 최근의 스캔 이후 수정된 블록을 플러시하는 것이다. 네트워크 파일 시스템은 파일 데이터에 대해 이 정책을 쓰는데, 캐시 플러시 도중 서버에 쓰기가 발생했을 때, 쓰기는 완료되기 전에 서버의 디스크에 도달해야 한다. 네트워크 파일 시스템은 메타데이터를 다르게 다룬다. 메타데이터 변경은 서버에 동기적으로 반영된다. 그러므로 클라이언트나 서버가 크래시되도 파일 구조 손실과 디렉토리 구조 붕괴는 일어나지 않는다. 지연된 쓰기의 또 다른 변형은 파일이 닫힐 때 데이터를 서버로 다시 쓰는 것이다. 이런 닫힘-쓰기 정책은 OpenAFS에 쓰인다. 짧은 시간 동안 파일이 열리거나 드물게 수정된다면, 이 정책은 네트워크 트래픽을 유의미하게 줄이진 못한다. 추가로, 닫힘-쓰기 정책은 파일이 쓰여지는 도중에 닫는 과정을 지연시킨다. 이는 지연된 쓰기의 성능 이점을 감소시킨다. 긴 시간동안 열리거나 자주 변경되는 파일이라면, 이 정책의 성능 이득은 더 빈번한 플러싱 상에서 지연된 쓰기에 비해 확실히 낫다.

19.8.4. Consistency

클라이언트 기기는 로컬 캐시된 데이터 복제가 마스터 복제와 일관적인지를 결정하는 문제를 맞닥뜨린다. 클라이언트 기기가 캐싱된 데이터가 오래된 것을 발견한다면, 이는 접근을 더 허용하기 전 데이터의 업데이토된 복제를 캐시해야 한다. 캐싱된 데이터의 유효성을 검증하는 두 가지 방법이 있다.

  1. 클라이언트 주도 접근. 클라이언트는 서버에 접속해서 유효성 체크를 주도하고 로컬 데이터가 마스터 복제와 일관적인지를 체크한다. 이 유효성 체킹의 빈도는 이 접근의 가장 중요한 부분이며 남은 일관성 방법을 결정한다. 이는 모든 접근 전 체크로부터 파일에 대한 최초 접근시에만 체크하는 것으로 다양하다. 캐시에 의해 즉각적으로 수행되는 접근과 비교하면 유효성 체크와 묶인 모든 접근은 지연된다. 대신, 고정된 시간폭마다 체크가 수행될 수도 있다. 그 빈도에 따라, 유효성 체크는 네트워크와 서버를 전부 로딩할 수도 있다.
  2. 서버 주도 접근. 서버는 각 클라이언트에 대해 캐시하는 파일을 저장한다. 서버가 잠재적 비일관성을 발견하면 반응해야 한다. 잠재적 비일관성은 충돌하는 모드의 두 다른 클라이언트가 파일을 캐싱할 때 일어난다. UNIX 방식이 쓰이면 서버가 활성화된 역할을 맡아 잠재적 비일관성을 해결할 수 있다. 서버는 파일이 열렸을 때 공지되어야 하며, 의도한 모드는 각 열기마다 지시되어야 한다. 파일이 충돌하는 모드에서 동시에 열렸음을 감지했을 때 서버는 그 파일에 대한 캐싱을 비활성화해서 반응한다. 캐싱을 비활성화하는 것은 동작을 원격 서비스 모드로 바꾸는 것과 같다.

클러스터 기반 분산형 파일 시스템에서는 캐시 일관성 문제는 더 어려워진다. 메타데이터 서버의 존재와 여러 데이터 서버에 따른 데이터 조각의 복제의 존재 때문이다. HDFS는 덧붙이기 한정 쓰기 연산과 단일 파일 쓰기를 제공하지만, GFS는 무작위 쓰기와 동시 쓰기를 지원하기 때문에 쓰기 일관성 보장이 훨씬 어려워진다.

19.9. Final Thoughts on Distributed File Systems

분산형 파일 시스템 클라이언트 서버와 클러스터 기반 아키텍쳐의 경계는 흐려지고 있다. GFS/HDFS 등은 비 POSIX API를 내보내므로 디렉토리를 일반 사용자 기기로 투명하게 매핑할 수 없고, 클라이언트 코드 설치를 필요로 한다. 하지만, 이런 DFS 위에 NFS가 마운트될 수 있도록 다른 소프트웨어 레이어들이 개발되고 있다. 이는 클러스터 기반 DFS의 확장성과 다른 이점을 취하면서도 네이티브 운영 체제 기능들과 DFS의 파일에 대한 직접 접근을 이룰 수 있으므로 매력적이다. HDFS는 무작위 쓰기를 지원하지 않으므로 파일은 한 바이트만 바뀌어도 삭제되고 재생성되어야 한다. DFS 쌓기를 허용하는 쌓을 수 있는 프레임워크, 병렬 컴퓨팅 모듈, 분산 데이터베이스, NFS를 통한 파일 볼륨 내보내기 등을 위해 이를 해결하려 하고 있다. 클러스터 기반 분산형 파일 시스템보단 덜 복잡하지만 클라이언트-서버 분산형 파일 시스템보다는 더 복잡한 파일 시스템은 클러스터 파일 시스템(CFS) 또는 병렬 파일 시스템(PFS)이다. 이는 LAN을 통해 동작하며 중요하고 범용적으로 쓰인다. LustreGPFS 등이 잇다. 분산형 파일 시스템은 LAN, 클러스터 환경, WAN 등에서 파일 공유를 제공하여 널리 쓰인다. DFS는 범용성을 위해 운영 체제에 독립적이어야 하고, 긴 거리에서도 가용성과 좋은 성능을 제공해야 하고, 하드웨어 실패에 대처해야 하고, 빈약한 네트워킹과 증가하는 사용자와 부하에도 대처할 수 있어야 하므로 이런 시스템을 구현하는 복잡도는 높다.

19.10. Summary

  • 분산형 시스템은 메모리나 클락을 공유하지 않는 프로세서의 모음이다. 대신 각 프로세서는 각 로컬 메모리를 갖고 프로세스는 고속 버스나 인터넷 등 여러 통신선을 통해 통신한다. 분산형 시스템 내 프로세서의 크기와 기능은 다양하다.
  • 분산형 시스템은 사용자에 모든 시스템 자원에 대한 접근을 제공한다. 공유 자원에 대한 접근은 데이터 이주, 연산 이주, 프로세스 이주로 이루어질 수 있다. 이런 접근은 사용자에 의해 특정되거나 운영 체제, 애플리케이션에 의해 제공될 수 있다.
  • 네트워크 레이어링 모델에 의해 특정되는 프로토콜 스택은 메시지에 정보를 더해 도착지에 도착할 수 있도록 보장한다.
  • DNS 같은 명명 시스템은 호스트명을 네트워크 주소로 바꾸는 데 필요하다. ARP 같은 다른 프로토콜은 네트워크 번호를 네트워크 기기 주소 (이더넷 주소등)로 변환하는 데 필요할 수 있다.
  • 시스템이 분리된 네트워크에 위치해 있으면 발신 네트워크에서 수신 네트워크로 패킷을 전달하는 데 있어 라우터가 필요하다.
  • 전송 프로토콜 UDP와 TCP는 유일한 시스템별 포트 번호를 써서 패킷을 대기 프로세스로 지시한다. 추가로, TCP 프로토콜은 패킷의 흐름을 더 신뢰성 있는, 연결 지향 바이트 스트림이 되게 한다.
  • 분산형 시스템이 올바르게 작동하려면 여러 난관이 있다. 시스템의 노드나 프로세스에 대한 명명, 실패에 대한 대처, 에러 회복, 확장성 등이다. 확장성 문제는 증가한 부하에 대한 대처, 실패에 대한 대처, 효과적인 저장소 방식의 사용, 압축과 중복 방지 등이 있다.
  • 분산형 파일 시스템은 클라이언트, 서버, 저장소 기기가 분산된 시스템의 지역에 펼쳐져 있는 파일 서비스 시스템이다. 이에 따라, 서비스 활동은 네트워크를 통해 이루어진다. 단일 중앙화된 데이터 저장소 대신, 복수의 독립적인 저장소 기기가 존재한다.
  • 분산형 파일 시스템 모델에는 2가지의 형태가 존재한다: 클라이언트-서버 모델과 클러스터 기반 모델. 클라이언트-서버 모델은 복수 클라이언트간 투명한 파일 공유를 가능케 한다. 클러스터 기반 모델은 데이터 서버간 파일을 분배하고 대용량 병렬 데이터 처리를 위해 만들어졌다.
  • 이상적으론, 분산형 파일 시스템은 클라이언트에게 전통적, 중앙화된 파일 시스템처럼 보여야 한다. 서버와 저장소 기기의 증식과 분산은 투명해야 한다. 투명 분산형 파일 시스템은 클라이언트 이동을 클라이언트의 환경을 클라이언트가 로그인한 지역으로 이동시켜서 이룬다.
  • 분산형 파일 시스템의 명명 방식에는 여러 접근법이 있다. 가장 간단한 방법은 파일이 호스트명과 로컬 이름의 조합으로 이루어져 유일한 시스템별 이름을 보장하는 것이다. NFS에 널리 쓰이는 다른 방법은 로컬 디렉토리에 리모트 디렉토리를 부착해 일관성 있는 디렉토리 트리 구조의 모습을 만드는 것이다.
  • 원격 파일에 대한 접근 요청은 대개 2개의 상호보완적 방법에 의해 다뤄진다. 원격 서비스와 함께, 접근에 대한 요청은 서버에 전달된다. 서버 기기는 접근을 수행해 그 결과는 클라이언트로 되돌려진다. 캐싱과 함께, 접근 요청을 만족해야 하는 데이터가 캐싱되지 않았다면 데이터의 복제가 서버에서 클라이언트로 전달된다. 접근은 캐시된 복제에 수행된다. 캐싱된 복제를 마스터 파일과 일관성 있게 유지하는 문제를 캐시 일관성 문제라 한다.

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google photo

Google의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

%s에 연결하는 중