Amazon Elastic Container Service(ECS), Amazon EFS 파일 시스템 지원 출시 (서울 리전 포함)

Amazon Elastic Container Service의 출시 5년후, 이제  개발자들에게 일상적인 요소가 되었으며 AWS 고객은 ECS와 같은 컨테이너 오케스트레이션 도구를 점점 더 많이 채택하고 있습니다.

그런데, 일부 유형의 애플리케이션은 여전히 컨테이너화된 환경으로 전환하는 것이 어렵습니다. 컨테이너는 사실상 일시적이기 때문에 데이터 지속성 또는 공유 스토리지가 필요한 애플리케이션을 빌드하는 경우, 컨테이너가 동적으로 확장 및 축소될 때,컨테이너가 종료되면 로컬 데이터가 손실됩니다.

오늘부터 Amaon ECS에 Amazon Elastic File System(EFS) 파일 시스템에 대한 지원을 시작합니다. ECS 및 AWS Fargate에서 실행되는 컨테이너는 모두 Amazon EFS을 사용할 수 있습니다.

Amazon Elastic File System(EFS)은 고가용성의 확장 가능한 완전관리형 공유 파일 시스템을 제공합니다. 즉, Amazon EFS를 사용하면 데이터를 컴퓨팅과 별도로 저장할 수 있습니다. 또한 Amazon EFS는 리전별 서비스입니다. 즉, 이 서비스는 고가용성 및 내구성을 위해 3개의 가용 영역 내에 또는 3개 영역에 걸쳐 데이터를 저장하고 있습니다.

이를 통해 AWS 고객은 콘텐츠 관리 시스템, 내부 DevOps 도구 및 기계 학습 프레임워크와 같은 공유 스토리지가 필요한 애플리케이션을 컨테이너화할 수 있습니다. 완전히 새로운 워크로드 세트는 이제 컨테이너가 제공하는 이점을 누리므로 고객은 배포 프로세스의 속도를 높이고 인프라 활용도를 최적화하며 더욱 탄력적인 시스템을 구축할 수 있습니다

이제 Amazon EFS을 사용하여 컨테이너 애플리케이션을 운영하는 방법을 살펴보겠습니다.

간단한 공유 파일 시스템 사례 살펴보기
본 예제에서는 일부 기본 인프라를 구축한 상태에서 AWS Fargate 클러스터에 EFS를 추가하는 경우의 전후 효과를 보여줄 수 있습니다. 먼저 두 가용 영역에 걸쳐 있는 VPC를 생성합니다. 그다음에는 ECS 클러스터를 생성합니다. 그리고 ECS 클러스터에서 Fargate를 사용하여 두 개의 컨테이너를 실행할 계획입니다. 이는 컨테이너가 AWS에 의해 관리되는 Fargate 플릿에서 실행되므로 EC2 인스턴스를 설정할 필요가 없음을 의미합니다.

애플리케이션을 배포하기 위해 간단한 드래그 앤 드롭 파일 관리자인 Cloud Commander라는 오픈 소스 애플리케이션의 Docker 이미지를 사용하는 작업 정의를 생성합니다.

ECS 콘솔에서 서비스를 생성하고, 앞서 생성한 작업 정의를 사용하여 애플리케이션을 배포합니다. 서비스가 배포되고 컨테이너가 프로비저닝되면 서비스의 일부로 생성된 Application Load Balancer URL로 이동합니다. 그러면 애플리케이션이 작동하는 것을 확인할 수 있습니다. 파일을 드래그하여 애플리케이션에 업로드할 수 있습니다.

그런데, 문제가 있습니다. 페이지를 새로 고치면 가끔 업로드하기 위해 드래그한 파일이 사라집니다. 이 문제는 애플리케이션을 실행하는 컨테이너가 두 개 있고 둘 다 로컬 파일 시스템을 사용하기 때문에 발생합니다. 브라우저를 새로 고치면 로드 밸런서에 의해 두 컨테이너 중 하나로 리디렉션되며 컨테이너 중 하나만 로컬 볼륨에 이미지를 저장합니다.

필요한 것은 두 컨테이너가 마운트할 수 있으며 파일을 쓸 수 있는 공유 파일 시스템입니다.

다음으로 EFS 콘솔 내부에 새 파일 시스템을 생성합니다. 마법사에서 ECS 클러스터를 생성할 때 사용한 것과 동일한 VPC를 선택하고, VPC가 걸쳐 있는 모든 가용 영역을 선택하고, 서비스에 요청하여 각각에 마운트 대상을 생성합니다. 이러한 마운트 대상은 서로 다른 가용 영역에 있는 컨테이너에서 여전히 파일 시스템에 연결할 수 있음을 의미합니다.

마법사의 다른 모든 옵션에 대해 기본값을 선택합니다. 3단계에서 버튼을 클릭하여 액세스 지점을 추가합니다. 액세스 지점은 특정 애플리케이션에 파일 시스템에 대한 액세스 권한을 제공하는 방법으로, 이를 통해 애플리케이션이 액세스할 수 있는 데이터를 매우 세밀하게 제어할 수 있습니다. EFS 파일 시스템에 여러 액세스 지점을 추가하여 다양한 애플리케이션에 동일한 파일 시스템에 대한 서로 다른 수준의 액세스 권한을 제공할 수 있습니다.

배포 중인 애플리케이션이 웹사이트의 사용자 업로드를 처리하므로 이 애플리케이션에 /uploads 디렉터리에 대한 전체 액세스 권한을 부여하는 EFS 액세스 지점을 생성하기만 하면 됩니다. 이를 위해 새 사용자 ID(1000) 및 그룹 ID(1000) 그리고 /uploads 홈 디렉터리를 사용하여 액세스 지점을 생성합니다. 디렉터리 생성 시 이 사용자 및 그룹을 전체 권한이 있는 소유자로 생성하고 다른 모든 사용자에게는 읽기 권한을 부여합니다.

보안은 AWS의 최우선 순위입니다. 이에 따라 팀은 ECS를 EFS와 통합함으로써 IAM 역할 기반 액세스 제어, VPC 보안 그룹 및 전송 중 데이터 암호화를 비롯하여 무단 액세스로부터 EFS 파일 시스템을 보호하기 위한 여러 보안 계층을 제공하고자 최선을 다하고 있습니다.

마법사를 통한 작업이 끝나면 파일 시스템이 생성되고 파일 시스템 ID 및 액세스 지점 ID가 제공됩니다. Fargate에서 작업 정의를 구성하려면 이러한 ID가 필요합니다.

ECS 클러스터 내부의 작업 정의로 돌아가서 새로운 작업 정의 개정본을 만듭니다. 정의의 볼륨 섹션으로 스크롤하여 [볼륨 추가]를 클릭합니다.

그런 다음에 EFS 파일 시스템 세부 정보를 추가할 수 있습니다. 그리고 올바른 파일 시스템 ID 및 이전에 생성한 올바른 액세스 지점 ID를 선택합니다.

이 예에서는 [전송 중 암호화]를 활성화하도록 선택했지만 [EFS IAM 권한 부여]는 활성화하지 않았습니다. 이 기능은 파일 시스템의 다른 부분에 대해 서로 다른 수준의 액세스가 필요한 여러 클라이언트가 있는 대규모 애플리케이션에서 유용합니다. 이 기능은 IAM 권한 부여를 사용함으로써 관리를 간소화할 수 있습니다. 이에 대해 자세히 알아보려면 올해 초에 기능을 출시하면서 작성한 블로그를 확인하시기 바랍니다.

작업 정의를 업데이트했으므로 ECS 서비스를 업데이트하여 이 새로운 정의를 사용할 수 있습니다. 또한 여기에서 필수적으로 플랫폼 버전을 1.4.0으로 설정해야 합니다.

서비스는 새로운 두 컨테이너를 배포하고 이전의 두 컨테이너를 해제합니다. 이제 새 컨테이너는 공유 EFS 파일 시스템을 사용하므로 애플리케이션도 예상대로 작동합니다.

파일을 업로드한 후 애플리케이션을 다시 방문한 경우 파일이 계속 남아 있습니다. 컨테이너를 교체하거나 확장 또는 축소한 경우 파일 시스템이 유지됩니다.

향후 전망
최근 컨테이너 팀에서 실현한 혁신이 마음에 듭니다. 그리고 이 팀의 공개 로드맵을 살펴보고 있는데 컨테이너 팀은 미래에 대한 정말 흥미로운 계획도 갖고 있습니다. 아이디어 또는 기능 요청이 있는 경우 의견을 밝혀 이미 로드맵을 진행하고 있는 많은 고객에게 여러분의 의견이 반영되도록 하십시오.

새로운 기능은 ECS 및 EFS를 사용할 수 있는 모든 리전에서 사용할 수 있으며 추가 비용 없이 제공됩니다. AWS 콘솔에서 새 기능을 확인하고 의견이 있다면 알려 주시기 바랍니다.

감사합니다.

– Martin