TroubleShooting

[Troubleshooting][ECS] 도커 스토리지 에러 ([graphdriver] ERROR: the devicemapper storage-driver has been deprecated and removed; )

[앙금빵] 2024. 8. 11.

이슈사항

신규로 생성한 ECS 기반 EC2에서 ECS 에이전트가 올라오지 않는 현상

#연관 에러 메세지
dockerd: failed to start daemon: error initializing graphdriver: [graphdriver] ERROR: the devicemapper storage-driver has been deprecated and removed; visit https://docs.docker.com/go/storage-driver/  for more information: devicemapper

2024-08-07 14:53:13 KST | CORE | WARN | (comp/core/workloadmeta/store.go:614 in func1) | error pulling from collector "ecs": Get "http://localhost:51678/v1/tasks ": dial tcp 127.0.0.1:51678: connect: connection refused
2024-08-07 14:53:14 KST | PROCESS | WARN | (comp/core/workloadmeta/store.go:614 in func1) | error pulling from collector "ecs": Get "http://localhost:51678/v1/tasks ": dial tcp 127.0.0.1:51678: connect: connection refused

 

이슈원인

기존 devicemapper 유형의 도커 스토리지를 이용중에 있었으며 25버전에서부터 devicemapper 유형의 도커 스토리지에 대하여 지원이 중단되었다. 최근 출시되는 ECS 기반 AMI에서 도커버전은 v25.x 로 출시된다. 아래 링크를 참조하여 현재 이용중인 혹은 생성 예정인 Ami에 대한 도커버전은 어떻게 되는지 확인할 수 있다. (https://github.com/aws/amazon-ecs-ami/releases)

 

지원 중단사유 분석

지원이 중단된 사유를 찾아본 결과 devicemapper는 주로 최신 스토리지 드라이버를 지원하지 않았던 오래된 커널(3.x)에서 사용되어져 왔으며 이 당시 overlay2나 btrfs 유형의 드라이버가 제공되어지지 않았다. 그러나 커널 4.x 의 발전과 overlay2 방식의 광범위한 채택으로 인해 devicemapper 지원을 중단한 것으로 보인다.

출처: 도커 공식 홈페이지


원인 1. 퍼포먼스 이슈 

devicemapper 경우 스토리지 공간을 동적으로 할당하는 장점을 제공한다. 블록 레벨에서 관리되어지며 각 블록은 64KB로 할당된다. 그러나, 쓰기 집약적인 상황에서는 높은 메모리 사용량을 소비하는 경향이 컸으며 메모리 효율성이 중요한 환경에서 문제가 되었다.

 

원인 2. 구성의 복잡성

devicemapper를 설정하려면 LVM, 볼륨 그룹 및 Thin-pool 등을 구성해야 하는 복잡한 과정이 필요하다.


이러한 원인들로 컨테이너별 용량 관리에 대한 이점을 가져갈 수 있는 상황을 제외하면 얻을 수 있는 장점이  별로 없었기에 deprecated가 된 것으로 추측된다.

 

해결방안

도커 스토리지 유형을 overlay2 유형으로 변경해주어야 한다. 아래와 같이 변경해준 뒤 ecs가 정상적으로 실행되는 것을 확인할 수 있었다.

DOCKER_STORAGE_OPTIONS="--storage-driver overlay2"

부록. devicemapper 내용 정리

Docker는 이미지와 컨테이너가 파일 시스템과 상호작용하는 방식을 관리하기 위해 스토리지 드라이버를 사용한다. 여기서 devicemapper는 도커 초기버전에서 많이 사용된 드라이버 유형이었으며, 블록 레벨에서 작동하고 Thin-provisioning 기능을 지원하는 드라이버였다.

Block Level
컴퓨터 저장장치에서 데이터를 처리하는 방식을 설명하는데 이용된다. 저장되어지는 데이터를 block 단위라는 고정된 크기로 나누어 저장하고 처리한다. 도커 관점에서 컨테이너의 이미지가 생성되어지거나 수정되어질 때, 해당 파일의 블록만 생성 및 수정되어지며 효율적인 저장 공간 관리의 장점을 제공해준다.

Thin-provisioning
저장 장치의 용량을 효율적으로 관리하는 기술이다. 실제로 사용되지 않는 저장 공간을 미리 할당하지 않고, 필요할때만 할당하는 동적 할당 방식으로 관리함으로써 저장 장치를 효율적으로 사용할 수 있게 해준다.

 

전통 방식 vs Thin provisioning

저장 방식 내용
전통방식 100GB의 저장 공간을 가진 시스템에서, 만약 50GB가 필요한 경우 전체 50GB를 미리 할당하여 사용할 수 있게 준비한다.
Thin-Provisioning 각 컨테이너 Layer에 필요한 공간을 동적으로 할당한다. 저장장치의 모든 공간을 미리 할당하는 것이 아닌, 실제로 사용된 데이터만큼의 블록을 할당하여 관리하므로 저장 공간을 절약하고 더 많은 컨테이너를 관리할 수 있다는 장점이 있다.

 


Reference

https://docs.docker.com/engine/storage/drivers/device-mapper-driver/#device-mapper-and-docker-performance

https://blog.naver.com/alice_k106/221202887853?trackingCode=blog_bloghome_searchlist

 

 

댓글