Gemini の Deep Research で、Go が libc を使わずに独自にメモリ管理しているかどうかを調べた回答がよくまとまっていました。英語で書かれていたため日本語に翻訳して、一部重複などを整理した上で公開します。

本記事と関連して古典的な sbrk についても調査した記事があります。

リサーチ計画

Go 言語では libc を使用せず自前でメモリ管理を行うと聞いています。Go 言語で作成し、単一バイナリとして生成された実行ファイルにおいて、メモリの確保や管理はどのように行われていますか？

Go 言語のランタイム環境が、libcに依存せず、独自のメモリ管理機能を提供していることを確認します。
Go プログラムにおけるヒープメモリの確保と管理の仕組みについて調査します。例えば小さなオブジェクトと大きなオブジェクトで異なる扱いがされるかどうかなどを調査します。
Go 言語のガベージコレクション (GC) のアルゴリズムと、それがどのようにメモリの解放を行うかについて調べます。
Go の実行可能ファイルが単一バイナリとして生成される際に、上記のメモリ管理機能がどのように組み込まれるかについて理解を深めます。
Go のメモリプロファイリングツールや関連するドキュメントを参照し、実際のメモリ使用状況の分析方法について調べます。
他のプログラミング言語（例えば C++ や Java）のメモリ管理方式と比較して、Go 言語の特徴を明らかにします。
Go 言語のメモリ管理に関連するパフォーマンスの考慮事項やチューニング方法について調査します。

はじめに

Go プログラミング言語は、シンプルさ、並列処理、パフォーマンスに重点を置いているため、特にクラウドコンピューティング環境において、さまざまなアプリケーションに最適であるとして、近年注目を集めている。Go の設計思想の重要な側面は、外部依存なしに簡単に展開できる、自己完結型の単一実行バイナリを作成できる能力である。これは、標準 C ライブラリ (libc) に依存せずに動作する Go 独自のメモリ管理システムによって実現されている。本レポートでは、Go がこれらのスタンドアロン実行ファイル内でメモリをどのように管理しているのかについて詳しく掘り下げ、ヒープメモリ割り当てのメカニズム、ガベージコレクション、異なるオブジェクトサイズに対する割り当て戦略、これらの機能のバイナリへの統合、利用可能なメモリプロファイリングツール、C++ および Java のメモリ管理との比較、パフォーマンスの考慮事項とチューニングテクニックについて取り上げる。

Go の設計は使いやすさとパフォーマンスを重視しており、その独立したメモリ管理はこれらの目標を達成する上で極めて重要である。libc のような外部依存なしに単一のバイナリを作成できる機能は、展開を大幅に簡素化する。このアプローチは、Go の特定の並列処理モデルと実行時要件に合わせた、より高度な制御と最適化を求める要望から生まれたものと思われる。明示的には述べられていないが、カスタムメモリマネージャの開発は、標準の libc が goroutine のような Go 独自の機能に対して、望ましいレベルの制御やパフォーマンス特性を提供していない可能性を示唆している。

1. Go ランタイムと独立したメモリ管理

Go のランタイム環境は、その動作に不可欠であり、メモリ管理、ガベージコレクション、並列処理の基礎となるサービスなど、重要なサービスを提供している。特に、Go のランタイムには独自のメモリ管理機能が含まれており、システムの libc とは独立して動作する。この独立性は、ビルドプロセス中に特定のリンカーフラグを使用することで、Go コードを libc にリンクせずにコンパイルできるという事実からも明らかである。これは、Go の開発初期段階からの基本的な目標であった。libc を必要とせずに直接システムコールを実行できる、完全に静的にリンクされたバイナリを作成することである。

この設計上の選択にはいくつかの利点がある。アプリケーションがターゲットシステム上の libc の存在や特定のバージョンに依存しないため、クロスコンパイルが容易になり、移植性が向上する。さらに、Go と libc 間の外部関数インターフェース (FFI) の境界を回避することで、コンパイラによる最適化が向上する可能性がある。また、特定の libc API が持つ、必ずしも基本的なシステムコールで必要とされるわけではない特定の制限や動作を回避する必要性も低減する。

しかし、この独立性は、Go ランタイムがメモリ管理に関連するすべての必要なシステムレベルの機能について、独自のインプリメンテーションを組み込む必要があることを意味する。これには、メモリの割り当て、解放、および重要なタスクであるガベージコレクションの処理が含まれる。Go ランタイムは、主に 2 つの領域でメモリを管理する。スタックとヒープである。スタックメモリは通常、ローカル変数や関数呼び出し情報に使用され、高速アクセスと自動クリーンアップを提供する。一方、ヒープメモリは動的に割り当てられたメモリに使用され、データの有効期間が単一の関数の範囲を超える可能性がある。

メモリを独立して管理するという決定により、Go ではメモリ管理を goroutine に基づく並列処理モデルなどの言語の他の側面と緊密に統合することが可能になっている。各 goroutine は独自のスタックを持ち、ランタイムがこれらのスタックの割り当てとサイズ変更を管理する。この緊密な統合により、libc のような汎用ライブラリに依存する場合と比較して、より効率的なリソース利用が可能となる。

2. Go におけるヒープメモリの割り当てと管理

Go プログラムがヒープメモリにメモリを割り当てる必要がある場合、ランタイムは TCMalloc（スレッドキャッシュMalloc）に着想を得た高度なシステムを採用する。Go は OS の mmap システムコールを使用して、カーネルに連続した大きなメモリ領域を要求する。このメモリは、スパンまたは mspan オブジェクトと呼ばれる管理可能な単位にまとめられる。これらのスパンは連続したメモリ領域であり、通常は 8 KB 以上であり、次の 3 つの状態のいずれかになる。アイドル（オブジェクトを含まず、再利用または解放が可能）、使用中（少なくとも 1 つのヒープオブジェクトを保持しており、さらにスペースを確保できる可能性がある）、スタック（goroutine スタック専用）。

Go のメモリアロケーターは、ヒープを効率的に管理するために、いくつかの重要なデータ構造を利用している。mcache は、Go ランタイムの各プロセッサ（P）に関連付けられたスレッドローカルなキャッシュである。このキャッシュは、ロックを必要とせずに小さなオブジェクトを高速に割り当てることを可能にする。これは、並列プログラムのパフォーマンスにとって非常に重要である。mcentral は、各サイズクラスのスモールオブジェクトについて、すべてのスレッドで共有される中央構造である。割り当て可能な空き領域を持つ mspan のリストを管理する。最後に、mheap は、mspan が使用するページランを管理し、また、ラージオブジェクトの割り当ても処理する中央ヒープ構造である。

Go における割り当てプロセスは、割り当てられるオブジェクトのサイズによって異なる。オブジェクトは一般的に、3 つのサイズクラスに分類される。Tiny（16 バイト未満）、Small（32 KB まで）、Large（32 KB より大きい）。Small オブジェクトの割り当ては、要求されたサイズを約 70 の事前定義されたサイズクラスのいずれかに切り上げて、さらに細分化される。各サイズクラスには、そのサイズのオブジェクト専用の空きリストが用意されている。

小さなオブジェクトの割り当ての場合、アロケーターはまず、現在のプロセッサの mcache から適切な小さなスロットオブジェクトがあるかどうかを確認する。既存のサブオブジェクトが存在する場合、そのサイズは新しいオブジェクトのサイズに基づいて 2/4/8 バイトに丸められる。新しいオブジェクトが 16 バイトの Tiny ブロックの残りのスペースに収まる場合、そこに配置される。収まらない場合、アロケーターは mcache 内の空き mspan を探す。現在の mspan に空きがない場合は、必要なサイズクラスの mcentral から新しい mspan が取得される。 mcentral の mspan のリストも空の場合は、mheap からページの連続が要求される。 mheap に十分な空きがない場合は、OS に新しいページのグループ（少なくとも1 MB）を要求することがある。

Small オブジェクトの割り当ても同様のプロセスに従うが、既存の小さなブロックに収まるかどうかの初期チェックは省略される。サイズは適切な Small サイズクラスに切り上げられ、アロケーターは mcache 内の対応する mspan の空きスロットを探す。空きスロットがない場合は、新しい mspan が mcentral から取得される。mcentral のリストが空の場合、ページは mheap から取得され、必要に応じて、mheap が OS にメモリを追加要求する。

32 KB を超える Large オブジェクトの割り当ては、mcache と mcentral をバイパスして、直接 mheap が関与する。Large オブジェクトはページサイズ（8 KB）に切り上げられる。アロケーターは、mheap の空きリストから必要なページ数の連続したブロックを検索する。適切なブロックが見つからない場合、mheap は OS にメモリを要求する。

スレッドローカルキャッシュ (mcache) の使用は、小さなオブジェクトと小さなオブジェクトの両方の割り当てを最適化する上で重要な役割を果たす。mcache は、mcentral や mheap のような共有リソースのロックを取得する必要のない高速な割り当てパスを提供することで、特に複数の goroutine が同時にメモリを割り当てることがある並列プログラムにおいて、メモリ割り当てのパフォーマンスを大幅に向上させる。

スレッドローカルキャッシュ、さまざまなサイズクラスのための中央管理、中央ヒープというこの複雑なシステムにより、Go はメモリ割り当てと解放を効率的に管理でき、ロックの競合や OS とのやりとりを最小限に抑えることができる。

3. Go のガベージコレクションのメカニズム

Go は自動メモリ管理モデルを採用しており、使用されなくなったオブジェクトが占有するメモリを再利用するためにガベージコレクタ (GC) に依存している。Go のガベージコレクタは追跡型のマークスイープアルゴリズムを使用している。これは、メモリ内のどのオブジェクトがプログラムによってまだ使用されているかを識別し、到達不能となったオブジェクトが使用していたメモリを再利用することを意味する。

Go の GC プロセスは主に、マークフェーズとスイープフェーズの2つのフェーズで構成される。マークフェーズでは、ガベージコレクタはまず、確実に使用中のオブジェクトへのポインタであるルートポインタのセットを特定する。次に、これらのルートオブジェクトからメモリ内の他のオブジェクトへのポインタをたどりながら、オブジェクトグラフを走査する。生存オブジェクトを発見すると、それらをマークして、まだ使用中であり回収すべきではないことを示す。Go の GC は、マークフェーズの進行状況を追跡するために、3色アルゴリズム（白、グレー、黒）を使用する。白のオブジェクトはまだ訪問されていない、グレーのオブジェクトは訪問済みだが参照の処理はされていない、黒のオブジェクトは訪問済みで、すべての参照の処理が完了している。

マークフェーズが完了すると、GC はスイープフェーズに入る。このフェーズでは、GC はヒープ内のすべてのメモリを巡回し、トレースフェーズでライブとしてマークされなかったメモリを特定する。マークされていないメモリは、プログラムから到達できなくなったため、ガベージと見なされる。その後、GC はプログラムによる今後の割り当てのために、このメモリを利用可能にする。

Go のガベージコレクタの重要な特徴は、その並列処理機能である。ガベージコレクタのほとんどの処理、特にマークフェーズは、アプリケーションの実行と並行して行われる。これにより、アプリケーションの応答性に影響を与える可能性のある長時間の「停止」を最小限に抑えることができる。しかし、データの整合性を確保するために、特定の重要なガベージコレクション処理を行うために、プログラムの実行が一時的に中断される短い期間が依然として存在する。

ガベージコレクタが実行される頻度は、主に GOGC 環境変数によって制御される。この変数は、前回の GC サイクルから生き残ったデータに対する新たに割り当てられたデータの比率の目標を設定し、次の GC サイクルがいつ開始されるかに影響を与える。 GOGC の値が高いと、GC サイクルがトリガーされる前にヒープがより大きく成長し、ガベージコレクションの頻度が低くなるが、メモリ使用量が高くなる可能性がある。逆に、GOGC の値が低いと、GC サイクルがより頻繁に発生し、潜在的にメモリ使用量が少なくなるが、CPU オーバーヘッドが増加する。

4. 単一のバイナリへのメモリ管理の統合

Go の主要な機能のひとつは、プログラムを単一の自己完結型実行バイナリにコンパイルできることである。これは、メモリアロケーターやガベージコレクターなどのメモリ管理コンポーネントを含む Go ランタイム全体を静的にリンクし、実行ファイルに直接組み込むことで実現される。Go プログラムを go build コマンドでビルドすると、コンパイラーとリンカーが連携して、必要なランタイムコードをすべて生成されるバイナリに含める。

このアプローチには、展開と移植性において大きな利点がある。実行ファイルには、Go ランタイムやメモリ管理システムなど、その依存関係がすべて含まれているため、ターゲットシステムに Go ランタイムや特定のライブラリがインストールされていることを確認する必要がない。バイナリは完全に自立しており、互換性のある OS やアーキテクチャであれば、どこでも直接実行できる。これにより、展開プロセスが大幅に簡素化される。開発者は外部依存関係の管理について心配する必要がないからだ。

さらに、ランタイムを静的にリンクすることで、移植性が向上する。メモリ管理システムの動作は、アプリケーション自体の一部であり、基盤となる OS やそのライブラリに依存しないため、異なる環境間でも一貫性を保つことができる。これにより、アプリケーションがメモリ管理のために libc のようなシステムレベルのライブラリに依存する場合に生じる可能性のある不整合や互換性の問題を排除できる。Go バイナリは自己完結型であるため、コンテナ化やクラウドネイティブアプリケーションなど、最新のデプロイメントシナリオに特に適している。

5. Go のメモリプロファイリングツール

Go には、アプリケーションのメモリ使用状況をプロファイリングするための強力な組み込みツールが用意されており、開発者はメモリ動作を分析し、潜在的なリークを特定し、メモリ割り当てを最適化することができる。この目的のための主なツールは、Go 標準ライブラリの一部である pprof パッケージであり、実行時プロファイリングには net/http/pprof パッケージを使用してアクセスできる。このパッケージをインポートし、HTTP サーバーを起動すると、開発者は一連の HTTP エンドポイントを通じてプロファイリングデータを公開することができる。

メモリ分析のための最も重要なエンドポイントのひとつは /debug/pprof/heap であり、リクエスト時のヒープメモリの使用状況のスナップショットを提供する。このデータは、curl や go tool pprof コマンドラインツールなどのツールを使用して収集できる。 go tool pprof は、ヒーププロファイルを含むさまざまなソースからのプロファイルデータを分析できる多機能ユーティリティである。メモリ消費を理解するのに役立つさまざまなタイプのレポートを生成することができ、例えば、メモリ消費量の多い上位のリスト、関数コールスタックによるメモリ使用状況を視覚化したフレームグラフ、割り当てパスを示すコールツリーなどがある。

メモリリークを特定するには、開発者は異なる時点における複数のメモリプロファイルを取得し、pprof を使用して -diff_base などのフラグを指定して比較することができる。作業負荷の増加に対応しないままメモリ使用量が継続的に増加している場合は、メモリリークの可能性がある。プロファイルデータは、解放されないメモリを割り当てているコードのどの部分が原因であるかを示し、リークの原因を特定するのに役立つ。

ヒーププロファイルに加えて、Goの新しいバージョンで導入された runtime/metrics パッケージは、メモリ使用に関連するさまざまな実行時メトリクスにアクセスするための、より構造化され、使いやすい方法を提供する。これらのメトリクスは、アプリケーションのメモリ動作の概要を把握するのに非常に役立つ。

Go では、その他のツールやテクニックもメモリプロファイリングに使用できる。例えば、Parca は継続的なプロファイリングツールであり、pprof から時間をかけてデータを収集し、メモリ使用状況に関するリアルタイムの洞察を提供する。GoLand のような IDE は、メモリプロファイルの分析に、より統合された開発環境を提供するビルトインのプロファイリング機能を提供する。さらに、ユニットテストやベンチマークの実行中には、testing パッケージの b.ReportAllocs() 関数を使用して、開発者はメモリアロケーションの数を追跡することができる。

これらのメモリプロファイリングツールを効果的に使用することで、開発者は Go アプリケーションがどのようにメモリを使用しているかを深く理解することができ、非効率な部分を特定したり、メモリリークを修正したり、全体的なパフォーマンスを最適化したりすることができる。

6. C++ と Java のメモリ管理との比較

Go のメモリ管理のアプローチは、自動ガベージコレクションを採用しており、C++ で採用されている手動のメモリ管理とは対照的である。また、Java 仮想マシン (JVM) 内で Java が使用するガベージコレクションのメカニズムと類似している。これらの相違点と類似点を理解することは、それぞれのアプローチのトレードオフと利点を理解する上で重要である。

C++ では、new と delete 演算子を使用して、開発者がメモリ割り当てと解放をきめ細かく制御できる。この手動によるアプローチでは、メモリ管理が慎重に処理されるシナリオにおいて、非常に最適化されたメモリ使用が可能となり、優れたパフォーマンスを実現できる。しかし、開発者には、割り当てられたすべてのメモリが最終的に解放されること、およびメモリリークやプログラムのクラッシュにつながる可能性のあるダングリングポインタや二重解放が発生しないことを保証する重大な責任が課せられる。

一方、Go では、ガベージコレクタによる自動メモリ管理を提供することで、手動メモリ管理の複雑性を抽象化している。これにより、メモリリークやダングリングポインタなどの一般的なメモリ関連エラーのリスクが大幅に低減される。そのトレードオフとして、ガベージコレクションプロセスによってオーバーヘッドが導入される。ガベージコレクションプロセスでは、定期的にプログラムを一時停止して未使用のメモリを特定し、再利用する。しかし、Go のコンカレントマークスイープ方式のガベージコレクタは、こうした中断を最小限に抑え、比較的効率的なメモリ使用を実現するように設計されている。

Java もまた、JVM 内のガベージコレクションによる自動メモリ管理を利用している。未使用のメモリを再利用するという基本的な目標は同じだが、Go の GC と JVM で利用可能なさまざまなガベージコレクタでは、具体的なアルゴリズムや実装が異なる可能性がある。多くの場合、Go のガベージコレクションは、Java のガベージコレクションと比較して、メモリ使用量や一時停止の期間の面でより効率的であると考えられている。特に、特定の種類の作業負荷の場合にその傾向が強い。Java が JVM を仲介層として使用しているため、Go のネイティブコードへのコンパイルと比較して、追加のオーバーヘッドが発生することがある。

Go/C++/Java の選択は、プロジェクトの特定の要件によって決まることが多い。C++ は最高の潜在的なパフォーマンスとシステムリソースの制御を提供できるが、複雑性が増し、メモリエラーのリスクも伴う。Java は JVM と自動メモリ管理によりクロスプラットフォームの互換性を提供し、大規模なエンタープライズアプリケーションに適しているが、Go と比較するとメモリ消費量が多く、起動時間が遅い可能性がある。Go はバランスを取ることを目的としており、自動メモリ管理による開発の容易性を提供しながら、優れたパフォーマンスと効率性を維持し、生産性とパフォーマンスの両方が重要なウェブサービス、クラウドネイティブアプリケーション、システムプログラミングのタスクに最適な候補となっている。

表1：Go/C++/Java のメモリ管理の比較

機能	Go	C++	Java
メモリ管理	自動（ガベージコレクション）	手動 (`new`、`delete`)	自動（JVM によるガベージコレクション）
割り当て制御	制限あり	細かい制御が可能	制限あり（JVM の制約内）
メモリリークのリスク	低い（GC が処理）	高い（慎重な手動管理が必要）	低い（GC が処理）
パフォーマンスオーバーヘッド	ガベージコレクションの一時停止	最小限（正しく管理されている場合）	ガベージコレクションの一時停止、JVM のオーバーヘッド
開発の複雑さ	低い	高い	中程度
バイナリサイズ	大きい（ランタイムとGC を含む）	小さい（システムライブラリにリンク可能）	小さい（JRE に依存）
クロスプラットフォーム	はい（ネイティブコードにコンパイル）	はい（再コンパイルが必要）	はい（JVM 経由）

7. Go メモリ管理のパフォーマンスに関する考慮事項とチューニング

Go アプリケーションのパフォーマンスは、そのメモリ管理のさまざまな側面、特にガベージコレクションに関連するオーバーヘッドによって影響を受ける可能性がある。ヒープの割り当てが増えると、ガベージコレクタに負荷がかかり、CPU 使用率が上昇し、「ストップ・ザ・ワールド」のレイテンシが時折発生する可能性がある。そのため、メモリ使用を最適化し、ガベージコレクタをチューニングする方法を理解することは、効率的な Go プログラムを構築する上で非常に重要である。

Go 言語では、いくつかのテクニックを用いてメモリ使用を最適化することができる。構造体のフィールドを大きい順から小さい順に並べる構造体アラインメントは、コンパイラによって追加されるパディングの量を最小限に抑え、構造体の全体的なメモリ使用量を削減することができる。メモリ割り当てを最小限に抑えることも、重要な戦略である。これは、sync.Pool を使用してオブジェクトを再利用したり、サイズがわかっているスライスやマップを事前に割り当てたり、+ 演算子を使用して文字列を何度も連結する代わりに strings.Builder を使用したりすることで実現できる。ポインタの賢明な使用も推奨される。ポインタの過剰な使用はヒープの割り当ての増加につながる可能性があるためだ。変数のスコープを管理することも、一般的に効率が良いとされるヒープではなくスタックにメモリを割り当てるようコンパイラに指示するのに役立つ。

Go では、開発者がガベージコレクタの動作を調整できる環境変数と実行時関数が提供されている。環境変数 GOGC は、ガベージコレクションサイクルが起動される前の対象となるヒープの成長率を制御する。GOGC の値を大きくすると、ガベージコレクションの頻度が減り、CPU のオーバーヘッドは低減するが、メモリ使用量は増える可能性がある。逆に、GOGC の値を小さくすると、GC がより頻繁に実行されるようになり、CPU 消費量が増える代わりにメモリ使用量を減らせる可能性がある。

Go 1.19 以降、Go ランタイムが使用できる総メモリにソフトリミットを設定する環境変数 GOMEMLIMIT が導入された。プログラムのメモリ使用量がこのリミットに近づくと、ガベージコレクタはメモリを回収する試みをより積極的に行うようになる。これは、コンテナなどのメモリが制限された環境で特に有用である。

runtime/debug パッケージは、これらの設定をプログラムから制御するための方法を提供する。SetGCPercent(int) 関数は、GOGC 環境変数を設定することと同等であり、SetMemoryLimit(int64) は実行時にメモリ制限を設定できる。

効果的なパフォーマンスのチューニングには、コードレベルの最適化を組み合わせ、メモリアロケーションを減らすことや、アプリケーションの特定の作業負荷やパフォーマンス目標に基づいてガベージコレクタのパラメータを調整することがよくある。前述のとおり、メモリプロファイリングツールは、メモリ管理に関連するパフォーマンスのボトルネックを特定し、チューニング作業の影響を検証するために不可欠である。

表2：Go のメモリ管理のチューニングパラメータ

パラメータ/機能	説明	デフォルト値	パフォーマンスへの影響
`GOGC` 環境変数	ガベージコレクションを起動する前に、ターゲットのヒープ成長率を設定する。	100	高い値：GC の頻度は少なく、メモリ使用量は多い。低い値：GC の頻度は多く、メモリ使用量は少なく、CPU使用量は多い。
`GOMEMLIMIT` 環境変数	Go ランタイムのソフトなメモリ制限を設定する。	OS 依存	制限に近づくと、GC は制限内に収まるようより積極的になる。
`runtime/debug.SetGCPercent(int)`	プログラムによる `GOGC` の同等機能。	100	`GOGC` と同じ。
`runtime/debug.SetMemoryLimit(int64)`	プログラムによる `GOMEMLIMIT` の同等機能。	OS 依存	`GOMEMLIMIT` と同じ。

結論

Go のメモリ管理システムは、その設計の重要な側面であり、効率的で移植性の高いアプリケーションの作成を可能にしている。独自のランタイムは、カスタムメモリアロケーターと並列ガベージコレクターを備えており、Go は libc のような外部ライブラリーに依存せずに単一の実行バイナリーを作成できる。ヒープメモリは、スパン、キャッシュ、中央構造体を使用して管理され、オブジェクトのサイズごとに最適化されたアロケーション戦略が採用されている。強力なビルトインメモリプロファイリングツールが利用できるため、開発者はメモリ使用状況を把握し、最適化することができる。Go の自動メモリ管理は、C++ での手動メモリ管理と比較して開発の簡素化とメモリエラーのリスク低減という点で大きな利点があり、Java の JVM ベースのガーベッジコレクションよりも効率的な場合が多いが、ガーベッジコレクションのパフォーマンスへの影響を考慮することは重要である。ガーベッジコレクタのチューニングやメモリ割り当ての最適化のためのさまざまなテクニックや実行時パラメータを理解することで、開発者は Go のメモリ管理機能を効果的に活用し、高性能なアプリケーションを構築することができる。Go のメモリ管理のアプローチは、効率的かつ開発者にとって使いやすい言語を提供するという目標の証であり、自動メモリ管理とパフォーマンス重視のアプリケーションに必要な制御のバランスを提供している。

参考資料