단일 인스턴스에서 EBS가 있는데, S3를 왜 사용해야 할까?

이번에 DND에 참여하면서, 새로운 도메인을 경험할 기회를 얻었다.

아직 초반이라 서버 구성이나 소셜 로그인 같은 기능들을 먼저 구현하고 있는데, 현재 서버는 운영 서버의 트래픽이 많지 않을 것을 고려해서 단일 인스턴스로 운영할 계획이다. 그런데 S3 버킷을 만들고 서버와 연결 구성하기 전 문득 이런 생각이 들었다.

 

"단일 인스턴스로 운영한다면, S3말고 EBS(EC2에 연결된 스토리지)를 사용하면 되는거 아닌가?"

 

결론부터 말하면, 필요하다. 답을 찾기 위해 먼저 두 서비스가 어떻게 다른지 알아보자.

 

EBS와 S3, 무엇이 다를까?

EBS(Elastic Block Store)는 EC2에 연결되어 사용하는 가상 하드디스크이다. 인스턴스에만 연결되기에 해당 인스턴스의 로컬 하드 디스크처럼 사용할 수 있다. 특징으로는 블록 스토리지(Block Storage)라는 것인데, 하드 디스크나 SSD처럼 데이터를 일정한 크기의 블록 단위로 저장한다. 또한 로컬 하드디스크처럼 동작하기에 낮은 지연시간(low latency)으로 빠른 읽기/쓰기가 가능하다.

S3(Simple Storage Service)는 아마존에서 제공하는 객체 스토리지 서비스이다. EC2와 독립적으로 존재하는 별도 서비스이기에 HTTP/HTTPS 통신을 통해 파일들을 저장한다. 그래서 EBS에 비해 읽기/쓰기 작업이 느리다. 또한, 객체 스토리지(Object Storage)이다. 이는 각 파일을 객체로 보고 하나의 독립적인 단위로 저장한다.

정리하면 EBS는 "로컬 하드디스크처럼 빠르게", S3는 "네트워크를 통해 안전하게" 데이터를 저장하는 방식이다. 그렇다면 단일 인스턴스 환경에서도 S3가 필요한 이유는 무엇일까?

단일 인스턴스에서도 S3가 필요한 이유

확장성 측면

현재는 트래픽이 많지 않을걸 고려해서 단일 인스턴스로 했다고 하지만, 만약 운영 서버의 트래픽이 많아져서 EC2를 하나 더 생성해야 하는 상황이 왔다고 생각해보자. EBS를 사용한다면, 해당 스토리지에 접근하기 위해서 기존 EC2의 내용을 그대로 새로운 EC2에 복사해야 할 것이다. 혹은 기존 EC2-1에 이미지 요청 API를 만들어서, EC2-2가 이미지가 필요할 때마다 EC2-1에 요청하는 방식도 있을 것이다.

하지만, 두 방법 모두 비효율적이고 확장성면에서 좋지않다. 새로 복사하게 되면 스토리지에 대한 비용이 정확히 2배 증가하게 되고 새로운 이미지가 저장될 때마다 두 EC2의 EBS를 동기화해야 하는 정합성 문제가 발생한다. 이미지 요청 API 방식도 가용성 측면에서 문제가 있다.

 

이에 반해 S3는 확장성 측면에서 자유롭다. EC2가 새롭게 추가된다고 해도 서버의 구성이 그대로라면 자연스럽게 S3에 연결되고, 사용할 수 있을 것이다.

 

가용성 측면

인스턴스 장애 시

EC2가 죽으면 해당 인스턴스에 연결된 EBS도 접근할 수 없다. 물론 EBS를 다른 EC2로 옮길 수 있지만, 이 과정에서 인스턴스 재시작 및 EBS 마운트에 수 분이 소요될 뿐더러 장애 감지부터 복구까지 개발자 개입 필요로 인한 서비스 중단이 발생한다.

반면 S3는 EC2와 독립적이기에, 인스턴스가 죽어도 새 EC2를 띄우고 S3 설정만 연결하면 즉시 서비스 재개가 가능하다.

 

가용 영역 장애 시

더 심각한 건 가용 영역 전체 장애다. EBS는 단일 가용 영역에만 존재하기에 해당 가용 영역에 장애가 나면 서비스 자체를 재개할 수 없다. 하지만, S3는 기본적으로 최소 3개의 가용 영역에 데이터를 자동 복제한다. 하나의 가용 영역에 장애가 나도 다른 가용 영역에서 자동으로 데이터를 제공하기에 EC2만 정상이라면 서비스에 영향이 없다.

 

용도 분리

EBS를 파일 저장 용도로 사용하면, 서버가 상태를 가지게 된다는 문제가 발생한다. 이미지나 첨부파일 같은 데이터가 서버 내부 스토리지에 저장되면, 해당 서버는 더 이상 단순히 요청을 처리하는 역할만 수행하지 않는다.

 

비즈니스 로직을 처리하는 역할과 파일을 보관하는 역할을 동시에 가지게 된다. 이렇게 역할이 섞이면, 서버 교체나 재배포가 어려워진다. 확장성 측면과 이어지는 부분이기도 하다.

 

인스턴스를 새로 띄우거나 기존 인스턴스를 제거할 때마다 “저장된 파일은 어떻게 할 것인가?”라는 추가적인 고민이 필요해진다. 반면 S3를 사용하면 파일 저장 책임을 서버 외부로 완전히 분리할 수 있다. 서버는 요청을 처리하고, S3는 파일을 저장하는 역할만 수행한다.

 

이로 인해 서버는 무상태에 가까운 구조를 유지할 수 있고, 인스턴스 교체나 확장이 훨씬 단순해진다.

비용 효율성

사실상 취준생에게 가장 큰 이유라고 볼 수 있다.

 

EBS 비용 - https://aws.amazon.com/ko/ebs/pricing/
S3 비용 - https://aws.amazon.com/ko/s3/pricing/

 

단일 인스턴스 환경에서는 EBS가 더 저렴할 것처럼 느껴질 수 있다. 하지만 실제로 비용을 계산해보면 파일 저장 용도로 사용할 경우 S3가 더 비용 효율적인 경우가 많다.

EBS는 설정한 용량에 대해 사용 여부와 관계없이 항상 비용이 발생한다. 그리고, 장애 대비를 위해 스냅샷을 주기적으로 관리해야 하고, 스냅샷 역시 별도의 저장 비용이 발생한다. 반면 S3는 사용한 만큼만 비용을 지불하는 구조이다.

그래서 단순하게 1TB를 기준으로 월 비용을 계산해보면 S3의 경우 $25, EBS의 경우 $91.20로 엄청난 차이를 보이고 있음을 알 수 있다.

즉, 파일 저장이라는 목적에 한정해서 보면 EBS는 성능에 최적화된 스토리지이고, S3는 저장 비용과 운영 비용에 최적화된 스토리지라고 볼 수 있다.

 

결론

인스턴스를 만들때 기본적으로 EBS를 만들기 때문에 이게 더 효율적인 선택이라고 생각했으나 단일 인스턴스 환경이라고 해서 EBS가 항상 더 나은 선택은 아니다.

EBS는 빠른 읽기/쓰기가 필요한 데이터베이스나 애플리케이션 내부 데이터에 적합한 스토리지이다.

반면 이미지나 첨부파일처럼 서버와 독립적으로 관리되어야 하고, 확장성과 가용성이 중요하며 장기적으로 비용 효율성을 고려해야 하는 데이터의 경우 단일 인스턴스 환경에서도 S3를 사용하는 것이 더 합리적인 선택이 된다.

즉, S3를 사용하는 이유는 지금 인스턴스가 하나이기 때문이 아니라 앞으로도 서버를 단순하게 유지하기 위해서이다.