社内システムの表示速度を6倍速にする

モウイでラタトゥイユの調理を試みる担当、イッペイです!こんばんは

突然ですが、
「Amazonでは各ページの表示速度を100ミリ秒改善したところ売上が2%変わった」とか、
「ページ読み込み時間が1秒遅いと、コンバージョン率は半分に減少する」
とか聞きますが、意外と表示速度の高速化って後回しになりませんか?

「そんな地味な改善より、新機能が付けたい」
「流行りのカタカナ文字を入れて派手に提案した方が分かりやすい」

みたいな。

前回の、そもそも自分が困っていることをシステム化で解決するでの話の延長上にあると思うのですが、表示がもたついている社内システムに高速化技術を導入して、自分達が快適さを実感して、心から高速化を人に勧められるようになれるのではないか?という試みです。


 

<今回対象の社内システム>

サンネットには、データを表示するのに14~15秒かかる社内システムがあります。
以下はGoogleデベロッパーツールで計測した時のキャプチャです。
a_system02

2007年から稼動し続ける、SEO関連の業務システムでありまして(仮に「Aシステム」としましょう)、検索エンジンでのキーワードの順位を日々記録し、順位に応じてお客様からの成果報酬を計算、月末には請求書発行までをまかなっております。
 
 

<Aシステムのやなところ>

Aシステム(笑)は、PHP4ベースのコードで開発されており、内部はフレームワークは無しのフルスクラッチ、
MVCなどなんぞ?というレベルのHTML、CSS、PHP、JavaScript、SQLのちゃんぽんで、テーブルレイアウトもどき、
メモ帳レベルのテキストエディタで開発が開始されたため、インデントはガタガタ、
ファイルの文字コードはShift_JISという天然記念物です。

さらに業務の変化に伴い、何度も改修を加えられ、人々を恐れさせ、困らせ、・・・そして、愛されてきました。

<Aシステムの凄いところ>

・・・はい。ここで前提として、私はこのAシステムをリスペクトしている。と、一言付け加えておきましょう。

「嫌なら作り直すか?」
とか、
「SEOの順位取得なんて凄いリーズナブルな価格でどっかの会社が売ってくれるよね?なんで買わないの??」
という場面に何度も直面し、その度に
「いいや、これはAシステムにしか出来ない!!」
と、廃止案を跳ね返してきたのです。

そもそも、お客さんの契約時期によって料金体系の契約内容が異なっているケースがあったりって、
他社さんのパッケージでカバーできないし、ましては帳票出力なんて難しすぎ。
(注:特定のお客さんが得をしているとか損をしているとかではなく、過去、大量受注の場合は案件に応じて料金体系を設計しなおしたりしていた。)

作り直すにはこれまでのSEO事業の歴史を知り尽くし、プログラミングが出来て、
通常業務をしながら片手間で・・・となると、かなり難易度は上がってきます。
 
 

<Aシステムの高速化のためにしたこと>

今回、高速化のために行ったことは、細かいチューニングが出来ない共用レンタルサーバから
全てroot権限でもってOSインストールから構築したVPSへコピーを行ったことです。
高速化前のサーバーと、高速化後のサーバーの主なスペック・構成を以下に記載します。

 
【高速化前】(共用レンタルサーバ)
CPU:Intel Xeon E312xx
メモリ:18GB
OS:FreeBSD 9.1
Webサーバ:Apache2.2
データベース:MySQL5.5(MyISAM)
実行言語:PHP5.3(CGIモード)
 
【高速化後】(VPS)
CPU:仮想3Core
メモリ:2GB
OS:CentOS7
Webサーバ:Apache2.4(gzip圧縮あり)
データベース:MySQL5.6(InnoDBバッファープール利用)
実行言語:PHP5.6(ZendOPcache利用)
 
高速化前のメモリ18GB・・・
むしろハードウェアのスペックは大幅にダウンしているとも言える状況。
しかし、Googleデベロッパーツールで以下のような数字を叩き出しました!
 
a_system01

2.4秒!約6倍速です。

サーバーのロードアベレージとか細かく計測したり、
どの設定が一番効果を発揮したのか調査しようと思いましたが、
ちょっと今回は時間がないのでまた次の機会
(多分、勘ではInnoDBバッファープール・・・)

<予想外の苦労>

ここからは泥臭い現実について。
予想外に苦労した点として、文字化けが挙げられます。
そのままコードとデータを写すと文字化けになりました。

Aシステムは現行サーバーで稼動する前にもサーバーの移行を一度しているのですが、
その時どうやってこれを切り抜けたのかが思い出せません・・・。

先にも述べましたがファイルの文字コードがshift-jisになっておりますので、
まず、一括文字コード変換ソフト「KanjiTranslator」を使って、ファイルの文字コードをutf-8に変更する荒業に出ました。
・・・正直、こんなソフトがあるんだと驚きましたし、こんな状況が発生することにもっと驚きました。

次に、HTMLのmetaタグの情報を一括置換します。

・変換前

<meta http-equiv="Content-Type" content="text/html;CHARSET=x-sjis">

・変換後

<meta http-equiv="Content-Type" content="text/html;CHARSET=utf-8">

ここまではどうにか・・・
しかし、まだ文字化けは収まりません。
何と、DBから取得した文字列の全てに個別で文字コードをutf-8からshift-jisに変換する内容が書かれていたのです!
ファイルの文字コードに合わせるためということでしょう。。。

そこで、「utf-8をutf-8に変換する」ことで「何もしない」という一括置換を行いました。

・変換前

cnv_enc($dat_list->ranking, "shift-jis", "utf-8");

・変換後

cnv_enc($dat_list->ranking, "utf-8", "utf-8");

 
このようにして、台風っぽくない土曜の昼が終わり、夜になりました。
後は夜間バッチで順位が取得されるのを待つのみ。
 
~就寝~
 
日曜日、朝、順位は取得されていませんでした。
先に、フレームワーク無しのフルスクラッチと述べましたが、
バッチ処理の内部にZendFramework1が使用されていたのです・・・。
(しかもサーバーのフルパスでパスを通して。定数でなくて直書き。しかも、これ、2年前に私がやりましたw)
日曜日、夜。高速化後のサーバーにZendFramework1を導入。
・・・まだ、バッチの稼動は月曜の朝まで分かりません。

高速化前のサーバーと平行運用で、同じ業務がこなせる挙動をするのか、見守りながら、
修正していきます。
 
 

<正直、面倒くさい。それでも体感して感動して、伝えていく>

今回の高速化はプログラムロジックや、SQLに大幅な変更をして実現しているものではないですので、
費用対効果は非常に高いと言えます。
しかし、同じことを社外に提案するとなると、中々気が進まないという部分があるかもしれません。
 
「これで万が一システム障害があったら、高速化のチューニングのせいだと思われないか?」
「こんな空気みたいに慣れてしまう改善、誰も覚えててくれないよ」
「それなら、もっと流行りのカタカナ用語や、大掛かりなシステム構成図でもって提案をした方が評価されるんじゃ・・・」
 
けど、導入したらコンバージョン率に良い変化が現れるかもしれないし、
一見変化が無くても、
そこをGoogleアナリティクスとかYahooアクセス解析、Piwik等のツールで
改善しているKPIを見つけ出して、粘り強くアピールして、改善を積み重ねていく。
 
そして、目指すのは、
急場しのぎで勉強して
「弊社のシステムは○○○で×××(←カタカナ用語)です。~円下さい」
ではなく、
普段から技術の恩恵を受けて心から便利さを体感していて、
 
「これ、凄いぜ!一緒に使おうぜ」
 
という勢いを持つこと。
 
口下手とか、論理的思考がどうとか、問題じゃないと思っていて、
本当に信じている人が勧める迫力って説得力を感じてしまうと思うのです。
 
もう一回言いましょう!
 
「これ、凄いぜ!一緒に使おうぜ」

   
サンネット株式会社
〒901-2101
TEL098-870-0670/FAX098-870-0671