[23.03.01] 스터디 복습(배포,cors,BFF 등)

스터디한 내용들이 거의 처음이고, 어려워서 정리를 해두려고 한다.

스터디를 하면서 느낀게 알아도 알고 있는게 아니고, 말로 설명하는 것은 더더욱 어렵다는 것이다. (연습만이 살길!)

 

1. server
2. 배포
3. git remote에서 origin
4. BFF(Backend for Frontend)
5. cors(Cross-Origin Resource Sharing)
6. preflight
7. ssh

 

 

 

 

server란?

---

누가 서버에 대해 물으면 나는 이제 이렇게 대답할 수 있다.

서버는 요청이 오면 응답하는 것입니다. 

 

서버는 클라이언트(웹 브라우저)에게 여러 가지 서비스를 제공하는 것을 뜻한다.

 

프론트 서버는 정적이고, 백엔드 서버는 동적이다. 프론트 서버는 어떤 주소에 대한 요청을 보냈을 때, markup language(html, css)를 보내주고, 백엔드 서버는 프론트 서버와 통신하는 컴퓨터로, 사용자가 프론트 서버에서 어떤 동작을 했을 때 사용자 정보나 데이터에 접근하는 것을 가능하게 해주기 때문이다. 

 

 

 

 

배포

---

다른 방법들도 있겠지만, 오늘은 4가지의 방법으로 배포를 해보았다. 

 

1. 로컬에서 배포하기

 

• npm run build를 사용하여 모든 파일 압축 => serve -s build 
• 같은 네트워크에서 다른 컴퓨터를 접속할 수 있는데, 이 때 IP를 알아내야 한다. 맥의 경우 터미널에 ifconfig를, 윈도우에 경우 터미널에 ipconfig를 작성해주면 IP를 확인할 수 있다. 참고로 윈도우의 경우 방화벽 설정에 들어가 방화벽을 열어줘야한다.(팀원 중 한 명이 윈도우라서 확인해볼 수 있었다.)

2. 깃헙 서버

 

• index.html을 가지는 브랜치

https://마지막 링크/레포명/ 을 작성해주면 깃헙 서버를 생성할 수 있다.

 

3. AWS Amplify

먼저 AWS 웹 사이트에서 회원가입을 해야지 사용할 수 있다. 깃헙 주소를 입력하고, 브랜치를 설정하면 아주 쉽게 배포를 해볼 수 있다. 

 

 

4. AWS EC2

 

• node 설치 => git clone => npm run build => serve -s build (우분투 터미널에서 로컬 터미널에서 하던 방식과 비슷하게 하면 된다.)
• 보안 그룹 편집에서 방화벽을 열어줘야 한다. 

 

 

728x90

 

git remote에서 origin이란?

---

remote는 원격 저장소이고, origin은 내가 정할 수 있는 주소 이름이다. 그래서 origin 말고 banana 이렇게도 가능하다. 

 

 

 

 

 

BFF(Backend for Frontend)

---

API를 다이렉트로 의존할 때의 이슈들을 해결하고자 등장했다. 여기서 말하는 이슈 중 몇가지를 예로 들어보자면 아래와 같다.

 

• CORS 이슈
• API 입장에서 여러 플랫폼과 스펙을 맞출 때의 커뮤니케이션 비용
• 플랫폼별로 다를 수 밖에 없는 인증 방식을 통합하려는 무리한 시도
• 화면에 필요한 데이터만 받는 partial response를 하기 어려운 이슈

 

BFF는 말 그대로 프론트엔드를 위한 중간 서버를 구현하는 것이라고 생각하면 된다. 하나의 프론트엔드에 대해 하나의 BFF가 있어야 BFF를 프론트엔드 요구사항에 맞게 구현할 수 있다. 다시 말해, 프레임워크(Web, Android, iOS, Desktop, 스마트 워치 등) 별로 필요에 맞게 각각 백엔드를 구성하는 아키텍처 방법론이다. 

 

BFF의 가장 큰 장점은 하나의 플랫폼 별로 적절한 서버가 돌아가고 있기 때문에 사용자에게 고른 경험을 줄 수 있다는 것이다. 또한 각각의 플랫폼 별로 BFF를 잘 따라서 설계가 되어 있다면 어플리케이션을 실행하는 동안에 자원 사용량도 최적화할 수 있다. 

 

BFF에서는 프론트엔드 생산성을 더욱 높이기 위해, 데이터를 통합하는 처리를 담당한다. BFF를 구현하여 프론트엔드를 백엔드에서 분리된 상태로 유지할 수 있다. BFF는 프론트엔드 요구사항을 충족하기 위해 존재하고, 이상적으로는 프론트엔드 개발자가 빌드해야 한다. 

 

정리해보자면 BFF를 도입했을 때의 장점은 아래와 같다.

 

• 여러 개의 프론트엔드 어플리케이션 인터페이스가 각각의 BFF 서버를 병렬적으로 호출하기 때문에 응답이 빨라진다. 
• 백엔드 시스템의 수정을 하거나 개선을 하는 과정에서 팀이 사용하는 시간이 줄어든다.
• 프론트엔드 어플리케이션으로 데이터를 전송하는 과정에서 민감하거나 불필요한 데이터는 숨길 수 있어서 시스템을 간결하게 할 수 있다. 

 

반면 단점은 아래와 같다. 

 

• 많은 부분의 코드가 중복되거나 재작성될 수 있다. 이 과정에서 많은 커뮤니케이션 비용이 발생한다. 
• 하나의 서비스가 전체 BFF 시스템을 다운시킬 수 있다. (Fan Out)

 

 

 

반응형

 

cors(Cross-Origin Resource Sharing)

---

다른 도메인으로부터 리소스가 요청될 경우 해당 리소스는 cross-origin HTTP 요청에 의해 요청된다. 하지만 대부분의 브라우저들은 보안 상의 이유로 스크립트에서 cross-origin HTTP 요청을 제한한다. 이것은 Same-Origin-Policy(동일 근원 정책)라고 한다. 요청을 보내기 위해서는 요청을 보내고자 하는 대상과 프로토콜(https 등)도 같아야하고, 포트도 같아야 함을 의미한다. 

 

이러한 문제를 해결하기 위해 과거에는 flash를 proxy로 두고 타 도메인과 통신을 했다. 하지만 모바일 운영체제의 등장으로 flash로는 더 이상 통신하기가 어려워졌다.(ios는 전혀 flash를 지원하지 않기 때문이다.) 대체제로 나온 기술이 JSONP(JSON-padding)이다. JSONP로 ajax를 호출할 때 타 도메인간 호출이 가능해졌다. JSONP에는 타 도메인간 자원을 공유할 수 있는 몇 가지 태그가 존재한다. img, ifame, script, link 등이 있다.

 

여기서 cors는 타 도메인 간에 자원을 공유할 수 있게 해주는 것이다. 웹 브라우저가 사용하는 정보를 읽을 수 있도록 허가된 출처 집합을 서버에게 알려주도록 허용하는 특정 HTTP 헤더를 추가함으로써 동작한다.

HTTP Header	Description
Access-Control-Allow-Origin	접근 가능한 url 설정
Access-Control-Allow-Credentials	접근 가능한 쿠키 설정
Access-Control-Allow-Headers	접근 가능한 헤더 설정
Access-Control-Allow-Methods	접근 가능한 http method 설정

 

 

 

 

Preflight Request

 

---

실제 요청을 보내도 안전한지 판단하기 위해 먼저 보내는 요청을 preflight request라고 한다. 다시 말해, 실제 요청 전에 인증 헤더를 전송하여 서버의 허용 여부를 미리 체크하는 테스트 요청이다. 

 

이 요청으로 트래픽이 증가할 수 있는데, 서버의 헤더 설정으로 캐쉬가 가능하다. 서버 측에서는 브라우저가 해당 도메인에서 cors를 허용하는지 알아보기 위해 preflight 요청을 보내는데 이에 대한 처리가 필요하다. preflight 요청은 HTTP의 OPTIONS 메서드를 사용하여 Access-Control-Request-* 형태로 헤더를 전송한다. 이는 브라우저를 강제하며 HTTP OPTION 요청 메서드를 이용해 서버로부터 지원 중인 메서드들을 내려 받은 뒤, 서버에서 승인 시에 실제 HTTP 요청  메서드를 이용해 실제 요청을 전송하는 것이다. 

 

 

 

 

SSH란?

---

SSH(Secure SHell)는 네트워크 상의 다른 컴퓨터에 로그인하거나 원격 시스템에서 명령을 실행하고 다른 시스템으로 파일을 복사할 수 있도록 해주는 응용 프로그램 또는 그 프로토콜을 가리킨다. 즉, 네트워크 프로토콜 중 하나로 컴퓨터와 컴퓨터가 인터넷과 같은 Public Network를 통해서 서로 통신을 할 때 보안적으로 안전하게 통신을 하기 위해 사용하는 프로토콜이다. 

 

대표적으로 데이터 전송, 원격 제어 시에 사용한다. 데이터 전송 예로는 소스 코드를 원격 저장소인 깃헙에 푸쉬할 때 SSH를 활용해 파일을 전송하는 케이스가 있다. 원격 제어의 예로는 AWS와 같은 클라우드 서비스는 서버에 접속하여 해당 머신에 명령을 내리기 위해서 SSH를 통한 접속을 해야하는 케이스가 있다. 

 

SSH는 다른 컴퓨터와 통신할 때 일반적으로 사용하는 비밀번호 입력을 통한 접속을 하지 않는다. 기본적으로 SSH는 한 쌍의 key를 통해 접속하려는 컴퓨터와 인증 과정을 거친다. 한 쌍의 key는 아래와 같다. 

 

1. Public Key

 

• 공개되어도 비교적 안전한 key이다.
• 이 키를 통해 메세지를 전송하기 전 암호화를 한다.
• 암호화는 가능하지만 복호화는 불가능하다. 참고로 복호화는 암호화된 데이터를 해독하는 것이다.

2. Private Key

• 절대로 외부에 노출되어서는 안되는 key이다.
• 본인의 컴퓨터 내부에 저장하게 되어있다.
• 암호화된 메세지를 복호화할 수 있다. 

 

이 키를 통해 서로 다른 컴퓨터와 통신하기 위해서는 먼저 Public Key를 통신하고 있는 컴퓨터에 복사하여 저장한다. 그리고 요청을 보내는 클라이언트 사이트 컴퓨터에 접속 요청을 할 때, 응답을 하는 서버 사이트 컴퓨터에 복사되어 저장된 Public Key와 클라이언트 사이트의 Public Key와 쌍을 이루는 Private Key와 비교해 서로 한 쌍의 key인지 검사한다. 

 

이렇게 서로 관계를 맺고 있는 key라는 것이 증명되면 비로소 두 컴퓨터 사이에 암호화된 채널이 형성되어 key를 활용해 메세지를 암호화하고 복호화하며 데이터를 주고 받을 수 있게 된다. 

 

 

 

 

 

참고 자료

---

• https://fe-developers.kakaoent.com/2022/220310-kakaopage-bff/
• https://www.mobilelive.ca/blog/why-backend-for-frontend-application-architecture
• cors
• ssh

 

 

 

---

질문이나 잘못된 점은 댓글로 남겨주세요 :)💖