1. CDN이란?
- CDN 정의, 작동방식, etc
(Option) Edge 서버
CDN(Content Delivery Network) 이란?
- 콘텐츠 전송 네트워크
- 지리, 물리적으로 떨어진 사용자에게 컨텐츠(그래픽, 이미지, 동영상 파일 등)를 더욱 빠르게 제공할 수 있는 기술
- 세계 각지에서 한 국가의 서버로 접속할때 느린 응답속도와 다운로드 타임을 극복하기 위해 나온 분산 기술
- 컨텐츠 전달에 특화
- 본사 미국(예. 넷플릭스, 유투브 등등)로 부터 한국, 캐나다, 호주 등등 의 다른 나라에서 서버를 받아 온다면, 굉장히 속도가 느림!!!
- 오리진 서버로 부터 각 지역마다 캐시 서버를 두고 해당 컨텐츠 등을 실시간으로 공유하거나 타임별로 저장하고 , 컨텐츠를 본사에 요청할 경우 CDN을 통해서 해당 캐쉬 서버로 부터 응답을 준다
- 도매상 같은 역할
CDN 기술의 장점
- CDN 이 없다면 컨텐츠를 담고 있는 오리진 서버는 모든 앤드유저 들에게 트래픽 을 받게 되는데 그에 따라 엄청난 부하 유발함
- 사람들의 요청이 몰릴 경우, 장애 발생할 확률이 큼!!
- 그래서 CDN은 이런 본 서버를 대신해서 각 각의 앤드유저들에 각 각의 가까운 위치에 응답함으로 써 오리진 서버의 트래픽 부하를 나눠주고 앤드유저의 웹 경험을 개선시켜 준다
대신!
- 특정 국가나 지역만을 타깃으로 하는 웹 서비스를 운영한다면 CDN 서비스를 활용할 필요가 없다
- PC 나 모바일 사용자가 어떤 주소에 접근 하려고 할때, http 통신으로 css, 자바스크립트, 이미지 등의 컨텐츠 등을 서버로 부터 요청한다
- DNS서버가 받아서 요청된 사이트의 ip를 조회해서 CDN으로 요청한다
- 본사 전화번호가 아닌 체인점(CDN)의 전화번호를 적는다
- 로컬 CDN 중에서 적합한 CDN을 찾아서 앤드 유저를 맵핑하고 해당 서버는 요청된 캐싱 저장된 버전으로 응답을 준다
- 세계 각지에 있는 엣지(Edge)서버 들 중에서 클라이언트와 가장 빠르게 서비스를 제공할 수 있는 엣지를 선택
- 엣지 서버들의 꾸준한 헬스 체크를 통해 상태 좋은 엣지만 골라서 연결시켜주는 것임
- 세계 각지에 있는 엣지(Edge)서버 들 중에서 클라이언트와 가장 빠르게 서비스를 제공할 수 있는 엣지를 선택
- 만약 오래된 컨텐츠거나 부적합한 컨텐츠라면, CDN이 오리진 서버로 부터 캐쉬를 보내달라고 요청을 하고 CDN에 다시 저장해둔다
- 정적 캐싱 : 캐싱할 것을 미리 보낸다
- 예 ) 체인점들이 미리 본사에게 물건 받아온다
- 동적 캐싱 : 사용자가 요청을 보낼 때 마다 보낼 컨텐츠가 엣지에 있는지 먼저 확인하고
- 있으면 바로 사용자에게 보낸다(cache hit)
- 없으면 그 때 서버에 요청해서 받아온다 (cache miss)
- ex) 체인점들이 물건 없으면 본사로 물건 발주하는 것
- 정적 캐싱 : 캐싱할 것을 미리 보낸다
CDN 활용 사례
온라인 동영상 스트리밍 서비스를 제공하는 넷플릭스(Netflix)는 전 세계의 사용자들에게 안정적인 서비스를 제공하기 위해 2011년에 자체 CDN을 구축했습니다. 넷플릭스의 서비스 범위가 전 세계에 걸쳐 있고, 구독자의 절반 이상이 미국 외의 지역에 분포하고 있어 콘텐츠를 안정적이고 빠르게 세계 각지로 전달하기 위해서는 CDN 기술이 필수적이기 때문입니다.
이와 더불어 세계 최대 숙박 공유 서비스인 에어비앤비(Airbnb) 또한 CDN 기술을 활용해 전 세계 고객에게 언제 어디서나 숙박 시설과 각종 액티비티를 예약할 수 있는 서비스 환경을 구축했습니다.
국내에서는 NC소프트나 카카오게임즈 같은 온라인 게임 기업이 CDN을 활용, 북미나 유럽과 같이 지리적으로 먼 지역의 사용자에게 안정적이고 빠른 게임 플레이 환경을 제공하고 있습니다.
출처 :
https://www.youtube.com/watch?v=x0sEyNYAF_g
https://www.youtube.com/watch?v=_kcoeK0ITkQ
2. CORS 란?
- 정의, 대처방법, etc
교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)
SOP(Same Origin Policy)
- 다른 출처의 리소스를 사용하는 것을 제한 하는 보안 정책
- Protocol, host, port 세가지가 모두 같아야지 같은 출처임
- 해커는 사용자의 인증토큰(id, pw 등)을 가지고 페이스북 포스트 게시
- 페이스북 같은 경우에는 오리진 주소가 어디서 왔는지 먼저 확인함
- 만약 가지고 있던 출처와 다르다면, 다른 출처로 판단 -> cross origin
- 요청을 받아들일 수 없다고 return
- cors 가 다른 출처에 접근 가능 할 수 있도록 해줌
교차 출처 요청의 예시:
https://domain-a.com의 프론트엔드 JavaScript 코드가 XMLHttpRequest를 사용하여
https://domain-b.com/data.json을 요청하는 경우.
cors 접근 제어 시나리오
- 프리플라이트 요청(Preflight request)
- 사전 확인 작업 -> 요청 가능 or 요청 불가능 한지 서버한테 일단 물어봄
- 단순 요청 (simple request)
- 인증 정보 포함요청(Credential request)
cors 해결방법
- chrome 확장 프로그램 이용
- Allow CORS: Access-Control-Allow-Origin' 크롬 확장 프로그램을 설치
- 서버에서 Access-Control-Allow-Origin 세팅하기
//^ CORS 허용
res.setHeader('Access-Control-Allow-origin', '*');
res.setHeader('Access-Control-Allow-Credentials', 'true'); // 쿠키 주고받기 허용
- 남이 만든 프록시 서버 사용하기
- 클라이언트에서 외부 서버로 바로 요청을 해버리는 것이 아니라, 프록시 서버를 사용해서 우회한다
- 프록시 서버 : 클라이언트가 프록시 서버 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속하게 해줌 (중계서버)
- 요청해야 하는 url 앞에 프록시 서버 url 붙여서 요청
출처:
https://www.youtube.com/watch?v=bW31xiNB8Nc
https://www.youtube.com/watch?v=-2TgkKYmJt4
3.구성해봤던, 혹은 알고 있는 배포 인프라에 대해서 설명하기
ex) WAS로 장고, 웹서버로 엔진엑스 사용, + gunicorn 하고 배포는 AWS EC2 사용..
spring boot, jar, tomcat 내장서버 사용 maven 빌드 후 배포
일반적인 배포
기존에 연결된 서비스를 해제 하고 새로운 버전으로 갈아끼운 뒤 다시 서비스를 하는 방식이다.
무중단 배포
여러 기술들을 이용해서 배포되는 도중에 연결을 해제하지 않고 새로운 버전으로 갈아끼운 뒤 지속해서 서비스를 유지하는 것이다.
- Rolling Deployment
- Blue-Green Deployment
- Canary Deployment
- L4 Switch
1. Rolling Deployment
배포된 서버를 한 대씩 구버전에서 새 버전으로 교체하는 것이다.
- 로드밸런서는 배포된 서버에 연결을 일시적으로 끊는다.
- 연결이 끊어진 서버에 새롭게 업데이트된 서버를 교체한다.
- 교체가 완료되면 나머지 버전을 위와 같은 과정으로 업데이트 한다.
장점
인프라에 구성된 현재 자원을 그대로 유지하고 무중단 배포가 가능하다는 것이다.
단점
단점은 조금 치명적이다.
업데이트 도중에 서버를 필연적으로 끊어야 하기 때문에 서버 과부하가 생긴다.
그리고 롤백이 힘들다는 점이 있다.
문제가 생겨서 롤백을 해야한다면 위와 같은 과정을 또 거쳐야하기 때문에 절 효율적이지 못한다.
2. Blue-Green Deployment
Rolling Update의 단점을 보완할 수 있는 방법
- 서버를 그대로 본떠 하나의 새로운 서버를 만든다. (새로운 서버는 로드밸런서에 연결되어있지 않다.)
- 새로운 서버 전체를 업데이트한다.
- 기존 서버에 연결된 연결을 새로운 서버의 연결로 변경한다.
장점
서버의 과부하가 일어나지 않는다.
단점
비용적인 측면에서 제약이 생긴다.
클라우드 환경이나 Docker과 같은 가상환경이 더 어울린다.
출처 : https://wonit.tistory.com/m/330
'IT_study > 스터디' 카테고리의 다른 글
객체지향 설계 원칙, 트랜잭션 격리, 해쉬테이블 (0) | 2022.08.24 |
---|---|
공인ip, 사설ip, nat, 프록시서버, DHCP (1) | 2022.08.18 |
Rest api, 클러스터형 vs Non클러스터형, 가비지콜렉터 (0) | 2022.08.04 |
TCP vs UDP, 라우터 vs 스위치 (0) | 2022.07.28 |
가상메모리, Redis vs Memcached (0) | 2022.07.28 |