위 출처의 내용의 번역본 입니다.
자세한 내용은 원문을 참고해주세요.
CPU, GPU, Memory 및 Multi Process 아키텍처
앞으로 이어질 4부작 블로그 시리즈에선 고급 아키텍쳐부터 렌더링 파이프라인의 세부사항까지 Chrome 브라우저의 내부를 살펴볼 것입니다.
브라우저가 어떻게 당신의 코드를 잘 동작하는 웹사이트로 변환하는지 궁금해해 본 적이 있거나 성능향상을 위해 특정 기술이 왜 제안되고있는건지 확실치 않는다면, 앞으로 이어질 글들을 꼭 읽어보세요!
이 시리즈의 1부에선 핵심 컴퓨팅 용어와 Chrome의 multi 프로세스 아키텍처에대해 알아보겠습니다.
컴퓨터의 핵심은 CPU와 GPU
브라우저 동작환경을 이해하기 위해선 컴퓨터의 몇 가지 부품과 그 역할을 알 필요가 있습니다.
CPU
첫 번째는 중앙 처리 장치(Central Processing Unit - CPU)입니다.
CPU는 컴퓨터의 두뇌라고 불리며 위 그림에서 한명의 회사원으로 묘사된 CPU코어는 매우 다양한 작업을 하나씩 처리할 수 있습니다.
고객이 요청하기만 하면 수학부터 그림에 이르기까지 못하는게 없죠.
과거엔 대부분의 CPU가 하나의 칩이었습니다. 그 당시 코어는 같은 칩에 들어있을 뿐 다른 CPU라 볼 수 있었습니다.
최근엔 스마트 폰이나 노트북에서도 높은 성은을 발휘하는 멀티코어를 흔히 볼 수 있게 됐습니다.
GPU
Graphics Processing Unit - GPU 는 컴퓨터의 다른 부분입니다.
CPU와 달리 GPU는 간단한 작업을 처리하는데 좋지만 동시에 여러개의 코어에 걸쳐있습니다. (이게 무슨말이지? )
이름에서 보듯, GPU는 처음에 그래픽처리를 위해 개발되었습니다.
"GPU사용함" 또는 "GPU지원됨"이런 말들이 빠른 렌더링 과 부드러운 interaction과 관련된 이유입니다.
최근 몇년간, GPU-accelerated computing을 통해서 점점 더 많은 연산이 GPU하나만으로도 가능해지고 있습니다.
( GPU만으로 작동하는 컴퓨터가 생겨나게 될까? 아니면 GPU는 GPU대로 성능이 좋아지면서 CPU도 더 좋아질 테니까 더 빠르고 복잡한 연산을 하는 컴퓨터가 보급화 될까? )
컴퓨터나 핸드폰에 어플리케이션을 시작할 때, CPU와 GPU는 어플리케이션에 전원을 공급합니다.
일반적으로, 어플리케이션은 운영체제에서 제공하는 메커니즘을 이용하여 CPU와 GPU 상에서 실행됩니다.
Process와 Thread에서 프로그램 실행하기
브라우저 아키텍처에 뛰어들기 전에 알아야 할 또다른 개념은 "Process(프로세스)와 Thread(쓰레드)"입니다.
- Process : 프로세스는 어플리케이션의 실행 프로그램이라 묘사되며
- Thread : 스레드는 프로세스 내부에 존재하면서 프로세스의 프로그램의 모든 부분을 실행합니다.
처음 어플리케이션을 시작하면, 프로세스가 만들어집니다.
프로그램은 쓰레드(들)을 만들어 프로세스가 동작하는걸 돕게하지만 이는 선택사항입니다.
운영체제는 프로세스에게 작동을 위한 메모리"slab"을 제공하고 모든 어플리케이션의 state는 해당 개인 메모리 공간에서 유지됩니다.
Slab?
"Slab allocation is a memory management mechanism intended for the efficient memory allocation of objects. "
"A slab is the amount by which a cache can grow or shrink. It represents one memory allocation to the cache from the machine, and whose size is customarily a multiple of the page size."
-> slab이란 용어를 처음 들어봐서 찾아보았다.
Slab allocation이란 것은 objects의 효율적 메모리 할당을 위해 고안된 '메모리 관리 메커니즘'이고
Slab은 캐시를 확장하거나 축소할 수 있는 양을 말하며 기기에서 cache에 할당된 하나의 메모리 할당량을 의미한다고 한다고 간략히 이해하고 넘어감.
어플리케이션을 닫으면, 프로세스 또한 사라지고 운영체제는 메모리를 확보하게 됩니다.
프로세스는 운영체제에 다른 프로세스가 다른 작업을 실행되도록 요청할 수도 있습니다.
그렇게되면 메모리의 다른 부분이 새로운 프로세스에 할당됩니다.
두 프로세스가 통신해야하는 경우엔 IPC (Inter Process Communication)를 사용하여 통신할 수 있습니다.
많은 어플리케이션이 이런식으로 동작하도록 디자인되어있으므로 다른 worker프로세스에서 응답이 없더라도 다른 프로세스(어플리케이션의 다른 파트에서 운영중인 프로세스)를 중단하지 않고도 재시작될 수 있는 것입니다.
Browser 아키텍처
그렇다면 웹 브라우저는 process와 thread를 사용하여 어떻게 만들어진걸까요?
( 웹 브라우저또한 프로그램의 일종입니다. 그러므로 process와 thread로 동작할텐데 그 내부구성은 어떻게 되어있을까요?)
글쎄요, 다수의 thread가 있는 하나의 process이거나
적은 수의 스레드를 가진 여러개의 프로세스가 있어 서로 IPC로 통신하는 형태일 수도 있습니다.
여기서 주목할 중요한 점은 이러한 다양한 아키텍처는 구현 세부사항이라는 것입니다.
웹 브라우저를 만드는데 표준 규격은 존재하지 않습니다.
어떤 브라우저에서의 접근법은 다른 브라우저와는 완전히 다를 수 있습니다.
이 블로그 시리즈를 위해선 우리는 아래의 Chrome의 최신 아키텍처를 사용해보도록 하겠습니다.
가장 상위엔 다른 프로세스들을 관리하는 "browser 프로세스"가 있습니다.
- "renderer 프로세스"의 경우, 여러개의 프로세스가 만들어지면 tab마다 할당됩니다.
매우 최근까진 Chrome은 가능한 각 tab마다 하나의 프로세스를 제공했습니다.;
지금은 iframe을 포함하여 각 사이트마다 고유한 프로세스를 제공하려고 합니다.
각각의 Process는 무엇을 제어하는걸까?
아래의 표에서 각각의 Chrome프로세스가 무엇을 컨트롤하는지 설명하고 있습니다.
-
Browser Process :
address bar (주소표시줄), 북마트, 뒤로가기와 앞으로 가기 버튼을 포함한 어플리케이션의 "chrome"파트를 컨트롤합니다.
또한 네트워크 요청과 파일접근 같은 웹브라우저의 보이지 않으면서 권한이 필요한 부분을 다룹니다. -
Renderer Process :
웹사이트가 보여지는 tab내부의 모든 것을 컨트롤합니다. -
Plugin Process :
웹사이트에서 사용되는 모든 플러그인들을 컨트롤합니다. 예) flash, 광고차단 플러그인... -
GPU Process :
다른 프로세스와 분리되어 GPU작업을 처리합니다.
왜냐하면 GPU는 여러 앱의 요청을 처리하면서 같은 화면에 그것들을 그려야하기 때문입니다.
여러 사이트를 켜둔 상태라면 내가 지금 보고 있는 게 A사이트여도 GPU는 B사이트도 관리하고 있어야 해서? 그런가보다..
Extension프로세스와 Utility프로세스 같은 훨씬 더 많은 프로세스가 존재합니다.
Chrome에서 얼마나 많은 프로세스가 돌아가고 있는 지 보고싶다면, 옵션 메뉴 아이콘을 눌려서 도구_더보기의 오른쪽 코너에서 작업 관리자를 클릭해보세요.
현재 동작중인 프로세스 목록을 보여주면서 얼마나 CPU와 메모리가 사용되고 있는지 보여줍니다.
Chrome에서 multi process 아키텍처의 이점
앞서 Chrome은 다중 렌더러 프로세스를 사용한다고 언급했습니다.
가장 간단한 경우에는 각 탭에 자체 렌더러 프로세스가 있다고 상상할 수 있습니다.
3개의 탭이 열려 있고 각 탭이 독립적인 렌더러 프로세스에 의해 실행된다고 가정해보면,
한 탭에서 응답이 없으면 응답하지 않는 탭은 닫고 다른 탭을 활성 상태로 유지하면서 계속 이동할 수 있습니다.
모든 탭이 하나의 render프로세스에서 실행 중이었다면 한 탭이 응답하지 않으면 다른 모든 탭도 응답하지 않게되었겠지요. 이는 슬픈 일이지요. ㅠㅠ
이런 이유때문에 Chrome은 멀티 프로세스를 갖는 구조로 설계되었나보다!
브라우저의 작업을 여러 프로세스로 분리하는 것의 GPU Process 또 다른 이점은 보안과 샌드박싱입니다.
운영체제는 프로세스의 권한을 제한하는 방법을 제공하므로 브라우저는 특정기능에서 특정 프로세스를 샌드박싱할 수 있습니다.
샌드박싱?이란게 뭐지?
일단은 "특정 프로세스가 특정기능을 수행할 수 없도록 제한하는 것"이라고 이해했음.
예를들어, Chrome브라우저는 렌더러 프로세스와 같이 임의의 사용자 입력을 처리하는 프로세스가 임의의 파일에 접근하는 것을 제한합니다.
프로세스는 저마다 고유한 개인메모리 공간이 있기 때문에, 공통된 인프라의 복사본(예.V8-자바스크립트엔진)을 포함하는 경우가 있습니다.
이 말인 즉슨 같은 프로세스 내에 존재하는 스레드였다면 공유했을텐데 그렇지 않기 때문에 더 많은 메모리를 사용해야한다는 말 이기도 합니다.
그래서 메모리 절약을 위해 Chrome은 돌릴 수 있는 프로세스의 수를 제한합니다.
사용자의 기기의 CPU성능과 메모리가 얼만큼인가에 따라 다르지만,
Chrome은 한도에 도달하면 하나의 프로세스에서 동일한 사이트의 여러 탭을 실행하기 시작합니다.
지금까지 이해한 바로는 Chrome은 하나의 프로세스안에 여러 역할을 하는 스레드로 구성되어있는게 아니라, 각각의 역할을 하는 다수의 프로세스로 구성되도록 설계했다.
이 다수의 프로세스들이 공통된 인프라(예. V8) 사용을 위해 프로세스 저마다 공통된 인프라의 복사본을 내부에 지니고 있다고한다.
이렇게 되면 아무래도 더 많은 메모리를 사용하게 되는 것이기에
Chrome은 ( 기본적으론 하나의 탭 마다 프로세스를 갖도록 되어있지만)
메모리 절약을 위해 돌릴 수 있는 프로세스의 한계에 도달하면
여러 탭에 열려있는 동일한 사이트에 대해선 하나의 프로세스에서 관리되도록 설계해두는 방식으로
메모리를 절약할 수 있다고 한다.
( ps.Chrome이 돌릴 수 있는 프로세스의 수는 기기의 메모리와 CPU성능에 따라 다르다.)
더 많은 메모리 절약 - Chrome에서의 서비스
browser프로세스에도 동일한 접근방식이 적용되어졌습니다.
Chrome은 브라우저 프로그램의 각 부분을 다른 프로세스로 쉽게 분할하거나 하나로 통합할 수 있는 서비스로 실행시키기위해 아키텍쳐 변경 중에 있습니다.
일반적인 아이디어는 Chrome이 강력한 하드웨어에서 실행될 때,
각 서비스를 다른 프로세스 나눠서 안정성을 제공하고자 하지만
만약 리소스가 제한된 기기에서 실행되는 경우엔 Chrome은 메모리 절약을 위해 하나의 프로세스로 각각의 서비스를 통합한다는 것입니다.
Android와 같은 플랫폼에서 메모리 사용을 줄이기위해 프로세스를 통합하는 비슷한 접근법이 사용되었습니다.
프레임별 렌더러 프로세스 - 사이트 격리
'사이트 격리'는 최근 Chrome에 도입된 기능으로 cross-site-iframe에 별도의 renderer프로세스가 실행되도록 합니다.
우리는 서로 다른 사이트간에 메모리 공간을 공유하면서 단일 renderer프로세스에서 cross-site-iframe이 동작할 수 있게하는 탭당 하나의 render프로세스 모델에대해 이야기했습니다.
iframe?
"The<iframe>HTML element represents a nested browsing context, embedding another HTML page into the current one."
동일한 renderer프로세스에서 a.com과 b.com을 실행시키는 것은 괜찮아 보이겠지만
'동일 출처 정책'은 웹의 핵심 보안 모델입니다.
; 동일출처정책(Same Origin Policy)이라하믄 동의없이는 한 사이트에서 다른 사이트의 데이터에 접근이 불가능하다는 것을 말합니다.
이 정책을 넘겨버리는 것이 보안공격의 주 목적이기도 합니다.
따라서 프로세스 격리는 사이트를 분리하는 가장 효과적인 방법입니다.
Meltdown과 Spectre로 프로세스를 사용해 사이트를 분리해야 하는 것은 더욱 분명해졌습니다.
Chrome 67부터는 기본적으로 데스크톱에서 사이트격리를 사용하도록 설정하면 탭의 각 사이트간 iframe에 별도의 프로세스가 적용됩니다.
Meltdown과 Spectre는 뭘까?
이 문서도 추후에 읽어봐야지..!
동일한 render프로세스에서 서로다른 사이트를 동작시키는게 괜찮아 보일 순 있지만,
'동일 출처 정책'이 웹의 핵심 보안 모델이라고 한다.
그러므로 이러한 정책을 지키기위해선 프로세스 자체를 따로 분리하는게 보안에 더 좋다고 이해했다.
그래서<iframe>으로 다른 사이트의 데이터를 보여줘야할 땐
얘를 위한 renderer프로세스를 또 따로 만드는 것이구나!라고 이해했다.
사이트 격리를 가능케하는 것은 다년간의 엔지니어링 노력이 필요한 작업이었습니다.
사이트 격리는 다른 렌더러 프로세스를 할당하는 것만큼 간단하지 않습니다.
iframe이 서로 통신하는 방식을 근본적으로 변경합니다.
다른 프로세스에서 실행되는 iframe이 있는 페이지에서 devtools를 열면 devtools가 원활한 것처럼 보이도록 하는 비하인드 작업을 구현해야 했습니다.
페이지에서 단어를 찾기 위한 간단한 Ctrl+F를 실행하는 것조차도 다른 렌더러 프로세스에서 검색하는 것을 의미합니다.
브라우저 엔지니어가 Site Isolation출시를 주요 마일스톤이라 말하는 이유이기도 합니다!
