이 중에는 가장 기본이 되어 다른 서비스들의 인프라와 같이 가장 폭넓게 역할을 하는 서비스도 있고,
특정 상황에서 편리하고 저렴하게 사용할 수 있는 특수화 된 서비스도 있다.
AWS의 주요 서비스에 대해서 정리해보자면 아래와 같다.
1. AWS의 주요 서비스
1) 컴퓨팅 서비스
- Amazon EC2(Elastic Compute Cloud): 가상화 서버. 다양한 형태의 타입과 서비스에 따라 적합한 사양을 선택할 수 있으며, 사용량만큼 비용을 지불하는 컴퓨팅 서버.
- Amazon Auto Scaling: 서버의 특정 조건(서버 사용량이 많은 경우 추가로 생성하고, 사용하지 않는 경우 서버를 자동으로 삭제)에 따라 서버를 추가/삭제 할 수 있게 해주는 서비스
등
2) 네트워킹 서비스
- Amazon Route 53: 가용성과 확장성이 우수한 클라우드 기반의 Domain Name System 웹서비스로, 사용자의 요청을 AWS에서 실행되는 다양한 인프라에 효과적으로 연결할 수 있다. 외부 인프라와도 연결 가능.
- Amazon ELB(Elastic Load Balancer): 웹 서버 및 각종 서버에 사용량과 접속자가 많은 경우 트래픽에 대한 부하 분산을 통해 네트워크 트래픽을 인스턴스로 전달한다.
3) 스토리지 서비스
- Amazon S3(Simple Storage Service): 데이터 보관에서 정적 웹사이트 호스팅 까지 다양한 형태의 서비스로 활용가능한 스토리지 서비스
- Amazon EBS(Elastic Block Storage): 빠른 속도로 데이터를 저장, 보관할 수 있는 서비스로 주로 서버에서 디스크로 추가하여 데이터를 보관,제공 할 수 있다.
4) 데이터베이스 서비스
- Amazon RDS(Relational Database Services): 관계형 데이터베이스 서비스인 MySQL, Oracle등 RDBMS서비스를 사용자가 직접 관리하지 않고, Amazon에서 제공하는 서비스를 이용하여 데이터베이스를 이용할 수 있도록 해준다.
처음 배포를 배웠을 때, EC2, S3, RDS를 배웠는데 그 때는 웹 사이트 배포 하면 서버 코드는 그냥 EC2로 실행시키면 되고, 클라이언트 코드는 S3에 업로드 하면 되고, 데이터베이스는 RDS인 것이 끝이고, 이게 다 인 줄 알았다. 그런데 정말 새 발의 피였다..
이제 와서야 배포를 제대로 해 보려고 하니
정말 많은 AWS서비스 중 내 서비스의 성격과 나의 (경제적)자원등을 고려하여 어떤 AWS 서비스를 고르고, 얼만큼의 사양을 선택해야할지가 서비스 '기획'수준으로 '디자인'되어야 하는게 아닌가
라는 생각이 든다.
'목적에 따라 알맞는 AWS 서비스를 사용하는 것' 이 매우 중요할 것 같다.
먼저 Server side의 AWS 인프라 구축을 해보고자 한다.
우선 서버가 필요하다. 운영 서버가 어떻게 구성되어 있는지 알아보자.
2. 운영 서버 아키텍처의 이해
1) 단일 서버
장점)
가장 기본적인 구성으로 웹 브라우저인 클라이언트와 서버 내에서 애플리케이션 코드와 데이터베이스가 실행되고 있다.
이렇게 애플리케이션과 데이터베이스가 같은 서버 내에서 실행되고 있기 때문에 별도의 네트워크 설정을 하지 않고 그냥 로컬호스트를 대상으로 연결되어 있으면 된다.
단점)
1. 애플리케이션과 데이터베이스가 같은 자원을 공유하고 있기 때문에 서버 문제가 생기면 둘 다 죽어버린다.
2. 애플리케이션과 데이터베이스은 각 속성에 따라 더 중요한 자원의 종류나 최적화를 위해 필요한 OS설정 등이 다를 수 있는데 이를 같이 이 사용하려면 자원의 사용이 매우 비효율적이게 된다.
3. 데이터베이스는 보안상 포트나 IP 등 접속 지점을 최소화 하는 것이 좋다. 그러나 위와 같은 경우 애플리케이션으로 요청이 오는 다양한 주소와 포트에 대해 다 열려있어야한다는 점에서 보안상 좋지 않다.
4. 서버 확장(Scale out)이 힘들다. 서버를 여러대로 늘려야 하는 상황이 오면 데이터도 그만큼 복제되어야 한다. 그리고 클라이언트가 그 모든 서버와 연결이 다 되어있어야 한다.
2) 애플리케이션과 데이터베이스 서버 분리
장점)
이렇게 구성하게 되면 위의 단일 서버의 단점 중 1~3번이 해결된다.
단점)
4번의 경우 클라이언트가 여전히 하나의 서버와 연결되어있으므로 이 문제는 여전히 존재한다. 또한 두 대의 서버를 관리해야하며, 어쨌든 서버 간 통신이란게 생겨서 지연 시간이나 네트워크 보안을 추가로 고려해야 한다.
3) 서버 단위의 로드 밸런서
클라이언트가 애플리케이션을 실행하는 서버와 직접 통신하는 대신 로드밸런서라는 서버와 통신하고, 그 뒤에 여러 대의 애플리케이션 서버를 두는 방식이다.
장점)
1. 클라이언트는 로드 밸런서 하고만 통신하고 로드 밸런서가 클라이언트에게서 받은 요청을 뒤에 있는 서버들에게 전달한다.
그리고 뒤에 있는 서버들이 요청을 처리 후 로드 밸런서를 통해 클라이언트에 전달한다.
그렇기 때문에 위에서 살펴본 클라이언트가 여전히 하나의 서버와 연결되어 있어서 발생하는 문제가 사라지고,서버의 Scale out이 가능해진다.
2. 일부 서버에 장애가 발생해도 로드 밸런서가 정상 서버에 요청을 전달하면 되기 때문에 대응이 가능하다.
단점)
모든 요청과 응답이 로드 밸런서를 통해 전달되기 때문에 로드 밸런서에 이상이 생기면 전체 서비스에 장애가 발생할 수도 있다.
1. EC2 배포 및 inbound 설정 2. ACM 에서 SSL 인증서 발급 3. ELB 생성 및 리스너 세팅 4. Route 53에서 레코드 생성 후 ELB 연결 5. EC2에 nginx 설치 및 세팅
으로 진행 될 것이다.
이를 위해 먼저 첫번째 단계인 EC2 배포 및 inbound 설정을 위해 Amazon EC2(Elastic Compute Cloud)를 이용하여 가상화 서버(Instance)를 생성해보자.
3. AWS EC2 가상화 서버(Instance) 생성
1. AWS에 로그인 후 네트워크 속도를 고려하여 region을 알맞게 설정한다. 나는 서울로 할 것이기 때문에 서울로 region이 되어있는지 확인 후 EC2에 들어간다.
2. 오른쪽 메뉴바에 '인스턴스'라는 걸 클릭하면 인스턴스 시작버튼이 보이고 이제 본격적으로 가상화 서버(Instance)를 생성할 수 있다.
3. 인스턴스 시작을 누르면 서버 OS와 환경이 설치된 AMI(Amazon Machine Image) 리스트가 보인다.
AMI(Amazon Machine Image)란 생성할 EC2 인스턴스의 기반이 되는 이미지이다. 저번에 연구실에 Linux OS를 설치할 때 설치 USB가 있었는데 그 안의 내용과 비슷한게 아닐까..라고 이해하고 있다. 이 이미지를 통해 EC2인스턴스에 원하는 운영체제, 환경이 구성된 서버를 설치 할 수 있다. 또한 내가 원하는 환경을 구성 한 뒤 이미지로 만들어서 재사용할 수도 있다.
여기서 '프리티어 사용가능'이라고 되어있는 것을 선택하였다.
4. 성능과 다양한 사양이 있는 서버를 선택할 수 있는 인스턴스 유형 선택이다. 여기서도 마찬가지로 프리티어 사용 가능을 골랐다.
5. 3. 인스턴스 구성, 4. 스토리지 추가는 기본값으로 하고 다음으로 넘어가고, 5. 태그 추가에서는 인스턴스를 구분할 수 있는 태그를 생성할 수 있다.
6. 보안 그룹 구성은 인스턴스의 접근을 제어하기 위한 보안 그룹 구성으로 일단 새 보안 그룹을 생성하고 검토를 끝으로 인스턴스 생성은 일단 마친다. 뒤에서 보안 그룹 편집을 할 수 있다.
보안 그룹 구성 아래에 적힌 내용을 잘 읽어보면 '보안 그룹은 인스턴스에 대한 트래픽을 제어하는 '방화벽 규칙' 세트. 특정 트래픽을 인스턴스에 도달하도록 허용할 규칙을 추가 가능' 이라고 되어 있다. '방화벽'은 인터넷과 같이 외부 네트워크에 연결되어 있는 내부 네트워크에 대해 외부로부터 불법적인 침입을 보호학 위해 시스템을 말한다. 외부 시스템이 내부 서버및 자원에 접근하기 위해서는 방화벽을 거쳐야한다. 즉 '보안 그룹'은 보안을 위해 방화벽에 허용하가나 금지할 IP와 포트번호를 정의해두는 서버 접속 규칙이다.
7. 키 페어 생성
새 키페어 생성 후 키 펭어 이름을 넣는다. 다운로드된 키페어는 만든 인스턴스에 접속 할 수 있는 비밀번호와도 같은 것이기 때문에 잘 보관해야하고 보안에 특히 주의하여야 한다!(또한 한번 다운받으면 다시는 못받음!!)
매번 키페어를 보관하고 찾는걸 잊어버려서 팀원분들게 많이 여쭤보곤했는데 HJ님 블로그에 방법이 정말 쉽고도 명확하게 나와있어서 가져와보았다! 출처: http://hazel-developer.tistory.com/120
여기까지 하고 조금 기다리면 인스턴스의 상태가 running이 된다!
4. AWS EC2 가상화 서버(Instance) 접속
위의 사진에 인스턴스 시작 옆의 '연결'버튼을 누르면 선택한 인스턴스에 연결을 진행 할 수 있다.
<독립 실행형 SSH 클라이언트> 방식으로 인스턴스에 연결해보자.
인스턴스 엑세스 방법이 순서대로 잘 나와있다. 위의 키페어가 보관된 .ssh/로 이동해서 제공된 명령어를 그대로 입력하면 된다!
이제
$ sudo apt update
하고 웹 서버인 Nginx를 설치하면 동시에 실행되므로 퍼블릭 Ipv4주소로 들어가본다.
위의 그림에 보면 EC2 안에 Nginx라는게 있다. 이게 웹 서버 제품중 하나이다. 서버 인스턴스에는 클라이언트의 요청을 받아 요청 처리, 응답을 도와주는 서버 소프트웨어가 필요하고, 이 서버 소프트웨어는 크게 웹 서버와 웹 애플리케이션으로 구성된다. 이에 대해서는 다음에 웹 서버 Nginx 적용 포스트에서 자세히 정리해보고자 한다.
그런데 접속이 안될 것이다 왜일까?
방화벽 때문! 이제 앞서 말한 보안 그룹 편집을 해주어야 할 때다.
인바운드 규칙은 외부에서 인스턴스로 접근할 때의 규칙을 말하고, 아웃바운드 규칙은 EC2인스턴스에서 바깥쪽으로 접속할때의 규칙이다.
그래서 인바운드 규칙은 최소한으로 열려있어야 보안적으로 안전 하다.
그 중 22번 포트는 SSH라는 통신을 위한 방법이라서 기본적으로 열려있으며
HTTP 웹을 사용하기 위해선 80번 포트도 열려있어야 한다.
+ 후에 적용할 것이지만 HTTPS 도 사용할 것이기 때문에 443번 포트도 열려있게 추가해줄 것이다.
누구나 접속 가능하도록 소스는 0.0.0.0/0, ::/0
5. 프로젝트 실행을 위한 서버 환경 구성
첫 번째 프로젝트로 진행한 SAFU 애플리케이션은 Node.js로 만들어졌기 때문에 Node.js, NPM를 설치한다.
그리고 Git으로 EC2 인스턴스에 코드를 배포할 수 있다.
서버에 접속 한 뒤 Git저장소에 있는 소스코드를 그대로 EC2 인스턴스로 git clone하여(이후 부터는 git pull) 코드 실행에 필요한 의존성 패키지를 npm install로 설치 하면 된다.
