[MinIO Study 1주차] MinIO 소개

CoudNet@ 팀의 가시다님께서 리딩하시는 MinIO Study 1주차 스터디 내용 정리

 

스터디 첫 주차에는 MinIO 스토리지에 대해 소개하고 동작 방식을 학습했습니다.
MinIO 는 S3 와 완벽하게 호환되는 오브젝트 스토리지입니다.
이번 글에서는 MinIO 가 왜 오브젝트 스토리지를 선택하게 되었는지 각각의 스토리지 별 특성을 알아보고 그 이유를 확인해보려고 합니다.

 

 

1. Storage

 

 

1.1. Block Storage

 

블록 스토리지는 데이터를 고정된 크기의 블록으로 나누어 저장하는 방식의 스토리지입니다.
블록 스토리지의 주요 특징은 다음과 같습니다.

 

a. 블록 단위 저장

- 블록 스토리지는 데이터를 고정된 크기의 블록 단위로 나누어 저장하는 방식
- 일반적으로 16KB 크기의 블록으로 나누어져 저장
- 하나의 파일은 여러 블록에 흩어져서 저장될 수 있음

 

b. 유연한 배치

- 블록들을 반드시 연속된 위치에 저장할 필요가 없음
- 스토리지 소프트웨어에 의해 자동으로 최적 배치를 수행하여 성능을 높임

 

c. 제한된 메타데이터

- 블록 자체는 단순히 데이터 조각과 ID 만 보유
- 데이터에 의미를 부여하는 메타데이터는 별도의 파일 시스템이나 데이터베이스에서 관리

 

d. 강력한 일관성

- 블록 수준에서의 읽기/쓰기 작업 시 높은 일관성과 정확성을 보장

 

e. 접근 방식

- 일반적으로 iSCSI, Fibre Channel, SATA, SAS 와 같은 프로토콜을 통해 서버에서 직접 디스크처럼 사용

1.2. File Storage

 

파일 스토리지는 데이터를 계층적 디렉터리 (폴더 구조) 와 파일 단위로 저장하는 방식의 스토리지입니다.
파일 스토리지의 주요 특징은 다음과 같습니다.

 

a. 파일 단위 저장 및 접근

- 파일은 전체 단위로 저장되며, 폴더/파일 경로 체계를 통해 접근

 

b. 제한된 메타데이터

- 블록 스토리지에 비해서는 메타데이터 저장 측면에 유연한 면이 있습니다.
- 하지만 파일 이름, 크기, 생성 날짜, 수정 날짜, 권한 등의 몇 가지 제한된 속성에 대해서만 메타데이터가 제공됩니다.

 

c. 동시성 제어 (파일 잠금)

- 파일 손상을 방지하기 위해 한 번에 단일 작성자만 허용 (write lock)
- 다른 사용자는 읽기 전용으로 접근하거나, 작성자의 작업이 완료되면 수정 가능

 

d. 스토리지 계층 구조

- 일반적으로 블록 스토리지 또는 오브젝트 스토리지 위에 파일 시스템 계층을 올려서 구현

 

e. 표준 프로토콜 기반

- NFS(Network File System), SMB(Server Message Block) 같은 특정 파일 저장 프로토콜을 사용

 

 

1.3. Object Storage

 

오브젝트 스토리지는 데이터를 객체(Object) 단위로 저장하는 스토리지입니다.
오브젝트 스토리지의 주요 특징은 다음과 같습니다.

 

a. 객체 단위 저장

- 파일은 잘게 쪼개진 분산 샤드로 저장되고, 요청 시 원본으로 재조립
- 각 객체는 데이터 + 메타데이터 + 객체ID 로 구성

 

b. 풍부한 메타데이터

- 블록 스토리지, 파일 스토리지와는 달리 무제한 메타데이터 첨부 가능
- 이를 활용하면 고급 검색, 분류, 정책 적용이 가능

 

c. 버전화 (Versioning)

- 파일을 잠글 수는 없지만 데이터 무결성을 보장하기 위해 버전 관리 지원
- 규제 요구 사항 충족 가능

 

d. 무한 확장성

- 스토리지를 특정 장비에 제한하지 않고, 노드를 계속 추가하는 방식으로 확장
- 애플리케이션은 항상 동일한 인터페이스 (REST API) 를 사용하기 때문에 확장에 따른 복잡도 최소화

 

e. API 기반 접근

- 전통적인 파일/블록 프로토콜이 아닌, HTTP 기반 REST API 로 접근

 

 

1.4. MinIO 가 Object Storage 를 선택한 이유

 

오브젝트 스토리지가 "대규모 분산 환경"에 최적화된 구조이기 때문

 

MinIO 의 공식문서에 나와 있는 것처럼 페타바이트 규모의 저장 요구사항을 만족하는 현대 애플리케이션 작업 패턴을 지원하도록 설계되기 위해서는 오브젝트 스토리지가 가장 적합했기 때문입니다.

 

출처: https://docs.min.io/community/minio-object-store

 

2. MinIO

 

 

2.1. MinIO 소개

 

MinIO 는 AWS S3 와 완벽하게 호환되는 고성능 오브젝트 스토리지 솔루션입니다.

 

AWS S3 는 오픈소스가 아니지만 거의 모든 애플리케이션들이 AWS S3 와 호환하기 위해서 S3 API 를 사용하고 있습니다.
그렇기 때문에 오브젝트 스토리지에서는 AWS S3 API 가 실질적인 표준이 되고 있습니다.
MinIO 는 이러한 점을 활용하기 위해 S3 를 Reverse Engineering 을 하여 S3 API 와 완벽하게 호환되도록 설계되었습니다.

 

이러한 점 때문에 개인적으로 MinIO 의 동작 방식을 이해하는 것은 오브젝트 스토리지와 S3 의 동작 방식을 이해한다는 것과 동일하다고 생각합니다.

 

 

2.2. MinIO 배포 방식

 

MinIO 의 배포 방식은 크게 3가지가 존재합니다.

 

1. Single-Node Single-Drive (SNSD, Standalone)

- 단일 노드 + 단일 드라이브(디스크) 배포
- 주로 로컬 개발 및 테스트 환경에서 사용

 

2. Single-Node Multi-Drive (SNMD, Standalne Multi-Drive)

- 단일 노드 + 다중 드라이브(디스크) 배포
- 저성능, 용량 요구사항이 낮은 작업
- 다중 드라이브에 대한 Failover 동작 (Erasure Coding, Parity 적용)

 

3. Multi-Node Multi-Drive (MNMD, Distributed)

- 다중 노드 + 다중 드라이브(디스크) 배포
- 운영 환경, 고성능 환경
- 다중 드라이브에 대한 Failover 동작 (Erasure Coding, Parity 적용)

 

MinIO 배포 아키텍처

 

운영환경 MinIO 배포는 동종 스토리지 및 컴퓨팅 리소스를 갖춘 최소 4개의 MinIO 호스트로 구성됩니다.

 

 

 

2.3. MinIO 동작 방식

 

MinIO 스토리지에 객체 읽기/쓰기 동작방식은 다음과 같습니다.
객체 읽기 쓰기 동작방식은 아래 MinIO 공식 유튜브를 확인하시면 이해하기 쉽습니다.

 

출처: MinIO 공식 유튜브

 

 

• MinIO 객체 쓰기 프로세스

1. MinIO 가 객체를 전달 받으면 MinIO 클러스터 내에서 객체를 저장할 위치를 찾기위해 결정론적 해시 프로그램 동작
2. 먼저 객체 이름에 결정적 해시 함수를 적용하여 고유한 해시 값을 생성
3. 그 후, 해시 값은 Mod 함수를 통해 객체가 최종적으로 저장될 드라이브 세트를 결정
4. 이와 별개로 객체 파일 자체는 Erasure Code 엔진에 의해 데이터와 패리티 블록으로 분해
5. 분해된 블록을 결정된 드라이브 세트를 이용해 각 드라이브에 저장

 

 

• MinIO 객체 읽기 프로세스

1. 객체 이름 기반으로 요청 수신
2. 객체 이름은 객체 쓰기 프로세스에서 그랬던 것과 같이 결정적 해시 함수와 Mod 함수를 통해 객체가 저장된 드라이브 세트 확인
3. 각 드라이브에 저장된 블록이 확인되면 Erasure Code 엔진에 의해 재조립
4. 이 때, 전체 객체의 무결성을 검증한 후 클라이언트로 전송

 

 

2.4. MinIO 가용성 및 복원력

 

MinIO 는 드라이브 또는 노드 수준 장애 발생 시 가용성과 복원력을 제공하는 핵심 구성 요소로 Erasure Coding (삭제 코딩) 을 구현합니다.
MinIO 는 각 객체를 데이터 및 패리티 (Parity) 샤드로 분할하고 해당 샤드를 단일 삭제 세트에 분산합니다.

 

출처: MinIO 공식 유튜브

 

 

• 패리티 (Parity)

 

Parity 는 동등함을 의미하는 영어 단어
데이터를 전송할 때 해당 데이터가 동등한 지(동일한 지), 오류는 없는 지 확인하기 위해 추가하는 값들을 의미
데이터를 지킬 수 있는 추가적인 정보이며, 데이터를 복구하기위한 여분 정보

 

 

• 삭제 코딩 (Erasure Coding)

 

데이터를 여러 조각으로 나누고, 추가적인 패리티(Parity) 조각을 생성해서 저장하는 기법
원본 데이터가 일부 소실되더라도 남은 데이터 조각과 패리티 조각을 이용해서 수학적으로 복구 가능

 

즉 원래라면 데이터를 균일한 크기로 나눌 때 5개가 된다고 한다면,

삭제 코딩 기법에서는 5개 + 패리티 3개를 합쳐서 8개의 데이터를 생성하는 것을 의미하며 패리티 3개에는 기존 데이터를 복구할 수 있는 힌트가 포함되어 있다고 생각하면 됩니다.

 

이를 통해서 기존 데이터가 3개까지 손실이 된다 하더라도, 패리티 블록 3개를 통해서 손실된 기존 데이터 3개를 복구할 수 있게 됩니다.
다만, 기존 데이터 손실이 4개가 되어 패리티 블록 개수를 초과하게 된다면 기존 데이터는 완벽하게 복구할 수 없습니다.

 

여기서 중요한 점은 기존 데이터 블록 외에 추가적인 패리티 블록이 저장될 스토리지 용량이 필요하기 때문에,

패리티 블록의 개수를 늘리면 늘릴 수록 가용 가능한 스토리지 용량은 줄어든다는 것입니다.

 

 

---

 

이번 글에서는 MinIO 의 개념에 대해 작성했습니다.
MinIO 개념과 동작 방식을 공부하면서 스토리지에 대한 개념을 다시한 번 정립할 수 있었고, 오브젝트 스토리지 동작 방식 또한 이해할 수 있게 되었습니다.

 

실제 MinIO 를 설치해보고 사용해보는 것은 다음 글에 이어서 작성하도록 하겠습니다.