グーグルのクラウドを支えるテクノロジー > 第107回 Googleのサーバークラスターのメモリー圧縮機能(パート1)

※この記事は読者によって投稿されたユーザー投稿です:
  • 編集部の見解や意向と異なる内容の場合があります
  • 編集部は内容について正確性を保証できません
  • 画像が表示されない場合、編集部では対応できません
  • 内容の追加・修正も編集部では対応できません

CTC教育サービスはコラム「グーグルのクラウドを支えるテクノロジー > 第107回 Googleのサーバークラスターのメモリー圧縮機能(パート1)」を公開しました。

###

はじめに
 今回からは、2019年に公開された論文「Software-defined far memory in warehouse-scale computers」に基づいて、Googleのサーバークラスターで用いられる独自のメモリー圧縮機能について解説していきます。Linuxカーネルのzswapと呼ばれる機能を拡張したものですが、論文のタイトルにあるように、「far memory」と呼ばれるメモリーアーキテクチャーをソフトウェアで独自に実装したものになります。

ソフトウェアによる「far memory」の実装
 第32回からの記事で紹介したように、Googleのデータセンターでは、Borgと呼ばれるコンテナ管理システムを利用しており、大規模なサーバークラスター上で、さまざまなワークロードをコンテナを用いて実行しています。1つのクラスターには1万台以上のサーバーが含まれることもあり、このような環境では、サーバーに搭載する物理メモリーのコスト削減も課題の1つとなります。特に最近では、大規模なデータ処理をオンメモリーで実施するなど、大容量のメモリーを要求するワークロードが増加しており、サーバー上で稼働する多数のコンテナに対して、効率的にメモリーを割り当てることが重要になります。
 その一方で、最近、「far memory」と呼ばれるメモリーアーキテクチャーが話題になることがあります。これは、メインメモリーとストレージの間に、不揮発メモリーなどを用いた新たな記憶レイヤー(far memory)を配置するものです。メインメモリー上の長期間アクセスされていないデータを「far memory」に移動することで、メインメモリーをより効率的に利用しようというものです。しかしながら、既存の不揮発メモリーを用いた仕組みの場合、専用の機能を持った新しいCPUを必要とする、あるいは、既存のCPUでも利用できるものはアクセス速度が遅くてアプリケーションへの影響が大きいといった課題があり、Googleのデータセンターでの採用は難しい状況でした。

この続きは以下をご覧ください
https://www.school.ctc-g.co.jp/columns/nakai2/nakai2107.html

この記事が役に立ったらシェア!
メルマガの登録はこちら Web担当者に役立つ情報をサクッとゲット!

人気記事トップ10(過去7日間)

今日の用語

リファラー
ブラウザがWebサーバーに送信する情報(アクセスログ)のひとつで、ユーザーがリン ...→用語集へ

インフォメーション

RSSフィード


Web担を応援して支えてくださっている企業さま [各サービス/製品の紹介はこちらから]