AWS OpenSearch Nori Plugin 트러블슈팅
Referenced by
1. 서론 (Context & Tension)
검색 기능 강화를 위해 AWS OpenSearch Service에 한국어 형태소 분석기인 analysis-nori 플러그인을 설치해야 했습니다. Terraform으로 리소스 하나 추가하면 끝날 것으로 예상했지만, 실제 적용 과정은 타임아웃, 리소스 Taint, API 접근 거부(403) 로 이어졌습니다.
이 문서는 플러그인 설치 과정에서 발생한 문제를 정리하고, AWS 관리형 서비스 동작과 Terraform 운영 전략을 기록합니다.
2. 문제 분해 (Problem Decomposition)
발생한 문제는 크게 세 단계로 나뉩니다.
- 배포 실패 (Timeout & Taint): Terraform이 플러그인 연결 중 타임아웃으로 실패하고, 리소스가
tainted상태로 표시됨. - 리소스 충돌 (409 Conflict): 복구를 위해 다시 배포하거나 삭제하려 했으나, AWS 측에서 “작업 중”이라며 거부함.
- 서비스 장애 (403 Forbidden): 플러그인 설치 후 애플리케이션의
/health체크가 실패하며 API가 불안정해짐.
3. 탐구 과정 (Investigation)
3.1. 첫 번째 원인: Terraform 타임아웃과 Blue/Green 배포
analysis-nori는 AWS OpenSearch의 ‘Optional Plugin’으로, 도메인에 Association하는 방식으로 설치됩니다. Terraform apply를 실행했으나, 10분이 지나자 Error: timeout 으로 실패했습니다.
- 원인: 패키지 연결(
Association)은 도메인의 Blue/Green 배포를 트리거합니다. 새 노드를 띄우고 데이터를 옮기는 이 과정은 데이터 양과 노드 규모에 따라 수십 분 이상 걸립니다. Terraform의 기본 타임아웃(10분)은 부족했습니다. - 결과: Terraform은 실패로 간주하고 리소스를
tainted로 마킹했습니다. 하지만 AWS 백그라운드에서는 배포가 계속 진행 중이었습니다.
3.2. 두 번째 원인: 409 Conflict와 Taint 처리
Taint된 리소스를 정리하려고 destroy나 재 apply를 시도했으나, 이번엔 409 Conflict 에러가 발생했습니다.
- 원인: AWS OpenSearch는 한 번에 하나의 설정 변경(Config Change)만 허용합니다. 첫 번째 시도로 촉발된 Blue/Green 배포가 아직 끝나지 않았기 때문에, 추가적인 수정이나 삭제 요청이 모두 거부된 것입니다.
- 해결: 도메인 상태가
Active로 돌아올 때까지 기다린 후,terraform untaint와refresh-only로 Terraform 상태(State)를 실제 AWS 상태와 동기화했습니다.
3.3. 세 번째 원인: Nori 설치 직후 403 발생
Nori 플러그인 설치가 완료된(Active) 직후, 애플리케이션의 헬스 체크가 실패하며 Response Error가 발생했습니다.
- 가설: Nori 설치 과정이 도메인 접근에 영향을 줬는가?
- 검증: 파드 내부에서
curl로 OpenSearch에 직접 요청을 보내보았습니다.# 파드 내부 curl https://vpc-....es.amazonaws.com/ > 403 Forbidden > "User: anonymous is not authorized ..." - 진짜 원인: Nori 때문이 아니었습니다. Terraform이 도메인 설정을 재적용(Update)하는 과정에서
Access Policy가root계정만 허용하도록 확정되었기 때문입니다. 애플리케이션은 SigV4 서명 없이(Basic Auth 등) 요청을 보내고 있었고, 이 요청들이 엄격해진 Access Policy에 의해anonymous로 분류되어 차단되었습니다.
4. 개념 연결 (Concept Linking)
이 문제는 다음 두 가지 개념 이해가 부족한 상태에서 발생했습니다.
- AWS OpenSearch Nori Plugin Management: 패키지 연결이 Blue/Green 배포를 유발하며, 이에 따른 타임아웃 관리가 필수적이라는 점.
- AWS OpenSearch Access Policy Principal:
Access Policy는 IAM 레벨의 방화벽이며, 서명되지 않은 요청은Principal설정에 따라anonymous로 거부될 수 있다는 점.
5. 결정과 트레이드오프 (Decision & Trade-offs)
타임아웃 해결
- 결정:
aws_opensearch_package_association리소스에timeouts { create = "60m" }을 명시적으로 설정했습니다. - 이유: 배포 지연은 AWS 구조적 특성이므로, Terraform이 이를 기다리도록 설정해야 합니다.
접근 권한 복구 (403 해결)
- 결정 (단기):
Access Policy의Principal을*(모든 AWS 계정) 로 열고, 보안은 Security Group(EKS Node, Bastion 허용) 과 FGAC(Basic Auth) 로 유지했습니다. - 결정 (장기): 애플리케이션 코드에 AWS SDK(SigV4) 서명 로직을 추가하여, IAM Role(
Principal) 기반의 정교한 접근 제어로 전환하기로 했습니다. - 트레이드오프: 단기적으로는 IAM 레벨의 방어를 낮추는 대신 가용성을 확보했고, 장기적으로는 코드 복잡도가 늘어나지만 보안을 강화하는 방향을 선택했습니다.
6. 결론 (Takeaways)
- 관리형 서비스의 설정 변경은 배포를 수반할 수 있다: AWS 리소스, 특히 데이터베이스류의 설정 변경은 인프라 교체(Blue/Green)를 동반할 수 있습니다. 따라서 Timeout을 넉넉히 잡아야 합니다.
- 보안은 계층이다: 네트워크(SG)와 인증(IAM/FGAC)은 별개입니다. 한쪽이 열리더라도 다른 계층으로 통제하는 구조를 전제로 운영해야 합니다.
References