CPU, GPU, Memory and Multi process
CPU
첫 번째로 볼 부품은 CPU(central processing unit, 중앙처리장치)이다. CPU는 컴퓨터의 두뇌라 할 수 있다. 다음 그림에서 사무원으로 묘사된 CPU 코어는 여러 종류의 작업을 하나씩 순서대로 처리할 수 있다. CPU 코어는 수학이나 예술은 물론 고객 전화에 응대하는 방법도 알고 있다. 예전에는 대부분의 CPU가 단일 칩이었다. CPU 코어 하나는 동일한 칩에 있는 또 다른 CPU나 마찬가지이다. 최신 하드웨어는 보통 하나 이상의 코어를 사용해 스마트폰이나 노트북의 실행 성능을 높인다.
GPU
GPU(graphics processing unit, 그래픽처리장치)는 컴퓨터의 또 다른 부품이다. CPU와 달리 GPU는 간단한 작업에만 특화되어 있지만 여러 GPU 코어가 동시에 작업을 수행할 수 있다. 그래픽처리장치라는 이름에서 알 수 있듯이 GPU는 그래픽 작업을 처리하기 위해 개발되었다. 그래서 그래픽 관련 설명에서 "GPU를 사용한다"나 "GPU의 지원을 받는다"와 같은 말이 빠른 렌더링과 매끄러운 상호작용에 관련된 표현이다. 최근 몇 년 동안 GPU 가속을 통해 GPU가 단독으로 처리할 수 있는 계산이 점점 더 많아졌다.
프로세스와 스레드로 프로그램 실행
브라우저 아키텍처를 살펴보기 전에 파악해야 할 또 다른 개념은 프로세스와 스레드이다. 프로세스는 애플리케이션이 실행하는 프로그램이라 할 수 있다. 스레드는 프로세스 내부에 있으며 프로세스로 실행되는 프로그램의 일부를 실행한다.
애플리케이션을 시작하면 프로세스가 하나 만들어진다. 프로세스가 작업을 하기 위해 스레드를 생성할 수도 있지만 선택 사항이다. 운영체제는 프로세스가 작업할 메모리를 "한 조각" 주는데, 이 전용 메모리 공간에 애플리케이션의 모든 상태가 저장된다. 애플리케이션을 닫으면 프로세스가 사라지고 운영체제가 메모리를 비운다.
프로세스는 여러 작업을 수행하기 위해 운영체제에 다른 프로세스를 실행하라고 요청할 수 있다. 그러면 메모리의 다른 부분이 새 프로세스에 할당된다. 두 프로세스가 서로 정보를 공유해야 할 때는 IPC(inter process communication, 프로세스 간 통신)를 사용한다. 많은 애플리케이션이 이러한 방식으로 작동하도록 설계되어 있다. 그래서 작업 프로세스가 응답하지 않을 때 애플리케이션의 다른 부분을 실행하는 프로세스를 중지하지 않고도 응답하지 않는 프로세스를 다시 시작할 수 있다.
브라우저 아키텍처
여기에서 주목해야 할 중요한 점은 이러한 서로 다른 아키텍처가 구현 세부 사항이라는 점이다. 브라우저를 만드는 방법에 대한 표준은 없다. 브라우저마다 접근 방식이 완전히 다를 수 있다.
제일 위에 있는 브라우저 프로세스는 애플리케이션의 각 부분을 맡고 있는 다른 프로세스를 조정한다. 렌더러 프로세스는 여러 개가 만들어져 각 탭마다 할당된다. 최근까지 Chrome은 탭마다 프로세스를 할당했다.
프로세스 | 프로세스가 제어하는 부분 |
브라우저 프로세스 | 주소 표시줄, 북마크 막대, 뒤로 가기 버튼, 앞으로 가기 버튼 등 애플리케이션의 "chrome" 부분을 제어한다. 네트워크 요청이나 파일 접근과 같이 눈에 보이지는 않지만 권한이 필요한 부분도 처리한다. |
렌더러 프로세스 | 탭 안에서 웹 사이트가 표시되는 부분의 모든 것을 제어한다. |
플러그인 프로세스 | 웹 사이트에서 사용하는 플러그인(예: Flash)을 제어한다. |
GPU 프로세스 | GPU 작업을 다른 프로세스와 격리해서 처리한다. GPU는 여러 애플리케이션의 요청을 처리하고 같은 화면에 요청받은 내용을 그리기 때문에 GPU 프로세스는 별도 프로세스로 분리되어 있다. |
다중 프로세스 아키텍처가 Chrome에 주는 이점
Chrome이 렌더러 프로세스를 여러 개 사용한다고 설명했다. 가장 간단한 예로 탭마다 렌더러 프로세스를 하나 사용하는 경우를 생각해 보자. 3개의 탭이 열려 있고 각 탭은 독립적인 렌더러 프로세스에 의해 실행된다. 이때 한 탭이 응답하지 않으면 그 탭만 닫고 실행 중인 다른 탭으로 이동할 수 있다. 만약 모든 탭이 하나의 프로세스에서 실행 중이었다면 탭이 하나만 응답하지 않아도 모든 탭이 응답하지 못하게 된다.
브라우저의 작업을 여러 프로세스에 나눠서 처리하는 방법의 또 다른 장점은 보안과 격리(sandbox)이다. 운영체제를 통해 프로세스의 권한을 제한할 수 있어 브라우저는 특정 프로세스가 특정 기능을 사용할 수 없게 제한할 수 있다. 예를 들어 Chrome은 렌더러 프로세스처럼 임의의 사용자 입력을 처리하는 프로세스가 임의의 파일에 접근하지 못하게 제한한다. (액티브 엑스는 되더라...)
프로세스는 전용 메모리 공간을 사용하기 때문에 공통부분(예를 들어 Chrome의 JavaScript 엔진인 V8)을 복사해서 가지고 있는 경우가 많다. 동일한 프로세스의 스레드가 메모리를 공유할 수 있는 데 반해 서로 다른 프로세스는 메모리를 공유할 수 없어 메모리 사용량이 더 많아질 수밖에 없다. Chrome은 메모리를 절약하기 위해서 실행할 수 있는 프로세스의 개수를 제한한다. 정확한 한도는 기기의 메모리 용량과 CPU 성능에 따라 다르지만 프로세스의 개수가 한도에 다다르면 동일한 사이트를 열고 있는 여러 탭을 하나의 프로세스에서 처리한다. --> 최대 호출 할 수 있는 양이 정해져 있음
레임별로 실행되는 렌더러 프로세스 - 사이트 격리
사이트 격리(site isolation)는 Chrome에서 최근 도입된 기능으로, iframe의 사이트를 별도의 렌더러 프로세스에서 실행하는 것이다. 탭마다 렌더러 프로세스를 할당하는 모델에서는 iframe의 사이트가 같은 렌더러 프로세스에서 작동하기 때문에 서로 다른 사이트 간에 메모리가 공유될 수 있다는 문제가 있어 지속적으로 논의가 있었다. a.com 사이트의 웹 페이지와 b.com 사이트의 웹 페이지를 동일한 렌더러 프로세스에서 실행하는 것이 문제가 없어 보일 수 있다. 하지만 동일 출처 정책(same origin policy)은 웹 보안 모델의 핵심이다. 한 사이트는 동의 없이 다른 사이트의 데이터에 접근할 수 없어야 한다. 이 정책을 우회하는 것이 바로 보안 공격의 주요 목표이다. 프로세스를 격리하는 것이 사이트를 격리하는 가장 효과적인 방법이다. Meltdown과 Spectre 사태로 여러 프로세스를 사용해 사이트를 격리해야 한다는 것이 더욱 분명해졌다. Chrome 67부터 데스크톱에서 사이트 격리를 기본으로 사용하도록 설정하면서 탭에서 iframe의 사이트에 별도의 렌더러 프로세스가 적용된다.
Last updated
