位置情報を「使える情報」に
変える基盤をつくる。
顧客課題は、GPSの生データはそのままでは業務に使えないこと。設計基準は、ビジネスインパクトからの逆算。
データはあるのに、
確かなことが言えない。
車両から送られてくる位置情報は、日々膨大な量が蓄積されていました。しかしその生データは、そのままでは業務判断に使える状態にありませんでした。
GPSの座標には誤差が含まれます。そのため「この車両が今どの道路を走っているのか」を機械的に判定しようとすると、並走する高速道路と一般道を取り違えたり、交差点付近で走行経路が飛んだりします。データはあるのに、そこから確かなことが言えない状態でした。
同時に、扱うべきデータ量は車両台数の増加とともに膨らみ続けていました。精度を上げようとすれば処理は重くなり、インフラコストは膨らみます。リアルタイム性を求めれば求めるほど構成は複雑になり、運用は属人化していきます。「精度」「速度」「コスト」「運用のしやすさ」が互いに引っ張り合う状況で、どこに着地させるかが決まらない。それがプロジェクトの出発点にあった問いでした。
技術ではなく、
ビジネスインパクトから決める。
この領域には「唯一の正解」がありません。インフラはオンプレミスでもクラウドでも実現でき、ストリーム処理エンジンにも複数の選択肢があり、位置判定の推論方式にいたっては幾何学的手法から確率モデル、機械学習ベースまで幅広い方式が存在します。どれを選んでも技術的には成立します。
だからこそ、技術の優劣から入らず、「業務にどれだけのインパクトが出るか」を先に定義し、そこから逆算して構成を決めるという順序を取りました。
具体的には、次の問いを技術選定より先に置いています。
- この判定結果は、どの業務判断に使われるのか
- その判断に必要な精度・鮮度はどの水準か
- その水準を超える精度に、追加投資する価値はあるのか
- 構築後、誰がこれを運用し続けるのか
この問いに答えた時点で、必要な技術構成の輪郭はほぼ決まりました。
低レイテンシの処理と大規模分析を、
同じ基盤に載せない。
業務インパクトを整理した結果、求められる処理特性が一つではないことが明確になりました。
車両ごとの走行状態を保持しながら逐次的に道路を判定する処理は、リアルタイム性が業務価値に直結します。ここは車両単位で状態を管理できるストリーム処理エンジン（Flink）に載せました。
一方、同じGPSデータを使った人流データの拡大推計は、サンプルから母集団を推計する分析的な処理であり、求められるのは鮮度よりも大規模データを捌く能力です。こちらは大規模データの分析に適したSpark Streamingで処理しました。
収集はFluentd、メッセージングはKafkaが受け持ちます。ひとつのエンジンにすべてを背負わせるのではなく、業務価値の性質ごとに適した技術を配置する構成です。
最高精度ではなく、業務要件を満たす
最小限の複雑さを選ぶ。
推論方式には、より高精度な選択肢も存在しました。しかし精度を1段上げるために構成の複雑さが跳ね上がり、運用が属人化し、インフラコストが膨らむのであれば、投じたコストに見合うインパクトは得られません。「業務要件を満たす最小限の複雑さ」を評価基準の中心に置いたことが、この案件における技術的な核心でした。
大容量ストリーミングで実際に効いてくる
物理制約。
ストリーミング基盤の設計では、アルゴリズムやエンジン選定よりも先に、物理層のボトルネックが処理性能の上限を決めてしまう場面が多くあります。この案件でも、以下の制約を前提に置いた上で構成を組み立てました。
ストレージI/O：状態管理の実体はディスクアクセス
車両ごとの走行状態を保持するステートフル処理では、状態がメモリに収まらない規模になった時点で、ディスクベースの状態管理（RocksDB等のLSM-tree系ストレージ）に載せることになります。ここで効いてくるのがランダムリード性能です。
- LSM-treeは書き込みには強い一方、読み出し時に複数のSSTableを探索するため、read amplificationが発生します
- さらにバックグラウンドのcompactionがwrite amplificationとI/O帯域の食い潰しを起こし、これが処理レイテンシのスパイクとして表面化します
- ローカルNVMe SSDとネットワークストレージでは、レイテンシもIOPSも一桁単位で変わります。状態サイズが大きい処理をネットワークストレージ上に置くと、アルゴリズムをいくら最適化しても頭打ちになります
対策としては、状態のTTL設計（不要になった車両の状態を確実に破棄する）、キー設計の見直しによる状態サイズそのものの削減、そしてローカルNVMeを持つノードへの処理の配置が基本線になります。
ネットワーク帯域：シャッフルとレプリケーションが帯域を食う
大容量データのリレーでは、ネットワーク帯域が実質的なスループット上限になります。
- メッセージング層のレプリケーション（可用性のためにデータを複製する）は、そのままネットワークトラフィックの倍増を意味します。レプリカ数を3にすれば、書き込み帯域は単純計算で3倍必要になります
- ストリーム処理でキー単位の再分配（シャッフル）が発生すると、ノード間をデータが横断します。この量が帯域を超えるとbackpressureが発生し、上流まで遡って処理が詰まります
- クラウド環境では、アベイラビリティゾーンをまたぐ通信にレイテンシとデータ転送コストの両方が乗ります。可用性のためにゾーン分散した結果、帯域コストが跳ね上がるという構図は頻繁に起こります
対策は、シリアライゼーション形式の選定（行指向のJSONではなく、スキーマを持つバイナリ形式でペイロードを圧縮する）、パーティションキー設計による不要なシャッフルの回避、そして前段での早期フィルタリング（明らかに不要なデータを、帯域を消費する前に落とす）です。
データの通り道全体で、どこが一番細いかを見る
収集エージェント、メッセージング、処理エンジン、シンクという一連の経路のうち、最も細い箇所が全体のスループットを決めます。処理エンジンのチューニングに時間をかけても、ボトルネックがメッセージング層のディスク書き込みにあるなら、成果は出ません。
この案件では、実装前の段階でスループット要件からデータ量を逆算し、各層に必要な帯域とI/O性能を見積もった上で構成を決めました。ここを詰めずに実装に入ると、負荷試験の段階でアーキテクチャそのものの作り直しが必要になります。
早期の集約が、下流すべてのコストを下げる
物理制約を踏まえると、最も効果が大きい打ち手は「そもそも下流に流すデータ量を減らす」ことです。
- 収集エージェントの段階でのフィルタリングと圧縮
- 業務上意味のない精度の座標（例：停車中の車両からの重複した位置情報）の間引き
- ウィンドウ単位での事前集約
上流で1割減らせば、メッセージング・処理・ストレージのすべてで1割分のコストと帯域が浮きます。この効果は下流にいくほど複利で効いてきます。
何が変わったか。
生データが、業務判断に使える情報になった
「位置座標の羅列」だった状態から、「どの車両がどの道路を走っているか」という業務で直接使える情報に変わりました。データの存在そのものではなく、そこから判断が下せることに価値があります。
コスト対効果で構成を選び、投資が過剰にならなかった
最先端・最高精度を追う構成ではなく、業務要件から逆算した構成を選びました。結果として、インフラコストと実装コストの両方を抑えながら、必要な業務価値を獲得しています。
運用が属人化しない形で残った
設計した仕組みを実際に回すのは現場です。属人化しやすい部分を抑え、運用側が持続的に扱える形に落とし込んだことで、構築後も継続して価値を出し続ける基盤になりました。
ひとつのデータから、複数の価値を引き出す構成になった
同じGPSデータが、車両の位置判定と人流の拡大推計という別々の用途に活かされています。データを一度集めれば、要件に応じた処理を後から追加できる構成そのものが、将来の拡張余地として残りました。
物理制約から逆算し、実装後の作り直しを回避した
ストレージI/Oとネットワーク帯域という物理的な上限を実装前に見積もったことで、負荷試験の段階でアーキテクチャを作り直すという、最もコストの大きい手戻りを避けられました。
技術は入れ替わっても、
順序は再現できる。
技術は数年単位で世代交代します。しかし「業務インパクトを先に定義し、そこから技術構成を逆算する」という順序そのものは、技術が入れ替わっても再現できる方法論です。
高性能な技術を選ぶことと、業務に効く構成をつくることは、必ずしも同じではありません。
ENGORGIOが提供しているのは、インパクトの精度と、実現のスピードです。どこに効くのかを見極める精度と、それを実際に動く形にするまでの速さ。この二つが揃ってはじめて、データは業務の成果に変わります。
まずは、将来への意思を共有してください。
最初の会話は、変革の起点を一緒に探す場。何を変えたいのか、何が変えられていないのか——そこから。