C21 Magazine

コマース21のエンジニアが大事にしていること Vol.3 ~効果=価値としての性能対策 前編~

【掲載日】2019.05.13

品質管理グループに効果=価値としての性能対策についてお話を聞きました。​​
品質管理グループのメンバーが性能を気にするようになったきっかけ、性能試験や脆弱性試験の
大切さ、チームの取り組みについて、前編・後編の2回に分けてお伝えします。



写真左から:品質管理グループ 両角健、三橋敬、製品技術部 村松史朗


村松 : TCQCが出来た経緯についてお話いただけますか?

三橋 : もともとテストの重要度という観点で言えば、性能試験は機能試験と同じくらい重要
なものなんです。性能不具合による損失は大抵の場合大きく、そして収束まで長引くからです。
にもかかわらず、小規模の開発でも必ず行われる機能試験と比べて、どうしても回避されがちで
す。というのも、性能試験はサーバースペックをそろえたり、大量データを準備したり、と環境
を整備するところから始めなければなりません。そして性能不具合を再現させるための負荷の与
え方にも工夫が必要だったりします。性能試験は機能試験に比べて様々なコストが掛かるんです
。そういうこともあって、プロジェクト単位で性能試験を経験する機会は少なく知見が蓄積しに
くいので、なかなか精度も上がらない。そこで、性能試験だけを取り出して専門的にやれば、同
一メンバーが経験する機会が増えるので精度も上がりやすく、効率も良くなって結果的にコスト
も抑えられるだろうというところから、じゃあ組織を別にしてやりましょうというのが始まりで
した。同様の理由で現在では脆弱性試験も担当しています。

村松 : TCQCではAPM(Application Performance Management)ツールとしてDynatraceを
活用されていますが、Dynatraceを活用する前は品質管理についてどう取り組んでいましたか?

三橋 : 例えばSQLが遅い場合などはエディタとかを使って基本的には手で直していました。
SQLとにらめっこしながら「ここはこう組み変えたら速くなるんじゃないか?」とか、実行計画
を取ってみては「なんか変わんないな、じゃあ、もう1回」みたいな。それでも開発環境だと
データが軽すぎて間違いにも気づけずに完全に見落とすようなこともありましたね。



村松 : SQLの質を気にすることになったきっかけって、いろいろあると思うんですよね。
例えば、お客様から今回リリースした機能が遅いということで指摘があったとか、サイトを止
めてしまった、もしくは他のチームが止めてしまったのを見て自分のチームは止めないように
しようとか。SQLの質を気にするきっかけは何だったんですか?

三橋 : エンジニアになったかなり初期の頃、最初にプログラムを作った時に「機能が同じ
であるならばより良い性能を目指して作りなさい」と教えられたことがありまして、その言葉
が今でも僕の中で一番響いていて、いわば原点といっても過言ではないかもしれません。
SQLが遅いというのもそうなんですけど、例えばプログラムひとつにとっても結果が同じならば
なるべく少ない経路で、ソースは少なく、行ったり来たりしないようにとか、そういうところ
を常に考えながら作ってきたので、自然と性能を気にしながら書くという流れが身に付いた感
じですね。

両角 : 僕の場合は前職のエンジニアの時も性能試験や脆弱性試験はやってはいたんですが、
その時はDynatraceとかはもちろんなくて、かろうじてJMeterで負荷をかけて試してみようと
いう感じでした。でも原因追究は人海戦術のトライアンドエラーでやっておこうというところ
だったので何か良い方法はないかなとずっと思ってましたが、特に前職の時には革命的なこと
はなくて。それからコマース21に入って、前職ではインターネット向けの開発ではなかったの
で気にならなかったのですが、コマース21はECサイトを作っているので、これはひとつ問題が
起きれば立て続けに問題が起きてしまうんではないか?という認識が強くなっていた時に
Dynatraceを知り興味を持ちました。あとは自前でSQLについての本も買ったりして、いわゆる
「べからず集」なんですが、そこからどんどん性能についても考えて開発するようになりまし
たね。



三橋 : さっき性能を気にする習慣が身について、ずっとやってきたという話はしたんです
けど、長らくこの会社に入ってDynatraceに出会うまで性能改善が自己満足の域をなかなか出ま
せんでした。例えばバッチプログラムだったら実行してから終わるまでの時間を計ってみたり、
検索のSQLだったらたたいて返ってくるまでの時間を見たりとか、手で確かめて体感で効果があ
るものは良いんですが、それこそちょっと直してミリ秒の世界で良くなるものは正直なところ
手ではわかりません。普段100ミリ秒しか掛からない処理が実は負荷が集中した時にボトルネッ
クになってシステムを落とす原因になりうるという話を、100ミリ秒を10ミリ秒にできたら危険
回避できますというのは体感だけでは説明できません。見えないものを体感だけで説明するの
であれば、実態も伴わないので自己満足や趣味の範囲と言われてしまうかもしれませんが、
Dynatraceを使うことで可視化して説明ができるようになり、自分がやってきたことが役に立つ
仕事であるという認識が出来上がる瞬間でもあったんです。そこから一気に性能改善というも
のに対する意識が上がっていったかなと思います。Dynatraceはそういうきっかけを作ってくれ
たツールではあります。

村松 : Dynatraceの導入効果ですね。

両角 : 導入効果という点ではTCQCの場合、システム全体を串刺しして遅いところ、悪いと
ころを見つけないといけないので、説明する時にDynatraceを使うことで「ここはこういう原因
だから遅くなっている」という指摘も可視化できるので貢献している、効果を生んでいると思
います。

~後編に続く~
 

一覧

お問い合わせ・資料請求・お見積り依頼

お気軽にお問い合わせください。

03-3470-4702

受付時間 平日10:00~19:00

メールフォームからのお問い合わせ

お問い合わせ・資料請求