Upgrade to Pro — share decks privately, control downloads, hide ads and more …

電気料金シミュレーションサービスの マイクロサービス化と動的プラン検索の改善

電気料金シミュレーションサービスの マイクロサービス化と動的プラン検索の改善

Avatar for So Hosoki

So Hosoki

March 18, 2024
Tweet

Other Decks in Technology

Transcript

  1. Confidential 自己紹介 ENECHANGE株式会社 └── エネルギークラウド事業部 └── Marketing Unit ├── backend

    エンジニアがメイン │ └── Ruby on Rails ├── アーキテクチャやインフラ構成などを考えたり │ └── AWS └── 電気料金シミュレーションや電力プラン管理の開発など 2
  2. Confidential 5 マイクロサービス化による新課題 • マイクロサービス化により事業者ごとのプラン管理の効率化が進んだ一方新たな課題も発生 • これまでは各リポジトリで管理していたシミュレーション対象のプランの一元管理が必要 ◦ シミュレーションの比較先プランは比較元の契約内容をもとに複雑なロジックで検索する必要がある ▪

    別リポジトリの時は事業者の要件にあったロジックのみで大丈夫だった ◦ 検索には複数テーブルを参照する必要があり、対象プランが多い事業者は負荷が高い ◦ 一部の事業者には対象プランを動的に切り替える機能があり、設定ファイルで定義したりも難しい • リクエストのたびに対象プランを検索していると大変なので効率的に検索する方法が必要
  3. Confidential 6 検索結果のキャッシュ化 • 検索結果をキャッシュ化 ◦ プラン情報自体は静的な csv で管理しており変更タイミングをコントロール可能 ◦

    そのため基本的には結果をキャッシュしても問題ないと判断 • 一方で一部の事業者は動的に対象プランを切り替えられる ◦ キャッシュ化した後に対象プランが切り替わった場合、その変更が検索に反映されない
  4. Confidential 7 検索結果のキャッシュ化 • キャッシュの登録、削除のタイミングをコントロールして常に正しい結果が出せるように調整 ◦ キャッシュは事業者、検索条件別に保持 ▪ 検索が実行されたらその結果をキャッシュ化 ◦

    プラン情報の変更時は必ずキャッシュクリア ◦ 動的に対象プランが変更になった際もキャッシュクリア • → 結果的に検索のパフォーマンスが向上 ◦ 対象プランが多い事業者の比較元が特に顕著 > # 比較元プラン > # 検索 : 単純、レスポンス : 複数テーブルの join が必要で複雑 > > no cache : 38.224745626 m > cached : 0.006153807 m > > > # 比較先プラン > # 検索 : 複雑、レスポンス : 単一テーブル単一カラムの配列で単 純 > > no cache : 1.860050647 m > cached : 0.035776146 m ローカルで本番同等のデータを再現して計測