トラヒック集計で思う処理方式今昔
最近は、通信ソフトウェアでもデータベースを使うようになった。特に通信システムのユーザ情報を管理する機能や、通信されたトラヒック情報の履歴を収集／集計する機能ではデータベースによる管理が主流になってきている。
上記のようなデータベースを利用しているシステムの方式設計時に、興味深い話があった。リアルタイムでトラヒックを集計して出したいのだが、トラヒック収集情報自体が膨大なために、リアルタイムトラヒック集計処理がある時間内に完了しないかもしれないので、方式検討を実施する必要があるという内容だった。リアルタイムのトラヒック集計と言っても10分単位程度のトラヒック収集情報を1分程度で集計するもので、ただトラヒック情報自体は膨大でかつ種類も多い。データベース上にあるトラヒック収集情報を検索して、トラヒック集計することを検討しているが、データ量も多いので検索ロジックとかデータベースのチューニングでトラヒック集計が時間内に収まるようにしたいという考え方であった。
まあ、確かにデータベースがあるのだからその情報をうまく検索して、必要な情報を集計できればいいのだが、こういう処理を行うと一時的にCPU負荷がかかるし、他の処理との競合もあり、あまり好ましいものではない。
昔だと、そんなことしたらシステムダウンになりかねない問題なので、一気に行うトラヒック集計処理ではなく、トラヒック収集側の一つ一つの小さな処理の中にトラヒック集計が簡単になる仕掛けを入れておくようなことをやっていた。多少トラヒック収集自体は負荷がかかるものの、システム全体への影響をなくす配慮だった。
システムの基盤としてデータベースが用意され、高性能なCPUや余裕のあるメモリ量があると、簡単にソフトウェアが組めるのは事実であり良いことだが、ちょっとした処理方式の工夫で簡単に要求条件をクリアできることもある。最近の主流の実現方式で困ったとき、昔はどうやっていたか？を顧みてみると案外答えが見つかるかも知れない。
