Snowflakeのワーカーノードがサイレント大幅アップグレードされてた！

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でハマらないようにしよう。