株式会社ポーラ・オルビスホールディングス｜基幹ECサイトのAmazon Auroraバージョンアップを 「Insight SQL Testing」によるSQLテスト自動化を活用し、短期間で「無事故」達成

ポーラ・オルビスホールディングスは、ブランドごとに独自のECサイト戦略を展開し、顧客体験の最大化を追求している。中核ブランドのオルビスでは、約18億レコードもの膨大なデータを抱えるECサイトがビジネスの根幹を成し、キャンペーン時にはアクセス集中により極めて高い負荷が発生する。そのため、システムの安定稼働は必須だった。しかし、過去のデータベースのサポート終了に伴うバージョンアップでは、意図せぬ性能劣化を経験しており、ECサイトでの同様の事態は絶対に避けなければならなかった。しかし、限られた期間内に膨大な数のSQLクエリを人手で網羅的にテストすることは非現実的だった。このような背景のもと、オルビスはデータベース移行の品質と効率を飛躍的に高める切り札として、Insight SQL Testingの導入を決めた。

個性を尊重し、顧客体験を最大化するポーラ・オルビスのECサイト戦略

1929年にポーラ化学工業所が創業、1980年代にはオルビスが生まれ、2006年に両社を傘下に収める持ち株会社ポーラ・オルビスホールディングスが誕生した。中核ブランドのポーラとオルビスに加え、ACROが展開する「THREE」などのプレステージブランドを含む、個性豊かなブランド群を擁する。それぞれのブランドが独自の販売チャネルと顧客層を持つ点が特長だ。さらに、自社による高い研究開発力に基づいた製品開発と、顧客との直接的なコミュニケーションを重視する販売戦略も強みだ。

各ブランドの個性を生かす戦略をとっているため、ネットワークやセキュリティなど共通化すべき部分を除き、ITシステムも独立して構築・運用されている。ECサイトやモバイルアプリもブランドごとに存在している。

主力のオルビスでは、通販事業の割合が約6割になっている。モバイルアプリのダウンロード数が600万を超えるほか、重要な顧客接点となるECサイトのデータベースには約18億レコードのデータがあり、基幹システムと連携し処理が行われる。

毎月20日から実施するキャンペーン「オルビスウィーク」には、多くの顧客がオンラインショップにアクセスし、最終日には極めて多くの決済処理が発生する。このキャンペーンは毎月開催されるが、3月、6月、9月、12月が特に利用が多く、短時間のシステム停止であっても甚大な影響を与えかねない。ピーク時にはアクティブユーザー数が1分間に約800名、受注処理数は200件を超え、ECサイトのトラブルはビジネスに甚大な影響を与えかねない。

人手を削減し確実なDB更新のためにInsight SQL Testingを選択

オルビスのECサイト内には、独立した機能としてクチコミサイトがある。そのデータベースにはAmazon RDS for MySQLを利用していた。2024年5月、Amazon RDS for MySQL 5.7の標準サポート終了に伴い、8.0へのバージョンアップを完了した。しかし、「意図しない性能劣化が発生し、ユーザビリティにも影響がありました」とポーラ・オルビスホールディングス グループデジタルソリューションセンターWEB・CRM DX推進チームの横内友理子氏は言う。この対処には、多大な手間を要した。

一方主要なECサイトの裏側では、5.7互換のAWS Aurora MySQLバージョン2を使用しており、サポート終了のため8.0互換のバージョン3への更新が必要だった。以前クチコミサイトで発生したような移行に伴う性能劣化は、中核であるECサイトでは絶対に許されない。標準サポート終了が2024年10月末に迫り、それまでにAmazon Auroraのバージョンアップを確実に実施しなければならなかった。

確実なバージョンアップには、網羅的なテストが不可欠である。しかし、クエリ数が多いため、人手によるテストは現実的ではなかった。オルビスのECサイトは、アプリケーションとインフラで協力会社の支援を受けている。データベース移行における詳細なテストは、アプリケーションを支援する協力会社に高い負荷をかける可能性があった。

「期限が数ヶ月先に迫っており、なおかつクエリ数が多いという状況でテストを確実に行い対処するには、何かウルトラC的なものが必要でした。その観点でアプリケーション担当者様が調べて、Insight SQL Testingを提案してくれました」と横内氏は振り返る。もし人手による網羅的なテストでバージョンアップに対応した場合、半年以上の期間を要する状況だったという。

さっそく机上でInsight SQL Testingのメリットや効果を調査し、トライアルを実施。テストの結果が網羅的に出力される点は評価できた。効率的にテストできると判断した。

横内氏はシステム開発経験もあり、手作業のテストにどれくらいの手間がかかるかの感触は持っていた。そこで、詳細にテストすべきSQLクエリが約300個あると想定し、人手でテストしレポートする場合とInsight SQL Testingを利用する場合で比較した。

人手では1クエリあたり最低でも0.25人日かかると見積もった。結果、単体テストだけでも3ヶ月以上を要すると積算された。「これでは期限に間に合いません。人件費も考慮すれば、Insight SQL Testingを利用することで大幅な効率化が期待できます。さらにスケジュール内に収めることができると説明して、採用の承認を得ました」と横内氏は説明する。試算では約300と見積もっていたSQLクエリ数だったが、実際には220件程度だったものの1時間当たりのログ件数は100万件と膨大な数に上った。これらを整理してテストを実行し、問題が発生した場合の原因やボトルネックを特定してレポーティングを行うところまで含めた工数は、Insight SQL Testingなしでは到底終わる量ではなかったという。

限られた時間での網羅的なテストはInsight SQL Testingがなければ不可能だった

2024年7月後半にInsight SQL Testingのトライアルを実施、その後約2週間の期間をかけ本番環境からSQLを取得した。1時間のSQL取得数が100万を超えることもあったため、クエリのログサイズが肥大化しないよう調整し、さらに数回に分けてテスト環境に送るなどの工夫をした。

取得したSQLを用い、機能・非機能テストを実施。機能面ではSQLの実行エラーや結果の相違は事前の想定通りで、Insight SQL TestingのAmazon Bedrockを活用した修正提案機能などを用いた結果、わずかな修正作業で対応できた。非機能面ではCPU使用率の上昇といった問題も発生したが、チューニングで対応できないものはインスタンス変更などで対処した。

「1時間に100万クエリといった数は、Insight SQL Testingなしでは到底テストはできませんでした」と横内氏。Insight SQL Testingがあったからこそ、短期間に網羅的なテストが実施できたと評価する。また、必要がないのに都度SQLを実行してデータを取得しているケースが見つかるといった、想定外のメリットもあった。これについては、キャッシュを設定して効率化している。

不具合や意図しない結果が出た際に、改めてテスト環境を用意しSQLを実行する手間をかけずとも、結果画面から該当SQLの再テストが直ちにできる点も便利だった。この機能により、テストの人的リソースをさらに削減することができた。

Insight SQL TestingのDB移行以外での活用にも期待

一連のテストと移行作業には横内氏と協力会社の3名ほどが携わり、アプリは11月に、ECサイトは2025年1月に完了した。「期間が限られる中、大量のクエリがあったので、まさに背水の陣の対応でした。結果的に無事故で移行でき、Insight SQL Testingには感謝しています」と横内氏は言う。

大規模なデータベースのマイグレーションの機会は今後も必ずある。それに対しInsight SQL Testingが有効なことを、グループデジタルソリューションセンターの部門メンバーにも共有した。

また、SQL Testingはデータベースの移行だけでなく「アプリケーションのリニューアル時などにも、メリットがあるのではと考えています」と横内氏。ポーラ・オルビスは、「守り」よりも「攻め」を大事にし、施策を数多く打っている。攻めの施策でも、もちろん性能劣化などは許されない。攻めながらもしっかり守る。その側面でも、Insight SQL Testingは活用できると期待している。