다시 블로그를 시작하며 쓰는 첫 기술포스팅을 무엇으로 할까 하다가
스터디에 공유해야지 하며 생각만 하던 ec2 instance 와 ami 에 대해 적어봅니다.
본 글은 서버에 대한 개념이 이해되어있다는 가정아래에 작성합니다.
ec2 인스턴스란 AWS 에서 제공해주는 클라우드 서버 자원입니다.
ec2 는 AWS 클라우드 서비스를 이용하면서 가장 먼저 접하게 되는 서비스입니다.
serverless 등이나 RDS만 사용한다던가, CDN 등을 사용하기 위해 접했다면 ec2는 사용하지 않을 서비스긴 하지만,
클라우드 서비스를 이용하는 가장 많은 이유가 아마 클라우드 서버 자원을 이용하기 위함이 아닐까 싶네요.
AWS 콘솔에 로그인을 하면 컴퓨팅 카테고리 아래 ec2 서비스를 접속할 수 있는데요,
이때 나오는 화면은 EC2 대시보드 입니다. 그리고 좌측 메뉴에는 여러 항목들이 나열되어있는데
인스턴스 라는 항목이 눈에 뜨입니다. 이 인스턴스가 바로 ec2 인스턴스입니다.
인스턴스 항목에 들어가서 인스턴스 시작을 누르게 되면 상단에 인스턴스 생성 단계가 나열됩니다.
해당 항목들을 그럼 하나씩 얘기해볼게요.
1. AMI 선택
제목에서 언급했던 AMI는 인스턴스 시작버튼을 누름과 동시에 등장합니다.
AMI란 서버구성에 필요한 소프트웨어와 스크립트 등을 미리 설치하고 설정한 템플릿같은 것입니다.
이 템플릿이 필요한 이유는 같은 환경의 서버를 여러대를 두어야 할 때에 반복적인 환경을 매번 설정하지 않기 위함입니다.
위 내용을 숙지하고 AMI 선택하는 화면을 보면 어떤 AMI 를 선택할지 도움이 될듯 하네요.
해당 화면에 접근하면 좌측에
a. 빠른 시작
AWS에서 기본으로 제공하는 AMI로 보통 타 프로젝트에 의존이 없는 AMI
b. 나의 AMI
콘솔을 사용하고 있는 사용자가 미리 만들고 관리하는 AMI,
처음 AWS콘솔을 접하면 없으며 빠른 시작등을 통해 ec2 인스턴스를 만들고 해당 인스턴스를 AMI 로 생성할 수 있습니다.
누군가가 제공하는 AMI로 무료, 혹은 유료 등이 있으며 보통 기업체에서 제공하는 경우가 다수인 것 같네요.
공식문서를 링크해두었습니다.
d. 커뮤니티 AMI
a를 포함한 커뮤니티에서 내놓은 AMI
위와 같은 메뉴들이 있습니다. 기선택되어있는 빠른 시작의 AMI 들을 보면 여러 OS와 환경을 미리 구축해놓은 여러 AMI들을 볼 수 있습니다. 적절한 환경의 AMI를 선택하면 됩니다.
* 위 a,b,c,d는 주관적인 해석이 있으므로 AWS 공식 문서를 참고 하시는 것을 추천드리며, 대개 일반적인 빠른 시작을 통해 시작할 것이라 예상합니다.
2. 인스턴스 유형 선택
1을 통해 어떤 소프트웨어와 설정값들을 구축한 서버가 선택되었다면 이제 실제로 소프트웨어가 구동될 서버의 성능을 선택해주어야 하겠죠? 그 선택이 2. 인스턴스 유형 선택에서 결정됩니다. 여기에서 얼마나 비싼 서버를 사용할지, 혹은 무료 서버를 사용할지 택할 수 있습니다.
어떤 유형의 인스턴스를 선택해야할지는 어떤 서비스를 운영할지에 따라 결정하면 됩니다.
자세한 유형에 대한 이해는 AWS 공식 문서를 참고하시는 것을 추천드립니다.
3. 인스턴스 구성
이제 좀 어려울 수 있는 얘기를 해야겠네요.
어떤 소프트웨어와 설정값들이 설치된 서버를 선택하고 해당 서버가 어떤 성능으로 운영될지 선택하였다면,
이제 해당 서버가 클라우드 환경에서 어떻게 운용되고 어떤 네트웤 환경을 가질지 결정하는 스텝이 인스턴스 구성 스텝입니다.
서술하면서 얘기하기엔 어려우니 아래와 같이 항목을 나열하고 부연설명을 적어볼게요.
a. 인스턴스 개수
설정중인 인스턴스를 몇 대 운용할지에 대한 옵션인데요, 이는 scailing 과 매우 밀접한 연관이 있습니다.
이번 포스팅에서 다루기엔 할 얘기가 꽤 방대하니 이 얘긴 다음에 하도록 해볼게요.
전 인스턴스 개수는 1로 설정하고 이후 해당 인스턴스를 AMI로 생성하고 이를 통해 오토스케일링 그룹을 잡으면서 작업하였는데요,
처음에 미리 오토스케일링 그룹을 잡으면서 시작할 필요가 없고 추후에 작업이 가능하니 쫄지마셔요 :)
b. 구매 옵션
특정 시간에만 운용되고 24시간 운용되지 않는 서버를 선택할 때에 필요한 부분인데 역시 나중에 수정이 가능한 부분입니다.
지금 얘기하기엔 많은 내용이 들어있는데요, 이는 추후 정리해봐야겠네요.
근래에 비용절감을 위해 여러 인스턴스 운용을 스케쥴링방식으로 설정해주었는데 제가 진행하지 않아 사내 환경을 살펴봐야겠어요.
스팟 인스턴스라고 하며 시간 단위로 설정, 자세한 내용은 AWS 공식 문서를 참고하시는 것을 추천드립니다.
c. 네트워크
클라우드 환경에서 제일 중요한 부분인듯 한데요,
아마존에서는 VPC 라는 가상 네트웤 환경을 사용자에게 제공하고 있습니다.
이러한 환경 덕분에 사용자는 마치 자신만의 독자적인 네트웤환경에서 서비스를 활용하고 있는 착각을 하게 됩니다.
처음에 별도 생성이 없다면 기본 값이 제공이 될텐데요, 그냥 기본 값을 사용하여도 무방합니다만,
만약 해당 계정으로 여러 프로젝트를 구성하고 별도의 네트웤으로 서비스를 할 것이라면
새로운 VPC 를 생성하는 것을 추천드립니다.
VPC 는 단순 ec2 인스턴스간의 네트웤만 얘기하는 것이 아니라 AWS의 모든 서비스들간의 네트웤 환경을 구성하는데 사용됩니다.
따라서 해당 계정으로 독립적인 서비스를 여럿 운용할 것이라면 각 독립적인 서비스 마다 새로운 VPC를 할당할 것을 추천드립니다.
위를 예로 들어보자면,
게임 회사를 운영하는 입장에서, 회사 AWS 계정으로 여러 서비스를 운영하는데
일본 시장을 상대로 야구게임을 만들고 대만 시장을 상대로 격투게임을 만든다는 가정을 하고
야구게임과 격투게임간에 접점은 전혀 없고 서로 독립적으로 서로 다른 팀이 운용한다고 가정을 한다면
vpc-baseball, vpc-action 2개의 vpc 를 만들 수 있습니다.
이 2개의 vpc는 서로 다른 네트워크이며 야구게임의 인스턴스는 격투게임에서 사용중인 AWS 서비스를 사용할 수가 없습니다.
야구게임에서 격투게임이 사용중인 RDS 서비스라던가 Redis 서비스 등을 이용할 수 없습니다.
VPC 를 통해 완전히 독립적인 서버 구성의 환경이 보장이 된다고 할 수 있습니다.
d. 서브넷
운용중인 서비스 중에는 외부에 노출시킬 서비스가 있고, 그렇지 않은 서비스가 있을 수 있습니다.
이를 위해 AWS에서는 퍼블릭, 논퍼블릭 네트웤을 구성하고 지원해주는데 이런 역할을 서브넷이 해줍니다.
여기서 다루기엔 좀 어긋난 내용인데,
이런 서브넷을 이용하여 서비스들에 대해 linux 호스트 접근을 제어해주는 bastion server 라는 것을 운용할 수도 있습니다.
그렇다하여 ec2 인스턴스를 논퍼블릭으로 구성했을때 외부에서의 접근이 막히는 것이 아닌가라는 생각을 할 수도 있는데요,
http 혹은 https, 혹은 특정 포트들에 대한 ec2 인스턴스 접근들에 대해서는 로드밸런서 설정 등을 통해 접근이 가능합니다.
e. 퍼블릭 IP 자동 할당
이 값은 AWS에서 자동으로 퍼블릭한 IP 를 제공할지를 선택하는 것입니다.
자동으로 퍼블릭한 IP 를 제공할 것이라 한다면 위의 서브넷도 그에 맞게 설정해주어야 가능하며,
만약 해당 옵션을 자동 할당으로 설정한다면 AWS에서 자동으로 퍼블릭 IP 를 할당해주고 DNS 주소도 제공해줍니다.
다만 이렇게 설정한다면 ec2 인스턴스가 종료되었다가 재시작 할 적 마다 새로운 DNS 주소가 할당될 수 있습니다.
간단히 토이 프로젝트를 만들고 버릴 인스턴스라면 상관없겠으나 그렇지 않다면 위험한 설정입니다.
그래서 AWS 에서는 EIP 라는 것을 제공하고 있으니 AWS 공식 문서를 참고하시는 것을 추천드립니다.
f. 배치 그룹
AWS 에서는 배치성 성격을 가진 로직을 처리하기 위한 배치서비스를 제공합니다.
여기서 다룰 내용은 아닌 것 같으니 AWS 공식 문서 링크정도로 하고 스킵하겠습니다.
참고로 스프링배치를 써보신 분이라면 이해가 더 수월할 것 같습니다.
전 스프링 배치 프로젝트를 빌딩해본 적 없이 만들어놓은것 가져다 쓰기만 해봤는데, 이것이나 그것이나 똑같이 어렵네요..
g. 용량 예약
이해하려고 여러 문서를 살펴보았는데, 쉽지가 않아 AWS 공식 문서 링크로 도망쳐봅니다...
h. IAM 역할
AWS에서는 계정에 대하여 여러 서브계정(?) 들을 만들 수가 있습니다.
그리고 각 계정들에 대해 서비스들에 대하여 제한된 권한을 부여할 수 있죠.
VPC 에서 예를 들었던 야구게임과 액션게임을 또 들어보자면,
iam-baseball, iam-action 두 IAM 계정을 만들 수 있고 각 IAM 계정에 각 게임들에 대한 권한들을 제공할 수 있습니다.
그럼 iam-baseball 계정이 액션게임에 실수할 여지를 줄일 수 있죠.
해당 항목은 따로 IAM 계정을 관리할 경우에 그러한 IAM 계정을 선택할 수 있습니다.
이때엔 linux 접근 키, 혹은 서비스 액세스 키 등이 IAM 에 귀속되니 IAM 설정시 염두에 두어야 합니다.
IAM 은 그 영향의 범위가 광범위 하니 필요시에 AWS 공식 문서 를 참고하시길 바랍니다.
i. 종료 방식
중지 / 종료 등으로 선택할 수 있는 항목으로,
중지는 해당 인스턴스를 중지하여 추후 필요시 다시 인스턴스를 재가동할 때에 선택합니다.
인스턴스 제거가 아니므로, 인스턴스에 남은 로그와 같은 데이터를 살펴볼 수 있습니다.
종료는 해당 인스턴스를 더이상 구동하지 못하도록 인스턴스를 제거함을 뜻합니다.
제거된 인스턴스는 더이상 접근할 수 없으므로 해당 인스턴스에 대한 정보를 더이상 취할 수 없게 됩니다.
* 종료 방지 기능 활성화
인스턴스의 종료는 더이상 해당 인스턴스에 어떤 일이 있었는지 알 수 없으므로 매우 위험한 액션입니다.
그런데 운영중에 사람의 실수로 인스턴스를 종료할 수도 있습니다.
이런 여러 이유로 제공되는 옵션입니다.
j. 모니터링
AWS에서는 거의 모든 서비스들에 대한 모니터링을 제공해주며 이 모니터링 서비스는 CloudWatch 를 통해 제공됩니다.
k. 테넌시
AWS는 클라우드 서비스로 하나의 물리자원을 여러 자원이 공유할 수 있습니다.
그런데 이 테넌시 항목을 설정한다면 물리적으로도 단일 인스턴스 환경을 구축할 수 있습니다.
해당 내용은 제가 이해가 깊질 못하여 AWS 공식 문서 를 핑계삼아봅니다..
l. Elastic Inference
GPU 기반의 컴퓨팅 성능이 일시적으로 필요한 경우?
이 Amazon Elastic Inference 서비스는 2018.11.13 에 런칭한 서비스 같은데 일반적인 api 서비스 보다는
시뮬레이션 서버 등에 필요해보이는데, 제가 아직 그 분야에 대해 이해도가 부족하여 공식 문서를 봐도 어렵네요.
이 부분은 위의 테넌시처럼 핑계삼아 피해봅니다.. 테넌시 도 그렇고 경험의 부족인지 이해가 잘 가질 못하네요.
m. T2/T3 무제한
이번에 정리하면서 새롭게 보게 된 서비스들이 많은데 이 항목이 가장 눈에 띄는 새로운 업데이트 같네요.
서비스할 때에 특정 시간에 요청이 몰리는 경우가 다반사입니다.
보통 주기적으로 이런 경향이 나타나는데 때론 갑작스레 요청이 몰리는 경우도 있죠.
이런 경우를 위해 보통 오토스케일링을 염두에 두고 설계를 합니다.
그에 따라 서비스 운영중에 늘 염두에 두어야 하는 관리 포인트들도 폭넓어지게 되죠.
여기에서는 ec2와 db의 오토스케일링의 상황과 성격이 다르기때문에 깊게 다루진 않겠지만 잠시 다른 서비스를 언급하자면
Database 는 그 특성상 오토스케일링이 불가하여 스케일업, 즉 더 좋은 성능의 장비로 교체하는 수 밖에 없습니다.
그래서 이런 상황을 막아보고자 샤딩 이라는 기법을 사용하는데 이 경우
트랜잭션 관리라던가, 코드의 복잡도 등이 올라가고 운영 역시도 꽤 번거롭게 됩니다.
이를 피하고자 AWS 에서는 오토스케일링을 지원해주는 mysql 기반으로 설계된 오로라 라는 database 를 서비스합니다.
이렇게 AWS 에서는 클라우드 서비스가 필요할 때에 바로 사용가능한 자원들을 쓸 수 있다는 장점을 잘 서포트해주는데요,
이 T2/T3 무제한 업데이트는 그간 사용자들이 직접 오토스케일링을 설계하던 피로를 제법 막아주는 것 같네요.
잠시 언급한다는게 너무 길게 얘기했네요,
해당 내용은 더 깊게 살펴봐야겠지만,
핵심은 T2/T3 인스턴스들에 대해 서비스를 제공하던 중 갑작스레 트래픽이 몰리더라도
평균적인 성능을 유지하게끔 지원되는 것으로 이해가 되네요.
추가로 크레딧이란 개념을 사용하며 서비스를 이용해본 적이 없어 관련하여 제목에 링크를 걸어둡니다.
* 고급 세부 정보 - 사용자 데이터
다양하게 사용될 수 있는 데이터이고 필요할 때에 작성합니다.
제가 근무하는 곳에서는 EFS 라는 가상 스토리지 서비스를 이용하기 위해 이곳에 필요한 정보를 기입해두었습니다.
* ec2의 오토스케일링의 핵심은 컴퓨팅 성능과 네트웤 처리량, Database 등과의 IO 등을 분산처리하는데에 있으나,
Database 의 핵심은 data를 담은 table 의 row 수에 집중해야 하겠습니다.
(row 수는 query에 영향을 주며 이는 database 의 성능에 치명적인 영향을 줍니다.)
4. 스토리지 추가
드디어 인스턴스 구성에 대한 내용 다음의 내용으로, 서버의 디스크 용량과 성능을 미리 설정하기 위한 옵션입니다.
5. 태그 추가
인스턴스에 태그를 걸어둠으로써 검색시에 도움을 얻기 위함이 있기도 하며,
태그를 걸어두면 code deploy 등에서 태그를 검색하여 특정 인스턴스들에 한하여 배포하는데 이점이 있을 수 있습니다.
외에도 api 를 활용하여 특정 인스턴스들에 대해 모니터링을 한다던가 하는 데에도 도움이 됩니다.
6. 보안 그룹
보안 그룹은 해당 인스턴스의 접근을 제어하기 위해 이해가 꼭 필요합니다. (방화벽과 같은 역할을 합니다.)
보안 그룹은 하나 이상을 설정해줄 수 있으며, 이 보안 그룹은 앞서 설정한 VPC 내에 포함되거나(새로 만들 경우) 포함되어 있어야 합니다.
보안 그룹에서 설정된 인바운드와 아웃바운드 규칙에 따라 외부에서의 접근 여부 등이 결정됩니다.
자세하게 얘기하기엔 보안 그룹은 너무 다양한 얘기를 해야하므로 AWS 공식 문서 를 우선 링크해둡니다.
7. 검토
1번 항목부터 6번 항목까지의 설정한 정보들을 다시 살펴보는 탭입니다.
7번까지 진행하여 시작하기 버튼을 누르게 되면 키 페어 선택, 생성 등이 나오게 되는데
이 키페어를 없이 시작한다면 어디서든 SSH 로 접근할 수 있는 서버가 열리게 됩니다.
따라서 키 페어를 생성해주어야 하는데 해당 키 페어는 반드시 어디엔가 저장하고 기억해두어야 합니다.
해당 키를 통해 인스턴스 접근이 가능합니다.
키를 생성하고 접근 할 때에 대해서는 AWS 공식 문서에 자세히 기술되어있으니 참고하시기 바랍니다.
블로그를 다시 시작하고 첫 포스팅인데 이해를 도와드리기 위해 적은 글속에 모르던 것도 새로이 알게 되었고 제가 많은 도움이 되었네요!
일주일만에 끝맺는 이 글을 통해 많은 분들께 도움이 되길 바라고,
저 또한 깜빡할 때엔 종종 페이지를 열어봐야겠어요.
금요일 오후 5시,
황금주말을 맞이 하기 위한 시간이 다가오네요.
즐주!!