본문 바로가기

분류 전체보기

 (345)
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..
Cache Proxy - 캐시 설치 ㅁ 풀어야 할 문제 높은 부하에 대한 대책으로 웹/AP 서버를 여러 대 사용하면 비용 부담이 많아짐 예산이 적을 경우 웹/AP 서버 수를 늘리지 않는 방법을 생각해야 함 ㅁ 해결/패턴 웹 시스템 성능을 높이는 대표적인 방법은 콘텐츠를 캐시화하는 방법이 있다. 이 방법은 변경이 많이 없는 정적 콘텐츠나 동적 콘텐츠를 웹/AP 서버 상위에서 캐시하여 캐시 기간이 끝날 때까지 배포 성능이 좋은 상위 캐시 서버로 콘텐츠 배포를 하는 방법 클라우드에서는 가상 서버를 쉽게 구축할 수 있어 캐시 서버가 없는 시스템에도 간단하게 도입이 가능 ㅁ 구현 EC2에 Varnish 등 많이 사용되는 캐시 서버 소프트웨어를 사용하여 캐시 서버로 사용 - 웹/AP 서버 앞에 Varnish 등의 캐시 서버 소프트웨어를 둠 - 캐시 ..
Rewrite Proxy - URL 변경 Proxy 설치 ㅁ 풀어야 할 문제 부하 대책의 하나로 정적 콘텐츠를 인터넷 스토리지나 콘텐츠 딜리버리 서비스에 올려두는 방법이 있다. 그러나 정적 콘텐츠 액세스 위치를 인터넷 스토리지로 변경해야 하고 컨텐츠 내의 URL 갱신이나 웹 서버 필터 설정 등 기존 시스템을 변경해야 함 ㅁ 해결/패턴 기존 시스템을 변경 없이 액세스 위치를 바꾸는 방법으로 프락시 서버를 사용하는 방법이 있다. 콘텐츠를 저장하고 있는 서버 앞에 프락시 서버를 두고, 정적 콘텐츠의 액세스 위치를 인터넷 스토리지나 콘텐츠 딜리버리 서비스로 변경 한다. ㅁ 구현 아파치나 Nginx 등 많이 사용되는 소프트웨어를 사용하여 프락시 서버를 구축하고 기존 시스템 앞 단에 설치한다. - ELB와 (정적 콘텐츠를 저장한) S3 사이에 Nginx 등 컨텐츠 내용을..
URL Rewriting - 정적 콘텐츠 이전 ㅁ 풀어야 할 문제 웹 서비스를 가상 서버로 제공하는 경우, 액세스 수가 많아지면 가상 서버의 수를 늘리거나 가상 서버의 사양을 올려 부하에 대응 그러나 액세스의 대부분은 정적 콘텐츠에 대한 요청이 많아 정적 컨텐츠의 액세스를 어떻게 분산시킬 것인지가 큰 문제이다. ㅁ 해결/패턴 정적 콘텐츠의 액세스 분산 방법으로 인터넷 스토리지를 이용하는 방법이 있다. 그렇게 하면 가상 서버를 증가시키거나 사양을 높이지 않아도 부하에 대한 대책을 세울 수 있다. 이 방법을 이용하려면 정적 콘텐츠의 URL을 인터넷 스토리지 URL로 변경해야 하지만 정적 콘텐츠를 직접 수정하는 방법 외에 웹 서버의 필터 기능을 이용해 배포 시 URL을 변경할 수 있다. 또 인터넷 스토리지에서 배포하는 대신 콘텐츠 배포 서버에서 콘텐츠를 ..
State Sharing - 상태 정보 공유 ㅁ 풀어야 할 문제 동적 콘텐츠를 생성할 때 사용자 고유의 상태를 가진 상태 정보(HTTP 세션 정보)를 이용하는 일이 많다. 그러나 로드 밸런서 아래 여러 대의 웹/AP 서버를 동작시킬 때 각 웹/AP 서버에 상태 정보를 가지도록 하면, 서버 장애나 서버 수를 의도적으로 줄일 때 상태 정보에 손실이 발생하는 경우가 있다. ㅁ 해결/패턴 이 패턴은 스케일 아웃 구성에서 상태 정보를 유지하기 위한 것으로 서버를 늘렸을 경우는 상태 정보 유지, 서버가 줄었을 경우는 (장애 포함) 상태 정보 손실을 방지 상태 정보를 안정성 좋은 공유 디스크 스토어(메모리/디스크)에 놓고 여러 대의 서버에서 그 정보를 참조하여 서버에 상태 정보를 가지지 않고 상태 정보 보유가 가능하다 새로운 서버가 추가되어도 공유 데이터 스토..

티스토리툴바