A Fog storage software architecture for the Internet of Things
원문: A Fog storage software architecture for the Internet of Things
요약(Abstract)
유럽의 Think Tank IDATE Digiworld 은 2030년 350억 장치가 연결될 것으로 예측했다. 이러한 물결은 data, application 및 service 의 폭발적인 성장을 동반할 것이다. 따라서 low latency, mobility (사용자, infrastructure) 및 네트워크 파티셔닝을 지원하는 Fog architecture를 제안하는 것이 매우 시급하다. 이 논문은 확장성과 성능을 모두 허용하는 object store system 과 확장형 NAS (Network Attached Storage) 를 결합하는 아키텍처를 설명한다. 또한 복제 관리를 위한 DNS (Domain Name Service) 에서 영감을 받은 새로운 프로토콜을 제안한다. 마지막으로 Fog Storage, CDN (Content Delivery Networks) 및 NDN (Named Data Networking) 간의 개념에 대해 설명한다. 또한 프랑스 클러스터인 Grid’5000에 대한 실험 평가가 포함된다.
1. Introduction
2012년 시스코에서 제안한 Fog 인프라는 네트워크 edge에 지리적으로 분산된 마이크로 나노 데이터 센터를 배포하는 것으로 구성된다. 각 소규모 데이터 센터는 Fog 사이트로 볼 수 있으며, low latency 기반의 컴퓨팅 및 스토리지 리소스를 제공하는 소수의 서버만 호스팅한다. IoT는 거리 및 전력 관점에서 계층적 토폴로지를 따른다: 클라우드는 네트워크 대기시간 측면에서 가장 긴 대기시간을 가지고 있으면서 가장 큰 컴퓨팅 및 스토리지 기능을 제공한다. Edge 장치는 로컬 컴퓨팅 및 스토리지 리소스의 장점을 가지고 있지만 클라우드에 비해 제한적이다. Fog 사이트는 IT 리소스의 거리와 전력 간의 균형을 제공하는 중간 시설로 볼 수 있다. 또한 Fog 사이트는 사용자 장치와 클라우드 컴퓨팅 센터간 요구를 충족시키기 위해 상호 보완적이다. 프로세싱 및 저장 측면에서 Fog 사이트는 수명이 며칠인 오퍼레이션 데이터를 처리하고 저장하도록 설계되었으며 클라우드 인프라는 몇 달 동안 히스토리를 저장하도록 설계되었다. 즉, 아키텍처는 수직 (클라우드~Edge) 과 수평 (Fog 사이) 을 골고루 갖추고 있다. 이렇게 분산 된 인프라는 대규모 병령 IoT 데이터 스트림을 지원하는데 필요하다. 가장 큰 문제는 어떤 종류의 분산 소프트웨어가 이러한 인프라를 관리하고 무엇을 할 수 있을까?
많은 use cases 가 Fog 인프라의 장점을 누릴 수 있다. 예를들어 Bonomi 등은 connected vehicles 에서 Fog 컴퓨팅을 사용할 것을 제안한다. Fog 는 Thing 으로 부터 메트릭을 수집하고 보행자가 도로에 감지되면 특정 지역의 차량을 정지하는 결정을 내릴 수 있다. 또 다른 use cases 는 Network Function이 사용자의 이동을 따라 움직일 수 있도록 Network Virtualization Functions 을 배포하는 것이다. 이것은 이동 중에 사용자 데이터에 대한 low latency 액세스를 제공하기 위해 버스나 기차에 내장된 Fog 사이트를 이용할 수 있도록 확장되어야 한다. 마지막으로 Fog 컴퓨팅은 인더스트리 4.0에서 사용할 수 있어야 한다. 많은 센서가 데이터를 Fog에 업로드 한 다음 많은 사용자가 이를 처리한다.
그림 1은 이러한 계층 구조와 use cases 일부를 표현하고 있다. 각 사이트는 스토리지 및 컴퓨팅을 제공하는 제한된 서버를 호스팅한다. 최종 사용자 장치 (스마트폰, 테블릿, 랩톱 등) 와 IoT 장치 (센서, 스마트 빌딩 등) 는 10ms (무선 링크 latency) 보다 짧은 low latency (LFog) 로 Fog 사이트에 도달할 수 있다. Fog 사이트 (LCore) 간의 latency 시간은 50ms (Wide Area Network link 의 평균 latency) 이다. 클라이언트에서 클라우드 플랫폼 (LCloud) 에 도달하는 latency 시간은 더 높으며 (약 200ms) 예측할 수 없다. 이 논문에서는 데이터 저장이 처리의 전제 조건이라고 주장한다. 따라서 엄청난 수의 IoT 장치에서 생성되는 방대한 양의 데이터를 처리하려면 Fog 계층에 배포 된 효율적인 스토리지 솔루션이 필요하다. 그러나 다중 사이트 및 low latency 에서 동작하도록 설계된 단일 스토리지 솔루션은 현재 존재하지 않으며 이것이 목표이다.
+----------------+ [Cloud Computing]
|Domestic Network|-----------+ | +-----------+
+--------+-------+ | Cloud Latency +-----|Edge Device|
| +--------+ = 200ms +--------+ | +-----------+
| |Fog site|----------+ | +----------|Fog site|-----+-----|Edge Device|
| +--------+ | | | +--------+ | +-----------+
+--------+---------+ | | | | +-----|Edge Device|
|Enterprise Network|---------+ | | | +-----------+
+------------------+ +-----------------------+ Edge to Fog latency
|Inter Micro DCs latency| [10-100ms]
+-----------+ | [50ms~100ms] |
|Edge Device|----------------+ +-----------------------+
+-----------+ | | |
+--------+ | | +--------+
|Mobile |----------+ +----------|Micro |
|Fog site| | Nano DC|
+--------+ +--------+
+-----------+ | Site of Fog Computing
|Edge Device|----------------+
+-----------+
<Extreme Edge Frontier> | <Edge Frontier> <Edge Frontier>
이 논문의 목표를 위해 첫번째로 이러한 네트워크에서 데이터를 찾기위한 기존 전략의 장점과 단점을 제시한다. 둘째로 로컬에 저장된 데이터를 보다 효율적으로 찾을 수 있는 로컬 Scale-Out NAS 를 추가하여 기존의 스토리지 솔루션을 개션한다. 마지막으로 분산 네트워크에서 데이터를 효율적으로 찾을 수 있는 새로운 프로토콜을 제안한다. 특히 데이터 (미디어) 가 네트워크 edge 에서 생성되고 다른 사이트와 공유되는 Content Delivery Network 의 시나리오에 중점을 둔다. 이러한 use cases 의 주요 관점은 데이터가 수정되지 않기 때문에 복제는 static replicas 라는 것이다. 이 특성은 consistency 을 고려하지 않을 수 있다는 것이다.
다음 장에서 Fog 인프라에 이상적인 스토리지 솔루션이 무엇인지 알아보고 클라우드 아키텍처 용으로 개발된 기존 솔루션을 사용할 수 없는 이유를 알아보고 개선하기 위한 솔루션을 제시한다.
2. Distributed storage for the Fog: an overview
Fog 인프라 기반으로 설계된 이상적인 스토리지 솔루션에서 기대하는 속성을 소개한다.
2.1. Properties for an object store working in a Fog environment
- 목표: 대량의 데이터와 많은 액세스를 병렬로 처리할 수 있는 Fog 스토리지
- 각 사용자와 IoT 장치는 모든 오브젝트에 효율적으로 액세스할 수 있어야 함
이상적인 스토리지가 충족할 5가지 속성은 다음과 같다.
- Data locality:
- 액세스 시간을 줄이기 위해 사용자와 가장 가까운 사이트에 데이터를 작성(low latency)해야 함
- 읽기 데이터는 리모트 액세스가 금지된 사이트에 있어야 함
- 높은 서비스 품질외에도 예상할 수 있는 결과는 개인 정보 보호 및 지속성
- Data availability:
- 스토리지 노드는 신뢰할 수 없는 링크로 연결되며 수 많은 사이트에 분산
- 이상적인 스토리지는 내결함성 (fault tolerant) 이 있어야 함
- 격리 오류 (isolated failures) 는 발생하는 사이트 내에서 관리해야 하며 연결할 수 없는 (unreachable site) 사이트는 다른 사이트에 영향을 주지 않아야 함
- 예) 버스나 기차에 포함된 모바일 Fog 사이트
- Network containment:
- 네트워크 억제 (network containment) 는 네트워크 트래픽을 제한하는 것으로 구성
- 이 속성은 다음과 같은 세가지 측면이 있음
- 첫째: 사용자 액션만 사이트간에 교환되는 네트워크 트래픽을 생성하여야 함
- 둘째: 사이트에 대한 액세스가 다른 사이트의 성능에 영향을 주지 않아야 함, 사이트가 다른 사이트보다 더 많이 요청될 때 다른 사이트는 성능 저하가 없어야 함
- 셋째: 사용자가 연결된 사이트에 저장되지 않은 데이터에 액세스하기 전에 데이터를 찾아야 함, 그럼에도 불구하고 참여하지 않는 사이트는 연결하지 않아야 함
- 이러한 맥락에서, 물리 토폴로지를 고려하여야 함
- low latency 링크를 통해 연결된 가까운 사이트간 교환이 선호되어야 함
- 예) 직장과 집 사이에 문서를 공유하는 경우 이 두 위치 사이의 도로에 있는 Fog 사이트만 요청하여야 함
- Disconnected mode:
- 네트워크 장애로 인해 다른 사이트에 접속할 수 없을 때 사이트에 로컬로 저장된 데이터에 액세스하는 기능은 필수 속성
- 사이트는 가능한 독립적 구성이 되어야 함
- 예) 모바일 Fog 사이트에 연결된 사용자는 네트워크 파티셔닝의 경우에도 데이터 액세스가 가능하여야 함
- Mobility support:
- 사용자는 이동성을 지니고 있으며 항상 low latency 시간으로 연결할 수 있는 사이트에 연결됨
- 요청된 데이터가 로컬 사이트에 저장되지 않은 경우 데이터를 다운로드하며 현재 사이트에 캐시하여 향후 액세스 성능을 향상시키고 예측 가능한 액세스를 수행함
- Scalability:
- Fog 아키텍처를 위한 이상적인 스토리지는 많은 사이트와 클라이언트로 확장가능 하여야 함
결론적으로, 이러한 특성은 Brewer 정리를 염두에 두고 이해할 수 있다. Brewer 정리는 일관성, 데이터 가용성 (예: 클라이언트가 제한 시간내에 응답을 받음) 및 네트워크 파티셔닝을 동시에 지원할 수 없음을 알수있다. 데이터 가용성 (availability) 및 disconnected mode 는 이상적 스토리지를 위해 원하는 속성 목록이 있기 때문에 일관성 (consistency) 은 네트워크 파티셔닝의 경우 항상 충족할 수 있는 속성이 아니다. 이러한 이유로 모든 데이터를 불변 (immutable) 으로 간주하고 모든 복제본을 정적 (static) 으로 간주한다. 즉, 액세스 패턴은 write-only, read-many 이다.
2.2. From Cloud storage solutions to Fog: the metadata management challenge
Fog 노드는 지리적으로 분산되어 있기 때문에 스토리지는 이러한 환경에서 동작하기 위하여 가장 중요한 것은 데이터를 찾는 것이다.
전통적인 분산 파일 시스템은 중앙 집중식 메타데이터 서버에 의존한다. 아래 그림과 같이 클라이언트는 먼저 메타데이터 서버에 연결하여 데이터를 찾은 다음 복제본을 저장하는 노드에 전달한다. 이 접근 방식은 PVFS, Luster 와 같은 HPC (High Performance Computing) 또는 RozoFS 와 같은 IO 집약적 Scale-Out NAS 에 사용된다.
########## [sequence diagram showing how a client can access a data in a traditional distributed storage solution] ##########
+------+ +---------------+ +---------------+ +---------------+ +---------------+
|client| |metadata server| |storage server1| |storage server2| |storage server3|
+------+ +---------------+ +---------------+ +---------------+ +---------------+
| | | | |
| where is | | | |
| {data identifier}? | | | |
|------------------->| | | |
| on "server2" | | | |
|<-------------------| | | |
| | | | |
| read {data identifier} | |
|-------------------------------------------------------->| |
| data = "mydata" | |
|<--------------------------------------------------------| |
그럼에도 불구하고 이러한 접근은 많은 수의 스토리지 노드와 엄청난 워크로드를 동반하는 대규모 배포에 필요한 확장성을 제공할 수 없으며 중앙 집중식 메타데이터 서버가 로컬 사리트에 없는 분산 환경에서 동작할 수 없다. 이러한 문제를 극복하기 위해 오브젝트 스토리지는 각 데이터가 단순히 이름과 연결되는 플랫 네임스페이스 (flat namespace) 가 필요하다. 이렇게 하면 디렉토리가 없기 때문에 저장하고 액세스할 메타데이터의 양이 줄어든다. 결과적으로 중앙 집중식 메타데이터 서버는 요청이 적고 확장성이 좋지만 DHT 와 같은 성능이 떨어지는 메커니즘으로 대체된다.
2.2.1. Approaches to locate data in a distributed manner
모든 스토리지의 주요 기능인 분산 방식으로 데이터를 찾는 접근 방법을 제시한다. Fog 스토리지에 대한 2.1 섹션의 5가지 속성을 위치 프로세스 (location process) 를 기반한 5개의 속성을 제안한다.
- (i) Access time 은 위치 기록이 사용자와 얼마나 가까운지 평가함. 위치 기록에 대한 “data locality” 속성의 확장임
- (ii) 사이트를 추가하거나 제거하는 동안 발생하는 네트워크 트래픽 양
- (iii) 네트워크 토폴로지에 대한 지식 은 위치 접근 방식이 확장 가능하고 사이트 자체의 이동성에 대한 반응을 평가함
- (iv) 오프젝트를 찾기위한 네트워크 트래픽 양 은 위의 “network containment” 속성과 연관이 있음
- (v) 최소 중복성 (minimal redundancy) 은 속성 ““에 해당함. 모든 노드에서 위치 정보를 복제해야 하는 접근 방식은 확장에 문제가 있음
데이터를 찾는데 일반적으로 사용되는 6가지 소프트웨어 솔루션을 다음과 같이 평가하였다: 중앙 집중식 메타데이터 서버, flooding, gossip, hash function, DHT, one-hop DHT. 아래 그림은 다이어그램에서 이런 분석을 보여준다.
Centralised metadata server: 중앙 집중식 메타데이터 서버는 확장되지 않으며 오브젝트를 찾기위해 원격 사이트를 사용하는 것은 액세스 시간에 큰 영향을 미친다. 이 접근 방식의 장점은 모든 노드가 전체 네트워크 토콜로지가 아닌 오브젝트를 찾을 수 있는 메타데이터 서버의 주소만 알면 된다는 것이다. 중앙 집중식 메타데이터 서버가 영향을 받지 않는한 네트워크 토폴로지 변경을 지원한다.
Flooding: 이 방식은 오브젝트 위치를 저장할 필요가 없다. 각 노드는 오브젝트의 요청이 오브젝트를 저장하는 노드에 도달할 때까지 이웃에 전달한다. 루프를 방지하기 위해 요청은 TTL (Time-To-Live) 에 연결된다. 이 접근법의 장점은 모든 노드가 네트워크 토폴로지를 알 필요가 없다는 것이다. 또한 네트워크 토폴로지를 모르기 때문에 교란 (churn) 을 지원한다. 그러나 이 접근법의 단점은 요청된 오브젝트에 도달하는데 시간을 예상할 수 없으며 생성된 네트워크 트래픽의 엄청난 오버헤드가 있다는 것이다. 많은 노드들이 저장하지 않은 오브젝트에 대한 요청을 받는다. 또한 기존 오브젝트를 찾은데 성공할 것이라는 보장도 없다.
Gossip: 이 방식은 각 노드가 임의의 이웃을 선택하고 오브젝트 위치에 대한 모든 정보를 전송하는 방식이다. 이 작업을 정기적으로 반복하여 각 노드는 모든 오브젝트의 위치를 파악한다. 결과적으로 모든 노드는 모든 오브젝트의 위치를 저장한다. 즉, 위치 정보가 네트워크를 통해 전파된다. 위치가 모든 노드로 전파되면 네트워크에서 아무런 연결없이 모든 오브젝트를 찾을 수 있다. 또한 노드가 전체 네트워크 토폴로지를 알 필요가 없으며 인접 항목만 알고 있으면 된다. 이러한 제한된 지식으로 인하여 많은 새로운 정보를 전파하지 않고 이탈 (chrun) 관리를 수행할 수 있다. 그럼에도 불구하고 가장 큰 단점은 각 오브젝트의 위치가 모든 노드에 저장되어 스토리지 비용이 증가한다는 것이다. 또한 추가 교환없이 데이터를 찾을 수 있도록 하기전에 모든 노드에 있는 모든 데이터의 위치 기록을 전파하기 위해 엄청난 네트워크 트래픽을 고려해야 한다. 실제로 필요할 때 네트워크 트래픽을 생성하지 않고 미리 생성한다. 이것이 백그라운드 트래픽을 데이터를 찾는데 필요한 네트워크 트래픽으로 고려하여야 하는 이유이다.
Hash function: 오브젝트 이름에 해시 함수를 적용하는 것은 또 다른 방법이다. 이를 통하여 네트워크에 요청하지 않고 모든 오브젝트를 찾을 수 있다. 이 방법의 장점은 네트워크 교환없이 매우 빠르게 위치를 찾을 수 있다는 것이다. 그러나 단점은 특정 데이터를 저장할 위치를 명시적으로 선택하지 않는 것이다. 또한 각 노드는 해시 함수로 계산된 값에서 노드 주소를 연관시킬 수 있도록 네트워크의 전체 토폴로지를 알아야 한다. 또한 네트워크 토폴로지가 변경될 때 해시 값고 노드간의 기존 매핑을 사용할 수 없게 된다. 따라서 네트워크에서 노드가 이탈 (churn) 된 경우 오브젝트를 이동해야 한다. 일관성있는 해싱은 이탈시 이동할 오브젝트 수를 최소화한다.
Distributed Hash Table: DHT 는 오브젝트를 찾기위해 생성된 네트워크 트래픽의 양과 각 노드의 토폴로지 지식 사이의 균형을 제공한다. 각 키 (key) 는 키에서 계산된 해시 값 바로 뒤에 있는 식별자와 함께 노드에 저장된다. 라우팅 테이블은 각 노드가 로그 갯수의 이웃을 알고 로그 갯수의 홉으로 모든 키에 도달할 수 있도록 계산된다. 이 방법의 장점은 오브젝트를 찾는데 필요한 네트워크 교환과 각 노드가 가지고 있는 토폴로지 지식의 양 사이에 적절한 균형을 유지한다는 것이다. 또한 DHT 는 최소한의 오브젝트를 이동하여 이탈을 가능하게 한다. 그러나 단점은 사용자가 데이터를 저장할 위치를 선택할 수 없다는 것이다.
One-Hop Distributed Hash Table: hash function 과 gossip 방식의 혼합이다. gossip 프로토콜을 사용하여 각 오브젝트의 위치를 보내는 대신 네트워크 토폴로지를 모든 노드로 전파한다. 각 노드는 자신이 담당하는 키 범위의 이웃에게 보내고 네트워크의 모든 노드에 대헤 이러한 값을 포함하는 테이블을 작성한다. 그런 다음 오브젝트를 찾기 위해 이름의 해시를 계산한 다음 해시 값을 포함하는 키 범위를 담당하는 노드에 전달된다. 네트워크 토폴로지가 모든 노드에 gossip 을 사용하면 위치 프로세스는 hash function 의 장점과 비슷하다. 그러나 단점은 위치가 모든 노드에 복제되어 저장공간 사용 측면에 비용이 많이 발생한다는 것이다.
위치 기록을 저장하는 가장 좋은 방법은 액세스 시간에 영향을 주지 않으며, 오브젝트가 위치할 때 및 네트워크에서 사이트가 추가 또는 제거될 때 네트워크 트래픽을 교환하는 방식이다. 따라서 각 노드가 각 오브젝트 위치를 저장하고 전체 토폴로지를 알 필요가 없는 것이 가장 좋은 방법이다.
2.2.2. Existing Cloud storage solutions
이 섹션은 기존 클라우드 인프라의 오브젝트 저장소를 제시하고 Fog 환경에 적용 평가를 제안한다.
특히 데이터를 찾기 위해 이전 섹션 (섹션 2.2.1) 에서 제시한 메커니즘에 의존하는 Rados, Cassandra, IPFS 에 중점을 둔다.
Rados: Rados 는 CRUSH 라는 hashing function 을 사용하여 데이터를 찾는다. 선출된 노드는 네트워크 토폴로지를 설명하는 맵과 모든 스토리지 노드 및 클라이언트에 대한 배치 제한 사항을 배포하는 역할을 한다. 이후 각 노드는 네트워크 교환없이 각 오브젝트의 위치를 로컬로 계산할 수 있다. Rados 주요 장점은 hash function 으로 네트워크 트래픽을 포함하지만 Paxos 프로토콜을 사용하여 모든 노드에 네트워크 토폴로지 설명을 배포하기 때문에 네트워크 파티셔닝이 동작하지 않는다. 또한 기존에 저장된 데이터를 이동하는 것이 쉽지 않기 때문에 이동성에 대한 지원이 제한된다.
Cassandra: Facebook 에서 개발한 것으로 gossip 과 hash function 을 활용하는 ‘one-hop DHT’ 를 사용한다. Cassandra 에서 각 노드는 네트워크 토폴로지에 대한 지식을 보내기 위해 무작위로 선택된 다른 노드에 주기적으로 연결한다. 이후 Rados 와 같이 다른 요청없이 각 노드에서 오브젝트를 찾을 수 있다. Rados 와 차이점은 토폴로지를 설명하는 맵이 노드에 분산되는 방식이다. Cassandra 의 장단점은 Rados 와 동일하지만 토폴로지 설명을 배포하기 위해 Paxos 프로토콜을 사용하지 않으므로 Brewer 정리에 따라 네트워크 파티셔닝을 사용할 수 있다.
IPFS: BitTorrent 프로토콜을 사용하여 노드간 데이터를 교환하고 Kademlia DHT 를 통해 오브젝트 복제본을 저장하는 노드를 찾는 오브젝트 저장소이다. 장점은 각 노드가 네트워크 토폴로지에 대한 제한된 지식을 가지고 있기 때문에 요청된 노드에 복제본은 생성하는 것으로 네트워크 파티셔닝을 지원한다. 그러나 단점은 불변 (immutable) 오브젝트를 사용하는 것이다. 이것은 오브젝트는 수정될 수 없음을 의미하며 DHT 가 네트워크 트래을 포함하지 않는다.
아래 표에 위 내용을 요약하였다. 대부분 엄청난 숫자의 서버를 대상으로 높은 대기시간과 이기종 네트워크 링크로 연결된 다중 사이트 환경에서 작동하는 것을 염두하지 않고 설계되었다. 일부 분산 파일시스템인 XtreemFS, GFarm, GlobalFS 등과 같은 WAN 링크와 상호 연결된 다중 사이트 환경을 지원하는 것이 있지만 오브젝트 스토리지가 아닌 파일 시스템인 관계로 중앙 집중식 접근 방식에 의존하기 때문에 Fog 에서 기대하는 성능을 나타내지 않는다.
########## summary of the advantages and disadvantages of the presented storage solutions ##########
| 제안 (Purpose) | 장점 (Advantages) | 단점 (Disadvantage) | |
|---|---|---|---|
| Rados | - CRUSH hash function 과 Paxos 프로토콜에 의존하는 오브젝트 스토리지 | - 네트워크 교환 없이 데이터 탐색 (CRUSH) | - (Paxos 프로토콜) 네트워크 파티셔닝이 동작하지 않음 - 확장이 어려움 (Paxos 프로토콜)</br> - 저장된 데이터 이동의 어려움</br> |
| Cassandra | - hash function 및 gossip 프로토콜에 의존하는 Key/Value store | - 네트워크 교환없이 데이터 배치 - (gossip) 네트워크 파티셔닝 가능</br> |
- 저장된 데이터 이동이 어려움 |
| IPFS | - BitTorrent 프로토콜 및 DHT 에 의존하는 P2P 오브젝트 저장소 | - 데이터를 새 위치로 자동 재배치: 액세스 시간 개션 - 네트워크 파티셔닝 가능</br> |
- DHT 는 네트워크 트래픽을 포함하지 않음 - immutable 오브젝트 활용</br> |
2.3. How existing solutions fit the properties
스토리지 솔루션을 처음부터 개발하지 않기 위해 Fog 인프라를 도입 (Rados, Cassandra, IPFS) 한 오브젝트 저장소를 배포하고 성능과 Fog 스토리지에 대한 평가를 진행하였다. 아래 표를 보면 기존 해결책이 Fog 스토리지의 속성을 충족하지 않는다는 것을 알 수 있다. Rados 는 Paxos 알고리즘을 사용하면 서비스 파티셔닝의 경우 데이터를 사용할 수 없게되고 Cassandra 의 경우 사용자가 이동하는 사이트에 저장된 오브젝트를 이동하여 액세스 시간을 늘리는 유연성이 부족하다. IPFS 는 배치 전략이 없기 때문에 기본 이동성만 제공한다. 클라이언트는 원하는 위치에 쓰고 오브젝트 저장소는 각 데이터 오브젝트가 기록된 위치를 추적한다.
########## summary of Fog characteristics a priori met for 3 different object stores ##########
| Rados | Cassandra | IPFS | |
|---|---|---|---|
| Data locality | Yes | Yes | Yes |
| Network containment | Yes | Yes | No |
| Disconnected mode | No | Yes | Partially |
| Mobility support | Partially | Partially | Natively |
| Scalability | No | Yes | Yes |
결과적으로 IPFS 오브젝트 저장소를 활용할 것을 제안하고 모든 속성이 충족될 수 있도록 Fog 환경에서 동작을 위한 수정사항을 제안한다. 이동성 지원은 스토리지 핵심에서 배치 전략을 수정하지 않고 추가할 수 없는 필수 속성이기 때문에 IPFS 로 시작하기로 결정하였다.
3. Designing a scalable and efficient Fog Layer
Fog 에서 사이트간 네트워크 교환은 비용이 많이 소요된다. 액세스 시간을 줄이는 것뿐만 아니라 (네트워크 파티셔닝으로 인한 무한 지연이 발생한 극단적인 경우) 네트워크 지연이 큰 환경에서 시스템이 동작할 수 있도록 하여야 한다.
다음 섹션에서 IPFS 오브젝트 스토리지를 Fog 환경에 적용하는 것을 중점적으로 살펴본다. 섹션 3.1 에 제시한 첫번째 수정은 사용자가 로컬로 저장된 오브젝트에 접근하는 동안 네트워크를 억제하는 것이다. 이를 위해 IPFS 를 Scale-out NAS 와 결합할 것을 제안한다.
두번째 수정은 데이터 저장 프로세스에서 네트워크 트래픽을 포함하도록 물리적 네트워크 토폴로지를 매핑하는 트리에 오브젝트의 위치를 저장하는 것으로 구성된다. 이것은 섹션 3.2 에서 다룬다.
3.1. Reduction of inter-sites network traffic for locally stored data
IPFS 가 오브젝트를 찾기 위하여 사용하는 DHT 가 네트워크 트래픽을 포함할 수 없는 이유를 설명한다. 둘째로 사용자가 사이트간 네트워크 요청을 보내지 않고도 연결된 사이트에 로컬로 저장된 오브젝트에 액세스할 수 있도록 IPFS 를 Scale-Out NAS 와 결합하는 방식을 설명한다.
3.1.1. Problem description
DHT 제한을 이해하기 위해 IPFS 에서 관찰한 네트워크 교환을 설명한다.
신규 오브젝트 생성: 클라이언트는 가장 가까운 사이트에 있는 모든 노드 (네트워크 대기 시간 측면) 로 오브젝트를 보냄. 오브젝트는 로컬에 저장되고 각 오브젝트 위치를 저장하는 DHT 가 업데이트 됨. DHT 는 지역성을 제공하지 않기 때문에 오브젝트 위치를 네트워크의 모든 노드에 저장할 수 있다. 아래 그림에서 site2 에 있는 노드3은 site1 에 기록된 오브젝트의 위치를 저장한다. 이 노드는 오브젝트 식별자에 대한 hash function 으로 결정됨.
########## [writing of an object] ##########
[############### <site1> ###############] [## <site2> ##]
+------+ +----------+ +----------+ +----------+
|client| |IPFS node1| |IPFS node2| |IPFS node3|
+------+ +----------+ +----------+ +----------+
| | |
| put | |
{object idenrifuer}= |
| "data" | |
|----------->| |
| |---+ |
| | | |
| store objceet |
| | | |
| |<--+ |
| | |
| | add locatino in DHT: |
| | "{object identifier} in IPFS node1" |
| |------------------------------------>|
클라리언트가 로컬에 저장된 오브젝트를 읽을때: 노드가 특정 오브젝트에 대한 요청을 수신할 때 마다 오브젝트가 하드 드라이브에 저장되지 않았는지 확인함. 그렇지 않은 경우 i) 오브젝트 이름에 따라 해시 계산, ii) 위치를 저장하는 노드 연결, iii) BitTorrent 와 같은 프로토콜을 통해 오브젝트 다운로드, iv) 로컬 오브젝트가 클라이언트로 전달되는 동안 복제본 생성, v) DHT 가 새 복제본의 존재를 반영하도록 업데이트
########## [reading of an object stored on the local site] ##########
[############### <site1> ###############] [## <site2> ##]
+------+ +----------+ +----------+ +----------+
|client| |IPFS node1| |IPFS node2| |IPFS node3|
+------+ +----------+ +----------+ +----------+
| | | |
get: {object identifire} | |
|----------->| | |
| |---+ | |
| | | | |
| read object | |
| | | | |
| |<--+ | |
object="data" | |
|<-----------| | |
| | | |
| get {object identifier} | |
|----------------------------->| DHT:local |
| | |{object identifier}|
| | |------------------>|
| | | in IPFS node1 |
| | |<------------------|
| | get/read | |
| {object identifier} |
| |<----------------| |
| | object="data" | |
| |---------------->| |
| | | |
| object="data" | |
|<-----------------------------| |
| | |---+ |
| | | | |
| | store object |
| | | | |
| | |<--+ |
| | | |
| | DHT: add '{object identifier}
| | | in IPFS node2' |
| | |------------------>|
원격 사이트에서 오브젝트를 요청할 때 프로토콜: 클라이언트가 한 사이트에서 다른 사이트로 이동하는 경우에 사용된다. 우리는 모든 상황에서 클라이언트가 가장 가까운 사이트에 있는 노드 (네트워크 대기 시간 측면) 에 접속한다는 것을 정확하게 알고 있음. 즉, IPFS 더 구체적으로 사용하는 DHT 는 Fog 의 물리적 토폴로지를 고려하지 않음. 각 서버는 동일 사이트에 있는 컴퓨터 클러스터의 일부가 아니라 독립적인 것으로 간주됨 (아래 그림의 첫번째). 사용자 또는 재배치 프로세스에 의해 새 오브젝트 복제본이 만들어지면 사이트의 다른 IPFS 노드는 새 복제본의 존재를 알리지 않고 DHT 를 사용하여 찾음 (아래 그림의 두번째). 오브젝트가 site3 의 노드4 에서 이미 사용 가능하지만 노드5 는 DHT 에 연결하여 위치를 찾아야 함.
이것을 볼 때 여기는 두가지 단점이 있다. 첫째, 이런 프로세스는 사이트간 액세스 시간과 네트워크 트래픽을 증가시킨다. 둘째, 클라이언트는 오브젝트의 위치를 찾을 수 없기 때문에 사이트가 다른 사이트와 연결이 끊어지면 (네트워크 파티셔닝) 사이트에 저장된 모든 오브젝트에 액세스 할 수 없다. IPFS 는 BitTorrent 프로토콜을 사용하여 데이터에 액세스하는 방법을 제공하지만 Fog 컴퓨팅의 특수성을 고려하지 않는다.
########## [reading of an object stored on a remote site (by requesting a local node: IPFS node4 or IPFS node5)] ##########
[####### <site1> #######] [## <site2> ##] [########### <site3> ###########]
+----------++----------+ +----------+ +----------++----------++------+
|IPFS node1||IPFS node2| |IPFS node3| |IPFS node4||IPFS node5||client|
+----------++----------+ +----------+ +----------++----------++------+
| | | | | |
| | | get {object identifier}
| | | DHT: local |<--------------------|
| | {object identifier} | |
| | |<---------------| | |
| | in IPFS node1 & 2 | |
| | |--------------->| | |
| get/read {object identifier} | | |
|<--------------------------------------------| | |
| object="data" | | |
|-------------------------------------------->| | |
| | get/read {object identifier} | | |
| |<--------------------------------| | |
| | object="data" | | |
| |-------------------------------->| object="data" |
| | | |-------------------->|
| | | | | |
| | | |---+ | |
| | | | | | |
| | | store object | |
| | | DHT: add | | | |
| | "{object identifier} |<--+ | |
| | in IPFS node4" | | |
| | |<---------------| | |
[####### <site1> #######] [## <site2> ##] [########### <site3> ###########]
+----------++----------+ +----------+ +----------++----------++------+
|IPFS node1||IPFS node2| |IPFS node3| |IPFS node4||IPFS node5||client|
+----------++----------+ +----------+ +----------++----------++------+
| | | | | |
| | | | get {object identifier}
| | | | |<--------|
| | DHT: locate {object identifier} |
| | |<---------------------------| |
| | | in IPFS node1, 2 & 4 | |
| | |--------------------------->| |
| get/read {object identifier} | |
|<--------------------------------------------------------| |
| object="data" | |
|-------------------------------------------------------->| |
| | get/read {object identifier} | |
| |<--------------------------------------------| |
| | object="data" | |
| |-------------------------------------------->| |
| | | get/read {object identifier} |
| | | |<---------| |
| | | object="data" |
| | | |--------->| |
| | | | object="data"
| | | | |-------->|
| | | | |---+ |
| | | | | | |
| | | DHT: add store object |
| | | "{object identifier} | | |
| | | in IPFS node5 |<--+ |
| | |<--------------------------| |
3.1.2. A Fog storage software architecture
Fog 컴퓨팅 환경에서 IPFS 를 적용하기 위해 Scale-Out NAS 와 같은 각 사이트에 독립적으로 분산 파일 시스템을 배포할 것을 제안한다. 이러한 Scale-Out NAS 는 아래 그림과 같이 사이트의 모든 IPFS 노드에 대한 기본 스토리지 솔루션으로 사용된다. 이 접근법을 사용하면 IPFS 노드가 사이트의 다른 노드에서 저장한 모든 오브젝트에 액세스할 수 있으며 소스 코드를 거의 수정하지 않아도 된다. 이러한 결합은 각 IPFS 노드가 각 오브젝트를 파일에 내부적으로 저장하기 때문에 가능하다. 로컬 파일 시스템의 파일에 액세스하는 대신 IPFS 는 Scale-Out NAS 에서 제공하는 분산 파일 시스템에 액세스한다.
########## [The Fog software architecture combining an object store (IPFS) and a Scale-Out NAS (like RozoFS)] ##########
+--[site1]-----------------------------------+
| |
| +--------[scale-out NAS]-----------------+ |
| | metadata | |
| |+--------++--------++--------++--------+| |
| ||storage1||storage2||storage3||storage4|| |
| |+--------++--------++--------++--------+| |
| | | |
| +--------[object store]------------------+ |
| |+--------++--------++--------++--------+| |
| || node1 || node2 || node3 || node4 || |
| |+--------++--------++--------++--------+| |
| +----------------------------------------+ |
| client |
+--------------------------------------------+
|
|
+---------------------------+----------------------------+
| |
+--[site2]-----------------------------------+ +--[site3]-----------------------------------+
| | | |
| +--------[scale-out NAS]-----------------+ | | +--------[scale-out NAS]-----------------+ |
| | metadata | | | | metadata | |
| |+--------++--------++--------++--------+| | | |+--------++--------++--------++--------+| |
| ||storage1||storage2||storage3||storage4|| | | ||storage1||storage2||storage3||storage4|| |
| |+--------++--------++--------++--------+| | | |+--------++--------++--------++--------+| |
| | | | | | | |
| +--------[object store]------------------+ | | +--------[object store]------------------+ |
| |+--------++--------++--------++--------+| | | |+--------++--------++--------++--------+| |
| || node1 || node2 || node3 || node4 || | | || node1 || node2 || node3 || node4 || |
| |+--------++--------++--------++--------+| | | |+--------++--------++--------++--------+| |
| +----------------------------------------+ | | +----------------------------------------+ |
| client | | client |
+--------------------------------------------+ +--------------------------------------------+
오브젝트 저장소를 Scale-Out NAS 와 결합하는 것은 새로운 아이디어가 아니며 이미 많은 제안이 되어있다. 예를들어 Yahoo 는 HDFS (Hadoop Filesystem) 와 같은 다양한 파일 시스템에 의존하는 오브젝트 저장소인 Wlanut 을 개발했다. 그러나 기본 Scale-Out NAS 가 전역 파일 시스템이 아니라 각 사이트에 로컬인 분산 파일 시스템이기 때문에 제안하는 접근 방법이 다르다. IPFS 는 다른 사이트를 통해 전역 네임 스페이스를 만드는 접착체일 뿐이다. 비슷한 접근 방식이 GBFS (Group Base FileSystem) 에서 이미 제안되었다. 여기서 서로 다른 위치에 배포된 서로 다른 파일 시스템이 공통 네임스페이스로 집계된다. 이것은 모든 액세스가 루트 디렉토리를 담당하는 서버를 요청하는 엄청난 워크로드를 발생시키기 때문에 효율적이지 않다. 접근 방식의 차이점은 오브젝트 저장소에 의존하기 때문에 병목 현상이 될 루트 디렉토리가 없다는 것이다.
RozoFS 또는 GlusterFS 와 같은 Scale-Out NAS 사용의 관심은 노드를 즉석에서 추가할 수 있는 기능으로, 요청이 서로 다른 노드간 균일하게 분산되기 때문에 스토리지 공간뿐만 아니라 시스템 성능도 향상된다.
오브젝트를 노드에 직접 저장하는 대신 분산 파일 시스템으로 보낸다.
########## [writing] ##########
[###################### <site1> #######################] [<site2>]
+------+ +-------+ +-------+ +------+ +------+ +-------+ +-------+
|client| |IPFS n1| |IPFS n2| |DFS n1| |DFS n2| |DFS MDS| |IPFS n3|
+------+ +-------+ +-------+ +------+ +------+ +-------+ +-------+
| | | | | | |
| put | | | | | |
{object identifier}= | | | | |
| "data" | | | | | |
|-------->| get DFS Nodes to store {object identifier} |
| |------------------------------------>| |
| | DFS n1 | |
| |<------------------------------------| |
| | store object | | | |
| |------------------>| | | |
| done | | | | | |
|<--------| | | | | |
| | | | | | |
| DHT: add location record "{object identifier} in IPFS n1"
| |------------------------------------------------>|
주요 변경 내용은 클라이언트가 오브젝트에 액세스하려고 할 때 발생한다. 아래 그림은 이러한 변경 사항을 보인다: Scale-Out NAS 로 인해 사이트의 모든 IPFS 노드는 동일 사이트의 다른 노드가 조작한 오브젝트를 볼 수 있다. 결과적으로 요청한 IPFS 노드에 관계없이 노드에서 오브젝트가 로컬에 저장되어 있는지 확인하면 Scale-Out NAS 에 요청하고 오브젝트가 자체적으로 작성된 것 처럼 찾는다. IPFS 원래 개념과 달리 사이트에서 로컬로 사용할 수 있는 오브젝트를 찾기위해 DHT 를 요청할 필요가 없다.
########## [reading of an object locally stored] ##########
[###################### <site1> #######################] [<site2>]
+------+ +-------+ +-------+ +------+ +------+ +-------+ +-------+
|client| |IPFS n1| |IPFS n2| |DFS n1| |DFS n2| |DFS MDS| |IPFS n3|
+------+ +-------+ +-------+ +------+ +------+ +-------+ +-------+
| | | | | | |
| get | | | | | |
{object identifier} | | | | |
|-------->| | | | | |
| get DFS Nodes storing {object identifier} |
| |------------------------------------>| |
| | DFS n1 | |
| |<------------------------------------| |
| | store object | | | |
| |------------------>| | | |
object="data" | | | | |
|<--------| | | | | |
| | | | | | |
get {object identifier} | | | |
|------------------>| | | | |
| | | get DFS Nodes | |
| | storing {object identifier} |
| | |-------------------------->| |
| | | DFS n1 | |
| | |<--------------------------| |
| | | | | | |
| | read object | | | |
| | |-------->| | | |
| object="data" | | | | |
|<------------------| | | | |
비슷한 방식으로 아래 그림은 클라이언트가 원격 사이트에 저장된 데이터에 액세스하는 경우의 프로토콜을 보인다. 클라이언트는 사이트의 모든 IPFS 노드에 요청을 보낸다. 노드는 분산 파일 시스템에서 오브젝트가 있는지 확인하고 오브젝트를 찾을 수 없기 때문에 DHT 에 복제본 찾기를 요청한다. 그런 후 오브젝트가 다운로드 되고 DHT 가 업데이트 되기 전 새로운 복제본이 로컬 Scale-Out NAS 에 저장된다. 이 사이트에서 수행되는 향후 액세스는 요청된 IPFS 노드에 관계없이 다른 사이트와 통신을 하지 않고 응답한다.
########## [reading of an object stored on a remote site] ##########
[################### <site1> ####################] [<site2>] [################### <site3> ###################]
+-------+ +-------+ +-------+ +-------+ +--------+ +-------+ +--------+ +-------+ +-------+ +-------+ +------+
|IPFS n1| |IPFS n2| |DFS1 n1| |DFS1 n2| |DFS1 MDS| |IPFS n3| |DFS2 MDS| |DFS2 n1| |IPFS n4| |IPFS n5| |client|
+-------+ +-------+ +-------+ +-------+ +--------+ +-------+ +--------+ +-------+ +-------+ +-------+ +------+
| | | | | | | | | | |
| | | | | | | | get {object identifier}
| | | | | | | | |<-----------------|
| | | | | | get DFS nodes storing | |
| | | | | | | {object identifier}| | |
| | | | | | |<-------------------| | |
| | | | | | | object not found | | |
| | | | | | |------------------->| | |
| | | | | DHT: locate {object identifier} | |
| | | | | |<-------------------------------| | |
| | | | | | in IPFS n1 | | |
| | | | | |------------------------------->| | |
| get/read {object identifier} | | |
|<------------------------------------------------------------------------------------| | |
get DFS Nodes storing {object identifier} | | | | | |
|-------------------------------------->| | | | | | |
| DFS n1 | | | | | | |
|<--------------------------------------| | | | | | |
| read object | | | | | | | | |
|------------------>| | | | | | | | |
| object="data" | | |
|------------------------------------------------------------------------------------>| object="data" |
| | | | | | | | |----------------->|
| | | | | | | get DFS Nodes | | |
| | | | | | to store {object identifier} | |
| | | | | | |<-------------------| | |
| | | | | | | DFS2 n1 | | |
| | | | | | |------------------->| | |
| | | | | | | store object | |
| | | | | | | |<--------| | |
| | | | | DHT add: "{object identifier} in IPFS n4" | |
| | | | | |<-------------------------------| | |
| | | | | | | | | | |
| | | | | | | | | get {object identifier}
| | | | | | | | | |<-------|
| | | | | | get DFS Nodes storing {object identifier} |
| | | | | | |<-----------------------------| |
| | | | | | | DFS2 n1 | |
| | | | | | |----------------------------->| |
| | | | | | | | read object | |
| | | | | | | |<------------------| |
| | | | | | | | | object="data"
| | | | | | | | | |------->|
이를 통해 IPFS 는 로컬 접속의 경우 “네트워크 containment” 속성을 충족시킬 수 있으며 네트워크 파티셔닝의 경우 각 사이트가 독립적으로 작동할 수 있다. IPFS 가 저장한 오브젝트는 불변이기 때문에 로컬 Scale-Out NAS 에 저장된 로컬 복제본이 오브젝트의 최신 버전인지 또는 다른 사이트에서 업데이트 된 버전을 찾을 수 있는지 확인하는 것은 신경쓰지 않는다.
########## summary of Fog characteristics met by IPFS and our proposal ##########
| IPFS | Scale-Out NAS 와 결합된 IPFS | |
|---|---|---|
| Data locality | Yes | Yes |
| Network containment | No | Only for local access |
| Disconnected mode | Parially | Yes |
| Mobility support | Natively | Natively |
| Scalability | Yes | Yes |
요약하자면, 제안한 접근 방식은 클라이언트가 로컬 사이트에서 사용 가능한 복제본 중 하나가 있는 오브젝트를 요청할 때 DHT 가 사용되지 않기 때문에 로컬에 저장된 오브젝트에 액세스하기 위한 네트워크 트래픽을 제한한다. 다른 상황에서는 사이트 간 네트워크 트래픽의 양이 동일하다.
제안한 방식은 사이트를 구성하는 모든 노드에 저장된 데이터의 균형을 균일하게 유지한다. 클라이언트가 특정 IPFS 노드에 막대한 양의 데이터를 전송하는 경우 노드는 이러한 데이터를 표준 접근 방식으로 저장해야 하지만 우리의 제안에서는 사이트 내 Scale-Out NAS 를 구성하는 모든 스토리지 서버에 데이터가 분산된다.
3.1.3. Limitations
위 내용을 근거로 제시한 접근 방식의 성능이 크게 향상될 수 있음을 알 수 있다. 원격에서 저장된 오브젝트에 액세스하면 복제본이 저장된 모든 노드에서 오브젝트가 다운로드 된다. 이것은 가장 효율적인 방법으로 오브젝트를 다운로드하기 위한 IPFS 의 기본 동작이다. 노드가 오버로드되면 모든 노드가 응답할 수 있다.
Scale-Out NAS 를 사용하는 접근 방식에서는 사이트당 하나의 노드가 DHT 에서 오브젝트 복사본을 저장하는 것으로 알려져 있기 때문에 상황이 다르다. 클라이언트가 오브젝트를 쓰는 노드 또는 첫번째 노드 오브젝트에 액세스할 수 있다. 위 그림에서 볼 수 있듯 site1 에 있는 IPFS node4 는 오브젝트가 이전에 기록된 노드에 있으므로 site1 에 있는 IPFS node1 에서만 오브젝트를 다운로드 할 수 있으며 DHT 에서 오브젝트가 있는 것으로 알려진 노드다. IPFS node4 는 분산 파일 시스템을 IPFS node1 과 공유하면서 IPFS node2 에서도 오브젝트를 다운로드 할 수 있다는 사실을 알 길이 없다. 이러한 상황은 병목현상이나 일부 노드의 과부하로 이어질 수 있다. 마찬가지로 IPFS node1 에 접속할 수 없게되면 IPFS node2 를 전송의 소스로 사용할 수 있는 반면, IPFS node1 에 접속할 수 없게 된다.
이러한 문제의 해결책은 IPFS node 의 식별자가 아닌 현장의 식별자를 DHT 에 저장하는 것이 될 수 있다.
3.2. Reduction of inter-sites network traffic for accessing data stored on a remote site
이전 섹션에서 IPFS 를 각 사이트에 독립적으로 구축된 Scale-Out NAS 와 결합하여 로컬로 저장된 오브젝트에 액세스하는 동안 네트워크 트래픽을 억제하도록 제안하였다. 그러나 원격 사이트에 저장된 오브젝트에 접근하기 위해 DHT 의 사용은 사용자와 가까운 네트워크 트래픽을 포함하지 않으며 복제본에 가까운 오브젝트 위치를 저장하지 않는다. 다음 섹션에서 Fog 인프라에 대한 흥미로운 속성을 가진 도메인 네임 시스템 프로토콜을 제시하고 물리 토폴로지에 따라 구축된 트리에 의존하는 프로토콜을 소개한다.
3.2.1. Domain Name System protocol: an inspiration for our approach
DHT 나 다른 방식에서도 물리적 인접성을 제공하지 않고 오브젝트 복제본의 위치를 저장한 기록을 필요한 곳에 가깝게 재배치할 수 없기 때문에 DNS 에서 영감을 받은 프로토콜을 제안한다. 쿼리를 수행하는 확인자인 DNS 프로토콜에서 먼저 루트 노드를 요청하고 루트 노드가 쿼리에 직접 응답할 수 없는 경우 응답할 수 있는 서버가 확인자에게 표시된다. 이 메커니즘은 DHT 에서 수행되는 hop 방식과 유사하지만 차이가 있다: hash function 을 사용하는 대신 오브젝트 복제본의 위치를 저장하는 노드를 선택할 수 있다. 또한 Fog context 에서 매우 흥미로운 속성인 쿼리를 수행하기 위해 노드가 도달해야 할 서버를 제어할 수 있다. 또한 접속 시간을 줄이기 위해 DNS 캐시 메커니즘을 재사용하는 것은 유용한 방법이다.
3.2.2. Metadata management overview
DNS 프로토콜과 같은 방법으로 서로 다른 이름들이 계층적인 방식으로 조직된 다른 서버에 분산될 것을 제안한다. 이 트리는 Fog 에서 서로 다른 사이트로 구성되어 있으며 DNS 와는 반대로 현재 사이트에서 루트 노드까지 상향식으로 탐색된다. 위치가 지정된 수준에서 발견되지 않으면 상위 노드가 요청된다.
트리가 어떤 데이터라도 찾기위한 시간을 단축하는 궁극적인 목표로 네트워크의 물리적 토폴로지와 네트ㅝ크 지연시간에 따라 구축된다고 가정한다. 즉, 각 노드의 상위 노드가 물리적으로 가깝고 요청하여 오브젝트 위치를 찾는 것이 상위 노드의 상위 노드에 요청하는 것 보다 빠르다. 게다가 네트워크 트래픽을 토폴로지의 작은 부분으로 제한한다.
########## [Tree computed with our algorithm showing the initial content of the "location servers". Each site also has storage nodes and clients which are not represented] ##########
+------------------------+
| city06 (site6) |
|- .city01 -> at "city01"|
|- .city02 -> at "city02"|
|- .city03 -> at "city03"|
|- .city04 -> at "city04"|
|- .city05 -> at "city05"|
|- .city06 -> at "city06"|
|- .city07 -> at "city07"|
|- .city08 -> at "city08"|
+------------------------+
| | | |
+----------------------------------+ | | +----------------------------------+
| +------------+ +-----------+ |
| | | |
+------------------------+ +------------------------+ +------------------------+ +------------------------+
| city01 (site1) | | city05 (site5) | | city03 (site3) | | city08 (site8) |
|- .city01 -> at "city01"| |- .city05 -> at "city05"| |- .city03 -> at "city03"| |- .city08 -> at "city08"|
| | |- .city02 -> at "city02"| |- .city04 -> at "city04"| | |
| | |-. city07 -> at "city07"| | | | |
+------------------------+ +------------------------+ +------------------------+ +------------------------+
| | |
+------------------+ +-------+ |
| | |
+------------------------+ +------------------------+ +------------------------+
| city02 (site2) | | city07 (site7) | | city04 (site4) |
|- .city02 -> at "city02"| |- .city07 -> at "city07"| |- .city04 -> at "city04"|
+------------------------+ +------------------------+ +------------------------+
위 그림은 가상의 네트워크 토폴로지에서 계산한 트리를 보여준다. 트리를 구축하는 방법은 다믕 섹션에서 설명한다. 위 그림에서 위치 기록에 대한 구성을 보여준다. 노드 사이의 edge 는 물리 네트워크 링크에 해당한다. 각 노드는 하위 트리에 저장된 오브젝트에 대한 모든 요청에 응답할 수 있으며, 특히 루트 노드는 모든 요청에 대한 응답을 제공할 수 있다. 루트 노드는 지리적 토폴로지에 따른 지연시간의 중심 위치이기 때문에 선택된다. 네트워크 대기 시간은 지리적 거리에 의해 좌우된다. 각 사이트는 “storage backend” 와 “location server” 로 구성되어 있다고 생각한다. “storage backend” 는 오브젝트를 저장하는 동시에 로컬에 저장되지 않은 다른 사이트 (예: 섹션 3.1 에 소개된 NAS 서버) 에서 오브젝트를 검색하는 역할을 겸한다. “location server” 는 복제본이 저장되는 하위 트리의 오브젝트 이름과 사이트 간의 연결을 저장하는 역할을 담당한다. 구체적으로 오브젝트 이름과 오브젝트 복제본을 저장하는 스토리지 노드의 주소로 구성된 위치 정보를 저장한다. 주어진 오브젝트에 대해 서버는 복제본 당 최대 하나의 레코드를 저장한다. 위 그림은 location server 의 초기 내용을 보여준다. 예를들어 * .city03 레코드는 .city03 프리픽스가 붙은 모든 오브젝트의 기본 위치를 정의한다. 이 특수 위치 기록의 장점은 다음 섹션에서 설명한다. 아래의 내용은 노드가 교환한 네트워크 메시지와 라우팅에 사용되는 물리 경로를 보여준다.
Object creation: 아래 그림은 클라이언트가 오브젝트를 작성할 때 오브젝트가 생성된 사이트에 해당하는 프리픽스가 오브젝트 이름에 추가되는 것을 보여준다. 그림에서 볼 수 있듯 위치 서버를 업데이트 하지 않는다. 와일드 카드 위임 (예: * .city03) 을 사용하면 오브젝트가 생성될 때 위치 정보가 업데이트되지 않고 추가 복제본이 추가될 때만 업데이트 된다. Fog Computing 비전에서 오브젝트가 생성된 사이트에서 대부분 읽힌다고 가정한다. 이것은 저장되는 위치 기록의 양을 크게 줄인다. 그럼에도 불구하고 오브젝트의 접미사 (suffix) 에만 의존하여 위치를 결정하는 것은 충분하지 않다. 사용자가 objectX.city03 에 액세스 하려고 할 때 city03 의 스토리지 노드에 직접 연결하면 안된다. 오브젝트의 복제본이 city03 에서 사용 가능하다는 것을 알고 있지만 네트워크에 더 가까운 복제본이 존재하지 않는지 확인하여야 한다. 여기서 접미사는 신규 오브젝트 복제본이 생성될 때 업데이트 메시지 양을 제한하는데만 사용된다.
########## [Sequence diagram of network traffic when a client writes an object in city03] ##########
city03
+------+ +---------------+ +---------------+
|client| |storage backend| |location server|
+------+ +---------------+ +---------------+
| | |
put objectX.city03 No location updated
|---------------->| The stored record
| done | *.city03 -> at "city03"
|<----------------| matches the object's name
Accessing an object from a remote site for the first time: 아래 그림은 city02 에서 city03 에 만들어진 오브젝트를 얻기위한 읽기 과정을 보여준다. 클라이언트가 로컬 스토리지 노드를 요청하기 시작한 다음 요청된 오브젝트가 로컬에 저장되지 않은 경우 이 노드는 오브젝트의 위치를 찾는다. 요청된 첫번째 위치의 서버는 가장 가까운 로컬 서버이다. 그런다음 위치가 존재하지 않은 경우 하나의 메타데이터 서버가 해당 위치에 응답할 때까지 저장 노드가 위치 서버의 부모 (city05) 를 요청한다. 최악의 경우 해당 위치는 루트 메타데이터 서버 (city06) 에서 발견된다. 최적 위치를 찾으면 city03 에 저장된 오브젝트가 로컬로 재배치되고 새로운 복제본이 만들어지기 때문에 위치 정보는 비동기적으로 업데이트 된다. 스토리지 노드는 위치가 발견된 서버와 가장 가까운 노드에서 location server 로 업데이트를 전송한다. 이러한 방식으로 업데이트된 “location server” 의 하위 트리에 있는 사이트는 향후 읽기에서 새로운 복제본을 찾을 수 있을 것이다. ‘위치 정보’ 를 사용하지 않고 사이트와 루트 노드 사이의 경로에 걸쳐 모든 오브젝트를 직접 복제하는 것이 가능할 수 있다는 점에 주목한다. 그러나 이것은 스토리지 공간 문제로 인해 구상할 수 없다.
########## [Read the object stored in city03 from city02] ##########
city02 city05 city06 city03
+------+ +-------+ +--------+ +--------+ +--------+ +-------+
|client| |storage| |location| |location| |location| |storage|
| | |backend| | server | | server | | server | |backend|
+------+ +-------+ +--------+ +--------+ +--------+ +-------+
| | | | | |
get obejctX.city03 | | Object lookup phase
|----------->| | | | |
| where is objectX.city03? | | |
| |------------->| | | |
| | not found | | | |
| |<-------------| | | |
| | where is objectX.city03? | | |
| |--------------------------------->| | |
| | not found | | |
| |<---------------------------------| | |
| | where is objectX.city03? | |
| |----------------------------------------------------->| |
| | at "city03" | |
| |<-----------------------------------------------------| |
| | get objectX.city03 |
| |------------------------------------------------------------------------>|
| | object |
| object |<------------------------------------------------------------------------|
|<-----------| | | | |
===========================================================================================
| | | | | |
| |---+ | | Object relocation phase
| | | | | | |
| store objectX.city03 | | | |
| | | | | | |
| |<--+ | | | |
| objectX.city03 -> at "city02" | | |
| |------------->| | | |
| add objectX.city03 -> at "city02" | |
| |--------------------------------->| | |
| | add objectX.city03 -> at "city02" | |
| |----------------------------------------------------->| |
Accessing the object when several replicas are available: 아래 그림에서 city07 이 city03 에서 생성된 오브젝트를 요청하고 이전에 city02 에서 재배치 한 것을 보여준다. 읽기 과정은 앞과 동일하지만 city02 에 있는 복제본은 city05 에서 발견된 위치 기록 덕분에 접속할 수 있다. 루트 (city06) 메타데이터 서버에 도달하거나 업데이트 되지 않는 경우 이전 city02 에서 오브젝트 복제본이 추가되었음에도 불구하고 오브젝트의 이름은 수정되지 않는다는 것에 유의하여야 한다. city07 은 여전히 ‘.city03’ 접미사가 붙은 오브젝트를 찾지만, 트리에 저장된 위치 기록 덕분에 city02 에 저장된 더 가까운 복제본에 접근할 수 있다. 따라서 오브젝트 이름의 접미사는 읽기 과정에서 아무 의미가 없다. 사용자는 복제의 모든 위치가 아닌, 오브젝트가 처음 쓰여진 사이트만 알면된다. 이 접근 방법에는 몇가지 장점이 있다. i) 쓰기는 하지만 접근은 하지 않는 오브젝트에 대해서는 네트워크 트래픽이 생성되지 않는다. ii) 사이트 오브젝트에 접근하는 횟수가 많을수록 데이터 및 위치 기록의 복제본이 많아진다. iii) 오브젝트 복제본은 오브젝트 복제본의 위치를 얻는 노드의 하위 트리에서 발견된다. 결국, 위치가 가까울 수록 데이터는 가까워진다. 즉 이런 접근방식은 노드가 (트리 관점) 가장 가까운 복제본을 검색할 수 있도록 한다.
########## [Read from city07 the object previously read from city02] ##########
city07 city05 city06 city02
+------+ +-------+ +--------+ +--------+ +--------+ +-------+
|client| |storage| |location| |location| |location| |storage|
| | |backend| | server | | server | | server | |backend|
+------+ +-------+ +--------+ +--------+ +--------+ +-------+
| | | | | |
get obejctX.city03 | | Object lookup phase
|----------->| | | | |
| where is objectX.city03? | | |
| |------------->| | | |
| | not found | | | |
| |<-------------| | | |
| | where is objectX.city03? | | |
| |--------------------------------->| | |
| | at "city02" | | |
| |<---------------------------------| | |
| | get objectX.city03 |
| |------------------------------------------------------------------------>|
| | object |
| object |<------------------------------------------------------------------------|
|<-----------| | | | |
===========================================================================================
| | | | | |
| |---+ | | Object relocation phase
| | | | | | |
| store objectX.city03 | | | |
| | | | | | |
| |<--+ | | | |
| objectX.city03 -> at "city07" | | |
| |------------->| | | |
| add objectX.city03 -> at "city07" | |
| |--------------------------------->| | |
Deleting a single replica or removing an object entirely: 단일 복제본을 삭제하려면 복제본을 저장하는 사이트에서 복제본을 가리키는 위치 레코드를 저장하지 않는 첫번째 사이트로 트리를 검색하는 것이 제안되는 전략이다. 삭제된 특정 복제본을 가리키는 사이의 모든 위치 정보가 제거된다. 그러나 노드가 하위 트리에 다른 복제본이 저장되어 있는지 모르는 불일치로 이어질 수 있다. 이것이 트리 위층에 위치 기록을 복사하는 것을 제안하는 이유이다. 예를들어 city02 에 위치한 복제본을 삭제하기 위해 위치 기록 objectX.city03->”city02” 는 city02 와 city05 및 city06 의 location server 에서 제거된다. 그럼에도 불구하고 city05 의 location server 는 city07 을 가리키는 오브젝트에 대한 기록도 가지고 있기 때문에 city06 에서 city07 을 가리키는 신규 기록을 추가한다. 오브젝트의 “master copy” 을 제거하는 경우, 트리를 현재 노드에서 루트 노드로 탐색할 수 있으며, 루트 노드에 저장된 위치 정보가 오브젝트의 와일드카드가 아닌 경로의 각 서버에 재복사할 수 있다. 예를들어 city03 에 저장된 복제본을 삭제하면 city03 에 objectX.city03->”city02” 기록을 삽입할 수 있다.
########## [Delete a single object replica (city02)] ##########
city02 city05 city06
+------+ +-------+ +--------+ +--------+ +--------+
|client| |storage| |location| |location| |location|
| | |backend| | server | | server | | server |
+------+ +-------+ +--------+ +--------+ +--------+
| | | | |
delete objectX.city03 | | |
|----------->| | | |
| |---+ | | |
| | | | | |
| delete objectX.city03 | | |
| | | | | |
| done |<--+ | | |
|<-----------| | | |
| where is objectX.city03? | |
| |------------->| | |
| at "city02" | |
| |<-------------| | |
| delete objectX.city03 -> at "city02" | |
| |------------->| | |
| | where is objectX.city03? | |
| |--------------------------------->| |
| | at "city02" and "city07" | |
| |<---------------------------------| |
| delete objectX.city03 -> at "city02" |
| |--------------------------------->| |
| | where is objectX.city03? |
| |----------------------------------------------------->|
| | at "city02" |
| |<-----------------------------------------------------|
| | delete objectX.city03 -> at "city02" |
| |----------------------------------------------------->|
| | add objectX.city03 -> at "city07" |
| |----------------------------------------------------->|
모든 복제본을 제거하는데 구성된 오브젝트를 완전히 삭제하려면 루트 노드에서 트리를 검색하고 이 오브젝트에 대해 발견된 모든 위치 정보를 따라 삭제한다. 와일드카드 기록은 따라갈 수 있지만 다른 오브젝트에도 사용되기 때문에 삭제하지 않는다.
########## [Delete a "master copy" (city03)] ##########
city03 city06
+------+ +-------+ +--------+ +--------+
|client| |storage| |location| |location|
| | |backend| | server | | server |
+------+ +-------+ +--------+ +--------+
| | | |
delete objectX.city03 | |
|----------->| | |
| |---+ | |
| | | | |
| delete objectX.city03 | |
| | | | |
| done |<--+ | |
|<-----------| | |
| | where is objectX.city03? |
| |--------------------------------->|
| | at "city07" |
| |<---------------------------------|
| add objectX.city03 -> at "city07" |
| |------------->| |
설명한 프로토콜이 현재 노드에서 루트 노드로 가는 물리적 경로를 따라 발견되기 때문에 DHT 보다 Fog 인프라에 더 적합하다고 주장한다. 위치 정보를 생성하면 조회 지연 시간을 줄일 수 있을 뿐만 아니라 네트워크 파티셔닝 시 사이트에 도달할 수 있는 오브젝트 복제본을 찾을 수 있어 Fog 사이트 자율성이 높아진다. 이 프로토콜은 오브젝트를 찾는 동안 교환되는 네트워크 트래픽 (대부분 log(N) 노드는 트리가 균형적일 때 접촉됨) 을 제한하고 접속 시간에 미치는 영향을 제한한다. 두번째 장점은 복제되지 않은 오브젝트가 와일드카드로 인해 특정 위치 기록이 없기 때문에 필요한 위치 기록의 복제본을 최소로 제한한다는 점이다. 마지막으로, 각 노드는 토폴로지에 대한 제한된 정보를 가지고 있다. 각 노드는 트리의 상위 노드만 알고있다.
3.2.3. Algorithm to build the tree
제안된 프로토콜은 트리 구성에 의존한다. 트리 구성에 있어 세부설명은 다음 섹션에서 소개한다. 플랫 트리는 루트 노드에 직접 도달하기 때문에 노드가 새 위치 스토리지 복제본의 장점을 살릴 수 없다. 이와 반대로 딥 트리 토폴로지는 수 많은 홉 구성으로 인해 성능이 저하된다. 실제 트리 구조는 오브젝트를 찾을 수 있는 최대 홉 수를 결정하지만 다른 노드가 가까운 오브젝트 복제본을 찾을 수 있는 기회와 이를 찾는 대기 시간도 결정한다.
소스 노드에서 다른 모든 노드로 최단 경로를 계산하는 고전적인 알고리즘은 Dijkstra 알고리즘이다. 소스 노드에서 다른 노드로 최단 경로 목록은 소스 노드가 루트인 트리로 볼 수 있다. Dijkstra 알고리즘의 단점은 루트 노드를 지정한다는 것이다. “best” 루트 노드를 선택하기 위해 각 노드를 소스로 사용하여 트리를 연속적으로 계산하고 가중치가 낮은 것을 선택한다.
예를 들어 아래 그림에서 트리의 가중치는 9.0+7.0+4.0+5.0+5.0+(2.5+4.0)+(4.5+5.0)=46 이다.
########## [Dijkstra with the traditional cost function] ##########
+--------------+
+--------------------------|city06 (site6)|-------------------------+
| +--------------+ |
| | | | |
| +-----------+ | +----------+ |
| | | | |
9.0ms 7.0ms 4.0ms 5.0ms 5.0ms
| | | | |
+--------------+ +--------------+ +--------------+ +--------------+ +--------------+
|city02 (site2)| |city01 (site1)| |city05 (site5)| |city03 (site3)| |city08 (site8)|
+--------------+ +--------------+ +--------------+ +--------------+ +--------------+
| |
2.5ms 4.5ms
| |
+--------------+ +--------------+
|city07 (site7)| |city04 (site4)|
+--------------+ +--------------+
아래 그림에서 보이는 트리는 총 지연 시간을 최적화하지만 매우 평평하며 대부분 노드가 재배치 없이 루트에 직접 액세스한다.
########## [Dijkstra with our cost function] ##########
+--------------+
+----------------------------------|city06 (site6)|----------------------------------+
| +--------------+ |
| | | | | |
| +-------------------+ | | +-------------------+ |
| | +-----+ +-----+ | |
| | | | | |
9.0ms 7.0ms 10.0ms 4.0ms 5.0ms 5.0ms
| | | | | |
+--------------+ +--------------+ +--------------+ +--------------+ +--------------+ +--------------+
|city02 (site2)| |city01 (site1)| |city04 (site4)| |city05 (site5)| |city03 (site3)| |city08 (site8)|
+--------------+ +--------------+ +--------------+ +--------------+ +--------------+ +--------------+
|
2.5ms
|
+--------------+
|city07 (site7)|
+--------------+
아래 그림에서 루트가 조금이라도 늘어날 때까지 모든 조상 노드에 도달하는 대기 시간이 길어도 깊은 노드는 위치 기록을 찾을 가능성이 더 크다.
########## [Dijkstra with our relaxed cost function] ##########
+--------------+
+-----------------|city06 (site6)|-----------------+
| +--------------+ |
| | | |
| +------+ +------+ |
| | | |
7.0ms 4.0ms 5.0ms 5.0ms
| | | |
+--------------+ +--------------+ +--------------+ +--------------+
|city01 (site1)| |city05 (site5)| |city03 (site3)| |city08 (site8)|
+--------------+ +--------------+ +--------------+ +--------------+
| | |
+----5.0ms----+ 2.5ms 4.5ms
| | |
+--------------+ +--------------+ +--------------+
|city02 (site2)| |city07 (site7)| |city04 (site4)|
+--------------+ +--------------+ +--------------+
3.5. Conclusion and Discussion
지금까지 로컬로 저장된 오브젝트가 요청될 때 사이트 간 네트워크 교환을 줄이는 방법을 제안했다. IPFS 를 Scale-Out NAS 와 결합하여 각 사이트에 저장된 모든 오브젝트를 사이트 전체 IPFS 노드에서 사용할 수 있도록 제안하였다. 또한 물리 네트워크 토폴로지를 고려하여 오브젝트 위치 관리에 사용되는 DHT (메타데이터 관리) 를 Dijkstra 알고리즘의 수정된 버전으로 구축된 트리에 의존하는 프로토콜로 교체하여 원격으로 저장된 오브젝트에 접속할 때 사이트간 네트워크 트래픽을 줄이는 방안을 제안하였다.
제안된 프로토콜에 추가적으로 필요한 개선점은 불변 오브젝트가 있는 경우 사용자가 자신의 데이터를 수정할 수 있도록 하는 것이다. 하지만 수정은 다른 모든 복제본을 수정해야 하기 때문에 일관성을 관리하는 것은 매우 어려운 일이다. 이것은 접속 시간에 대한 영향을 제한하기 위해 비동기적으로 수행될 수 있지만, 제안된 프로토콜은 최신 버전에 가까운 복제본을 찾기 위한 프로토콜로 수정되어야 한다.
제안된 Fog 아키텍처는 대칭 또는 역방향 CDN 으로 간주될 수 있다. CDN 은 사용자와 가까운 곳에 위치한 서버의 데이터를 캐싱하는 방식으로 구성된다. 여기에 두가지 장점이 있다: i) 근접 서버에 접속하면 요청된 자원에 대한 액세스 시간을 줄일 수 있으며, ii) 모든 클라이언트가 아닌 캐싱 서버에만 콘텐츠를 전송하면 되기 때문에 중앙 서버 부하를 줄일 수 있다. 이러한 네트워크는 표준 아키텍처가 없다. 일부는 트리 hash function 에 의존하는 반면 다른 일부는 DHT 에 의존하고 일부는 하이브리드로 다른 프로토콜의 혼합에 의존한다.
몇몇 저자들이 Fog 계층 구조는 가까운 곳에 오브젝트 복제본이 즉시 작성되는콘텐츠 배포 네트워크로 간주될 수 있다. 예를들어 Yang 등의 경우, 네트워크 edge 에 있는 스토리지 서버를 사용하여 클라우드에 저장된 데이터를 캐싱하는데 이것은 제안한 것과 유사한 접근 방식이다. 그러나 Fog 컴퓨팅용 CDN 과 스토리지 솔루션의 주요 차이점은 CDN 에서 데이터가 네트워크 코어에 저장되어 edge 에 전파되는 반면, Fog 는 edge 에 데이터가 생성된다는 것이다. 이러한 의미로 Fog 컴퓨팅은 클라이언트에서 전송된 데이터가 클라우드에 도달할 때 까지 모든 계층을 통과하는 거꾸로된 CDN 으로 볼 수 있다.
또한 제시한 접근 방식은 네트워크 오버레이를 사용하지 않기 때문에 ICN 과도 비교될 수 있다. ICN 과 NDN 또는 NNC 는 요청 데이터를 저장하는 노드로 요청을 직접 라우팅하기 위해 네트워크를 사용하는 개념이다. 다른 방식과는 달리 데이터에 접근하기 전 데이터를 찾을 필요가 없다는 것이다. 클라이언트가 특정 컴퓨터가 아닌 데이터의 대상으로 요청을 보내고 네트워크는 이것을 저장하고 있는 컴퓨터로 전송한다. 이것에 대한 몇 구현이 제안되었다. 일부는 데이터센터 내에서 작업하는 것으로 전문화되었고, 다른 일부는 멀티사이트 환경 특히 CDN 네트워크에서 작업하도록 조정되었다. 이 방식의 주요 장점은 네트워크에 저장된 다른 오브젝트를 찾기위해 메타데이터 서버나 어떤 프로토콜도 요구하지 않고 접근 시간을 향상시키는 것이다. 이런 의미에서 이 접근 방식은 데이터를 Fog 컴퓨팅 아키텍처를 저장하는데 사용될 수 있다. 그러나 각 라우터에서 각 오브젝트의 위치를 저장하는 테이블을 유지하는 것은 비용이 많이든다.
다음 섹션에서 사이트 간 교환되는 네트워크 트래픽 양 뿐만 아니라 접속 시간에 미치는 영향을 측정하기 위해 제안사항을 실험 평가한다.
