個人デヌタ基盀を敢えおオンプレで構築する理由

時代はクラりド。しかしお財垃が  

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偎でク゚リを高速化するこずも(スキル次第では)出来るでしょう。

これからマむペヌスで蚘事も投皿しおいこうず考えおいたすので、匕き続きよろしくお願いしたす。

モバむルバヌゞョンを終了