Snowflakeのワーカーノードのスペック調べてみた。
ローカルディスク容量が倍に、CPUアーキテクチャがx86_64からaarch64になってた。
いつのまにかスペックが上がってました。
現在のワーカーノードのスペック
2024年１月現在は、以下のようなマシンでクエリが実行される。
１ノードあたり
| パラメータ | 値 |
|---|---|
| インスタンスタイプ | C6g.2xlarge |
| プラットフォーム | Elastic Kubernetes Service |
| オペレーティングシステム | Amazon Linux 2（Linux Kernel 5.4.181） |
| CPU コア | 8コア/ノード |
| CPU アーキテクチャ | aarch64(arm64) |
| ディスク容量 | 400GB(392156184576 bytes)/ノード |
裏付けを取るため調べて知ったが、昨年５月の決算で「Graviton２に移行済み」とCFOが発言した記録があった。
We've fully migrated all of our customers in AWS to Graviton 2. [１]
もしかしたら、現在はGraviton3を使っているかもしれない。
それ以前のワーカーノードのスペック
SELECT社によると、2022年11月時点では c5d.2xlargeが使われていたらしい[2]
AWSでは各ノードがc5d.2xlarge EC2インスタンスで、16GBのRAMと200GBのSSDを搭載していることはよく知られている。
この情報と比較すると、以下のように変化したようだ。
| 項目 | 2022年11月 | 2024年１月 |
|---|---|---|
| インスタンスタイプ | C5d.2xlarge | C6g.2xlarge |
| OSバージョン | 不明 | Amazon Linux 2（Linux Kernel 5.4.181） |
| コア数 | 8コア/ノード | 8コア/ノード |
| アーキテクチャ | x86_64 | aarch64(arm64) |
| ディスク容量 | 200GB/ノード | 400GB/ノード |
以下に詳細な検証手順を示す。
検証手順
1. Pythonで情報を集める
pythonのplatformモジュールを使うと、ノードの情報を出力できる。
import platform
system_info= {
'system': platform.system(),
'release': platform.release(),
'version': platform.version(),
'architecture': platform.architecture(),
'machine': platform.machine(),
'processor': platform.processor(),
'python_version': platform.python_version(),
'python_compiler': platform.python_compiler(),
'python_build': platform.python_build(),
'os_version': platform.uname(),
'disk_usage': shutil.disk_usage("/"),
'environment_variables': dict(os.environ),
}
実行結果を示す。
{
"system": "Linux",
"release": "5.4.181-99.354.amzn2.aarch64",
"version": "#1 SMP Wed Mar 2 18:50:47 UTC 2022",
"architecture": [
"64bit",
""
],
"machine": "aarch64",
"processor": "",
"python_version": "3.11.5",
"python_compiler": "GCC 11.2.0",
"python_build": [
"main",
"Sep 11 2023 13:15:12"
],
"os_version": [
"Linux",
"PYTHON-UDF",
"5.4.181-99.354.amzn2.aarch64",
"#1 SMP Wed Mar 2 18:50:47 UTC 2022",
"aarch64",
""
],
"disk_usage":[
392156184576,
6392868864,
385763315712
],
"environment_variables":{
"USER":"udf",
"LOGNAME":"udf",
"HOME":"/home/udf",
"TZ":"America/Los_Angeles",
"OMP_NUM_THREADS":"1",
"OPENBLAS_NUM_THREADS":"1",
"MKL_NUM_THREADS":"1",
"BLIS_NUM_THREADS":"1",
"VECLIB_MAXIMUM_THREADS":"1",
"NUMBA_NUM_THREADS":"1",
"NUMEXPR_NUM_THREADS":"1",
"CONDA_PREFIX":"/usr/lib/python_udf/xxxxxxxxxxxxxxxxx",
"PROJ_LIB":"/usr/lib/python_udf/xxxxxxxxxxxxxxxxx/share/proj",
"GDAL_DATA":"/usr/lib/python_udf/xxxxxxxxxxxxxxxxx/share/gdal",
"GDAL_DRIVER_PATH":"/usr/lib/python_udf/xxxxxxxxxxxxxxxxx/lib/gdalplugins",
"GEOTIFF_CSV":"/usr/lib/python_udf/xxxxxxxxxxxxxxxxx/share/epsg_csv"
},
}
Pythonランタイムはconda。デフォルトのタイムゾーンはロサンゼルスなのか。プロセッサ名は隠されてそう。環境変数を見ると、ワーカーノードごとに処理がシングルスレッドに制限されていた。
2. /procから調査する
プロセッサ名が知りたいので/procを調査した。
Linuxでは/procフォルダ以下を見ることで、システムの情報を収集することができる。
CPUの情報が格納されているのは/proc/cpuinfoだが、読み取り権限がなかった。
せっかくなので、読み取り権限のあった以下のファイルについて見る。
- /proc/self/exe
- /proc/self/stat
- /proc/self/maps
/proc/self/exeはUDFのプロセス名を示す。これは/bin/python_udf_server_3.11であった。
/proc/self/mapsはメモリのマップファイル。
長いので今回はスキップ。読み込まれたPythonの標準ライブラリなどが見れて面白い。
/proc/self/statはプロセス自身の状態を示す。
これは以下のようなテキストになっている。
4858 (python_udf_serv) S 4857 4858 4788 0 -1 4194560 5530 601 0 0 9 1 0 0 25 5 2 0 9957 57290752 6351 18446744073709551615 2097152 16947760 281473996413216 0 0 0 0 17305601 17640 0 0 0 17 7 0 0 0 0 0 17475264 17517840 318431232 281473996417949 281473996423137 281473996423137 281473996423137 0
興味深いのはCPUの番号だった。
17 7 0の7の部分は0から始まるプロセスの実行CPUの番号を示す。
UDFを複数回実行したが必ず0~7のどれかだった。このことから8コアのCPUだと推測できる。
感想
ローカルディスク２倍増し無料、助かる。
古い情報ではx86_64と書いてある事が多いので、SPCSでハマらないようにしよう。
Discussion