Critical ManufacturingがClickHouseを活用して工場現場にリアルタイムインテリジェンスをもたらす方法

製造業に一時停止ボタンはありません。eコマースやSaaSのダッシュボードが遅いとイライラします。しかし、工場のダッシュボードが遅延すると、生産ラインが停止したり、検査で不良品が見逃されたり、エンジニアが間違った原因を追いかけて貴重な時間を浪費したりすることになります。工場の現場で意思決定に必要な正確でリアルタイムなデータが手に入らなければ、たった1分のダウンタイムでも数千ドルのコストになり得ます。

それが Critical Manufacturing が事業を展開する世界です。ポルトガルに本拠を置くこのグローバル企業は、半導体、エレクトロニクス、医療機器、産業機器など、ハイテク製造業向けのエンタープライズMES(製造実行システム)ソフトウェアを開発しています。数十カ国にまたがる100社以上の顧客と、世界中で数百件の導入実績を持つ同社のプラットフォームは、「リアルタイム」が前提となる工場の24時間365日稼働を支えています。

「当社の分析機能は、顧客の生産性と効率に直結します」と、同社のIoTデータプラットフォームを管理するリードソフトウェアエンジニアのRicardo Magalhaes氏は語ります。「私たちは常に、現場から流れてくるイベントストリームをサポートしています」

私たちはRicardo氏に、MESにおける分析の役割、Critical Manufacturingがレガシースタックから ClickHouse Cloud へ移行した経緯、そしてClickHouseが単一の分析ユースケースからビジネス全体のプラットフォーム層へとどのように拡張されたかについて話を聞きました。

工場の「神経系」 #

ソフトウェアインフラに関わったことがある方なら、テレメトリパイプライン、アドテクの集計、大規模な製品分析の話を耳にしたことがあるでしょう。製造業はそれとは異なる土俵です。データ駆動でないわけではなく、計装される対象が物理的なシステムだという点が違うのです。

Ricardo氏はMESを「工場現場の神経系」と表現します。SAPのようなエンタープライズ計画システムが「何をいつ作るか」を決めるのに対し、MESは生産を現実のものにする場所です。すべての製品をすべての工程で追跡し、設備とオペレーターを管理し、作業指示書とレシピを実行し、最終製品が使用可能かどうかを判断する品質シグナルを取得する役割を担います。

医療機器のような規制された業界では、MESはコンプライアンスとトレーサビリティの記録システムでもあります。どの材料がどの完成品に使われ、いつ加工され、その過程で何が起こったかを、しばしば何年も後まで記録します。

Critical Manufacturingにとって、これはRicardo氏が言う「膨大なデータの課題」を生み出します。オペレーターのあらゆる操作はイベントです。あらゆる品質測定はイベントです。あらゆる材料の移動はイベントです。これに機械、ライン、施設をかけ合わせると、MESは数百万のイベントが分単位、機械単位で取り込まれる洪水となります。

「私たちの分析レイヤーは、このデータの消火栓のような流れを実用的な洞察に変えなければなりません」とRicardo氏は語ります。「インフラ面で極めて要求が厳しく、しかも高速でなければなりません」

古いシステムからの脱却 #

Critical Manufacturingの旧分析システムはMicrosoft SQL Server上で稼働していました。長年機能していましたが、会社の規模が拡大し顧客の期待が変化するにつれ、レガシーなアプローチでは現代の要求に応えるスケーラビリティを実現できなくなりました。

Ricardo氏が説明するように、今日のオペレーターは静的なレポートにはほとんど価値を見出しません。彼らはサブ秒のクエリによる即時の洞察を期待しています。複数ラインにまたがるスライス&ダイス分析、年初来の計算、長期の履歴トレンド、工場現場で何かが変わったときのアドホックな原因分析を求めています。「彼らはレポートを待つ我慢強さなどありません」とRicardo氏は言います。「何も待つ気はないのです」

一方で、Industry 4.0の台頭がデータ量をかつてないほど押し上げ、より多くの機械、センサー、プロセスがオンライン化されるにつれ、システムは数百万から数十億のレコードへと移行しています。

結果は予測可能でした。履歴クエリに時間がかかりすぎるようになり——「時には数時間も」とRicardo氏は語ります。リアルタイムダッシュボードは生産イベントに追従するのに苦労しました。インデックスとパーティションのチューニングそのものが運用上の負担となり、チームはシステムを使える状態に保つだけで、集計ジョブやデータメンテナンスとの戦いを強いられました。ストレージコストは、さらなる遅延を防ぐために設計されたインデックスがシステムに蓄積されるにつれて上昇しました。

Ricardo氏の言葉を借りれば、古いアプローチに本質的に壊れた点はありませんでした。「単に、私たちがそれを上回ってしまったのです」と彼は語ります。

すべてはRedditから始まった… #

2022年までに、Critical Manufacturingは異なるアプローチが必要だと認識していました。イベントストリームを取り込み、サブ秒クエリによるリアルタイムダッシュボードを実現し、大量集計をサポートし、スケールしても費用対効果が高く、メンテナンスが容易なものです。

ある晩、Ricardo氏がRedditを眺めていると、/r/dataengineeringのスレッドで自分のものに非常によく似た問題が説明されているのに偶然出くわしました。大規模な 時系列 、リアルタイム分析 、そして追いつけない従来型データベース。

当時、Ricardo氏とチームは「お決まりの候補」——Pinot、Druid、Databricks、Snowflake——を評価していました。それぞれに強みはありましたが、Ricardo氏に言わせれば、「試したソリューションはどれも、重い依存関係と膨大な運用オーバーヘッドを伴っていました」

Redditのスレッドで、誰かがコメントしていました。「ClickHouseを試してみろ」。Ricardo氏はそれまで聞いたことがありませんでしたが、リンクをコピーして自分宛にメールし、翌朝ダウンロードしました。

「昼までには、最初のMESテーブルを作成して本番データをロードしていました」と彼は語ります。「その日の終わりには、最初の マテリアライズドビュー を作って、Kafkaトピックから読み取り、MergeTreeテーブル に書き込んでいました。圧倒されました」

SQL Serverで数分かかっていたクエリが、ミリ秒で返ってきました。さらに良いことに、立ち上げが「驚くほど簡単」で、重い依存関係や複雑なセットアップは不要でした。馴染みのあるSQLインターフェースのおかげで、チームは一から学び直す必要もありませんでした。

「エンジニアとして、適切なツールは戦う相手であってはならないと確信しています」とRicardo氏は語ります。「ClickHouseは私たちがやっていたことに完璧にフィットしました。ただ動いたのです」

POCからプラットフォーム層へ #

その初日でチームはPOCを得ましたが、Ricardo氏が言うように「1日のテストでは、すべてを賭けるには不十分でした」。そこで彼らは正式な評価を実施し——ClickHouseは引き続き際立った結果を見せました。

ネイティブKafka統合 により、ストリーミングトピックからClickHouseへのデータ移動が容易になりました。カラム型ストレージ と ベクトル化クエリ実行 は、分析負荷下で一貫したパフォーマンスを提供しました。圧縮 と TTL(time-to-live) ポリシーにより、ストレージ効率の向上と自動化されたデータライフサイクル管理が可能になりました。そして JSONサポート により、絶え間ないスキーマの調整なしに半構造化イベントペイロードを処理できるようになりました。

数週間後、彼はリーダーシップチームとのミーティングを設定しました。小さなプロトタイプ——Kafkaを入力、ClickHouseを中間、ダッシュボードとクエリを上に——を構築し、彼らに説明しました。チームが直面している課題を理解していた技術担当VPは、すぐに興奮しました。ミーティングの後、Ricardo氏は彼自身が試せるようにClickHouseのクエリインターフェースへのアクセスを与えました。

「彼はパフォーマンスに圧倒されました」とRicardo氏は語ります。「データを非常に素早くスライス&ダイスできるようになりました。彼は『これはゲームチェンジャーだ。私たちの分析のやり方を変える』と言いました」

技術的な確信とビジネス側の賛同を得て、ClickHouseはPOCから本番へと移行し、分析から始まり、急速にビジネス全体へと拡大しました。

今日、ClickHouseはCritical Manufacturingの履歴データとリアルタイム分析のための運用データストアを支えています。機械センサーデータや状態追跡などの製造設備テレメトリを保存し、現場イベントと空気質、湿度、粒子数などの環境シグナルとの相関分析をサポートしています。

ClickHouseは社内のオブザーバビリティにも使用されています。アプリケーションログ、メトリクス、トレースは OpenTelemetry を通じてClickHouseに流れ込み、24時間365日オンラインを維持する必要のあるシステムのトラブルシューティングと監視を統一された場所で行えるようになっています。

同社がAI駆動の機能に投資する中、ClickHouseはそこでも役割を果たし始めており、製品内のRAGシステムをサポートする埋め込みを保存しています。

「私たちは1つの分析問題から始めました」とRicardo氏は語ります。「今では、ClickHouseはどこにでもあります」

その道のりにおける主要な最適化 #

チームはClickHouseを環境を超えて柔軟に展開しており、さまざまなメーカーのニーズに応えるためクラウドとオンプレミスの両方の導入をサポートしています。また、パフォーマンスと効率を最大化するための一連の重要な最適化も行ってきました。

大きな転換の1つは、ETLからELTへの移行でした。旧システムでは、変換はロード前に行われていました。メトリクス定義のバグがあれば、チームは集計パイプラインを最初から再実行する必要があり、時には数時間または数日かかることもありました。ELTでは、ソースデータを保持し、変換は後でClickHouse内で適用します。「変換を修正するだけで完了です」とRicardo氏は語り、さらに「ELTは、データベースがクエリ時に変換できるほど高速である場合にのみ機能します。これがClickHouseのスーパーパワーの1つです」と付け加えます。

2つ目の最適化は、遅延到着イベントと重複の管理に ReplacingMergeTree を使用することでした。これらはどちらも製造業ではよくあることで、デバイスがオフラインになり、再接続後にバーストでデータを送信することがあります。順序キーを慎重に設計することで、チームは状態テーブル(エンティティの現在の状態)と履歴テーブル(完全な監査証跡)を維持しながら、重複排除の仕組みはClickHouseに任せることができます。

また、JOINの多いリレーショナルクエリパターンを避けるために 非正規化 にも力を入れています。Ricardo氏が説明するように、製造データは本質的にリレーショナルであり、12以上のJOINを必要とするクエリを目にすることもよくあります。しかし、分析的なカラム型システムはそのような形状を必ずしも好みません。チームはリレーションシップのコンテキストをJSONフィールドに埋め込み、クエリ時に値を抽出することで、複数テーブルのJOINを排除し、パフォーマンスを向上させ、開発者体験を簡素化しました。

最後に、TTLベースのライフサイクル自動化 が、手動ジョブとスクリプトの寄せ集めを置き換えました。ホットデータは高速かつアクセス可能なまま維持され、古いデータは自動的に期限切れにしたり、より安価なストレージに移動したりできます。データ保持、トレーサビリティ、コスト管理が重要な環境では、この組み込みのライフサイクル管理が大きな運用負担を取り除きます。

次のステップ: 大規模な高可用性 #

ClickHouseの旅を始めて数年が経ちましたが、Critical Manufacturingにはまだやるべきことがあります。Ricardo氏が指摘するように、同社はSQL ServerからClickHouseへのワークロードの移行を続けており、「データを失うことは大惨事」という厳しい要件があります。

ロードマップの次のステップは、より高い可用性と耐障害性です。これは Replicated*テーブルエンジン への移行と、マルチレプリカ展開への信頼を構築し、その後、フットプリントと顧客の需要が拡大するにつれてシャーディングとレプリケーションのパターンへと拡大することを意味します。

Ricardo氏にとって、その一貫した思いは、RedditでClickHouseを発見した最初の日と変わりません。製造業はますます接続され、計装され、データ駆動になっています。すべてのデバイス、機械、生産ロットが、捕捉する価値のあるシグナルを生成しています。「ワークロードは本当に変化しており、フロンティアは曖昧になっています」と彼は語ります。

機会は、それらのシグナルがアクセス可能になったら何ができるかという点にあります。そして、工場が決して止まらない世界では、その背後にあるデータプラットフォームもまた、止まることはできません。