システム開発を依頼するときは、おおよそのデータ件数を提示してください

2019年5月19日日曜日

システム開発

t f B! P L

業務システムでも小さなツール開発でも、社内開発でも外注開発でも、システム開発を情技師(ITエンジニア)に依頼するときは、おおよそのデータ件数を予め調べて、情技師に伝えてください。
データ件数によりITシステムの作り方が全く違うのです。

(以下、敬語を略)

データ件数とは、例えば「顧客数」とか「支店数」とか「製品数」「商品数」「SKU数」「部品数」などITシステムで扱わなければならない要素の数だ。

この「要素の数」を、「全ての要素の分」だけ用意して欲しい。
漏れがあってはいけない。

これは依頼者(あるいは業務担当者)の仕事だ。

なぜ、データ件数が必要なのかと言えば、データ件数によってITシステムの作り方がまったく違うからだ。

簡単なITシステムの仕組み解説 !

クライアント・サーバー(C/S)

以下の図のように、人が操作するPCと、APサーバーとDBMS(database management system)を運用するDBサーバーの3階層で構成される。
PCにクライアント・アプリケーションを、APサーバーにサーバー・アプリケーションを運用し、DBサーバーにデータを格納する。


APサーバーは通常は1台だが、インターネットで広く使われるものは、何十何百何千台というAPサーバーを負荷分散して併用する。

DBサーバーも論理的には1台だが、インターネットで広く使われるものは、物理的には分散情報処理されている。

スマホのアプリなどもクライアント・サーバーだ。
クライアント・ソフトウェアがアプリに相当する。
業務用システムの場合は、社内の配布サーバーがクライアント・ソフトウェアをPCに配布する。

一般のアプリの場合はApple,Google,Microsoft などのストアが配布サーバーを担当している。

WEBアプリケーション


基本的な構造はクライアント・サーバーと同じだが、クライアントをブラウザ上で稼働させる点が異なる。
大半の情報処理をAPサーバー側で行い、サイトをブラウザで開いたとき、必要最小減のプログラムがダウンロードされ実行されるため、クライアント・ソフトウェアを配布する必要がない。
また、ブラウザだけ存在すれば動くので端末やOSを選ばないメリットがある。

クライアント・サーバーの場合は、Windows,Mac,iOS,Android などOSに合わせてクライアントを開発しなければならない。

メモリとストレージ

コンピュータでは記憶装置は「速度が速く小容量(高価)」なものと「速度が遅く大容量(安価)」との間で階層構造を形成して、コンピュータという仕組みを構成している。

もっとも早いのはCPUの中の記憶装置であり、その次が半導体メモリ、次がストレージ(SSD,HDD)となる。
階層構造は以下のようになる。


3層
CPUキャッシュメモリ
数MB
2層
メインメモリ
数GBから数百GB
1層
ストレージ
16GBから数TB

速度の必要な情報処理は高層にデータを読み込んで高速に行い、一時的に必要の無くなったデータは低層に保存される。

つまり低速な記憶装置の読み書き回数を最小減にして、コンピューターを高速に稼働させる仕組みになっている。
この仕組みはスマホ・PC・(AP・DB)サーバー機全てで同じである。

システム間連携

昨今のシステムは他のシステムと横の連携をとることが多い。
その時、データをシステムからシステムへ受け渡す、システム間データ連携を行う。

このシステム間データ連携にはデータ量や更新頻度によっていくつか種類がある。



連携手法
データ量
距離
連携頻度
(1)
サービス連携(APIを含む)
数百MB以下
遠距離可能
何時でも
頻繁に可能
(2)
他DB直接書き込み
数万件程度
近距離のみ
頻繁に可能
(3)
ファイル共有
大容量可能
近距離のみ
頻繁に可能
(4)
ファイル転送
数GB程度まで
通常は社内LANのみ
通常は夜間のみ連携
(5)
データ・レプリケーション
大容量可能
製品しだいだが、社内LANのみ
随時連携可能

(1)サービス連携(APIを含む)

「サービス」という言葉も色々な使われ方をしていて非常に分かりにくく誤解を招きやすい状態にある。
サービスには私が知る限り以下の物がある。

・物以外の価値を提供するビジネス
・マイクロサービス(他のソフトウェアがその機能を利用できる独立したソフトウェア)
・Windowsの常駐プログラム(UNIXのデーモンと同じ)
・WEBサービス(クライアントが使うサーバー側の機能のこと)

ここで言う「サービス」とは「WEBサービス」になる。
サービスはC/Sシステムのサーバー側の機能の一部である。
クライアントがAPサーバーの機能を使用するときにWEBサービスを呼び出す。

この機能を他システムのAPサーバーが呼び出すこともできる。

WEBサービスはTCP上のHTTPやSSLで通信し、高位プロトコル(通信規約)としてはSOAPとRESTが使用される。
SOAPの場合はデータはXML(Extensible Markup Language)で受け渡され、
RESTの場合は JSON(JavaScript Object Notation)で受け渡す。
XMLと JSONはどちらもテキストファイルだ。

WEBサービスを外部公開したものを Web API(Application Programming Interface)と呼ぶ。
通常はRESTが使用される。

このWEBサービスによりシステムが稼働していれば通信できる相手ならいつでもどこにでもデータを送受信できる。
インターネットを経由して社外へ接続することもできる。
(セキュリティコストがかかるが)
速度も速い。

しかし一度に遅れる情報量が少ない。
一度に数百MBで程度しか遅れない。
工夫すればもっと大きなデータを遅れるが正攻法ではなくなる。

小さなデータを送受信するならWEBサービスが良い。

(2)他DB直接書き込み

WEBサービスはAPサーバーとAPサーバーが連携する方法だが、この「他DB直接書き込み」はDBサーバーとDBサーバーが直接連携する。
甲システムのDBサーバーが、乙システムのDBサーバーへ接続し、甲データを直接乙DBのテーブルに書き込んでしまう方法だ。

手軽に大量のデータを遅れる。
速度も速い。

社内LANで安全が保障されているネットワークでしかできない。
社外にはこの方法では接続出来ない。
社内でも部署によって制限される。

(3)ファイル共有

システムと別にファイルサーバーを用意して、複数のシステムから接続できるようにしておき、通信目的ごとにフォルダーを分け、システムからシステムへファイルを受け渡す。

簡単であり、大容量データを受け渡せる。

そのかわりセキュリティが弱く、安全な社内LAN内でしか使用できない。

(4)ファイル転送

ファイル転送専用のソフトウェアを使用し、さまざまな通信回線を経由して、ファイルを転送する。

企業の業務システムならHULFT(ハルフト)がデファクトスタンダードだ。

大きなファイルも転送できる。
Windows,UNIX,メインフレームなど規格の異なるOS間でも通信できる。
インターネットを介して社外と通信することもできる。
セキュリティも設置方法が正しければ問題ない。

高価で、使いこなすにはある程度スキルが必要なのが欠点。

(5)データ・レプリケーション

これはレプリケーション専用ソフトを使用し、複数のDBサーバーの一部のテーブルの中身が常に同じになるように保障する技術である。
複数DBの対象テーブルのデータが更新されたら、他のDBの対象テーブルにもその更新を反映する。
複数のDB間で共有テーブルを使用する技術である。

双方向にデータ共有する方法と、一方向にだけデータを送る方法がある。

製品に特にデファクトスタンダードは存在しない。

Double-Take

Arcserve Replication

DBMoto

DataSpider Servista (多機能データ連携ソフト)

価格帯は比較的高い。
100万から10万円といったところだ。

システム間データ連携の選択基準

複数のシステム間データ連携の中からどの手法を使うかは以下の基準で選ぶ。

(1)データサイズ(データ件数)
(2)システム間の論理的距離(社内LAN内か、外部との連携か、セキュリティの壁の厚さ)
(3)連携頻度・タイミング(即時・1時間以内・1日一度夜間に連携、など)
(4)通信速度
(5)予算

これは基本設計に入る前の要件定義の段階で全て明らかになっていなければならない。


データ件数によってシステムの作り方が違う

例えば「顧客数」とか「支店数」とか「製品数」「商品数」「SKU数」「部品数」など各項目の個数は、システムで扱うデータ件数に反映する。

例えば画面に顧客一覧を表示する場合、100人から500人程度であれば一つのスクロール画面で一括表示すれば良い。
しかし1万人の顧客情報を表示するとなると、スクロール画面で一括表示では使い物にならない。
検索条件を絞って、一部を一覧表示するか、ExcelなどにエクスポートしてExcelのフィルターで絞りながら閲覧するとか、20人ごとに改ページ表示するなど一工夫必要になる。

データ編集もやり方が変わる。
例えば製造業で仕入れた部品の価格と個数から、部品ごとの費用を算出してデータに書き込むとする。


部品名
価格
仕入れ個数
費用
ネジA001
90円
15000
1,350,000円
バネH202
110円
8200
902,000円

この部品数が3000個ぐらいなら、ストレージからメインメモリに全部読み込んで、メモリの中で計算し更新して、一括でストレージに書き込んだ方が良い。
(この場合のストレージはDBと考えてください)

部品数が100万個ぐらいになると、メモリには読み込めない。
(8GBなら入るじゃないか! などと野暮な突っ込みは禁止します)
(現実の業務ではもっと大きく複雑なデータを扱います)

この場合は一件ずつ、メモリに読み込み計算してストレージに書き込む、ということをする。

現代ではDBMS(Oracle,SQL Server, MySQLなど)のストアドプロシージャでこの処理を行う。
DBサーバーの中だけで処理し、いちいちAPサーバーに読み込んで計算したりしない。
DBMSの中でメモリキッシュを行うので実際は数千件ずつデータを読み込み、計算更新する。
プログラム上は一件ずつ処理するように書く。

他システムと連携する時は、3000個ぐらいなら、Web API(WEBサービス)でどことでも連携できる。

100万個だとWeb APIでは送れないので、

(1)データサイズ(データ件数)
(2)システム間の論理的距離(社内LAN内か、外部との連携か、セキュリティの壁の厚さ)
(3)連携頻度・タイミング(即時・1時間以内・1日一度夜間に連携、など)
(4)通信速度
(5)予算

の条件に合わせて、他の連携手段を選択する。

データ件数はレスポンスにも影響する


データ件数は作り方が変わるだけではなく、システムのレスポンスにも影響する。
ユーザーが「画面から検索して3秒以内に結果が返ってくる機能が欲しい」と要求してきたとき、データ件数が多すぎると実現できない場合もある。

この場合は、「最初に検索条件を複数登録しておくと、1時間後には集計した結果が、複数何度でも閲覧できるようにする」などの対策が取られる。

少ないデータ件数なら、夜間バッチで集計できるが、大量のデータなら、別にバッチ処理専用DBサーバーを立てて、並列運用しなければならない。
(トランザクション処理用DBと集計用DBを分けるなど、互いの連携も必要)

システムの構成も変わってくる。

システム開発を依頼する前にデータ件数を提示してください


以上、説明してきたようにシステム開発を依頼するなら、「顧客数」とか「支店数」とか「製品数」「商品数」「SKU数」「部品数」など各項目の個数は、正確でなくても良いので、だいたい何個かを調べておいてください。

要件定義が楽になります。

お互いに。

このブログを検索

Translate

人気の投稿

自己紹介

自分の写真
オッサンです。実務経験は Windows環境にて C#,VB.NET ,SQL Server T-SQL,Oracle PL/SQL,PostgreSQL,MariaDB。昔はDelphi,C,C++ など。 趣味はUbuntu,PHP,PostgreSQL,MariaDBかな ?基本無料のやつ。

QooQ