PROFILE
前田 啓佑
大阪第二開発部 楽楽販売開発1課
大学卒業後、BtoB / BtoC / 公共案件、スマートフォンアプリの開発〜サーバサイドまで一通りの構築・運用・保守を経験後、2021年ラクス入社。これまでの幅広い開発経験を活かし、入社後は楽楽販売（働くDB）のバックエンドを中心に開発チームのリーダーを務めています。
まず、前田さんの担当されているプロダクトをご紹介いただけますでしょうか。
楽楽販売（旧名：働くDB）は現在延べ3500社以上に導入いただいている、急成長中のクラウド型業務システム構築ツールです。名前だけ聞くと、「販売管理をするためのシステム」と思われがちですが、それ以外にも幅広い用途でご利用頂いている汎用データベースシステムと言えます。ユーザがブラウザ上で設定変更を行う事で一覧画面をいくつも作ったり、定期的な自動処理の実行を定義したりする事が出来ます。
エンジニア目線でわかりやすく言うなら、ユーザが行った設定に応じてリレーショナルデータベース上に動的に「Tableの作成 / Fieldの作成 / INDEXの追加」等が行われるシステムです。
また、開発が始まって15年以上も経っている歴史の長いシステムというのも特徴の１つと言えます。
今回は楽楽販売のパフォーマンス改善をどのようなアプローチで進めたかを伺いたいと思います。そもそも、今回の改善はどのようなことを目的としていたのでしょうか？
改善の目的の１つは「一覧画面の15%の速度改善」になります。
こう言うと、話は至ってシンプルに思われるのですが、楽楽販売ではユーザの設定次第で一覧画面の数はかなり多くなります。実際、検証環境として準備した環境は社内の実データを暗号化して準備しましたが、1300種類以上の一覧画面がありました。
そして、2つ目の目的は「一覧画面の中でもユーザが一番パフォーマンス劣化を感じやすいレスポンスタイムが１秒〜３秒程度を対象に15%の速度改善」をする事になります。
この目的を掲げた理由としては、パフォーマンス改善の手法によって改善される画面に偏りが出るからです。例えば、前者の目的だけを掲げた場合、0.3秒以下でレスポンスされる画面が軒並み0.1秒で返るようになったとしてもUXとしては大きな変化はないし、30秒以上かかっている特殊ケースの画面だけ爆速で改善したからといって、90%以上のユーザにとってはUXは全く向上しません。
そういった考えからこの２つの目標値を掲げる事としました。
今回の改善に至る背景を教えてください。
仮想化した際に発生するパフォーマンス劣化の懸念を払拭する事が目的でした。
楽楽販売は急成長する一方で、物理サーバーベースで複雑な構成をしているため、このままでは運用が回らなくなるという課題を抱えていました。
そのため、仮想化する事で解決したいと考えましたが、仮想化するとなるとハードウエア・リソースを複数のOS環境が共有するため、どうしても性能劣化が発生する懸念というのがついてきます。
当然、性能劣化すればUXが下がり、サービスの利便性が低下してしまうので、なんとかUXを低下させずに仮想化出来ないかという話になり、スケールアップには頼らずにこの懸念を払拭できるぐらいにパフォーマンス改善出来る見込みがないのかを検証しようという話になりました。
この改善に関わったチームの体制と、前田さんの役割を教えてください。
細かい所では他の開発メンバーにも協力頂く事はありましたが、基本的には全て私が実施し、課長にレビュー頂くという形で進めました。
パフォーマンス改善のPoC（Proof of Concept：概念実証）となりますので、過度なリソースは割かずにやってみましょうという感じです。楽楽販売では何かしらの機能追加する際にもPoCを実施し、「実現可能か？その時の課題としては何があるか？」を洗い出すといった作業を行う事は一般的です。とはいえ、「小さく試して大きく育てる」というのはラクスのリーダーシッププリンシプルにも掲げられていて、全社的にそういう考え方といった方がいいかもしれません。
やるしかない！と言いつつも無理に進めず、計画を立てて進めるのはラクスのいい所だと思います。
具体的にはどのように進めていったのでしょうか。
パフォーマンス改善の作法に準拠したやり方ですね。基本的にはボトムアップ式で進めました。計測して、ボトルネックを改善の繰り返しです。
ただ、一覧画面で時折劇的に遅いSlowQueryが発生している事などは事前に知っていた事もあり、最初は楽楽販売の一覧画面といえば「ユーザの設定に応じて独自カスタマイズされた一覧を返すSQLが遅い」という思考が先行してしまいました。また、実際の計測でもSlowQuery判定されるのはそういったSQLであったため、このSQL生成を効率化する事に注力し、最終的には目標値未達となってしまいました。
改めてトライした際には、SlowQueryには囚われずに、複数回呼ばれているSQLに遅いものがないか？本当に遅い処理はどこなのか？を全SQLのログから統計を取ったり、プロファイリングを実施する事で一番のボトルネックを探す方法で進めていきました。
進めるにあたって、どのような課題があったのでしょうか。その対応はどうされましたか？
課題としては、大きく分けて2点あります。
１つ目は、サーバ構成がモノリスであること。１つのサーバにアプリケーション、DB、その他のMWも全て混在しているため、サーバリソースを効率的に使えるチューニングを決めるのが困難な状況にあります。これに関してはすぐには手が打てるポイントではないので、サーバリソースに影響しない内容で改良ポイントがないかを再確認する事に留めました。
2つ目は、ユーザの設定毎に一覧を取得するSQLの構成が動的であること。普通のサービスであれば、テーブル毎に実行されるSQLにはある程度の型があり、データ量も予測できますが、楽楽販売ではそういった予想は非常に困難です。
よって、先にお話したように、一覧取得のSQLがSlowQueryとなっていても、それ以外の処理を対象とした改善を探す事で目標達成できるかを検証してみる事にしました。
パフォーマンス改善に取り組んだ結果どうなりましたか？また、今後期待される効果を教えてください。
全体としても、レスポンスタイムが1〜3秒帯のリクエストに関しても24%程度の改善を行う事が出来ました。その結果、仮想化を推進していく話も安心して進める事が出来、楽楽販売としては大きな成果だったかと思います。直近の機能改善とか優先順位の兼ね合いもあり、まだこのPoCの結果は現在の所はリリースされていませんが、随時リリースしていく予定でいます。
また、今回のパフォーマンス改善では手を加える事が出来なかった箇所もあり、理由としては技術的負債を抱えている中では手を出しにくい事などが上げられます。
今後はそういった技術的負債の解消に取り組みにも注力し、更なる改善・機能追加等を進めていける開発環境を整えていければと考えています。
