特集
Oracleの「SPARC S7」プロセッサが面白いのでちょっと紹介
2016年12月2日 06:00
米Oracleが6月に発表、日本国内でも10月に発表されている「SPARC S7」プロセッサ。PC Watchではこれまで本プロセッサの概要や特徴について紹介していなかったが、公開されているドキュメントを見てみたところ、いくつか興味深い機能を見つけたので、ここで紹介したい。
SPARC S7は、2015年に発表したハイエンドサーバー向けプロセッサ「SPARC M7」のサブセットとして位置付けられる製品。M7は最大32コア/L3キャッシュ64MBという構成を採っていたが、S7は最大8コア/L3キャッシュ16MBに削減されている。最大駆動周波数はM7の4.13GHzより若干高い4.27GHzとなっている。製造プロセスは20nmで、メタルレイヤーは13。
1コアあたり最大8つの仮想スレッディングをサポートし、プロセッサ全体で64スレッドをサポートする。クリティカル・スレッド・オプティマイゼーションにより、OS側(現時点ではSolaris)から割り当てられたスレッド数に対して最適な動作をするようになっている。
それぞれのコアは、16KBの命令キャッシュと16KBのデータキャッシュを持つ。L2キャッシュはちょっと特殊で、命令キャッシュに関しては4つのコアが256KBを共有、データキャッシュに関しては2つのコアが256KBを共有する形を取る。一方L3キャッシュは全てのコアで共有する。
メモリはDDR4をサポート。CPU自身は2チャネルのメモリコントローラを2基内蔵しているとされるので、計4チャネルとなる。バンド幅は48GB/s(コア当たり6GB/s)とされており、理論値では1,500MHz(1,500MHz×4チャネル×8byte=48GB/s)だが、これは実測値と思われ、実際はより高速なDDR4-2400が搭載される。CPUにはPCI Express 3.0 x16レーン分のコントローラも内蔵している。
1個のコアにつき1個の暗号化アクセラレータを搭載する点はM7から変わっていない。AES/Camillia/CRC32s/DES/MD5/RSA/SHAといった15種類の業界標準の暗号化アルゴリズムをサポートしており、約2%程度のオーバーヘッドだけで暗号化データを出力できるのが特徴だ。
ここまで概観すると、よくできたハイエンドサーバー向けプロセッサという印象しか持たれないかもしれないが、SPARC S7/M7の核心はエンタープライズに特化した「Software in Silicon(ソフトウェア・イン・シリコン:SWiS)」である。
Software in Siliconとは?
Software in Siliconと書くと「ユーザーが書いたソフトウェアがシリコン上で高速に動作する」というイメージを持たれるかもしれないが、クラウドWatchの記事にも書かれている通り、いわゆるハードウェアアクセラレータで、SPARC S7/M7の場合、データベース処理を高速化する機能が内蔵されている。
Software in Siliconで実際に行なっている処理は4つ。1つ目が「シリコンセキュアードメモリ」である。これはメモリアクセスに関してエンドツーエンドでハードウェアバリデーションを行なうもの。例えばアプリケーションのスレッドAが、スレッドBで確保されているデータ領域に対して書き込みを行なうと、「Silent Data Corruption」と呼ばれる、(スレッドBが)“知らない間にデータが破損する”現象が発生する。
そこでシリコンセキュアードメモリでは、4bitのパターンを“キー”として使い、システムコールによりメモリを14種類に“色分け”する。キー、つまり色が一致するポインタ指定の場合のみアクセスを許可し、異なる場合はアクセスを拒否してアプリケーションに通知。これによりSilent Data Corruptionの発生を阻止するとともに、アプリケーション開発者はメモリ参照に関するバグを早期に発見することができるという。この機能により、Heartbleedのようなバッファオーバーフロー攻撃に対しても対策できるようになる。
2つ目が先ほど述べた暗号化アクセラレータ。とは言えSPARCプロセッサは2005年から既に同機能を実装しており、目新しい点ではないが、段階的に機能を強化している。データ暗号化処理によるペナルティを最小限に抑えるのが目的だ。
3つ目はインメモリのクエリアクセラレーション機能、4つ目はインラインの展開機能であるが、これらはインメモリデータベースに特化したもので、まとめて「DAX(Data Analytics Accelerators)」と呼ばれ、M7では8基、S7では4基内蔵されている。S7のCPUコア数はM7の4分の1だが、DAXに関しては2分の1と削減規模が少なく、Oracleがもっとも力を入れている部分であることが伺える(とは言え、下で述べる通りDAXはメモリコントローラに付随するもので、S7のメモリコントローラ数もM7比で半減されているので当然の結果とも言える)。
DAXはオンチップメモリコントローラに直結されており、メモリを直接読み書きできるほか、オンチップネットワークを介してL3キャッシュにもアクセスでき、CPUコアとは比較的高速にデータのやり取りができる。インメモリデータベースに特化している理由は、従来のようなディスクに置かれるデータベースでは、そちらのアクセス時間の方がはるかに長いからだ。インメモリデータベースでは、理論上メモリバス幅を目一杯使ったデータ処理が可能なはずで、OracleのエンジニアはここにCPU処理のボトルネックが存在すると着目したからと思われる。
1つのDAXには4つのパイプライン/エンジンを備えており、16個の異なるデータストリームを同時にオフロード処理できる。具体的には、圧縮データの展開、スキャン、フィルタ、ジョインなどが行なえる。
例えば、従来1GB分の圧縮データベースの中から必要情報を抽出して出力しようとし、その条件に合うデータが0.5GB分あり、展開すると4倍の2GBになるデータがあったすると、
1.CPUコアがインメモリデータベースから1GB分の圧縮データを読む
2.CPUコアが圧縮フォーマットの中でスキャンとフィルタをかける
3.必要なデータ0.5GBを抽出する
4.CPUコアが0.5GBの圧縮データを読む
5.CPUコアがデータを展開し、2GBの結果として書き込む
といった手順が必要だった。一方DAXを使うと
1.CPUコアはこのクエリのタスクをDAXにオフロードし、1GB分の圧縮データを読む
2.DAXがデータをオンザフライで展開し、追加のクエリを処理
3.CPUコアが2GBの結果を書き出し
という処理が可能となり、CPUコアは空いた時間を使って別の処理が行なえるようになるわけだ。加えて、DAXによる処理はCPUよりも高速で、単純処理では30%から最大で23倍もの速度向上を実現している。
ちなみにDAXは専用のAPIを通してソフトウェア上から利用できる。Oracleではlibdaxとvectorという2種類のAPIライブラリを用意しており、前者はデータストリームの操作、後者はベクター操作を行なうものとなっている。なお、当然だが、Oracle自身がリリースしているデータベースソフト「Oracle Database 12c」でサポートしている。
DAXを実装した背景には、インメモリ型データベースの台頭に加えて、いわゆるビッグデータで処理するデータが、ロー型からカラム型に変化している点が挙げられる。ビッグデータはこれまでのデータベース処理とは異なり、追加や更新、削除といった操作ではなく、集めたデータを集計して分析するのが主な目的で、ロー型よりもカラム型の方が向いている。また、カラム型ではデータ型が揃っているため、高い圧縮効果が得られ、容量の制限が大きいインメモリ型データベースとは相性が良い。さらに、ロック処理を行なう必要がなく、分散処理や並列処理に向くといったメリットもある。つまり、DAXはビックデータの処理に向いた実装だと言える。
Intelのx86プロセッサの場合、使用用途を想定できないので、データベースに特化したアクセラレータの実装は難しいが、Oracleはデータベース処理高速化の実装に踏み切った点がユニークだ。ここでようやくSun Microsystemsを買収したメリットが活きてきたと言えるだろう。