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

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

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

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

【OCI/GCP/AWS】メモリ1GBの無料インスタンス生活にはスワップメモリが必要

メモリ1GB無料インスタンスは太っ腹……だけど1GBでも足りない😭

 クラウドの無料インスタンスを利用している方の用途は、だいたいWordPressなどを用いた個人サイトかと思います。最近はメモリ1GBの無料VMが各社から提供されるようになり、個人サイトの運営はだいぶ楽になりました。私も、無料でこそありませんがAWS LightSailのメモリ512MBでさんざん苦労したWordPressを1GBに増やしたら安定した経験があります。

 しかし、少し欲張ったとたんにメモリ1GBでも足りなくなってしまいます。自宅にもLinuxサーバーを置いている方は、だいたいこんな感じで

メモリ32GB以上、プロセッサ8vCPUくらいはあるので、重いサーバーソフトを入れても「いきなり全く動かない」事態に直面することは無いと思います。しかしこの感覚でメモリ1GBの無料インスタンスを使うと大変なことになります……。

Logstash(ETLツール)がフリーズしまくる

 2年ほど前からツイートデータなどの蓄積・抽出にElastic Stackを使っています。全文検索エンジンのElasticsearch、データ前処理(ETL)ツールのLogstash、BIツールのKibanaが3点セットで構成されています。

 今回、このうちLogstashだけOCIの無料枠VMインスタンスに設置を試みました。というのも、自宅の回線が低速・不安定なため各種情報サービスからAPI経由で安定してデータを取得するのが難しいからです。

回線が安定したパブリッククラウドで『クラウドETL』

エンタープライズ系ツールの鬼門『JavaVM』

 ところが、データベース周りなどエンタープライズ系のツールは、複数のOSやプラットフォームで互換性を確保するため、たいていJava VM上で構成されています。まずJava VMを起動して、その上で各種アプリを起動する仕組みです。しかしこれがデカい……。

 メモリ1GBのインスタンスにLogstashをインストールして起動したところ、またたく間にメモリがすべて食いつくされてしまいました😨

こうなるともう大変。sshでのログインすら出来なくなり、モニターを見ると再起動をかけるたびにOSがフリーズしているのです😭

サーバー向けUbuntuにはスワップが初期設定されていない

 私はメモリー極小のレンタルサーバー時代からLinuxを使っていたので、てっきりクラウドのインスタンスにもスワップメモリ(メモリが足りなくなったときに、一時的にデータをディスクに退避させてメモリ不足を防ぐ仕組み)が設定されていると思い込んでいました。

 ところが、サーバー向けUbuntu Linuxのイメージは初期設定ではスワップが設定されていないのです。従って、メモリ使用量が1GBに達するとそのままOSがフリーズしてしまうことになります。

 私は泣きながら再起動して速攻でsshしてLogstashをいったん止めた上で、スワップの設定を行い、なんとかLogstashの動作を安定させることが出来ました。

スワップの設定後。2GBのスワップ領域が確保されデータの一部が退避されている

サーバーでスワップは設定するべきか?

 なぜ、Ubuntuサーバーでは初期設定でスワップが無いのでしょうか。理由はふたつ考えられます。

 第一の理由は、『速度重視』です。Webサーバーなど多数のアクセスをさばかなければならないサーバーは、常に高負荷の状態にあります。データを頻繁にディスクに退避させると、メモリとの速度差のぶんだけサーバーの処理速度が落ちてしまいます。特に業務用途では避けたいところです。

 第二の理由は、『ディスクの消耗』です。一般的にディスクはメモリーと比べて寿命が短く、頻繁にアクセスすると故障につながる恐れがあります。サービスダウンが許されない業務用途では、これも避けたいところです。

 しかし、個人用途のサーバーはめったに高負荷になりませんし、遅くても我慢すればどうにかなります。しかも、遅いと言ってもハードディスクの時代とは違い、今ではSSDなので大して遅くありません。さらに言ってしまえば、ディスクが消耗しても困るのはクラウドサービス側だけです……💦

 というわけで、

個人用途のクラウドインスタンスには遠慮なくスワップを設定しよう

というのが私の結論です。