AWS 솔루션 아키텍쳐

WhatIsTheTime.com

사람에게 시간을 알려주는 사이트이다. 

하나의 인스턴스가 있고 유저가 그 인스턴스에 들어가면 인스턴스는 단순히 시간을 알려준다.

이 인스턴스가 재시작해도 같은 아이피 주소를 가리키기 위하여 ElasticIP를 생성하여 부착시켜주었다.

이 애플리케익션이 유명세를 탔다.

 

그러면서 기존에 t2.micro스펙으로는 충분하지 않다는 걸 깨달았다. 

그래서 수직 확장을 통해 m5.large유형으로 교체하려고 한다.

인스턴스를 중지 시키고 유형을 바꾸고 다시 인스턴스를 시작했다.

이는 elastic ip를 가지고 있었기에 아이피가 변하지 않아 사람들은 여전히 접속할 수 있었다.

그러나 M5로 업그레이드하는 동안 다운타임이 발생했다. 그 동안 접속할 수 없었기 때문이다.

 

더 많은 사람들이 이 앱을 사용하기 시작했고 우리는 이제 수평확장을 해야할 차례이다.

따라서 추가로 2개의 같은 스펙의 인스턴스를 만들고,  elastic ip또한 추가하였다.

하지만 사람들은 3개의 IP를 정확히 알고 있어야 세개에 다 접근할 수 있다.

 

하지만 추가할 수록 이렇게 별도로 관리하는 것이 힘들어졌다. EIP도 한 계정에서 리전마다 5개밖에 가질 수 없다.

따라서 먼저 각기다른 EIP를 제거한다.  그리고 Route53을 사용하여 도메인을 생성하자. 그럼 이 전까지 유저는 각기 다른 아이피를 외워야 하였지만 이제는 하나의 주소만 외우면 될것이다. 이를통해 상당한 개선을 이루었다. TTL은 한시간으로 설정해두자.

 

이제는 상황에 맞게 인스턴스를 추가하고 제거할 수 있도록 확장하고 싶어졌다.

세개의 인스턴스 중에 하나를 지웠다. 그럼 그 인스턴스와 통신 중이었던 유저들은 어떻게 될까 TTL이 한시간으로 설정되어있어서

한시간 동안은 route53쿼리를 시도하고, 그건 바람직하지 않다. 한시간이나 지나야 접근 가능할 것이다.

 

이럴 때에는 로드밸런서를 추가해보자 이 전까지 우리는 공용인스턴스를 사용했는데 이제는 사설인스턴스를 사용할 것이다.

이건 같은 가용영역에서 실행할 것이다. 로드밸런서는 헬스체크기능이 있어서 한 인스턴스가 다운되거나 작동을 하지 않으면 다른 인스턴스로 트래픽을 전달한다. 

 

이제 루트53에 등록한 레코들을 (A타입으로 3개 만들었지만) 지우소 CNAME으로 하나만 생성하여 로드밸런서의 DNS를 적어주면 된다. 혹은 Alias로 해주면 된다. 그럼 유저들은 기존 도메인을 통해 들어오면 로드밸런서로 들어오고 로드밸런서가 각 인스턴스로 분배해줄것이다. 이제 트래픽도 알아서 잘 배분해 주는데 수동으로 인스턴스를 추가 제거하기도 귀찮아 졌다. 이 때 필요한 것이 오토스캐일링이다.

 

이제 트래픽이 적은 아침에는 1개의 인스턴스 밤에는 3개의 인스턴스가 알아서 생성되고 삭제될 것이다. 이 와중에도 다운타임은 발생하지 않는다. 이제 완벽한 것 같은데 만약 가용영역에 지진이 나면 어떻할까? 연결이 안될것이다. AWS는 우리에게 다중AZ를 사용하지 않았기 때문이라고 말했다. 가용성을 높이기 위해서 다중AZ를 사용해보자, 다중AZ를 사용하면 로드밸런서는 1 ~ 3까지 영역에 존재하고.

오토스캐일링 그룹 역시 다중 AZ에 걸쳐있다. 1에는 2개의 인스턴스, 2에도 2개의 인스턴스 3에는 1개의 인스턴스 이렇게 있다고 가정해보자. 이 경우 AZ1이 다운 되더라고 AZ2와 AZ3이 있기 때문에 사용자를 위한 트래픽을 처리할 수 있다. 가용성을 확보하여 장애발생에도 대비가 되었다. 근데 우리는 아까전에 3개의 인스턴스와 한개의 ELB가 있었지만 지금은 3개의 ELB 5개의 인스턴스가 있다. 물론 가용성이 높아져 한층 안전해졌지만 비용적인 측면이 부담이 될 것이다.  오토스캐일링의 폴리시를 통해서 이 부분을 좀더 유연하게 변경할 수 있을 거같다. 비용절감을 위해서 인스턴스를 예약하는 방법도 있다. 2개는 무조건 사용할 거라면 2개를 예약해서 사용하면 더 절약할 수 있다.

 

 

 

MyClothes.com

상태 유지 웹이다. 

위의 내용앱에서 추가해보자

먼저 사용자가 있고 루트 53 다중 AZ ELB가 있으며, 오토스캐일링 그룹과 세개의 AZ가 기본적으로 있다고 가정하다.

사용자는 도메인주소를 적으면 루트 53이 로드밸런서의 주소를 알려주면서 거기로 이동하게 되고 로드밸런서는 적절한 인스턴스에 불배시켜줄 것이다. 여기 장바구니에 물건을 담아두었다. 그리고 다시 접속을 하면 이 전에 접속했던 인스턴스가 아니라 다른 인스턴스에 접속을 시켜줄 것이다. 그럼 장바구니가 사라져있을 것이다. 이상하다고 느끼지만 다시 상품을 장바구니에 넣고 또 다시 접속을하면 또다른 인스턴스에 접속을 시켜줄 것이다. 그럼 또 장바구니가 사라져 있을 것이다. 이걸 Stickness를 사용하면 해결할 수 있다. 이건 로드밸런스의 기능이고. 이걸 사용하면 유저는 첫번째 인스턴스에 접속하면 그 다음에 접속할 때에도 첫번째 인스턴스로 이동을 하게 된다.

잘 동작하는데 만약 인스턴스가 어떤 이유로든 종료되면 장바구니를 잃어버리게 된다. 하지만 stickness덕에 조금이나마 개선이된것은 사실이다. 이번엔 사용자 쿠키에 대해서 알아보자 기본적으로 인스턴스가 장바구니 내용을 저장하는 대신 사용자쪽에서 장바구니 내용을 저장하도록 하는 것이다. 로드밸런서에 접속할 때마다 내 장바구니에는 이런것들이 있어 라고 얘기하는 것이다.

웹 쿠키를 이용하면 이렇게 할 수 있다. 이제 각각의 인스턴스가 이전에 있었던 일을 알 필요가 없는 무상태를 달성했다. 하지만 http요청이 무거워 지는 문제점이 있다. 그리고 쿠키를 변조시켜 보안적인 측면에서도 위험해질 수도 있다.

ec2가 반드시 쿠키의 내용을 검증해야 한다. 쿠키도 크기가 작아서 많은 양을 담기에는 한계가 있기도 하다.

서버세션의 개념을 도입해보자, 전체 장바구니를 웹 쿠키로 보내는 대신에 단순히 세션 ID만 보내는 것이다.

이걸 받으면 백그라운드에서는 elastic cache클러스터가 존재한다. 유저는 장바구니에 담고싶은 것을 인스턴스에게 전달해주면 인스턴스는 elastic cache에 그 정보를 담고 그 내용을 불러올 수 있는 ID를 주는데 이게 세션 ID이다.

그 다음 다시 유저가 접속하면 다른 인스턴스에 접속을 할 것이고, (stickness를 뺀 상태 )그 인스턴스는 사용자가 보낸 세션아이디를 사용하여 elastic cache에서 그 아이디에 해당하는 내용을 불러올 수 있을 것이다. 

세션 데이터 저장의 또 다른 방식으로 dynamoDB라는 것이 있다.  이제 공격자들은 쿠키의 내용을 변경할 수 없어서 더 훨씬 안전해지고 빨라지게 됐다. 이제 사용자의 정보를 데이터베이스에 저장하려고 한다. 이번에는 ec2와 rds인스턴스를 통신시킬 것이다.

정보를 저장하고 불러오는 것이 이제 가능해졌다. 각각의 인스턴스 모두가 RDS와 통신을 할 수 있다. 사용자가 점점 많아지면서 하나의 RDS로는 무리가 있다고 판단했다. 읽기 전용 복제본을 사용함으로써 이 부분을 해결할 수 있다. 즉 뭔가를 읽을 때는 읽기 전용 복제본으로 부터 읽고 쓸 때는 마스터RDS로 쓰는 것이다. RDS에는 5개의 레플리카를 가질 수 있다.

 

다른 하나의 방법도 있다. 먼저 유저가 인스턴스에 들어오고 인스턴스가 elastic cache에게 이런 정보를 가지고 있나요? 라고 물어볼 수 있다. 가지고 있지 않은 경우에는 RDS로 부터 읽어들이고 그 내용을 elastic cache에 저장한다. 즉 이 정보가 캐싱되는 것이다. 다른 사용자가 접근한 경우 그 정보를 가지고 있다면 RDS에서 불러오지 않고 elastic cache에서 바로 불러올 수 있으니(cash hit) RDS트래픽을 줄일 수 있다. 

 

이제는 재해에 대비할 차례이다. 우리는 이를 대비하기 위해서  다중AZ ELB를 사용했다. 오토 스케일링 그룹도 다중 AZ였다.

그리고 RDS또한 다중 AZ기능이 있다. 레디스를 사용한다면 elastic cache도 다중 AZ로 사용할 수 있다고 한다.

 

보안그룹을 신중히 정해야하는데, ELB의 경우에는 모든 유저가 다 들어올 수 있도록 하여 http/https 의 모든 아이피를 열어 놓아야한다.

하지만 인스턴스는 로드밸런스의 보안그룹만 허용하여 로드밸런서로 부터 들어오는 트래픽만 허용하고 RDS나 Elastic cache역시 인스턴스의 보안그룹만 허용하여 인스턴스로부터의 트래픽만 허용하도록 해야한다. 

 

MyWordPress.com

위에서 했던 내용을 한번 더 이용해보자. 좀 더 크게 확장시키고 싶다면 RDS를 오로라 Mysql로 교체할 것이다. 다중 AZ, 읽기 전용 복제본, 글로벌 데이터베이스까지 적용할 수 있다. 연산을 줄일 수 있다.

이미지를 저장하고 싶다고 가정하고, 하나의 인스턴스의 기본적으로 붙어있는 EBS가 있다고 가정해보자.

이 EC2는 로드밸런서에 연결이 되어있고, 사용자는 로드 밸런서로 이미지를 보내고 싶다. 이미지는 EBS에 저장된다. 

그리고 EBS로 부터 다시 불러올 수도 있다. 근데 이게 하나의 인스턴스면 문제가 없는데 두개의 인스턴스가 각각 다른 가용영역에 존재한다고 가정해보자. 그리고 각각의 EC2인스턴스는 각각의 EBS볼륨을 가지고 있을 것이다. 만약 첫번째 인스턴스에 이미지를 저장했는데 두번째 인스턴스로 접속한 경우에는 이미지를 불러올 수 없는 상황이 발생할 것이다.  같은 EBS가 아니기에 당연하다.

 

이를 해결하기 위해 EFS를 사용할 수도 있다. EFS를 각 인스턴스에 사용하기 위해서 각각의 AZ에 ENI를 생성한다.

이 ENI는 EFS드라이브에 접근하는 모든 EC2에서(여러 인스턴스도 상관 없음) 사용할 수 있다. 이렇게 ENI와 EFS를 묶으면 스토리지가 모든 인스턴스에게 공유된다는 점이다. 다른 가용영역에 있더라도 말이다. 

 

 

애플리케이션을 빨리 설치하는 방법 

 

golden ami

EC2 인스턴스에서 Golden AMI를 사용할 수 있다. 애플리케이션과 OS등을 사전에 설치하고 그것으로부터 AMI를 생성하는 것이다.

이렇게 하면 애플리케이션, OS 종속성 등을 재설치할 필요거 없다. 모든 것이 이미 설치된 상태에서 바로 실행시킬 수 있다. 

 

bootstrap using user data : 스크립트를 미리 작성하여 실행 되자마자 자동으로 명령어를 실행시킬 수 있다. 처음 시동될때 단 한번만 한다. 근데 이건 좀 느리다. 하지만 이것저것 정보를 가져올 때 편하게 할 수 있을 것이다.

 

Hydirx :  Golden AMI and User Data -> Elastic Beanstalk

 

RDS data base,

EBS volumes 스냅샷으로 부터 복구하여 이미 포맷된 형식을 가지고 있거나 스키마와 데이터를 가지고 있어 훨씬 빠르고 편리하게 생성할 수 있다. 

 

 

Elastic Beanstalk