3계층형 시스템을 살펴보자

3계층형 아키텍처를 주축으로, 시스템이 처리하는 데이터와 시스템상에서의 데이터 흐름을 구체적으로 살펴보자.

주요 개념 설명

프로세스와 스레드

프로세스와 스레드는 프로그램 실행 파일 자체가 아니라 OS상에서 실행돼서 어느정도 독립성을 가지고 동작하는 것

프로세스 및 스레드가 활동하려면 메모리 공간이 필요하다. 커널에 의해 메모리상에 확보된다.

메모리 공간은 프로세스 및 스레드가 자신을 위해 소유하는 공간으로 개인 공간이라 할 수 있다.

프로세스는 전용 메모리 공간을 이용해서 동작한다. 반면 스레드는 다른 스레드와 메모리 공간을 공유한다.

프로세스는 개별 처리 독립성이 높은 대신, 독자 메모리 공간을 가지기 때문에 생성 시 CPU 부하가 스레드와 비교해 높아진다.

스레드는 생성 시 부하가 낮지만, 메모리 공간을 공유하기 때문에 의도하지 않는 데이터 읽기/쓰기가 발생할 수 있다.

단, 프로세스는 외부 공유 메모리 공간을 상호 이용함으로써 메모리 공간을 공유할 수 있다.

OS 커널

OS에서 커널은 심장이자 뇌이며 척수다. 커널 자체가 OS의 인프라라고 생각하면 된다.

커널은 다양한 역할을 갖지만, 가장 중요한 것은 뒤에서 무슨 일이 벌어지는지 은폐하면서도 편리한 인터페이스를 제공하는 것이다.

→ 커널이 존재하기 때문에 개발자는 하드웨어나 다른 애플리케이션에 끼치는 영향을 의식하지 않고 애플리케이션을 만들 수 있다.

커널의 대표적인 역할

시스템 콜 인터페이스

프로세스/스레드에서 커널로 연결되는 인터페이스

애플리케이션이 OS를 통해서 어떤 처리를 하고 싶으면 시스템 콜이라하는 명령을 이용해서 커널에 명령을 내린다.

뒤에서 구체적으로 어떤 처리를 하고 있는지는 프로세스가 의식할 필요가 없다.

프로세스 관리

OS상에서는 수천 개의 프로세스를 가동할 수 있는 반면, 물리 서버의 CPU 코어 수는 많아야 수 십 개다. → 효율적인 프로세스 관리의 필요성

언제, 어떤 프로세스가 어느정도의 CPU 코어를 이용할 수 있는지, 처리 우선순위를 어떻게 결정할 것인지 등을 관리

메모리 관리

물리 메모리 공간의 최대치를 고려한다.

프로세스가 이용하는 독립 메모리 공간을 확보하거나 상호 간의 참조 영역을 지키기 위해 독립성을 관리하는 등의 메모리 관리 역할

이 기능이 없으면 각 프로세스는 자신 외의 프로세스가 사용하고 있는 메모리 영역 범위를 파악해야하는 작업이 수반됨 → 애플리케이션 개발이 매우 어려워짐

네트워크 스택 (6장에서 설명)

파일 시스템 관리

파일 시스템용 인터페이스 제공

파일 시스템은 OS 기능의 하나로서 물리 디스크에 제공된 데이터를 관리하는 기능

물리 디스크에 기록된 데이터는 ‘01010’과 같은 숫자의 집합일 뿐. 구분 표시도 없어서 그대로 사용하기는 어려운 형태다. 이를 파일이라는 단위로 묶어 관리를 한다.

파일 시스템 덕분에 애플리케이션은 파일 단위로 데이터를 작성하거나 삭제할 수 있다.

장치 드라이버

디스크나 NIC 등의 물리 장치용 인터페이스를 제공.

벤더마다 독자적인 제품을 제공하고 있기 때문에 각각에 대응하는 애플리케이션 개발은 불가능

커널은 장치 드라이버를 이용해서 그 아래에 있는 물리 장치를 은폐하고, 각 장치 제조사가 OS에 대응하는 장치 드라이버를 제공해서 해당 OS의 표준 장치로서 커널을 경유해 이용할 수 있게 한다.

웹 데이터 흐름

3계층형 시스템의 웹 데이터의 흐름을 알아본다.

클라이언트 PC부터 웹 서버까지

1. 웹 브라우저가 요청을 발행한다.
2. DNS를 통해 이름 해석을 한다.
3. 웹 서버가 (웹 서버의 httpd 프로세스가) 요청을 접수한다.
4. 웹 서버가 (httpd가 받은 요청 내용을 분석해서) 정적 콘텐츠인지 동적 콘텐츠인지 판단한다.
5. 필요한 경로로 데이터를 액세스 한다.

정적 콘텐츠란 실시간으로 변경할 필요가 없는 데이터를 가리킨다. 웹서버에서는 데이터 갱신 빈도가 낮은 것은 디스크에 저장한다.

동적 콘텐츠란 높은 빈도로 변경되는 데이터를 가리킨다.

이런 데이터를 서버 내부의 디스크에 저장하면 갱신 빈도가 높기 때문에 디스크 성능이 병목현상의 원인이 될 수 있다.

웹서버는 동적 콘텐츠에 대한 요청을 AP 서버에게 던지고 결과를 기다린다.

웹 서버부터 AP 서버까지

동적 컨텐츠에 대한 요청을 처리하는 것이 AP 서버다.

1. 웹 서버로부터 요청이 도착한다.
2. 스레드가 요청을 받으면 자신이 계산할 수 있는지, 아니면 DB 접속이 필요한지를 판단한다.
3. DB 접속이 필요하면 연결 풀에 액세스한다.
4. DB 서버에 요청을 던진다.

DB 서버 이외의 옵션

데이터를 DB 서버에 저장하는 것이 일반적이지만, 항상 효율적이라 할 수는 없다. 규모가 작고 갱신 빈도가 낮은 정보는 Java의 경우 JVM 내부에 캐시로 저장해두면 고속 처리가 가능하다.

반대로, 규모가 큰 정적 데이터 전송 시에는 CDN(Content Delivery Network)이라 불리는 데이터 전송 전용 서버를 이용하는 경우도 있다.

AP 서버부터 DB 서버까지

1. AP 서버로부터 요청이 도착한다.
2. 프로세스가 요청을 접수하고 캐시가 존재하는지 확인한다.
3. 캐시에 없으면 디스크에 액세스한다.
4. 디스크가 데이터를 반환한다.
5. 데이터를 캐시 형태로 저장한다.
6. 결과를 AP 서버에 반환한다.

인메모리 DB 등에서는 디스크 자체를 사용하지 않고 모든 처리를 메모리 내에서 완료하는 구조기 때문에 고속화를 실현할 수 있다.

AP 서버부터 웹 서버까지

DB 서버로부터 데이터가 도착한다.

스레드가 데이터를 가지고 계산 등을 한 후에 파일 데이터를 생성한다. (파일 외에도 HTTP로 전송 가능한 데이터라면 어떤 형태의 데이터든지 상관 없다)

결과를 웹 서버로 반환한다.

웹 서버부터 클라이언트 PC까지

1. AP 서버로부터 데이터가 도착한다.
2. 프로세스는 받은 데이터를 그대로 반환한다.
3. 결과가 웹 브라우저로 반환되고 화면에 표시된다.

웹 데이터의 흐름 정리

각 서버의 동작은 다르지만 다음과 같은 공통점이 있다.

프로세스나 스레드가 요청을 받는다.
도착한 요청을 파악해서 필요에 따라 별도 서버로 요청을 보낸다.
도착한 요청에 대해 응답한다.

3계층이라고 명명하고 있지만, 실제로는 3계층보다 많은 계층을 이용하는 경우가 대부분이다.

요청 기반 아키텍처이기 때문에 각 서버는 문을 열고 기다리고 있는 상태로, 어느 정도 요청이 올지는 실제 요청이 오기 전까지는 알 수 없다.

이것이 IT 인프라에서 성능 문제가 발생하는 이유 중 하나다.

가상화

가상화란 컴퓨터 시스템에서 물리 리소스를 추상화 하는 것이다. 물리 리소스에는 서버, 네트워크, 저장소 등이 있지만 여기서는 서버 가상화에 대해 알아본다.

OS도 가상화 기술의 하나

하드웨어를 의식하지 않고 애플리케이션을 실행할 수 있는 운영체제는 가상화 기술 중 하나라고 볼 수 있다.

OS의 커널에 의해 하드웨어가 추상화되면서, 컴퓨터에 연결된 기억 장치나 네트워크를 통한 데이터 교환이 하드웨어를 의식하지 않고 이뤄지고 있다.

가상 머신

가상 머신 방식에는 호스트 OS형과 하이퍼바이저형이 있다.

호스트 OS형

윈도우, 리눅스 등의 호스트 OS상에 가상화 소프트웨어를 설치해서 이용하는 것
소프트웨어를 에뮬레이터하는 것으로 성능면에서 제한이 있음
VMware Server, Microsoft Virtual Server 등

하이퍼바이저형

하드웨어상에서 직접 가상화 소프트웨어를 실행하고 그 위에 가상 머신을 동작시키는 기술
호스트 OS를 거치지 않으므로 호스트형보다 성능이 우수해서 서버 가상화의 대표 기술로 자리잡음
VMware vSphere, Hyper-V, Xen, KVM 등

하이퍼바이저형 가상화 구조에는 완전 가상화와 준가상화가 있다.

완전 가상화

물리 머신상에서 동작하는 OS나 드라이버를 그대로 게스트로 이용할 수 있음 단, 소프트웨어로 에뮬레이션학기 때문에 성능이 저하된다는 문제가 있음

준가상화

실존하는 하드웨어를 에뮬레이션하는 것이 아니라, 가상 환경용 가상 하드웨어를 소프트웨어적으로 에뮬레이션한다.

가상 환경에서 동작시키는 게스트 OS마다 준가상화 전용 드라이버나 준가상화용으로 최적화된 OS 커널을 사용해야 했음

이후 인텔이나 AMD 등의 프로세서 제조사가 가상 하드웨어 지원 기능을 개발해서 하이퍼바이저도 지원하게 되면서 현재는 완전 가상화가 자리 잡았다.

컨테이너의 역사

Docker의 등장 이후 컨테이너가 급속도로 유행하기 시작했다.

컨테이너는 리소스가 격리된 프로세스다. 하나의 OS 상에서 여러 개를 동시에 가동할 수 있으며, 각각 독립된 루트 파일 시스템, CPU/메모리, 프로세스 공간 등을 사용할 수 있다는 점이 하드웨어 가상화인 가상 머신과 차이다.

컨테이너의 출발은 1970년대 Bill Joy가 개발한 chroot라고 알려졌다.

1970년대 컴퓨터는 매우 비싸서 하나의 컴퓨터로 상용 환경과 개발 환경을 서로에게 영향을 주지 않으면서 함께 사용하기 위해 등장한 것이 chroot다. 프로세스가 OS의 루트 디렉터리 아래에 있는 특정 계층에 접근하지 못하도록 하는 기능이다.

1990년대 특정 디렉터리 이하를 루트 디렉터리처럼 보이게 하는 개념이 추가됐으며, 이를 통해 애플리케이션의 프로세스도 격리할 수 있게 되었다.

2000년대 Sun Microsystems는 솔라리스 컨테이라 불리는 컨테이너 기능을 제공했다.

도커의 등장

2013년 컨테이너에 파일 시스템과 프로세스를 분리하는 기능이 추가되면서, 파일 시스템 이미지의 패키징과 버저닝이 가능해졌고 컨테이너 이미지를 공유할 수 있는 도 커가 등장함으로써 컨테이너 기술이 주목 받기 시작했다.

도커 이미지는 원래 클라우드 내부 구조로 개발했던, 애플리케이션 실행 환경을 자동 구축해주는 기술 기술이다.

클라우드 이외의 환경에서도 사용할 수 있게 오픈 소스로 공개 + 이미지를 공유할 수 있는 레지스트리 도커 허브의 등장으로 인기를 얻기 시작.

가상 머신과 비교해서 도커가 지니는 장점은 다음과 같다.

컨테이너는 호스트 OS와 OS 커널을 공유하므로 컨테이너 실행이나 정지 속도가 빠르다.

호스트 OS의 커널을 공유하므로 VM만 사용하는 경우와 비교해 한 대의 호스트 머신상에서 훨씬 많은 컨테이너를 실행할 수 있다. 
이를 통해 리소스를 한 곳에서 쉽게 관리할 수 있다.

도커는 라이브러리나 프레임워크 등을 도커 이미지로 묶어서 공유할 수 있음. 
특정 환경에서는 재현되지만 자신의 개발 환경에서는 재현되지 않는 문제가 발생하기 어렵다. 
따라서 버그를 효율적으로 수정할 수 있다.

클라우드와 가상화 기술

하이퍼바이저 및 컨테이너 등의 가상화 기술은 구글이나 페이스북, 아마존 등의 대규모 웹 서비스에서 사용되고 있다.

AWS, GCP, Azure 등의 클라우드 서비스에서는 가상 머신 서비스, 컨테이너 서비스, Function as a Service 서비스나 다른 기타 서비스를 지탱하는 기술로 이용되고 있다.