永産システム開発がいかにClickHouse Cloudを活用し、POS分析を高速、低コストかつ信頼性の高いものにしたか

永産システム開発は約40年にわたり、医療・ヘルスケアシステムから大規模データマッチング、最近ではIoT対応プラットフォームまで、精度が重視される分野で高度に専門化されたソフトウェアを開発してきました。これらの多くは水面下で密かに稼働し、ミスが許されない組織のミッションクリティカルなワークフローを支えています。

その考え方は、2025年7月に東京で開催されたClickHouseミートアップで、永産システム開発の代表取締役である生方守氏が共有した最近の課題にも引き継がれています。きっかけは、クライアントからの支援の依頼という単純なものでした。従来のBIツールを基盤とした既存の分析システムは、増加するデータ量とリアルタイムインサイトへの期待の高まりにより、限界に達し始めていました。

「クライアントはより良い解決策を求めて連絡を取ってきました」と生方氏は述べています。永産システム開発はその後、信頼性を損なうことなくスケール可能かつ実用的なプラットフォームをエンジニア主導で探し求めることになり、最終的にたどり着いたのがClickHouse Cloudでした。

従来のシステム：高コストで信頼性に欠ける #

その課題において最も重要であったのは、ID-POSデータでした。これは、スーパーマーケットやドラッグストアから収集された、個々の顧客IDに関連付けられたPOSレコードです。小売クライアント一般において、バスケット分析やクロス分析、および顧客が店内で自身の身分を明かすと製品がおすすめされるリアルタイムパーソナライゼーションにこのデータが活用されています。時間が経つにつれてそのデータは積み重なり、クライアントによっては年間2億件近くのレコードが蓄積されることもあります。

このワークロードに対して永産システム開発が使用していた分析プラットフォームはQlikViewをベースに構築されており、理論上はスピードを重視して設計されていました。すべてがメモリ内で処理されるため、単純な集計の多くはわずか数秒で完了していました。「しかし、データが増えるにつれて、一部のプロセスの処理に数分かかることがありました」と生方氏は言います。さらに悪いことに、システムは予測や制御が難しい形で不具合が出始めました。「最近では、分析結果がまったく返ってこないケースが増えてきています。これは非常に深刻な問題です。」

プラットフォームを利用するクライアントが増えるにつれ、コスト圧力も強まっていきました。QlikViewのライセンスモデルでは、新規導入のたびに費用が増加していました。生方氏はこれを「ユーザーにとって大きな負担であり大きな懸念事項」と表現しています。システムのメモリ負荷の高い設計は問題をさらに悪化させました。「QlikViewはすべての処理をメモリ内で行うため、必然的に膨大なメモリを消費します」と彼は述べています。「結果として、私たちのサーバコストも増加し続けています。」

ClickHouseが深刻な課題の解決に貢献 #

チームが最初に考えたのは、オープンソースの代替手段を探すことでした。目標は、コストを削減しながらパフォーマンスとスケーラビリティの制御を取り戻すことでした。PostgreSQLのような馴染みのある選択肢や、YugabyteDBのような分散システムを評価しました。「どれも私たちが求めていた結果を出すことはありませんでした」と生方氏は語ります。落胆したチームは、より良い解決策が本当に存在するのか疑問を持ち始めました。「どうせ無駄だろうと、私たちはほとんど諦めかけていました。」

その後ClickHouseを見つけたのはほぼ偶然でした。「そのスピードは本当に驚異的でした」と生方氏は言います。「これは実際にうまくいくかもしれない」と考えました。その最初の印象から、さらに詳しく検討する価値があると判断し、最終的には本格的な導入への動きにつながりました。

東京のミートアップで、生方氏は従来のQlikViewベースのシステムと新しいClickHouseの構成の比較を並べて紹介しました。ClickHouseのほうが明らかに高速でしたが、その結果は書面上ではそこまで大きなものではありませんでした。しかし、彼は文脈が重要だと言います。「QlikViewはすべてをメモリ内で処理しています。一方、ClickHouseはそうではありません。これには本当に感心しました。」

いわゆる一般的な構成と比べても、ClickHouseは少ないリソースで安定した結果が出ました。「サーバースペックは標準的な構成より抑えめですし、高負荷寄りの設定でも動かしています。それでも性能は崩れず、結果は非常に安定しています。従来の製品だと、同じことをやろうとするとハードウェアを増やす判断になりがちですが、ClickHouseはその前に解決できる感触があります」と生方氏。

おそらく最も重要なのは、ClickHouseが負荷がかかっている状況でも予測可能な動作をすることです。「QlikViewでは、結果がまったく返ってこないことがよくあります」と生方氏は言います。「これまでのところ、ClickHouseが結果を返さなかったことは一度もありません。」

サーババランスの洗練された技術 #

ClickHouseがその有効性を証明した後、新たな疑問が生まれました。それは、効率的に運用するにはどうすればよいかということです。生方氏とチームは、CPUコアとメモリのバランスに焦点を当て、ClickHouse Cloudの異なる構成のテストを開始しました。ある構成では、30コアと120GBのRAMを使用し、ClickHouseのワークロードにおける出発点として一般的に使用されるメモリ対 CPU コア比 4 GB : 1を採用しました。

一見すると、メトリクスから疑問が浮かびました。CPU使用率は健全に見えましたが、メモリ使用量は意外に低かったのです。「そのことが、このバランスが本当に最適かどうかについての議論につながりました」と生方氏は言います。ClickHouse日本チームと話し合った後、状況がより明確になりました。「そこでかなりの量のメモリがキャッシュに使われていることを知りました。」

その動作を考慮に入れると、実際の使用量は約100GBに近くなり、最初に見えたよりもその構成のほうがバランスが良く感じられました。ここで得られた結論は決まった答えではなく、むしろプロセスのようなものでした。「もちろん、まだ多くの異なるシナリオを検討する必要があります」と生方氏は言います。チームは引き続き負荷テストを行い、サーバの仕様を調整しながら、さまざまな状況下でClickHouseの動作を観察し、構成を段階的に改善しています。

永産システム開発とClickHouseの次なる展開 #

永産システム開発のClickHouseに関する計画は、現行のシステムをはるかに超えています。「最終的にはユーザー数が増加すると予想しています」と生方氏は語ります。「我々の目標は1,000億レコード規模のデータを扱えるようにすることです。」そのスケールを達成するには、ワークロードの進化に合わせてアーキテクチャの設計をスマートに行い、継続的なテストと反復が必要です。

チームはまた、システムの日常的な利用状況を詳細に分析しています。現在、多くの分析ジョブは業務時間内に実行されています。「その結果、システムは夜間にはほとんど利用されていません」と生方氏は説明しています。利用可能な容量をより有効活用するため、週次や月次処理をオフタイムにシフトし、リソースの利用を平準化する方法を模索しています。

オートスケーリングもその議論の一部です。また、より意図的で計画的なスケーリングのアイデアも含まれます。「『計画的なスケーリング』という表現が適切かは分かりません。例えば日曜日に完全に運用を停止するのも可能かもしれません。それは有用だと思います」と生方氏は言います。

永産システム開発にとって、ClickHouseは完成されたプロジェクトというよりも、これからの展開のための基盤です。処理時間はすでに改善されており、新しい機能が可能性を広げ続けています。本当の課題は今や運用面にあります。それは、データ量と期待が増え続ける中で、大規模なリアルタイム分析システムをいかに円滑に稼働させ続けるかということです。

チームのデータ運用を拡張する準備はできていますか？ClickHouse Cloudを30日間無料でお試しください。