현재 다니고 있는 회사는 SaaS형 웹 사이트를 고객사에 제공하고 있습니다. 외부 API를 연동하는 부분이 많아, 장애 대응 방법을 고민하고 있었습니다. 대외 고객사가 많아, 에러가 나면 리스크가 크고 보고와 대응 방법 체계가 중요했습니다. 특히, 요즘 모니터링 툴을 살펴보면 쓰레드 임계치를 넘을 때가 많아, 외부 API 장애 대응 레퍼런스를 정리하였습니다. 아래 사례는 저희 회사의 직접적인 사례는 아니지만, 유사한 점이 있어 많은 도움이 되었습니다. 앱이 API 요청을 하면 일부는 DB에서 처리하고 일부는 뒤쪽 외부 API를 호출하는 형태인데, 이 구조에서 에러가 발생했다. 최근, 순간적인 DB 커넥션 풀 부족 장애 방생 약 10분 정도 2차례, API 서버에서 응답 시간 지연과 에러 발생 커넥션 풀에..

1번) 전통적인 Client - Server 구조는 Cline(Front)가 있고 통신할 API Server가 있고 아이디와 비밀 번호를 검증할 수 있는 Database가 있습니다. 만약, 1번 아키텍처를 사용하는 서비스의 이용자가 많아졌을 때 어떤 현상이 발생할까? API Server는 스케일 업(Scale-up)과 스케일 아웃(Scale-out)으로 서버 증강을 진행한다.(서버를 늘린다) 문제는 Database에서 발생한다. 병렬처리(분산처리)가 쉽지 않고 서버보다 증강 비용이 많이 든다. 또한, Clinet의 데이터를 보관해서 따르는 보안, 관리 부담감이 생긴다. 2번) Client - Server 구조는 JWT(JSON Web Token) 를 활용하여, 가장 관리하기 번거로운 Database를 없..

HTTP의 개념과 문제점 HTTP : Hyper Text Transfer Protocol (하이퍼 텍스트르르 전송하기 위해 만들어진 약속) 단점 : 보안에 취약 암호화하지 않은 통신 : (통신 경로상에 있는 네트워크 기기나 케이블, 컴퓨터로) 도청 가능 입력한 텍스트 그대로, 누구든 알아볼 수 있는 형식으로 보내짐 통신 상대를 확인하지 않기 때문에 신뢰성이 떨어짐 HTTP는 누가 요청을 보내와도 응답을 해주는 구조 클라이언트, 서버에 대한 확신이 없음 서버와 클라이언트 정보를 누군가 바꿀 위험도 있다 HTPP 단점 극복 1) 암호화하지 않은 통신 대칭키의 등장 로그인할 때 실어보내는 비밀번호를 대칭키로 암호화하고 네이버에서는 이를 복호화해서 인식할 수 있다. 중간에 누가 이 데이터를 훔치더라도 대칭키가 ..