Logo

支援実績一覧

2024/06/11に公開

パフォーマンス改善

データベースや配信経路の最適化によって、システム全体の応答速度と安定性を向上。

チケット管理SaaSの検索レスポンスを高速化（N+1解消）

チケット管理SaaSにて N+1 解消と Preload / IN句最適化を実施し、一覧APIの応答時間を 1.4s → 0.2s（約7倍高速化）、DBクエリ数を 80%削減。

観点 内容
課題 一覧APIで N+1 クエリが多発し、ページ取得ごとに大量の SELECT が発行されていた。
対応 データアクセス層を再設計し、関連データを Preload で一括取得。複合条件の参照は IN句によるバッチ取得で最適化。
観測 リクエスト相関IDをキーとした構造化クエリログを導入し、クエリ数・種別・レイテンシをリアルタイム可視化。
結果・成果 クエリ数を削減し DB負荷と接続プールの占有率が安定。さらに、性能退行を常時検知できる状態を確立。
詳細を見る →

MySQL障害からの復旧と書き込み性能の安定化

本番DB障害の原因となっていたバッチI/O負荷を、テーブル月次パーティション化とINSERT最適化で解消し、バッチ時間を70%短縮、空きメモリ安定化。以降3ヶ月再発なし。

観点 内容
課題 業務時間帯に本番DBが障害を起こし、再送リトライがスパイクして全体のレスポンスが悪化。加えて、可視化が不十分で再発リスクを事前把握できない状態だった。
初動 Aurora 自動フェイルオーバーとリードレプリカ分散を即時整備し、Slow Query / CloudWatch メトリクス / エラーログを常時監視できる状態に。
調査 CloudWatch メトリクスとイベントログを相関分析し、バッチ処理の DELETE→INSERT 方式 がメモリ・I/O を圧迫していることを特定。
対応 テーブルを 月次パーティション化し、バッチを TRUNCATE + Multi-row INSERT に刷新。運用は 段階的移行・即時ロールバック・週次レポート をセットで定着させた。
結果・成果 計画外フェイルオーバーの 再発リスクを抑制。バッチ時間と負荷変動が安定し、システム全体の可用性と 判断スピード が向上。
詳細を見る →

リバースプロキシ(Nginx)導入によるオリジン負荷の軽減

CDN〜アプリ間にNginxリバースプロキシを導入し短期TTLキャッシュ/コネクション再利用を実装。オリジン到達リクエストを40%削減しCPU負荷と応答ばらつきを安定化

観点 内容
課題 動的APIがアプリサーバーに集中し、CPU使用率の高止まりとレスポンスばらつきが発生していた。CDN→アプリの直結構成により、リクエスト負荷を吸収できない状態。
対応 CDN とアプリの間に Nginx 中継レイヤを配置し、短期TTLキャッシュと Keep-Alive接続再利用 を導入。
運用 段階的導入と即ロールバック可能な設計を採用。HIT / MISS を可視化し、TTL と除外対象パスを継続的にチューニング。
結果・成果 オリジン到達リクエストを大幅削減し、アプリのCPU負荷とレスポンスのばらつきが安定。ピーク時の耐性が向上。
詳細を見る →

開発生産性向上

品質保証の自動化とビルドパイプラインの改善により、継続的な開発速度を維持。

自動テスト基盤整備による安心して改善できる状態の確立

手動検証依存だった環境に対し、Unit/Integration/E2E の三層テスト基盤を構築し、リグレッションを防止。“壊さない確信” を得て大規模リファクタとアップグレードを継続可能に。

観点 内容
課題 手動検証に依存しており、リグレッション発生・検証コスト増・手順の属人化により、改善スピードと大型アップグレードが停滞していた。
対応 ユニット / 結合 / E2E の3層を明確に定義し、テストが実装しやすい実行環境（CI・DB・モック・データ投入）を整備。
運用 テストテンプレート化 と 共通 Fixture / Builder により、記述と保守コストを圧縮。
失敗時に原因が一読で分かる命名規則を整備。
結果・成果 “壊していない確信” を得られる状態により、リファクタリングや依存アップグレードを安心して実施可能に。
手動確認も大幅に削減。
詳細を見る →

ビルド環境刷新による開発スピード向上

Webpack 前提のモノレポでビルドとHMRが重く開発が滞留していたところ、Rspack へ段階的に移行し、体感速度とレビューサイクルを大幅に改善した。

観点 内容
課題 Webpack 前提の大規模モノレポで、HMR の遅さ・初回/CI ビルドの重さ・キャッシュの不安定さが慢性化。
結果として、レビュー待ちが発生しやすく、変更の反映・検証に時間がかかっていた。
対応 Webpack とほぼ互換のある Rspack に段階的に切り替え。
変換・SourceMap・コード分割などの設定を整理し、キャッシュが安定して効く構成に再設計。
自動テストや E2E で互換性を確認しながら、無停止で移行。
運用 各 PR で Webpack / Rspack の二重ビルドを回し、差分（特にバンドルサイズ）を自動チェック。
ビルド時間やキャッシュ効率などの指標を可視化し、継続的に改善できる状態を維持。
結果・成果 HMR の体感速度とビルド時間が明確に改善。（例：差分ビルド -81%, 初回ビルド -67%）。
レビューが滞留しにくくなり、開発サイクルが軽く安定。
SSR / Storybook / Sentry など既存の仕組みを壊さずに効果を段階的に獲得できた。

プロダクト改善

検索体験や予約システムなど、ユーザー視点での操作性と信頼性を向上。

検索体験を改善し「0件」を減らす（クエリ緩和＋ランキング調整）

完全一致検索により「0件」になりやすい検索体験を、段階的な条件緩和とスコアリング調整により改善。代替提案を自然に提示できるようにし、離脱率を抑えつつ手応えのある結果提示を実現した。

観点 内容
課題 完全一致検索により、条件が少しずれただけで「0件」になりやすく、ユーザーが再検索を繰り返して離脱につながっていた。
対応 検索候補に点数をつけて、より「条件に近いもの」から順に表示する仕組みを導入。距離や一致度が少し違っても、なだらかに点数が下がるようなスコア調整（function_score + gauss）を適用。
運用 緩和ステップ／重み／閾値をダッシュボードで継続モニタリングし、A/Bテストによる副作用の検証と調整を継続。
結果・成果 「0件検索」を大幅に減らし、再検索回数の減少と滞在時間の向上を達成。
代替提案の受容率向上により、検索体験が分断されずスムーズに。
効果 手応えのある検索体験が実現し、在庫消化率・予約率の改善に寄与。今後のML化 / ベクトル検索への拡張余地も確保。
詳細を見る →

検索インデックス更新を非同期化し、ピーク時の耐性向上

ElasticSearch 更新を同期から Outbox→Pub/Sub→Indexer の非同期パイプライン に刷新し、ピーク時でも在庫反映の安定性と鮮度を両立。さらにこの方式を社内標準化し、他APIへ展開することで、負荷平準化と運用コスト削減を実現。

観点 内容
課題 在庫・価格更新を同期で ElasticSearch に反映していたため、書き込み処理が負荷集中時に遅延・タイムアウト。特にセール時などスパイク環境で可用性が不安定化していた。
対応 Outbox → Pub/Sub → Indexer による非同期パイプラインへ刷新。加えて、部分アップサートを採用し、更新処理の軽量化・最小差分更新を実現。
成果 書き込み体験の安定性を維持しつつ、ElasticSearch への反映も大きな遅延なく実施可能に。ピーク負荷時でも在庫鮮度と検索信頼性が両立。
波及効果 この非同期更新方式が社内の標準パターンとして定着。他 API や他プロジェクトへ横展開が進み、負荷平準化と拡張容易性を兼ね備えた更新基盤として運用コストを継続的に削減。
詳細を見る →

期限切れ予約の自動解放により、在庫整合性と販売機会を維持

期限切れ予約が在庫に残存する問題に対し、Redis TTL＋バックグラウンド解放ジョブを設計し、自動回収を実現。未解放率を7%→ほぼ0%にし販売機会損失を防止。

観点 内容
課題 一部の予約が解放されずに残り、在庫が「満席のように見える」状態が発生。販売機会を失い、担当者の手動解放も発生していた。
対応 Redis の TTL（有効期限）とバックグラウンドジョブを用いて、期限切れ予約を自動解放する仕組みを導入。
・ 同一予約の重複処理を防ぐため、一意キーで制御。
・ Redis はトリガー、実際の在庫更新は DB が担当する構成に。
可視化 滞留中の予約数と解放までの経過時間をメトリクス化し、モニタリングで挙動を常時把握。
成果 未解放予約はほぼゼロに改善。在庫が速く正確に更新されるようになり、販売機会損失を防止。
効果 予約APIのレスポンスが安定し、ロック待ちも減少。手動での解放作業がほぼ不要になった。
詳細を見る →