[AWS] 정리

EC2

아마존 웹서비스 중에 가장 먼저 생겨났고, 가장 범용적인 서비스입니다.

해당 상품은 독립된 컴퓨터 한 대를 통째로 임대해주는 서비스입니다.

여기서 존재하는 ‘인스턴스’ 는 컴퓨터 한 대 단위를 의미합니다.

 

대상 리눅스를 원격제어 하기 위해 쓰는 프로그램 : ssh (Secure shell)

대상 윈도우를 원격제어 하기 위해 쓰는 프로그램 : RDP

 

ftz : 파일 송수신 프로토콜 

 

scaability : 변화하는 수요에 얼마나 탄력적으로 대응할수 있는가. 이를 클라우드 컴퓨팅 기술로 잘 실현할 수 있음.

수요가 늘면 컴퓨터를 빠른 속도로 만들고, 수요가 줄면 컴퓨터를 삭제하면 되기 때문.

 

Elastic IP : aws 로부터, 아이피 주소 하나를 받는 것임. 왜 받냐면, EC2에서 컴퓨터를 켜고끄고 하다보면 아이피 주소가 바뀌게 되는데, 웹서비스의 경우 아이피가 바뀌어버리면 안되므로 변하지 않는 Elastic IP를 하나 받고 이걸 인스턴스에 붙이는것.

 

Scale up : 인스턴스를 이미지화해서 저장시킨 다음에(이미지화 도중에는 인스턴스가 작동하지 않음 주의) 이 이미지를 새로운 성능의 인스턴스로 실행시키는것. 예전 집에 있던 짐을 싸서 새로운 집으로 이사가는 느낌.

Elastic IP를 부여했던 인스턴스가 성능적 한계에 도달했다면, 이 인스턴스를 이미지화 한 뒤에 새로운 성능의 인스턴스에서 이 이미지를 설치하고 이전 인스턴스에 붙여놨던 Elastic IP를 이제 새 인스턴스에다가 붙여주면 사용자 입장에서 아이피 변동 없이 서비스를 그대로 이용할 수 있고, 서비스의 성능은 업그레이드 될 수 있음. 

 

Scale Out : 스케일 아웃이란 단일 컴퓨터들을 여러대 연결시켜서 하나의 컴퓨터로 작동하게끔 하는 작업이다. 스케일은 분산되고 전체 서비스의 성능은 향상시킨다. 예를 들어 스케일 업의 한계에 도달한 경우, 단일 컴퓨터에서 할 수 있는 성능 업은 다 한 격이다. 여기서 더 성능을 좋게 하려면 스케일 아웃을 사용한다. 스케일 업이 가능할 경우에는 굳이 사용하지 않는 것을 추천한다. (스케일 업을 하는 것 보다 더 복잡하고, 관리도 복잡해지므로) 즉, 한 대의 컴퓨터가 제공하던 서비스를 여러 대가 분업하여 제공해주는 것.

 

이런 스케일 아웃 방식을 구현하면서, 사용자에게 제공할 전체 서비스(이를테면 웹서버 - 미들웨어 - 데이터베이스 서비스)를 여러개의 인스턴스를 통해 분업하여 작업하고 필요에 따라 각 작업 단위 서비스(웹서버 or 미들웨어 or 데이터베이스) 까지 여러대의 인스턴스로 분업하기도 하는데,

ex) 

기존 -> 인스턴스 x1 ( 웹서버 - 미들웨어 - 데이터베이스 제공)

아래는 스케일 아웃의 예

A. 웹서버 인스턴스 x1, 미들웨어 인스턴스 x1, 데이터베이스 인스턴스 x1 

B. 웹서버 인스턴스 x2, 미들웨어 인스턴스 x2, 데이터베이스 인스턴스 x2

 

이때 사용자가 서비스로 처음 접속할 주소(여기서는 웹서버)의 인스턴스는 하나여야하는데 서비스를 분업하고자 웹서버 인스턴스를 여러 대로 두게 되면 접속 주소에 대해 사용자에게 난감한 상황이 생긴다. 어디로 접속해야 하는지 혼란이 오게 되는 것이다.

이럴 때 로드 밸런싱이라는 기능을 도입한다. 사용자의 모든 접근을 로드밸런서의 주소로 놓아 담당하게 하고, 그곳에서 사용자에게 접근 주소를 적절히 분배시키는 방식(너는 웹서버 1의 주소로, 너는 웹서버 2의 주소로)이다. 사용자가 최초 접근하는 주소가 일정(=로드밸런서의 주소)하게 되므로 일레스틱 로드 벨런서라고도 부르며, 이 로드 밸런서의 기능은 각 연결된 인스턴스(여기서는 웹서버를 담당하는 인스턴스) 중 다운된 서비스(=웹서버)가 있을 경우 그쪽으로는 사용자를 보내지 않으며 관리해주는 기능까지 한다. ( 과부하가 일어나지 않게 접속을 분산시켜주면서, 연결된 인스턴스 중 하나에 문제가 생길 경우 해당 주소로는 접근을 막아주며 전체 서비스의 원활한 동작을 관리하는 기능. 네트워크의 로드밸런싱과 같은 개념) 이때 정말 주의해야 할 점은, 만약 제공하는 전체 서비스가 사용자로 인해 데이터베이스에 변화를 줄 수 있는 서비스 (글을 쓰는 게시판 같은 서비스. 사용자에 의해 데이터베이스에 변화를 줄 수 있는 서비스)일 경우, 그리고 동시에 여러대의 각 웹서버 인스턴스가 서로 다른 독립된 데이터베이스 인스턴스와 연결되어 있을 경우엔 사용자가 로드밸런서에 의해 웹서버 1에 접근되어 글을 쓰고 다음 접속에 웹서버 2로 접근되었다면, 웹서버 1이 사용하는 데이터베이스와 웹서버 2가 사용하는 데이터베이스가 현재 독립된 각각의 데이터베이스이므로 해당 글이 없는 경우가 생기게 된다. 그러므로 여러 개의 웹서버가 각자 독립된 개별의 데이터베이스 인스턴스를 이용하지 않도록, 즉 하나의 데이터베이스 인스턴스를 사용하게끔 연결하거나 여러 대의 데이터 베이스 인스턴스를 사용하되 서로 연결되어 있도록 해야 하겠다.

 

이러한 로드밸런서는 전체 서비스 제공에 있어서 여러 대의 인스턴스로 부하를 분산하며, 로드밸런서와 연결된 인스턴스 중 하나의 주소가 다운되더라도 다른 살아있는 주소를 통해서만 접근하게 동작하도록 관리해줌으로써 전체 서비스 다운에 대한 보험도 잘 갖춰질 수 있음.

 

헷갈릴 수 있는 점은,

꼭 제공할 전체 서비스(웹서버 - 미들웨어 - 데이터베이스)가 각각의 인스턴스로 스케일 아웃 된 상태에서만 로드밸런싱을 사용할 수 있는 것은 아니고, 전체 서비스가 하나의 인스턴스로 작동하더라도 동일한 기능을 하는 인스턴스를 여러개로 만들어 로드밸랜서에 열결해 로드밸런싱을 사용한다. 결국 제공할 서비스를 여러개의 인스턴스로 분할하는 것은 동일하다. 이것이 스케일 아웃의 개념이기도 하다. 하지만 접속할 주소는 하나여야 하는데 접속을 담당할 인스턴스가 여러대면 안되므로 이때 로드밸런서를 사용하는것이다.

 

아래 예시 모두 ‘스케일 아웃’이다. 

-> 하나의 전체 서비스를 제공하는데 있어서 인스턴스끼리 분업하여 제공. 사용자가 봤을 땐 하나의 아이피 주소로만 연결되지만 그 아이피의 컴퓨터에서 모든 작업을 수행하는 것이 아니라 사용자에게 제공할 서비스를 여러 개의 인스턴스로 분업하는것. 이것이 스케일 아웃. ( 로드밸런서를 사용할 때가 있고 사용하지 않을 때가 있음 )

 

A.

인스턴스 1(웹서버) -  인스턴스 2(미들웨어) - 인스턴스 3(데이터베이스)

 

인스턴스 4(웹서버) - 인스턴스 5(미들웨어) - 인스턴스 6(데이터베이스)

 

-> 인스턴스 1 과 4를 로드밸런서에 연결시켜 서비스를 제공. 이때 인스턴스 3과 6이 각각 독립된 데이터베이스이므로, 인스턴스 1에 접속하여 데이터베이스를 수정하고 인스턴스 4에 접속하여 데이터베이스를 열면 수정 데이터가 없게됌. 따라서 인스턴스 3, 6을 하나로 묶어 사용하는게 좋음.

 

B.

인스턴스 1(웹서버 - 미들웨어 - 데이터베이스)

 

인스턴스 2(웹서버 - 미들웨어 - 데이터베이스)

-> 인스턴스 1과 2를 로드밸런서에 연결시켜 서비스를 제공. 이때도 인스턴스 1과 2가 독립된 데이터베이스이므로 하나로 묶어주는게 좋음.

 

C.

인스턴스 1(웹서버) - 인스턴스 2(미들웨어)/인스턴스 3(미들웨어) - 인스턴스 4(데이터베이스)

-> 해당 경우는 접근 주소가 하나(인스턴스 1)로 동일하므로 로드밸런서를 사용할 필요가 없음.

 

D.

인스턴스 1(웹서버) - 인스턴스 2(미들웨어) - 인스턴스 4(데이터베이스)/인스턴스 5(데이터베이스)

-> 하나의 웹서버를 통해 두개의 데이터베이스를 제어. 당연한 얘기겠지만 두 데이터베이스는 연결관계여야하겠음.

 

 

로드 밸런서에 대한 접속의 한계나 통신의 에러같은 문제를 생각해볼 수 있는데, 아직 아마존이나 네이버 같은 대형회사들도 로드밸런서를 사용하고있고 아직까지도 문제가 있다고 보고된 바가 없으니 걱정하지 않아도 될 문제.

 

오토스케일링 : 수동으로 서비스(서비스를 제공하는 인스턴스들 전부 혹은 인스턴스 하나)를 만들어서 로드밸런스에 붙이는 작업들을 자동으로 해주는 시스템. 

 

오토 스케일링을 더이상 사용하지 않을 경우 Delete를 통해 삭제해주고, 클라우드 와치에 들어가서 오토스케일링을 위한 알람유형도 삭제해줘야 과금이 발생하지 않는다. 그리고 SNS 서비스 카테고리에 들어가서 알람이 발생했을 때 SNS 통보기능( 이메일로 전송 같은 기능)을 했던 부분을 모두 삭제해준다. 엘라스틱 로드 밸런서도 더이상 사용하지 않는 경우 삭제해주는것이 좋다. 

 

Q. 오토 밸런싱을 이용하는게 스케일 업을 하는것보다 낫지 않을까? (필요에 따라 자동으로 인스턴스를 생성 - 제거하면서 부하를 조절해주니까..)

 

S3

파일 송수신 서비스. 파일을 저장하고 보관하고 공유할 수 있는 시스템. Bucket 이라는 디스크 개념의 저장소들 안에 파일들을 넣어 저장.

이 버킷명은 아마존 웹서비스 전체에서 겹치지 않는 유니크한 네임이여야 함.

 

 

 

본 공부 자료는 opentutorials.org 의 생활코딩의 이고잉님께서 제공해주셨습니다. 도움을 주셔서 감사합니다.