Snowflakeのワーカーノードがアップグレードされていた!

前田 健太郎

前田 健太郎

#Snowflake #AWS

Snowflakeのワーカーノードのスペック調べてみた。
ローカルディスク容量が倍に、CPUアーキテクチャがx86_64からaarch64になってた。
いつのまにかスペックが上がってました。

現在のワーカーノードのスペック

2024年1月現在は、以下のようなマシンでクエリが実行される。

パラメータ
インスタンスタイプC6g.2xlarge
プラットフォームElastic Kubernetes Service
オペレーティングシステムAmazon Linux 2(Linux Kernel 5.4.181)
CPU コア8コア/ノード
CPU アーキテクチャaarch64(arm64)
ディスク容量400GB(392156184576 bytes)/ノード

裏付けを取るため調べて知ったが、昨年5月の決算で「Graviton2に移行済み」とCFOが発言した記録があった。

We've fully migrated all of our customers in AWS to Graviton 2. [1]

もしかしたら、現在はGraviton3を使っているかもしれない。

それ以前のワーカーノードのスペック

SELECT社によると、2022年11月時点では c5d.2xlargeが使われていたらしい[2]

AWSでは各ノードがc5d.2xlarge EC2インスタンスで、16GBのRAMと200GBのSSDを搭載していることはよく知られている。

この情報と比較すると、以下のように変化したようだ。

項目2022年11月2024年1月
インスタンスタイプC5d.2xlargeC6g.2xlarge
OSバージョン不明Amazon Linux 2(Linux Kernel 5.4.181)
コア数8コア/ノード8コア/ノード
アーキテクチャx86_64aarch64(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はプロセス自身の状態を示す。
これは以下のようなテキストになっている。

/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だと推測できる。

感想

ローカルディスク2倍増し無料、助かる。
古い情報ではx86_64と書いてある事が多いので、SPCSでハマらないようにしよう。

おすすめの記事