CPU, GPU, 메모리, 멀티 프로세스 아키텍처
4부로 구성된 이 블로그 시리즈에서는 개략적인 아키텍처부터 렌더링 파이프라인의 세부사항에 이르기까지 Chrome 브라우저를 자세히 살펴봅니다. 브라우저가 코드를 제대로 작동하는 웹사이트로 변환하는 방법이 궁금하거나 성능 개선을 위해 특정 기법이 권장되는 이유가 궁금하다면 이 시리즈를 참고하세요.
이 시리즈의 1부에서는 핵심 컴퓨팅 용어와 Chrome의 다중 프로세스 아키텍처를 살펴봅니다.
컴퓨터의 핵심은 CPU와 GPU입니다
브라우저가 실행되는 환경을 이해하려면 컴퓨터의 몇 가지 부분과 그 작업을 이해해야 합니다.
CPU
첫 번째는 C C작업 C니트, 즉 C입니다. CPU는 컴퓨터의 두뇌라고 볼 수 있습니다. 여기서 사무 작업자로 표현된 CPU 코어는 다양한 작업이 들어오는 대로 하나씩 처리할 수 있습니다. 수학에서 예술에 이르기까지 모든 것을 처리할 수 있으며 고객 문의에 응답하는 방법을 알고 있습니다. 과거에는 대부분의 CPU가 단일 칩이었습니다. 코어는 같은 칩에 있는 다른 CPU와 같습니다 최신 하드웨어에는 코어가 두 개 이상 있어 휴대전화와 노트북에 더 많은 컴퓨팅 성능을 제공합니다.
GPU
그래픽 Unit(GPU)은 컴퓨터의 또 다른 일부입니다. CPU와 달리 GPU는 간단한 작업을 처리하는 데 훌륭하지만 동시에 여러 코어에서 가능합니다. 이름에서 알 수 있듯이 처음에는 그래픽을 처리하기 위해 개발되었습니다. 이러한 이유로 그래픽의 맥락에서 'GPU 사용' 또는 'GPU 지원'이 빠른 렌더링과 원활한 상호작용과 관련이 있습니다. 최근 몇 년 동안 GPU 가속 컴퓨팅으로 GPU만으로 점점 더 많은 계산이 가능해지고 있습니다.
컴퓨터나 휴대전화에서 애플리케이션을 시작할 때 CPU와 GPU가 애플리케이션의 기반이 됩니다. 일반적으로 애플리케이션은 운영체제가 제공하는 메커니즘을 사용하여 CPU 및 GPU에서 실행됩니다.
프로세스 및 스레드에서 프로그램 실행
브라우저 아키텍처를 살펴보기 전에 알아야 할 또 다른 개념은 프로세스와 스레드입니다. 프로세스는 애플리케이션의 실행 프로그램으로 설명할 수 있습니다. 스레드는 프로세스 내부에 상주하며 프로세스 프로그램의 모든 부분을 실행하는 스레드입니다.
애플리케이션을 시작하면 프로세스가 생성됩니다. 프로그램은 작업을 돕기 위해 스레드를 만들 수 있지만 이는 선택 사항입니다. 운영체제는 프로세스에 사용할 메모리 '슬래브'를 제공하고 모든 애플리케이션 상태는 해당 비공개 메모리 공간에 유지됩니다. 애플리케이션을 닫으면 프로세스도 사라지고 운영체제에서 메모리를 확보합니다.
프로세스는 운영체제에 다른 프로세스를 시작하기 위해 다른 프로세스를 시작하도록 요청할 수 있습니다. 이 경우 메모리의 다른 부분이 새 프로세스에 할당됩니다. 두 프로세스가 통신해야 하는 경우 IPC (Inter rocess ommunication)를 사용하면 통신합니다. 많은 애플리케이션이 이러한 방식으로 작동하도록 설계되어 있으므로 작업자 프로세스가 응답하지 않는 경우 애플리케이션의 다른 부분을 실행 중인 다른 프로세스를 중지하지 않고 다시 시작할 수 있습니다.
브라우저 아키텍처
그렇다면 웹 브라우저는 어떻게 프로세스와 스레드를 사용하여 빌드될까요? 다양한 스레드가 있는 하나의 프로세스이거나 IPC를 통해 통신하는 스레드가 몇 개의 다른 프로세스일 수 있습니다.
여기서 중요한 점은 이러한 다양한 아키텍처가 구현 세부정보라는 점입니다. 웹 브라우저를 빌드하는 방법에 대한 표준 사양은 없습니다. 한 브라우저의 접근 방식은 다른 브라우저의 접근 방식과 완전히 다를 수 있습니다.
이 블로그 시리즈에서는 그림 8에 설명된 Chrome의 최신 아키텍처를 사용합니다.
상단에는 애플리케이션의 여러 부분을 처리하는 다른 프로세스와 함께 작동하는 브라우저 프로세스가 있습니다. 렌더기 프로세스의 경우 여러 프로세스가 생성되어 각 탭에 할당됩니다. 최근까지만 해도 Chrome은 가능한 경우 각 탭에 프로세스를 제공했습니다. 하지만 이제는 각 사이트에 iframe을 포함한 자체 프로세스를 제공하려고 합니다 (사이트 격리 참고).
어떤 프로세스에서 무엇을 제어하나요?
다음 표에는 각 Chrome 프로세스와 해당 프로세스가 제어하는 항목이 설명되어 있습니다.
| 프로세스 및 제어 대상 | |
|---|---|
| 브라우저 |
주소 표시줄, 북마크, 뒤로 및 앞으로 버튼을 포함하여 애플리케이션의 'chrome' 부분을 제어합니다. 네트워크 요청, 파일 액세스 등 웹브라우저에서 보이지 않고 권한이 있는 부분도 처리합니다. |
| 렌더기 | 웹사이트가 표시되는 탭 내부의 모든 항목을 제어합니다. |
| 플러그인 | 웹사이트에서 사용하는 플러그인(예: 플래시)을 제어합니다. |
| GPU | GPU 작업을 다른 프로세스와 분리하여 처리합니다. GPU가 여러 앱의 요청을 처리하고 동일한 노출 영역에 그리므로 다른 프로세스로 분리됩니다. |
확장 프로세스 및 유틸리티 프로세스와 같은 더 많은 프로세스가 있습니다. Chrome에서 실행 중인 프로세스 수를 확인하려면 오른쪽 상단의 옵션 메뉴 아이콘 을 클릭하고 도구 더보기를 선택한 다음 작업 관리자를 선택합니다. 그러면 현재 실행 중인 프로세스와 사용 중인 CPU/메모리의 목록이 포함된 창이 열립니다.
Chrome 다중 프로세스 아키텍처의 이점
앞서 Chrome은 여러 렌더기 프로세스를 사용한다고 언급했습니다. 가장 간단한 경우에는 각 탭에 자체 렌더기 프로세스가 있다고 가정해 보겠습니다 3개의 탭이 열려 있고 각 탭이 독립적인 렌더기 프로세스에 의해 실행된다고 가정해 보겠습니다.
한 탭이 응답하지 않을 경우 응답하지 않는 탭을 닫고 다른 탭을 활성 상태로 유지하면서 계속 진행할 수 있습니다. 모든 탭이 한 프로세스에서 실행 중일 때 한 탭이 응답하지 않으면 모든 탭이 응답하지 않습니다. 안타까워요.
브라우저의 작업을 여러 프로세스로 분리하는 또 다른 이점은 보안과 샌드박스입니다. 운영체제에서는 프로세스의 권한을 제한하는 방법을 제공하므로 브라우저에서는 특정 기능의 특정 프로세스를 샌드박스 처리할 수 있습니다. 예를 들어 Chrome 브라우저는 렌더러 프로세스와 같이 임의의 사용자 입력을 처리하는 프로세스의 경우 임의의 파일 액세스를 제한합니다.
프로세스는 자체 비공개 메모리 공간이 있기 때문에 일반적인 인프라 (예: Chrome의 자바스크립트 엔진인 V8)의 사본을 포함하는 경우가 많습니다. 즉, 동일한 프로세스 내의 스레드인 경우처럼 공유할 수 없으므로 메모리 사용량이 더 많아집니다. 메모리를 절약하기 위해 Chrome은 가동할 수 있는 프로세스 수를 제한합니다. 한도는 기기의 메모리 및 CPU 성능에 따라 달라지지만, Chrome에서 한도에 도달하면 Chrome에서 같은 사이트의 여러 탭을 한 번에 실행하기 시작합니다.
더 많은 메모리 절약 - Chrome 서비스
브라우저 프로세스에도 동일한 접근 방식이 적용됩니다. Chrome은 브라우저 프로그램의 각 부분을 서비스로 실행하여 여러 프로세스로 분할하거나 하나로 집계할 수 있도록 아키텍처를 변경하고 있습니다.
일반적으로 Chrome이 강력한 하드웨어에서 실행될 때는 각 서비스를 여러 프로세스로 분할하여 안정성을 높일 수 있지만, 리소스 제약이 있는 기기의 경우에는 Chrome이 서비스를 하나의 프로세스로 통합하여 메모리 공간을 절약합니다. 메모리 사용량을 줄이기 위해 프로세스를 통합하는 유사한 접근 방식이 이번 변경 전에 Android와 같은 플랫폼에서 사용되었습니다.
프레임별 렌더기 프로세스 - 사이트 격리
사이트 격리는 최근 Chrome에 도입된 기능으로, 각 교차 사이트 iframe에 별도의 렌더기 프로세스를 실행합니다. 지금까지 여러 사이트 간에 메모리 공간을 공유하는 단일 렌더기 프로세스에서 교차 사이트 iframe을 실행할 수 있도록 하는 탭 모델당 하나의 렌더기 프로세스에 관해 알아보았습니다. 동일한 렌더기 프로세스에서 a.com과 b.com을 실행하는 것은 괜찮아 보일 수 있습니다. 동일 출처 정책은 웹의 핵심 보안 모델로서, 한 사이트에서 동의 없이 다른 사이트의 데이터에 액세스할 수 없도록 합니다. 이 정책을 우회하는 것이 보안 공격의 주요 목표입니다. 프로세스 격리는 사이트를 분리하는 가장 효과적인 방법입니다. 멜트다운 및 스펙터를 통해 프로세스를 사용하여 사이트를 분리해야 한다는 사실이 더욱 분명해졌습니다. Chrome 67부터 데스크톱에서 사이트 격리가 기본적으로 사용 설정되면 탭의 각 교차 사이트 iframe이 별도의 렌더기 프로세스를 받습니다.
사이트 격리를 사용 설정하는 데는 다년간의 엔지니어링 작업이 있었습니다. 사이트 격리는 서로 다른 렌더기 프로세스를 할당하는 것만큼 간단하지 않습니다. 즉, iframe이 서로 통신하는 방식이 근본적으로 바뀝니다. iframe이 다른 프로세스에서 실행되는 페이지에서 devtools를 열면 devtools가 원활하게 표시되도록 보이지 않는 작업을 구현해야 했습니다. 간단한 Ctrl+F를 실행하여 페이지에서 단어를 찾는 것만으로도 여러 렌더러 프로세스에서 검색할 수 있습니다. 브라우저 엔지니어들이 사이트 격리 출시를 주요 이정표로 언급하는 이유를 알 수 있습니다.
요약정리
이 게시물에서는 개략적인 브라우저 아키텍처 뷰와 다중 프로세스 아키텍처의 이점을 살펴보았습니다. 또한 다중 프로세스 아키텍처와 밀접한 관련이 있는 Chrome의 서비스 및 사이트 격리에 관해서도 알아보았습니다. 다음 게시물에서는 웹사이트를 표시하기 위해 이러한 프로세스와 스레드 간에 발생하는 과정을 자세히 알아보겠습니다.
게시물이 도움이 되었나요? 향후 게시물과 관련하여 질문이나 제안이 있으면 트위터의 @kosamari로 알려주시기 바랍니다.