EBS 내부구조 분석

Block Storage를 사용하는 방법은 다양하다.

• NAS(Network Attached Storage)
• DAS(Direct attached storage)
• SAN(Storage-Area Network)

여기서 나는 SAN에 대해 고민해 보려 한다.

https://aws.amazon.com/ko/ebs/

블록 스토리지 | Elastic Block Store | Amazon Web Services

SAN 네트워크 구조

AWS의 EBS는 SAN 구조로 개발되어 있다.(물론 전용 호스트나 인스턴스의 경우는 DAS일수도 있다만...이 부분은 좀 더 확인이 필요하다)

SAN은  특수 목적용 고속 네트워크로, 대규모 네트워크 사용자를 위해 서로 다른 종류의 저장장치를 데이터 서버와 연결하여 별도의 네트워크로 관리하는 시스템이다. SAN을 구축하기 위해서는 NAS에 비하여 많은 비용이 들고, 기존에 사용하던 시스템의 업그레이드가 필요하다. 서로 다른 기기를 하나의 SAN으로 연결하고자 한다면 별도의 매니지먼트가 필요하다.

SAN은 각 서버과 스토리지 사이에 광 스위치를 넣어 네트워크의 개념을 도입한 것이다. 쉽게 이해할 수 있도록 설명하자면, 우리가 일반적으로 사용하는 LAN선 대신에 광케이블을 사용하는 것이고, 광케이블을 위한 각 서버용 모듈과 네트워크 스위치를 사용한다고 보면 된다. 라우터, 허브, 게이트웨이 등을 연결에 사용하게 되면 다양한 네트워크 구축도 가능하지만 광을 이용한 네트워크를 SAN의 표준으로 보고있다.

SAN의 장점은 빠른 전송속도와 안정적인 시스템을 이야기 할 수 있습니다. 대용량의 데이터를 연결된 서버에 상관없이 원거리에 분산된 저장장치 사이에서 데이터를 주고 받을 수 있습니다.

SAN의 단점은 초기 구축비용이 많이 들고 구성이 복잡합니다.

 

AWS Cloud의 특성상 Elastic하게 Storage가 증감되며 수시로 마운트 되고 언 마운트 되머 삭제된다. 그렇다면 궁금하게 EBS 볼륨을 만들때 어떤 동작을 하는지? 스냅샷은 어떻게 되는지에 대하 분석해보려 한다.

EC2에서 AMI를 생성할때

우선 AMI 를 생성하면 EBS스냅샷도 같이 생성되며 S3에 저장된다. 근데 신기하지 않나? 500GB를 냅샷에서 복구해도, 1TB를 복구해도 바로 EBS가 생성된다. 이유는 RTO에 있다

AMI를 사용해서 EC2를 생성할때

우선 만들고 데이터를 가져올때 S3와 통신하여 Lazy loading되어 파일을 찾게된다. 이것 때문에 초기 EBS 생성시 Init Latency가 발생한다. 왜 Layency를 감수해서라도 빠르게 Provisioning이 되는가?

RTO와 매우 깊게 관련이 있다. AutoScaling과 같이 수평전개시 빠르게 서비스를 전개하여 실행하기 위함이 강하다.

그래서 우선적으로 생성부터 진행되는것

Amazon EBS 볼륨 초기화

Amazon EBS 볼륨 초기화 - Amazon Elastic Compute Cloud

위의 링크에서도 명시되어 있다. 초기 생성시 초기화 과정에 I/O 성능이 예상 수준보다 50%미만으로 저하된다. 그렇기 때문에 도큐먼트에 보는것처럼 dd또는 fio 명령어를 통해 초기 실행시 강제적으로 파일들을 모두 읽어와 초기화 시켜주는 것을 권장한다.

생성후 EC2에서 EBS Volume을 사용할때

다만, 매번 이렇게 실행 시킬수 없기 대문에 AWS에서는 EBS FSR(Fast Snapshot Resrtore)를 제공한다. 미리 SAN영역에 해당 EBS의 공간을 Provisioning해 놓고 실제 사용시 바로 Attach하여 사용이 가능한것. 이때 미리 해당 영역을 확보 하여 사전에 파일들의 객체 메타데이터(덴트리든 아이노드든)를 로딩해 놓기에 지연시간 없이 바로 EBS생성 및 사용이 가능하다.

그렇기 때문에 각 가용영역으로 로딩을 별도로 지원하며 그만큼 자원을 미리 가지고 있기에 각각 비용도 크게 발생한다.