본문 바로가기
웹서비스 개발 기초

DevOps Day 7 (3/15) 웹서비스 개발 기초_클라이언트-서버 아키텍처

by Jackykim 2023. 3. 15.

Client Server Architecture – 2 Tier Architecture
Case Study :
쇼핑몰 앱
-
인터넷 연결 없이 쇼핑몰 앱이 작동되지 않는 이유 : 상품 정보를 인터넷 어딘가에 존재하는 서버로부터 받아와야 하기 때문.
-
쇼핑몰 앱에 새로운 상품 목록 받기 위해서는 앱 자체를 업데이트 해야함, 그래서 꾸준한 업데이트가 필요하며 결제 시스템도 결국 금전 정보를 주고받는 은행 서버와의 연결이 필요함

리소스를 사용하는 앱

리소스가 존재하는 곳과 리소스를 사용하는 앱을 분리시킨 것을 2-Tier 아키텍처, 다른 말로는 클라이언트-서버 아키텍처하고 부릅니다.
리소스에 접근하는 앱 (클라이언트)가 서버에 요청해야 리소스를 담아 응답합니다.

 

3-Tier 아키텍처

리소스를 저장하는 공간을 별도로 마련해 두는데 이 공간을 데이터베이스라고 부릅니다. 데이터베이스는 창고와 같은 역할을 하고 있음. 참고로 서버는 리소스를 전달해 줄 뿐, 리소스를 저장하고 있지는 않습니다.

 

프론트엔드와 백엔드

클라이언트 앱은 사용자가 눈으로 보고, UI를 클릭 또는 터치하는 앱을 주로 프론트엔드 개발자라고 합니다.
눈에 보이지는 않지만, 상품 정보를 API로 노추한다든지 로그인/로그아웃, 관한 관리 등 뒤에서 작동하는 영역은 주로 벡엔드 개발자라고 합니다. (데이터베이스 등의 시스템 설계)

 

클라이언트와 서버 종류

- 브라우저를 통해 주로 이용하는 웹 (web) 플랫폼에서의 클라이언트는 웹사이트 또는 웹 앱이라고 합니다.
- IOS
나 안드로이드와 같은 스마트폰/태블릿 플랫폼 또는 윈도우와 같은 데스크탑 플랫폼에서 이용하는 앱 역시 클라이언트가 될 수 있습니다.
-
서버는 무엇을 하느냐에 따라 종류가 달라집니다. 파일 서버는 파일을 제공하는 앱, 웹 서버는 웹사이트에서 필요로 하는 정보들을 제공하는 앱 등등
-
데이터베이스도 데이터 제공자로서 일하무로 일종의 서버라고 볼 수 있음

 

HTTP를 이용한 클라이언트-서버 통신과 API
클라이언트와 서버 간의 통신은 요청과 응답으로 구성 되어 있고, 요청이 있어야 응답이 옵니다. 서버 마음대로 클라이언트 리소스를 전달하지 않습니다.

 

프로토콜 (Protocol)
프로토콜은 통신 규약, 즉 약속입니다. 클라이언트가 서버에 리소스 요청할 때 꼭 지켜야 하는 약속이 몇가지 존재합니다 (외계어로 요청, 존재하지 않은 리소스 요청 등)

 

웹 애플리케이션 프로토콜 : HTTP

웹 애플리케이션 아키텍처에서는, 클라이언트와 서버가 서로 HTTP라는 프로토콜을 이용해서 서로 대화를 나눕니다.

 

프로토콜 Case Study : 커피 주문
프로토콜 1: 집접 카운토로 찾아감
프로토콜 2: 모바일 앱 이용
프로토콜 3 : 키오스크

 

프로토콜 Case Study : 우편
우편 보낼때에 수신자에 대한 아무런 표기가 없거나 우표를 안 붙이면 발송이 불가합니다. 그래서 우편을 이상 없이 보내라면 규약을 지켜야 합니다.

 

주요 프로토콜

OSI 7 layers는 컴퓨터공학과 네트워크에서 자주 등장하는 개념입니다.

API

컴퓨터에게 요청할 때에는, 정확한 주문 방법을 따라 요청해야 합니다.
그럼 서버가 어떻게 구성되어 있는지 모른다면, 클라이언트는 어떻게 리소스 요청을 할 수 있는가? 서버에는 마치 식당에서 메뉴판을 제공할 듯, 리소스를 잘 활용할 수 있도록 API를 제공해야 합니다.
API :
사전적 의미는 의사소통이 가능하도록 만들어진 접점을 의미합니다.

 

API case Study : 커피 주문

서버는 리소스 전달을 위한 메뉴판, API 문서를 작성해야 클라이언트가 이를 활용 할 수 있습니다. 보통 인터넷 데이터를 요청할 떼에는 HTTP 프로토콜을 사용하여, 주소 (URL, URI)를 통해 접근 할 수 있습니다.

 

HTTP API 디자인을 잘 하는 방법


HTTP API 디자인에는 Best Practice가 존재합니다. 리소스를 그저 달라고 (GET) 요청했지만, 사용자 관리 API에서는 사용자를 추가해 달라고 (CREATE) 요청하거나, 지워달라고 (DELETE) 요청할 수도 있습니다.

 

HTTP API 디자인을 잘 하는 방법

HTTP API 디자인에는 Best Practice가 존재합니다. 리소스를 그저 달라고 (GET) 요청했지만, 사용자 관리 API에서는 사용자를 추가해 달라고 (CREATE) 요청하거나, 지워달라고 (DELETE) 요청할 수도 있습니다.

 

발표
[C331] public IP Private IP의 차이점을 설명하세요.

Public IP : 네트워크 외부와 통신하는데 사용되는 IP 주소이며 ISP (Internet Service Provider)에서 활당하고 외부에 공개되어 있는 IP 주소입니다. 또한 IP 주소가 외부에 공개되어 있기에 인터넷에 연결된 다른 PC로 부터의 접근이 가능합니다. (보안 문제가 있음)

 

Private IP : 동일한 네트워크 내에서 사용되는 IP 주소입니다. 일반적으로 사내 등에서 (가정 / 회사 등) 할당된 네트워크의 IP 주소이며 IPv4의 주소 부족으로 인하여 서브넷팅된 IP 이기 때문에 라우터에 의해 로컬 네트워크상의 PC나 장치에 할당됩니다. (외부 접근 불가능하여 안전함)

라우터를 통해 1개의 공인 (public) IP만 할당하고, 라우터에 연결된 개인 PC는 사설 (private) IP를 각각 할당 받아 인터넷에 접속할 후 있음.

 

출처 https://velog.io/@hidaehyunlee/%EA%B3%B5%EC%9D%B8Public-%EC%82%AC%EC%84%A4Private-IP%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90

https://hanjustudy.tistory.com/23

 

[C332] 터미널에서 nslookup 명령을 실행 했을 때 나오는 결과값에 대한 설명을 작성하세요.

 

Nslookup : 인터넷 도메인 네임 서버 (DNS server)에게 특정 호스트에 대한 정보 (호스트 네임과 IP address)를 문의하는 대화식 프로그램입니다. 호스트 이름이나 IP 주소를 알려고 할 경우나 IP 주소를 알고 있는데 호스트 이름을 모를 경우 사용합니다. Nslookup google.com 실행 했을 때 아래와 같은 정보가 표시 됩니다.

 

Server : 접속하고자하는 DNS 서버 IP 혹은 호스트네임
Non-authoritative answer
값들은 서버에서 DNS 값을 이미 캐시로 가지고 있을 때 캐시에서 가져온 값들입니다

-type 옵션을 사용하여 다양한 value를 얻을 수 있습니다.
DNS 리소스 레코드 종류를 지정합니다. 기본 리소스 레코드 형식은 이지만 다음 값 중 하나를 사용할수 있습니다.

 

A: 컴퓨터의 IP 주소를 지정 합니다.
ANY:
컴퓨터의 IP 주소를 지정 합니다.
CNAME:
별칭의 정식 이름을 지정 합니다.
GID
그룹 이름의 그룹 식별자를 지정 합니다.
HINFO:
컴퓨터의 CPU 및 운영 체제 유형을 지정 합니다.
MB:
사서함 도메인 이름을 지정 합니다.
MG:
메일 그룹 구성원을 지정 합니다.
MINFO:
사서함 또는 메일 목록 정보를 지정 합니다.
MR:
메일 이름 바꾸기 도메인 이름을 지정 합니다.
MX:
메일 교환기를 지정 합니다.
NS:
명명 된 영역에 대 한 DNS 이름 서버를 지정 합니다.
PTR:
쿼리가 IP 주소인 경우 컴퓨터 이름을 지정 합니다. 그렇지 않으면 다른 정보에 대 한 포인터를 지정 합니다.
SOA: DNS
영역에 대 한 권한을 지정 합니다.
TXT:
텍스트 정보를 지정 합니다.
UID:
사용자 식별자를 지정 합니다.
Uinfo:
사용자 정보를 지정 합니다.
WKS:
잘 알려진 서비스에 대해 설명 합니다.

 

[C333] 검색창에 http://google.com 을 검색하면, DNS에서 어떤 일이 일어나나요? 이에 대한 설명을 작성하세요.


웹 브라우저는 해당 도메인 이름을 IP 주소로 변환해야 합니다. 이때 DNS가 사용되고 입력된 URL의 프로토콜을 파악하고, 해당 프로토콜에 맞는 포트번호를 결정합니다. 도메인 이름인 google.com 을 찾기 위해 DNS 서버에 요청합니다. 로컬 DNS 서버는 우선 자신의 DNS 캐시를 검색하여 해당 도메인 이름에 대한 IP 주소가 있는지 확인하여 존재할 경우 IP주소를 웹 브라우저에 변환합니다. 존재하지 않는 경우 상위 레벨 SNS 서버에 쿼리를 보내 도메인 이름에 대한 IP 주소를 검색합니다. 따라서 Google.com IP 주소만 인터넷 창에 기입해도 해당 웹 브라우저가 뜹니다.