AWS Certified Soultions Architect Associate Day 07(EBS)

7. EC2 인스턴스 스토리지

 

55. EBS 개요

이번 섹션에선 EC2 인스턴스의 다양한 스토리지 옵션을 살펴볼 겁니다

 

우선 가장 중요한 옵션은

EBS 볼륨인데요 개념을 함께 살펴봅시다. EBS 볼륨은 일래스틱 블록 스토어의 줄임말입니다. 인스턴스가 실행 중인 동안 연결 가능한 네트워크 드라이브죠. 모르는 사이에 계속 사용해왔던 기능입니다.

EBS 볼륨을 사용하면 인스턴스가 종료된 후에도 데이터를 지속할 수 있습니다. EBS 볼륨을 쓰는 목적이죠 우리가 인스턴스를 재생성하고 이전 EBS 볼륨을 마운트하면 데이터를 다시 받을 수 있는 겁니다.

매우 유용하죠 그리고 CCP 레벨의 EBS 볼륨은 (CCP 레벨: 하나의 EBS는 하나의 EC2 인스턴스에만 마운트 가능 / 어소시에이트 레벨: 일부 EBS 다중 연결) 한 번에 하나의 인스턴스에만 마운트할 수 있습니다 (CCP 레벨: 하나의 EBS는 하나의 EC2 인스턴스에만 마운트 가능 / 어소시에이트 레벨: 일부 EBS 다중 연결)

또한 EBS 볼륨을 생성할 때는 특정 가용 영역에서만 가능한데요 즉, 예를 들어 EBS 볼륨이 us-east-1a에서 생성된 경우 us-east-1b에는 연결이 불가능하죠

 

그럼 EBS 볼륨이란 뭘까요?

네트워크 USB 스틱이라고 생각하시면 됩니다. USB 스틱처럼 한 컴퓨터에서 꺼내, 다른 컴퓨터에 꽂는 그런 장치는 맞지만 실제 물리적 연결은 없으며 네트워크를 통해 연결되는 거죠.

무료 등급으로는 매달 30GB의 EBS 스토리지를 범용 SSD 혹은 마그네틱 유형으로 제공됩니다

EBS 볼륨은 네트워크 드라이브고 물리적 드라이브가 아닙니다.

즉, 인스턴스와 EBS 볼륨이 서로 통신을 하기 위해서는 네트워크를 필요로 합니다 그리고 네트워크가 사용되기 때문에

컴퓨터가 다른 서버에 도달할 때 지연이 생길 수 있죠 EBS 볼륨은 네트워크 드라이브이므로 EC2 인스턴스에서 분리될 수 있고 매우 빠르게 다른 인스턴스로 연결될 수 있습니다

이 때문에 대체 작동 등의 경우에 굉장히 유용하죠

EBS 볼륨은 특정한 가용 영역에 고정되어 있으므로 us-east-1a에 생성된 볼륨은 us-east-1b로 연결이 불가능합니다

그런데 이번 섹션의 나중에 나올 내용이지만 스냅샷을 이용하면 다른 가용 영역으로도 볼륨을 옮길 수 있습니다

 

또한 볼륨이기 때문에 용량을 미리 결정해야 합니다. 따라서 원하는 양의 GB 및 IOPS, 즉 단위 초당 전송 수를 미리 지정해야 하는데요. 기본적으로 여러분이 원하는 EBS 볼륨의 성능을 미리 정의하는 식이죠.

 

그러면 해당 프로비전 용량에 따라 요금이 청구되고 더 좋은 성능이나 큰 사이즈가 필요하면 이후에 용량을 늘릴 수도 있습니다

그럼 도면을 통해 살펴볼까요?

US-EAST-1A에는 EC2 인스턴스 하나가 있고 EBS 볼륨 하나를 EC2 인스턴스로 연결할 수 있겠죠

만약 EC2 인스턴스를 하나 더 생성한다면 앞서 말했듯이 CCP 레벨의 EBS 볼륨은 한 번에 두 개의 인스턴스와 연결될 수 없습니다.

따라서 이 경우에 두 번째 EC2 인스턴스는 고유한 EBS 볼륨이 따로 연결되어야 하죠. 하지만 인스턴스 하나에 두 개의 EBS 볼륨이 연결되는 건 문제없이 가능합니다. 네트워크 USB 스틱 두 개가 머신 하나에 연결되는 상황을 생각해 보시면 되겠죠

이제 EBS 볼륨이 가용 영역에 연결되었습니다. 현재 도면 상에서는 모두 US-EAST-1A를 사용하고 있죠. 이제 다른 EBS 볼륨을 다른 가용 영역에 두려면 이런 식으로 다른 가용 영역에 별도로 생성을 해야 합니다

EC2 인스턴스와 마찬가지로 EBS 볼륨도 특정 가용 영역 내로 한정되죠. 마지막으로, EBS 볼륨을 생성한 후 연결하지 않고 그대로 둘 수도 있는데요. 꼭 EC2 인스턴스에 연결될 필요가 없죠. 필요한 경우에만 연결이 가능한 아주 강력한 기능입니다.

마지막으로는 EC2 인스턴스를 통해 EBS 볼륨을 생성하는 경우 종료 시 삭제라고 하는 속성이 있습니다. 시험 출제 가능성이 있는 내용입니다

 

여기 보시는 것처럼 EC2 인스턴스를 생성할 때 콘솔에서 EBS 볼륨을 생성하면 끝에서 두 번째 열에 종료 시 삭제 옵션이 있습니다. 기본 설정으로는 루트 볼륨에 체크되어 있고 새로운 EBS 볼륨에는 체크가 되어 있지 않죠. 이 옵션을 통해 EC2 인스턴스 종료 시 EBS 행동을 제어할 수 있습니다

보시다시피 기본적으로 루트 EBS 볼륨은 인스턴스 종료와 함께 삭제되도록 설정이 되어 있죠. 활성화가 된 상태입니다 다른 EBS 볼륨은 삭제되지 않는데 기본적으로 비활성 상태이기 때문이죠. 물론 UI에서 보시다시피 종료 시 삭제 기능의 활성화 여부는 원하시는 대로 조작이 가능합니다

 

실제 사용 예시로는

인스턴스가 종료될 때 루트 볼륨을 유지하고자 하는 경우 데이터를 저장하고자 하는 등의 경우에는 루트 볼륨의 종료 시 삭제 속성을 비활성화하면 됩니다.

 

57. EBS 실습

이제 EBS 볼륨을 실행해 봅시다

EC2 인스턴스를 클릭하고 Storage로 이동하면 여기에 루트 장치 세부 정보가 있습니다.

/dev/xvda라고 나왔네요

루트 장치 유형은 EBS이고 인스턴스에 연결된 블록 장치를 살펴보면 볼륨 ID가 한 개 있습니다 8GB를 가진 EBS 볼륨이네요.

여기를 클릭해 보면 EBS 콘솔로 바로 이동합니다.

볼륨 ID 필터를 삭제하면, 계정의 EBS 볼륨 전체를 볼 수 있는데요. 현재는 EBS 볼륨이 하나뿐입니다. 이제 고유의 EBS 볼륨을 생성할 수 있습니다.

Create Volume을 누르고 볼륨 유형은 gp2로 하겠습니다

다른 옵션도 많이 있지만 지금은 gp2로 만듭시다. 간단하니까요 크기는 2GB로 지정하고

이 볼륨의 가용 영역은 하나로 지정하겠습니다. EC2 인스턴스가 생성된 것과 동일한 영역이죠.

가용 영역에 대한 정보는 여기 Availability Zone을 보시면 됩니다. us-east-2b네요, 그러면 가용 영역을 us-east-2b로 바꿉시다. 암호화 활성이나 태그는 추가하지 않을 겁니다

 

볼륨 생성만 클릭합시다

생성한 볼륨이 보이지 않네요 이번에도 필터를 제거해 보면 이제 두 개의 볼륨을 확인할 수 있습니다.

볼륨 하나는 머신의 루트 볼륨으로 사용 중이고 다른 하나는 현재 사용 가능한 2GB 볼륨입니다

이제 마우스 오른쪽 클릭으로 Attach Volume을 선택해

 

EC2 인스턴스로 연결합니다

EBS 볼륨과 동일한 가용 영역에 있기 때문이죠

Attach를 클릭해 연결합니다 현재 연결 진행 중이네요

 

새로 고침을 할게요 얼마 걸리지 않을 겁니다

EC2 인스턴스로 돌아가서 여기서 정보를 새로 고침해 보면 Storage 메뉴 아래에 블록 장치가 이제 두 개입니다.

하나는 8GB인 루트 볼륨이고 또 하나는 /dev/sdf, 2GB로 역시 인스턴스에 연결된 상태죠.

이 볼륨을 사용하는 방법은 복잡하고 시간이 많이 걸리며 범위에서도 벗어납니다. 그래도 설명서를 보시면 튜토리얼이 나와 있습니다. formats EBS volume to attach on EC2 instance를 입력해 검색하시면 찾을 수 있죠

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-using-volumes.html

Make an Amazon EBS volume available for use on Linux - Amazon Elastic Compute Cloud

이 튜토리얼을 보시면 사용 방법을 볼 수 있습니다. Google 상에서 AWS 설명서를 이용하셔도 되죠

 

하지만 복잡한 편이고 범위에도 포함되지 않으니

이번 시간에는 AWS의 관점에서

EBS 볼륨의 작동 방식이 어떤지만 보여드리겠습니다

그럼 이렇게 볼륨이 연결되었으니

 

이제 볼륨 브라우저로 가서

새로 고침을 하면 둘 다 사용 중이죠

새로운 볼륨을 생성하겠습니다 크기는 2GB로 하고

이번에는 영역을 us-east-2a로 하죠

Create Volume을 클릭합니다

그러면 방금 만든 것을 포함해 세 개의 볼륨이 보입니다

이 볼륨을 마우스 오른쪽 클릭해 Attach Volume을 선택합니다

그런데 일치하는 인스턴스가 없다고 나오죠

 

해당 볼륨이 us-east-2a 가용 영역 안에 있기 때문입니다

따라서 us-east-2a 인스턴스가

필요하지만 아직은 없는 상태입니다

지금 인스턴스는 us-east-2b에만 있죠

연결이 불가능한 겁니다 그럼 이 볼륨을 마우스 오른쪽 클릭해

Delete Volume을 클릭하면 없어집니다

보시다시피 클라우드는 굉장히 강력합니다

스토리지 요청 및 삭제가 5초 안에 이루어지니까요

이렇게 빠르다는 게 놀라울 따름이죠

생각해 보세요 자체 데이터 센터에서

직접 설치 및 삭제를 하려면 정말 오래 걸릴 겁니다

이 볼륨은 삭제가 되었으니

이제 사용 가능한 EBS 볼륨은 두 개입니다

그럼 작은 실험을 해봅시다

지금 클라우드에 있으니까 인스턴스를 종료하겠습니다

그럼 EBS 볼륨은 어떻게 될까요

이 인스턴스를 종료할 텐데

지금은 EBS 볼륨이 두 개 있지만

이 하단에 있는 볼륨을 보시면

이제 인스턴스를 종료할 때

종료 시 삭제가 될 겁니다

왜냐하면 이 볼륨은 우리가 인스턴스를

생성했을 때 잠시 인스턴스로 이동할까요

인스턴스를 시작했을 때를 보면

옵션들은 빠르게 넘어가겠습니다

EBS 볼륨이 8GB였고

종료 시 삭제 속성에 체크를 했었죠

따라서 여기 있는 EBS 볼륨이 삭제될 겁니다

하지만 이쪽 볼륨에는 종료 시 삭제 속성이 없습니다

그러니 삭제되지 않겠죠

 

EC2 인스턴스로 돌아가서 검증해 보겠습니다

여기서 인스턴스를 종료합니다

됐습니다 이제 종료 중입니다

종료 후에 이 볼륨은 없어질 겁니다

이제 EBS 볼륨이 어떻게 되었는지 한 번 확인해 봅시다

새로 고침을 하면 지금은 볼륨이 두 개지만

바로 하나가 사라졌습니다

유일하게 남은 볼륨은 2GB 볼륨뿐이네요

10초에서 20초가 걸렸습니다

 

 

58. EBS 스냅샷 개요

 

EBS 스냅샷을 살펴보겠습니다

EBS 스냅샷은 EBS 볼륨의 특정 시점에 대한 백업입니다. EC2 인스턴스에서 EBS 볼륨을 분리할 필요는 없지만 권장 사항입니다. EBS 스냅샷은 다른 가용 영역이나 다른 리전에도 복사할 수도 있습니다.

예를 들어 US-EAST-1A에 있는 EBS 볼륨을 가진 EC2 인스턴스가 있고 US-EAST-1B에 있는 EC2 인스턴스가 있을 때 EBS 볼륨에 대한 스냅샷을 찍고 이 스냅샷을 활용해 다른 AZ에 복원할 수 있습니다. 이런 식으로 EBS 볼륨을 한 AZ에서 다른 AZ로 전송이 가능하죠.

 

.

이제 EBS 스냅샷의 기능을 살펴보죠.

먼저 EBS 스냅샷 아카이브는

- 최대 75%까지 저렴한 아카이브 티어로 스냅샷을 옮길 수 있는 기능입니다

- 스냅샷을 아카이브 티어로 옮기면 아카이브를 복원하는 데 24시간에서 최대 72시간이 걸립니다. 즉시 복원되지 않아요.

 

다음은 EBS 스냅샷 휴지통입니다

- EBS 스냅샷을 삭제하는 경우 영구 삭제하는 대신에 휴지통에 넣을 수 있습니다. 실수로 삭제하는 경우에 휴지통에서 복원할 수 있죠.

- 휴지통에 보관되는 기간은 1일에서 1년 사이로 설정할 수 있습니다.

 

EBS 스냅샷의 마지막 기능은 빠른 스냅샷 복원(FSR)입니다

- 스냅샷을 완전 초기화해 첫 사용에서의 지연 시간을 없애는 기능입니다. 스냅샷이 아주 크고 EBS 볼륨 또는 EC2 인스턴스를 빠르게 초기화해야 할 때 특히 유용합니다. 하지만 비용이 많이 드니 사용에 주의하세요.

 

 

59. EBS 스냅샷 실습

복사해서 다른 지역으로 보낼 수 있다. 다른 지역에서 재해 복구 전략을 백업하거나 할 때 유용하다.

볼륨 생성시 가용 영역을 바꿀 수 있다. 생성시 다른 리전에 볼륨이 생기게 된다.

 

스래기통을 이용해 EBS 스냅샷이 실수로 삭제되지 않도록해준다.

규칙을 생성해주고

 

리소스에 아무것도 없으니 무언가 지워보자.

 

아카이빙해 다른 가격 책정 레벨에 있는 스토리지 티어로 옮길 수 있다. 물론 복구하는데 최대 3일이 걸린다

아무튼 지원보자

 

리소스가 있는 것을 볼 수 있다.

 

이제 다시 복구해 놓자

 

 

60. AMI 개요

이제 EC2 인스턴스의 기반이 되는 AMI에 대해 알아보겠습니다

AMI는 Amazon Machine Image의 약자로 사용자 지정 EC2 인스턴스를 나타냅니다. 따라서 AWS에서 생성한 AMI를 사용하거나 사용자 지정 AMI를 만들 수도 있습니다.

 

그렇다면 AMI란 뭘까요?

각자의 소프트웨어 구성에 대해 운영 체제를 정의 및 설정하며 모니터링 도구를 설정할 수도 있는데 이때 자체적으로 AMI를 생성하면 부팅과 구성에 시간이 단축됩니다. 이는 여러분의 EC2 인스턴스에 설치하고자 하는 모든 소프트웨어가 AMI를 통해서 사전에 패키징 되기 때문이죠.

따라서 AMI를 자체적으로 구성하고 특정 리전에 맞도록 구축함으로써 이들을 원하는 리전에 복사해 놓거나 AWS 글로벌 인프라를 활용할 수 있는 겁니다.

따라서 여러 종류의 AMI에 EC2 인스턴스를 실행할 수 있는데 본 코스에서는 지금까지 AWS가 제공하는 공용 AMI를 사용했습니다. AWS의 AMI로는 아마존 Linux 2 AMI가 자주 사용되며 이는 AWS가 자체적으로 제공합니다. 직접 AMI를 생성할 수도 있습니다

여러분이 따로 AMI를 생성하고 유지할 수 있도록 이를 자동화하는 도구가 있긴 하지만 이는 클라우드 사용자인 여러분이 직접 해야 하는 작업입니다.

끝으로 AWS 마켓 플레이스 AMI에서도 EC2 인스턴스의 실행이 가능합니다. 이는 다른 사용자가 만들어서 판매하는 AMI로 자주 찾아볼 수 있습니다. AWS의 공급 업체가 자체적으로 AMI나 구성이 훌륭한 소프트웨어를 생성하고 여러분은 시간 절약을 위해 마켓 플레이스 AMI에서 이들을 구매할 수 있습니다.

사용자인 여러분도 AWS 마켓 플레이스에서 AMI를 직접 판매할 수 있습니다. 실제로 일부 기업이 이렇게 하고 있죠

그럼 EC2 인스턴스의 AMI 처리는 어떻게 이루어질까요?

1. 먼저 EC2 인스턴스를 시작하고 이를 사용자 지정으로 바꾸어 줍니다.

2. 다음으로는 인스턴스를 중지시켜 데이터 무결성을 확보합니다.

3. 그리고 AMI를 구축하는데 이때 표시되지는 않으나 EBS 스냅샷 또한 생성됩니다.

4. 끝으로 다른 AMI에서 인스턴스를 실행할 수 있게 됩니다. 다음 강의에서 이 처리 작업에 대한 데모를 함께 살펴보죠

US-EAST-1A 인스턴스가 있고 동일한 US-EAST-1B 인스턴스를 생성했다고 했을 때 US-EAST-1A에서 인스턴스를 실행하려면 먼저 이를 사용자 지정으로 바꾸고 Custom AMI인 AMI를 생성해 줍니다. 이로써 US-EAST-1B 내에서는 해당 AMI로부터 인스턴스를 실행하여 EC2 인스턴스의 사본을 생성할 수 있습니다.

 

61. AMI 실습

 

이제 AMI 생성 실습을 시작해 보겠습니다 AMI 생성을 위해 먼저 신규 EC2 인스턴스를 만들어야 합니다 인스턴스를 실행해 보죠 아마존 Linux 2를 사용합니다 선택한 다음 t2.micro를 확인하고 스크롤을 내려서 사용자 데이터를 지정해 줄 차례입니다 해당 칸에는 마지막 행을 제외한 모든 코드를 복사해서 넣어 줄 겁니다 마지막 행은 복사하지 마세요 이는 현재 아파치(Apache) 웹 서버인 httpd를 설치하는 AMI를 생성하는 작업이며 부팅 시 AMI에서 런타임이 돌아가는 html 파일은 아직 사용자 지정을 할 필요가 없기 때문입니다 마지막 행만 제외한 코드 일체를 복사해서 User data에 입력해 줍니다 Add Storage를 클릭하면 EBS 볼륨에 모든 속성이 들어갔음을 알 수 있습니다 Delete on Termination까지 말이죠 Add Tags를 클릭하고 Configure Security Group로 가서 이미 존재하고 있던 보안 그룹인 launch-wizard-1에 이를 연결할 수 있습니다 Review and Launch로 가서 Launch를 누른 다음 이미 있는 키 페어인 EC2 Tutorial을 골라 줍니다. 이제 인스턴스가 실행되었습니다. View Instances를 클릭하면 현재 새로운 인스턴스가 생성 보류 중임을 알 수 있습니다. 부팅 시간이 좀 지난 뒤에 다시 살펴보도록 하죠.

인스턴스는 실행 중이니 이제 공용 IPv4를 복사해서 브라우저에 붙여 넣어 주면 아직 생성 중이라 이 웹사이트에 접근할 수 없다는 메시지가 표시됩니다. 여기 보이는 것처럼 EC2 인스턴스가 아직 부트스트랩 작업을 완료하지 않아서 EC2 인스턴스에 대한 설치가 미완료 상태임을 알 수 있습니다. 연결 오류가 표시되는 거죠. 이 페이지를 새로고침한 다음 잠깐 기다려 주면 EC2 데이터 스크립트가 실시되어서 http 웹 서버 생성이 완료될 겁니다

 

모든 작업이 즉각적으로 수행되지 않음을 단적으로 보여 주는 예시죠. 우리가 AMI를 생성하는 이유 중 하나이기도 합니다. AMI 생성 후에는 이 EC2 인스턴스에 대해 20초에서 30초가량 소요되는 부트스트랩 타임이 사라질 겁니다.

이제 테스트 페이지가 뜹니다 현재 http 웹 페이지에 대한 사용자 지정 사항이 없으므로 이를 요하는 표준 테스트 페이지가 표시되는 거죠. 어쨌든 지금까지는 인스턴스에 대한 모든 설치가 완료되었다는 뜻입니다.

이제 이 인스턴스에 대한 AMI를 생성해야 합니다. 생성한 인스턴스를 오른쪽 클릭하여 Images and templates에서 Create image를 선택합니다

이 이미지를 DemoImage로 지정해 주고 이 인스턴스에서 AMI를 생성해 보겠습니다

 

이제 루트 EBS 볼륨의 스냅샷을 생성하도록 설정하고

Create image를 클릭합니다

이제 이 AMI 생성을 마쳤습니다

이제 이 AMI에서 EC2 인스턴스를 실행해 볼 텐데

Launch instances를 클릭하고

My AMIs로 이동합니다 이 AMI가 생성되기까지

시간이 좀 걸리니 잠깐 기다려 줄 필요가 있겠습니다

우측에 있는 AMIs를 보면 해당 AMI가 현재

pending 상태라고 뜹니다

따라서 해당 AMI에서 인스턴스 실행이 가능할 때까지 기다려야 합니다

이제 AMI가 사용 가능해졌으니 Instances에서 Launch instance를 누르고

우측에 있는 My AMIs에서 DemoImage 생성을 확인할 수 있습니다. 선택한 뒤 t2.micro와 인스턴스 세부 구성으로 넘어가서

사용자 데이터 부분에 대해 간단히 따로 지정할 사항이 있습니다

코드 중 매우 중요한 첫 번째 행을 복사한 다음

가장 첫 번째 행과 마지막 행을 복사해서 입력해 줍니다

이 작업으로 인스턴스가 시작될 때

index.html 파일을 생성하는

메시지를 사용자 지정하고

EC2를 사용자 부팅했을 때 하나의 명령만 실행되도록 하는 겁니다

따라서 본 AMI에 이미 httpd 파일이

설치되어 있으니 이제 이를 따로 재설치할 필요가 없습니다

Add Storage 다음은 Add Tag

이 이미지의 이름은

From AMI로 지정해 주겠습니다

Configure Security Group에서 launch-wizard-1을 보안 그룹으로 지정합니다

Review and Launch에서 Launch, 키 페어는 그대로 지정한 다음

View Instances로

확인하면 다음 세 개의 인스턴스가 나옵니다

각각 종료, 실행, 보류 상태입니다

전체 클라우드의 흐름인 거죠

현재 보류 중인 EC2 인스턴스의

IPv4 주소를 열어 보겠습니다

실행 중으로 상태가 바뀌길 기다려 보죠

해당 인스턴스의 Running 상태를 기다린 다음

바뀐 것을 확인하고 해당 IP를 열어 보겠습니다

현재 해당 인스턴스가 부팅 중이며

곧 화면이 표시될 겁니다

금방 테스트 페이지가 나타나죠

아파치 http 서버가 이미 설치된 상태이기 때문에

시간 소요 없이 표시되는 겁니다

새로고침을 누른 다음 EC2 사용자가 실시되도록 잠깐 기다려 줍니다

그러면 해당 인스턴스의 사설 IP로부터

Hello World라는 메시지가 표시되죠

이로써 AMI의 강력한 힘을 살펴봤습니다

필요한 소프트웨어가 이미 EC2 인스턴스에

설치되어 있기 때문에 부팅 시간이 훨씬 단축됩니다

이를 통해서 AMI가 여러분의 일반적인 소프트웨어나 보안 소프트웨어

방화벽 또는 사용자 지정 구성 등의

작업 시 얼마나 유용한지 알아볼 수 있었습니다

오늘 강의는 여기까지입니다 유익하셨기를 바라며

강의를 마치기 전 아래 두 인스턴스는 필요가 없으니

해당하는 두 인스턴스는

종료시키도록 합니다

그럼 다음 강의에서 뵙겠습니다

 

62. EC2 인스턴스 스토어

지금까지 EC2 인스턴스에 네트워크 드라이브를 연결하는 방법까지 알아봤으나 그 성능은 제한됩니다. 제한된다는 뜻은 성능 자체는 뛰어나지만 이보다 더 높은 성능을 요구할 때가 있고 이때는 EC2 인스턴스에 연결된하드웨어 디스크 성능이 향상되어야 합니다

EC2 인스턴스는 가상 머신이지만 실제로는 하드웨어 서버에 연결되어 있습니다. 이와 같은 서버에는 해당 서버에 물리적으로 연결된 디스크 공간을 갖습니다. 따라서 특정 유형의 EC2 인스턴스는 EC2 인스턴스 스토어라고 불리며 이는 해당하는 물리적 서버에 연결된 하드웨어 드라이브를 가리킵니다

이 EC2 인스턴스 스토어는 I/O 성능 향상을 위해 활용할 수 있습니다. 이들이 훌륭한 처리량을 갖추고 있어서 매우 향상된 디스크 성능을 요할 때에 활용할 수 있도록 확보할 필요가 있습니다.

이때 주의할 점은 여러분이 EC2 인스턴스, 즉 인스턴스 스토어를 중지 또는 종료하면 해당 스토리지 또한 손실된다는 것입니다. 이 같은 이유로 이를 임시 스토리지라고 부르며 EC2 인스턴스 스토어가 장기적으로 데이터를 보관할 만한 장소가 될 수 없음을 보여 줍니다.

 

그러면 언제 사용하는 것이 좋을까요?

1. 버퍼나 캐시

2. 스크래치 데이터 또는 임시 콘텐츠를 사용하려는 경우

이들을 보관할 좋은 장소가 되지만 장기적인 스토리지는 될 수 없습니다

장기 스토리지의 경우에는 EBS가 적합합니다

 

마지막으로 EC2 인스턴스의 기본 서버에 장애가 발생할 시에는 해당 EC2 인스턴스가 연결된 하드웨어에도 장애가 발생하므로 데이터 손실에 대한 위험이 존재합니다. 따라서 EC2 인스턴스 스토어를 사용할 때에는 여러분의 필요에 따라 데이터를 백업해 두거나 복제해 둬야 합니다.

 

더 나은 성능에 대한 예시를 살펴보긴 할 텐데 굳이 알아 둘 필요는 없습니다.하지만 이 예시를 살펴보면

인스턴스 크기가 i3.인 인스턴스에 연결된 인스턴스 스토어가 있으며 Read IOPS와 Write IOPS에서 초당 수행 가능한 I/O 작업의 수를 확인할 수 있습니다. Read IOPS는 330만 Write IOPS는 140만에 달하는 것을 볼 수 있습니다. 성능이 가장 뛰어날 때 말이죠. 32,000 IOPS 정도인 BP2 유형 EBS 볼륨과 비교하면 훨씬 더 훌륭하다는 것을 알 수 있죠 이 예시는 단지 시험 대비를 위해 여러분의 EC2 인스턴스에 성능이 아주 뛰어난 하드웨어가 연결된 것이 보일 때, 로컬 EC2 인스턴스 스토어를 생각하라는 점을 알려드리려 한 것뿐입니다

 

63. EBS 볼륨 유형

오늘은 EBS 볼륨에 대해 살펴보죠 볼륨의 유형은 다양합니다.

총 여섯 개의 유형이 있고 이들을 여러 범주로 나눌 수 있습니다

1. 첫째로는 gp2/gp3가 있는데 이는 범용 SSD 볼륨으로

다양한 워크로드에 대해 가격과 성능의 절충안이 되어 줍니다. 본 코스에서 지금까지 사용한 유형이죠

 

 

2. 다음으로는 io1과 io2가 있습니다

최고 성능을 자랑하는 SSD 볼륨으로 미션 크리티컬이자 지연 시간이 낮고 대용량의 워크로드에 쓰입니다.

 

3. 그리고 st1 볼륨이 있는데 이는 저비용의 HDD 볼륨으로

잦은 접근과 처리량이 많은 워크로드에 쓰이죠. sc1 볼륨은 가장 비용이 적게 드는 HDD 볼륨으로 접근 빈도가 낮은 워크로드를 위해 설계되었습니다.

 

EBS 볼륨은 어떻게 정의하는 걸까요?

여러 요소가 있을 수 있습니다. 가령 크기, 처리량과 IOPS가 있죠. IOPS는 초당 I/O 작업 수를 뜻합니다. 언제나 그렇듯 의문이 생길 때는 문서를 참고하시면 됩니다

EC2 인스턴스에는 gp2/gp3와 io1/io2만이 부팅 볼륨으로 사용될 수 있습니다. 루트 OS가 실행될 위치에 해당하죠

 

이제 gp2/gp3, io1/io2 그리고 다른 유형에 대해 자세히 알아보죠

단, 시험에 있어서는 범용 gp2와 IOPS 프로비저닝이 가장 중요한 내용으로 출제됩니다.

gp2는 짧은 지연 시간을 자랑하며 효율적인 비용의 스토리지입니다. 시스템 부팅 볼륨에서 가상 데스크톱, 개발, 테스트 환경에서 사용할 수 있죠.

크기는 1GB에서 16TB까지 다양합니다. gp2와 gp3에는 차이가 있는데 gp3는 최신 세대의 볼륨으로 기본 성능으로 3,000 IOPS와 초당 125MB의 처리량을 제공합니다. 각각 IOPS는 최대 16,000 처리량은 1,000MB/s까지 증가시킬 수 있습니다. 연결되어 있지 않다는 뜻이죠.

gp2는 좀 더 오래된 버전으로 볼륨이 더 작습니다 최대 3,000 IOPS에 볼륨과 IOPS가 연결되어 있어서 IOPS가 증가할 때면 즉 볼륨의 GB 수를 늘릴 때에 세 배 더 증가한 16,000 IOPS가 된다는 의미입니다.

가령 5,334GB라고 한다면 최대 용량인 16,000 IOPS를 초과하는 상황이 발생하죠.

이 슬라이드에서 기억할 점은 gp2/gp3가 비용 효과적인 스토리지이며 gp3에서는 IOPS와 처리량을 독자적으로 설정할 수 있는 반면 gp2에서는 그 둘이 연결되어 있다는 점입니다.

 

 

시험에서 보게 될 다음 내용은 프로비저닝을 마친 IOPS로 이는 IOPS 성능을 유지할 필요가 있는 주요 비즈니스 애플리케이션이나 16,000 IOPS 이상을 요하는 애플리케이션에 적합합니다. 일반적으로 데이터베이스 워크로드에 알맞죠 스토리지를 이용하는 경우에 말입니다. 이는 스토리지 성능과 일관성에 아주 민감한데 따라서 이 경우에 해당하면 gp2 또는 gp3 볼륨에서 io1 또는 io2 볼륨으로 바꾸는 것이 해답이 될 겁니다.

io1/io2에 중에서는 최신 세대를 고르는 것이 좋습니다 4에서 16TB에 달하며 Nitro EC2 인스턴스에서는 최대 64,000 IOPS까지 가능합니다. Nitro EC2 인스턴스의 경우 이를 통해 더 높은 IOPS까지 이용할 수 있습니다. Nitro EC2 인스턴스가 아닌 경우에는 최대 32,000 IOPS까지 지원됩니다.

또한 io1/io2를 이용하면 gp3 볼륨처럼 프로비저닝된 IOPS를 스토리지 크기와 독자적으로 증가시킬 수 있습니다.

 

io2 이용 장점은 무엇일까요?

io1과 동일한 비용으로 내구성과 기가 당 IOPS의 수가 더 높습니다. 현재까지는 io2를 사용하는 것이 더 합리적인 거죠

간단히 io2 블록 익스프레스를 살펴보죠. 이는 4GB에서 64TB 달하며 좀 더 고성능 유형의 볼륨입니다. 지연 시간이 밀리초 미만이며 IOPS 대GB 비율이 1,000:1일 때 최대 256,000 IOPS를 자랑합니다

마침내 다음 강의에서

EBS 다중 연결을 지원하는 프로비저닝 IOPS의 EBS 볼륨 유형을 살펴봅니다

 

간단히 st1과 sc1에 대해 이야기해 보죠. 이 둘은 부팅 볼륨일 수 없습니다. 이전 유형의 볼륨에 해당하죠.

최대 16TB까지 확장되며 두 가지 종류의 볼륨을 제공합니다 하나는 st1인 처리량 최적화 HDD로 빅 데이터나 데이터 웨어하우징 로그 처리에 적합합니다. 최대 처리량은 초당 500MB 그리고 최대 IOPS는 500에 달합니다.

다음으로는 sc1인 콜드 HDD가 있는데 이는 아카이브 데이터용으로 접근 빈도가 낮은 데이터에 적합합니다. 최저 비용으로 데이터를 저장할 때에 사용하죠. 최대 처리량은 초당 250MB 그리고 최대 IOPS도 250입니다. 모든 세부적인 내용이 시험에 출제되지는 않습니다. 대략적으로 모든 볼륨의 차이를 이해하기만 하면 되죠.

 

범용 SSD와 프로비저닝 IOPS SSD의 차이나 데이터베이스가 필요할 때와 대용량, 저비용을 요할 때 st1을 사용하는 경우 그 차이를 이해하는 정도만 알면 됩니다. 방금 내용에 대한 요약은 아래 링크에서 찾아볼 수 있습니다.

이 스크린샷과 동일한 내용이죠. 세부적인 내용을 모두 기억할 필요는 없지만

32,000 IOPS 이상을 요할 때에는 io1 또는 io2 볼륨의 EC2 Nitro가 필요할 겁니다.

 

64. EBS 다중 연결

오늘은 EBS 다중 연결을 살펴보죠 io1/io2 제품군에 대한 내용입니다. 앞서 EBS 볼륨은 단일한 EC2 인스턴스에만 연결할 수 있다고 했습니다. EBS 다중 연결을 제외한 경우에 말이죠. 다중 연결로 동일한 EBS 볼륨을 동일한 가용 영역 내의 여러 EC2 인스턴스에 연결하여 사용할 수 있습니다.

 

표로 한번 살펴보죠

세 개의 EC2 인스턴스가 있고 다중 연결이 가능한 io2 볼륨이 있다고 가정해 봅시다. 이 볼륨은 한 번에 총 세 개의 EC2 인스턴스에 연결할 수 있습니다. 이때 각 EC2 인스턴스는 볼륨에 대한 전체 읽기 및 쓰기 권한을 갖습니다.

Teradata와 같이 클러스터 된 Linux 애플리케이션에서 애플리케이션의 가용성을 높여야 하는 경우가 있을 시 모든 애플리케이션에서 가능하지는 않으나 해당 애플리케이션 내에서는 동일한 볼륨에서의 동시 쓰기 작업을 관리할 수 있어야 합니다. 따라서 이는 특정 워크 로드에만 해당되며 특정 유형의 EBS 볼륨에 대해서만 가능합니다. 이를 위해서는 반드시 클러스터 인식 파일 시스템을 사용해야 합니다.

XFS나 EX4 등은 사용할 수 없죠. 특별한 파일 시스템을 필요로 합니다 이와 같은 기능이 시험에 나올 수 있다는 점만 기억하세요. EBS는 io1이나 io2 제품군일 때만 여러 EC2 인스턴스에 연결이 가능합니다.

 

65. EBS 암호화 + 실습

 

EBS 볼륨 암호화에 대해 배워봅시다. EBS 볼륨을 생성하면 즉시 다음과 같은 일이 일어나요.

1. 저장 데이터가 볼륨 내부에 암호화되고

2. 인스턴스와 볼륨 간의 전송 데이터 역시 암호화되죠

3. 스냅샷 뿐만 아니라 스냅샷으로 생성한 볼륨 역시 모두 암호화됩니다

암호화가 동시다발적으로 일어나요. 이때 암호화 및 복호화 메커니즘은 보이지 않게 처리되고 아무것도 하지 않아도 돼요

백그라운드에서 EC2와 EBS가 모두 처리하죠 종합적으로 봤을 때 암호화를 사용해야 하는 이유는 지연 시간에는 영향이 거의 없고 KMS에서 암호화 키를 생성해 AES-256 암호화 표준을 갖죠 알고 계시는 게 좋아요

스냅샷을 복사해 암호화를 푼 걸 다시 암호화 활성화를 하는 거죠

그럼 핵심 내용에 들어갑시다

EBS 볼륨을 암호화하거나 암호화를 푸는 방법을 배울 거예요.

0. EBS 볼륨 암호화 및 암호화 풀기 후, 발음이 상당히 어렵네요.

1. 우선 볼륨의 EBS 스냅샷을 생성하고

2. 복사 기능을 통해 EBS 스냅샷을 암호화합니다

3. 스냅샷을 이용해 새 EBS 볼륨을 생성하면 해당 볼륨도 암호화될 거예요

4. 이제 암호화된 볼륨을 인스턴스 원본에 연결해요

콘솔에서 함께 봅시다

그럼 EBS 볼륨의 옵션을 보고 암호화를 연습해 보죠

EBS 암호화를 하지 않은 1 GB 볼륨을 생성합시다

Encrypt this volume을 설정하지 않고

생성된 볼륨을 확인하면

암호화 상태를 보면 '암호화가 되지 않음'이죠

해당 볼륨에서 스냅샷을 생성하려고 하면

암호화 설정이 자동으로 Not encrypted로 지정됐어요

암호화되지 않은 EBS 볼륨에서 생성한 스냅샷은 암호화되지 않습니다

스냅샷을 생성하면

Snapshots 페이지가 생길 거예요

아까 봤듯이 암호화되지 않은 스냅샷이죠

따라서 암호화된 스냅샷을 생성하려면

Actions Copy snapshot으로

스냅샷을 복사할 때

동일한 대상 리전에 암호화를 활성화하면

스냅샷이 암호화될 거예요 체크박스를 체크하고

그 아래에 KMS 키도 선택하세요

이렇게 스냅샷을 복사하면 됩니다

방금 완성한 암호화 스냅샷에서 볼륨을 생성하려면

Create volume from snapshot을 클릭하세요

1 GB인 EBS 볼륨을 생성할 수 있죠

기초가 되는 스냅샷이 암호화되어 있어서 볼륨도 자동으로 암호화됩니다

Create Volume을 누르고

왼쪽 메뉴에서 Volumes에 들어가면

스냅샷으로부터 생성된 볼륨이 있고

암호화 상태가 '암호화 됨'이라고 나옵니다

이렇게 스냅샷 복사를 통해 EBS 볼륨을 암호화해봤어요

더 빠르게 하려면 암호화되지 않은 스냅샷을 클릭해서

Create volume from snapshot을 누른 다음

바로 EBS 볼륨에 암호화를 활성화하는 체크박스를 선택하고

aws/ebs 키를 선택하면

비암호화 스냅샷으로부터 암호화 EBS 볼륨을 생성할 수 있어요

두 가지 옵션을 모두 살펴봤어요

 

마치기 전에 delete를 입력해서 스냅샷을 삭제하는 걸 잊지 마세요

마찬가지로 EBS 볼륨도 모두 삭제합니다

그럼 다음 강의에서 다시 만나요

 

66. Amazon EFS(Elastic File System)

EFS는 관리된 NFS 즉 네트워크 파일 시스템이죠. 네트워크 파일 시스템이기 때문에 여러 EC2 인스턴스에 마운트할 수 있습니다. 또 EC2 인스턴스는 여러 가용 영역에 있다는 게 EFS의 큰 이점이죠. 높은 가용성으로 확장성이 뛰어납니다

gp2 EBS 볼륨에 비해 3배 정도 비싸며 사용할 때 마다 비용을 지불하기 때문에 사전 프로비저닝 용량이 없어요. EFS 파일 시스템을 보안 그룹으로 감싸고 us-east-1a 가용 영역의 여러 EC2 인스턴스나 us-east-1b 가용 영역의 EC2 인스턴스 혹은 us-east-1c 가용 영역의 E2C 인스턴스를 EFS를 통해 하나의 네트워크 파일 시스템에 동시에 연결할 수 있어요.

 

EFS 사용 사례에는 콘텐츠 관리 웹 서비스 제공, 데이터 공유 WordPress 등이 있습니다. 내부적으로 NFS 프로토콜을 사용하며 EFS 접근을 제어하기 위해 보안 그룹을 설정해야 해요. EFS에 관해 기억해야 할 점은 Windows가 아닌 Linux 기반 AMI에만 호환이 된다는 겁니다. KMS를 통해 EFS 드라이브의 저장 데이터 암호화를 활성화하며 Linux의 표준 파일 시스템이에요. 바로 표준 File API를 사진 POSIX 파일 시스템이죠 EFS의 장점은 용량을 미리 정하지 않아도 된다는 겁니다. 파일 시스템이 자동으로 확장되고 EFS에서 사용하는 데이터의 1GB마다 비용을 지불하면 됩니다

 

그럼 EFS의 성능에 대해 배워봅시다. 시험에 나올 수 있는 내용이에요. 수천 명의 NFS 클라이언트를 동시에 가질 수 있는 스케일에 10 GB/s 이상의 용량을 가집니다. 미리 용량을 정해두지 않아도 자동으로 페타바이트 수준의 스케일로 커질 수 있어요.

파일 시스템을 생성할 때 EFS의 성능 모드를 설정할 수 있습니다.

첫 번째는 기본값인 Performance 모드로

- 지연 시간이 중요한 경우에 사용합니다. 웹 서버, CMS 등이 있겠죠.

- I/O를 극대화하려면 Max I/O 모드를 사용하면 지연 시간과 용량이 늘어납니다. 또 병렬적 처리가 가능해 빅 데이터나 미디어 처리에 적합합니다.

 

다음은 Throughput 모드예요

- 기본값인 Bursting 모드가 1 TB 즉 50MiB/s 정도 속도의 데이터 전송을 지원하는데 100 MiB/s까지도 가능하죠.

- 이때는 프로비저닝도 설정할 수 있어요. 원래는 더 많은 공간을 사용할 수록 처리량과 용량이 커지는데 스토리지 크기와 무관하게 용량을 프로비저닝할 수 있습니다.

예를 들어 EFS에 1 TB의 스토리지가 있고 EFS 네트워크 파일 시스템에 1 GiB/s 속도를 프로비저닝할 수 있는 거죠.

 

스토리지 클래스에도 여러 옵션이 있어요. 그 중 스토리지 계층은 일정 시간 뒤 파일을 다른 계층으로 이동하는 기능입니다.

- Standard 계층은 자주 접속하는 파일에 적용되며

- Infrequent 계층 즉 EFS-IA 계층은 파일을 찾을 때 비용을 지불해야 하지만 EFS-IA에 파일을 저장할 때 비용이 낮아요. EFS-IA를 활성화하려면 수명 주기 정책을 사용해야 하죠. EFS Standard 계층에 자주 사용하는 파일이 있다고 가정합시다. 이때 60일 이상 액세스하지 않은 파일이 있다면 수명 주기 정책을 설정했기 때문에 파일이 EFS-IA 계층으로 이동될 거예요. 비용도 적어지죠

 

가용성과 내구성 측면에서는 두 가지 옵션이 있습니다

- EFS를 다중 AZ로 설정하면 프로덕션 환경에 훌륭하겠죠. 한 가용 영역이 다운돼도 EFS 파일 시스템에 영향이 없으니까요.

- 만약 One Zone EFS 파일 시스템을 원한다면 개발에는 좋지만 가용 영역이 하나일 뿐이고 기본값으로 백업이 활성화 됩니다. EFS-IA 계층과 호환이 가능해서 EFS One Zone-IA라고 부르며 큰 할인 폭으로 비용의 90% 정도를 절감할 수 있어요.

 

시험 문제에 EFS 사용 사례와

EFS 네트워크 파일 시스템에 설정할 수 있는 옵션이 나올 거예요

요구 조건을 확인하고 준수하는지 알아보기 위함이죠

 

67. Amazon EFS - 실습

자 EFS를 연습해봅시다

바로 EFS 콘솔로 가서

우리의 첫 번째 네트워크 파일 시스템을 생성해볼 거예요

보이는 대화창을 빠르게 넘어갈 수도 있지만

EFS 파일 시스템을 생성하는 여러 옵션을 배우고자

아래에 있는 Customize 버튼을 클릭하겠습니다

파일 시스템 설정에서

이름은 선택 사항이니 입력하지 않고 넘어갈게요

가용성과 내구성 옵션에는

리전 NFS EFS 파일 시스템이 있죠

여러 가용 영역 간에 데이터를 복제하고 싶을 때 사용하며

기본 옵션으로 프로덕션에 적합합니다

하지만 단순히 EFS 테스트하신다면 비용 절감을 위해

One Zone 타입의 EFS 파일 시스템을 선택하세요

하나의 AZ에만 데이터가 저장되므로

AZ가 다운되면 EFS 파일 시스템도 다운됩니다

이제 가용 영역을 선택해야 하는데

Regional 옵션으로 되돌려 두겠습니다

다음은 백업 자동화로 EFS 파일 시스템 백업을 설정해요

활성화 또는 비활성화할 수 있는데 우선 활성화를 선택할게요

아주 중요한 수명 주기 관리도 있죠

비용 절감을 위한 옵션이에요

자주 사용되지 않는 객체가 있다면

다른 액세스 계층인 Standard-Infrequent Access라는

스토리지 클래스로 이동시키는 겁니다

즉 파일이 30일 이상 액세스되지 않았으면

IA로 이동시켜서 비용을 절감하고

원하는 경우에만 IA 밖으로 이동되게 설정합니다

성능 모드에는 범용 옵션(General Purpose)과 Max I/O 옵션이 있죠

범용 옵션은 이름이 말해주듯이

다목적 용도이며 지연 시간이 중요한 경우에 사용해요

웹 서비스 제공 환경이나 콘텐츠 관리 시스템 등이죠

WordPress에 스토리지가 필요한 경우

범용 옵션을 사용하는 게 좋습니다

Max I/O 옵션을 선택하면

용량 및 초당 연산 작업이 최대가 됩니다

빅 데이터 등의 사용 사례에 해당하죠

지연 시간은 그만큼 늘어납니다

간단히 하기 위해 General Purpose (범용 옵션)로 두겠습니다

용량 모드에는 Bursting과 Provisioned가 있어요

Bursting 모드는 파일 시스템 크기와 비례한 용량을 가져요

파일 시스템이 클 수록 용량이 커지고 Burst도 추가되죠

반면 Provisioned는 1부터 1024 MiB/s 사이의 값으로

파일 시스템을 어느 정도로 읽을지 설정합니다

작은 파일 시스템에 유용한 옵션이지만

초반에 큰 처리량이 필요해요

Bursting 모드로 둘게요

저장 데이터 암호화도

설정을 바꾸지 않고 그냥 두겠습니다

다음은 네트워크 액세스 설정입니다

이때 VPC를 설정하는 게 중요해요

기본값 VPC로 둔 다음 마운트 타겟을 설정합니다

EFS의 Regional 유형을 선택하면 세 개의 AZ가 있네요

각 AZ가 서브넷에 지정되는데 기본 서브넷으로 두겠습니다

IP는 자동으로 설정되며 각각에 보안 그룹을 지정합니다

즉 EFS를 위해 특정 보안 그룹을 생성해야 하죠

EC2 콘솔을 열어

Security Groups에 들어가서 보안 그룹을 생성할게요

이름으로 sg-efs-demo를 지정하고

설명 역시 EFS Demo SG를 입력합니다

일단 인바운드 규칙은 설정하지 않을게요

Create Security Group을 누르면 실패하네요

sg를 지우고 efs-demo만 입력할까요

이렇게 efs-demo를 성공적으로 생성하고

페이지를 새로 고침 하면 나타날 겁니다

설정이 초기화됐는데 기본 설정으로 두고 그냥 넘어갑시다

원래 보안 그룹을 제거한 뒤

방금 생성한 efs-demo 보안 그룹을 선택할게요

좋습니다

이렇게 네트워크 액세스 구성도 모두 완성했어요

Next로 넘어가면

파일 시스템 정책이 있는데 선택 사항이므로 그냥 두겠습니다

고급 설정이라 아직은 필요하지 않아요

Next를 클릭해서

파일 시스템 설정을 검토하고 문제가 없으니

Create를 클릭하면

파일 시스템이 다 생성된 후에 나타날 거예요

생성된 파일 시스템을 살펴보면

6.00 KiB가 사용되고 있죠

EFS 파일 시스템은 사용한 스토리지에 대한 비용만 지불하므로

현재는 비용이 없다고 볼 수 있죠 좋습니다

이제 EC2 인스턴스에 마운트해볼게요

우선 EC2 인스턴스부터 생성해야겠죠

Launch instances를 클릭해

이름을 Instance A로 설정합니다

AZ A라는 서브넷에 실행할 거거든요

Amazon Linux 버전 2에

무료인 t2.micro를 선택하고

키 쌍은 비활성화하겠습니다

대신 EC2 인스턴스로 연결할 거예요

네트워크 설정은 그대로 두면

다음 규칙을 적용한 새 보안 그룹이 생성된다고 하네요

Allow SSH traffic은 Anywhere로 두겠습니다

이제 8 GiB의 gp2 스토리지를 설정하는데

EFS에 EC2 인스턴스의 스토리지를 구성하기 위해

바로 EC2 콘솔에서 보여드릴게요

그 전에 몇 가지 명령어를 실행합니다

0 x File systems 옆에 Edit을 누르면

'서브넷을 선택하기 전에 파일 시스템을 추가할 수 없다'라고 나오죠

다시 위로 올라가서 네트워크 설정을 수정합시다

서브넷으로 eu-west-1a를 선택할게요

서브넷을 생성하고 File systems에 가보면

EFS나 FSx 중에 EFS 파일 시스템을 선택합니다

Add shared file system을 클릭하면

바로 EFS에 연결될 거예요

마운트 포인트는 /mnt/efs/fs1이고 괜찮네요

그럼 보안 그룹이 자동으로 생성되고 연결됩니다

또 필요한 사용자 데이터 스크립트를 연결해서

공유 파일 시스템을 자동으로 마운트할 수 있어요

예전에는 EC2 인스턴스에 직접 실행하고

데이터 스크립트를 직접 생성해야 했는데

이제 EC2 콘솔이 대신 해줘서 아주 좋아요

이제 인스턴스를 하나 생성하고 실행해봅시다

자, 인스턴스가 실행됐어요

View all instances를 눌러 또 다른 인스턴스를 실행합니다

이번에는 Instance B라고 부르고

Amazon Linux 2에

빠른 작업을 위해 '키 쌍 없이 진행'을 선택할게요

가용 영역은 eu-west-1b에

전에 생성했던 보안 그룹 launch-wizard-2를 선택합니다

이번에도 Edit을 눌러 EFS 유형의 파일 시스템을 추가해야죠

전과 동일한 파일 시스템과 마운트 포인트를 지정하고

아래 옵션도 그대로 두겠습니다

Launch instance를 누르고

어떤 일이 일어났는지 볼까요

Instance state=running을 입력하고

두 인스턴스가 모두 보일 때까지 새로 고침 합니다

둘 다 실행되는 걸 확인하고 EFS 콘솔에 가서

Network 탭에 들어가면

각 가용 영역에 여러 보안 그룹이 있죠

전에 생성한 efs-demo 뿐만 아니라

efs-sg-1과 efs-sg-2도 있습니다

바로 EC2 콘솔이 우리 대신 생성하여 EFS 파일 시스템에 연결한 거죠

EC2 인스턴스로 돌아가서 Security Groups를 보면

efs-sg-2의 인바운드 규칙을 보면

NFS 프로토콜 유형과 20479 포트를 허용하며

소스가 보이죠

보안 그룹의 소스로

EC2 Instance B에 연결된 바로 그 보안 그룹이에요

Instance B의 EFS 파일 시스템 접근을 허용하겠죠

efs-sg-2라는 보안 그룹이

EFS 파일 시스템에 연결되어 있으니까요

이처럼 AWS가 모든 설정을 우리 대신 해주니 아주 좋죠

이제 Instance A에 들어가서

EC2 Instance Connect 탭을 눌러 연결을 하겠습니다

Instance B도 동일하게

EC2 Instance Connect로 연결할게요

그럼 /mnt/efs/fs1/라는 파일 시스템이 있는 걸 확인한 후

그 안에 파일을 생성할 차례예요

간단한 작업을 위해 권한을 높이는 sudo su를 입력하고

명령어 echo "hello world"에

/mnt/efs/fs1/ 안에

hello.txt를 입력하면

그럼 완성된 파일인 hello.txt의

전체 파일 이름에 cat 명령어를 실행하면

hello world가 출력되죠

EC2 인스턴스로부터 EFS 파일 시스템에 파일이 생성되었으며

가용 영역은 eu-west-1a입니다

두 번째 EC2 인스턴스로 가서 ls 명령어에

같은 파일 시스템을 입력해서

그 안에 있는 파일을 찾아보면

hello.txt가 나오죠

해당 파일에 cat 명령어를 실행하면

역시나 hello world가 나옵니다

두 EC2 인스턴스 모두 EFS 파일 시스템이

네트워크 드라이브로 마운트 된 거예요

이렇게 AZ는 다르지만 같은 EFS를 공유하는

두 가지 유형의 스토리지에 대한 데모를 만들었습니다

EFS 데모를 충분히 알아봤으니

정리하기 위해

두 EC2 인스턴스를 종료하세요

Terminate instance를 누르고

EFS 파일 시스템으로 돌아가서

파일 시스템 ID를 입력해 삭제합니다

모두 삭제하고 나면

Security Groups에 들어가서

데모 중에 생성된 추가 보안 그룹을 삭제하세요

아주 좋습니다 그럼 다음 강의에서 만나요

 

68. EFS vs EBS

 

이제 EBS와 EFS를 비교해 봅시다

EBS 볼륨은 한 번에 하나의 인스턴스에만 연결이 가능하고 특정 가용 영역에 한정됩니다. 예시를 보시면, EC2 인스턴스가 첫 번째 AZ에 연결됐고 EBS 볼륨은 실제로 해당 AZ 안에 있는 거죠. 그리고 한 번에 EC2 인스턴스 하나에만 연결 가능합니다

다른 유형의 EBS 볼륨이 있는데요. 중요한 유형으로 gp2가 있습니다 gp2에서는 디스크 크기가 늘어나면 IO도 함께 증가하죠. io 1은 IO를 볼륨 크기와 관계 없이 독립적으로 증가시킬 수 있죠. 중요한 데이터베이스를 실행할 때 좋은 방법입니다

 

EBS를 다른 가용 영역으로 옮기고자 할 때는 가장 먼저 스냅샷을 찍어야 합니다. 스냅샷을 찍었다면 다른 AZ에서 그 스냅샷을 복원시키죠. 그러면 해당 AZ에 EBS 볼륨이 생성될 겁니다. EBS의 스냅샷이나 백업을 만들 때에는 EBS 볼륨 내의 IO를 전부 사용하게 되니 인스턴스가 EBS를 사용 중이 아닐 때에만 실행하셔야 합니다. 그렇지 않으면 성능에 문제가 생길 수 있죠

 

EC2 인스턴스가 종료되면 인스턴스 내의 루트 EBS 볼륨도 기본적으로 종료됩니다. 원할 경우 이 동작은 비활성화할 수 있습니다

 

 

 

EFS는 일래스틱 파일 시스템으로 EFS는 여러 개의 가용 영역에 걸쳐 무수히 많은 인스턴스들에 연결될 수 있습니다.

예시의 인스턴스들은 Linux를 실행 중이고 해당 예시의 EFS들은 다중 AZ이기 때문에 AZ 외부에 존재합니다. EFS Mount Target을 사용해 특정 AZ에서 EC2 인스턴스들과 EFS 드라이브를 연결해 줄 수도 있습니다

 

WordPress 같은 웹 사이트 파일을 공유할 때도 EFS를 쓰죠. 이는 Linux 인스턴스에서만, 가능한데 POSIX 파일 시스템이라 Windows에서 구동되지 않기 때문입니다.

 

EFS는 EBS보다 훨씬 비쌉니다. 거의 세 배 정도 더 비싸죠. 하지만 비용을 절약하고 싶은 경우에는 스토리지 티어로 EFS-IA를 사용하고 제품 수명 정책을 사용하면 비용을 절감할 수 있습니다. EFS 사용 시에 또 기억해야 할 점은 EFS는 사용한 만큼만 비용이 청구된다는 겁니다. EBS의 경우에는 실제 사용한 양이 아니라 EBS 드라이브의 크기에 따라 실제 사용량이 아니라 정해진 사용량을 지불하는 식이었죠.

 

EFS는 다수의 인스턴스에 걸쳐 연결해야 하는 네트워크 파일 시스템에 적합하다는 걸 알아 두시면 됩니다. 반면 EBS는 네트워크 볼륨을 한 번에 하나의 인스턴스에 연결할 수 있고 특정 AZ 내로 한정이 되죠. 인스턴스 스토어는 EC2 인스턴스에 IO를 최대로 사용하게끔 해주지만, 인스턴스가 망가지면 함께 망가지는 임시 드라이브인 거죠.

 

69. EBS 및 EFS 섹션 정리

이 섹션 전체를 삭제해 봅시다

파일 시스템에 있는 Actions 메뉴에서 삭제를 하면 되는데요

파일 시스템 ID를 입력해야 하니 이 부분을 복사해 붙여 넣습니다

파일 시스템이 삭제되겠죠 됐습니다

이제 EC2 인스턴스로 가서 실행 중인 EC2가

없는지 확인해서 종료해 주세요

이번엔 볼륨입니다 볼륨 역시 전부

지워줄 거라서 실행 중인 볼륨이 있다면

모두 종료해 주시고요 우클릭 후 전부 삭제합니다

스냅샷의 경우에는 기존에 찍은 스냅샷들을

뒤로 돌아가서 모든 스냅샷을 삭제해 줍니다

모두 삭제해야 스냅샷에 차지하는 저장 공간에 비용을 지불할 일이 없겠죠

마지막으로 보안 그룹입니다

원하시면 삭제하시면 됩니다 보시다시피 보안 그룹이 굉장히 많죠

기본으로 되어있는 그룹 하나를 뺀 나머지 보안 그룹은

전부 지워도 되죠 기본은 지우시면 안 됩니다

이렇게 Delete Security Group을 클릭해 주시면 되죠

보통은 연계된 EC2 인스턴스들을 먼저 전부 지운 상태여야만

보안 그룹들을 삭제할 수 있습니다

그래서 바로 삭제가 되지 않을 수도 있는데

될 때까지 삭제를 계속 눌러 주시면 됩니다

이 보안 그룹도 지울게요 이건 바로 되네요

로드 밸런서 보안 그룹도 삭제해 주고요

네, 이것도 됐네요 ec2-for-efs도 지웁시다

이건 아직 인스턴스에서 사용 중이라

인스턴스가 올바르게 종료되기까지 잠시 기다린 후

마지막 보안 그룹을 지우면 됩니다

좀 더 기다려야 하네요 그럼 끝이 납니다

 

이렇게 전부 지우고 난 뒤 다음 섹션으로 넘어가시면 됩니다

 

EC2 데이터 관리 퀴즈