Naming
분산 시스템에서 Name이란, 엔티티의 참조로 사용되는 비트나 문자 스트링이다.
많은 수의 노드의 ip 관리가 어렵기 때문에, name을 붙이기 시작했다.
네트워크 주소, 프로세스 식별자, 파일 이름, 유저 이름, 서비스 이름, 클래스 식별자 등이 있다.
네임은 공유를 가능하게 한다. 네임은 다른 오브젝트와 통신하기 위해서 흔히 쓰이는 것이며, 싱글 네임은 같은 일을하는 다수의 오브젝트를 대표할 수 있다.
또한, 네임은 큰 집합에서 특정 구성원을 고유하게 식별할 수 있다.
네임은 명명된 객체가 수행하는 역할을 나타낼 수 있으며, 위치에 대한 힌트를 줄 수 있고, 수행할 수 있는 작업을 나타낼 수 있다.
네임의 유형
- 주소: IP주소나 포트같이 특정 엔티티에 연결된 접근 지점을 나타내는 네임이다. 하나의 엔티티는 여러 주소에서 접근이 가능하다. 엔티티는 자신의 주소를 변경할 수 있으며, 변경된 주소는 다른 엔티티에 다시 할당될 수 있다.
- 식별자: 전화번호 같이 최대 하나의 엔티티를 참조하는 네임이다. 각 엔티티는 최대 하나의 식별자로 참조된다. 식별자는 항상 동일한 엔티티를 참조하며, 다른 엔티티에 재사용되지 않는다.
- 사람이 읽을 수 있는 네임: 문자열로 표현된다. DNS나 파일 이름 등등 다양한 형태로 사용된다. 시스템을 위해 네임은 주소와 바인딩될 수 있다.
Flat Naming
식별자를 사용하는 네임을 Flat Name이라고도 부른다.
식별자는 엔티티를 고유하게 나타내는 도구이며, 대게 단순한 랜덤 비트들로 이루어져 있다. 이를 비구조적 또는 플랫네임이라고 부른다.
플랫네임은, 의미없는 비트스트링이기 때문에 어떤 정보도 포함되어 있지 않다.
Broadcasting
ID를 방송한 다음, 엔터티에게 현재 주소를 반환하도록 요청한다.
식별자는 위에서 말했듯이 정보가 없어서 연결된 노드를 찾을 수 없다.
하지만 로컬 영역 네트워크(LAN)를 넘어서 확장될 수 없으며, 모든 프로세스가 요청을 듣고 있어야한다.
ex) 주소 결정 프로토콜(ARP): IP주소에 연결된 MAC 주소를 알아내기 위해 브로드캐스트를 통해 쿼리 "이 IP주소를 가진 노드?" 를 전송한다.
하지만 모든 노드에 방송을 해야하기 때문에, 네트워크가 커지기 시작하면 비효율적인 방식이다.
네트워크의 밴드넓이가 요청 메세지로 인해 소비되며, 요청에 응답할 수 없는 많은 호스트들이 블락을 당한다.
때문에 제한된 그룹의 호스트만 요청을 수신하는 방식인 멀티캐스팅을 사용한다.
멀티캐스팅은 Point-to-piont 네트워크에서도 엔티티를 찾는데 사용할 수 있다.
Home-based Approaches
홈 기반 접근 방식은 대규모 네트워크에서 모바일 엔티티를 지원하는 방식이다.
홈 위치는 엔티티의 현재 위치를 추적하는 역할을 한다.
각 모바일 호스트는 고정된 IP주소를 사용하며, 이 주소는 네이밍 서비스에 등록된다. 이 IP주소로의 모든 통신은 해당 모바일 호스트의 홈 에이전트로 전달된다. 홈 에이전트는 모바일 호스트의 IP주소에 포함된 네트워크 주소에 해당하는 로컬 영역 네트워크에 위치해 있다.
만약 모바일 호스트가 다른 네트워크에 이동한다면, 모바일 호스트는 통신을 위해 사용할 임시 주소를 요청하고, 이 임시 주소는 호스트 에이전트에 등록된다.
클라이언트가 호스트의 홈 위치로 패킷을 전송하면, 홈 에이전트는 현재 호스트가 있는 주소를 리턴해준다.
홈 에이전트가 클라이언트에게서 온 첫 번째 패킷을 일단 호스트의 현재 위치로 보내주면, 주소를 받은 클라이언트는 두번째 패킷부터는 호스트의 현재 주소로 패킷을 전송한다.
하지만 홈 기반 방식에도 문제점이 존재한다.
홈 주소가 엔티티가 살아있는 동안에는 계속 지원되어야한다.
또한 홈 주소는 고정되어 있어, 엔티티가 영구적으로 다른 위치로 이동할 경우 불필요한 부담이 발생한다.
엔티티가 실제로는 클라이언트 가까이에 존재할 수 있기 때문에, 지리적 확장성이 좋지 않다.
엔티티의 영구적인 이동은 다른 네이밍 수준을 통해 해결할 수 있다. (DNS는 매칭된 ip 변경 가능)
Hierarchical Apporoaches
계층적 구조에서, 네트워크는 여러 도메인으로 나눠진다. 여기서 각 도메인은 더 작은 서브도메인들로 나뉜다.
최하위 도메인(leaf domain)은 일반적으로 영역 네트워크(LAN) 또는 모바일 전화 네트워크의 셀(cell)에 해당한다.
Hierarchical Location Services(HLS)은 이 접근 방식을 이용한 서비스다.
기본 네트워크는 계층적으로 나눠지고, 각 도메인은 개별 디렉터리 노드에 의해 대표된다. 상위 노드는 하위 노드의 위치 정보를 가지고 있는 것이다.
트리형태의 구조에서, 엔티티의 주소(E)는 리프 노드 또는 중간 노드(M)에 저장된다.
중간 노드는 자식 노드를 가리키는 포인터를 포함하고 있고, 루트 노드는 모든 엔티티에 대한 정보를 알고 있다. 여기서 정보란, 데이터 정보가 아니는 엔티티로 향하는 경로 데이터를 말한다.
조회 연산(Lookup operation) 요청을 수행한다고 하자.
노드가 엔티티 E에 대한 정보를 알고 있으면, 아래쪽 포인터를 따라가고, 모르면 위로 이동한다.
위의 노드에서 엔티티 E에 대한 정보를 알고 있으면 다시 포인터를 따라가지만, 몰라서 위로 계속 이동하다보면 결국 루트 노드에서 멈춘다.
이번엔 삽입 연산(Insert operation)을 수행한다고 하자.
(a) 삽입 요청은 엔티티 E에 대한 정보를 알고 있는 첫 번째 노드로 전달된다. 요청이 들어온 리프노드에서 위로 올라가다가 정보를 가지고 있는 노드 M을 만나고 멈춘다.
(b) 요청을 한 리프 노드로 가는 포인터가 생성된다.
Structured Naming
Flat name은 머신에는 좋지만, 사람에게는 그렇게 편하지 않다.
하지만 Structured name은 간단하고 사람이 읽을 수 있는 이름이다.
구조적 네임 서비스에서 인식되는 유효한 네임들의 집합을 네임스페이스라고 하는데, 네임스페이스는 라벨이 붙은 방향성 그래프로 표시되며 두 가지 유형의 노드가 존재한다.
- 리프 노드: 일반적으로 엔티티에 대한 정보를 저장한다.
- 디렉터리 노드: 여러 개의 엣지(간선)를 가지고 있다.
Namespace
위에서 설명했듯, 네임스페이스의 네이밍 그래프에는 리프노드와 디렉터리 노드가 존재한다.
리프 노드는 엔티티를 대표하고, 디렉터리 노드는 다른 노드로 향하는 참조를 제공하는 엔티티다.
디렉터리 노드는 디렉터리 테이블을 저장하는데, 이는 노드 식별자와 엣지 라벨을 쌍으로 저장하고 있다.
위 그림에서 보이듯이 일반노드(=리프 노드)는 네임이 저장된 엔티티를 나타내며, 엣지가 존재하지 않는다.
컨텍스트 노드(= 디렉터리 노드)는 라벨이 붙은 여러 개의 엣지를 저장하고 있으며, 노드 식별자와 엣지라벨이 쌍으로 저장되어 있는 컨텍스트 테이블을 포함한다.
컨텍스트 테이블을 통해 노드의 위치를 알아낼 수 있는데, 이를 노드의 Path name이라고 한다.
라벨들의 순서로 노드를 참조할 수 있게 되며, /(slash)를 기준으로 경로를 나열한다.
- 절대 경로 이름: 루트부터 시작하는 전체 경로
- 상대 경로 이름: 현재 위치에서 시작하는 경로
Name Resolution: 네임 해석
네임스페이스는 네임을 통해 엔티티에 대한 정보를 저장하고 검색하는 편리한 메커니즘을 제공한다. 네임을 조회하는 과정을 '네임 해석'이라고 한다. 이 때 사용되는 메커니즘을 Closure mechanism이라고 하며, 네임 해석을 어디서 어떻게 시작할지를 결정한다.
- www.dankook.com - DNS 네임 서버에서 해석을 시작
- /home/dankook/helloworld - 로컬 NFS파일 서버에서 해석을 시작하며, 재귀적인 검색이 가능
- 031-0000-0000 - 전화번호를 다이얼하여 통신 시작
- 222.222.222.2 - 특정 IP주소로 메시지를 라우팅
네임 해석 방법 1: Name Linking
네임 링킹은 다른 네임 컨텍스트에 대한 별칭을 만드는 방식이다. 심볼릭 링크나 하드 링크를 통해 파일 시스템에서 하나의 파일에 대해 여러 경로를 만들 수 있다. 이는 단일 네임스페이스에서 사용된다.
하드 링크는 위에서 설명한 경로 이름과 관련되어 있다. 경로 이름은 네이밍 그래프에서 한 노드에서 다른 노드로 이동하며 특정 경로를 따라 해석되는 이름이다.
소프트(심볼릭) 링크는 노드 N이 다른 노드의 이름을 포함할 수 있다. 먼저 N의 네임에 접근하여 N을 해석한 후, N의 내용을 읽어 다른 노드의 네임을 얻는다. 얻은 네임을 사용해 네임 해석이 진행된다.
네임 해석 방법2: Name Mounting
네임 해석은 마운팅을 통해 서로 다른 네임스페이스를 투명하게 병합하는데 사용할 수 있다.
즉, 한 네임스페이스의 노드 식별자를 현재 네임스페이스의 노드와 연결하는 방식이다.
- 외부 네임스페이스: 접근해야 하는 네임스페이스를 말한다.
- 마운트 포인트: 현재 네임스페이스에서 외부 네임스페이스의 노드 식별자를 포함하고 있는 노드이다.
- 마운팅 포인트: 외부 네임스페이스에서 네임해석을 진행할 지점을 말한다.
Namespace Implementation
네임서비스는 유저와 프로세스가 네임을 추가하고, 지우고, 조회하는 것을 허용하는 서비스다.
네임서비스는 확장성, 긴 수명, 높은 가용성, 장애 격리, 불신의 용인(? 보안이 중요하다는 뜻인 것 같다.) 등의 특성이 구현할 때 중요하다.
네임스페이스를 구현할 때의 고려사항이 있다.
- 바인딩: 분산 시스템은 동적인 특성이 강하므로 시간을 유연하게 설정해야하며, 자주 사용되는 바인딩을 캐시하는 것으로 성능을 최적화 할 수 있다.
- 네임 해석: 가용성과 신뢰성을 위해 서버는 보통 복제되어 운영된다. 아무런 정보도 포함하지 않는 Pure name은 네트워크 크기를 고려하여 신중하게 사용해야한다. 네트워크의 규모가 클수록 네임해석에 더 많은 리소스가 필요하게 된다.
- 일관성: 절대적으로 정확한 결과보다는 접근성이 더 중요하게 여겨진다. 쉽게 말하자면, 시스템이 일단 작동은 해야한다는 것이다.
- 확장성: 네임스페이스 크기에 대한 가정을 하지 말아야한다.
대규모 네임스페이스는 계층적으로 조직된다.
네임스페이스를 논리적 계층으로 분할하여 효과적으로 구현하는 것이다.
- 글로벌 계층: 상위 수준의 디렉터리 노드들로 구성된다. 이 디렉터리 노드는 서로 다른 관리 주체가 공동으로 관리해야한다.
- 관리 계층: 중간 수준의 디렉터리 노드를 포함한다. 디렉터리 노드들은 그룹으로 묶여, 각 그룹이 별도의 관리 주체에 할당된다.
- 운영 계층: 단일 관리 주체 내에서 하위 수준의 디렉터리 노드로 구성된다. 이 계층은 특정 관리 주체 내에서만 관리되는 로컬 네임스페이스를 나타낸다. 이러한 디렉터리 노드를 로컬 이름 서버에 효과적으로 매핑해야하는 것이 중요하다.
네임스페이스 관리 관점에서,
- 글로벌 계층: 변경이 드물고 사용자 수가 많다. 하위 계층에서 캐시가 가능하며, 성능은 그다지 중요하지 않다. 글로벌 계층에서 문제가 생기면 전체적으로 문제가 발생하기 때문에, 안정성과 높은 가용성이 중요하다. 이를 위해 레플리케이션이 필요하다.
- 관리 계층: 비교적 안정적이지만, 글로벌 계층보다는 더 자주 변경된다. 가용성과 성능은 글로벌 계층과 유사하다.
- 운영 계층: 자주 변경되며, 접근 빈도가 높다. 가용성 요구사항은 낮지만, 즉각적인 응답이 요구된다.
Example: DNS
DNS는 호스트의 네임 해석을 위해 사용된다.
DNS의 특징은 아래와 같다.
- 조회 시 평균 응답 시간을 짧게 제공하도록 설계되었다. UDP에 기반한 간단한 요청 및 응답 프로토콜을 사용하며, 데이터는 분할・복제・캐시의 조합으로 관리된다.
- 일시적인 불일치가 허용된다. 약간의 불일치를 감수하면서, 빠르고 효율적인 조회를 제공한다.
- 데이터 일관성을 위한 중앙 관리 기관이 존재한다.
DNS 네임스페이스의 구조는, 단일 루트를 가지는 계층적 구조다. 루트를 제외한 각 노드는 정확히 하나의 들어오는 간선을 가진다.
각 노드는 대소문자를 구분하지 않는 알파벳 및 숫자로 라벨링되며, 각 라벨은 최대 63자까지 허용된다. 전체 경로는 최대 255자까지 허용되며, 라벨은 . 으로 구분된다. 네임을 읽을 때는 왼쪽(리프노드)에서 오른쪽(루트 또는 서브트리 루트)으로 읽는다.
도메인 이름은 노드에서 서브트리의 루트까지의 라벨이다. 도메인 이름은 상대적일 수도 있고, 절대적일 수도 있다.
DNS 데이터베이스는 서버의 논리적 네트워크를 통해 분산되어 있고,
DNS의 네이밍 데이터는 영역(Zone)으로 나뉜다. 영역에는 몇가지 정보가 포함되어 있다.
- 해당 도메인 내 네임에 대한 속성 데이터
- 네임 서버의 이름과 주소
- 하위 영역의 네임서버 목록
- 영역 관리 매개변수
서버는 0개 이상의 영역에 대한 데이터를 가질 수 있으며, 영역은 최소한 두 개 이상의 장애 독립적인 권한 있는 서버에 복제되어 있어야한다. 서버는 권한이 없는 영역 파일을 캐시할 수 있으며, 캐시의 유효성은 TTL에 의해 결정된다.
DNS의 네임 해석은 어떻게 이루어질까?
일단, DNS 프로토콜은 UDP/IP가 기반이며 서버의 능력에 따라 재귀, 반복 중 선택을 한다.
또한 하나의 요청 메시지를 보내더라도, 다수의 쿼리가 발생할 수 있다.
반복적 네임 해석은, 클라이언트가 해석을 주도한다. 클라이언트의 자원을 사용하는 것이다.
클라이언트의 네임 해석기는 해석이 완료될 때까지 가능한 많은 네임 서버에 연락을 한다. 각 네임 서버는 부분적인 정보만 가지고 있지만, 네임 해석기의 역할도 가능하다.
위 그림을 예시로 들자면,
클라이언트가 dankook 홈페이지의 ip에 대한 쿼리를 전송했다. 쿼리를 받은 .kr 네임 서버는 ac.kr도메인에 대한 ip주소를 전송해줬으며, 클라이언트의 네임서버가 다시 ac.kr에 쿼리를 전송한다. ac.kr 네임서버 역시 dankook 홈페이지에 대한 ip 주소는 모르지만, 부분적인 정보로 네임을 해석하여 dankook.ac.kr의 ip 주소를 전송해준다. 이렇게 클라이언트의 쿼리 반복으로 ip주소를 얻을 수 있다.
재귀적 네임 해석은, 서버가 해석을 주도한다. 서버의 자원을 사용하는 것이다.
네임서버는 네임 해석이 완료될 때까지 다음 네임 서버로 결과를 전달하고, 서버에는 더 높은 성능이 요구된다.
각 네임 서버는 해석할 수 없었던 네임의 일부에 대해 그 네임서버의 주소를 학습할 수 있고, 이렇게 캐시된 해석 결과는 다음 번에 재사용될 수 있다. 통신 비용을 절감할 수 있는 장점이 있다.
재귀적 네임 해석은 통신 비용을 절감할 수 있다고 했는데, 이에 대해서 알아보자.
DNS 서버들이 클라이언트의 로컬에서 거리가 멀면, 클라이언트와 네임서버가 반복적으로 통신하는 반복적 네임 해석은 당연히 레이턴시가 길어질 수 밖에 없다. 재귀적 네임 해석은 빠른 응답을 받을 수 있지만 그만큼 서버에 걸리는 부하가 크다.
Attribute-based Naming: 속성 기반 네이밍
엔티티를 이름으로 지정하고 조회하는 것보다 속성을 지정하고 조회하는 것이 더 편리하다. 하지만, 속성 네이밍의 조회 연산은 필요한 속성 값과 실제 속성 값을 일치시켜야하기 때문에 비용이 많이 든다.
위에서 설명했던 구조적 네이밍을 지원하는 시스템은 네이밍 시스템이라 하고, 속성 기반 네이밍 시스템은 디렉터리 서비스라고 한다.
디렉터리 서비스에서는 엔티티에 연결된 속성 집합을 사용하여 검색이 가능하다.
예시로, 이메일의 메시지는 발신자, 수신자, 제목 등과 같은 속성을 사용하여 검색할 수 있다.
디렉터리 서비스
디렉터리 서비스는 네임과 속성간의 바인딩 컬렉션을 저장한 후에 속성과 일치하는 항목을 조회한다.
Lightweight Directory Access Protocol(LDAP)를 대표적인 예로 들 수 있으며, LDAP의 각 디렉터리 항목은 (속성, 값)쌍으로 구성되고 조회를 쉽게하기 위해 고유한 이름이 지정된다.
LDAP에서 모든 디렉터리 항목들의 모임을 디렉터리 정보 베이스(DIB)라고 한다.
디렉터리 정보 트리(DIT)는 LDAP의 네이밍 그래프를 나타내며, 각 노드는 하나의 디렉터리 항목을 나타낸다.
** 대학교 수업을 듣고 이해한 부분을 최대한 풀어서 작성한 글입니다.
틀린 정보가 존재할 수 있으며, 언제나 피드백은 환영입니다. **
'DKU > 분산처리' 카테고리의 다른 글
| Distributed System 11 (0) | 2024.11.05 |
|---|---|
| Distributed System 10 (1) | 2024.10.17 |
| Distributed System 8 (7) | 2024.10.07 |
| Distributed System 7 (2) | 2024.09.30 |
| Distributed System 6 (0) | 2024.09.30 |