データベース化されていないサービスを便利にシステム化したい時のエンジニアならではの気付き

某日、10年以上運用してきている、とあるWebサービスを、いい加減システム化したいというオーダーをウチの会社に相談されました。 この手の相談は大小問わず、月に何回かあります。 弊社にそうした相談を言ってくる人は、大体他の会社でシステム化を断られたという経緯がある場合が多く、要するに難易度MAXの場合が多いというワケです。 相談者の人たちは、ITが詳しくないため、システム化する時に何が難しくて、どの点が無理ゲーなのかを理解せずに、自分のやりたいことだけをひたすら説明されるので、 まずは、無理ゲー確認をするところから始めます。 今回相談されたWebサービスのシステム化もその時に色々と調査をさせてもらった内容を、ITが苦手な人でもできるだけわかりやすく書いてみたいと思います。

システム化できていないローテク部分

そのWebサービスというのは、特定の原稿を表示するサービスで、それを見に来るお客さんがお金を出してまで見る価値のあるコンテンツ・サービスです。 毎日たくさんのユーザーに原稿を見てもらうことで、非常に大きな収益をあげているので、サービス運営の効率化をしたくてシステム化を行いたいのだそうです。 一体何をシステム化したいのかというと、その原稿が全てテキストファイルでサーバー（Linuxです）に格納されているため、現場の運用担当者がFTPでアクセスして、 ファイルを直接書き換えたり、以前に登録したファイルを探したりする作業でかなりの時間を有しているのだそうです。 「そのファイルは全部でどのくらいの数あるんですか？」 と聞いてみたところ、 「たくさんあるけど、数は数えたことがありません。」 とのこと・・・ ここから骨の折れる調査になることはなんとなく理解していました。 とにかく、この原稿を管理するシステムが作れれば良いんだな！と・・・

テキストはデータベースにすべし

テキストだけの原稿なのですが、データベースなどには格納されておらず、ファイルでそのままサーバーに置かれているので、 ひとまずLinuxコマンドでファイル数を調べてみました。 find (原稿置き場のパス) -name *.txt 返ってきた結果が・・・ 100万以上の値・・・orz なんかすごい！ 毎日数十個以上のファイルを更新しつづけているのだそうです。 そりゃあ、管理も大変だし、探すのも一苦労だわな〜。 そして、原稿の中身を検索するのにgrepコマンドを使ってみましたが、サーバーからのレスポンスが、数十秒程度かかったので、適度に整理してデータベースに格納する必要があると思いました。

テキスト管理のクセが強い！

実際のテキストの中のデータは、このブログではお見せできないんですが、次のような構成になっていました。 ###### # No : 1 # 記入者 : AAA # 備考 : hoge-hoge-hoge ##### A 本文・・・ B 本文・・・ C 本文・・・ テキスト上部がヘッダ部分で、下部が原稿の本文という構成でした。 まずは、このヘッダ部分をkey-valueに分解してデータベースに格納するマスターデータにしてしまえばいいかと考えてみました。

データベース格納自体はさほど難しくない

ということで、100万ファイル以上あるテキストデータを1ファイルずつ読み込んで、ヘッダ部分を分解して、データベースに格納してみると・・・ 「あれ？なんか想定外に、ヘッダのkeyの数が多いぞ・・・」 と思い、データベース内を調べてみると・・・ Noというkey値を取得するところが、 no、NO、O、No.1・・・（もっとたくさん） ・・・全然統一されていないやんけ・・・ という事に気が付きました。 大文字小文字であればいいんですが、全角でＮＯと書かれていたり、№（絵文字）で書かれていたり、もはやカオス状態でした。 ちなみに、Oは、Nが抜けている記入ミスでしょうね。 要するにこのヘッダ部分は全然フォーマットがルール化されていなかったという事実を確信しました。 まあ、手作業でのテキストファイルなんで、この辺は想定内ですね。

衝撃の事実

でも不思議に思うのは、このヘッダ部分を使って現状のシステムはある程度の情報を取得して、本番サービスで表示をしているんじゃないのか？という疑問が浮かびました。 すると、現状のシステム管理をしている技術者(サーバー管理者)から、そのヘッダ情報は、テキストを作成する人が参照するだけのもので、サービス内では一切使っていないのだそうです。 ここまでくると、この仕組みで運用している効率の悪さがまるわかりですよね。 他の会社ではエクセルとかで管理してそうなものを、テキストファイルに直接書き込んで、統一性のない状態で延々運用され続けていたという、駄目システムだったわけです。 こんなローテク、時間がかかって当たり前ですよね。 このテキストのヘッダ部分のルールを定義してあげるところから始めないといけないね。

乗りかかった船は、沈没させない主義なので

まだまだヘッダ部分だけですが、原稿の本文部分も恐らく何かしらの不具合や、裏技系ルールなどがたくさんあることが想像できますが、まだそこまで調査ができていません。 でも、この辺のシステム化が整うと、運用作業をしている人達（いっぱいいるようです）のしごと効率がよくなり、残業などの時間が減る事は明確です。 ある意味人助けだと思って、その会社のお手伝いをさせてもらっています。 今回ブログで言いたかった事は、システム化する前に、ルールを作る（明確にしておく）という事は非常に重要だという事です。 この会社の担当者の方どなたに聞いても、一昔前から運用しているので、当初からいるメンバーはほぼ会社辞めてしまっていて、自分は知る由もないという返答が常に返ってくるため、 明確なルールは知らぬ存ぜぬの一辺倒でした。 まるで、自分が使っているシステムを他人行儀のモノのような言い方で、もっと自分事として取り組んでもらいたいという事も頭の中に過ぎったんですよね。 でも、個人的にはそうした駄目システムを、便利なシステムに変貌させるのはエンジニアの腕の見せ所というワクワク感が強いので、おもしろそう感が勝っています。

あとがき

自分たちが使っているシステムが駄目システムでも、ちゃんとルールを作って、思考して、管理できるシステムに変えてあげたら、もう少しシステムのことが好きになるんじゃないかな〜と思うので、その感覚を含めて面倒を見てあげようと思っています。 ※でも先は長そうなので、相手のコストがそこまで潤沢に保てるかどうかも少し不安なんですが・・・