가끔 블럭 디바이스와 EC2, AMI와의 관계와의 내용이 명확하지 않아 이들 서비스간의 내용을 정리해 봅니다. 프로그래밍으로 따지자면 클래스와 객체정도로 비유 될수 있을텐데요, 이미지들을 테스트나 개발 계정에서 테스트하고 배포하기위하여 이미지를 프로모션하는 경우 이러한 관계를 명확히 하지않으면 인프라 코딩이 어려워 질수있다는 경험을 하였습니다.




AMI

AMI의 가장중요한 역할중 하나는 EC2 Instance를 생성하는 Base이미지 역할을 하는것이라고 할수 있습니다.


또한 이 AMI는 AWS로부터 제공되는 이미지를 사용할수있지만, 회사 조직내에서 미리 준비된 AMI를 생성할수도 있습니다. 이때 조직내에서 AMI를 생성하였다면 AMI는 어떤 Block디바이스(즉 디스크)와 마운트 될것인지 정보를 자체적으로 포함하고있기 있을겁니다. 이런 경우 지정된 Block디바이스(AMI에서 사용될 디스크)는 Snapshot으로 만들어져 보관되어 집니다. (이런경우 Snapshot을 지우려고 하는 경우 삭제할수 없다는 오류 메시지가 뜹니다.)


역으로 종종 Snapshot으로부터 AMI를 다른 계정에 생성해야하는 경우가 생기는데 이경우 복사하고자 하는 AMI가 어떤 블럭디바이스(Snapshot)를 사용하고 있는지 조사해서 해당 Snapshot도 복사(또는 공유)해줘야 합니다.


EC2

EC2인스턴스를 생성할때 반드시 하나이상의 블럭 디바이스를 지정해야하는데 Root디바이스는 필수이기 때문입니다. 그밖에 추가로 마운트될 디바이스를 지정하는 경우 추가로 Volume이 생성되기도 합니다.


이렇게 생성된 EC2인스턴스는 역으로 AMI를 생성해 둘수가 있는데 이때 사용되었던 Block디바이스가 있었다면 AMI에 자동으로 추가할 것인지 물어보지만, 원하지 않는경우 빼버리거나 블럭디바이스의 Encrypt옵션도 추가해서 저장할 수 있습니다.



Volume/Snapshot

볼륨은 현재 서버(EC2 인스턴스)에서 사용하고있는 디스크와도 같습니다. 이 디스크(편의상)는 특정시점에 Snapshot 형태로 분리하여 저장할수도 있고, 역으로 Snapshot으로부터 서버에서 사용할수 있(마운트가능한)는 형태의 디스크로 생성할 수도 있습니다.



Snapshot

이미 Snapshot에 대해 설명했지만, 흥미로운 점은 Snapshot으로 부터 AMI를 생성할 수도 있다는 겁니다. 일반적으로 EC2로부터 AMI를 생성하는 것이 여러면에서 쉽지만 종종 Snapshot으로 부터 AMI를 생성해야 하는 경우가 발생 할 수 있습니다.


그러면 EC2 인스턴스로부터 AMI를 생성하는 것과 Snapshot으로부터 AMI를 생성하는 경우 무엇이 다를까요?


EC2 인스턴스로부터 AMI를 생성하는 경우 위에서 이미 설명했지만, Snapshot으로부터 AMI를 생성하는 경우 지정된 Snapshot이 Root디바이스로(Volume)(만) 지정된다는 겁니다.


즉, EC2 인스턴스로부터 AMI를 생성하는 경우 이미 현재 EC2 인스턴스가 사용되고있는 디스크들을 찾아서 AMI로 만들것을 추천하지만 Snapshot으로부터 AMI를 생성하는 경우 그렇게까지는 해주지 않는 다는 차이점이 있습니다.


** Snapshot은 내부적으로 S3로 저장된다고 문서에서 설명하고 있습니다.실제로 블럭디바이스를 사용하지 않는 Volume형태로 남겨 두는 경우 개인 계정을 개설하는 경우 요금이 생각보다 저렴하지 않을수 있으므로 Snapshot형태로 저장하도록 합시다. 본인의 경우 개인계정에서 인프라코드를 통해서 EC2 서버를 계속생성하고 테스트후 삭제하였는데도 불구하고 요금이 엄청나온적이 있습니다. 주된 과금이유는 바로 이러한 Volume을 삭제하지않은채로 놔뒀기 때문이었습니다.

 



Posted by Steven J.S Min

댓글을 달아 주세요

AWS EFS 설정

DevOps 2017.07.28 11:15

EFS는 EBS볼륨과 가장 많이 다른점은 

  • 동일한 Region내(그리고 동일한 VPC네트웍 내에서)   AZ에 상관없이 마운트가 가능합니다.

그리고..

  • Network File System V4(NFSv4)를 지원
  • Petabytes 스케일업

등을 지원합니다.


일단 EFS를 생성하면 생성시 지정된 어베일어빌리티전(AZ)에 저장하고, Mount Target에는 EFS에서 제공된 DNS를 통해 마운트합니다.

이상은 일반적인 메뉴얼에 있는 내용입니다.


실제 프로젝트에서 적용하면서 이슈가 되는 몇가지 내용을 정리해봅니다.




1. Security Group의 적용에 관하여

   보통 일반 메뉴얼은 기본적으로 제공되는 (VPC) Default Security Group을 적용하는것으로 가이드 되어있습니다.

   기본적으로 제공되는 SG는 소스에 자기자신이 지정되어 self-referential로 설정되어있습니다.


  이것은 해당 SG가 적용된 리소스로부터는 어느 Source이든 지정된 트래픽과 프로토콜을 허용하겠다는 것입니다.

  (기본 SG는 All traffics, All Types 으로 되어있습니다.)


  EFS를 운용하다보면 가끔 특별한 제어가 필요할때도 있기때문에 우선 기본SG와 동일한 SG를 적용해서 인스턴스와  EFS에 적용하는것이 좋습니다.



2. EFS 마운트

   서버가 시작되면 그때마다 마운트해서 사용해도 되겠지만 

   /etc/fstab 에 추가 지정하여 자동 마운트 되도록 사용할 수있습니다.


  $> vi /etc/fstab

     

    fs-89f514b0.efs.ap-southeast-2.amazonaws.com:/ /root/share nfs4 nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,_netdev 0 0


  **  fs-89f514b0.efs.ap-southeast-2.amazonaws.com:/ 는 EFS에서 제공도는 DNS입니다.

  ** /root/shar는 마운트되는 디렉토리입니다.

  


3. EFS 언마운트

   $> mount      --> 현재 마운트되어있는 목록을 보여줍니다.

   $> umount fs-89f514b0.efs.ap-southeast-2.amazonaws.com:/





EFS의 개인적인 느낌은 다음과 같은 경우를 제외하면 EFS  보다는 EBS 볼륨을 사용하는 것이 좋을것 같다는 생각을 합니다.


EBS가 유용 한 경우.

- AZ 제약없이 하나이상의 서버가 공유가 필요한 디렉토리가 필요한경우

- 아마존 이외에 기존의 데이터센터에서 Amazon으로의 네트웍드라이브가 필요한 경우






Posted by Steven J.S Min

댓글을 달아 주세요

AWS에서의 Scaling은 처음에 설정해보고 테스트해보면 그 편리성과 예전과는 비교할수 없을만큼 용이함에 모든것이 이해된것 처럼 생각되지만, 막상 프로젝트에서 이를 구현하다보면 기본 개념이 정리되지 않아서 그 문제를 찾기 어려운 경험이 있었습니다. 다시한번 쭉 살펴보면서 몇가지 정리해 보았습니다.



AutoScaling 설정은 보통 다음과 같은 과정을 거치게됩니다.


1. AutoScaling 그룹에서 사용할 템플릿(Configurtion)을 정의

   : 개발 인스턴스 설정하는 것도 거의 동일합니다.

    - 어떤 형태의 인스턴스를 사용할것인지 선택  : 리눅스종류, 스토리지, SecurityGroup, 사용할키페어

    - IAM Role 지정



2. 정의된 템플릿을 이용하여 AutoScaling Group 정의

    - 몇개의 인스턴스부터 시작할것인지

    - Scaling될 AZ들 선택

    - 임계치설정

        - 인스턴스를 어떤 경우에 증가 할 것인지

        - 인스턴스를 어떤 경우에 감소 시킬 것인지


    - 이미 운영중에도 대부분의 임계치 값을 변경시킬수 있습니다.



나의 경우 그 동안 몇가지 개념때문에 트러블슈팅에 애를 먹은 경험이 있는데, 아래 임계치 설정에대한 개념의 좀 부족했던것 같습니다.

Health Check Type :

    EC2 - Amazon EC2에서 제공한 상태 확인 (기본)

    ELB - Elastic Load Balancing에서 제공한 상태 확인



Health Check Grace Period :

AutoScaling을 하는 입장에서는 해당 인스턴스의 상태를 체크해서 리소스를 늘려야할지 줄여야할지 판단해야하는데

이때 언제 이 상태를 체크하느냐가 문제가 될수있습니다.


일단, AutoScaling이 작동하기 위해서는 인스턴스가 InService상태가 될까지는 기다려야 합니다.

Health Check Grace는 ELB로부터 Health Check를 받고 얼마만큼 기다려야하는가와 관련이 있습니다.

보통은 그래서 어플리케이션이 구동되는데 3분이 걸리면 최소한 180초(3분)를 잡으라고 되어있지만, 

실상 이것은 ELB에서 Health체크의 임계값에 따라 결정되어야하며

    

Healthy인지 Unhealthy인지 Threshold값과 Interval 설정을 고려해서 설정해야 하겠습니다.


증상 : 이러한 소요기간보다 Health Check Grace를 적게잡으로 의도하지 않게 서버서비스가 올라올때 이미 서버가 ScaleUp되어있는 현상이 있을수있습니다.




Scaling Cooldowns : 

Health Check Grace Period와 약간 혼동스러운 부분이 있는데, 인스턴스 상태값(Not ELB)을 체크하여 AutoScaling 스케일작업을 결정할때 일반적으로 서버가 시작되도 어플리케이션 구동(예를들어 무거운 WAS서버등)의 준비 시간이 필요하기 때문에 이러한 추가 시간을 설정해주도록 해서 이러한 조정작업을 중지하도록 조치 할수 있습니다.



http://docs.aws.amazon.com/autoscaling/latest/userguide/Cooldown.html

http://docs.aws.amazon.com/autoscaling/latest/userguide/healthcheck.html

    

어떻게보면 AuotoScaling 자체가, 시스템의 성능보다는 신뢰성을 높이는데 촞점이 맞추어져있지만, 고객이나 엔드유저 입장에서는 이러한 임계값간의 Gap으로 인하여 성능에관한 이슈로 발전 될 수도 충분히 있습니다. 이러한 임계값을 최적화 하므로서 이러한 이슈를 최소화 할 수 있다고 봅니다.


요즘 경량화된 컨테이너 사용으로 베이스이미지를 사용하는 경향이 있는데...그리도 서버를 프로젝트에 맞게 프로비저닝하는 시간도 무시할수 없습니다.  완전한 베이스 이미지로부터 프로비저닝하기보다는 프로젝트에 최적화된 기본 베이스를 더 적극 활용하므러서 이러한 Threshold간의 Gap을 줄일수 있는 포인트라 할수 있겠습니다.







Stress Tool 사용

AutoScaling을 설정을 하다보면 설정한 환경이 의도대로 작동하는지 테트해 봐야겠지요. 

이런 경우 간단히 사용할수 있는 stress 사용을 정리해보았습니다.

(이왕이면 htop과 같은 툴도 같이 설치하면  OS레벨에서 실제 변화되는 수지를 확인하면서 AWS가 어떻게 반응하는 확인이 더 수월하겠습니다.)



1개 core CPU에 60초가 부하테스트

$> stress -c 1 -t 60


4개 core CPU에 60초가 부하테스트

이때 예를 들어 코어가 1개라도 4개를 지정하여 실행하면 X4배 만큼 부하를 주게됩니다.(프로세스 4개 생성)

$> stress -c 4 -t 60


256M(메로리를 지정하지 않으면) X 3 를 소비하는 60초간 부하 즉 256M를 소비하는 3개의 프로스가 부하를 주게됩니다.

$> stress -m 3 -t 60


300M X 2를 소비하는 60초간 부하

$> stress -m 2 --vm-bytes 300M -t 60



1G(기본값)의 2개의 프로세스로 Disk 60초간 테스트

$> stress -d 2 -t 60


512M의 2개의 프로세스로 Disk 60초간 테스트

$> stress -d 2 --hdd-bytes 512M -t 60


CPU, Memory 그리고 Disk에 모두 테스

$> stress -c 4 -m 2 -d 1






Posted by Steven J.S Min

댓글을 달아 주세요

Amazon Linux가 아닌 일반 머신에서는 반복적으로 AWS CLI를 설치하게되는데요, 그 과정을 단순히 정리해봅니다. RHEL계열은 아래과정과 대동소이하며, Debian계열의 Linux에서도 거의 비슷합니다.


우선 Python이 설치되어 있다고 가정합니다.



전체적인 과정

  • 먼저 Python 패키지관리자인 PIP을 설치해줘야합니다.
  • Python Packaging Authority에서 제공하는 스크립트를 사용하여 pip를 설치한 다음 AWS CLI를 설치합니다.


wget이나 curl을 이용해서설치스크립을 다운로드.

$> curl -O https://bootstrap.pypa.io/get-pip.py


Python으로 다운로드 받은 파일을 실행합니다.

$> python get-pip.py --user


설치된 패키지를 영구히 등록하려면 "./.local/bin"를 PATH에 추가 등록합니다.

$> export PATH=$PATH:./.local/bin


pip이 정상적으로 설치되었는지 다음과 같이 확인해 봅니다.

$> pip --version


이젠 pip으로 AWS CLI를 설치합니다.

$> pip install awscli --upgrade --user




Posted by Steven J.S Min

댓글을 달아 주세요