1. CDN이란?
컨텐츠 전달 이라는 용도에 특화.
Contents
Delivery
Network
데이터 사용량이 많은 애플리케이션의 웹 페이지 로드 속도를 높이는 상호 연결된 서버 네트워크입니다.
필요 배경
1. 물리적 거리
한국- 미국 - 중국 - 호주
한국에서는 빠르겠지만, 다른 나라는 느리겠다.
2. 다수의 요청
서버도 기계다 보니, 요청이 많으면 뻗는다.
그래서 요청을 여러군데에 분산 시킨다.
전체 기능을 복사해서 나라별로 배포를 하는 것이 아니다. : 미러 사이트
컨텐츠 전달 이라는 용도에 특화되어 있다.
서버 입장에서는 방문객 하나하나를 직접 대응하는 것이 아니라,
각 지역 담당 CDN 서버, 체인점이 커버를 쳐줘서 서버 부담이 줄어든다.
<도매인을 구매한 곳에서 설정을 한다>
DNS에서 본사 전화번호를 등록하는 대신
체인점을 총괄하는 부서, CDN의 전화번호를 적는다.
클라이언트에게 가장 빠르게 제공할 수 있는 edge를 선택해서 제공한다.
CDN의 필요성 (장점)
유튜브, 페이스북은 요청이 많이 들어온다.
1. 주서버 과부하 줄임, 비용 절감
그러면 서버에 요청이 많아질 수 록 돈이 많이 든다.
이에 정적인 것은 캐시를 만들어놔서 요청을 줄인다.
대역폭 비용 절감
들어오는 모든 웹 사이트 요청은 네트워크 대역폭을 사용하기 때문에 대역폭 비용이 상당히 높습니다. 캐싱 및 기타 최적화를 통해 CDN은 오리진 서버가 제공해야 하는 데이터의 양을 줄여 웹 사이트 소유자의 호스팅 비용을 절감할 수 있습니다.
2. 빠른 서비스 제공
가까운 거리의 서버에 캐시를 저장해서놔서 사용자가 빠르게 접속이 가능하다.
페이지 로드 시간 단축
페이지 로드 시간이 너무 느리면 웹 사이트 트래픽이 감소할 수 있습니다. CDN은 반송률을 줄이고 사용자가 사이트에서 보내는 시간을 늘릴 수 있습니다.
3. 보안
디도스 공격을 막아준다.
강력한 보안: 컨텐츠의 암호화 : 최신의 검증 인증 방식을 사용한다.
웹 사이트 보안 강화
분산 서비스 거부(DDoS) 공격은 대량의 가짜 트래픽을 웹 사이트로 전송하여 애플리케이션이 작동 중지되도록 만들려고 시도합니다. CDN은 여러 중간 서버 간에 로드를 분산하여 오리진 서버에 미치는 영향을 줄임으로써 이러한 트래픽 급증을 처리할 수 있습니다.
4. 콘텐츠 가용성 제고
한 번에 너무 많은 방문자가 방문하거나 네트워크 하드웨어 오류가 발생하면 웹 사이트가 중단될 수 있습니다. CDN 서비스는 더 많은 웹 트래픽을 처리하고 웹 서버의 로드를 줄일 수 있습니다. 또한 하나 이상의 CDN 서버가 오프라인으로 전환되면 다른 운영 서버가 해당 서버를 대체하여 서비스가 중단되지 않도록 할 수 있습니다.
CDN 전송 콘텐츠
콘텐츠 전송 네트워크(CDN)는 정적 콘텐츠와 동적 콘텐츠의 두 가지 유형의 콘텐츠를 전송할 수 있습니다.
1) 정적 콘텐츠
정적 콘텐츠는 사용자 간에 변경되지 않는 웹 사이트 데이터입니다.
웹 사이트 헤더 이미지, 로고 및 글꼴 스타일은 모든 사용자에게 동일하게 유지되며 기업이 자주 변경하지 않습니다.
정적 데이터는 수정, 처리 또는 생성할 필요가 없으며 CDN에 저장하는 데 이상적입니다.
2) 동적 콘텐츠
소셜 미디어 뉴스 피드, 날씨 보고서, 로그인 상태 및 채팅 메시지와 같은 동적 콘텐츠는 웹 사이트 사용자마다 다릅니다.
이 데이터는 사용자의 위치, 로그인 시간 또는 사용자 기본 설정에 따라 변경되며 웹 사이트는 모든 사용자와 모든 사용자 상호 작용에 대한 데이터를 생성해야 합니다.
캐싱 방법
정적 캐싱 | 캐싱할 것들을 미리 각 엣지에 보낸다 |
동적 캐싱 | 사용자가 요청을 보낼때마다 보낼 컨텐츠가 엣지에 있는지 먼저 확인한 후에 있으면: cache hit 바로 사용자에게 보낸다 없으면: cache miss 그때 서버 요청을 해서 받아온다 |
cdn 적용 방법
aws --> cloudFront
azure
- CDN 정의, 작동방식, etc
(Option) Edge 서버
참조 사이트:
https://aws.amazon.com/ko/what-is/cdn/
https://www.youtube.com/watch?v=_kcoeK0ITkQ
2. CORS 란?
- 정의, 대처방법, etc
CORS
교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는
추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제입니다.
웹 애플리케이션은 리소스가 자신의 출처(도메인, 프로토콜, 포트)와 다를 때 교차 출처 HTTP 요청을 실행합니다.
교차 출처 요청의 예시: https://domain-a.com의 프론트 엔드 JavaScript 코드가
XMLHttpRequest를 사용하여
https://domain-b.com/data.json을 요청하는 경우.
보안 상의 이유로, 브라우저는 스크립트에서 시작한 교차 출처 HTTP 요청을 제한합니다.
예를 들어, XMLHttpRequest와 Fetch API는 동일 출처 정책을 따릅니다.
즉, 이 API를 사용하는 웹 애플리케이션은 자신의 출처와 동일한 리소스만 불러올 수 있으며, 다른 출처의 리소스를 불러오려면 그 출처에서 올바른 CORS 헤더를 포함한 응답을 반환해야 합니다.
한 사이트에서 주소가 다른 서버로 요청을 보낼때 자주 접하는 오류이다.
주소가 착한토끼.com에서 url이 나쁜토끼.com으로
api로 정보를 받아오기 위해
착한토끼 프론트에서 http 요청을 보냈을 때
미리 어떤 설정을 해주지 않으면 cors문제로 막힌다
포스트맨이나 백엔드에서 돌리면 되는데 왜 웹사이트에서 오류가 나는가?
웹사이트에서 ajax요청을 보냈을 때 마다 안된다고 했잖아요
웹사이트를 여는 곳: 크롬, 엣지, 사파리
같은 브라우저에서 일어나는 문제이다.
네이버 지도 api 제공 서비스들이 내 크롬을 안믿는 것인가?
아니요.
크롬이 미토씨가 방문한 사이트를 못 믿는다.
내가 개발한 이 사이트를 못 믿어서,
거기서 네이버 api에다가 요청을 못보내게끔 크롬이 막고 있다.
착한토끼 -> 네이버 지도
cors 필요성
착한토끼 사이트
회원가입 후 로그인
다음에 접속했을 때, 아이디, 비번을 입력할 필요가 없도록 로그인이 유지되는 경우가 많다.
-> 쿠키, 세션, 캐시
내 브라우저에 토큰 정보가 쿠키로 저장되어있다.
로그인했던 사이트에(착한 토끼) 요청에 쿠키를 실어 보내면
착한토끼 서버에서 쿠키를 보고
내가 로그인이 돼있다 라고 판단해서 사이트를 보여줍니다.
----------------
나쁜토끼 사이트
쿠키에서 착한토끼 토큰을 이용하는
웹사이트를 만든다.
1. 나쁜토끼 닷컴에 접속하도록 유도한다
2. 나쁜 토끼 닷컴의 html, css, javascirpt가 내 크롬(브라우저)에 받아진다.
3. 나쁜토끼 닷컴에서 받아온 자바스크립트 코드로 내 크롬(브라우저)에게 무슨 일을 시킬지 모른다.
브라우저 쿠키에는 착한닷컴의 인증 토큰이 담겨있음 !!!
4. 착한닷컴으로 부터 미토가 개인정보를 조회하는 요청에
크롬에 저장된 미토씨의 착한닷컴 토큰을 실어서 착한닷컴에 보낸다음
탈취한 정보를 나쁜닷컴 서버로 보낼 수 있다.
=> 내 의지와 상관없이 착한닷컴의 나의 정보가 나쁜닷컴으로 내 개인 정보가 넘어갈 수 있다.
또 악의적인 행위를 할 수 있겠구나
브라우저와 서버에서 서로 허용을 해주지 않으면 오류가 발생한다.
서로 다른 출처끼리 요청을 주고 받는게 안되는게 기본 값이다
Cross Origin | Same-Origin |
다른 출처간의 리소스를 공유 할 수 있도록한다. 출처: 보내고- 받는 위치 웹사이트랑 api의 주소 리소스: 주고 받아지는 데이터 |
미친토끼에서 미친토끼한테 요청한다 언제나 가능하다 |
착한토끼--- > 네이버 지도 요청을 한다 브라우저는 헤더에 origin이라는 헤더를 추가한다 데이터가 다른 곳으로 전송될 때 데이터의 맨 앞에 붙는 보충 정보. 받는 쪽의 ip 주소, 사용할 프로토콜, 옵션 봉투: 봉투 바깥에 적힌 내용 헤더에는 요청하는 쪽의 scheme(요청할 자원의 접근 방법 http, ftp, telnet), 도메인, 포트 ---------> 네이버 지도 api 지정된 Access-control-Allow-Origin 정보를 실어서 보낸다 -----> 크롬이 요청과 응답을 비교해서 오리진에서 요청한것과 똑같은게 있으면 브라우저한테 데이터를 받을 수 있게 해주는거네요? 오리진에서 보낸 출처 값이 서버의 답장 헤더에 담긴 Access-control-Allow-Origin 에 있으면 안전한 요청으로 간주하고. 응답 데이터를 받아온다. 토큰(사용자 식별 정보) 요청에 대해서는 엄격하다 보내는 측에서는 credentials 항목을 true로 설정해야함 받는 쪽도 아무 출처나 다 된다고 와일드 카드로 할게 아니라 보내는 쪽의 출처 - 웹페이지 주소를 정확히 명시해야만 Access-control-Allow-credentials 항목을 true로 맞춰야한다. |
요청 방식 2가지
Simple request | Preflight request |
통과를 못하면 답장만 못 받음 | Preflight 요청이란 걸 먼저 보내서 본 요청이 안전한지 체크하고 승인되어야 삭제, 수정이 가능하다 요청을 보내는 것도 허락을 받아야 요청할 수 있음 |
get, post | delete, push |
웹 생태계가 다양해지면서 여러서비스 간에 자유롭게 데이터를 주고 받을 필요성이 생김
다른 사이트 간의 요청들을 브라우저가 막고 있으니까
개발자들은 jsonp등의 방식으로 우회하는 꼼수들을 사용하기 시작했다.
그래서 이걸 합의된 출처들간에 합법적으로 허용해주기 위해
어떤 기준을 충족시키려면 리소스 공유가 되도록 만들어진 메커니즘이 cors
교차 출처 자원 공유 방식이다.
cors 허용해주는 방법
요청을 받는 백엔드 쪽에서 이걸 허락할 다른 출처들을 미리 명시해 두면 된다.
프레임워크들 스프링, 장고, express등의 문서를 살펴보면
cors 옵션을 넣는 방법들을 쉽게 마련되어 있습니다.
허용할 사이트: 미친토끼, 착한토끼
이제 지정한 사이트에서는 이 서버로 얼마든지
http요청을 보낼 수가 있다.
아무나 보내도 되는 요청의 경우
일반적인 방법으로 와일드카드(*)를 적어넣으면 누구나 쓸 수 있게 된다.
당연히 나쁜토끼는 지정한 사이트에 안들어가 있을테니 막히겠죠.
네이버 지도 api등의 서비스들도 콘솔에 들어가보면
cors를 허용해줄 주소들을 지정하는 페이지를 찾을 수 있다.
참고 사이트:
https://www.youtube.com/watch?v=bW31xiNB8Nc
https://developer.mozilla.org/ko/docs/Web/HTTP/CORS
3. 구성해봤던, 혹은 알고 있는 배포 인프라에 대해서 설명하기
ex) WAS로 장고, 웹서버로 엔진엑스 사용, + gunicorn 하고 배포는 AWS EC2 사용..
저는 maven 으로 jar 파일을(내장톰캣) 만들었습니다.
그리고 jar 파일을 ec2서버에 올려서 파일을 실행시켰습니다.
웹서버는 톰캣을 사용했습니다.
방법
1. spring boot 에서 jar 파일을 만든다
1) 툴 사용
Run As -> Maven build
2) 명령어
mvn package (or mvn package -DskipTests)
참고: https://jhleeeme.github.io/create-jar-with-maven-in-vscode/
2. 서버에 jar 파일을 옮긴다
3. java -jar 파일명.jar 실행
nohup $JAVA_HOME/bin/java $JAVA_OPTIONS $JAVA_CUSTOMS $GC_OPTIONS -jar $FULL_PATH/lib/$PKG_BIN.jar --spring.config.location=file:$FULL_PATH/conf/config.properties --logging.config=file:$FULL_PATH/conf/logback.xml >> $FULL_PATH/logs/nohup.out 2>&1 &
$JAVA_HOME 은 설정변수라
echo로 값을 확인 할 수 있다.
war, jar 차이
https://hye0-log.tistory.com/27
https://jeongkyun-it.tistory.com/126
컴파일
작성한 코드를 바이너리 코드로 변환 하는 과정
빌드
소스 코드를 실행 가능한 독립적인 소프트웨어 산출물로 만드는 과정
빌드 도구
소스 코드를 컴파일, 테스트, 정적 분석을 실시하 여 실행 가능한 애플리케이션으로 자동 생성하는 프로그램
계속해서 늘어나는 라이브러리의 자동 추가 및 관리
라이브러리 버전을 자동으로 동기화
배포
작성한 코드를 빌드 --> 빌드가 완성된 실행가능한 파일을 --> 사용자가 접근 할 수 있는 환경에 배치 ---> 배포 완료
빌드 --> war or jar --> WAS에 올리면 완료