オルタナティブ・ブログ > 吉政忠志のベンチャービジネス千里眼 >

IT業界でベンチャービジネスの支援をしている執筆者が日々の活動ログと感じたことを、徒然なるままに書き綴っていきます。

グーグルのクラウドを支えるテクノロジー > 第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

Comment(0)