aws MyClothes.com

AWS MyClothes.com

- MyClothes.com은 온라인 쇼핑 플랫폼으로 AWS를 기반으로 구축되었습니다.

- 이 웹사이트는 고객들에게 다양한 의류, 액세서리, 신발 등의 패션 아이템을 제공하여 개별 소비자나 기업에서 손쉽게 구매할 수 있도록 도와줍니다.

- 안정적이고 확장 가능한 서비스를 제공할 수 있도록 하는 클라우드 컴퓨팅 플랫폼입니다.

- 이를 통해 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기 있습니다. ElastiCache가 정보의 출처이고 공격자들은 ElastiCache의 내부를 수정할 수 없기 때문에 훨씬 안전해졌습니다 훨씬 더 안전한 패턴이고 실제로 많이 사용됩니다. 

 

 

사용자 데이터를 데이터베이스에 저장하려고 합니다. 사용자 주소 등을 저장하고 싶습니다. 따라서 다시 한번 EC2 인스턴스와 통신을 할 텐데 이번에는 RDS 인스턴스와 통신할 겁니다. RDS는 장기적인 저장을 위한 것이라 좋습니다. 따라서 다시 한번 EC2 인스턴스와 통신을 할 텐데 이번에는 RDS 인스턴스와 통신할 겁니다. RDS는 장기적인 저장을 위한 것이라 좋습니다. RDS와 직접 통신함으로써 주소, 이름 등의 사용자 데이터를 저장하거나 불러올 수있습니다. 그리고 각각의 인스턴ㄴ스가 RDS와 통신할 수 있으며 일종의 다중 AZ 무상태 솔루션을 효과적으로 얻을 수 있습니다. 트래픽이 늘어나고 우리 웹 사이트가 잘 운영됩니다.

 

 

사용자도 계속 늘어납니다. 우리는 사용자들이 대부분의 시간을 웹사이트를 둘러보며 보낸다는 걸 알게 됩니다. 읽어서 제품 정보를 얻는 등의 일입니다. 그러면 어떻게 읽기를 확장할까요 쓰기를 수행하는 RDS 마스터를 사용할 수 있습니다. 복제가 일어나는 RDS 읽기 전용 복제본을 사용할 수도 있습니다. 즉 뭔가를 읽을 때 읽기 전용 복제본으로부터 읽습니다, RDS에서는 다섯 개의 읽기 전용 복제본을 가질 수 있습니다. 이는 RDS 데이터베이스의 읽기를 확장할 수있도록 해줍니다. 

 

 

또 다른 패턴으로는 캐시를 사용하는 쓰기 모드도 있습니다. 사용자가 EC2 인스턴스와 통신하는 방식으로 작동합니다. 캐시를 살펴보고 '이런 정보를 가지고 있나요'라고 물어봅니다. 가지고 있지 않다면 RDS로부터 읽어 들여서 ElastiCache에 집어넣었습니다. ElastiCache에 집어넣었습니다. 즉 이정보가 캐싱 되는 것입니다. 다른 EC2 인스턴스들도 같은 방식으로 작동합니다. 단 이번에는 ElastiCache와 통신할 때 정보를 얻게 되고 캐시 히트됩니다, 그러면 캐싱이 됐기 때문에 즉시 응답을 받습니다.  이 패텀을 통해 RDS상의 트래픽을 줄일 수 있습니다. 기본적으로 RDS상의 CPU 사용을 줄이고 동시에 성능을 향상시키는 겁니다. 그러나 이제는 캐시 유지 보수가 필요합니다. 이는 꽤 어려운 일이고 애플리케이션 쪽에서 이루어져야 합니다. 아주 좋습니다. 이제 우리 애플리케이션은 확장이 가능하고 많은 읽기가 있습니다.

 

 

이제 재해에 대비할 차례입니다, 재해로 인해 피해를 받지 않으려면 어떻게 할까요> 사용자 Route 53과 통신을 하는데 이제 우리는 다중 AZ ELB가 있습니다. 그런데 Route 53은 이미 가용성이 높습니다. 뭔가를 더 할 필요가 없습니다, 로드 밸런서는 다중 AZ로 만들 겁니다, 오토 스케일링 그룹도 다중 AZ입니다. 다음으로 RDS 역시 다중 AZ 기능이 있습니다, 또 다른 방법으로는 재해가 발생할 경우 인계받을 수 있는 대기 복제본이 있습니다, RDS를 사용하다면 ElastiCache도 다중 AZ 기능을 가지고 있습니다. 이제 전반적으로  다중 AZ 애플리케이션이 됐습니다.

 

 

보안 그룹에 대해서는 매우 안전해야 합니다. ELB쪾 어디에서나 HTTP HTTPS 트래픽을 열 수 있습니다. EC2 인스턴스 측면에서는 로드 밸런서로부터 오는 트래픽만 제한하고 ElastiCache 측면에서는 EC2 보안 그룹으로부터 오는 트래픽만 제안하려 합니다. RDS도 마찬가지 입니다. EC2 보안 그룹으로부터 오는 트래픽을 제안하기 웝합니다.