Cloud storage란, 원격에서 public internet이나 private network를 통해 데이터를 전달하고 저장할 수 있는 저장소이다. 기존의 on-premise storage 의 경우는 한정된 디스크 용량으로 인해 디스크가 다 차게 되면 데이터를 다른 서버로 옮겨야했다. 하지만 cloud storage를 사용하게 되면 그럴 필요가 없이 사용자가 용량을 정하고 그에 해당하는 비용만 지불하면 된다.
Cloud storage도 사실은 실제 서버의 디스크를 사용하는 것이다. Provider가 수 많은 서버들을 묶어서 하나의 거대한 용량의 디스크를 갖고 있는 서비스를 구축하고, 여러 사용자들에게 그 중 일부를 필요에 따라 나눠준다.
사용자 입장에서 cloud storage를 사용하게 되면 서버 관리의 부담이 줄게 되고 사용량을 유연하게 정할 수 있다. 하지만 데이터를 provider의 서버에 저장하기 때문에 보안상의 우려가 있을 수 있고 데이터에 대한 세세한 컨트롤이 불가능하다는 점도 있다.
큰 데이터를 블록으로 나누어서 여러 노드에 보관한다.
어떤 데이터를 요청하면 퍼져있는 여러 블록들을 모아서 원래의 데이터를 만든다.
Latency가 낮아서 퍼포먼스가 좋다.
파일을 변경하면 새로운 오브젝트가 생성되기 때문에 자주 바뀌지 않는 데이터에 적합하다.
메타데이터가 기본 파일 속성으로 제한되기 때문에 모든 블록은 동일한 형식의 메타데이터를 갖는다.
기존의 로컬 파일시스템과 유사하게 파일과 폴더를 이용해 계층적 구조로 보관이 된다.
데이터를 생성한 클라이언트나 보관하는 스토리지나 동일한 형태의 파일을 갖게 되기에 데이터를 요청하면 그대로 전달할 수 있다.
데이터에 대한 접근이 단일 경로로 제한되므로 성능이 비교적 좋지 않을 수 있다.
정형 데이터와 비정형 데이터가 섞여 있을 때 유용하다.
데이터를 오브젝트 형태로 저장한다.
오브젝트 종류에 따라 메타데이터를 다르게 가질 수 있다. 예를 들어, 동영상 오브젝트라면 촬영 시각, 장소 등을 메타데이터로 넣을 수 있다.
각 객체마다 고유 아이디가 있어서 분산 시스템의 어디에 있든 불러올 수 있고, 확장성이 매우 높다.
main 노드가 별도로 구분되어 있는 게 아니라 metadata는 object storage 어디든 옮겨질 수 있다.
연속된 데이터라도 연속적으로 저장하지 않기 때문에 연속된 데이터를 불러올 때 각 오브젝트마다 네트워크 대역폭에 따라 걸리는 시간이 다를 수 있다. 따라서 작업 성능이 일정하게 유지해야되는 경우나 interactive 작업과 같이 낮은 latency가 필요한 경우는 object storage가 적합하지 않을 수 있다.
이럴 때는 object storage에 저장된 데이터 중 필요한 만큼 HDFS와 같이 data locality를 사용하는 저장소로 옮겨온 후에 작업을 하는 방법도 있다.
rename, delete 등의 작업이 atomic하지 않다.
대용량 데이터를 저장하기 위한 분산 파일 시스템으로서 physical machine에서 실행된다.(다른 프로세스도 같이 실행될 수 있다.)
메타데이터가 저장되어 있는 NameNode가 중심에 있고 실제 데이터가 저장되어 있는 DataNode가 여러 대 있는 구조이다. 클라이언트는 NN와 먼저 통신하여 원하는 데이터가 있는 DN 위치를 알아오게 되고, 그 다음에 그 DN에게 직접 데이터를 요청해서 받아온다.
NN가 다운되면 서비스가 불가능하기 때문에 Quorum Journal Manager를 통해 고가용성을 제공한다. active NN와 standby NN를 두어서 active NN에 일어나는 변경 사항들을 QJM을 통해 standby NN에 동기화시킨다.
모든 메타데이터를 NN의 메모리에 보관하기 때문에 NN의 메모리 한계에 따라 파일 개수에 제한이 있다.
AWS의 object storage로서 파일 저장을 하는 것이 아니다. key, value, versionID를 갖는 오브젝트의 형태로 데이터를 저장한다. 파일 시스템이 아니기 때문에 이 이외의 것은 할 수가 없다.
메타데이터는 storage 외부에 저장되기 때문에 메타데이터 크기에 대한 한계에 얽메이지 않는다.
계층적인 디렉토리 구조가 없고 flat address space에 존재한다. 따라서 POSIX I/O call(open, close, read, write)을 지원하지 않고 GET, PUT만 지원한다.
PUT은 새로운 오브젝트를 만드는 것이다. 생성하게 되면 데이터 저장 위치를 가리키는 UUID가 같이 만들어지게 된다. UUID는 hash 로 간편하게 정할 수 있다.
GET은 UUID를 통해 오브젝트를 받아온다. 오브젝트에 접근하기 위해서 metadata에 접근할 필요가 없이 UUID로 위치를 알 수 있다.
모든 오브젝트는 immutable이다. 오브젝트를 수정하려면 기존의 오브젝트를 받아서 새로운 오브젝트로 복사한 후 PUT을 하고 그 UUID를 받아와야한다.
오브젝트는 기본적으로 한번 생성되면 다시 write가 없기 때문에 read할 때 lock을 잡을 필요가 없다.
UUID를 통해 오브젝트를 가져올 때는 데이터만 가져오기 때문에 정보가 부족할 수 있다.(동영상 파일을 가져올 때 파일명, 데이터 생성 날짜 등이 필요할 수 있다.) 이를 위해 data layer 위에 database layer를 추가함으로써 오브젝트 이름이나 권한 등을 매핑하여 보여줄 수도 있다.
HDFS
S3
Software Defined Storage platform 으로서 클러스터에 object storage를 구현하고 object, file, block 레벨의 스토리지 인터페이스를 제공한다.
RADOS: Ceph Storage Cluster이다. 기본적으로 데이터에 대한 작업이 RADOS를 통해 수행된다.
RadosGW: Object storage이다. AWS S3나 OpenStack Swift와 호환되는 API를 제공한다.
RBD: Block device이다. 스냅샷 및 clone 기능이 있다.
CephFS: File storage이다. 마운트 혹은 사용자 공간에서 파일 시스템으로 사용할 수 있다.
Go Lang으로 짜여진 오픈소스 프로젝트로서 S3와 api compatible한 object storage를 제공한다.
다양한 public cloud에서도 동작할 수 있어서 vendor lock in을 해소해준다.
Ceph는 데이터를 복제해서 보관하기 때문에 노드 확장이나 노드 장애에도 잘 동작을 한다. 하지만 rebalancing이나 recovery 작업이 빠르게 이루어지진 않고 learning curve도 크다.
MinIO의 경우는 배포가 간단하고 데이터에 대한 작업도 빠르다. 문서나 모니터링에 대한 지원은 충분하지 않을 수 있다. on-premise, cloud, hybrid 등 여러 환경에서 세팅이 가능하다는 장점도 있다.
Reference
https://www.ibm.com/cloud/learn/cloud-storage
https://www.ibm.com/kr-ko/cloud/learn/block-storage
https://www.ibm.com/cloud/learn/object-storage
https://data-flair.training/blogs/hdfs-data-read-operation/
https://luminousmen.com/post/hdfs-vs-cloud-based-object-storage-s3/
https://cloud.google.com/blog/products/storage-data-transfer/hdfs-vs-cloud-storage-pros-cons-and-migration-tips
https://docs.ceph.com/en/latest/glossary/#term-Ceph-Object-Storage
https://min.io/
https://www.peerspot.com/questions/how-does-red-hat-ceph-storage-compare-with-minio