[Chromium] 멀티 프로세스 아키텍쳐 (Multi-process Architecture)

문제

충돌하거나 멈추지 않는 렌더링 엔진을 만드는 것은 거의 불가능하다. 완벽하게 안전한 렌더링 엔진을 만드는 것도 거의 불가능하다.

어떤 면에서, 2006년 경의 웹브라우저는 단일 사용자, 협업 멀티 태스킹 운영체제와 비슷했다. 이러한 운영체제에서 한 어플리케이션의 오작동은 전체 시스템을 파괴시킬 수도 있었으므로, 이것은 웹 브라우저에서 오작동하는 웹페이지가 될 수도 있다. 하나의 브라우저나 플러그인 버그가 전체 브라우저와 모든 실행중인 탭을 제거할 수 있다는 말이다.

 

현대의 운영체제는 더욱 견고해졌다. 왜냐하면 그들이 애플리케이션을 서로 분리된 다른 프로세스로 분산시켰기 때문이다. 한 애플리케이션의 충돌은 다른 애플리케이션이나 운영체제의 무결성을 손상시키지 않으며 다른 사용자의 데이터에 대한 접근도 제한된다.

 

개요

렌더링 엔진에서는 버그와 작은 결함으로부터 전체의 애플리케이션을 보호하기 위해서 브라우저 탭 별로 다른 프로세스를 사용한다. 또한 각 렌더링 엔진 프로세스가 다른 프로세스나 나머지 시스템에 접근하는 것을 제한한다. 어떤 면에서, 메모리 보호 및 액세스 제어가 운영체제로 가져오는 이점을 웹에서도 찾아볼 수 있다.

UI를 실행하고 탭 및 플러그인 프로세스를 "브라우저 프로세스" 또는 "브라우저"로 관리하는 기본 프로세스를 참조한다. 마찬가지로, 탭에 관한 프로세스는 "렌더 프로세스" 또는 "렌더러"라고 부른다. 렌더러는 HTML을 해석하고 배치하기위해 Blink라는 오픈소스 레이아웃 엔진을 사용한다.

 

렌더 프로세스 관리

각 렌더 프로세스는 RenderProcess 라는 전역 객체를 가지고있다. 이것은 부모 브라우저 프로세스와의 통신을 관리하고 전역 상태를 유지 관리한다. 브라우저는 각각의 렌더 프로세스에 해당하는 RenderProcessHost를 유지 관리한다. 렌더 프로세스는 브라우저의 상태와 렌더러와의 커뮤니케이션을 관리한다. 브라우저와 렌더러는 크로미움의 IPC 시스템 을 사용해 통신한다.

 

뷰 관리

각 렌더 프로세스는 하나 이상의 RenderView 객체를 가지고있다. 이는 탭 내용에 해당하는 RenderProcess에 의해 관리된다. 해당 RenderProcessHost는 렌더러 내의 각 뷰에 해당하는 RenderViewHost를 유지한다. 각 뷰는 같은 렌더러 내의 여러 개의 뷰를 식별하기 위해 사용되는 뷰 ID를 할당받는다. 이 아이디는 렌더러 내에서는 유니크하지만 브라우저 내에서는 아니다. 그래서 뷰를 식별하기 위해서는 RenderProcessHost와 뷰 ID가 필요하다. 브라우저로부터 특정 탭까지의 통신은 RenderViewHost 객체를 통해 이루어진다. 이 객체는 RenderProcessHost를 통해서 RenderProcess와 RenderView로 메시지 보내는 방법을 알고있다.

 

컴포넌트와 인터페이스

 

렌더 프로세스에서 :

• 브라우저 내에서 RenderProcess 는 IPC와 연관된 RenderProcessHost 를 다룬다. 렌더 프로세스마다 정확히 하나의 RenderProcess 객체가 있다. 이것이 모든 브라우저 <-> 렌더러 통신이 이루어지는 방식이다.
• RenderView 객체는 브라우저 프로세스와 WebKit 임베딩 레이어에서 연관된 RenderViewHost 객체와 통신한다. (RenderProcess를 통해서) 이 객체는 탭이나 팝업창 내의 내용을 나타낸다.

브라우저 프로세스에서:

• Browser 객체는 최상위 레벨 브라우저 창을 나타낸다.
• RenderProcessHost 객체는 단일 브라우저 <-> 렌더러 IPC 연결의 브라우저 측면을 나타낸다. 브라우저 프로세스의 각 렌더 프로세스에는 하나의 RenderProcessHost가 있다.
• RenderViewHost 객체는 원격 RenderView 와의 통신을 캡슐화하고, RenderWidgetHost 는 입력 및 RenderWidget 을 위한 페인팅을 브라우저에서 처리한다.

이 임베딩 동작이 동작하는 원리에 대한 자세한 사항은, 크로미움이 웹페이지를 어떻게 나타내는가 를 참고하라.

 

렌더러 프로세스 공유

일반적으로, 각각의 새로운 창이나 탭은 새로운 프로세스로 열린다. 브라우저는 새로운 프로세스를 생성하고 RenderView를 생성하도록 지시할 것이다.

가끔 탭이나 창 사이에 렌더 프로세스를 공유해야할 필요가 있다. 웹 애플리케이션은 JavaScript로 window.open를 실행하는 것과 같이 동기적으로 통신하며 새로운 창을 연다. 새로운 창이나 탭을 만들때, 이미 열려있는 창의 프로세스를 다시 사용해야한다. 프로세스의 갯수가 너무 많을 때나 사용자가 이미 프로세스를 열어 해당 도메인으로 이동한 경우 새로운 탭을 이미 존재하는 프로세스에 할당하는 몇가지 전략이 있다. 그 전략들은 프로세스 모델 에 설명되어있다.

 

충돌이나 렌더러 오작동 감지

브라우저 프로세스에 대한 IPC 연결은 프로세스 처리를 감시한다. 만약 시그널이 감지되면, 렌더 프로세스는 충돌이 일어났거나 탭이 충돌을 알린 것이다. 지금은 충돌이 일어나면 사용자에게 "슬픈 탭" 화면을 보여준다. 페이지는 새로고침 버튼이 눌리거나 새로운 검색을 시작할 때 다시 로드된다. 이 상황에서, 우리는 프로세스가 없다는 것을 알아차리고 새로운 프로세스를 만든다.

 

Sandboxing the renderer

주어진 렌더러는 서로 다른 프로세스에서 돌아간다. 샌드박싱을 통해서 시스템 자원에 접근하는 것을 막을 수 있다. 예를 들어, 우리는 렌더러가 부모 브라우저 프로세스를 통해서만 네트워크에 접근하는 것을 보장할 수있다. 이와 같이, 우리는 호스트 운영체제의 내장된 권한을 이용해서 파일 시스템에 대한 접근을 제한할 수 있다.

파일시스템과 네트워크에 대한 렌더러의 접근을 제한하는 것뿐만 아니라, 사용자의 화면과 관련된 객체들에 대한 접근에 대한 제한도 둘 수 있다. 각각의 렌더 프로세스는 분리된 창 "데스크탑" (유저에게 보이지 않는다.) 에서 돌아간다. 이렇게하면 손상된 렌더러가 새창을 열거나 키 입력을 캡쳐하지 못한다.

 

메모리 되찾기

렌더러가 별도의 프로세스에서 실행되는 경우 숨겨진 탭을 낮은 우선순위로 처리하는 것이 좋다. 일반적으로 Windows의 최소화된 프로세스들은 자동으로 그들의 메모리를 "사용 가능한 메모리" 풀에 넣는다. 메모리가 부족한 상황에서 Windows는 우선순위가 높은 메모리를 교체하기 전에 이 메모리를 디스크로 스왑하여 사용자가 볼수있는 프로그램의 응답 속도를 향상시킨다. 동일한 원칙을 숨겨진 탭에도 적용할 수 있다. 렌더 프로세스에 최상위 탭이 없는 경우, 시스템의 힌트로 해당 프로세스의 'working set' 크기를 릴리즈하여 해당 메모리를 디스크로 스왑할 수 있다. working set의 크기를 줄이면 두 탭 사이를 전환할 때 탭 전환 성능도 저하된다는 것을 알았기 때문에 이 메모리를 점진적으로 해제한다. 즉, 사용자가 최근에 사용한 탭으로 다시 전환하면 해당 탭의 메모리가 최근 사용되지 않은 탭보다 페이징 될 가능성이 높아진다. 모든 프로그램을 실행하기에 충분한 메모리를 가진 사용자는 이 프로세스를 전혀 알지 못한다. Windows는 실제로 필요한 경우에만 이러한 데이터를 회수하므로 충분한 메모리가 있다면 성능에 영향을 주지 않는다.

 

플러그인과 확장

파이어폭스 스타일의 NPAPI 플러그인은 렌더러에서 분리된 각각의 프로세스에서 실행된다. 이에 대한 자세한 설명은 플러그인 구조에 설명되어있다. 이 사이트 분리 프로젝트는 렌더러 사이에서 더 고립되도록 하기위한 목적이다. 사이트 격리 프로젝트는 렌더러간에 더 많은 고립을 제공하는 것을 목표로하며, 이 프로젝트의 초기 산출물에는 격리된 프로세스에서 Chrome의 HTML / JavaScript 콘텐츠 확장을 실행하는 것이 포함된다.

 

출처:

https://www.chromium.org/developers/design-documents/multi-process-architecture 

Multi-process Architecture - The Chromium Projects