2주차 개념 스터디 - BE (웹 서버, DB)

🚿 웹 서버

1. 웹 서버란 무엇인가?

웹서버란 HTTP 프로토콜을 통해 클라이언트의 GET, POST 등의 메소드를 활용한 요청을 서버에게 전달하고, 이를 서버 컴퓨터가 처리하여 다시 클라이언트에게 전달해주는 작업이다

 

이는 다음 두 가지 측면으로 구분이 가능하다

[ 하드웨어 측면 웹서버 ]

• 웹 사이트의 컴포넌트 파일들을 저장하는 컴퓨터
• 컴포넌트 파일 : HTML, Images, CSS, Javascript
• 컴포넌트 파일을 인터넷을 통해 클라이언트에게 전달한다

[ 소프트웨어 측면 웹서버 ]

• 사용자가 어떻게 호스트 파일들에 접근하는지를 관리한다
• 웹서버는 주소 HTTP 프로토콜을 사용하여 클라이언트의 요청을 처리 및 응답한다

 

2. apache

- 가장 폭넓게 사용되는 오픈소스 웹서버 중 하나로, MPM (Multi Processing Module) 아키텍처를 기반으로 한다

- 클라이언트 요청을 처리하기 위해 멀티 스레드 방식을 따른다

- 웹 서버 자체 내에서 동적 컨텐츠를 처리한다

- 모듈을 동적으로 로드 및 언로드하여 더욱 유연하다

- 다양하고 검증된 기능들을 필요로 하면 신뢰도가 높은 아파치를 사용한다

- 다양한 동적 모듈을 로드하기 위한 더 많은 문서와 지원이 제공된다

- 그러나 아파치는 다중 스레드 접근 방식을 따르고, 각 스레드는 한번에 하나의 연결만 처리가 가능하기 때문에 웹 트래픽이 많아지면 여러 요청을 동시에 처리할 수 없다

 

 

 

3. nginx

 

- 가장 폭넓게 사용되는 오픈소스 웹서버 중 하나로, 이벤트 중심 접근 방식을 사용하여 클라이언트 요청을 제공한다

- 제한된 하드웨어 리소스로도 여러 클라이언트 요청을 동시에 효율적으로 처리가 가능하다

- 단일 스레드를 통해 여러 연결을 처리할 수 있다

- 모든 요청을 event listener로 미루기 때문에 흐름이 끊기지 않고 응답이 빨라 성능과 가벼움을 중요하다면 이를 사용한다

- 최소한의 리소스로 웹 서버의 아키텍처를 개선하기 위해 독립형 HTTP 서버로 배치가 가능하다

- 트래픽이 많ㅇ느 웹 사이트를 위한 많은 정적 컨텐츠 및 미디어 스트림을 제공할 수 있다

- 그러나 NGNIX는 동적 컨텐츠를 기본적으로 처리할 수 없기 때문에 이를 처리하려면 PHP를 통해 외부 프로세서로 전달하고 렌더링 된 콘텐츠가 다시 전송될 때까지 기다려야 한다 -> 프로세스 속도 저하

 

 

[ Apache vs NGINIX ]

	Apache	NGINIX
정적 컨텐츠 처리	전통적인 파일기반 방식의 정적 컨텐츠	이벤트 처리/비동기식/논블로킹 방식 처리를 통한 고속 처리 가능
동적 컨텐츠 처리	서버 내에서 처리	처리하지 않음
OS 자원에 대한 범용성	리눅스, BSD, UNIX, Window	리눅스, BSD, UNIX, Window 부분지원
분산/중앙집중식	분산/중앙집중식 구성 채택	중앙집중식 구성 채택
모듈 및 확장성/보안	- 60개 이상의 다양한 기능과 모듈을 지원하며, 필요에 따라 활성화/비활성화 가능 - 다양한 디자인과 확장 가능	- 다른 코어 모듈을 동적으로 로딩 불가 - 옵션을 최소화하여 처음부터 성능에 집중 - 보안에 대한 다양한 기술 문서를 제공하며, 코드 자체가 가볍고 경량화되어 있어 보안에 유리

 

 

4. Node.js

- HTTP 서버 라이브러리가 내장되어 있어 웹 서버에서 별도의 소프트웨어 없이 동작이 가능하기 때문에 웹 서버의 동작에 있어 더 많은 통제가 가능하다

- CPU 코어를 하나밖에 사용하지 못하는 Single thread로 멀티 thread 방식보다 컴퓨터 자원을 적게 사용하지만, CPU 부하가 큰 작업에는 적합하지 않다

- 이벤트 기반 비동기 방식이라 하나의 thread가 요청을 받으면 바로 다음 처리에 요청을 보내놓고 다른 작업을 처리하다가 먼저 요청한 작업이 끝나면 이벤트를 받아서 응답을 보낸다

- 따라서 동시에 요청이 오더라도 처리가 완료될 때까지 기다리지 않아 서버 부하가 적고 가볍다

- 논블로킹 방식으로 하나의 스레드가 많은 수의 I/O를 처리하기 때문에 I/O 입출력이 많은 작업에 적합하다

- 간단한 로직과 대용량, 빠른 응답 시간과 개발이 필요한 웹서비스에 적합하다

 

---

🚒 RDBMS와 NoSQL

0. 들어가기전에!

[ Database ]

데이터베이스란 일반적으로 컴퓨터 시스템에 전자 방식으로 저장도니 구조화된 정보 또는 데이터의 체계적인 집합을 의미한다

 

[ DBMS ]

DataBase Management System의 약자로, 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해주고 데이터베이스를 관리해주는 소프트웨어이다

 

[ SQL ]

Structed Query Language의 약자로, 관계형 데이터베이스 관리 시스템의 데이터를 관리하기 위해 설계된 특수 목적의 프로그래밍 언어이며, 관계형 데이터베이스 관리 시스템에서 자료의 검색과 관리, 데이터베이스 스키마 생성과 수정, 데이터베이스 객체 접근 조정 관리를 위해 고안되었다

 

1. RDBMS

• R은 Relational의 약자로 RDBMS는 관계형 데이터베이스 관리 시스템을 의미한다. 이는 RDB를 관리하는 시스템으로, 여기서 RDB는 관계형 데이터 모델을 기초로 두고 모든 데이터를 2차원 테이블 형태로 표현하는 데이터베이스이다.
• 기존의 RDBMS에서의 저장 방식은 SQL에 의해 저장되고 있으며, 정해진 스키마에 따라 데이터를 저장해야 한다.
• RDBMS는 테이블이 다른 테이블들과 관계를 맺고 모여있는 집합체로, 관계를 나타내기 위해 외래 키(foreign key)를 사용한다
• 이러한 테이블간의 관계에서 외래 키를 이용한 테이블 간 Join이 가능한 것이 특징이다.

[ 종류 ]

MySQL, PostgresQL, Oracle, MariaDB 등

 

[ 장점 ]

• 정해진 스키마에 따라 데이터를 저장해야 하므로 명확한 데이터 구조를 보장한다
• 관계는 각 데이터를 중복없이 한 번만 저장할 수 있다

[ 단점 ]

• 테이블 간에 관계를 맺고 있어 시스템이 커질 경우 JOIN 문이 많은 복잡한 쿼리가 만들어질 수 있다
• 성능 향상을 위해서 서버의 성능을 향상시켜야 하는 Scale-Up만을 지원하기 때문에 비용이 기하급수적으로 증가할 수 있다
• 스키마로 인해 데이터가 유연하지 못하여 나중에 스키마가 변경될 경우 번거롭고 어렵다

 

2. NoSQL

• Not Only SQL의 약자로 RDB 형태의 관계형 데이터베이스가 아닌 다른 형태의 데이터 저장 기술을 의미한다.
• 또한 RDBMS와는 달리 테이블 간 관계를 정의하지 않는다
• 데이터 테이블은 그냥 하나의 테이블이며 테이블 간의 관계를 정의하지 않기 때문에 일반적으로 테이블 간 Join도 불가능하다
• 이는 빅데이터의 등장으로 인해 데이터와 트래픽이 기하급수적으로 증가하였고 이에 따라 RDBMS의 단점인 성능을 향상시켜야 했다. 이를 위해서는 장비가 좋아야 하는 RDBMS의 특징인 Scale-Up으로 인해 비용이 급격히 증가하였다. 이를 보완하기 위해 데이터 일관성은 포기하되, 비용을 고려하여 여러 대의 데이터에 분산하여 저장하는 Scale-Out을 목표로 등장하였다
• NoSQL은 다양한 형태의 저장 기술을 지원하며, 이는 RDBMS 스키마에 맞춰 데이터를 관리해야 한다는 한계를 극복하고, 수평적 확장성(Scale-out)을 쉽게 할 수 있다는 장점이 있다

 

[ NoSQL의 특징 ]

 

1) Key-Value Database

• Key-Value Database는 데이터가 Key와 Value의 쌍으로 저장된다.
• Key는 Value에 접근하기 위한 용도로 사용되며, 값은 이미지나 비디오 등 어떠한 형태의 데이터라도 담을 수 있다.
• 또한 간단한 API를 제공하는 만큼 질의의 속도가 굉장히 빠른 편이다.
• 대표적인 NoSQL Key-Value Model로는 Redis, Riak, Amazon Dynamo DB 등이 있다.

2) Document Database

• Documnet Database 데이터는 Key와 Document의 형태로 저장된다.
• Key-Value 모델과 달리 Value가 계층적인 형태인 도큐먼트로 저장된다
• 객체지향에서의 객체와 유사하며, 이들은 하나의 단위로 취급되어 저장되기 때문에 하나의 객체를 여러 개의 테이블에 나눠 저장할 필요가 없다
• 객체를 Document의 형태로 바로 저장 가능하기 때문에 객체-관계 간의 매핑이 필요하지 않다
• 또한 검색에 최적화되어 있는데, 이는 Key-Value 모델의 특징과 동일하게 검색에 최적화되어 있다
• 도큐먼트 모델에서는 질의의 결과가 JSON이나 xml 형태로 출력되기 때문에 사용이 번거롭고 쿼리가 RDBMS에서의 SQL과는 다르다
• 대표적인 NoSQL Document Model로는 MongoDB, CouthDB 등이 있다.

3) Wide Column Database

• Column-family Model 기반의 Database로, Key-Value 값을 이용해 필드를 결정했던 이전 모델과는 달리 이는 키에서 필드를 결정한다.
• 키는 Row(키 값)와 Column-family, Column-name을 가진다.
• 연관된 데이터들은 같은 Column-family 안에 속해 있으며, 각자의 Column-name을 가진다. (관계형 모델로 설명하자면 어트리뷰트가 계층적인 구조를 가지고 있는 느낌?)
• 이렇게 저장된 데이터는 하나의 커다란 테이블로 표현이 가능하며, 질의는 Row, Column-family, Column-name을 통해 수행된다.
• 대표적인 NoSQL Column-family Model로는 HBase, Hypertable 등이 있다.

4) Graph Database 

• Graph Model Model에서 데이터를 Node와 Edge, Property와 함께 그래프 구조를 사용하여 데이터를 표현하고 저장하는 Database이다
• 개체와 관계를 그래프 형태로 표현한 것이므로 관계형 모델이라고 할 수 있으며, 데이터 간의 관계가 탐색의 Key일 경우에 적합하다.
• 페이스북이나 트위터 같은 소셜 네트워크에서 팔로워 파도타기 등의 질의에 적합하고, 연관된 데이터를 추천해주는 추천 엔진이나 패턴 인식 등의 데이터베이스로도 적합하다.
• 대표적인 NoSQL Graph Model로는 Neo4J가 있다.

 

[ 종류 ]

MongoDB, Redis, ElasticSearch, Cassandra, Neo4j 등

 

[ 장점 ]

• 스키마가 없기 때문에 유연하며 자유로운 데이터 구조를 갖는다
• 언제든 데이터를 조정하고 새로운 필드를 추가할 수 있다

[ 단점 ]

• 데이터 중복이 발생할 수 있으며, 중복된 데이터가 변경될 경우 수정을 모든 컬렉션에서 수행해야 한다
• 스키마가 존재하지 않기 때문에 명확한 데이터를 보장하지 않으며 데이터 구조 결정이 어려울 수 있다

 

 

3. RDBMS vs NoSQL

[ RDBMS ]

• 데이터 구조가 명확하며 변경 될 여지가 없고, 명확한 스키마가 중요한 경우 사용하는 것이 좋다
• 중복된 데이터가 없어 데이터 무결성이 보장되고, 변경이 용이하기 때문에 관계를 맺고 있는 데이터가 자주 변경이 이뤄지는 시스템에 적합하다

 

[ NoSQL ]

• 정확한 데이터 구조를 알 수 없고 데이터가 변경/확장이 될 수 있는 경우에 사용하는 것이 좋다
• 데이터 중복이 발생할 수 있으며, 중복된 데이터가 변경될 시에는 모든 컬렉션에서 수정을 해야하기 때문에 Update가 자주 발생하지 않는 시스템에 적합하다
• Scale-out이 가능하기 때문에 막대한 데이터를 저장하기 위해 데이터베이스를 Scale-Out을 해야하는 시스템에 적합하다

 

 

 

 

---

 

 

[ 참고 사이트 ]

https://khj93.tistory.com/entry/Database-RDBMS%EC%99%80-NOSQL-%EC%B0%A8%EC%9D%B4%EC%A0%90