認証サーバーの応答速度最適化

 (engineering.ab180.co)
13 ポイント 投稿者 toughrogrammer 2025-08-28 | 2件のコメント | WhatsAppで共有
  • 問題の認識
    • Airbridge認証サーバーで断続的な応答遅延が発生。
    • APIリクエスト前に認証・認可を行うため、認証サーバーの遅延はサービス全体の安定性に直接影響。
    • 監視の結果、1秒以上の応答遅延アラートが次第に増加 → 原因分析と最適化作業に着手。
  • 原因分析
    • (1) 過剰なDBクエリ: 権限確認の過程でリクエストごとにDBクエリが過剰に発生し、その結果DB Connection Poolが急速に枯渇 → 応答遅延が発生。
    • (2) HikariCP Connection Poolの飽和: DBクエリを過剰実行するとHikariCPプールが飽和 → 30秒以上スレッドが待機する現象を確認。
    • (3) 低いキャッシュ効率: TTLを30秒と短く設定 + 非効率なキャッシュロジック → DBクエリ再発の可能性が高い。
  • 改善戦略
    • (1) 権限確認およびキャッシュ構造の改善
      • DB一括取得(findAllBy~)方式を導入 → DBクエリ134回 → 4回(-97%)に削減。
      • アプリケーションメモリベースのmutableMapキャッシュを適用。
      • 単一責任の原則(SRP)を適用 → メソッド分離および下位ロジックごとのキャッシュ戦略を設定。
    • (2) 2-Layer Cache構造の導入
      • Local Cache(Caffeine, L1) + Remote Cache(Redis, L2)の混合構造を適用。
      • キャッシュ戦略をL1-Only、L2-Only、Hybridに細分化し、運用効率を改善。
      • キャッシュメモリ使用量を分析 → Redisキー50万個を想定、必要メモリは約190MB、安全バッファを確保。
    • (3) Redis Pub/Subベースのキャッシュ無効化
      • TTL依存から脱却し、権限情報変更時にリアルタイムでキャッシュを同期。
      • 1台のサーバーで変更が発生した際、Redisチャネルを通じて全サーバーのLocal Cacheを同期的に無効化。
    • (4) HikariCPコネクションプールのチューニング
      • maximum-pool-size 10 → 30に拡張。
      • Connection Timeout、Idle Timeout、Max Lifetimeなどの詳細オプションを最適化 → DB I/O競合を緩和。
  • 性能テストおよび結果: 大規模トラフィックでも安定した性能を維持。
  • 本番環境での改善効果
    • デプロイ後、応答遅延アラートが消え、全体の応答時間が安定化。
    • サービス信頼性と運用安定性が大幅に向上。
  • 追加最適化: JVM Warm-Up
    • デプロイ直後、JITコンパイル遅延による初期リクエストの応答遅延問題を発見。
    • Warm-Up Runnerを導入:
      • アプリケーション起動時にダミーリクエストを事前実行。
      • K8s Pod入れ替え時、JIT完了後にトラフィックを処理 → 初期応答時間 1.07s → 94msに短縮。
  • 結論と効果
    • 応答遅延の問題を解決 + トラフィック急増に対応できる構造を確保。
    • Airbridge全体のサービス安定性と信頼性が向上。
    • 認証サーバーの活用度を高め、ドメインサービス開発の生産性を向上。

関連記事

2件のコメント

 
anona 2025-08-29

最近の Google ディープリンクサービス終了により、このサービスを利用する企業が増えたようですね。
安定したサービスに期待しています！
 
daumkakao 2025-08-28

えっ…うちの会社も最近ここに契約したんですが、性能向上のためにすごく頑張っていらっしゃるんですね！！！