先日のブログ記事で、「Delphi / C++Builder マイグレーションの新常識」というデベロッパーTVの番組を紹介したばかりですが、マイグレーションではもうひとつ注意すべき事柄があります。それは、アーキテクチャのアップデートです。
ここでいうアーキテクチャとは、アプリケーションを構成する「デスクトップ」「クライアントサーバー」「分散」などの構成のことです。PC向けのソフトウェア技術は、単独のPCで動作するモノシリックな構成からネット接続された分散型、さらにはマイクロサービスをキーとしたインテリジェントな接続によって構成される相互依存するシステムへと変化しています。
古いアプリケーションは、シンプルなクライアントサーバー型で構成されていたとしても、それを稼働させるPC環境や、連携を必要とするシステムが現在のアーキテクチャをベースとしていることに注意する必要があります。
BDEが推奨されないもうひとつの理由
「Delphi / C++Builder マイグレーションの新常識」では、BDEを「サポート終了」「サポートデータベースバージョンが古い」といった理由で非推奨としていますが、アーキテクチャ的観点から見ても、使うべきではないことは自明です。
BDEは、本来デスクトップデータベースをベースとした80年代のモノシリックなアーキテクチャをベースとしています。これに、SQLデータベースへのアクセスを追加する技術を追加し、RDBMSをあたかもデスクトップデータベースのように扱うことを可能にしているのです。
つまり、BDEは多数のクライアントからのリモートアクセス、大容量のデータといった現代のデータ利用では当たり前の要件に対して備えがありません。小規模な社内LANで、80～90年代に入手可能だったハードディスクに収まる程度の量のデータを扱うのが精一杯であると言えば分かりやすいでしょうか。
セキュリティ上のリスクを増大させる古いアーキテクチャ
BDEを例にとると、セキュリティ上のリスクについても理解しやすいでしょう。
セキュリティ上のリスクは日々高まっており、常に新しい脅威とその対応の繰り返しによって、リスク軽減を計っています。つまり、20年あまりメンテナンスされていない通信技術を使用しているBDEは、これらの脅威に対してまったく無防備であり、どのような損害を被るか予測もできないということです。
これは、インストールや設定／管理についても言えることで、WindowsVista以前までは、UAC（ユーザーアカウント制御）が導入されておらず、使用者と管理者の厳格な区別がありませんでした。
従って、BDEの管理は、ユーザーが実行可能であるという前提で作られています。これを回避するテクニックなどは、情報として存在していますが、それが「セキュリティ上の対策を無効にする」方向へと舵を切る行為である点に注意してください。
ユーザー企業に対し、「古いアプリケーションは最新のOSでも動作しますが、セキュリティ上のリスクを最大化することに同意いただきますよ」と説明することを想像してみてください。
アプリケーションのロジックに潜む古いアーキテクチャ
BDEをFireDACなどの最新技術に置き換えたとしても、アプリケーションコードに古いアーキテクチャが存在しているケースも見受けられます。
よくあるのが、クライアント側で実行するバッチ処理的なコードです。
クライアントからデータを単純に一括投入する場合はあまり問題になりませんが、サーバーに格納されているデータを参照して、投入方法を決定するようなコードを記述している場合、デスクトップデータベースのアーキテクチャをそのまま温存させているケースが見られます。
以下のようなシナリオです。
- 投入すべきデータが用意される
- サーバーに問い合わせを行いこのデータのステータスを確認する
- ステータスに応じてデータを加工して投入する（あるいは投入しない）
この一連の操作をクライアント側で実行した場合、少なくとも2回のクエリーが発行されます。1件のデータを投入する場合は問題ないでしょう。100件のデータでも、目に見えて問題になるようなことはないかもしれません。しかし、10万件ではどうでしょう。
マイグレーションプロジェクトでは、機械的に既存コードを最新バージョンで「動作する」ように変換する「作業」を行いがちです。しかし、このようなコードが、今日のデータサイズに対応できるかという吟味は絶対に避けて通るべきではありません。
