인프라 아키텍쳐 구조와 기초 용어에 대해

이번 글에서는 IT 인프라 아키텍쳐 구조에 대해 살펴볼 것이다.

우리가 흔히 서비스를 구성할 때, IT 인프라 아키텍쳐를 빼놓고선 시작할 수가 없다.

IT 인프라는 컴퓨터로 구성되어 있고, '집약형'과 '분할형'으로 구분하여 설계할 수 있다.

​

집약형의 경우 단순히 대형 컴퓨터로 모두 처리하는 것이다.

이는 확자성 측면에서도, 비용적인 측면에서도 비효율적이다.

요즈음은 가격이 저렴하고 확장성이 높은 '분할형' 구조를 선호하는 편이다.

​

분할형 아키텍쳐는 또 다시 두 가지 형태로 나뉜다.

첫 째는 수직 분할형 아키텍쳐로, 클라이언트 - 서버로 나뉘는 것이다.

이는 요즈음 흔히 사용되는 개념으로, 클라이언트는 보통 PC, 스마트폰, 태블릿 등이 해당된다.

일례로 HTS를 이용한다고 했을때, 주식 데이터는 서버에서 요청해서 가져오지만, 플라팅하는 부분은 클라이언트에서 진행하기도 한다.

두 번째는 3계층형 아키텍쳐이다. 프레젠테이션 계층, 어플리케이션 계층, 데이터 계층으로 구성되어 있다.

프레젠테이션 계층은 말그대로 사용자의 입력을 받아 웹브라우저 화면을 표시하는 것이다.

애플리케이션 계층은 사용자 요청을 처리하고, 데이터 계층은 그 request에 따른 데이터 입출력을 한다.

이는 각각 웹서버, AP서버, DB서버로 구성되어 불리기도 한다.

* 3-Tier 아키텍쳐라고도 불린다.

3계층 시스템의 전체 구성

이전 OS 글에서 다뤘듯이, 새로운 프로세스와 스레드가 시작되면 커널으로부터 메모리 공간을 할당받는다.

프로세스는 독립된 메모리 공간을 가진다. 반면 스레드의 경우 하나의 메모리 공간을 공유한다.

* 프로세스의 경우 독립된 메모리 공간을 지녀야하기 때문에 처음 생성시 CPU부하가 있을 수 있다.

** 스레드의 경우 공유 공간을 지니기 때문에 원치않는 데이터 읽/쓰기가 발생할 수 있다.

프로세스 역시 독립된 공유 메모리 공간을 가질 수도 있다. Oracle DB의 경우 캐시로 저장하는 데이터는 공유 메모리 공간에, 프로세스가 단독으로 이용하는 데이터는 독립된 공간에 저장한다.

​

데이터 흐름을 좀 살펴보면,

클라이언트 PC에서 웹 브라우저에 대한 접근 요청이 발생한다.

새로운 프로세스가 생성되고, 사용자가 새로운 웹 페이지 링크를 클릭하면 웹 서버로의 요청이 생성된다.

클릭한 웹 URL은 브라우저에서 알 수 없는 주소이기 때문에 DNS서버를 통해 IP주소로 반환된다.

이 때 우리는 HTTP 프로토콜을 통해 HTML 파일을 반환받게 되고,

이 파일 안에는 정적 콘텐츠와 동적 콘텐츠로 구성되어 있다.

바뀌지 않는 이미지와 텍스트 등의 정적 콘텐츠는 디스크에 저장하고,

변경이 잦은 데이터는 AP서버를 통해 HTML파일을 동적으로 생성한다.

​

웹 서버는 들어온 request를 받아 웹 서버로만 계산이 가능한 경우엔 직접 처리하고,

DB 접근을 통한 응답이 필요하다면 DB서버에 요청을 주게 된다.

이 때 데이터가 캐시되어있는 경우 내부에서 바로 데이터를 반환하기 때문에 속도가 매우 빠르다.

​

DB서버는 받은 요청을 접수하여 캐시가 존재하는지 확인한 뒤, 없을 경우 디스크에 쿼리를 날리게 된다.

다시 거꾸로 돌아가서, DB서버에서 데이터를 AP서버로 보내면, AP서버는 데이터 결과를 웹 서버로 반환한다.

클라이언트PC는 AP서버로부터 데이터를 받아 웹 브라우저에 반환한다.

---

직렬/병렬 처리

다음으로는 직렬/병렬 처리에 대해 알아볼 것이다.

직렬 처리는 분명 처리 속도를 올리는 데 한계가 있다.

이에 따라 병렬 처리가 대안으로 떠올랐고, 이마저도 합류하는 지점과 직렬화 구간, 분기점에서 병목이 발생한다.

사람들은 병목이 발생하는 오버헤드보다 병렬 처리로 얻는 이득이 더 클 때 병렬로 구성한다.

​

앞서 살펴본 웹서버도 다수의 이용자로부터 요청이 오기 때문에, 멀티 프로세스 / 멀티 쓰레드로 처리한다.

이 때 프로세스와 스레드의 수는 CPU 코어수를 고려하여 정하게 된다.

DB서버도 병렬화 처리가 가능하다.

​

병렬 처리시에는 배타적 제어가 필요하다.

복수의 처리가 공유 자원을 동시에 엑세스할 경우 consistency 불일치 문제가 발생할 수 있기 때문이다.

(이 부분에서 병목 현상이 발생하기도 한다.)

​

락을 이용하여 배타적 제어를 하기도 한다.

DBMS에서는 세 가지 타입의 락을 건다.

1. Spin-lock : 의미없는 처리를 반복하면서 대기

2. Sleep-lock : 락을 확보하지 못할 경우 Sleep

3. Adaptive-lock : 1,2를 선택적으로 수행

​

OS에서는 리눅스 커널의 빅 커널락(Big Kernel Lock, BKL)이 있다.

이 부분은 처리가 직렬화되어 하나의 CPU만 커널 코드를 실행할 수 있다.

​

배타적 제어는 CPU뿐만 아니라 서버로까지 확장하여 생각해볼 수도 있다.

---

동기/비동기

동기란 요청이 끝날 때까지 다른 업무를 처리하지 않고 기다리는 것이고,

비동기는 요청이 끝나기 전에 다른 업무를 처리하는 것이다. 보통 병렬로 처리시에 비동기로 진행한다.

동기와 비동기성은 의존성에 따라 중요하게 작용한다.

비동기는 서로 이벤트간 의존성 없이 작동하는 것이다.

​

예를 들어 우리가 검색 엔진에서 검색창에 무언가를 입력할때, 후보 키워드를 표기해주는 창과 별도로 이전에 검색했던 결과는 그대로 남아있는 것을 비동기식 처리라고 할 수 있다. 검색창에 입력하는 값에 따라 화면 전체를 재로딩해야할 경우 우리는 꼼짝없이 기다려야하지만, 검색창에서 후보 키워드 결과만 바뀌기 때문에 그렇지 않아도 된다.

​

DB에서도 예시를 찾아보 수 있다. 비동기 I/O 방식을 이용하는 경우는 이전 I/O 처리가 끝나지 않아도 다른 처리를 할 수 있다. 그 예로 대량의 데이터를 하드디스크에 기록하는 경우 비동기 I/O라면 다른 I/O가 끝나지 않았을때도 I/O를 요구할 수 있다. 즉 어떠한 데이터 기록 요청이 세 가지가 있다고 하면, 각각에 대한 요구를 비동기로 진행하고, 각각에 대한 요청 처리가 끝난는지 확인하게 된다.

---

큐

큐는 대기 행렬이라고도 부르고, FIFO원칙을 준수하고 있다.

큐 자료구조는 프로세스나 스레드 행렬에도 사용되고, request 행렬로도 사용된다.

CPU는 코어 수에 따라서 프로세스/스레드가 각각 처리될 수 있는 반면,

DB의 디스크 I/O의 경우는 HDD에 각각 접근하여 사용할 수 없기 때문에 별도 큐를 생성하기도 한다.

---

Stateful / Stateless

http는 Stateless, ssh는 Stateful 프로토콜로 분류된다.

각각의 차이는 어떤 것이 있을까?

​

상태 정보를 저장한다는 것은 각각의 단계별 상태에 따라 세세한 제어가 가능하다.

즉 과거 정보를 지속적으로 이용하여야할 때는 상태 정보를 저장해야한다.

반면 과거 정보를 전혀 알 필요가 없는 경우에는 상태 정보를 지니지 않아도 된다.

​

상태 저장은 캐시와 같이 데이터를 저장해야하는 경우를 일컫기도 한다.

​

Stateless는 정보를 따로 저장하지 않기 때문에 간단하고 성능을 해치지 않는다.

상태를 저장할 때는 복잡성이 높아지지만 과거 데이터를 기반으로 응답을 줄 수 있다.

​

일전에 알아본 프로세스의 상태 전이에는 Stateful한 방식을 이용한다.

또한 일전에 로그인을 하였던 웹사이트에서 세션 정보를 지닐 경우 다시 로그인을 하지 않아도 되는 상황에서도 상태 저장 방식을 이용한다.

---

고정 길이/가변 길이 데이터

고정된 길이의 경우 위치가 고정되어 있어 쉽게 접근이 가능하다는 장점이 있다.

반면 가변 길이의 경우 미리 계획해두지 않아도 유연성 있게 공간을 활용할 수 있다.

​

파일은 고정 길이로 저장된다. 이미지 파일 속성을 보게 되면 크기와 디스크 할당 크기가 동일한 것을 볼 수 있다.

반면 텍스트 파일의 경우 고정길이를 사용하지 않는다.

일전에 네트워크에서 보았던 데이터 전송 과정에서도 TCP헤어와 IP헤더와 같은 헤더 데이터는 가변길이를 사용한다.

​

---

참고자료

그림으로 공부하는 IT인프라 구조

https://book.naver.com/bookdb/book_detail.nhn?bid=17527140