Amazon Connect를 통해 치명적 오류 감시 비용을 절감한 방법

반응형

일본에서 클라우드 기반팀에서의 내부용 API 개발을 하던 때의 이야기입니다.

월 2만원정도의 유지비를 통해 치명적 에러 감시 자동화를 구축했던 경험이다.

 

고객사의 요청은 온프레미스 환경에서 구축되어 있던 기존 서버에서의 치명도가 높은 레벨의 에러 발생 시 보수 담당자에게 메일을 통보하고 교대로 24시간 감시하던 부분을 자동화를 통해 해결하고 싶다는 것이었다.

 

목적은 치명도가 굉장히 높은 에러를 보수담당자가 직접 확인하거나 메일로 통보받다가 누락되어 엄청난 손실을 받은 적이 있기 때문이다. 

 

클라우드 기반의 API 구축에서는 Lambda를 통해 해결하기 쉬운 문제였으나 온프레미스에서 AWS 클라우드 환경의 네트워크 통신 경로가 외부 아이피에 접근할 수 없는 구조였으므로 Lambda 리소스에 접근할 수 없었다.

 

해결하기 위해 어떠한 경로를 통해 Lambda에 접근할 수 있을 것인가를 혼자 해결해야하는 상황이었는데 온프레미스 클라이언트 서버의 에러 감지 소프트웨어가 치명적인 에러를 감지하면 스크립트를 실행할 수 있는 구조였기에 일단 Rest API를 통해 API Gateway의 엔드포인트에 접근할 수 있다면 해결할 수 있지 않을까 생각하여 API Gateway에 대해 엄청 공부를 하던 중 VPC Endpoint라는 서비스를 통해 접근할 수 있는 방법을 확인했다. VPC Endpoint는 외부로부터 격리된 공간의 프라이빗 서브넷에서 내부 아이피를 부여받아 AWS 서비스에 끝점을 연결할 수 있는 방식이다. 이를 통해 API Gateway에 접근할 수 있었고 Lambda에 로직을 구성하여 API를 내부에서 호출하는 방식으로 해결할 수 있었다.

 

온프레미스 환경에서 프라이빗 네트워크 통신에서 API Gateway까지의 통신경로

API Gateway를 통해 페이로드에 담긴 내용을 통해 Lambda는 Amazon Connect의 아웃바운드 호출 API를 호출해 보수담당자에게 전화를 걸어 치명적인 에러 발생 사실을 알리고 Amazon SNS를 통해 에러 내용을 메시지로 전달한다.

 

이렇게 배포된 API는 외부에서 접근할 수 있는 모든 경로가 차단되어 있으며 혹시라도 보안에 더욱 신경쓰기 위해 리소스 정책에 온프레미스 클라이언트 서버의 IP만 화이트리스트에 허용하는 방식으로 내부에서도 정해진 클라이언트 서버의 IP만 허용하는 방식으로 API 요청을 할 수 있었다.

 

뿐만 아니라 클라우드의 환경에서 관리하던 서버의 에러 또한 Amazon CloudWatch를 통해 트리거 설정을 할 수 있으며 에러 중요도를 설정해 같은 Lambda를 돌려 사용할 수 있었다. 즉 온프레미스에서의 에러는 API Gateway를 통해 요청을 받았고 클라우드의 서버에서의 에러는 CloudWatch의 감시기능을 트리거로 사용하여 Lambda를 호출하는 방법으로 두 요청에 대해 처리할 수 있었다.

 

가장 중요한 비용적인 측면에서 Amazon Connect로 아웃바운드 번호를 부여받아 유지하는데 약 1만원과 VPC에 엔드포인트를 구축하고 유지하는 게 1만원 이외에 API Gateway나 Lambda 호출 비용은 무료 사용범위에 손톱만큼의 영향도 끼치지 않는 범위였다.

 

혼자 기획하고 혼자 개발에 착수하는 큰 위험도가 있었기때문에 API Gateway 혹은 Lambda 단위에서 코드의 에러 이외에 에러가 발생할 경우를 대비해 AWS 측에 자문을 구하고 그런 경우의 에러가 발생했다는 것은 AWS 클라우드 시스템 자체에 치명적인 오류가 발생할 경우 이외에는 없을 것이라는 AWS 측의 답변을 듣고 안심하면서 혹시 모를 사태에 대비해 팀원 모두에게 빠르게 메시지를 전송하는 기능을 함께 추가하고 배포 마무리를 하고 약 1년간 문제없이 돌아가고 있는 것을 확인하고 안심할 수 있었다.