Amazon S3은 많은 서비스 엔지니어들이 익숙한 스토리지입니다.
2006년부터 지금까지 엄청난 스케일의 작업들을 문제없이 처리하고 있습니다.
- 초당 10억개의 Request 처리
- 초당 400 terabits 처리
- 280 trillion objects 저장
이 정도의 스케일을 지원하기 위해서 어떤 구조를 가지고 있는지 확인해 보려고 합니다.
Amazon S3 란?
Amazon S3의 사용자 입장에서의 특징은 아래와 같습니다.
0. 일반적인 파일 시스템이 아닌 Object Storage 입니다.
1. REST API를 사용해서 각 Object에 엑세스를 할 수 있습니다.
2. 내구성(Durability)가 99.999999999%입니다. (거의 절대로 데이터를 손실하지 않습니다.)
3. 각 Object의 버전 관리 기능이 있다.
4. 단일 파일을 5TB 까지 저장 가능합니다.
5. 정적 웹사이트 호스팅이 가능합니다.
6. 저장가능한 파일 개수의 제한이 없습니다
이러한 특징들 중에서 이번 포스트에서 살펴 볼 것은 Object Storage라는 특징입니다.
Object Storage Architecture
왜 Amazon S3는 파일 시스템의 방식이 아닌 Object Storage를 사용하게 된것일까요?
Object Storage의 아키텍처에 대해서 더 알아 볼 필요가 있습니다.
일반적으로 알려진 Object Storage 아키텍처는 아래와 같이 표현 될 수 있습니다. (실제 구현은 Object Storage 아키텍처마다 다를 수 있습니다.)
Object Storage Component
Object Storage Architecture 에는 5개의 주요 Component가 있습니다.
1. Object
2. Object based Storage Device (OSD)
3. Installable File System
4. Metadata Server
5. Network Fabric
1. Object
Object는 실제 저장하고 싶은 데이터와 이 데이터를 더 쉽게 관리하기 위한 몇 가지 필요한 메타 데이터들을 가지고 있습니다.
이 메타 데이터들은 메타데이터 서버에서 트래킹 하고있습니다.
그리고, 모든 Object는 Object ID (size는 사용 DB마다 다름)을 통해서 접근이 가능합니다.
그리고 해당 Object는 < Object ID, Object의 Offset, Object의 길이. > 이 세가지 값으로 접근이 가능하게 됩니다.
또한 Object는 유저의 Owner ship이나 Access Control과 관련된 정보를 metadata에 포함하고 있습니다.
2. Object based Storage Device (OSD)
OSD는 CPU, RAM, 디스크 및 Network 인터페이스를 포함합니다.
위의 장비들을 이용해서 local object store 관리, 자동 서비스 그리고 네트워크를 통한 데이터 저장을 지원합니다.
OSD는 4가지 중요한 역할을 합니다.
1. 데이터 저장 : Object ID를 통해서 데이터에 접근 가능하게 합니다. 컴퓨팅 노드는 Object ID, Offset, Length를 통해서 해당 데이터를 요청할 수 있습니다.
2. Intelilgent Layout : 디스크에 데이터가 저장되는 방식을 결정합니다. 캐싱과 같은 기능도 포함합니다.
3. Metadata Management : linux의 inode 정보와 같은 내용들을 가지고 있습니다. Metadata 서버는 Object ID만 관리하고 섹터나 다른 정보들은 Object에게 맡깁니다. 기존의 파일시스템의 역할을 OSD에게 일부 나눈것입니다.
4. 보안 : authorization이나 encryption이 OSD를 통해서 지원합니다.
OSD는 실제 스토리지를 지원하기 위한 물리적인 디바이스들 입니다.
OSD는 아래와 같이 여러 Pool과 여러 OSD들로 데이터들을 replicate 할 수 있습니다.
3. Installable File System
컴퓨팅 노드와 합쳐져서, POSIX 파일 시스템 명령어와 운영 체제로부터의 데이터를 수용하며, OSD들을 직접 지정하고 여러 OSD에 걸쳐 Object를 분산시킵니다.
예를들면 S3fs-fuse 같은게 있습니다.
4. Metadata Server
인증, 파일 및 디렉토리 엑세스 관리, 캐시제어 , 용량 관리, 확장 등의 역할을 합니다.
메타데이터 서버는 블록/섹터 매니지먼트를 OSDs 에게 분산시키고 ( 대략 workload의 90%), 파일/메타데이터 관리 ( workload의 10%)를 합니다.
또한, 이 파일/메타데이터들은 여러 서버로 분리되어 scalable cluster를 구성할 수 있습니다.
Metadata Server의 Scalability는 전체 Object Storage의 용량과 성능을 포함한 균형있는 확장성을 만들어 주는 핵심입니다.
5. Network Fabric
Network Fabric은 Object Storage Architecutre의 핵심 요소입니다.
Network Fabric을 통해서 Object-based Storage Devices, Metadata 서버, 그리고 Compute node를 하나의 구조로 묶을 수 있습니다.
위의 아키텍처에서 실제로 데이터의 Read와 Write는 어떤식으로 작동하는지 확인해 보겠습니다.
데이터 읽기
1. 클라이언트가 Metadata Server 에 읽기를 요청합니다.
2a. Metadata Server가 Object 리스트를 반환합니다.
2b. Metadata Server가 Auth Token과 같은 Security 데이터를 같이 반환해줍니다.
3. 클라이언트는 Auth Token 데이터를 포함하여 OSD에 직접 Read 데이터를 요청합니다.
4. 클라이언트와 OSD간의 직접적인 데이터 전송이 이루어 집니다.
데이터 쓰기
데이터 읽기와 비슷한 과정을 거칩니다.
1. 클라이언트가 Metadata Server에 쓰기를 요청합니다.
2a. Metadata Server는 Object 리스트를 반환합니다.
2b. Metadata Server는 마찬가지로 Security 데이터를 반환합니다.
3. 클라이언트는 Security 데이터와 함께 쓰기 요청을 직접 OSD에 보냅니다.
4. 클라이언트와 OSD 사이의 직접적인 데이터 전송이 이루어 집니다.
Object Storage 의 이점
위의 특징들로 인해서 Object Storage는 아래와 같은 장점을 가지고 있습니다.
1. 우수한 검색 가능성: 오브젝트 스토리지 아키텍처의 경우 메타데이터가 오브젝트에 자체적으로 포함되어 있습니다.
따라서 IT 관리자는 메타데이터를 오브젝트와 결합하기 위해 데이터베이스를 구축할 필요가 없습니다. 게다가, 시간이 흐름에 따라 맞춤형 메타데이터를 생성, 변경, 추가할 수 있습니다. 가장 중요한 이점은 맞춤형 메타데이터 덕분에 이전 기술인 파일 스토리지와 다르게 오브젝트 스토리지는 간편하게 검색하고 탐색할 수 있다는 점입니다.
2. 무한한 확장성: 아마도 오브젝트 스토리지를 선택하게 만드는 가장 두드러진 장점은 무한한 확장성일 것입니다. 기업들은 필요에 따라 노드를 추가하고 수평적으로 확장할 수 있습니다. 오브젝트에 메타데이터가 포함되어 있으므로, 시스템이 Hierarchy가 없으니 "flat" 하다 표현 됩니다. 따라서 기존의 스토리지 시스템에 비해 거의 무한한 확장이 가능해집니다.
3. 비용 효율성: 확장성과 관련된 얘기를 하자면, 대량의 데이터를 생성하는 기업은 예산에 가장 적합한 시스템이 필요합니다. 오브젝트 스토리지는 쉽게 확장 가능하므로, 용량과 검색 가능성이 제한되지 않는 환경에 데이터를 저장하여 비용 효율성을 훨씬 더 향상할 수 있습니다.
4. 복원력 향상: 오브젝트 스토리지는 오브젝트 파일을 대상으로 빠르고 안정적인 재해 복구를 제공합니다. 오브젝트가 생성되면 자동으로 1+ 노드에 복제되므로 이것이 가능해집니다. 재해가 발생할 경우, 데이터 손실을 염려하지 않고 안심해도 됩니다.
이런 장점들을 토대로 S3 Storage는 지속적으로 확장되고 유지되어 왔음을 알 수 있습니다.
이와 반대로 Object Storage는 아래와 같은 한계점이 있습니다.
Object Storage의 한계
1. 접근 속도 : 파일 시스템이나 블록 스토리지에 비해서 상대적으로 접근 속도가 느릴 수 있습니다. Object Storage는 HTTP 오버헤드또한 가지고 있으며, 빈번한 작은 파일 혹은 데이터베이스 의 읽기/쓰기에는 최적화 되어 있지는 않습니다.
2. latency : 네트워크를 기반으로한 스토리지라서 네트워크 지연시간의 영향을 받습니다. 고 성능이 필요한 곳에서는 문제가 될 수 있습니다.
3. 마이그레이션 제한 : 파일시스템이나 블록스토리지에서 Object Storage로의 마이그레이션은 복잡하고 시간이 많이 소요 될 수 있습니다.
이러한 한계점이 있으므로, 장점을 최대화 할 수 있는 영역에서 Object Storage를 많이 사용하도록 성장해 온것 같습니다.
아래와 같은 영역이 Object Storage가 잘 할 수 있는 영역입니다.
Object Storage의 활용처
1. 정적 웹 자원 저장 : 웹사이트의 이미지, 비디오, CSS 파일, 자바스크립트 등의 정적 콘텐츠를 호스팅합니다.
2. 비디오 및 이미지 저장소 : 대규모 멀티미디어 파일을 저장합니다.
3. 데이터 백업 및 아카이브 : 데이터의 여러 복제본을 서로 다른 지리적 위치에 분산시켜 저장해, 재해 발생시 데이터 복구를 보장합니다.
4. 클라우드 네이티브 앱의 데이터 레이크 : 빅데이터 분석 및 처리를 위한 데이터 레이크 구축에 사용됩니다. 대량의 비 구조화된 데이터를 저장합니다.
위와 같은 데이터들을 주로 저장하는데 사용합니다.
다음 포스트에서는 S3 Storage가 어떤 문제를 해결하고 발전 해 왔는지에 대해 중점적으로 다뤄보도록 하겠습니다.
참고 : Amazon S3 스토리지 클래스의 종류
스토리지 클래스 | 주요 특징 | 첫 바이트 레이턴시 | Durability | Availiability |
S3 스탠다드 | - 자주 엑세스 하는 (한달에 한번 이상 엑세스) |
밀리 초 | 모두 99.999999999% 초과 |
99.99% |
S3 Intelligent-Tiering | - 액세스 패턴 불확실하고 변경되는 - 자동 비용 절감 |
밀리초 | 99.9% | |
S3 Express One Zone | - 가장 자주 엑세스 하는 - 1개의 zone |
한 자리수 밀리초 | 99.95% | |
S3 스탠다드 IA (Infrequent Access) | - 자주 엑세스 하지 않는 | 밀리 초 | 99.9% | |
S3 One Zone IA (Infrequent Access) | - 자주 엑세스 하지 않는 - 1개의 zone |
밀리초 | 99% | |
S3 Glacier Instant Retrieval | - 일년에 몇번 엑세스하는 | 밀리초 | 99% | |
S3 Glacier Flexible Retrieval | - 거의 엑세스 하지 않는 - 저렴한 |
분 또는 시간 | 99.9% | |
S3 Glacier Deep Archive | - 거의 엑세스 않는 - 매우 저렴한 |
시간 | 99.9% |
각 스토리지 클래스 별로 저장하는 데이터의 특징이 다릅니다.
스토리지 클래스 별로 가격과 목표로하는 데이터의 특징이 다르니 데이터에 적절한 위치를 결정하고 저장하면 될것같습니다.
참고 : Storage 비교 (Object vs File vs Block)
Object Storage | File Storage | Block Storage | |
Performance | Big content and High stream throughput | Perform best for smaller files | 데이터베이스와 transactional data에 좋은 성능 |
Geography | 여러 region에 저장 가능 | Data needs to be shared locally | The further the distance between storage and application, the higher the lantecy |
Scalability | 페타바이트 및 그 이상 스케일 까지 무한 확장 가능 | Potentially scales up to millions of files but can't handle more | Addressing requirements limit Scalability |
Analytics | Customizable metadata | limited number of set metadata tags | No metadata |
참고 : Key-Value Storage vs Object Storage
참고 : 여러 회사들의 Object Storage Architecture
참고 : 용어설명 - 내구성 (Durability) 과 가용성 (Availability)의 차이
데이터의 내구성 (Durability)는 서비스의 중단 또는 장애 발생 시 손실 또는 손상으로부터 데이터를 잘 보호하는 것을 의미합니다.
물론 성능의 저하 없이 유지하는것을 포함합니다.
반면, 데이터의 가용성 (Availability)는 사용자가 데이터를 요청되었을때 바로 사용을 가능한지가 중요한 요소입니다.
데이터의 내구성과 가용성 둘 다 수치적으로 많이 표현을 하곤합니다.
데이터 내구성의 경우에는 위의 AWS S3의 예시에서도 볼 수 있듯 "11 nines (99.999999999%)"로 많이 포현합니다.
그 의미는 10억개의 Object를 100년동안 단 1개도 잃어버리지 않을 수 있다는 것을 의미합니다.
그리고, 데이터 가용성 = (데이터 사용 가능 시간) / ( 데이터 사용 가능 시간 + 사용 불가능한 시간) 으로 계산합니다.
예를 들어서, 하나의 이미지 파일이 7일 (168시간) 중 145시간만 엑세스가 가능하다면
데이터의 가용성 = 145 / (145 + 23) % = 86.30 % 인것이지요.
일반적으로 가용성은 "5 nines (99.999%)" 혹은 "11 nines (99.999999999%)" 로 많이 표현하는데요.
"five nines (99.999%)" 가용성의 의미는 1년에 5분정도의 사용 불가능한 시간을 의미합니다.
위의 특징으로 보았을때 AWS S3의 내구성은 99.999999999%로 견고하게 데이터를 보존하고있다고 볼 수 있겠습니다.
위와 같은 내구성에도 불구하고 아래와 같은 데이터 loss 케이스가 있다는 점도 알려드립니다.
버지니아 북부(US-EAST-1) 리전의 Amazon S3 서비스 중단 요약
참고 문서
'CS 지식 > 아키텍처' 카테고리의 다른 글
Amazon S3 : 2. Massive Scale (0) | 2024.04.14 |
---|
개발 및 IT 관련 포스팅을 작성 하는 블로그입니다.
IT 기술 및 개인 개발에 대한 내용을 작성하는 블로그입니다. 많은 분들과 소통하며 의견을 나누고 싶습니다.