[reinvent 2024] 올바른 AWS 스토리지 서비스 선택하기
Summary
AWS는 애플리케이션 마이그레이션, 데이터 백업, 온프레미스 애플리케이션과 클라우드 스토리지 통합, 데이터 레이크 구축, 클라우드 네이티브 애플리케이션 개발 등 다양한 사용 사례에 맞춰 설계된 여러 가지 스토리지 서비스를 제공합니다. 여러 옵션이 제공되므로 서비스 불일치와 불필요한 복잡성을 피하기 위해 필요를 신중하게 평가하는 것이 중요합니다. 우리의 목표는 워크로드 및 애플리케이션 요구 사항에 맞는 적절한 AWS 스토리지 서비스를 선택하는 데 도움을 주어 필요에 따라 확장할 수 있는 유연성을 제공하는 것입니다. 이 세션은 참가자들에게 다양한 시나리오와 상황에 맞는 AWS 스토리지 서비스를 선택하는 데 대한 명확한 이해를 제공합니다.
리인벤트 2024 테크 블로그의 더 많은 글이 보고 싶다면?
Overview
들어가며
클라우드를 처음 사용하는 것만큼이나 스토리지를 어떻게 선택하느냐는 인스턴스보다도 더 신중할 필요가 있습니다.
본 세션은 Chalk Talk이므로, Breakout세션보다 좁은 장소에서 더 적은 장표를 제공하고, 소규모 인원들이 많은 커뮤니케이션을 권장하도록 설계된 세션입니다. 스토리지에 대해 떠들고 듣는 것으로도 도움이 되는 세션을 지향합니다.
스토리지 서비스에 대해 폭넓고 이야기하고, 모든걸 다룰 수 없으니 얕게 다룹니다.
공통된 고객 시나리오로 출발해서, 주요 고려사항, AWS가 제공하는 스토리지 서비스 전반, 각자 자신들의 유즈케이스에 적합한 스토리지 서비스 선택하기로 구성되어 있습니다.
공통된 고객의 시나리오부터 살펴보시면, 왼쪽부터 순서대로 다음과 같습니다.
- Data migration
- Building apps with cloud storage
- Building Data lake
- Hybrid Cloud storage for On-premise apps
- Data protection 입니다.
그리고, 스토리지를 선택할때 따지지 않을 수 없는 주요지표들이 있습니다.
성능, 가용성, 비용, 보안, 데이터 보호, 재해 복구 입니다. 성능은 적절한지? 높은 수준의 내구성과 가용성이 보장되는지? 선택한 스토리지를 사용하게될 애플리케이션의 데이터 접근 방식은 어떻게 되는지? 읽기만 하는건지? 쓰기도 해야하는건지? 이를 위해 부여해야하는 권한은 어느 정도인지? 자체 암호화를 사용하는지? 데이터 누적되는 패턴은 어떻게 되는지? 재해 복구대비 백업하는 방식은 어떤 규정 준수가 필요한지? 등등의 것을 모두 고려해야 합니다.
실상은 사용 전에 이해관계자로부터 이에 대한 정보를 얻기어려운 것이 현실이고, 초기 사용부터 얼마간의 기간이 지난 후 성능이 느리다든지, 쓰기가 불가하거나, 사용자별로 권한이 분리되어야한다든지의 세부사항이 발생하게 됩니다. 그래서, 폭넓게 어떠한 스토리지들이 제공되는지 알아볼 필요가 있습니다.
AWS가 제공하는 모든 스토리지 서비스들이고, 13개를 제공하지만 5개그룹으로 분류할 수 있습니다.
먼저 객체 스토리지에 S3가 있습니다. 최근 테이블 버킷 등의 기능이 최근 출시되었고, AWS가 제공하는 스토리지 중 가장 비용효율적인 서비스입니다.
그 다음, 블록 스토리지를 제공하는 EBS가 있습니다. EBS는 인스턴스에 연결되어 동작하며 우리가 사용하는 디스크와 가장 비슷하게 동작합니다. EBS는 단일 인스턴스에 장착하여 사용하는, 친숙하지만 확장성과는 거리가
있는 스토리지입니다. 물론, 사이즈증가는 가능하지만, 1대의 EBS볼륨을 다중 인스턴스에 연결할 수는 없습니다.
그리고, 데이터 전송과 마이그레이션을 위한 Storage Gateway, DataSync, Transfer Family, Snowball이 있습니다. Storage Gateway는 On-premise 애플리케이션 및 데이터와 클라우드로 전송하는 일종의 세련된 방법입니다. File Gateway, Tape Gateway, Volume Gateway로 선택하여 On-premise에 위치한 스토리지타입에 맞게 전송할 수 있습니다.
Snowball은 오프라인 전용이며, 네트워크 대역폭이 형편없거나 격오지, 극지, 폐쇄망 등 특수한 경우에 사용됩니다.
오늘날 스토리지는 네트워크와 불가분의 관계에 있으니, 이 특성 자체가 스토리지에 녹아든 서비스가 있습니다.
가장 많은 스토리지 서비스를 보유한 파일 스토리지입니다. EFS, File cache를 제외한 4개 서비스가 FSx패밀리입니다. EFS의 성능에 만족을 못하는 상태에서 예산이 충분하다면, FSx패밀리의 선택도 좋습니다. FSx는 NetApp ONTAP, Windows File Server, Lustre, OpenZFS 로 구성됩니다.
고객 시나리오로 돌아가 데이터 Migration의 주요 항목 5가지를 살펴봅니다.
- 어떤 종류의 데이터가 어디로 전송되어야 하는가?
- 1회성 전송인가 혹은 지속적으로 재전송해야 하는가?
- 단방향 전송인가 혹은 양방향 전송인가?
- 얼마나 많은 데이터가 있으며, 얼마나 자주 전송해야하는가?
- 전송목적지까지의 구간별 네트워크 대역폭은 얼마나 확보되었는가?
S3 File Gateway의 아키텍처입니다. On-premise근처에 사용자가 직접설치하는 가상머신입니다. S3 File Gateway가상머신은 S3의 접근경로와 성능을 위한 파일 캐시를 제공합니다. On-premise에 Storage Gateway를 설치하는 것만으로도 클라우드의 무제한 스토리지를 갖는것과 동일한 효과가 있습니다.
Datasync는 전송도 좋지만, 자동화된 전송 – 동기화에 중점을 둔 서비스입니다.
On-premise에 위치한 데이터를 클라우드로 전송하거나 혹은 수신하거나 주기적으로 데이터를 동기화할때 DataSync가 사용됩니다. 전송도 쉽게 해주지만, 전송에 대한 스케줄링 기능이 있으므로 이를 통해 주기적인 데이터 동기화를 쉽게 할 수 있습니다. 대규모 데이터 전송에 적합하므로, 데이터 무결성 검증기능도 지원합니다.
DataSync는 타 클라우드 스토리지서비스와도 연동이 가능합니다. Google cloud storage, Azure Blob storage, VMware, NAVER, Alibaba도 Datasync의 지원대상입니다.
그리고, AWS에서 데이터를 저장해야한다면 단연코 S3입니다.
확장성, 회복력, 내구성, 비용효율성 등이 가장 잘 구현되고 쉽게 쓸 수 있는 객체 스토리지입니다. Storage Gateway의 통합도 잘되어 있으므로, 사용하는데 가장 보편적으로 권장하고 사용하는 스토리지입니다.
모든 데이터의 일반적인 기착지는 S3이며, 모든 방면에서 폭넓게 사용되는걸 보실 수 있습니다.
Migration의 7R전략에서 Lift-and-Shift의 경우에도 좋은 해법을 제시하는데, 이는 손쉬운 접근과 사용법과 많은 분석도구의 지원이 용이합니다. 일단, S3에 데이터를 집어넣기만 하면, 그 다음스텝으로 이동하는데 많은 선택지가 제공됩니다.
마지막으로 On-premise, Hybrid, Cloud환경에서 데이터 보호 중앙화를 나타내는 Backup서비스가 있습니다.
On-premise에서는 백업을 위해 전통적인 스토리지어레이에 백업어플라이언스가 연결되어 디스크건 테이프건 물리적인 형태의 미디어로 백업을 받게됩니다.
Hybrid의 인프라라면 Storage Gateway를 사용해서 S3백업하는 방법도 있지만, AWS Backup for VMware를 통해 On-premise의 물리적 스토리지의 데이터를 클라우드의 Backup으로 백업하는 방법도 있습니다. 물론, 클라우드 인프라 내에서의 Backup이 제시하는 데이터 보호의 안전성과 신뢰성은 최고 수준입니다.
결론
Chalk talk방식으로 스토리지에 대해 정해진 답변없이 유즈케이스만으로 신나게 떠들었던 세션이었습니다.
세계에 퍼져있는 AWS스토리지 엔지니어들이 경험한 대규모 데이터와 사용 사례에 얽힌 이야기들이 대기업부터 낡은 데이터센터의 테이프, 화학연구소의 연구데이터, 극지방의 데이터 이동까지 각자의 사례만큼이나 각자의 일과 어려움을 웃으며 공감하며 승화되는 자리였습니다.
그럼에도 스토리지 전반을 살펴보며, 꼭 가져가야하는 주요지표와 주요질문들은 스토리지선택을 진행하는데 있어 가장 합리적인 제안이었던 것 같습니다.
영어를 좀 더 잘했으면 더 잘 참여할 수 있었을텐데, 하는 아쉬움이 개인적으로 가장 많이들었던 세션이었습니다.