最新のウェブブラウザの詳細(パート 1)

Mariko Kosaka

CPU、GPU、メモリ、マルチプロセス アーキテクチャ

4 部構成のブログシリーズでは、アーキテクチャの概要からレンダリング パイプラインの詳細まで、Chrome ブラウザの内部を取り上げます。このシリーズは、ブラウザによってどのようにコードが正しく機能するウェブサイトになっているのか疑問に思う方や、パフォーマンスを向上させるために特定の手法が提案される理由がよくわからない方に最適です。

このシリーズのパート 1 では、主要なコンピューティング用語と Chrome のマルチプロセス アーキテクチャについて説明します。

コンピュータの中核となっているのは、CPU と GPU です。

ブラウザが実行されている環境を把握するために、コンピュータのいくつかの部分とその役割を理解する必要があります。

CPU

CPU
図 1: 各デスクに座ってタスクを処理するオフィス ワーカーとしての 4 個の CPU コア

1 つ目は、C中央のCプロビジョニングC(Unit)(C)です。CPU はコンピュータの頭脳ともいえますCPU コアはオフィスワーカーのように さまざまなタスクを 1 個ずつ処理し数学から芸術まであらゆることを処理し、顧客からの電話への返信方法を理解できます。以前は、ほとんどの CPU が単一のチップでした。コアとは 同じチップ内にある 別の CPU のようなものです最近のハードウェアでは複数のコアを利用することが多く、スマートフォンやノートパソコンのコンピューティング能力を高めます。

GPU

GPU
図 2: 限られたタスクの処理を提案するレンチ機能を備えた多数の GPU コア

グラフィックプロセッサ(GPU)もコンピュータの一部です。CPU とは異なり、GPU は単純なタスクの処理に適していますが、複数のコアにまたがって同時に処理できます。その名のとおり、当初はグラフィックを処理する目的で開発されました。このため、「GPU を使用」や「GPU 対応」は高速なレンダリングとスムーズな操作に関連付けられるためです。近年、GPU アクセラレーションを備えたコンピューティングにより、GPU だけで計算できる量がますます増えています。

パソコンまたはスマートフォンでアプリを起動すると、そのアプリケーションで処理を行うのは CPU と GPU です。通常、アプリケーションはオペレーティング システムのメカニズムを使用して CPU と GPU で実行されます。

ハードウェア、OS、アプリケーション
図 3: コンピュータ アーキテクチャの 3 レイヤ。下がマシン ハードウェア、中央がオペレーティング システム、上がアプリケーションです。

プロセスとスレッドでプログラムを実行する

プロセスとスレッドの
図 4: 境界ボックスとしてのプロセス(プロセス内を泳ぐ抽象的な魚としてのスレッド)

ブラウザ アーキテクチャの説明に入る前に把握しておくべきもう一つの概念は、プロセスとスレッドです。プロセスは、アプリケーションの実行プログラムとして記述できます。スレッドはプロセス内に存在し、そのプロセスのプログラムの一部を実行します。

アプリケーションを起動すると、プロセスが作成されます。プログラムは、動作を支援するためにスレッドを作成する場合がありますが、これは任意です。オペレーティング システムは、プロセスが処理するメモリの「スラブ」をプライベート メモリ空間に保持します。アプリを閉じると、プロセスも終了し、オペレーティング システムによってメモリが解放されます。

プロセスとメモリの
図 5: メモリ空間を使用してアプリデータを保存するプロセスの図

あるプロセスは、別のプロセスを開始してさまざまなタスクを実行するよう、オペレーティング システムに要求できます。その場合、メモリのさまざまな部分が新しいプロセスに割り当てられます。2 つのプロセスで通信が必要な場合は、Inter Process Communication(IPC)を使用して通信できます。多くのアプリはこのように動作するように設計されています。そのため、ワーカー プロセスが応答しなくなった場合、アプリケーションの別の部分を実行している他のプロセスを停止することなく、ワーカー プロセスを再起動できます。

ワーカー プロセスと IPC
図 6: IPC を介して通信する個別のプロセスの図

ブラウザ アーキテクチャ

では、ウェブブラウザはプロセスとスレッドを使用してどのように構築されるのでしょうか。1 つのプロセスに複数の異なるスレッドがある場合や、複数のスレッドが IPC を介して通信する多数の異なるプロセスである場合があります。

ブラウザ アーキテクチャ
図 7: プロセス / スレッドにおけるさまざまなブラウザ アーキテクチャの図

ここで重要なのは、これらの異なるアーキテクチャは実装の詳細であるということです。ウェブブラウザの構築方法に関する標準的な仕様はありません。ブラウザによって方法が完全に異なる場合があります。

このブログシリーズでは、図 8 に示すように、Chrome の最新のアーキテクチャを使用します。

一番上には、アプリのさまざまな部分を処理する他のプロセスと連携するブラウザ プロセスがあります。レンダラ プロセスでは、複数のプロセスが作成され、各タブに割り当てられます。つい最近まで、Chrome では可能な場合に各タブにプロセスを提供していましたが、現在は iframe を含む各サイトに独自のプロセスを割り当てようとしています(サイト分離を参照)。

ブラウザ アーキテクチャ
図 8: Chrome のマルチプロセス アーキテクチャの図。[Renderer Process](レンダラ プロセス)の下に複数のレイヤが表示され、タブごとに複数のレンダラ プロセスを実行している Chrome を表します。

どのプロセスで何を制御するか

次の表に、Chrome の各プロセスと制御対象を示します。

プロセスとその制御内容
参照者 アプリケーションの「Chrome」部分(アドレスバー、ブックマーク、戻るボタンと進むボタンなど)を制御します。
ネットワーク リクエストやファイル アクセスなど、ウェブブラウザの目に見えない特権部分も処理します。
レンダリング タブ内のウェブサイトを表示するすべての要素を制御します。
Plugin(プラグイン) ウェブサイトで使用するプラグイン(Flash など)を制御します。
GPU 他のプロセスから独立して GPU タスクを処理する。GPU は複数のアプリからのリクエストを処理し、同じサーフェスに描画するため、異なるプロセスに分割されます。
Chrome のプロセス
図 9: さまざまなプロセスが参照するブラウザ UI のさまざまな部分

拡張機能プロセスやユーティリティ プロセスなど、さらに多くのプロセスがあります。Chrome で実行されているプロセスの数を確認するには、右上のオプション メニュー アイコン をクリックし、[その他のツール]、[タスク マネージャー] の順に選択します。ウィンドウが開き、現在実行中のプロセスの一覧と、プロセスが使用している CPU/メモリの量が表示されます。

Chrome のマルチプロセス アーキテクチャのメリット

前述のように、Chrome は複数のレンダラ プロセスを使用します。最もシンプルなケースでは 各タブに 独自のレンダラプロセスがあります3 つのタブを開き、各タブが独立したレンダラ プロセスによって実行されているとします。

1 つのタブが応答しなくなった場合は、応答しないタブを閉じて、他のタブはそのままで次に進むことができます。1 つのプロセスですべてのタブが動作している場合、1 つのタブが応答しなくなると、すべてのタブが応答しなくなります。残念。

タブ用のマルチレンダラ
図 10: 各タブを実行している複数のプロセスを示す図

ブラウザの処理を複数のプロセスに分割することのもう一つの利点は、セキュリティとサンドボックス化です。オペレーティング システムにはプロセスの権限を制限する手段があるため、ブラウザは特定のプロセスを特定の機能からサンドボックス化できます。たとえば Chrome ブラウザは、レンダラ プロセスなど、任意のユーザー入力を処理するプロセスに対して、任意のファイル アクセスを制限します。

プロセスには独自のプライベート メモリ空間があるため、多くの場合、共通のインフラストラクチャのコピー(Chrome の JavaScript エンジンである V8 など)が含まれます。つまり同じプロセス内のスレッドの場合のようには共有できないため、メモリ使用量が増えます。 Chrome では、メモリを節約するために、スピンアップできるプロセスの数に上限を設けています。 上限はデバイスのメモリと CPU の処理能力によって異なりますが、上限に達すると、Chrome は 1 つのプロセスで同じサイトの複数のタブを実行するようになります。

メモリの節約 - Chrome のサービス

ブラウザ プロセスにも同じ手法が適用されます。Chrome では現在、ブラウザ プログラムの各部分をサービスとして実行し、複数のプロセスに分割したり、1 つに集約したりできるようにアーキテクチャの変更を進めています。

一般に、Chrome を高性能なハードウェアで実行している場合、各サービスを異なるプロセスに分割して安定性を高めますが、リソースに制約のあるデバイスの場合、Chrome は複数のサービスを 1 つのプロセスに統合してメモリ使用量を削減します。この変更以前は、Android などのプラットフォームでも、メモリ使用量を抑えるためにプロセスを統合する同様のアプローチが使用されていました。

Chrome のサービス
図 11: さまざまなサービスを複数のプロセスと単一のブラウザ プロセスに移行する Chrome のサービスの図

フレームごとのレンダラ プロセス - サイト分離

サイト分離は、最近 Chrome に導入された機能で、クロスサイト iframe ごとに個別のレンダラ プロセスを実行します。タブモデルごとに 1 つのレンダラ プロセスについて説明し、クロスサイト iframe を 1 つのレンダラ プロセスで実行し、異なるサイト間でメモリ空間を共有できるようにしました。a.com と b.com を同じレンダラ プロセスで実行しても問題ないように思えるかもしれません。同一生成元ポリシーは、ウェブの中核的なセキュリティ モデルであり、あるサイトが同意なしに他のサイトのデータにアクセスできないようにします。このポリシーの回避は、セキュリティ攻撃の主な目的です。 サイトを分離するにはプロセス分離が最も効果的な方法です。メルトダウンとスペクターにより、プロセスを使用してサイトを分離する必要があることがさらに明白になりました。Chrome 67 以降、パソコンでサイト分離がデフォルトで有効になっており、タブ内のクロスサイト iframe ごとに、別々のレンダラ プロセスが使用されます。

サイト分離
図 12: サイト分離の図(複数のレンダラ プロセスが 1 つのサイト内の iframe を参照している)

サイト分離の有効化には、数年にわたるエンジニアリングの取り組みが伴います。サイト分離は、異なるレンダラ プロセスを割り当てるような単純なものではなく、iframe の相互通信方法を根本的に変えます。さまざまなプロセスで実行されている iframe があるページで DevTools を開くと、devtools がシームレスに動作するようにバックグラウンドで作業を実装する必要があることを意味します。Ctrl+F というシンプルな操作でページ内の単語を見つけるだけでも、さまざまなレンダラ プロセスを検索することになります。ブラウザ エンジニアがサイト分離のリリースを大きなマイルストーンとして発表する理由がわかります。

まとめ

この投稿では、ブラウザ アーキテクチャの概要と、マルチプロセス アーキテクチャの利点について説明しました。また、マルチプロセス アーキテクチャに深く関連する Chrome におけるサービスおよびサイト分離についても取り上げました。次回の投稿では、ウェブサイトを表示するためにこれらのプロセスとスレッドの間で行われる処理について詳しく見ていきます。

この投稿はお楽しみいただけましたか?今後の投稿についてご質問やご提案がありましたら、Twitter の @kosamari までお寄せください。

次へ: ナビゲーションの内容