月: 2016年3月

iPhone5で、QRコードをまとめて読み取るデモを作りました。
iOS標準装備のバーコード読み取りAPIを使ったのですが、とてもサクサク動くので感動しました。

少し前の話になりますが、2016年2月16日に、「空飛ぶ電波タワーとしての小型無人機活用の取組みとUWBを用いた高精度屋内測位技術の開発」という、電子情報通信学会主催の一般講演会に参加してきました。発表者は、NICT ワイヤレスネットワーク研究所の三浦 龍 室長でした。

大規模災害時に、地上の基地局が被災して情報孤立してしまった被災地へ、小型無人機（ドローンみたいな無人飛行機）を飛ばして電波タワー代わりにすれば、素早く通信を復旧できるのでは？というのが研究テーマです。

実証実験で使用された小型無線機はPUMA-AEで、元々アメリカの軍用だったものが、商用利用可能になったのだそうです。（購入しようとすると数千万するらしいです。気軽には買えないですね（笑））

このPUMA-AEに、専用の無線モジュールを搭載して、電波タワー代わりにします。実証実験では、１０Km程度の圏内まで通信できたそうです。

実証実験をするにあたっては、電波を遠くまで飛ばす必要がある為、総務省から、許可が必要な通信帯域を割り当てて貰ったそうです。電波法に準拠する為にこのような手続きが必要になるそうで、提出書類が多く、時間もかかるので大変だと言っていました。

私を含めほとんどの一般市民は、市場に広く出回っている携帯、Wi-Fiルータ、BlueToothデバイスなどの通信機器しか使ったことがないので、電波法を意識する機会はまずありません。

携帯が使用している帯域は各キャリアが総務省から免許をもらっているし、Wi-Fi、BlueToothはそもそもISMバンドと呼ばれる免許不要な帯域を使っています。

私は、今回の講演会で、これらの通信機器以外を使った無線ソリューションが研究されている事を初めて知りました。加えて、それを実現しようとすると、電波法という壁があるのだということも初めて知りました。

とても面白く、タメになる講演会でした。

前回の続きです。

前回は、業務システムの検索画面が遅い理由を３つ挙げました。今回は、これらの対策を、業務システムの全体設計を担うアーキテクトの立場から考えてみます。

最小限の手戻りで、テーブル設計を見直したい

検索画面の遅さは、テーブル設計を見直すことで解決できます。とはいえ、前回も触れましたが、開発終盤に手戻りの大きい見直しをかけるのは現実的ではありません。なんとか最小限の手戻りで、テーブル設計を見直すことができないものでしょうか？

非正規化テーブルを追加する

こういう場合、大抵は「非正規化テーブルを追加する」ことになります。非正規化テーブルとは、他テーブルが保持しているデータを、性能上のメリットが得られる形（予め集計しておく等）に変換した上で、重複して保持するテーブルのことです。非正規化テーブルの追加であれば、既存テーブルの設計には一切手を入れる必要がなく、性能アップしたい機能のみをテコ入れできます。

例えば、検索時にオプティマイザが使うインデックスを間違えてしまうのは、１つのテーブルに多くのインデックスが割り当てられていることが原因です。この場合、検索に特化した非正規化テーブルを追加することで、インデックスを分散させる事ができます。

同期処理がネック

この手法を導入する際に避けて通れないのが、重複データの「同期処理」です。同じデータを複数テーブルに重複して保持している為、データ更新時には、それらのテーブルを同時に更新しなければならないのです。

この同期処理は、業務システムの更新機能に組み込む必要がある為、手戻りが発生します。この手戻りをどこまで限定的にできるかが、「非正規化テーブルを追加する」案の良し悪しを決めると言っても良いでしょう。

更新処理をAPI化すべし

私は、この同期処理による手戻りを限定的にする為に、「更新処理を始めからAPI化しておく」ことが必要と考えています。

大半の業務システムは、テーブルそのものが、画面間を繋ぐAPIと位置付けられてています。そして、テーブルを読み書きするデータアクセスは、各画面が個別にSQLを設計しています。

このような構造だと、今回のような同期処理が必要となった時に、各画面の手戻りが必ず発生してしまいます。更新処理をAPI化しておけば、同期処理はそのAPIの中で吸収できる為、各画面まで手戻りが及ぶことはありません。加えて、業務寄りのロジックとシステム寄りのロジックを綺麗に分離できる為、コードの見通しも良くなり、保守しやすくなります。

加えて、RDBを使っている大抵の業務システムは、更新処理が単純です。（逆に、参照処理は複雑なことが多い）単純なので、更新処理をAPI化する開発コストも、さして大きくありません。

おわりに

私は、アーキテクトとして、今までに大小様々なシステムの全体設計に携わってきました。その都度、ああすれば良かったとか、凝り過ぎたなぁとかいろいろ反省させられます。

今回は、そんな試行錯誤の中で見つけた解決策について、書かせて頂きました。

社内で業務システムを日常的に使う方であれば、検索画面のレスポンスの遅さにイライラした経験があるのではないでしょうか？

実際のところ、遅いレスポンスでよしと考える開発者はいません。頑張ってチューニングしたくてもできないから、そのような状況に陥ってしまうのです。

業務システムの仕組み

大抵の業務システムは、リレーショナルデータベース（RDB）と呼ばれるミドルウェアを使って、データを管理しています。業務データはすべてそこに格納されており、日々バックアップされています。RDBのイメージが湧かないのであれば、「システムが使うExcelブック」と考えていただければ良いかと思います。

どのRDBにも、「インデックス」と呼ばれる機能があります。これは、特定の列を常にソートされた状態に保っておく機能です。ソートされていると、検索が素早くできます。国語辞典が、５０音順に並んでいるのと同じ理屈です。

このインデックスは、１つのテーブル（Excelで例えるとシート）に複数貼ることができます。例えば、「５０音順」の国語辞典と、「品詞順（名詞・動詞など）」の国語辞典の２種類を持っていれば、２つのインデックスがある状態と言えます。この場合、業務システムの検索画面は、入力された検索条件に応じて、どちらの国語辞典を使うべきか選択する必要があります。

RDBの場合、この選ぶ作業は「オプティマイザ」と呼ばれるRDBの内部機能が担っています。利用者の検索パターンに合わせて、予めインデックスを用意しておくのは開発者の仕事ですが、使うべきインデックスを選択するのはオプティマイザの仕事です。オプティマイザは、利用者が入力した検索条件に基づいて、自動的に適切なインデックスを選択します。

前置きが長くなりましたが、ここまでの仕組みが分かっていれば、業務アプリの検索画面が遅い理由を理解できるようになります。

検索画面が遅い３つの理由

大別すると、遅い理由は３つあります。

1.使うインデックスを間違える

インデックスが多すぎて、オプティマイザが選択を誤ってしまうケースです。開発者としては、その検索で使うインデックスはこっちでしょ！と言いたくなる状態です。
更に悪いことに、オプティマイザはなまじ賢いので、インデックス選択の判断材料として、入力された検索条件の他に、格納データの内訳（統計）も使っています。その結果、同じ検索条件を入力しているのに、昨日と今日で使うインデックスが違うという事が起こります。利用者からすると、昨日までレスポンス早かったのに、今日いきなり遅くなった、と感じるわけです。

2.使えるインデックスがない

これは、文字列の部分一致検索をしようとするとよく起きます。普通のインデックスは、前方一致検索にしか対応していません。部分一致検索する為には、フルテキストインデックス（転置インデックス）と呼ばれる特殊なインデックスが必要になるのですが、普通のインデックスよりも運用が大変なので、採用しないケースも多いのです。

3.インデックスはあるけど役に立たない

国語辞典で例えるなら、「あ」から始まる単語が99%で、それ以外が1％といった状態です。データがある程度均等にばらけていないと、インデックスを使っても早い検索はできません。オプティマイザは、使えないと判断したインデックスは、あっても使いません。

解決策は？

根本的に解決しようとするなら、テーブル設計を見直すことが一番です。
ただ残念なことに、このような性能問題は開発終盤に発覚することが殆どなので、そこまで遡って見直しする時間が残されていないケースが殆どなのです。（家を建てることに例えるなら、完成間近に間取りを変えるようなものです）

じゃあ、開発者としてこの問題にどう立ち向かうべきなのか？長年の経験の中で、私が思い描いている解決案がありますので、次回のブログで公開したいと思います。