118. 솔루션 아키텍처 토론 개요
지금까지 배운 것은 모두 개별적인 기술에 대한 것이었죠. 이제는 그 기술들이 어떻게 서로 맞아 들어가는지 배울 겁니다. 즉 솔루션 아키텍처에 대해 살펴보겠습니다. 개인적으로는 이 부분이 이 강의에서 최고라고 생각해요. 제가 가장 자랑스러워 하는 부분이죠. 이 기술들이 어떻게 서로 맞아 들어가는지 어떻게 협력하여 솔루션 아키텍처가 되는지 다른 곳에서는 볼 수 없을 겁니다.
여러분은 시험을 보러 갈 때 제가 이 섹션에서 설명할 모든 내용을 100% 숙지해야 합니다. 이는 순수한 솔루션 아키텍처에 대한 내용이기 때문이죠
솔루션 아키텍처를 어떻게 구상할지 예시 사례 연구를 살펴보며 전체적으로 반복하여 배우게 될 겁니다.
- WhatIsTheTime.com MyClothes.com, MyWordPress.com
- 애플리케이션을 신속하게 인스턴스화하는 방법 그리고 Beanstalk에 대해 다루겠습니다
전체적으로 자연스럽게 진행되면서 점진적으로 복잡해질 것입니다. 이를 통해 여러분이 EC2, ELB, ASG, EBS, EFS, RDS ElastiCache, Route 53 등을 비교하고 서로 어떻게 조화를 이루는지에 대해 적절한 관점을 갖추기를 바랍니다
119. WhatsTheTime.com
첫 번째 솔루션 아키텍처에 대해 이야기해 봅시다. 이렇게 다양한 주제를 함께 다룬다고 생각하니 정말 흥분되는군요. 그것들이 서로 어떻게 맞아들어가는지 그리고 솔루션스 아키텍트로서 직면하게 될 과제들이 무엇인지 잘 이해하게 될 겁니다.
첫 번째 웹사이트는 WhatIsTheTime.com입니다. WhatIsTheTime.com은 사람들에게 시간을 알려줍니다.
너무 단순하기 때문에 데이터베이스가 필요 없습니다. 각각의 인스턴스와 서버는 시간이 몇 시인지 알고 있습니다.
작은 것부터 시작하죠. 다운타임을 수용할 수 있지만
우리 앱은 전반적으로 점점 더 인기를 얻게 되겠죠 사람들은 전 세계에 걸쳐 시간을 알고 싶어하기 때문에 다운타임을 제거할 수 있도록수직 및 수평적으로 확장할 필요가 있습니다.
이 앱에 대한 솔루션스 아키텍트 여정을 시작합시다.
진행 방법에 대한 많은 것들을 보게 될 겁니다
정말 간단한 것부터 시작하죠
가장 처음부터 시작합시다. 여러분은 솔루션스 아키텍트입니다. 대단한 걸 말씀드리죠
t2.micro 인스턴스와 사용자가 있습니다. 사용자가 시간을 물어봅니다. 오후 5시 30분이라고 답하죠. 됐습니다. 이게 제 앱입니다. 공용 EC2 인스턴스가 있고 무슨 일이 생기면 재시작할 수 있도록 EC2 인스턴스가 고정 IP 주소를 갖도록 하고 싶습니다. 그렇기에 탄력적 IP 주소를 연결할 겁니다. 이것이 첫 번째 PoC입니다. 정말 잘 작성됐죠. 사용자들이 우리 애플리케이션에 접근할 수 있고 반응도 매우 좋습니다
다음으로 일어날 일은 이렇습니다.
사용자들이 우리 애플리케이션을 정말 잘 사용하다가 친구들에게도 이 애플리케이션을 사용하도록 추천하죠. 한 친구가 와서 시간을 물어봅니다. 오후 7시 30분입니다. 다른 친구가 와서 시간을 물어봅니다. 오후 6시 30분입니다. 여기서 우리는 애플리케이션이 점점 더 많은 트래픽을 갖게 되면서 t2.micro 인스턴스로는 충분하지 않다는 것을 깨닫게 되죠. 우리는 솔루션스 아키텍트로서 부하를 처리하기 위해 t2.micro 인스턴스를 조금 더 큰 것으로 교체해야겠다고 생각합니다. 이를 수직 확장이라고 하죠. 따라서 m5.large 유형의 인스턴스로 교체하려고 합니다. 인스턴스를 중지시키고 인스턴스 유형을 바꾸고 그 후에 다시 인스턴스를 시작하죠 됐습니다. 이것은 M5 유형 인스턴스입니다. 이는 탄력적 IP를 가지고 있기 때문에 동일한 공용 IP를 가지게 되고 사람들은 여전히 애플리케이션에 접근할 수 있죠. 그러나 M5로 업그레이드 하는 동안 다운타임이 발생했고 사용자들은 이를 그리 좋아하지 않았습니다. 그동안에 애플리케이션에 접근할 수 없었으니까요. 어쨌든 해결은 됐지만 아주 잘 된 것은 아니죠.
다음으로, 우리가 정말로 큰 인기를 얻게 됐습니다. 이제는 수평 확장을 해야 할 때입니다. 이 M5 애플리케이션은 하나의 공용 IP를 가지고 있고 탄력적 IP가 연결되어 있다는 것을 기억하세요. 이제 정말 많은 사용자들이 와서 모두들 시간을 물어봅니다. 그래서 이제는 수평 확장을 하려고 합니다. 먼저 EC2 인스턴스들을 추가하죠. 모두 m5.large입니다. 이것들 모두 탄력적 IP가 연결되어 있죠. 즉 세 개의 EC2 인스턴스가 있고 세 개의 탄력적 IP가 있습니다. 따라서 우리 사용자들이 인스턴스들과 통신하려면 이 세 개의 탄력적 IP의 정확한 값을 알고 있어야 합니다. 이것이 수평 확장입니다. 나름 잘 하고 있지만 이제 한계가 느껴지기 시작합니다. 사용자들은 점점 더 많은 IP를 알아야 하고 우리는 더 많은 인프라를 관리해야 하죠. 꽤 어려운 일입니다.
그러면 접근 방식을 바꿔봅시다. M5 유형의 EC2 인스턴스 세 개가 있습니다. 탄력적 IP를 제거합니다 관리하기 너무 어려우니까요. 한 계정에서 리전마다 겨우 다섯 개의 탄력적 IP만을 가질 수 있습니다. 그 대신 우리 사용자들은 Route 53를 활용하게 될 겁니다. 이를 위해 Route 53를 설정했고 웹사이트 URL은 api.whatisthetime.com입니다. TTL이 한 시간인 A 레코드로 정했습니다. A 레코드로 정했다는 건 이와 같이 DNS로부터 IP 리스트를 받는다는 의미입니다. Route 53의 A 레코드는 IP라는 걸 기억하세요 좋아요. 사용자들이 Route 53을 쿼리합니다. 그러면 EC2 인스턴스들의 IP 주소들을 얻게 되고 이는 시간에 따라 변하고 Route 53이 업데이트될 것이니 전혀 문제가 되지 않습니다. 업데이트를 하고 동기화를 유지할 겁니다. 이제 사용자들은 EC2 인스턴스에 접근할 수 있고 관리할 탄력적 IP도 더 이상 존재하지 않죠. 즉 Route 53을 사용하여 상당한 개선을 이루었습니다.
그러나 이번에는 상황에 따라 즉시 인스턴스를 추가하고 제거할 수 있도록 확장하고 싶어졌습니다. 인스턴스를 제거하면 어떻게 될까요? 가장 위쪽 사용자들이 이 m5.large 인스턴스와 통신 중이었는데 이제 그것이 없어졌습니다. 그리고 TTL이 한 시간이었기 때문에 Route 53 쿼리를 시도하면 동일한 응답을 한 시간 동안 사용하게 됩니다. 따라서 사용자들이 한 시간 동안 그 인스턴스에 접속하려 하겠지만 그 인스턴스는 더 이상 존재하지 않습니다. 이건 그리 바람직하지 않죠. 사용자들이 아마 한 시간 후에는 이 두 인스턴스에는 접속할 수 있어 다시 즐길 수 있겠지만 지금 당장은 만족할 수 없기 때문입니다. 그들은 애플리케이션이 다운됐다고 생각할 것이고 이건 정말 좋지 않습니다. 이것은 아키텍처이고 그 한계도 명확하죠
그러면 어떻게 더 개선할 수 있을까요?
로드 밸런서 추가에 대해 얘기해 봅시다. 이제 공용 인스턴스는 더 이상 없습니다. 대신 사설 EC2 인스턴스들이 있죠. 이들을 같은 가용 영역에서 실행할 겁니다. 더 이상 아는 것이 없으니까요. 수동으로 실행했습니다. 세 개의 m5.large 인스턴스가 있죠. 강의를 들어오면서 로드 밸런서를 사용하자고 했는데 그거 아세요? 로드 밸런서에는 상태 확인 기능도 있습니다. 이는 한 인스턴스가 다운되거나 작동하지 않으면 사용자로부터 해당 인스턴스로 트래픽을 전송하지 않습니다.
이렇게 둘을 연결하면 ELB는 공개되겠지만 사설 EC2 인스턴스들은 뒤에 숨어 있습니다. 그리고 이전에 봤던 보안 그룹 규칙을 사용하여 이 둘 사이의 트래픽을 제한합니다. 보안 그룹을 참조해서요. 꽤 괜찮을 것 같네요.
이제 WhatIsTheTime.com에 대해 사용자들이 쿼리하지만 로드 밸런서가 IP 주소를 지속적으로 바꾸기 때문에 이번에는 A 레코드가 될 수 없습니다. 대신, 로드 밸런서이기 때문에 별칭 레코드를 사용할 수 있습니다. 별칭 레코드는 완벽합니다. Route 53으로부터 ELB를 가리킬 것이고 모든 것이 매우 잘 작동할 거니까요. 여기서 DNS를 바꾸지만 사용자들은 이제 로드 밸런서에 접속합니다. 그리고 로드 밸런서는 EC2 인스턴스로 리디렉션하고 트래픽의 균형을 잡죠 이제 로드 밸런서로 이 인스턴스들을 추가 및 제거하고 정렬할 수 있기 때문에 너무 좋습니다. 또한 상태 확인 기능 덕분에 사용자들에게 다운타임도 없을 겁니다. 정말 좋아요
그러나 수동으로 인스턴스를 추가하고 제거하는 것은 꽤 어렵죠. 이 강의에서 배운 뭔가를 활용하면 어떨까요? 오토 스케일링 그룹을 실행하겠습니다.
이제 왼쪽에는 API 즉 Route 53 ELB가 있고 오른쪽에는 가용 영역이 있습니다. 그리고 사설 EC2 인스턴스를 실행할 겁니다. 그러나 이번에는 오토 스케일링 그룹이 이들을 관리합니다. 즉 기본적으로 오토 스케일링 그룹이 요청에 따라 확장하도록 하는 것이죠. 아마 아침에는 아무도 시간이 궁금하지 않지만 밤에 퇴근하고 싶은 사람들이 시간을 알고 싶어 하겠죠. 이제 요청에 따른 확장이 가능합니다 확장과 축소 모두 말이죠. 애플리케이션에 다운타임은 없고 오토 스케일링과 로드 밸런싱이 있으니 정말로 대단하네요. 정말 안정적인 아키텍처로 보이고 실제로 그렇습니다.
그러나 이번에는 지진이 발생합니다. 가용 영역 1번이 다운됩니다 그러면 어떻게 될까요? 우리 애플리케이션도 완전히 다운됩니다. 사용자들이 좋아하지 않겠죠. Amazon 측이 우리에게 '당신이 다중 AZ를 사용하지 않았기 때문입니다. 가용성을 높이려면 다중 AZ 사용을 추천합니다'라고 말하죠. 우리는 알았다고 대답합니다. 조금 더 바꿔봅시다. 이번에는 ELB가 필요할 겁니다. 상태 확인 뿐만 아니라 다중 AZ도 추가됩니다. AZ 1부터 3에서 실행될 것이며 이 ELB는 세 개의 AZ가 있습니다. 오토 스케일링 그룹 역시 다중 AZ에 걸쳐 있게 됩니다. 예를 들어 AZ 1에 두 개의 인스턴스가 있고 AZ 2에 두 개의 인스턴스가 있고 AZ 3에는 하나가 있다고 합시다. 이 경우 AZ 1이 다운되더라도 AZ 2와 AZ 3이 있기 때문에 사용자를 위한 트래픽을 처리할 수 있다는 장점이 있죠. 이제 앱을 다중 AZ로 만들었고 높은 가용성을 확보했으며 장애 발생에도 대비가 됐습니다 정말 훌륭하네요.
더 개선할 여지가 있을까요?
계속 해봅시다. 두 개의 AZ가 있습니다. 그리고 각각의 AZ에는 최소 하나 이상의 인스턴스가 실행 중일 겁니다. 그러면 용량을 예약하면 어떨까요? 기본적으로 애플리케이션의 비용을 줄이는 작업을 시작하는 것이죠. 1년 내내 두 개의 인스턴스가 항상 실행 중일 것이기 때문입니다. 즉 오토 스케일링 그룹의 용량을 최소화하기 위해 인스턴스를 예약함으로써 미래에 상당한 비용을 절감할 수 있을 겁니다. 새로운 인스턴스가 실행되더라도 일시적일 것이고 요청에 따른 것은 괜찮습니다. 좀 더 극단적으로는 비용 절감을 위해 스팟 인스턴스를 사용할 수도 있죠. 그러나 이는 인스턴스들을 종료시키게 될 수도 있습니다.
아키텍처가 아주 작은 애플리케이션에서 시작하여 로드 밸런싱, 오토 스케일링 그룹 다중 AZ, 상태 확인 예약 인스턴스까지 진행되는 걸 보면 정말 재미 있지 않나요? 이것이 솔루션스 아키텍트로서 여러분이 가야 할 길입니다. 요구 사항이 무엇인지를 이해하는 것에 달려있죠. 이 요구 사항들에 대해 어떻게 대응해야 할까요? 여러분은 이런 것에 대해 시험을 치르게 될 겁니다. 지금까지 첫 번째 아키텍처에 대해 다뤘습니다. 다음 강의에서도 다른 많은 것들이 나올 겁니다. 일단 지금은 배운 내용을 복습하겠습니다.
예를 들면, EC2 인스턴스가 공용 IP와 사설 IP를 갖는 목적에 대해 얘기했죠. 아키텍처 도표의 어디에 해당하는지 여러분은 알고 있을 겁니다.
또한 애플리케이션에 탄력적 IP vs Route 53 vs 로드 밸런서를 사용할 때의 장점에 대해 배웠습니다.
또한 Route 53 TTL 때문에 A 레코드를 사용할 수 없었고 따라서 로드 밸런서와 별칭 레코드를 사용해야 한다는 것을 봤습니다. 즉 Route 53이 전체적인 그림에서 어떻게 맞아들어가는지 알 수 있죠
EC2 인스턴스를 수동으로 관리하는 법과 그에 대한 유지 보수가 어렵다는 것을 봤습니다. 오토 스케일링 그룹도 사용했는데 여러분 그거 아세요? 사실 이는 비용 절감에도 도움이 됩니다. 요청이 있을 때만 확장을 함으로써 EC2 인스턴스의 양을 항상 최적으로 유지할 수 있기 때문입니다.
다음은 다중 AZ를 다뤘죠. 이 방법을 통해 재난 발생을 극복할 수 있습니다.
정확히 응답하는 인스턴스만 트래픽을 받도록 하기 위해 ELB 상태 확인도 활성화했습니다
EC2 인스턴스가 ELB로부터의 트래픽만 받도록 보안 그룹 규칙을 설정하는 법도 다뤘습니다.
그리고 마지막으로 용량에 대해 살펴봤습니다. 비용 절감을 위한 것이죠. 항상 두 개의 EC2 인스턴스가 실행되어야 한다는 것을 알고 있습니다. 이 인스턴스들을 예약하면 많은 비용을 절감할 수 있죠.
이 모든 내용을 다뤘습니다. AWS에는 좋은 아키텍처를 가진 프레임워크라는 것이 있습니다. 이 부분에 대해서는 별도의 섹션에서 보다 상세하게 다루겠지만 일단 다섯 개의 기둥이 존재합니다. 비용, 성능, 신뢰성, 보안 그리고 탁월한 운영을 말하죠. 이번 설명에서 여러분이 실제로 이 다섯 가지 기둥을 모두 접하도록 해주고 싶었습니다. 비용은 다양한 목적을 가집니다. 인스턴스를 수직으로 확장할 수도 있고 부하에 따라 적절한 양의 인스턴스를 갖기 위해 ASG를 사용할 수도 있습니다. 비용 최적화를 위해서 인스턴스를 예약할 수도 있죠. 성능 측면에서는 수직 확장을 봤습니다. ELB와 오토 스케일링 그룹도 봤고 기본적으로 시간이 흐르면서 어떻게 성능을 조정하는지도 봤습니다. 신뢰성 측면에서는 트래픽을 안정적으로 적절한 EC2 인스턴스에 전달하기 위해 Route 53를 어떻게 사용하는지 살펴봤습니다. ELB와 ASG에 대한 다중 AZ를 사용할 수도 있죠. 보안에 대해서는 로드 밸런서와 인스턴스들을 확실히 연결하기 위해 보안 그룹을 사용하는 법도 봤습니다. 탁월한 운영 측면에서는 매우 투박한 수동 프로세스에서 시작하여 오토 스케일링 그룹 등의 기능을 갖추고 완전히 자동화되도록 개선할 수 있었습니다.
120. MyClothes.com
이전 강의에서는 무상태 형식의 웹 애플리케이션인 WhatIsTheTime.com을 다뤘습니다. 단순히 시간을 알려주기만 했고 이를 위해 어떤 데이터베이스나 정보 또는 외부 정보를 필요로 하지 않았죠.
이번에는 상태 유지 웹 애플리케이션인 MyClothes.com을 다루겠습니다. MyClothes.com은 사람들이 온라인으로 옷을 살 수 있게 해주고
MyClothes.com을 둘러볼 때 장바구니가 있습니다.
동시에 수백 명의 사용자가 있고 이 모든 사용자들이 웹사이트를 둘러봅니다
확장을 할 수 있어야 하고 수평 확장성을 유지하며 애플리케이션의 웹 티어를 최대한 무상태로 유지하고 싶습니다. 비록 장바구니의 상태가 존재하지만 웹 애플리케이션을 최대한 쉽게 확장할 수 있어야 하죠
이는 사용자들이 웹사이트를 둘러볼 때 장바구니를 잃어버리면 안된다는 뜻입니다 그건 정말 좋지 않아요. 또한 주소 등의 사용자 정보를 효과적으로 보관하고 어디에서나 접근할 수 있는 데이터베이스에 저장할 겁니다.
어떻게 하는지 보시죠
이번 내용도 정말 재미있지만 동시에 꽤 어려울 겁니다
이것이 우리 애플리케이션입니다 빨리 진행하겠습니다. 여기에 이전 강의에서 봤던 것과 같은 종류의 아키텍처가 있습니다. 사용자가 있고 Route 53과 다중 AZ ELB가 있으며 오토 스케일링 그룹과 세 개의 AZ가 기본적으로 있죠. 애플리케이션이 ELB에 접근하고 ELB는 '이 인스턴스와 대화하세요' 라고 하죠. 장바구니를 생성하고 다음 요청은 같은 인스턴스가 아니라 다른 인스턴스로 갑니다. 그러면 장바구니가 사라집니다. 사용자는 '아마도 작은 버그가 있는 것 같군 다시 해봐야지'라고 생각합니다. 그래서 장바구니에 뭔가를 넣은 다음 이번에는 세 번째 인스턴스로 리디렉션되는데 또 장바구니가 사라집니다 그러면 사용자는 화가 나서 이렇게 말하겠죠. '잠깐, 내가 뭔가를 할 때마다 장바구니가 없어지잖아 이거 정말 이상한데 MyClothes.com은 나쁜 웹사이트야 여기에서 쇼핑 안 할 거야'라고 하면 손해를 보겠죠.
이걸 어떻게 고칠까요? 고착도 즉 세션 밀접성을 도입할 수 있습니다. 이는 ELB의 기능이죠 ELB Stickiness를 활성화합니다. 이제 사용자가 첫 번째 인스턴스에 접속하여 뭔가를 장바구니에 추가합니다. 그리고 고착도 덕분에 두 번째 요청도 동일한 인스턴스로 가게 됩니다. 세 번째 요청도 마찬가지로 같은 인스턴스로 가죠. 사실 모든 요청이 고착도 덕분에 동일한 인스턴스로 가게 될 겁니다. 아주 잘 작동하지만 만약 EC2 인스턴스가 어떤 이유로든 종료되면 장바구니를 잃어버리게 됩니다. 어쨌든 고착도과 세션 밀접성 덕분에 조금은 개선된 것은 사실이죠.
이제 완전히 다른 접근 방법인 사용자 쿠키를 살펴봅시다.
기본적으로 EC2 인스턴스가 장바구니 내용을 저장하는 대신 사용자쪽에서 장바구니 내용을 저장하도록 하는 것이죠. 로드 밸런서에 접속할 때마다 '내 장바구니에는 이런 것들이 있어'라고 말하게 하는 것입니다. 이는 웹 쿠키를 통해 이루어집니다. 첫 번째 서버에 접속하거나 두 번째 또는 세 번째 서버에 접속해도 사용자가 직접 EC2 인스턴스로 장바구니 내용을 보내주기 때문에 각각의 서버가 장바구니의 내용을 알 수 있습니다. 정말 멋지죠? 이제 각각의 EC2 인스턴스가 이전에 있었던 일을 알 필요가 없는 무상태를 달성했습니다. 이전에 있었던 일은 사용자가 말해줄 겁니다.
그러나 HTTP 요청이 점점 더 무거워지는 문제가 있습니다. 왜냐하면 웹 쿠키를 통해 장바구니 내용을 보낼 때 장바구니에 뭔가를 추가할수록 점점 더 많은 데이터를 보내기 때문이죠. 또한 쿠키가 공격자에 의해 변경됨으로써 사용자의 장바구니가 갑자기 수정될 수 있기 때문에 어느 정도의 보안 위험도 존재합니다. 따라서 이런 종류의 아키텍처에서는 EC2 인스턴스가 반드시 사용자 쿠키의 내용을 검증해야 합니다. 또한 전체 쿠키의 크기는 4KB 이하까지만 가능해 쿠키 내에는 매우 작은 정보만 저장할 수 있습니다. 대량의 데이터 셋을 저장할 수는 없어요
그래서 개념은 이러합니다. 지금까지 아주 잘 작동하고 있죠. 이것은 많은 웹 애플리케이션 프레임워크에서 실제로 사용하는 패턴입니다. 그러나 조금 다른 것을 해보면 어떨까요? 서버 세션 개념을 도입해 봅시다.
전체 장바구니를 웹 쿠키로 보내는 대신에 단순히 세션 ID만 보내는 것이죠. 이것은 사용자에 대한 세션 ID입니다. 즉 이걸 보낼 것이고 백그라운드에는 ElastiCache 클러스터가 존재합니다. 세션 ID를 보낼 때 EC2 인스턴스에게 '이 물건을 장바구니에 추가할 거야'라고 말합니다. 그러면 EC2 인스턴스는 장바구니 내용을 ElastiCache에 추가하고 이 장바구니 내용을 불러올 수 있는 ID가 바로 세션 ID가 됩니다. 그래서 사용자가 세션 ID와 함께 두 번째 요청을 보내면 이는 다른 EC2 인스턴스로 가게 되고 그 EC2 인스턴스는 세션 ID를 사용하여 ElastiCache로부터 장바구니 내용을 찾아서 세션 데이터를 불러올 수 있습니다.
마지막 요청에 대해서도 동일한 패턴입니다. ElastiCache의 또 다른 장점은 1천분의 1초 이하의 성능을 가졌다는 점이죠. 따라서 이 모든 것은 매우 빠르게 진행됩니다. 참고로 세션 데이터 저장의 또 다른 방식으로 아직 다루지는 않았지만 DynamoDB가 있습니다. DynamoDB가 무엇인지 아시는 분이 있을 수도 있어서 말씀드리는 겁니다
이제 정말 멋진 패턴이 됐습니다. ElastiCache가 정보의 출처이고 공격자들은 ElastiCache의 내부를 수정할 수 없기 때문에 훨씬 안전해졌습니다. 훨씬 더 안전한 패턴이고 실제로 많이 사용됩니다.
ElastiCache에 대해 알아봤습니다. 사용자 데이터를 데이터베이스에 저장하려고 합니다. 사용자 주소 등을 저장하고 싶습니다. 따라서 다시 한번 EC2 인스턴스와 통신을 할 텐데 이번에는 RDS 인스턴스와 통신할 겁니다. RDS는 장기적인 저장을 위한 것이라 좋습니다. RDS와 직접 통신함으로써 주소, 이름 등의 사용자 데이터를 저장하거나 불러올 수 있습니다. 그리고 각각의 인스턴스가 RDS와 통신할 수 있으며 일종의 다중 AZ 무상태 솔루션을 효과적으로 얻을 수 있습니다.
트래픽이 늘어나고 우리 웹사이트가 잘 운영됩니다. 사용자도 계속 늘어나죠.
우리는 사용자들이 대부분의 시간을 웹사이트를 둘러보며 보낸다는 걸 알게 됩니다. 읽어서 제품 정보를 얻는 등의 일이죠. 그러면 어떻게 읽기를 확장할까요? 쓰기를 수행하는 RDS 마스터를 사용할 수 있습니다. 복제가 일어나는 RDS 읽기 전용 복제본을 사용할 수도 있습니다. 즉 뭔가를 읽을 때 읽기 전용 복제본으로부터 읽습니다. RDS에서는 다섯 개의 읽기 전용 복제본을 가질 수 있죠. 이는 RDS 데이터베이스의 읽기를 확장할 수 있도록 해줍니다.
또 다른 패턴으로는 캐시를 사용하는 쓰기 모드도 있습니다. 사용자가 EC2 인스턴스와 통신하는 방식으로 작동합니다. 캐시를 살펴보고 '이런 정보를 가지고 있나요?'라고 물어봅니다. 가지고 있지 않다면 RDS로부터 읽어 들여서 ElastiCache에 집어넣죠. 즉 이 정보가 캐싱 되는 것입니다. 다른 EC2 인스턴스들도 같은 방식으로 작동합니다. 단 이번에는 ElastiCache와 통신할 때 정보를 얻게 되고 캐시 히트됩니다. 그러면 캐싱이 됐기 때문에 즉시 응답을 받습니다.
이 패턴을 통해 RDS상의 트래픽을 줄일 수 있죠. 기본적으로 RDS상의 CPU 사용을 줄이고 동시에 성능을 향상시키는 겁니다 그러나 이제는 캐시 유지 보수가 필요합니다. 이는 꽤 어려운 일이고 애플리케이션 쪽에서 이루어져야 하죠.
아주 좋습니다 이제 우리 애플리케이션은 확장이 가능하고 많은 읽기가 있습니다 .
이제 재해에 대비할 차례입니다. 재해로 인해 피해를 받지 않으려면어떻게 할까요?
사용자가 Route 53과 통신을 하는데 이제 우리는 다중 AZ ELB가 있죠. 그런데 Route 53은 이미 가용성이 높습니다. 뭔가를 더 할 필요가 없죠. 로드 밸런서는 다중 AZ로 만들 겁니다. 오토 스케일링 그룹도 다중 AZ죠. 다음으로 RDS 역시 다중 AZ 기능이 있습니다. 또 다른 방법으로는 재해가 발생할 경우 인계받을 수 있는 대기 복제본이 있습니다. 레디스를 사용한다면 ElastiCache도 다중 AZ 기능을 가지고 있습니다. 정말 좋습니다 이제 전반적으로 다중 AZ 애플리케이션이 됐습니다. AWS의 가용 영역이 다운되는 것에 대비할 수 있게 됐네요.
보안 그룹에 대해서는 매우 안전해야 합니다. ELB 쪽 어디에서나 HTTP HTTPS 트래픽을 열 수 있습니다. EC2 인스턴스 측면에서는 로드 밸런서로부터 오는 트래픽만 제한하고 ElastiCache 측면에서는 EC2 보안 그룹으로부터 오는 트래픽만 제안하려 합니다. RDS도 마찬가지입니다. EC2 보안 그룹으로부터 오는 트래픽을 제안하기 원합니다. 이상입니다.
이제 웹 애플리케이션에 대한 이 아키텍처에 대해 얘기해 봅시다
ELB 고정 세션,
쿠키 저장을 위한 웹 클라이언트 웹 앱을 무상태로 만드는 법,
ElastiCache를 위한 세션 ID와 세션 캐시의 사용,
- 그리고 대안으로서의 사용할 수 있는 DynamoDB에 대해 얘기했습니다.
- 읽기의 경우 RDS로부터 데이터 캐시를 위해 ElastiCache를 사용할 수 있죠.
- 또 재해에 대비하기 위해 다중 AZ를 사용할 수 있습니다
사용자 데이터를 저장하기 위해
- 더 오래가는 데이터 형식인 RDS를 사용할 수 있습니다
- 읽기 전용 복제본은 읽기 확장에 사용하고 또는 ElastiCache를 사용할 수도 있고
- 재해 복구를 위한 다중 AZ가 있습니다
또한 서로 참조하는 보안 그룹을 위해 철저한 보안을 추가했습니다
이것은 꽤 복잡한 애플리케이션입니다. 클라이언트 티어, 웹 티어 그리고 데이터베이스 티어 이렇게 세 개의 티어가 있죠. 이것은 매우 보편적인 아키텍처입니다. 비용이 다소 증가하기 시작했지만 그래도 괜찮습니다. 대신 얻는 게 무엇인지 알고 있으니까요. 다중 AZ를 원한다면 당연히 돈도 더 내야겠죠. 읽기를 확장하고 싶다면 당연히 돈을 더 내야 합니다. 그 대신 아키텍처 관련 결정을 내릴 때 도움이 되는 것들을 얻을 수 있습니다.
121. MyWordPress.com
상태 유지 웹 애플리케이션을 하나 더 살펴봅시다. MyWordPress.com이라고 부르겠습니다
완전히 확장 가능한 WordPress 웹사이트를 만들려고 합니다. WordPress는 웹사이트를 만드는데 흔히 사용되는 방법으로 아주 인기가 많죠. WordPress를 호스팅 하기도 하지만 사람들은 WordPress를 AWS에 배포하는 걸 좋아하죠.
그 웹사이트에 접근하고 싶고 업로드한 그림이 바르게 나타나길 원합니다. WordPress가 작동하는 방식으로 어떤 드라이브에 그림을 저장하고 기본적으로 모든 인스턴스들이 그 데이터에 접근해야 하죠. 이 내용은 솔루션 아키텍처 설명에서 볼 수 있을 거예요.
사용자 데이터와 블로그 내용 등 모든 게 MySQL 데이터베이스에 저장되야 하고 글로벌하게 확장하고 싶습니다 어떻게 이를 달성할 수 있는지 보시죠.
첫 번째로 할 일은 RDS가 있는 계층을 생성하는 것입니다
이제 백엔드에 RDS가 있는 이러한 아키텍처는 우리에게 매우 익숙합니다. 다중 AZ이고 모든 EC2 인스턴스에 걸쳐 적용되죠.
만약 정말로 크게 확장하고 싶다면 어떻게 할까요? 이 계층을 오로라 MySQL로 교체할 겁니다. 다중 AZ, 읽기 전용 복제본, 원하면 글로벌 데이터베이스까지 적용할 수 있죠. 바로 여기에서 오로라를 사용함으로써 연산을 줄일 수 있습니다. 이는 솔루션스 아키텍트로서 제가 선택한 겁니다. 여러분도 같은 선택을 할 필요는 없어요. 그러나 저는 오로라를 좋아합니다. 보다 확장성 있고 기록하기 쉽기 때문이죠.
좋아요 이제 이미지 저장에 대해 다뤄 봅시다. 하나의 EC2 인스턴스가 있고 하나의 EBS 볼륨이 연결되어 있는 단일 AZ의 아주 단순한 솔루션 아키텍처를 살펴봅시다. 일단 로드 밸런서에 연결되어 있습니다. 사용자는 로드 밸런서로 이미지를 보내고 싶죠. 그러면 그 이미지는 EBS까지 도달합니다. 그리고 EBS에 저장되죠. EC2 인스턴스가 하나일 때는 정말 잘 작동합니다. EBS 볼륨까지 바로 연결되고 아무 문제 없죠. 이미지를 불러올 때도 마찬가지입니다. EBS 볼륨으로부터 이미지를 읽어들여서 사용자에게 보내죠 좋습니다.
그러나 확장하기 시작하면 문제가 생깁니다. 이제 두 개의 EC2 인스턴스와 두 개의 AZ가 있죠. 그리고 각각의 EC2 인스턴스는 각각의 EBS 볼륨을 가지고 있습니다. 어떻게 되는지 보시죠 이 인스턴스로 이미지를 보내면 해당 EBS 볼륨에 저장됩니다. 이미지를 불러오고 싶다면 이쪽으로 와서 읽어들일 수 있죠 그러나 흔한 오류는 이미지를 읽어들이기 위해 이쪽으로 가는 겁니다. 그러면 같은 EBS 볼륨이 아니기 때문에 아래쪽에는 이미지가 없고 이미지에 접근할 수 없습니다. 아주 좋지 않죠. EBS 볼륨의 단점은 하나의 인스턴스만 있을 때는 아주 잘 작동하지만 다중 AZ 또는 다중 인스턴스로 확장을 시작하면 문제가 생기기 시작한다는 점입니다.
이를 해결하려면 어떻게 저장하는지 이미 보신 적이 있죠. EFS를 사용할 수 있습니다 완전히 동일한 아키텍처를 사용해 봅시다. 하지만 이번엔 EFS 즉 네트워크 파일 시스템 드라이브를 사용합니다. EFS가 NFS죠.
EFS는 탄력적인 네트워크 인터페이스를 위해 각각의 AZ에 ENI를 생성합니다. 이 ENI는 EFS 드라이브에 접근하는 모든 EC2에 사용할 수 있습니다. 여기에서 정말 좋은 것은 스토리지가 모든 인스턴스에게 공유된다는 점이죠. 즉 M5 인스턴스로 이미지를 보내면 ENI를 거쳐 EFS로 전달되고 이미지가 EFS에 저장됩니다. 이미지를 불러오고 싶다면 아래쪽으로 가서 ENI를 거쳐 EFS로부터 읽어들이죠. EFS에 그 이미지가 있고 이미지를 보낼 수 있습니다. 이것은 가용 영역이나 인스턴스 숫자에 관계없이 모든 인스턴스가 동일한 파일에 접근하도록 허용하기 위해 다수의 EC2 인스턴스에 걸쳐 웹사이트 스토리지를 확장하는 아주 흔한 방법입니다.
이상으로 WordPress에 대한 조금 미묘한 내용이었지만 EBS와 EFS의 차이에 대해 말씀드리고 싶었습니다
적은 연산량과 다중 AZ 및 읽기 전용 복제본을 갖춘 오로라 데이터베이스에 대해 얘기했고
단일 인스턴스 애플리케이션에서 아주 잘 작동하는 EBS에 데이터를 저장하는 것에 대해서도 다뤘습니다
그러나 인스턴스가 많아지면 잘 작동하지 않기 때문에 EFS를 사용하여 다중 AZ에 걸친 분산 애플리케이션을 만들 수 있죠. 비용 관점에서 볼 때 EBS가 EFS 보다 쌉니다. 그러나 EFS를 사용할 때 많은 이점을 얻을 수 있죠. 특히 이와 같은 사례에서 말이죠. 다시 한번 말씀드리지만 작업에 대한 장단점과 왜 그 작업을 하는지 그리고 그로 인한 비용을 이해하는 것은 솔루션스 아키텍트인 여러분에게 달려있습니다.
122. 애플리케이션을 빠르게 인스턴스화 하기
애플리케이션을 빠르게 인스턴스화하는 방법에 대한 짧은 강의입니다. 지금까지 거쳐온 모든 아키텍처 관련 강의에서 웹사이트를 운영하기 위해서 EC2 인스턴스에 애플리케이션을 어떻게 설치하고 배포하는지에 대해 다룬 적은 없습니다.
풀 스택을 실행하면
- 애플리케이션을 설치하고
- 데이터 삽입 및 복구하고
- 모든 내용을 구성한 다음
- 애플리케이션을 실행하는 데 매우 긴 시간이 걸립니다.
어떻게 하면 더 빨리 할 수 있을까요?
속도를 높이기 위해 클라우드의 장점을 사용할 수 있죠
한번 봅시다
EC2 인스턴스에서
- Golden AMI를 사용할 수 있습니다. Golden AMI는 애플리케이션과 OS 종속성 등 모든 것을 사전에 설치하고 그것으로부터 AMI를 생성하는 것이죠. 이후로는 EC2 인스턴스들을 Golden AMI로부터 직접 실행하면 됩니다. 이렇게 하는 이유는 애플리케이션, OS 종속성 등을 재설치할 필요가 없기 때문입니다. 모든 것이 이미 설치된 상태에서 바로 실행할 수 있죠. 이것이 EC2 인스턴스를 시작하는 가장 빠른 방법입니다. 그래서 Golden AMI는 클라우드에서 아주 흔한 패턴입니다
- EC2 사용자 데이터를 어떻게 사용하는지도 살펴봤습니다. 이는 인스턴스를 부트스트랩할 수 있게 해주죠. 부트스트래핑은 기본적으로 인스턴스가 처음 시작될 때 구성하는 것을 의미합니다. 즉 애플리케이션, OS 종속성 등을 설치하기 위해 부트스트래핑을 할 수 있죠. 그러나 이건 매우 느립니다. EC2 인스턴스가 다른 인스턴스가 이미 했던 완전히 같은 일을 반복하기를 원하지 않습니다. 동적 구성에서 예를 들면 데이터베이스 URL과 비밀번호 등을 가져올 때 EC2 사용자 데이터를 사용하여 부트스트래핑을 활용할 수 있죠.
- 우리는 기본적으로 Golden AMI와 EC2 사용자 데이터를 하이브리드 혼합체로 작동하도록 할 수 있습니다. 이건 곧 Elastic Beanstalk을 사용할 때 보게 될 겁니다. Elastic Beanstalk은 AMI를 구성하고 사용자 데이터를 추가하는 하이브리드와 동일한 원칙을 적용합니다.
RDS 데이터베이스는
- 스냅샷으로부터 복구할 수 있고 그러면 데이터베이스에서 스키마와 데이터가 준비될 겁니다. 이는 RDS 데이터베이스를 시작하기까지 매우 긴 시간이 걸리는 대형 삽입 문장을 사용하는 것보다 훨씬 낫죠. 데이터를 검색하려고 할 때 더 빠르게 할 수 있는 방법입니다.
스냅샷으로부터 EBS 볼륨을
- 복구할 수 있어서 포맷되지 않은 빈 디스크는 필요하지 않습니다. 스냅샷에서 가져올 수 있고 스냅샷은 이미 적절히 포맷되어 있으며 필요한 데이터를 가지고 있을 겁니다.
시험장에 갈 때 솔루션스 아키텍트로서 이해해야 하는 부분을 말씀드렸습니다. EC2 인스턴스의 시작 속도를 높여야 하고 RDS 데이터베이스 또는 EBS 볼륨의 속도를 높여야 하며 이 모든 것들을 포맷해야 하죠. 이것이 Golden AMI 사용자 데이터 데이터베이스 스냅샷 EBS 스냅샷을 사용할 때 해야 할 일입니다.
123. Beanstalk 개요
이제 일래스틱(Elastic) Beanstalk에 대해 이야기해 봅시다. 이 강의를 진행하면서 지금까지는 애플리케이션을 실행할 때 동일한 아키텍처를 사용해왔습니다. 사용자로부터 모든 요청을 접수하는 로드 밸런서가 있고 다수의 가용 영역을 가진 오토 스케일링 그룹이 있으며 각각의 AZ에서 실행되는 EC2 인스턴스가 있습니다. 그리고 백엔드에는 RDS 데이터베이스를 위한 데이터 서브넷이 있어 읽기와 쓰기를 받아들입니다. 그 외 읽기 전용 복제본도 있죠. 캐싱 계층이 필요하다면 일래스티 캐시를 사용해야 합니다.
우리가 배포할 수 많은 애플리케이션이 존재하고 이들은 동일한 아키텍처를 따릅니다. 이를 매번 다시 생성하는 건 힘든 일이죠.
개발자로서 인프라를 관리하고
코드를 배포하는 것은 복잡합니다
모든 데이터와 로드 밸런서 등을 구성하고 싶지는 않죠
물론 모든 것이 확장 가능해야 합니다
보시는 것처럼
대부분의 웹 애플리케이션은 로드 밸런서와 오토 스케일링 그룹이 있는 동일한 아키텍처를 가집니다.
개발자로서 원하는 것은 코드가 잘 실행되는 것뿐입니다.
다른 것들에 대해서는 걱정하고 싶지 않아요
또한 여러 프로그래밍 언어로 개발할 때 여러 다른 애플리케이션과 환경이 있다면 아마도 애플리케이션을 배포하는 단 하나의 방법만을 원할 겁니다. 이때 필요한 것이 Beanstalk이죠
Beanstalk은 AWS에서 애플리케이션을 배포하는 개발자 중심의 관점입니다.
즉 단 하나의 인터페이스로 우리가 지금까지 봤었던 EC2, ASG, ELB, RDS 등의 모든 구성 요소를 재사용하는 것이죠.
여러분을 위해 이 모든 것을 배포하는 관리 서비스가 될 겁니다
- 즉 용량 프로비저닝과 로드 밸런서의 구성, 확장, 애플리케이션 상태 모니터링, 인스턴스 구성 등을 처리해 줄 거예요.
- 개발자로서 여러분이 신경써야 할 유일한 부분은 코드 그 자체 뿐이죠
여러분은 여전히 각각의 구성 요소를 완전히 제어할 수 있지만 Beanstalk에서는 하나의 인터페이스로 통합되어 있습니다. 또한 Beanstalk는 아주 멋진 애플리케이션 업데이트 방법을 가지고 있죠.
Beanstalk 서비스 자체는 무료지만 Beanstalk가 활용할 기본 인스턴스들이나 ASG 또는 ELB 등에 대한 비용은 지불해야 합니다
Beanstalk의 구성 요소는 애플리케이션으로 이루어져 있습니다. 이는 환경과 버전 그리고 구성을 가진 Beanstalk 구성 요소들의 묶음으로 구성되어 있습니다
애플리케이션 버전은 애플리케이션 코드의 반복입니다. 그래서 버전 1, 버전 2 버전 3 등이 있을 수 있습니다.
- 환경은 특정 애플리케이션 버전을 실행하는 리소스의 모음입니다. 환경 내에서는 한 번에 하나의 애플리케이션 버전만 존재할 수 있습니다. 환경 내에서 애플리케이션 버전을 버전 1에서 버전 2로 업데이트 할 수 있죠
- Beanstalk에서는 서로 다른 두 개의 티어를 가질 수 있습니다. 웹 서버 환경 티어와 작업자 환경 티어가 있는데 곧 살펴볼 겁니다.
- 또한 Beanstalk에서는 dev, test, prod 등 여러분이 생각하는 어떤 환경이든 다수의 환경을 만들 수 있습니다.
프로세스를 말씀드리면 애플리케이션을 생성하고 -> 버전을 업로드하고 -> 환경을 실행하고 -> 그 후에는 환경 수명 주기를 관리합니다
이를 반복하고 싶다면 새로운 버전을 업로드하여 버전을 업데이트하고 환경 내에서 새로운 버전을 다시 실행하여 애플리케이션 스택을 업데이트합니다
Beanstalk은 여러 프로그래밍 언어를 지원하는데
Go, Java SE, Java with Tomcat .NET Core on Linux, .NET Core on Windows Server Node.js, PHP, Python, Ruby, Packer Builder Single Container Docker, Multi-container Docker Preconfigured Docker 등입니다
원하는 프로그래밍 언어가 여기에 없다면 사용자 지정 플랫폼을 만들 수 있는 고급 기능도 있습니다. Beanstalk에서는 거의 모든 것을 배포할 수 있다고 보면 됩니다
마지막으로 서버 티어와 작업자 티어는 무슨 뜻일까요?
웹 티어의 모습은 이와 같습니다. 우리가 아는 전통적인 방식의 아키텍처죠. 로드 밸런서가 있는데 여기에서 웹 서버가 될 다수의 EC2 인스턴스가 있는 오토 스케일링 그룹으로 트래픽을 보냅니다. 이걸 Beanstalk의 1번 아키텍처라고 합시다.
Beanstalk의 2번 아키텍처는 작업자 환경에 대한 것입니다. 따라서 이번에는 클라이언트가 직접 EC2 인스턴스에 접근하지 않죠. 메시지 대기열인 SQS 대기열을 사용할 겁니다. 메시지가 SQS 대기열로 전송됩니다. 그리고 EC2 인스턴스들이 작업자가 되죠. 왜냐하면 SQS 대기열로부터 메시지를 가져와서 처리하기 때문입니다. 그리고 이 경우에는 작업자 환경이 SQS 메시지 숫자에 따라 확장될 겁니다. 즉 메시지가 많을수록 EC2 인스턴스도 많아집니다. 멋진 점을 말씀드리면 웹 환경이 작업자 환경의 SQS 대기열로 메시지를 푸시함으로써 웹 환경과 작업자 환경이 함께 할 수 있다는 점입니다.
Beanstalk의 개요에 대해 말씀드렸습니다
