- CDN - LB 두가지 배포 분기
- Docker
프로세스와 쓰레드
프로세스가 하나의 컴퓨터로 생각한다면, 쓰레드는 그 컴퓨터에서 돌아가는 하나의 프로그램이다.
리눅스 command pipe (
|)이 파이프는 명령어를 연결하는 역할을 하는데, 파이프의 왼쪽에 있는 명령어의 결과를 바탕으로 오른쪽 명령어를 실행할 수 있는 특징을 가지고 있다.
ps -ef | grep node
프로세스를 띄우는데, 그 중에 노드가 있습니까? 를 의미한다.
cat test.txt | grep 1234
test.txt 파일을 라인별로 출력시키는데 거기에 1234란 문자열이 들어간 라인만 출력해라.파이프 사용 개수에는 제한이 없다.
이전 명령어의 반환값을 필터링/가공 하는 데 많이 사용하기 때문에 awk, cut, grep, more 등과 같이 조합해서 사용한다.
CDN, LB 분기
이전까지는 클라우드 스토리지를 이용한 정적 페이지 배포와 로드 밸런서를 통한 동적 페이지 배포까지 알아봤었다.
오늘은 CDN과 LB 사이의 분기에 대해 알아보자.
정확히 무슨 말이냐하면
사용자가 정적 페이지로 갈 경우 - CDN에서 정적 페이지로 사용자를 보내고
동적 페이지로 갈 경우 - 로드 밸런서로 보내는 분기이다.
이전에 나는 CDN에 SSL을 설치해놨기 때문에 CDN을 거치기만 하면 Secure가 적용된다. CDN에서 다른 곳으로(
Cloud Storage, Load Balancer)갈 때는 http로 가도 이전에 CDN에서 HTTPS로 검증을 한 번 거쳤기 때문에 괜찮다. 만약 모든 경로 마다 HTTPS를 적용시키고 싶다면 전부 SSL을 설치해줘야 한다. 하지만 이러면 경로가 길어질 수록 검증을 더 많이 하게 되고 속도 저하가 발생한다. 결론은, 상황에 따라 다르다 보안이 매우 중요한 곳이라면 경로마다 SSL을 설치해줄 수도 있고, 그런 게 아니면 보통 분기점인 CDN에만 설치해서 통합적으로 한 번 검증해줄 수도 있다.
먼저, 클라우드의 CDN 페이지로 와서 CDN의 작동 방식을 조작해줘야한다. 이 행동 조작을 함으로써 받는 주소에 따라 어디로(LB, Storage) 갈 지 정할 수 있다.
AWS 같은 경우 CloudFront 페이지에서 보내려는 곳을 origin에서 추가해주면 된다.
추가를 한 뒤에, CloudFront 작동 방식 조작 부분인 Behaviors를 건드려준다. Path pattern에 여기로 접속하게 되면(나의 경우 boards/[동적id]가 오기 때문에 /boards/* 로 뒤의 모든 값들을 의미하는 *을 사용해서 주소를 적어줬다) 에 해당하는 주소를 적고 Origin and origin groups에 로드밸런서? Cloud Storage? 여기로 보내주세요에 해당하는 주소를 선택하면 된다. 적은 뒤, 밑의 Viwer 칸에 HTTP로 들어오는 연결을 HTTPS로 리다이렉트 시켜주자. SSL 설치까지 했는데 이걸 안 쓰는 건 말도 안된다.
그 뒤 invalidation 작업이 조금 필요했는데, invalidation은 아래 작은 글귀로 적힌 설명을 보면 알겠지만, 내가 적은 주소에 해당하는 페이지들의 캐시를 무효화시킨다. 지금 나의 경우, 테스트용이기 때문에 모든 페이지 주소를 뜻하는 /*를 기입하고 만들어줬다.
테스트 할 땐 계속 터미널을 연결시켰다가 끊는 걸 반복해야하는데, 브라우저 캐시나 쿠키로 인해 접속이 안되어야 하는데 접속이 될 때가 많아서 쿠키나 캐시에 관련된 테스트를 할 때가 아니면 항상 시크릿 모드를 사용하자.
여기까지 하면, 동적 페이지 또한 404가 나오지 않고 페이지가 나온다. 그런데 정상적으로 나오지 않는다.
분명 접속까지는 되는데, 주소 boards/뒤에 붙은 aaa가 게시글 아이디로 나와야하는데 빈값으로 나온다.
브라우저 렌더링 원리
- HTML 코드를 받아온다.
- src, href 를 통해 링크들을 받아와서 css, js를 받아온다.
이 src, href 주소들 앞에 나의 도메인 주소가 붙어서 요청을 보내는데, 지금 나는 도메인 주소/boards/*만을 로드 밸런서로 보내고 있다. 근데 앞서 말한 주소들은 나의 도메인 주소 바로 뒤에 붙기 때문에 로드 밸런서로 가지 않고 Cloud Storage로 간다.
이게 정적 페이지를 불러올 땐 문제가 없는데 동적 페이지를 불러올 때 문제가 생긴다. 동적 페이지에 접속했을 때 첫 렌더링을 하면서 src, href 링크를 통해 api 요청을 보내는데 이 요청들은 처음에 내가 접속한 주소인 /boards 가 앞에 붙지 않는다. 도메인 주소 바로 뒤에 붙기 때문에 로드 밸런서로 가지 않고 CloudStoage로 간다. 이게 왜 문제가 되냐면, CloudStorage와 로드 밸런서가 가지는 buildId 폴더가 있는데, 이 두 id는 다른값을 가지기 때문에 api 요청이 거부된다.
이걸 고치는 방법에는 두 가지가 있는데,
- CDN 분기점에서 작업을 해준다. (복잡함)
- config 파일에서 빌드 아이디를 고정시켜준다. (간편함)
2번 방법이 간편하기 때문에 이걸로 일단 해보자.
config.js 파일에서 다음과 같이 써준다.
그 다음 yarn build와 yarn build:ssg를 해서 .next와 out 폴더를 갱신해준다.
그럼 다음과 같이 buildId가 통일된 것을 확인할 수 있다. 통일된 것을 확인하면 git add commit push 해준다.
이 이후에 out을 다시 빌드했기 때문에 S3에 들어가서 이전 objects들을 전부 지우고 out 폴더 내부의 새로운 파일들을 전부 업로드해준다.
그 뒤 ec2 터미널에서 git pull로 push한 것을 받아온 뒤, yarn build로 빌드해주고 동적 페이지로 접속하면 정상적으로 나오는 것을 볼 수 있다.
Docker
과거
윈도우로 개발하는 개발자와 맥으로 개발하는 개발자 이렇게 두 명이 있었다. 여기에 신입이 들어왔는데 신입은 리눅스로 개발하고 있는 사람이었다. 신입에게 사수가 환경 설정에 관한 설치 파일 리스트를 건네줬고 신입은 그대로 설치를 완료했다. 그런데 작동을 안한다. 문제가 뭘까? 신입이 유일하게 다른 사람들과 달랐던 건 운영체제였다.
이렇게 과거에는 운영체제에 따라 환경이 달라져서 협업을 못하는 것이 이슈였다.
이를 바탕으로 나온 것이 Virtual Machine Ware :VMWare이다. 자신의 컴퓨터 안에 운영체제와 버전을 선택해서 가상 환경을 만드는 것이다. 이렇게 하면, 가지고 있는 기기의 운영체제가 달라도 같은 환경에서 협업할 수 있게 된다.
이것도 문제가 있다.
기기 안에서 가상의 컴퓨터를 작동시키는 것이라 많이 무겁다. 그래서 성능이 좋지 않다. 그리고 운영체제를 매번 설치하고, 환경 설정을 매번 해줘야해서 시간이 오래 걸린다.
이를 배경으로 나온 것이 도커이다. 도커는 기기 안에 가상 머신을 설치하는 개념은 똑같지만, 기존 기기 안의 운영체제와 가상 머신의 운영체제 사이의 공통되는 핵심 기능은 공유를 할 수 있기 때문에 OS 전체를 새로 설치하지 않아도 되었다. 이로써 훨씬 가볍고 빨라졌다.
리눅스에서 리눅스 VM 과 기능 공유는 뭐 같은 운영체제니까 말할 것도 없고, 맥에서 리눅스 VM 과의 기능 공유는 같은 부모를 가진 운영체제니까 기능 공유가 가능할 것 같다. 그런데 윈도우와 리눅스는 너무 다른 운영체제이기 때문에 애초에 도커가 실행되지 않는다. 그래서 윈도우는 WSL2(Window Subsystem for Linux)를 사용해서 도커를 실행시킨다.
그리고 도커의 장점이 또 있다. 도커는 같은 환경을 위해 설치해야하는 파일들을 미리 설치해놓을 수 있는 도커 파일이란 개념이 있는데, 미리 만들어 놓을 수 있다는 것은 만들어놓고 공유가 가능하다는 뜻이다. OS를 다루는 NPM이라고 보면 된다.
정리하자면, 도커는 다음과 같은 이점이 있다.
- 개발/배포 환경 통일이 가능하다.
- 프로그램 미리 설치가 가능하다.
- 이전 VM보다 훨씬 가볍다.
