이 글은 아래 원문을 번역한 글로 의역이 있을 수 있습니다. 정확한 의미를 파악하고 싶으신 분은 원문을 참고해주시기 바랍니다.
원문: https://developer.chrome.com/blog/inside-browser-part1
저작권 정보: https://developer.chrome.com/blog
CPU, GPU, Memory, 그리고 멀티 프로세스 아키텍처
4부작으로 된 이 블로그 시리즈에서는, 크롬 브라우저의 내부를 고수준의 아키텍처부터 렌더링 파이프라인의 구체적인 내용까지 살펴볼 것이다. 브라우저가 당신이 짠 코드를 어떻게 기능적인 웹사이트로 바꾸는지, 혹은 왜 특정 기술이 성능 향상을 위해 추천되고는 하는지 잘 모르겠다면, 바로 이 시리즈를 보면 된다.
시리즈의 파트 1 에서는, 컴퓨터의 코어 한 용어와 Chrome의 멀티 프로세스 아키텍처에 대해서 알아볼 것이다.
CPU/GPU 와 프로세스/스레드 개념에 대해 잘 알고 있다면, 바로 Browser Architercutre 부분으로 건너뛰어도 된다.
컴퓨터의 코어인 CPU와 GPU
브라우저가 실행되는 환경을 이해하기 위해서는, 먼저 컴퓨터의 몇몇 부분과 그것들이 뭘 하는지 이해할 필요가 있다.
CPU
중앙 프로세싱 유닛(Central Processing Unit) 혹은 CPU를 먼저 얘기해보겠다.
CPU는 컴퓨터의 두뇌 같은 거라고 생각하면 된다. CPU 코어는, 그림에 보이는 오피스 노동자직원 처럼 많은 다른 작업들을, 들어오는 대로 하나씩 처리할 수 있다. 고객 전화에 어떻게 응답해야 하는지 알고 있으면서도 수학부터 미술까지, 모든 것을 다룰 수 있다. 과거 대부분의 CPU 들은 하나의 칩이었다. 코어는 같은 칩 내부에 있는 다른 CPU 같은 것이다. 현대의 하드웨어는 1개 이상의 코어를 가진 경우가 많아서, 전화기나 노트북의 성능이 향상되기도 한다.
GPU
그래픽 프로세싱 유닛(Grapic Processing Unit) 혹은 GPU는 컴퓨터의 또 다른 부분이다. CPU와 달리, GPU 는 간단한 일들을 처리하지만, 동시에 여러개의 코어들로 처리할 수 있다. 이름에서 알 수 있듯이, 그것은 그래픽을 다루기 위해 먼저 개발되었다. 이게 바로 “GPU 사용” 또는 “GPU 지원” 이 빠른 렌더링과 부드러운 인터렉션과 관련이 있는 이유다. 최근 들어서는, GPU 가속화 컴퓨팅에 의해, 점점 더 GPU 로만 연산 할 수 있는 경우가 증가하고 있다.
컴퓨터나 폰에 있는 앱을 실행할 때, CPU와 GPU 가 앱이 돌아갈 수 있게 해준다. 통상 앱은 OS 가 제공하는 메카니즘을 사용해 CPU 와 GPU 위에서 동작하게 된다.
프로세스와 스레드 위에서 실행하는 프로그램
브라우저 아키텍처에 뛰어들기 전에 프로세스와 스레드라는 또 다른 개념을 이해해야 한다. 프로세스는 실행 중인 애플리케이션 프로그램이라고 할 수 있다. 스레드는 프로세스 내부에서 살아 있는 것 중 하나이고, 프로세스의 프로그램의 일 부분으로서 실행된다.
애플리케이션을 실행할 때, 프로세스가 생성된다. 프로그램은 그것의 작업을 돕기 위해 스레드들을 만든다. 하지만 스레드를 만드는 것은 선택 사항이다. OS는 프로세스에 사용할 수 있는 메모리 “slab(조각)” 을 준다. 그리고 모든 애플리케이션 상태는 프라이빗한 메모리 공간에서 유지가 된다. 애플리케이션을 닫으면, 프로세스는 없어지고 OS 도 그 메모리를 비운다.
프로세스는 OS에 다른 프로세스를 스핀업 해서 다른 작업들을 실행할 수 있도록 요청할 수 있다. 이런 일이 발생할 때, 메모리의 다른 부분들은 새로운 프로세스에 할당이 된다. 두 개의 프로세스들이 통신이 필요하다면, 프로세스 간 통신(Inter Process Communication. IPC)을 사용할 수도 있다. 많은 애플리케이션들이 이런 방식으로 동작하도록 만들어져 있고, 만약 워커 프로세스가 응답하지 않을 경우, 애플리케이션의 다른 부분들을 실행하고 있는 다른 프로세스들을 멈추지 않고 재시작할 수도 있다.
브라우저 아키텍처
그래서 어떻게 웹 브라우저가 프로세스와 스레드들을 이용해 만들어지는가? 글쎄, 그건 많은 스레드들을 가지고 있는 하나의 프로세스일 수도 있고, 몇몇의 스레드들로 이루어져 있는 다수의 프로세스들이 IPC를 통해 통신하고 있는 방식일 수도 있다.
중요하게 알아야 할 것은, 이렇게 다양한 아키텍처들은 구현의 세부사항이라는 것이다. 웹 브라우저를 구축하는데 표준 사양은 없다. 브라우저마다 접근 방식이 완전히 다를 수도 있다.
이 블로그 시리즈에서는 아래 다이어그램에 묘사되어 있는 것처럼, 크롬의 최신 구조를 사용할 것이다.
상단에는 애플리케이션의 각자 다른 부분들을 처리하고 있는 다른 프로세스들과 연계되어 있는 브라우저 프로세스가 있다. 렌더러 프로세스의 경우에는, 여러 프로세스들이 생성되고, 각 탭에 할당이 된다. Chrome 은 최근까지, 각 탭에 가능한 한 개의 프로세스를 제공했지만, iframe 을 포함해서 각 사이트 마다 한개의 고유한 프로세스를 제공하려고 한다. (사이트 Isolation을 참고하자)
어떤 프로세스가 무엇을 제어하는가?
아래 테이블에는 각 크롬 프로세스들이 무엇을 제어하는지 보여주고 있다.
| 프로세스, 그리고 프로세스가 제어 하는 것들 | ||||
| Browser | 주소 바, 북마크, 뒤로가기 앞으로 가기 버튼들을 포함한 어플리케이션 “Chrome” 부분을 제어한다. 또한 네트워크 요청 및 파일 접근과 같은 웹 브라우저의 보이지 않는 권한 부분들도 처리한다. | |||
| Renderer | 웹사이트가 표시되는 탭 내부의 보든 것들을 제어한다. | |||
| Plugin | 웹사이트에서 사용되는 플러그인들을 제어한다. 예를 들면 flash 같은 | |||
| GPU | 다른 프로세스들로부터 분리해서(isolation) GPU 작업을 처리한다. GPU 는 여러 앱의 요청을 처리해서 그것들을 같은 표며에 그리기 때문에 , 다른 프로세스들과는 분리된다. | |||
확장 프로세스나 유틸리티 프로세스들과 같은 더 많은 프로세스들이 존재한다. 크롬에서 얼마나 많은 프로세스들이 실행되는지 보고 싶다면, 오른쪽 상단 모서리에 있는 옵션 메뉴에서 more_vert를 클릭하고 More Tools를 선택한 다음 Task manager를 선택하면 된다. 그러면 현재 실행 중인 프로세스 목록과 사용 중인 CPU/메모리 양이 표시된 창이 열린다.
크롬의 멀티 프로세스 아키텍처의 장점
초반에, 나는 크롬에서 여러 개의 렌더러 프로세스들을 사용하고 있음을 언급했다. 가장 간단한 케이스로, 각각의 탭이 고유의 렌더러 프로세스를 가지고 있는 것을 상상해볼 수 있다. 당신이 3개의 탭을 가지고 있고, 각 탭이 독립적인 렌더러 프로세스로 실행되고 있다고 해보자. 한개의 탭이 응답하지 않는 상태가 되면, 그 응답없는 탭을 닫을 수 있고 다른 살아 있는 탭들로 이동할 수 있다. 만약 모든 탭들이 하나의 프로세스로 실행한다면, 한 개의 탭이 응답하지 않는 상태가 되면, 모든 탭들도 응답하지 않게 된다. 그건 슬픈 일이다.
브라우저의 작업을 여러개의 프로세스로 나누는 것의 또 다른 장점은 보안과 샌드박싱이다. OS는 프로세스의 권한을 제한하는 방법을 제공하기 때문에, 브라우저는 특정 피쳐들로부터 특정 프로세스들을 샌드박스 할 수 있다. 예를 들어, 크롬 브라우저는 렌더 프로세스 같은 임의의 사용자 입력을 다루는 프로세스들의 임의의 파일 접근을 제한한다.
프로세스들이 그들만의 프라이빗한 메모리 공간을 가지고 있기 때문에, 공통 인프라구조의 복사본을 포함하고 있는 경우가 많다. (크롬의 자바스크립트 엔진인 V8 같은 거라던지). 같은 프로세스 내에 있는 스레드들과는 달리 메모리를 공유할 수 있는 방법이 없기 때문에, 이것은 더 많은 메모리를 사용할 것임을 의미한다. 메모리 절약을 위해서, 크롬은 프로세스 스핀업에 제한을 두고 있다. 얼마만큼의 메모리와 CPU 파워를 디바이스에서 가져하는지에 따라서 제한은 달라진다. 하지만 크롬이 제한에 도달하면, 같은 사이트에 있는 여러 개의 탭들을 하나의 프로세스로 실행하기 시작한다.
메모리 절약 - 크롬에 있는 서비스화(Servicification)
같은 방식은 브라우저 프로세스에도 적용된다. 크롬은 브라우저 프로그램들의 각 부분들을 다른 프로세스들로 쉽게 분할할 수 있거나, 하나로 통합할 수 있는 서비스로 실행하도록 아키텍처를 변경하는 작업을 진행하고 있다.
보편적인 생각은 크롬을 파워풀한 하드웨어에서 실행시킬 때는, 아마 각기 다른 서비스를 다른 프로세스들로 분할해서 안정성을 높일 거라는 것이다. 하지만, 리소스가 제한된 디바이스라면, 크롬은 서비스들을 하나의 프로세스로 통합해서 메모리 공간을 절약한다. 이런 변화 전에는, 더 적은 메모리를 사용하기 위해 안드로이드 같은 곳에서 프로세스 통합과 유사한 방식을 사용했다.
프레임 별 렌더러 프로세스 - 사이트 격리(Isolation)
사이트 격리는 크롬에 최근에 소개된 기능이다. 그것은 각 교차된 사이트(cross-site) iframe에 대해 별도의 렌더러 프로세스를 실행한다.
우리는 지금까지 각 탭 당 하나의 렌더러 프로세스가 있는 모델을 얘기해 왔다. 그것은 다른 사이트들과 메모리 공간을 공유하는 하나의 단일 렌더러 프로세스 위에서 교차 사이트 iframes들 실행하는 것을 허용해 준다. a.com과 b.com 이 같은 렌더러 프로세스를 공유하는 것은 괜찮아 보일 수 있다. Same Origin Policy 은 웹의 핵심 보안 모델이다. 그것은 한 사이트가 다른 사이트로 부터온 데이터에 동의 없이 접근하는 것을 막아준다. 이 정책을 우회하는 것이 보안 공격의 주 목표다. 프로세스 격리는 사이트들을 분리하는 가장 효과적인 방법이다. Meltdown과 Spectre에서는, 프로세스를 사용해서 사이트를 분리해야 함이 더 명백해진다. 사이트 격리는 Chrome 67 이후로는 기본으로 데스크톱에서는 설정되어 있고, 각 탭 내에 있는 교차 사이트 iframe 도 분리된 렌더러 프로세스를 가지게 된다.
사이트 격리를 가능하게 하기 위해 몇 년에 걸친 기술적 노력이 있었다. 사이트 격리는 다른 렌더러 프로세스들을 할당하는 것처럼 간단하지 않다. 그것은 iframe 간의 통신 방식을 근본적으로 바꾼다. 다른 프로세스들에서 실행되고 있는 iframe 이 있는 페이지에서 개발 도구를 여는 것은 개발 도구가 매끄럽게 보이기 위해 백그라운드 작업을 구현해야 한다는 것을 의미한다. 심지어 Ctrl F를 눌러서 페이지 내에 단어를 찾는 간단한 것을 실행하는 것도, 다른 렌더러 프로세스들을 거쳐서 찾아야 한다. 당신은 왜 브라우저 엔지니어들이 왜 사이트 격리 릴리즈를 중요한 마일스톤이라고 얘기했는지 알 수 있다.
정리
이번 포스트에서는, 브라우저 아키텍처의 고수준 레벨과 멀티 프로세스 아키텍쳐의 장점에 대해서 다뤘다. 또한 멀티 프로세스 아키텍처와 깊게 연관되어 있는 서비스화와 크롬 내 사이트 격리에 대해서도 다뤘다. 다음 포스트에서는, 웹 사이트를 표시하기 위해 프로세스들과 스레드들 사이 간에 무슨 일이 일어나는지에 관해 다룰 것이다.
포스트를 읽는 게 즐거웠는가? 궁금한 것이 있거나, 포스팅할 만한 것에 대한 제안이 있다면, 아래 댓글이나 트위터에서 의견을 남겨주길 바란다.
'Chrome' 카테고리의 다른 글
| Key data structures and their roles in RenderingNG(한글)(2) (0) | 2022.04.20 |
|---|---|
| Key data structures and their roles in RenderingNG(한글)(1) (0) | 2022.03.09 |
| Overview of the RenderingNG architecture (한글) (1) | 2021.12.15 |
