Recommended
More Related Content
Similar to Gotanda Bachelor Thesis
Similar to Gotanda Bachelor Thesis (20)
More from pflab
More from pflab (20)
Gotanda Bachelor Thesis
- 1. Shared Runtime for Memory-effective Unikernels ランタイムの共有によるユニカーネルのメモリ効率の向上 情報科学科4年 加藤研究室 05-171011 五反田正太郎
- 3. 軽量性と堅牢性を両立 軽量・堅牢な仮想化技術: ユニカーネル ハードウェア ハードウェア ハードウェア ハイパーバイザ ハイパーバイザ OS OS App + OS App OS App App App App App AppApp + OS App + OS 仮想マシン型仮想化 ユニカーネル型仮想化 コンテナ型仮想化 ◯軽量 ×脆弱◯堅牢 ×高コスト ◯軽量 ◯堅牢
- 4. ライブラリの重複によるメモリ圧迫 ユニカーネルはOS機能がライブラリとして個別にリンク App ① App ② App ③ OS機能 (ライブラリ) OS機能 (ライブラリ) OS機能 (ライブラリ) OS機能 (ライブラリ) OS機能 (ライブラリ) OS機能 (ライブラリ) App ① App ② App ③ 内容に重複 物理メモリ
- 5. OS機能 (ライブラ リ) OS機能 (ライブラ リ) 提案: ライブラリ共有によるメモリ使用量削減 App ① App ② App ③ OS機能 (ライブラリ) OS機能 (ライブラリ) OS機能 (ライブラリ) OS機能 (ライブラリ) App ① App ② App ③ メモリ使用量削減 ライブラリの重複回避によるユニカーネルのメモリ使用量削減 物理メモリ
- 6. ユニカーネルのライブラリ共有の課題 • ユニカーネルは静的ライブラリであるため共有ライブラリは困難 • 通常ライブラリの共有には動的リンクライブラリが必要 静的ライブラリを用いたライブラリ共有を提案 先行研究[Zhang et al. ATC’18]で導入された共有ライブラリは効果が限定的
- 7. 提案手法 • 従来のビルド、実行手順 App ① コンパイル リンク OS機能 (ライブラリ) ロード .text .rodata .data 実行バイナリ メモリ空間 0x0 0x..FFFF .text .rodata .data
- 8. 提案手法 • 従来のビルド、実行手順 App ① コンパイル リンク OS機能 (ライブラリ) • 提案手法でのビルド、実行手順 App ① コンパイル OS機能 (ライブラリ) ロード メモリ空間 0x0 0x..FFFF 既存の静的ライブラリを直接利用 （コード修正、再コンパイル不要） .text .rodata .data 実行バイナリ .text .rodata .data
- 9. 提案手法 • 従来のビルド、実行手順 App ① コンパイル リンク OS機能 (ライブラリ) • 提案手法でのビルド、実行手順 App ① コンパイル リンク OS機能 (ライブラリ) .text .rodata .data 実行バイナリ .text.app .rodata.app .data.app 共通部分 アプリ依存部分 リンカスクリプトの変更により ユニカーネル間共通部分と アプリ依存部分を分離 ロード .text .rodata .data 実行バイナリ メモリ空間 0x0 0x..FFFF .text .rodata .data
- 10. 提案手法 • 従来のビルド、実行手順 App ① コンパイル リンク OS機能 (ライブラリ) ロード • 提案手法でのビルド、実行手順 App ① コンパイル リンク OS機能 (ライブラリ) .text .rodata .data 実行バイナリ .text.app .rodata.app .data.app ロード .text .rodata .data メモリ空間 0x0 0x..FFFF .text.app .rodata.app .data.app .text .rodata .data 共有 .text .rodata .data 実行バイナリ メモリ空間 0x0 0x..FFFF .text .rodata .data
- 11. 評価 評価環境 • lubuntu 18.10 (linux kernel 4.18) • gcc 8.2.0 評価方法 1. 静的ライブラリとしてglibcを採用 ユニカーネルを模したHello World相当のプログラムを生成 従来手法と提案手法で合計メモリ使用量を比較(3回測定平均) 2. MirageOS(OCamlのユニカーネル) [Madhavapeddy et al. ASPLOS13] への本手法適用による静的なコード解析
- 12. 評価結果(1) 0MB 10MB 20MB 30MB 40MB 50MB 60MB 70MB 80MB 0 10 20 30 40 50 60 70 80 90 100 合計メモリ使用量 同時実行数 提案手法 既存手法 約86% メモリ使用量削減 0MB 2MB 4MB 6MB 8MB 1 2 3 4 5 6 7 8 9 10 同時実行数が4未満の場合 メモリ使用量増大 既存手法 提案手法
- 14. 結論 • ライブラリの共有によるユニカーネルのメモリ効率向上手法を提案 • 既存の静的ライブラリを活用するため低コストで適用可能 • ユニカーネルを模したプログラムでの実験により 最大約86%のメモリ削減を実現 今後の課題 • ユニカーネルの同時実行数が少ない場合メモリ使用量増大 • 提案手法の効果が薄いユニカーネルが存在 • 実ユニカーネルアプリケーションにおいて効果を未確認
- 16. 補足:仮想マシン間のメモリ重複問題 ハイパーバイザによるVM間のメモリ共有 [Waldspurger OSDI’02] 他 Content-based Page Sharing ページ毎スキャンにより共有可否を決定 ◯ 適用の透過性 × 実行時のオーバーヘッド https://www.vladan.fr/vmware-transparent-page-sharing-tps-explained/
- 17. 補足: ユニカーネル基盤 solo5 • x86_64 Linux、KVM向けのユニカーネル基盤 • ArmやFreeBSD等にも拡張中 • リンカスクリプト、モニタ(ローダ)、インターフェース等を提供 • 現状MirageOSやIncludeOSに公式対応し、Rumprunも非公式対応 [Williams et al. hotcloud’16]、 [Williams et al. SoCC’18]等の成果 https://github.com/Solo5/solo5
- 18. 補足:実装詳細(リンク) • 静的ライブラリは~.oまたは~.aの形式 • ~.aでは、依存解析により一部コードがリンクされない可能性 があるので~.oに分解。 • リンカスクリプト中で指定するために、ライブラリのオブジェ クトのファイル名にprefixを付与。 • ファイル名のprefixの有無により、各入力ファイルのセクショ ンのリンク先を指定 • リンク先のセグメントやアドレスの指定等も行う。
Editor's Notes
- https://www.slideshare.net/jacopen/k8spaasserverless https://www.slideshare.net/QnibSolutions/melig-unikernel-and-serverless
- それではまず、研究背景として、現在のクラウドを取り巻く環境について説明いたします。 従来、クラウド向けのアプリケーション設計では、LAMP、と呼ばれる構成に見られるようにHTTPサーバーやデータベース等、複数のサービスを一つの仮想マシン上で動作させることが一般的でしたが、 近年では、スケーラビリティの向上や柔軟なリソース活用のため、アプリケーションを機能単位で、小さなサービスに分解し、別々の基盤上で動かす。というような設計が普及しており、それらを効率よく運用するため、軽量な仮想化基盤技術への需要が高まっています。 また、近年では、サイバー攻撃等のリスクが増大していることもあり、クラウド環境を支える仮想化基盤が、堅牢であることも求められています。 (1:00) https://cybersecurity-jp.com/cybersecurity-guide/14641 https://www.ibm.com/cloud-computing/jp-ja/icp/ https://www.publickey1.jp/blog/16/qcon_tokyo_2016.html
- こうした状況の中、現在、ユニカーネル。と呼ばれる仮想化技術の研究が進んでいます。 現在は仮想マシンとコンテナという二つの技術が、クラウド上での、仮想化基盤として主流ですが、 仮想マシンでは各ゲストマシンが、OSを個別に保持するため、比較的堅牢ではありますが、イメージサイズが大きい、起動時間が長いなど、仮想化コストが高いという問題があり、 一方で、コンテナは、ゲスト間でOSを共有するため、1ゲストあたりの仮想化コストは小さいものの、仮想マシンと比べて脆弱であるという問題があります。 ユニカーネルは、OS機能をリンクしたアプリケーションをハイパーバイザ上で直接動作させることで、軽量性と堅牢性を両立した技術であり、 本研究では、特にその軽量性を伸ばす提案を行います。 それでは、ユニカーネルについてより詳しい説明を行います。 (2:00 〜 2:10)
- 既存のユニカーネルの実装において、ユニカーネルアプリケーションはハイパーバイザ上です直接動作します。 そのため、アプリケーションはOSが行なっていた処理も、自分で行う必要があります。 従来の方法では、OS機能は静的ライブラリとしてアプリケーション毎に個別にリンクされています。 しかしこの方法では、複数のユニカーネルアプリケーションが同時に起動された場合、物理メモリ上にOS機能を提供するライブラリが重複して読み込まれ、メモリリソースを圧迫する原因となっています。 (2:40) それでは、ユニカーネルについて詳しく説明します。 ユニカーネルはハイパーバイザ上で直接動作するアプリケーションです。 ハイパーバイザは、ゲストOSを動作させる前提で作られているため、 起動処理の他、ファイルシステムやネットワーク通信等、OSの機能は必要なアプリケーションが個別に保持する必要があります。 ユニカーネルではそうしたOS機能はライブラリとして個別に静的リンクされます。 しかしこの方法では、アプリケーション毎に独立にライブラリをもつため、 特にランタイム、すなはち各アプリケーションが必ず保つような機能については、 物理メモリ上に大量の重複が発生し、メモリの効率的な活用を妨げています。 本研究では、この問題の解決をテーマとします。 それではまず、関連研究を2つ紹介します。
- そこで、本研究では、OS機能をアプリケーション毎にメモリにロードせず、 メモリ上の1つの実態をユニカーネル間で共有することで、メモリ使用量を削減するという手法を提案いたします。 (3:00~3:20) それでは、ユニカーネルについて詳しく説明します。 ユニカーネルはハイパーバイザ上で直接動作するアプリケーションです。 ハイパーバイザは、ゲストOSを動作させる前提で作られているため、 起動処理の他、ファイルシステムやネットワーク通信等、OSの機能は必要なアプリケーションが個別に保持する必要があります。 ユニカーネルではそうしたOS機能はライブラリとして個別に静的リンクされます。 しかしこの方法では、アプリケーション毎に独立にライブラリをもつため、 特にランタイム、すなはち各アプリケーションが必ず保つような機能については、 物理メモリ上に大量の重複が発生し、メモリの効率的な活用を妨げています。 本研究では、この問題の解決をテーマとします。 それではまず、関連研究を2つ紹介します。
- ライブラリの共有という概念自体は新しいものではありません。 しかし、ユニカーネルでライブラリの共有を行うには一つ課題があります。 それは、ユニカーネルが静的ライブラリを採用しているという点です。 通常のアプリケーションではライブラリの共有には動的リンクライブラリと呼ばれるような 専用の形式のライブラリを用いるため、ユニカーネルに直接使用することができず、 動的リンクを適用にはソースコードの修正等、大きなコストがかかります。 そのため、zhangらの先行研究により、ユニカーネルに対する共有ライブラリの仕組みは導入されているものの、 その適用範囲は制限されています。 そこで、本研究では静的ライブラリを用いたライブラリ共有の仕組みを提案します。 (4:00)
- それではまず、提案手法を説明するために、既存にユニカーネルのビルドおよび実行手順を説明します。 基本的に、ユニカーネルのビルド手法は通常のアプリケーションのビルド、実行手順と同様です。 はじめに、アプリケーションをコンパイルし、OS機能等のライブラリを静的にリンク、 その後、生成された実行バイナリをメモリ上にロードして実行という流れになります。 それでは、これを踏まえた上で、提案手法の説明を行います。 (4:40~5:00)
- まず、提案手法において、アプリケーションのコンパイルと、使用するライブラリは従来手法と変わりません。 そのため、本手法は既存の静的ライブラリを用いたユニカーネルの実装に対して、ライブラリのソースコードの変更なしで適用することが可能です。 (5:00~5:30)
- 続いて、提案手法でのリンクについて説明いたします。 従来の方法では、静的リンクにおいて、アプリケーションとライブラリは、リンク時に、テキスト領域、読み込み専用のデータ領域、書き込み可能なデータ領域の3つの領域毎に、まとめて格納され、ライブラリの分離は困難です。 そこで、本手法では、従来手法でのリンクに使用されている、リンカスクリプトを書き換える等の実装を行うことで、入力ファイルに応じて、共通部分とアプリケーション部分の二つに分離する形でリンクを行い。 実行ファイルの分離を行いました。 (5:40)
- 同時にリンクの変更に合わせてロード部分も変更し、 共有部分はユニカーネル間で共通のファイルからロードすることで、 物理メモリ上でランタイムを共有し、 合計のメモリ使用量を削減することがことが可能となります。 (6:00~6:30)
- それでは、本研究の効果を検証するために行った評価について説明いたします。 まず、評価環境として、本研究ではlubuntu18.10 ,linux kernel4.18、gcc8.20を使用しました。 CPU等のマシンスペックは評価に影響しないので割愛してあります。 具体的な評価方法としては 静的ライブラリとしてglibcを用いてユニカーネルを模したHello World相当の簡単なプログラムを作成し、 従来手法と提案手法による合計メモリ使用量の比較を行いました。 それに加え、ユニカーネルの最初の実装であるMirageOSに本手法を適用し検証を行いました。 (7:00)
- 初めの評価によって得られたグラフがこちらになります。 この図からわかる通り、ユニカーネルの同時実行数が少ない場合、メモリ使用量は増加します。 これは、 通常の静的リンクでは依存解析によって廃棄されていたコードが、共有ライブラリとしてリンクされ、読み込まれたためと考えられます。 しかし、同時実行数が増大すると、メモリ使用量は同時実行数に対してほぼ線形に増加し、 既存手法と比較して、提案手法ではおよそ86%のメモリ使用量削減という結果が得られました。 次に、本手法をMirageOSに対して適用した評価を説明いたします。 (8:00) タイトル
- MirageOSというOcamlのユニカーネルに対しても、同様に簡易プログラムを作成しました 提案手法を用いて生成された実行ファイルに対して静的な解析を行った結果、 理論上の効果は最大2%という結果が得られました。 この結果はヒープやスタック等の割り当て分を考慮していないため、 実際のメモリ削減効果はさらに小さなものであると考えられます。 原因としては、MirageOSではアプリケーションの実行に必要なOS機能のうちの大半がOcamlのソースコードで提供されているため、静的ライブラリに着目た本研究の提案手法の効果が薄くなったと考えられます。 (9:00) 客観的に。 句読点等、体裁を整える。
- それでは、最後に本研究のまとめを行います。 まず、本研究では、OS機能の重複によるメモリリソースの圧迫という問題を指摘し、 ライブラリの共有によるユニカーネルのメモリ効率向上手法を提案しました。 また、本研究の提案手法は、既存のユニカーネル実装で提供されている静的ライブラリを用いているため、既存実装に低コストで適用可能です。 また、評価として、ユニカーネルを模したHello World相当のプログラムでの実験を行い、最大約86%の合計メモリ使用量削減を実現いたしました。 一方、 提案手法ではユニカーネルの同時実行数が少ない場合、メモリ効率が悪化するほか、 MirageOS等、効果が薄いユニカーネルが存在する等の課題があるほか、 実際のユニカーネルのワークロードを用いた効果を測定できていない等の課題があり、 これらは今後の課題とさせていただきたく思います。 以上で発表を終わります。 (9:50) 全体としてのまとめ。 アイテマイズを使う。 結論に数値を含める。修論等参考に。 今後の課題は体裁が重要。
- テキストで関連研究を示せば良い。 1つ目の先行研究はContent-based page sharingという技術についてです。 この技術は元々既存の仮想マシンのメモリ効率向上のためVMWare が提唱した技術で、ハイパーバイザがゲストのメモリをスキャンし、ページ毎に内容が等しければCoWを用いて内容をマージするというものです。 この技術はその性質上、通常のプロセスやユニカーネルに対しても、透過的に適用可能ですが、メモリ内容のスキャンが必要なため、その実行にオーバーヘッドを伴い、またメモリ使用量の削減までに時間がかかるという問題があります。 メモリ内容の重複問題は仮想マシンにおいても存在。 Content-based samepage sharingという手法が存在。 メモリ内容をスキャン、メモリ内容が同一のページをCoWの仕組みを用いてmerge。 Unikernelの想定されるユースケースでは、ライフサイクルが仮想マシンより短いため(説明スライドを用意)、オーバーヘッドのコストが相対的に上がる。 ベストエフォート VMWare Content based samepage sharing