Cipher 클래스에서 암호화·복호화 지연 이슈 해결

 

EATceed 서비스에서는 사용자가 이메일 인증을 시도할 때 인증 코드를 사용합니다.

 

이 과정에서 보안을 위해 인증 코드를 암호화/복호화하고 있는데, 여기서 지연 문제가 발생했습니다. 암호화/복호화를 할 때마다 시간이 너무 오래 걸리고, CPU 부하가 크게 증가하는 것이었습니다.

 

문제를 분석한 결과, 원인은 Cipher 클래스를 사용하는 방식에 있었습니다. 본격적인 해결 방법을 설명하기 전에, 먼저 Cipher 클래스에 대해 간단히 소개하겠습니다.

 

Cipher 클래스란?

 

Cipher 클래스는 데이터를 암호화하거나 복호화하는 Java에서 제공하는 주요 클래스입니다. 이 클래스는 다양한 암호화 알고리즘과 작동 모드, 그리고 패딩 방식을 제공하여 다양한 보안 요구사항을 충족할 수 있도록 설계되었습니다.

 

하지만 중요한 점은 Cipher 클래스가 멀티스레드 환경에서 Thread-safe 하지 않다는 것입니다. 따라서 매번 새로운 Cipher 인스턴스를 생성해서 사용해야만 안전하게 암호화 작업을 수행할 수 있습니다.

 

또한, Cipher 클래스를 사용할 때는 암호화 알고리즘(예: AES), 작동 모드(예: ECB, CBC), 그리고 패딩 방식(예: PKCS5Padding)을 각각의 서비스 요구사항에 맞게 적절히 선택해야 합니다.

 

CBC 모드와 성능 병목

 

EATCeed에서는 AWS EC2 T3.micro 인스턴스를 사용하고 있습니다.

 

이 인스턴스는 vCPU 2개로 기본적인 성능을 유지하다가 트래픽이 몰리면 버스트 기능을 통해 일시적으로 성능을 높일 수 있습니다. 하지만 CPU 사용량이 기준 성능을 초과하게 되면 버스트 크레딧이 소모되며, 크레딧이 모두 소진되면 CPU 성능이 급격히 저하되는 문제가 발생합니다. 더더욱 T3 타입 인스턴스 이기때문에 기본적으로 버스트 기능이 무제한입니다. 

잘못하면 큰일날 수도 있습니다...😨

 

 

모니터링 결과 암호화/복호화를 수행할 때 기준 성능 10%를 초과하는 경우가 빈번하였습니다. 이에 암호화 모드를 CBC 모드에서 ECB 모드로 변경하였습니다.

 

ECB 모드는 각 블록을 독립적으로 처리하므로 병렬 처리가 가능해 속도가 훨씬 빠릅니다. 다만, 같은 평문이 반복되어 같은 암호문이 생성되어 보안성이 CBC 모드보다 낮습니다.

그러나, 인증 코드를 Redis에 저장할 때 짧은 TTL을 설정하고 있기 때문에 보안 관련 문제는 어느정도 보완할 수 있을 것이라 생각됩니다.

 

지금까지 Cipher 클래스를 사용하며 겪은 문제에 대해 포스팅하였습니다.