[Storage] Block Storage와 File Storage

Block Storage vs. File Storage

최근 Ceph 관련 장애를 겪으면서, 스토리지 개념에 대해 정리 해볼 필요성을 느꼈습니다. 대충, ReadWriteOnce로 쓸 때는 Ceph-Block 을 쓰면 되고, ReadWriteMany로 생성하고 싶을 땐, Ceph-Filesystem을 사용하면 된다는 것은 알겠지만, 왜 그런 것일까요? 오늘 글에서는 둘은 어떻게 다르고, 어떤 특징을 가지고 있는지 알아보겠습니다.

File Storage

File Storage의 역사는 꽤 오래되었습니다. 그리고 유저들에게 가장 친숙한 스토리지 시스템이기도 합니다. 우리의 파일 또는 데이터에 이름을 붙여주고, 이걸 ‘폴더'에 저장합니다. 그리고 위 이미지에서 볼 수 있는 것처럼 파일에 접근할 때, 계층적으로 접근하게 됩니다. 따라서, 우리가 데이터에 액세스해야 하는 경우, 정확한 경로를 알아야 찾을 수 있습니다. (물론 ‘검색’을 활용하면 메타데이터를 이용해서 대강 찾아낼 수는 있지만, 시간이 꽤 오래 걸립니다)

File Storage는 파일 자체적으로 메타데이터를(이름, 위치, 생성일, 크기 등) 관리하고 있고, 이를 계층적 구조로 유지하고 있기 때문에, 개별 파일 단위로 Lock을 걸 수 있습니다. 따라서 여러 사람이 동시에 파일에 접근하는 것을 허용하며, ReadWriteMany로 쓸 수 있는 근거가 됩니다.

File Storage는 거의 모든 데이터를 저장할 수 있으며, 다수의 복잡한 구조의 형태를 저장하기에 유리하며, 사용자가 쉽게 탐색할 수 있습니다.

File Storage의 용량을 키울 땐, 용량을 늘려주는 것만으로는 불가능합니다. 추가로 더 많은 파일 시스템을 추가해 Scale Out 해주어야 합니다.

File Storage를 제공하는 서비스로는 Amazon의 EFS (Elastic File System), Google의 Google Cloud Filestore 등이 있습니다.

Block Storage

Block Storage는 가장 오래되고 간단한 형태의 데이터 스토리지입니다. 위 이미지에서 볼 수 있듯이, Block Storage 시스템에서 데이터는 “block”이라 불리는 고정된 사이즈의 조각으로 쪼개져 저장됩니다. 이렇게 쪼개진 조각들은 다양한 시스템에 분산되어 저장되어 있다가, 사용자의 파일 요청이 있을 때, 해당 파일을 구성하는 조각들을 모음하여 원본 파일로 만들어 돌려줍니다. Block Storage를 사용하는 경우, 애플리케이션은 블록들의 올바른 주솟값을 찾기 위해 SCSI 요청을 보냅니다. 그리고 그렇게 모아온 블록을 하나로 합쳐 완전한 파일로 만들어줍니다. 다만, 데이터가 쪼개져있기 때문에, 블록들이 비슷한 위치에 저장되어 있다면 빠른 성능을 보여주지만, 여기저기 멀리 떨어져 존재한다면, 그만큼 성능도 저하된다는 문제가 있습니다.

그럼에도 File Storage처럼 단일 데이터 path에 의존하고 있지 않기 때문에 꽤 빠른 검색이 가능합니다. 또한 파일의 개수가 늘어나면 성능이 저하되는 File Storage와는 달리, Block Storage는 데이터가 늘어나도 성능 저하가 거의 없기 때문에, 더 많은 데이터를 이용해야 한다면 Block Storage를 적용하는 것이 좋습니다.

Block Storage의 용량을 키우는 방법은 간단합니다. 노드를 좀 더 붙여주면 됩니다.

다만, File Storage와는 달리 Block Storage에선 파일의 무결성을 보장하기 위해 전체 볼륨을 Lock 하고, Read-Only로 만듭니다. 이로 인해 여러 사람이 동시에 파일에 접근해서 쓰거나 읽는 작업을 수행하는 것이 불가능한 구조입니다. (ReadWriteOnce로만 이용 가능)

Block Storage를 제공하는 클라우드 서비스로는 Amazon의 EBS (Elastic Block Store), Google의 Google Cloud Storage가 있습니다.

무엇을 선택해야할까?

그렇다면 Block Storage와 File Storage 중 어떤 것을 선택해야할까요? 정해진 답은 없습니다. 사용하려는 Application의 특성에 맞게 선택하면 됩니다.

예를 들어, 여러 대의 VM 인스턴스가 부팅 시에 참조하는 부트 이미지를 저장하는 부트 볼륨으로 사용해야 하는 경우, Block Storage를 사용하면 됩니다.

만약, 굉장히 낮은 지연시간을 필요로 하는 트랜젹션이 가능한 DB 또는 관계형 DB를 사용하는 경우에도 Block Storage를 사용하면 됩니다.

때로는 정형 데이터 뿐만 아니라, 비정형 데이터까지 섞인 데이터를 취급해야 하는 경우에는 File Storage를 선택하는 것이 좋습니다. 예를 들면, 텍스트 파일과 미디어 데이터를 동시에 취급하는 웹 호스팅 서버를 제공하는 경우가 이 케이스에 해당합니다.

마지막으로, Read와 Write 작업이 동시에 일어나는 등의 협업 공간이 필요한 경우 File Storage를 사용하면 됩니다.

지금까지 다룬 내용들을 정리해보면, 아래 이미지처럼 정리할 수 있습니다. GCP에서 정리한 글에서 발췌한 “어떤 스토리지를 사용해야 할까요?”라는 제목의 이미지입니다.

출처 : https://cloud.google.com/blog/topics/developers-practitioners/map-storage-options-google-cloud

끝으로

충분히 조사하지 못하고 글을 작성하려니, 어려움이 많았습니다. 이후 Object Storage까지 곁들여 조사한 내용을 바탕으로 글을 써볼 계획인데, 이때 조금 더 보완해보아야겠습니다.

만약 이 글이 도움이 되셨다면 글 좌측 하단의 하트❤를 눌러주시면 감사하겠습니다.

혹시라도 글에 이상이 있거나, 오역, 이상한 번역이 있거나, 이해가 가지 않으시는 부분, 또는 추가적으로 궁금하신 내용이 있다면 주저 마시고 댓글💬을 남겨주세요! 빠른 시간 안에 답변을 드리겠습니다 😊

참고

• https://www.redhat.com/ko/topics/data-storage/file-block-object-storage
• https://www.datacore.com/blog/three-types-of-storage-block-file-object/
• https://www.alibabacloud.com/ko/knowledge/difference-between-object-storage-file-storage-block-storage
• https://velog.io/@leesjpr/스토리지File-storage-Block-storage-Object-storage
• https://blog.csdn.net/hwclong911/article/details/90240767
• https://cloud.google.com/blog/topics/developers-practitioners/map-storage-options-google-cloud
• https://rajkumaraug20.medium.com/file-storage-vs-block-storage-vs-object-storage-2519031a2646