AWS Certified Soultions Architect Associate Day 06(EC2-SAA)

6. EC2-Associate

46. 프라이빗 vs 퍼블릭 vs 탄력적 IP

네트워크는 두 종류의 IP가 있습니다 IPv4와 IPv6입니다. IPv4가 가장 대중적인 거예요 아마 여러분도 이미 아실 텐데요. 네 개의 숫자가 세 개의 점으로 분리된 형태로 되어 있죠.

IPv6는 조금 덜 대중적인데 이건 정말 길고 독특한 숫자 기호와 문자로 이뤄진 이상한 문자열 형태로 되어 있습니다.

기본적으로 이 강의에서는 IPv4만 사용할 거예요. 하지만 AWS가 IPv6도 역시 지원한다는 걸 아셔야 합니다.

IPv4는 현재 여전히 온라인에서 가장 널리 사용되는 형식이고 IPv6는 IoT, 즉 사물 인터넷에 더 많이 쓰이는데요. IPv6는 많은 문제를 해결해 주지만 우리가 사용하지 않을 겁니다. 아직까지 우리는 IPv4로도 전혀 문제 없거든요. IPv4는 공용 공간에서 37억 개의 서로 다른 주소를 허용하는데그래서 이제 IP 주소가 거의 고갈되어 가고 있습니다. 기본적으로 IP 주소에서 점으로 나눠진 각 숫자는 0에서 255 사이의 숫자가 될 수 있는데 그럼 계산을 해보면 서로 다른 주소가 37억 개 정도 나오죠.

 

이게 의미하는 바가 무엇인지 예시를 한번 들어보겠습니다. 여기 공용 웹 서버가 하나 있다고 합시다. EC2 인스턴스이거나 공용 IP를 가졌을 수 있겠죠. 그리고 다른 공용 IP를 가진 다른 서버도 있을 수 있습니다. 이 서버들은 공용 IP를 사용해서 서로 통신할 수 있습니다, 멋지죠

이제 회사가 하나 있다고 합시다 제 회사라고 예를 들겠습니다. 회사엔 사설 네트워크가 있고 사설 네트워크에는 기본적으로 사설 IP 범위가 있는데 사설 IP는 매우 구체적으로 정의되지만 기본적으로 사설 네트워크 내의 모든 컴퓨터가 사설 IP를 사용하여 서로 통신할 수 있음을 의미합니다. 반면 공용 게이트웨이인 인터넷 게이트웨이를 이용하게 되면 이 인스턴스들도 다른 서버들에 액세스할 수 있게 됩니다. 이것이 AWS의 일반적인 패턴입니다.

만일 여러분이 사설 네트워크가 있는 다른 회사를 갖고 있다면 사설 네트워크 안에서 모든 컴퓨터들은 다른 컴퓨터들과 통신할 수 있고 이 회사 역시 IP가 있는 인터넷 게이트웨이가 있어서 인터넷을 통해 어디든 연결하며 다른 서버들과 통신할 수 있겠죠.

보여드리고자 했던 차이점은 공용 IP가 있으면 인터넷 전역에 액세스할 수 있고 사설 IP로는 사설 네트워크 내에서만 액세스할 수 있다는 점입니다.

 

 

이렇게 몇 가지 차이가 있습니다 말씀드렸듯 공용 IP는 곧 기기가 인터넷상에서 식별될 수 있음을 의미합니다. 그리고 각 공용 IP는 전체 웹에서 유일한 것이어야 하는데 즉 두 개 이상의 기기가 같은 공용 IP를 가질 수는 없다는 거죠. 그리고 IP가 있으면 Google 검색으로 그 IP의 지리적 위치를 쉽게 찾을 수 있습니다.

반면 사설 IP는 기기가 오직 사설 네트워크 안에서만 식별될 수 있으며 따라서 IP가 사설 네트워크 안에서만 유일한 것이면 됩니다. 그러니까 두 개의 다른 사설 네트워크 즉 두 개의 다른 회사는 같은 사설 IP를 가질 수 있고 전혀 문제가 되지 않습니다.

기기가 사설 네트워크에 있을 때 NAT 장치와 프록시 역할을 할 인터넷 게이트웨이를 통해 인터넷에 연결됩니다. 마지막으로 지정된 범위의 IP만 사설 IP로 사용될 수 있습니다.

 

 

마지막으로 탄력적 IP의 경우 EC2 인스턴스를 시작하고 중지할 때 공용 IP를 바꿀 수 있습니다

어떤 이유에서든 인스턴스에 고정된 공용 IP를 사용하면탄력적 IP가 필요하게 될 겁니다

탄력적 IP는 공용 IPv4인데 삭제하지 않는 한 계속 가지고 있게 되고요. 이건 당연히 한 번에 한 인스턴스에만 첨부할 수 있습니다.

 

 

IP 주소가 탄력적이면 한 인스턴스에서 다른 인스턴스로 빠르게 이동함으로써 인스턴스 또는 소프트웨어의 오류를 마스킹할 때 사용할 수 있지만 이런 일은 사실 드문데요.

왜냐하면 계정당 탄력적 IP를 5개만 쓸 수 있기 때문입니다. AWS에 개수 증가를 요청할 수는 있지만 사실 그렇게 사용할 일은 드물죠.

결론적으로 탄력적 IP는 사용하지 않는 것이 좋습니다. 이건 매우 좋지 않은 구조적 결정으로 종종 언급되거든요. 대신 임의의 공용 IP를 써서 DNS 이름을 할당하는 것이 좋습니다. DNS는 Route 53에서 살펴볼 텐데 훨씬 더 많은 제어가 가능하고 확장 가능성도 더 큽니다.

또는 나중에 보게 되겠지만 로드 밸런서를 사용해서 공용 IP를 전혀 사용하지 않을 수도 있습니다. AWS에서 취할 수 있는 최상의 패턴이죠

 

 

기본값으로 EC2 기기는 내부 AWS 네트워크엔 사설 IP를 쓰고 World Wide Web 즉 WWW엔 공용 IP를 사용합니다. 그리고 EC2 기기에 SSH를 할 땐 사설 IP를 사용할 수 없는데요 왜냐하면 VPN을 쓰지 않는 이상 같은 네트워크에 있는 게 아니기 때문이죠. 그러니 VPN이 없다면 공용 IP만 사용할 수 있습니다. 그리고 기기가 멈췄다가 다시 시작하면 공용 IP가 바뀔 수도 있습니다.

 

47. 프라이빗 vs 퍼블릭 vs 탄력적 IP 실습

IP를 접속해보면 알겠지만 public으로 ssh 접근은 되는데 private 접근은 막히어 있다.

 

만약 이걸 껐다가 킨다면 public ip는 변경된다. 그래서 이 문제점을 해결하기 위해 Elastic IP를 사용해야만 한다.

 

탄력적 IP 탭으로 가서 새로운 IP 주소를 할당해보자

 

만약 이걸 연결 안 시키면 요금이 부과되기 때문에 빠르게 연결해야 한다.

 

그러면 위와같이 연결을 할 수 있게 된다.

 

 

이 상태에서 public IP가 elastic ip와 같아진 것을 볼 수 있다.

 

이제 이 public IP로 접속할 수도 있고 인스턴스를 껏다 켜도 ip는 유지된다.

 

 

이제 다시 elastic ip로 가서 해제해주자

 

 

48. EC2 배치그룹

이제 배치 그룹에 대해 이야기해 보겠습니다. 배치 그룹은 조금 더 심화된 내용입니다

EC2 인스턴스가 AWS 인프라에 배치되는 방식을 제어하고자 할 때 씁니다.

배치 그룹을 사용하여 이러한 전략을 정의할 수 있습니다. AWS의 하드웨어와 직접적인 상호 작용을 하지는 않지만 EC2 인스턴스가 각각 어떻게 배치되기를 원하는지 AWS에 알려주는 거죠.

따라서 배치 그룹을 만들 때 세 가지 전략을 사용할 수 있습니다.

- 단일 가용 영역 내에서 지연 시간이 짧은 하드웨어 설정으로 인스턴스를 그룹화할 클러스터 배치 그룹이 있습니다. 이 전략은 높은 성능을 제공하지만 위험 또한 높습니다. 자세한 건 곧 보겠습니다.

- 분산 배치 그룹은 인스턴스가 다른 하드웨어에 분산된다는 의미입니다. 여기에는 가용 영역별로 분산된 배치 그룹당 7개의 EC2 인스턴스만 가질 수 있다는 제한 사항이 있습니다. 따라서 크리티컬 애플리케이션이 있는 경우 분산 배치 그룹을 사용합니다

- 마지막으로 정말 유용한 새로운 유형의 배치 그룹으로 분할 배치 그룹이 있습니다. 분산 배치 그룹과 비슷하게 인스턴스를 분산하려는 것인데요. 다만 이건 여러 파티션에 인스턴스가 분할되어 있고 이 파티션은 가용 영역 내의 다양한 하드웨어 랙 세트에 의존합니다. 즉 인스턴스가 여전히 분산되어 있지만 다른 실패로부터 격리되지 않았다는 겁니다. 하지만 파티션은 다른 오류 파티션과 격리되어야 합니다. 즉 그룹당 수백 개의 EC2 인스턴스를 통해 확장할 수 있고 이를 통해 Hadoop, Cassandra, Kafka 같은 애플리케이션을 실행할 수 있다는 겁니다.

 

 

 

이제 이 배치 그룹에 대해 자세히 살펴보겠습니다. 클러스터 배치 그룹의 경우 이는 모든 EC2 인스턴스가 동일한 랙에 있다는 겁니다 즉 동일한 하드웨어와 동일한 가용 영역에 있다는 거죠. 보시다시피 이러한 모든 인스턴스는 동일한 하드웨어에 있습니다.

그러면 어떻게 해야 할까요? 클러스터 배치 그룹을 만들려고 하고 지연 시간이 매우 짧은 10GB 속도 정도의 네트워크를 원하기 때문에 우린 이들을 동일한 랙에 배치합니다. 즉 우리는 놀라운 네트워크를 갖게 되는 거죠.

그러나 이 훌륭한 네트워크의 단점은 랙에 실패가 발생하면 즉 하드웨어에 실패가 발생하면 모든 EC2 인스턴스가 동시에 실패한다는 겁니다. 그래서 전체 스택에 걸쳐 실패가 전파될 위험을 높인 꼴이 되었습니다

언제 이것을 사용하게 될까요? 이렇게 위험이 증가하는 대신 얻는 혜택이 뭘까요?

- 엄청난 네트워크를 얻었죠. 이 네트워크로 매우 빨리 완료되어야 할 빅데이터 작업을 수행할 수 있습니다.

- 또는 극히 짧은 지연 시간과 높은 네트워크 처리량을 필요로 하는 그런 애플리케이션에 대한 요청이 있는 경우엔 이런 실패를 겪을 위험을 기꺼이 감수할 수도 있겠죠.

 

여러분이 알아 두셔야 할 점은 모든 종류의 애플리케이션에 적용되진 않지만 애플리케이션에 매우 높은 대역폭과 짧은 지연 시간이 필요한 경우 클러스터 배치 그룹이 이를 수행하는 좋은 방법입니다.

 

 

분산 배치 그룹은 완전히 반대입니다. 분산 배치 그룹에서는 실패 위험을 최소화하려고 합니다.

그래서 이 경우 분산 배치 그룹으로 하게 되면 모든 EC2 인스턴스가 다른 하드웨어에 위치하게 됩니다. 여기에서 볼 수 있듯이 3개의 가용 영역과 6개의 EC2가 있고 각 EC2 인스턴스는 서로 다른 하드웨어에 있습니다

 

이게 무슨 뜻일까요?

- 장점은 여러 가용 영역에 걸쳐 있을 수 있으며

- 동시 실패의 위험이 감소한다는 겁니다. Hardware 1이 실패하더라도 Hardware 2가 실패하지 않을 거라 확신할 수 있기 때문이죠.

- 그래서 Us-east-1a에 있는 두 인스턴스가 동시에 실패할 위험을 분리했습니다. 이것이 분산 배치 그룹의 이점입니다

 

단점은 이 구성에서 배치 그룹의 가용 영역당 7개의 인스턴스로 제한이 된다는 겁니다. 즉 배치 그룹의 규모에 제한이 있는 거죠. 그래서 크기가 적당하지만 너무 크지는 않은 그런 애플리케이션에서만 쓸 수 있습니다.

 

사용 사례는 가용성을 극대화하고 위험을 줄여야 하는 애플리케이션입니다. 그리고 일반적으로는 인스턴스 오류를 서로 격리해야 하는 크리티컬 애플리케이션의 경우죠 여기서 기억하세요, 배치 그룹당 가용 영역당 인스턴스 수는 7개로 제한됩니다.

 

 

 

이제 분할 배치 그룹의 경우에는 여러 가용 영역의 파티션에 인스턴스를 분산할 수 있습니다. 가용 영역당 최대 7개의 파티션이 있을 수 있고요.

이 예시에선 us-east-1a에 Partition 1과 Partition 2가 있고 각 파티션에는 많은 EC2 인스턴스가 있을 수 있습니다.

첫 번째 것에는 4개, 두 번째에는 4개 세 번째에도 4개 있습니다.

 

그럼 분할 배치 그룹을 쓰는 이유는 뭘까요?

각 파티션은 AWS의 랙을 나타냅니다. 파티션이 많으면 인스턴스가 여러 하드웨어 랙에 분산되어 서로 랙 실패로부터 안전합니다. 따라서 가용 영역당 최대 7개의 파티션이 있을 수 있고

이러한 파티션은 동일한 리전의 여러 가용 영역에 걸쳐 있을 수 있습니다.

설정으로 최대 수백 개 EC2 인스턴스를 얻을 수 있습니다. 이것이 분산 배치 그룹 유형과의 차이입니다.

그리고 말씀드렸듯 인스턴스와 파티션은 다른 파티션의 인스턴스와 동일한 하드웨어 물리적 랙을 공유하지 않으므로 각 파티션은 실패로부터 격리됩니다.

즉 파티션이 하나가 다운되면 만일 Partition 2가 다운되면 Partition 1은 정상이어야 함을 의미합니다.

그리고 이러한 EC2 인스턴스가 어떤 파티션에 있는지 알기 위해 메타데이터 서비스를 사용하여 이 정보에 액세스하는 옵션이 있습니다.

 

그럼 언제 분할 배치 그룹을 사용해야 할까요? 파티션들 전반에 걸쳐 데이터와 서버를 퍼뜨려 두도록 파티션 인식 가능한 애플리케이션의 경우에 사용합니다.

일반적인 사용 사례는 HDFS Hbase Cassandra 및 Apache Kafka를 사용하여 파티션을 인식하는 빅 데이터 애플리케이션이 되겠죠.

 

 

 

49. 배치 그룹 - 실습

새로운 인스턴스 생성

고급 옵션에 Placement group을 고를 수 있다.

 

50. ENI(탄력적 네트워크 인터페이스)

VPC의 논리적 구성 요소이며 가상 네트워크 카드를 나타낸다.

ENI는 EC2 인스턴스가 네트워크에 엑세스 하게 해준다. ENI는 외부에서도 접근할 수 있게 해준다.

 

예를 들어 가용 영역 안에 하나의 EC2 인스턴스가 있을때. 기본 ENI는 eht0에 연결되어 EC2 인스턴스 네트워크 연결을 제공한다. 사설 IP로 제공한다.

 

각 ENI는 다음 과 같은 속성을 갖게 된다.

1. 주요 사설 IPv4와 하나 이상의 보조 IPv4를 가지게 된다.

2. 각 ENI는 사설 IPv4당 탄력적 IPv4 또는 공용 IPv4를 가질 수 있다.

사설 및 공용 IP가 한 개씩 제공된다. 

3. ENI에 하나 이상의 보안 그룹을 연결할 수 있다.

 

EC2 인스턴스와 독립적으로 ENI를 생성하고 즉시 연결하거나 장애 조치를 위해 EC2 인스턴스에서 이동시킬 수 있다.

또 ENI는 특정 AZ에 바인딩된다.

 

그래서 위의 예시와 같이 첫 번째 문제 인스턴스에서 Eth1 를 뽑아다가 다른 인스턴스에 옮겨 붙일 수도 있다. 장애 조치에 매우 유용하다.

 

---

탄력적 네트워크 인터페이스 즉 ENI에 대해 살펴보겠습니다. 제가 ENI라고 할 땐 탄력적 네트워크 인터페이스를 가리키는 겁니다

VPC의 논리적 구성 요소이며 가상 네트워크 카드를 나타냅니다. ENI는 EC2 인스턴스가 네트워크에 액세스할 수 있게 해주죠. 이후 강의에서 보시겠지만 ENI는 EC2 인스턴스 외부에서도 사용됩니다.

예를 들어 가용 영역이 있고 하나의 EC2 인스턴스가 있다고 합시다. 기본 ENI인 Eth0에 연결되어 EC2 인스턴스 네트워크 연결을 제공합니다. 예를 들어 사설 IP로요.

 

각 ENI는 다음과 같은 속성을 가질 수 있습니다

- 첫 번째로 주요 사설 IPv4와 하나 이상의 보조 IPv4를 가질 수 있습니다. 따라서 이 예시에서는 Eth0 하나만 있지만 EC2에 보조 ENI를 얼마든지 추가해도 되는 거죠. 그건 Eth1이 될 거고 또 다른 사설 IPv4도 제공될 겁니다.

- 각 ENI는 사설 IPv4당 탄력적 IPv4를 갖거나 혹은 하나의 공용 IPv4를 가질 수 있으므로 사설 및 공용 IP가 한 개씩 제공됩니다. 이후 실습에서도 보시게 될 거예요.

- ENI에 하나 이상의 보안 그룹을 연결할 수 있습니다

- Mac 주소 및 기타 항목을 연결할 수도 있지만 지금 이 강의에서는 가장 중요한 부분만 알려드리겠습니다.

 

또 EC2 인스턴스와 독립적으로 ENI를 생성하고 즉시 연결하거나 장애 조치를 위해 EC2 인스턴스에서 이동시킬 수 있습니다. 어떻게 생겼는지 살펴보겠습니다

참고로 ENI는 특정 가용 영역 즉 AZ에 바인딩됩니다. 즉 특정 AZ에서 ENI를 생성하면 해당 AZ에만 바인딩할 수 있습니다.

 

이 인스턴스에 다른 문제가 생겼는데 또 다른 ENI가 연결되어 있다고 합시다. 그러면 첫 번째 EC2 인스턴스에서 두 번째 EC2 인스턴스로 Eth1을 옮겨서 사설 IP를 이동시킬 수 있습니다. 그러면 사설 IP가 첫 번째 문제 인스턴스에서 두 번째 EC2 인스턴스로 연결되게 됩니다. 장애 조치에 매우 유용하죠. 가령 사설 정적 IP로 EC2 인스턴스에 액세스하는 경우 장애 조치를 위해 EC2 인스턴스 간에 IP를 이동시킬 수 있습니다.

 

 

51. ENI 실습

위와같이 기존에 만들던 것에 인스턴스 숫자만 2개로 해서 배포하자

 

이제 인스턴스를 살피어 보면 위와같이 ENI 가 잡혀 있는 것을 볼 수 있다.

 

네트워크 인터페이스로 가보면 두 개의 네트워크 인터페이스가 잡혀 있는 것을 볼 수 있다.

위와 같이 해서 새로운 ENI 를 생성해보자

 

만들어진 ENI를 연결해보자

아무거나 골랐다.

 

ENI가 두 개 붙은 인스턴스를 확인할 수 있다.

 

DemoENI는 우리가 조절할 수 있기 때문에 다른 인스턴스로 ENI를 옮겨줄 수 있다. 이렇게 하면 빠르게 네트워크 에러 조치를 할 수 있다.

 

이 상태에서 인스턴스 두 개를 모두 종료시키면 Default ENI는 삭제되고 우리가 만든 ENI는 Available 상태가 된다.

ENI는 비용이 들지 않으니 마음대로 가지고 놀자

https://aws.amazon.com/blogs/aws/new-elastic-network-interfaces-in-the-virtual-private-cloud/

 

New – Elastic Network Interfaces in the Virtual Private Cloud | Amazon Web Services

 

53. EC2 Hibernate 모드

인스턴스를 중지하면 EBS 디스크 데이터는 다시 시작할 때까지 그대로 유지된다.

인스턴스를 종료하면 루트 볼륨이 삭제되게 했다면 인스턴스도 삭제된다. 그외의 볼륨들은 그대로 남게된다.

 

인스턴스를 다시 시작하면 운영 체제가 먼저 부팅되기 시작하고 EC2 사용자 데이터 스크립트도 실행

 

---

 

이번 강의에서는 EC2 절전 모드(Hibernate)라는 다소 생소한 기능을 배워보겠습니다. 지난 시간에는 인스턴스를 중지 또는 종료하는 법을 배웠습니다.

인스턴스를 중지하면 EBS 디스크 데이터는 다시 시작할 때까지 그대로 유지될 겁니다.

하지만 인스턴스를 종료한다면 루트 볼륨이 삭제되게 했다면 인스턴스도 삭제되겠죠. 하지만 그렇게 설정하지 않은 다른 볼륨은 인스턴스가 종료되더라도 그대로 남습니다.

 

그리고 인스턴스를 다시 시작하면 운영 체제가 먼저 부팅되기 시작하고 EC2 사용자 데이터 스크립트도 실행됩니다.

그 뒤 운영 체제가 부팅이 완료되고 애플리케이션도 실행되고 캐시도 구성되기 시작하므로 과정이 끝날 때까지 시간이 다소 걸리겠죠.

 

 

인스턴스 절전 모드가 되면 RAM에 있던 인 메모리 상태는 그대로 보존. => 인스턴스 부팅이 보다 빨라진다.

 

백그라운드에서 RAM에 기록되었던 인 메모리 상태는 루트 경로의 EBS 볼륨에 기록되기 때문에 루트 EBS를 암호화 하고 볼륨 용량도 RAM을 저장하기에 충분해야겠죠

 

예를 들어 실행 중인 EC2 인스턴스가 있다고 합시다

RAM에는 데이터가 있고요 이제 절전 모드를 켜면 실행 중인 인스턴스는 중지 상태로 전환되고 RAM의 내용은 EBS 볼륨에 덤프됩니다. 그리고 인스턴스를 종료하면 RAM이 사라집니다

인스턴스를 종료하면 RAM은 사라지죠

하지만 EBS 볼륨에는 여전히 RAM이 덤프된 게 있으니, 인스턴스를 다시 실행하면 디스크에서 RAM을 불러와 EC2 인스턴스 메모리로 가져간다.

이렇게 하면 EC2 인스턴스를 중지한 적이 없는 것처럼 됩니다

 

절전 모드의 사용 사례입니다

1. 오래 실행되는 프로세스를 갖고 있고 중지하지 않을 때

2. RAM 상태를 저장하고 싶을 때

3. 빠르게 재부팅을 하고 싶을 때

4. 서비스 초기화가 시간을 많이 잡아먹어 서비스가 중단 없이 인스턴스를 절전 모드로 전환하고 싶을 때 등의 사용 사례가 있겠죠.

 

---

그러면 여기서 절전 모드(Hibernate)라는 새로운 상태를 알아봅시다

인스턴스가 절전 모드가 되면 RAM에 있던 인 메모리 상태는 그대로 보존됩니다.

다시 말해, 인스턴스 부팅이 더 빨라진다는 거죠. 운영 체제를 완전히 중지하거나 다시 시작하지 않고 그대로 멈춰뒀으니까요.

절전 모드가 되고 백그라운드에서 RAM에 기록되었던 인 메모리 상태는 루트 경로의 EBS 볼륨에 기록되기 때문에 루트 EBS 볼륨을 암호화해야 하고 볼륨 용량도 RAM을 저장하기에 충분해야겠죠.

 

 

예를 들어 실행 중인 EC2 인스턴스가 있다고 합시다. RAM에는 데이터가 있고요 이제 절전 모드를 켜면 실행 중인 인스턴스는 중지 상태로 전환되고 RAM의 내용은 EBS 볼륨에 덤프됩니다. 그리고 인스턴스를 종료하면 RAM이 사라집니다. 인스턴스를 종료하면 RAM은 사라지죠. 하지만 EBS 볼륨에는 여전히 RAM이 덤프된 게 있으니 인스턴스를 다시 실행하면 디스크에서 RAM을 불러와 EC2 인스턴스 메모리로 가져갑니다.

이렇게 하면 EC2 인스턴스를 중지한 적이 없는 것처럼 됩니다. 이를 실습을 통해 살펴보겠습니다.

 

다음은 절전 모드의 사용 사례입니다

- 오래 실행되는 프로세스를 갖고 있고 중지하지 않을 때

- RAM 상태를 저장하고 싶을 때

- 빠르게 재부팅을 하고 싶을 때

서비스 초기화가 시간을 많이 잡아먹어 서비스가 중단 없이 인스턴스를 절전 모드로 전환하고 싶을 때 등의 사용 사례가 있겠죠.

 

EC2 Hibernate에 관해 아시고 넘어갈 부분은 지원하는 제품군이 많고 인스턴스 RAM 크기는 최대 150GB라는 거죠

이 크기는 변할 수 있지만 시험에 나오진 않을 거예요

 

Hibernate는 베어 메탈 인스턴스에는 적용할 수 없고 Linux, Windows 등의 여러 운영 체제에서 사용할 수 있고

루트 볼륨, 즉 EBS에만 저장이 가능하며, 암호화가 필요하고 덤프된 RAM을 포함할 만큼 충분한 용량이 있어야 합니다

 

온디맨드(On-Demand), 예약(Reserved) 스팟(Spot)와 같은 모든 종류의 인스턴스에 사용할 수 있습니다

그리고 절전 모드는 최대 60일까지 사용할 수 있고 이후에 변경될 수도 있지만 현재는 60일이 최대 기간입니다

 

---

- EC2 Hibernate에 관해 아시고 넘어갈 부분은 지원하는 제품군이 많고

- 인스턴스 RAM 크기는 최대 150GB라는 거죠 이 크기는 변할 수 있지만 시험에 나오진 않을 거예요. 알고 계시면 절전 모드를 이해하기가 더 수월할 겁니다.

- Hibernate는 베어 메탈 인스턴스에는 적용할 수 없고

- Linux, Windows 등의 여러 운영 체제에서 사용할 수 있고

- 루트 볼륨, 즉 EBS에만 저장이 가능하며

- 암호화가 필요하고

- 덤프된 RAM을 포함할 만큼 충분한 용량이 있어야 합니다

- 온디맨드(On-Demand), 예약(Reserved) 스팟(Spot)와 같은 모든 종류의 인스턴스에 사용할 수 있습니다.

- 그리고 절전 모드는 최대 60일까지 사용할 수 있고 이후에 변경될 수도 있지만 현재는 60일이 최대 기간입니다.

 

 

 

54. EC2 Hibernate 모드 실습

EC2 Hibernate 기능을 직접 사용해 봅시다

먼저 인스턴스를 실행해 봅시다

Amazon Linux 2, t2.micro로 지정된 것을 확인하고

키 쌍(Key pair)은 EC2 Tutorial 그리고 네트워크 보안에서는

존재하는 보안 그룹인

launch-wizard-1을 지정합시다

스토리지는 지금 상태로 두면 되겠네요

몇 가지 보여드릴 것이 있는데

아래로 내려가 보면 '중지 - 대기 모드 행동'이 있습니다

이 설정을 활성화하면

EC2 인스턴스를 절전 모드로 둘 수 있게 됩니다

- 절전 모드를 활성화하는 경우 루트 볼륨에 RAM을 저장할 수 있는 공간 즉 EC2 인스턴스를 저장할 공간이 충분한지 그리고 루트 EBS 볼륨이 암호화되었는지 확인하라고 되어 있어요

먼저 저장소 구성(Configure storage)에서 고급(Advanced)을 누르고 EBS 볼륨에서 암호화(Encrypted)를 Yes로 두고 KMS 키는 기본값인 awg/ebs로 지정하면 절전 모드를 위한 설정이 끝납니다

 

용량은 8 GiB가 할당되어 있고

이 정도면 충분합니다 t2.micro를 보시면 1 GiB의 메모리를 사용하기 때문에 이 정도 크기의 RAM은 디스크에 저장하는 데 문제가 없겠죠

인스턴스가 생성되었고

이렇게 EC2 Instance Connect에서 인스턴스를 연결했습니다

 

특정 중지 동작을 절전 모드로 활성화 했어요. 그러면 제대로 작동하는지 어떻게 알 수 있을까요?

uptime이라고 하는 명령어가 있는데 이 명령어를 실행하면 인스턴스가 얼마 동안 가동되었는지를 알 수 있습니다

 

이 uptime이라는 명령어는 최근 재시작부터 가동된 시간을 알려줍니다

이제 인스턴스의 연결을 해제하고

인스턴스를 절전하는 것입니다.

 

인스턴스 상태(Instance state)에서 인스턴스 절전(Hibernate instance)을 클릭하면 RAM에 있던 모든 데이터를 EC2의 EBS 볼륨에 저장해줍니다

 

만약 절전 모드를 하지 않고 인스턴스를 중지했다가 다시 실행했다면 uptime 명령어의 결과는 0분이었다가

다시 1분이 되겠죠 중지 후에 시작했으니까요

하지만 인스턴스를 절전 모드가 됐다가 다시 시작하면 이런 경우에는 uptime의 결과는 0이 아니라 3-4분로 시간이 계속될 거예요

이제 다시 인스턴스에서 uptime을 입력하면 1시간 17분에서 종료한 시점에서 부터 현재까지 이어져 오고 있는 것을 알 수 있다.

 

여기서 핵심은, 우리가 인스턴스를 중지했다고는 하지만 우리는 절전 모드로 뒀다가 다시 실행한 것이기 때문에

운영 체제가 보기에는 이 인스턴스는 한 번도 중지된 적이 없죠

따라서 uptime 명령어를 입력하면 2-3분이 나오는 겁니다

즉, 중지한 적이 없는 것처럼 운영 체제가 인식하게 하는 것이 절전 모드의 목적입니다

 

 

 EC2 - SAA 문제