본문 바로가기

AWS Design Pattern

 (46)
WRITE PROXY - 인터넷 스토리지로 고속 업로드 ㅁ 풀어야 할 문제 인터넷 스토리지는 일반적으로 읽기에 대한 수용 능력 및 데이터 안정성이 매우 뛰어나다. 그러나 이중화를 위해 여러 지역에 쓰기가 이루어지고 있고 HTTP 프로토콜로 클라이언트와 통신하므로 비교적 쓰기 속도가 느린 특성이 있다. 따라서, 큰 데이터를 인터넷 스토리지에 쓰는 경우 성능이 문제가 될 수 있다. ㅁ 해결/패턴 클라이언트에서 인터넷 스토리지에 직접 데이터를 전송하는 것이 아니고, 가상 서버로 데이터를 받아 그 가상 서버로부터 인터넷 스토리지로 전송함 클라이언트에서 가상 서버로의 전송은 HTTP보다 빠른 프로토콜(예를 들어, UDP 기반의 프로토콜)을 이용할 수 있다. 또, 작은 용량의 파일이 많을 경우 클라이언트 쪽에서 한번 압축하여 가상 서버로 전송 후 압출을 풀어 인터넷 스..
Private Cache Distribution - CDN을 이용한 프라이빗 배포 ㅁ 풀어야 할 문제 전 세계 캐시 지역을 활용한 콘텐츠 딜리버리 서비스를 이용하면, 전 세계에 있는 사용자에게 빠르게 데이터 배포 가능하다. 그러나 특정 사용자에게만 콘텐츠를 배포할 때는 사용자 인증이 필요하고 인증 구조를 만들기는 쉽지 않다. ㅁ 해결/패턴 콘텐츠 딜리버리로 제공되는 [서명을 포함한 URL 인증 기능]을 이용하는 방법이 있다. 사용자가 콘텐츠를 다운로드하기 위해 웹 사이에 액세스할 때, 미리 설정해둔 액세스 위치 IP Address, 다운로드 가능 기간, 액세스 위치의 지역 등이 맞는 경우에만 서명을 포함한 URL 인증 기능을 발급하면 된다. 보다 정확하게 특정 사용자에게 배포가 가능한다. ㅁ 구현 - 콘텐츠 딜리버리 서비스인 CloudFront의 apitool이나 AWS SDK를 준비..
Rename Distribution - 변경 지연 없는 배포 ㅁ 풀어야 할 문제 - Cache Distribution 패턴을 사용해 콘텐츠를 배포하는 경우, 마스터 서버의 파일을 변경해도 에지 서버(캐시 서버)의 데이터는 타임 아웃이 될 때까지 갱신되지 않음 - 원하는 타이밍에 파일을 갱신하려고 할 때에는 사용 불가 ㅁ 해결/패턴 - 에지 서버의 캐시 데이터는 그 쪽에 액세스하는 URL이 키가 됨 - 갱신하려고 하는 파일을 다른 파일명으로 배치하고 액세스 URL 자체를 변경하면, 에지 서버의 캐시 타임 아웃에 상관없이 새로운 콘텐츠 배포 가능 ㅁ 구현 - 콘텐츠와는 별도로 기본 콘텐츠(액세스 URL을 포함한 HTML 파일 등)를 만든다. - 기본 콘텐츠는 캐시 타임아웃을 짧게 하거나 계속 마스터 서버에서 배포 - CloudFront로 배포하는 콘텐츠를 갱신하는 경..
Cache Distribution - 사용자와 물리적으로 가까운 위치에 데이터 배치 ㅁ 풀어야 할 문제 - 컴퓨터나 모바일 장치의 보급에 따라 더 많은 사람이 더 많은 지역에서 인터넷 상의 콘텐츠에 액세스하게 됨 - 또 이미지나 동영상 데이터는 품질이 좋아져 데이터 양도 굉장히 많아지고 있음 - 사용자 경험(User Experience) 관점에서 보면, 보다 빠르고 안정적으로 데이터를 이용자에게 제공하고 싶어하지만 현재의 기술로는 어느 정도 통신 지연이 발생 - 이런 이유로 콘텐츠 배포 장소가 한 곳 밖에 없다면 사용자 경험이 나빠짐 ㅁ 해결/패턴 - 세계 각지에 있는 지역에 콘텐츠 배포 장소(origin)에서 배포되는 콘텐츠 캐시 데이터를 배치 - 이렇게 하여 지리적으로 이용자와 더 가까운 지역에서 콘텐츠를 배포하게 되고, 지리적/물리적 제약 해결 가능 - 이 패턴을 적용하면 사용자와..
Private Distribution - 특정 사용자에게 데이터 배포 ㅁ 풀어야 할 문제 인터넷 스토리지는 가용성과 안정성이 높고 사이즈가 큰 콘텐츠나 액세스 수가 많은 콘텐츠를 배포하는데 적당하다. 그러나 특정 사용자에게만 콘텐츠를 배포하는 경우, 애플리케이션의 인증 부분과 연동이 필요해 인터넷 스토리지만으로 액세스를 제한하는 것은 어렵다. ㅁ 해결/패턴 인터넷 스토리지에서 제공되는 접근 제한 URL 발급 기능을 이용하면, 콘텐츠로 액세스하는 IP 어드레스 및 액세스 기간을 설정할 수 있다. 사용자 별로 URL을 발급하고 접근 제한 URL에서만 콘텐츠 다운로드가 가능하게 하면, 만료된 링크나 다른 IP 어드레스를 가진 사용자가 접근한다고 해도 다운로드가 불가능 실질적으로 특정 사용자만 접근이 가능하게 한다. ㅁ 구현 - S3의 apitool이나 AWS SDK를 준비 - ..
Direct Hosting - 인터넷 스토리지 직접 호스팅 ㅁ 풀어야 할 문제 단기간 액세스가 급격이 늘어날 경우 상황에 맞춰 서버 증설이 어려움 거기에 대응하기 위해 액세스 양을 예측하여 많은 서버를 준비하는 방법도 있지만, 불필요하게 서버를 준비해 두면 비용 측면에서 문제가 발생 ㅁ 해결/패턴 이 패턴은 클라우드가 제공하는 인터넷 스토리지를 웹 서버로 이용하여 이미지나 동영상 등 큰 용량의 정적 파일이나 HTML 등을 호스팅 함 인터넷 스토리지는 원래 공유 스토리지로 사용하게 설계되어 있어 용량에 문제 없으며 특정 서비스의 액세스 수가 급격히 증가해도 인터넷 스토리지에서는 문제 없이 처리가 가능하여 부하 대책을 고려할 필요가 없다. ㅁ 구현 - 인터넷 스토리지 S3에 공개할 정적 콘텐츠(HTML/CSS/자바스크립트/이미지/동영상 등)를 업로드함. - S3 버..
WEB Storage 패턴 - 고가용성의 인터넷 스토리지 활용 ㅁ 풀어야 할 문제 동영상이나 고화질 이미지, Zip 파일 등 용량이 큰 파일을 한대의 웹 서버에서 배포할 때 네트워크 문제가 발생됨 그럴 때 네트워크 부하를 줄이기 위해 여러 대의 웹 서버로 부하를 분산하는 경우가 있지만 그 경우 비용이 문제됨 ㅁ 해결/패턴 대용량 파일을 인터넷 스토리지에 저장하고 거기서 직접 파일을 배포하면, 웹 서버의 네트워크 부하와 디스크 용량 문제 해결 인터넷 스토리지에 저장된 객체는 공개 설정하여 사용자가 직접 액세스 가능 이것을 이용하여 인터넷 스토리지에서 배포하도록 하면, 웹 서버 네트워크 분산을 줄일 수 있고 배포 파일을 동기화하기 위하여 가상 서버간 데이터를 복사할 필요가 없어짐 ㅁ 구현 배포할 콘텐츠를 S3에 저장하고 사용자가 직접 S3에서 다운로드 가능하도록 함 -..
Schedule Scale Out - 스케줄에 의한 서버 증감 ㅁ 풀어야 할 문제 클라우드 환경에서 구축된 웹 서비스는 많은 트래픽 처리를 할 때 Scale Out 패턴이 효과적 그러나 부하 상태를 보고 수동으로 가상 서버를 추가하거나 가상 서버의 부하 상태에 따라 자동으로 인스턴스를 추가하거나 할 경우, 급격하게 많은 액세스 발생 시 상황에 맞춰 인스턴스를 가동하지 못할 수 있음. ㅁ 해결/패턴 순간적으로 액세스가 급증하는 타이밍을 알 경우 스케줄링 된 스케일 아웃이 효과적 Scale Out 패턴과 기본 구성은 비슷하나, 스케일 아웃하는 타이밍을 시간 지정하여 실행하는 것이 주요 특징 사전에 스케일 아웃을 완료하는 것으로 트래픽 급증에 만전의 태세로 대응할 수 있으며 직전에 스케줄링이 실행되어 불필요한 비용을 줄일 수 있다. ㅁ 구현 AWS의 AutoScaling..

티스토리툴바