배포
서버 : 컴퓨터
IP 주소 : 인터넷 상에서 내 컴퓨터, 우편주소, 숫자로 생긴다.
프로그램 : 컴퓨터가 실행하도록 프로그래밍 언어로 작성된 수열 또는 명령어 세트이다.
프로세스 : 실행되는 프로그램
DNS : 숫자가 어려워 알기쉽게 알려주는 시스템
포트번호 : 각 프로그램을 구분해주는 번호 / IP주소는 건물 위치, 포트번호는 건물의 호수(특정 방)
localhost : 특별히 약속된 도메인 이름 == 나
웹의 시작 : 문서 공유 시스템, 이때의 서버는 HTML 파일이 어딘가에 저장되어 있고, 사용자가 브라우저에 주소를 입력하면 서버는 그 주소에 해당하는 파일을 준다.
요청 : 버튼(URL) 입력 -> 서버가 요청을 처리 -> 응답 : HTML 파일을 준다.
요청 : 없는 버튼(URL) 입력 -> 서버가 버튼을 찾지 못함 : 404 Not Found
URL = 버튼 / 요청을 받아서 제공해주는게 웹서버 = 자판기 / HTML 파일 = 음료
아파치 : 요청이 들어오면 파일을 준다.(안정적으로) 이정도면 충분했었지만, 동적 웹이 등장하면서 문제가 생겼다. 서버가 HTML을 만들어줘야하는데 파일은 이게 불가능 하기때문이다. 이래서 나온게 그 자리에서 HTML을 만들어 주는 것.
처음엔 CGI를 만들어줬다 > 요청이 들어오면 외부 프로그램을 실행해서 HTML을 만들었다. > 요청마다 프로그램을 새로 실행. 그래서 느리고 무겁다. > 그리고 PHP가 등장한다.
PHP는 HTML에 프로그래밍 코드를 섞어서 쓸 수 있도록. 서버가 PHP파일을 읽으면 코드 부분은 실행하고 그 결과를 HTML 파일로 바꾼다. 그리고 브라우저로 보낸다.
DB에서 데이터를 꺼내고 로그인 정보를 확인하고 그걸 토대로 HTML을 조립해서 내보냄.
웹서버 : HTML,CSS,JS 정적인 파일을 그대로 돌려주는 역할
WAS : 내가 짠 코드를 실제로 실행해주는 역할 / WAS는 각 언어의 런타임을 포함해서 코드 실행 전반을 담당한다.
아파치는 요청이 1개 들어올 때마다 프로그램을 1개 실행한다. 요청이 1K개 들어오면 1K개의 요청을 처리하기 위한 프로세스 또는 스레드를 생성한다. 컴퓨터의 메모리는 유한하다. 프로세스 하나가 메모리를 일정부분 차지하는데 이게 양이 많아지면 서버가 다운된다.
C10K 문제 발생 : 동시에 10K개의 요청(접속)을 어떻게 처리하나?
스레드 : 일반적으로 운영체제의 일부인 스케줄러가 독립적을 관리할 수 있는 가장 작은 프로그래밍된 명령이 시퀀스이다.
Ngnix 등장 : C10K를 해결하기 위한 웹서버. 요청마다 프로세스를 만들지 말고 하나의 프로세스가 여러 요청을 같이 처리하게 함 > 이벤트 기반 아키텍처 > 적은 메모리로 많은 동접을 처리할 수 있음
리버스 프록시 : 앞에서 요청을 받고, 뒤에 있는 서버로 연결해주는 역할 > Ngnix는 이런것도 한다.
Nginx가 받고 WAS가 코드를 실행한다. 그 결과가 돌아오는 구조
실제로 서비스가 돌아가는건 아님. 내가 짠 코드가 인터넷상의 어떤 서버에 올라가 있어야 전세계 사람들이 접속할 수 있음. 이 과정을 배포라고 한다.
배포 : 내 컴퓨터에서 짠 코드를 서버 컴퓨터에 올려서 인터넷에 있는 누구나 쓸 수 있게 만드는거
FTP(File Transfer Protocol) : 로컬 파일을 드래그해서 서버 파일 목록으로 복사
클라이언트 : 서비스를 요청하는 쪽
서버 : 서비스를 제공하는 쪽
git : 내 컴퓨터에서 코드 히스토리, 버전 관리
github : 코드를 클라우드에 업로드, 백업, 공유
Docker : 코드 + 환경 > 컨테이너로 해결
배포 자동화 개념 : CI/CD
CI : Continuos Inbtergration 지속적 통합
- 개발자가 작성한 코드를 공유 리포지토리에 자주 병합합니다.
- 코드를 합칠 때마다 자동으로 빌드와 테스트를 수행합니다.
- 오류를 빠르게 발견해 코드 충돌과 품질 저하를 막습니다
CD : Continuous Delivery / Deployment 지속적 제공 / 배포
- 지속적 제공(Delivery): 테스트를 마친 코드를 운영 환경 직전 단계까지 자동으로 전달합니다.
- 지속적 배포(Deployment): 최종 승인 과정까지 자동화해 실제 사용자 환경(Production)에 곧바로 반영합니다.
코드 저장 > 자동으로 테스트 > 자동으로 빌드 > 자동으로 배포해주는게 가장 이상적인 과정
Github Action :
코드 수정 > push > Github Actions 실행 > 테스트 > Docker Image 빌드 > 서버 배포 > 재시작
만약에 중간에 문제가 있다면 생기면 멈추고 어디서 뭐가 잘못됐는지 알려줌.
CI/CD가 보편화
클라우드 배포 플랫폼 : AWS, GCP, Azure > Iaas : Infrastruct as a Sercive 인프라를 서비스로, 버튼 클릭으로 서버 생성 가능
배포 플랫폼 : Vercel,Netlify, Raliway, Render > 배포를 극단적으로 단순화
과정이 단순해질도록 내가 제어할 수 있는 부분이 줄어든다.
vercel은 편하지만 정밀한 설정이 안되고 AWS는 복잡하지만 미세한 컨트롤이 가능하다 > 상황과 규모와 비용 고려해서 선택
A레코드 : 도메인을 IPv4 주소로 연결 : myApp.com > 202.0.111.12
CNAME : 도메인 별명을 다른 도메인으로 연결 > www,myApp.com > myApp.com
MX : 메일 서버
TXT : 문자열 정보 저장, 인증
NS : 도메인 관리하는 네임서버 지정
설정했는데 안들어가질때는 기다리면 된다
DNS 서버가 전세계에 많다. 여기에 캐시로 저장되어있는데 이게 전부 업데이트 되야한다
갱신하면 모두 업데이트 되야하는데 이 과정을 디엔스 전파 propagation 라고 함
패킷 스니핑 > 중간에서 패킷을 훔쳐보기 / 보통 공용 WI-FI에서 / 비밀번호가 평문으로 다 보임 > 보안 사고
SSL > TLS : SSR이 시작, TLS가 현재 표준 / 데이터를 암호화해서 주고받는 방식
HTTPS : HTTP(통신 규칙) + TLS(보안 계층) > 안전한 웹 통신 --> 브라우저의 자물쇠 아이콘
암호화만으로는 완전하지 않다. 내가 접속한 서버가 찐인지 아닌지 확인 해야함 / 피싱사이트
- 코드가 사용자에게 도달하기까지
개발자(코드작성) > git commit(변경사항 기록) > github push(원격저장소에 업로드) > CI/CD(자동 파이프라인) > Docker 이미지 빌드 > 서버 배포(릴리즈) > Nginx + WAS (사용자의 요청 처리) > 로드 밸런서 (트랙픽 분산) > 사용자(접속)
- 도메인 입력부터 화면 표시까지
브라우저(도메인 입력) > DNS 조회(IP 찾기) > TLS 핸드셰이크 (HTTPS 연결) > 로드 밸런서 (트래피 분산) > Nginx(프록시) > WAS(비즈니스 로직)
