Ubuntu 22.04 LTSが自宅PCクラスタの救世主な理由【2022年3月版】

自宅PCクラスタを組むなら『弁当箱PC』で決まり❕

個人データ基盤を敢えてオンプレで構築する理由』でご説明した通り、「ビッグデータを贅沢に使いたい」ならクラウドとは別にオンプレのPCクラスタが必要です。そして狭い日本の家でPCクラスタなどという仰々しいシステムを組むには超小型PCが必要です。私はサイズが分かりやすいので『弁当箱PC』と呼んでいます🤗

弁当箱PC(超小型PC)の特徴は、

  • モニタ無しで容量1リットル前後の弁当箱サイズ
  • 消費電力40W以下(CPUのTDPは35W)
  • グラフィックはGPU内蔵型(APU)

といったものです。小ささにこだわるのは、限られた面積で少しでも多くのCPUコアを動かすためです。消費電力にこだわるのは、1500Wの家庭用コンセントで安定稼働させるべく余計な機能による電力消費を抑えるためです。特に高性能GPU(グラフィック)はディープラーニング以外の用途では不要です。

弁当箱PCは本来受付やコールセンターの端末用のため、CPUやメモリの性能が全体的に抑えめです。しかしPCクラスタ用途では弁当箱サイズの範囲内で可能な限り贅沢にする必要があります。処理速度だけなら遅いPCを何台も並べるより我らがヒーロー藤井SOTAのThreadripperのように超高性能PC1台の方が強いです。PCクラスタは貧乏人の激安PC活用術分散処理データ保全の両取りを狙って敢えて複数台にしますが、個々のPCが速ければ速いに越したことはないです。具体的には、

  • CPUは最低6コア、予算が許せば8コア16スレッド
  • メモリは最低32GB、予算が許せば64GB
  • 512GB以上のSSD、予算が許せば1TB
  • USB Type-C 3.2 Gen2 10Gbpsポート推奨
  • 台数は5台以上を想定

となります。1台10万円以下に抑えたいところですが、インフレが進んだ今では10万円を超えてしまうかも知れません。予算に余裕がないならリース落ちの中古PCを拾っていくのもひとつの選択肢です。USB 3.2 Gen2推奨なのは将来的に10Gbps EthernetのハブとLANアダプターが安くなった際に10GbEで運用出来るからです。ストレージが控えめなのはクラスタの強みである「壊れたら復旧など考えずさっさと入れ替え」を想定しているからです。

2022年時点のお勧めCPUはAMD Ryzen APU

PCクラスタのCPUはIntelかAMDの2択となりますが、現時点で私はAMD Ryzen APU推しです。IntelがCPU自社製造に縛られて未だに14nmや10nmのプロセスを使っているのに対して、AMDはTSMCの最新7nmプロセスを使っており近い将来5nmも出てくるからです。CPUが微細化するほど消費電力あたりの処理性能(通称『ワッパ』)が上がるので貧乏人に優しい自宅クラスタで有利だからです。

実際に2022年3月20日時点でHPの弁当箱PCでIntelとAMDの同価格帯商品の性能を比べてみると、

  • Intel …… Core™ i5-10500T
  • AMD …… AMD Ryzen™ 5 Pro 5650GE

消費電力はどちらもTDP35Wで6コア12スレッド。CPUの総合性能(マルチスレッド)ベンチマークであるPassMark resultはAMDの19266に対してIntelは10760でAMDの方が2倍近く速いことが分かります。この差は基本的に微細化の差であり、将来的には微細化でどちらが勝つかで勝負が決まると思われます。なおbig.LITTLEという「比較的大型で高いパフォーマンスを持つCPUコア(big)と、小型で低消費電力のCPUコア(LITTLE)を組み合わせる」技術を用いた製品も出てきていますが、サーバー用途では基本的に全てのCPUコアを用いるので無意味です。

Ubuntu Linuxは無料で管理が楽なOSだが、AMD対応は遅れている

Ubuntu LinuxはWindowsと比べて巨大なアップデートで苦しむことが少なく、必要な機能を選んで入れられるのでスキルがある方には便利なOSです。サーバーが10台にもなるとアップデートの通信量も10倍になるので、貧弱な回線しか引けない貧乏人にとっては比較的アップデートが小さいUbuntuが有力な選択肢になります。

また弁当箱PCを新品で買うとリモートデスクトップのホストになれないWindows Homeが入っていることが多く、高いProを買うくらいならUbuntuに替えた方が楽で安上がりという事情もあります。

ところが、LinuxはかつてAMD対応が遅れており、私も「Ubuntu 20.04 LTSがRyzen5 4600Hノートで画面表示出来ない」など苦労がありました。しかし、Linuxの親玉リーナス・トーバルズがAMDを寄付してもらった買ったことでAMD対応が進み、UbuntuでもAMD Ryzen APUで画面表示出来るようになってきました

Ubuntu Linux 22.04 LTSは初の最新Ryzen APU対応LTSバージョン

Ubuntuは長期サポート版(LTS = Long Time Support)と無印版があり、LTSは2年ごとのリリースとなっています。サーバーとして真面目に使うならLTSが前提となるため、2022年4月21日にリリース予定のUbuntu Linux 22.04 LTSが初の最新Ryzen APU対応LTSバージョンとなります。

Ubuntu 22.04 LTSは2032年3月までのサポートなのでサーバー運用でも安心

Ryzen APUへの対応はUbuntuではなくLinuxカーネルで行われているので、

  • Linuxカーネルのどのバージョンから該当するRyzen APUに対応しているか
  • Ubuntu LTSがどのバージョンのLinuxカーネルを採用するか

の2点でお手持ちのRyzen APUでUbuntuが(素のバニラ状態で)動くかが決まります。具体的には、Linuxカーネルバージョンは

となります。なおTDP35Wモデルのうち5000番台は5300GE(4コア)、5600GE(6コア)と5700GE(8コア)、4000番台は4300GE(4コア)、4350GE(4コア)、4600GE(6コア)、4650GE(6コア)、4700GE(8コア)、4750GE(8コア)などとなります。

Ubuntuが採用するLinuxカーネルは下記となります:

  • Ubuntu 20.04 LTS …… 5.4
  • Ubuntu 20.10 …… 5.8
  • Ubuntu 21.04 …… 5.11
  • Ubuntu 21.10 …… 5.13
  • Ubuntu 22.04 LTS …… 5.15

長くなりましたが、要は「新品のRyzen弁当箱PCを買って2022年4月21日まで待ってUbuntu 22.04 LTSを入れれば動く(はず)」ということです。

なお、私は現在無職で貧乏なのでPCクラスタを全部入れ替えることなど出来ませんが、1台だけ4750GEを入手済です🤗

個人データ基盤を敢えてオンプレで構築する理由

時代はクラウド。しかしお財布が……

AWSやAzure、GCP、OCIなど大手ITはクラウドサービスを揃え、熱心に推進しています。個人でもクラウドを学習しやすいように、無料枠クーポンを拡充するベンダーも増えてきました。

クラウドはPCやLANなどの初期投資が不要でコスト的にも敷居は低く、高性能PCを上回る処理能力の仮想マシン(VM)インスタンスも提供されています。

しかし、常時稼働するとランニングコストが1台あたり月1万円を超えてきます。私は90年代からレンタルサーバーで当サイトを運営してきましたが、普通のサラリーマンとして自腹でサーバー費用を負担するのは月 1万円あたりが限界でした。

クラウドがコスト的に有利なのは「必要なものを必要なときだけ」調達するからです。具体的には当Webサイトのように最小限のリソースだけ常時稼働する場合、あるいは機械学習などのために高性能GPUなど贅沢なリソースを一定時間だけ用いる場合などに限られます。技術力が高い方なら、データ処理タスクにしか課金されないサーバーレスアーキテクチャでシステム全体を構築することも選択肢となり得ます。

いずれにせよ、「使い放題はクラウドでは実現出来ない(現実的な費用では)」ということです。例外として、常時稼働こそ出来ませんが月1,000円でGPUインスタンスが使い放題Colab Proあたりがデータ基盤として個人が契約出来るクラウドの限界、との認識です。

Excelで出来るデータ分析にデータ基盤は要らない

ここでいったん原点に戻り、「個人が何のためにデータ基盤を構築するのか?」というテーマを考察します。

学校の課題や仕事で、初めてデータ分析に取り組んだときのことを思い出してみましょう。ほとんどの人はExcelだったと思います。機械学習界隈では「なぜかいきなりPython」というストーリーが多いです。しかし、PythonやRはExcelより圧倒的に敷居が高いですから、本来は「Excelでは無理だから」PythonやRに取り組むのが筋、というものでしょう。具体的には

  • Excelにない機能を使いたいのでPythonやRなどの言語を使う
  • Excelでは処理出来ないほど巨大なデータを操作したいのでSQLデータベースを使う
  • ギガバイト、テラバイト単位のデータベースを管理したいのでデータ基盤を構築する

といった動機であるはずです。これってかなり高度で贅沢ですよね。まずExcelやGoogleスプレッドシートを試してみて、データ分析の目的が本当にExcelやGoogleスプレッドシートで足りないのか確認することをお勧めします。特にGoogleスプレッドシートはPC版のExcelではやりにくいウェブからのデータ取得も無料で出来ますので、集めたいデータがビッグデータでなければ最初に検討するべき選択肢だと思います。

個人データ基盤を作るのは「ビッグデータを贅沢に使いたいから」

ここまで来ると、個人でデータ基盤を作るのは「ビッグデータを贅沢に使いたいから」だということが見えてきます。本来なら企業や大学でしか扱えないような巨大なデータを敢えて個人で蓄積・活用したいのが動機ですから、石油王でもなければクラウドでは無理ということになります。

オンプレと言っても、PC1台で出来るタスクなら『データ基盤』などという仰々しいものを個人で作る必要はありません。バックアップの観点でもGoogleドライブでは100GBが年額2,500円ですから、将来的に1TBを超えるようなデータを管理したいような人が『データ基盤』を検討する価値がある人、ということになります。

個人データ基盤で想定するアーキテクチャ=『PCクラスタ』

個人でテラバイト単位のデータを大量に蓄積して利活用するには、さすがにクラウドやPC1台では無理があります。そこで複数台のPCを連携する『PCクラスタ』を考えてみます。

個人用PCは最近ではノートPCが主流ですし、タワー型のような大型PCを複数台自宅に置くのは現実的ではありません。しかしコールセンターや受付用に販売されている超小型PCなら、5台くらい自宅に置いても場所はさほど取りません。私の自宅では、実際に超小型PCが10台ほど稼働しています

超小型PCで組むPCクラスタ

1台あたりの消費電力は30W前後で、電気料金は1台あたり月額数百円程度です。電気料金だけで見れば「オンプレデータ基盤のランニングコストはクラウドの100分の1」ということになります。

データ基盤としてのPCクラスタ利用を想定する場合、LANの速度が深刻なボトルネックとなります。現状ではコストとの兼ね合いから2.5GbEで構築するのが現実的です。少しお値段が張りますが2.5GbE対応のハブとUSB接続のLANアダプターを用意することをお勧めします。

OSは、アップデート時の通信量の少なさやサーバー管理の容易さなどからUbuntu Linuxを使用しています。現在はUbuntu 20.04 LTSを使用していますが、2022年4月末にリリース予定のUbuntu 22.04 LTSに入れ替える予定です。Ubuntu 22.04 LTSは、最近のAMD Ryzen APUでも素のバニラ状態で動く初のLTSリリースとなるため大いに期待しています。なお、後にご紹介する『分散データベース』は大半がJava VM上で動作するため、中古PCバンドルで安価に入手出来るWindows Professionalなど一般の方が使い慣れたOSでも構築運用自体は可能と思われます。

念のため補足しておきますが、超小型PCをクラスタ運用する際には、モニターやキーボードは邪魔なので外しています。必要に応じてHDMI/DisplayPortで接続出来るモバイルモニター、キーボードとタッチパッドが一体化した入力装置を接続してメンテナンスを行います。部屋が暑くなる方は先の写真のように超小型PCと同サイズのUSBファンを重ねて設置しておくと夏場も少し安心です。

SQL or NoSQL?

PCクラスタ向けのデータ管理には専用のソフトウェアが必要です。スタンドアロンのデータベースは定期的なバックアップでデータを保全しますが、PCクラスタ向けの分散データベースはデータ本体を分割して複数の『レプリカ』としてサーバーに分散格納する『シャーディング』という仕組みで動きます。

これまで分散データベースにはNoSQLの『Elasticsearch』を使ってきました。しかしElasticsearchはKibanaなど同社のBIツールと連携して用いることを前提としており、無償の範囲では汎用的なJDBCコネクタを利用出来ないことなどから、次期のデータ基盤は分散RDBに替えようと思っています。

NoSQLはJSON&KeyValueでのデータ格納を前提としています。ログデータの蓄積に向いており柔軟なデータ構造に対応出来るという意味では優れています。しかし、データ分析の際はほぼほぼ表形式に加工して用いることやデータ格納時にデータ型をチェックしておかないと分析時に前処理で困ることが多いことなどから、私にとってはSQL対応の分散RDBでデータを管理するのが一番、という結論に至りました。

クラウドでは『ボタンひとつ』で使える分散RDB。しかしオンプレでは……

分散RDBは分散データベースの一種で、複数のサーバーにデータを複製して保存するシャーディングという技術を用います。サーバーの数を増やしてレプリカを再構築すれば自動的に新しいサーバーにデータが複製されますし、サーバーのうち1台が壊れても他のサーバーにレプリカが保存されているのでデータを失わずに済みます。

個人でもNASなどでRAIDを運用している方も多いと思いますが、NASそのものが壊れてしまうとデータはHDDからサルベージしなければならず、無事サルベージ出来るかも運次第、というのが現実です。ハードウェア障害時にもデータを実運用出来る形で保持するためには、PCクラスタでデータをレプリケーションして分散運用するのがオンプレで唯一の有効な手段と考えています。

このような技術は、大手クラウドでは既に当たり前のものとなっています。GoogleのCloud Spannerやデータ分析に特化したBigQuery、AWSのAmazon Redshiftなどはユーザーが意識しない形で巨大な分散データベースを構築しており、これによりペタバイト級のデータを扱えるとされています。データのレプリケーションもユーザーに意識させることなく複数のデータセンターに分散して格納されているため、データの堅牢性という意味ではクラウドが最強であることに疑いはありません。ただし、当然ながら堅牢な分だけお高いので、データ保全命でクラウドにビッグデータを置くかどうかは「お財布と相談」になります。

しかし、オンプレ用の分散RDBには従来、めぼしいものがありませんでした。オープンソースの製品もいくつか存在してはいるのですが、SQLの対応が弱かったりJDBCドライバで文字化けが出るなど汎用的なデータ基盤としては厳しいものがありました。開発元もアメリカではなく会社としての事業継続性も未知数、という印象。

分散RDBの決定打となるか?PostgreSQL拡張『Citus』

ところが最近になって、マイクロソフトからAzure Database for PostgreSQL – Hyperscale (Citus) というクラウドサービスが出てきました。これ自体は他社クラウドの分散RDBと大差無いのですが、

  • 定番のOSS RDBであるPostgreSQLを拡張する形で分散RDBを実現している
  • PostgreSQLの拡張であるため、BIなど各種ツールが用意しているPostgreSQL用のJDBC/ODBCドライバがそのまま利用できる(かも知れない)
  • 【これが重要】CitusはOSSであり、オンプレで利用できる
  • 開発元のCitus Dataは2019年にマイクロソフトが買収しており、経営が安定している

など利点が多く「まさに決定的」という印象です。

Citusはマイクロソフト傘下でありながらOSSであり、オンプレで使える

マイクロソフトの藤田氏によれば「Citus Dataの創立者から聞いた話ですが、買収提案を受け入れた理由は、MicrosoftがOSSコミュニティーに最も貢献しているパブリッククラウドプロバイダーだったからとのことです」とのこと。ベンダーがここまで明言している以上は、CitusがOSSサポートを中止することは当分ないはず、です。

Citusを使うのはAzureが一番楽だと思いますが、Citusがオンプレで提供されている限り、その気になればAWSやGCPのVM上でもCitusによる分散RDBを構築運用できるはず、です。これはクラウドベンダーにロックインされた挙句、突然の大幅値上げで泣く羽目になっても逃げる余地があることを意味します。これがどれだけ重要なことかは、IT業界に長い方ならよくご存知でしょう。

うちでは「全部これから」です💦

我が家の自宅クラスタは、2022年4月末のUbuntu 22.04 LTSのリリースを待って全てのサーバーOSを入れ替える予定です。これに合わせて分散データベースもCitusに入れ替えたいと考えており、「全部これから」です。近い将来PostgreSQL自体も分散RDB機能を持つようになるかも知れませんが、それを待っていられるほど私の寿命は長くなさそうです。

データ活用の観点からも、従来kibanaやPythonなどに限られていた分析ツールがJDBC/ODBC対応の各種BIツールに拡がることが期待されます。無償で多機能なPower BI Desktopなどが使えるはずですし、PostgreSQL自体が持っているマテリアライズドビューなどの機能を用いてRDB側でクエリを高速化することも(スキル次第では)出来るでしょう。

これからマイペースで記事も投稿していこうと考えていますので、引き続きよろしくお願いします。