API가 없는 회사와의 통신

회사의 신규 서비스 개발 중 외부 업체의 비지니스 로직을 통한 계산이 필요한 기능이 필요했다.

 

■ As-is

• 외부 업체는 IT업체가 아니기 때문에 사내 개발자와, API 서버가 존재하지 않는다.
• 외부 업체는 제휴를 통해 계속해서 늘려나가야 한다. (다른 외부 업체는 개발자와 API서버가 존재할 수도 있다.)

■ Challenge

• 외부 업체에서 만들어야 할 시스템을 우리 회사 내부 로직으로 만들기로 하였다.
  
  • 기준 데이터들과 도메인 지식을 활용하여 내부 로직으로 구현.
  • 기준 데이터가 주기적으로 변경되기 때문에 로직에 직접 넣는 것이 아닌 RDB에 값을 넣고 확인.
• 추후 통신을 할 수 있는 외부 업체가 있을수도 있으니, 통신이라는 Interface를 사용하여 Factory Pattern으로 작성.
  • 외부 업체의 관리 코드와, 연결방식 2가지의 데이터를 가지고 Factory Pattern을 만들어 사용.

■ To-be

• API 통신여부와 상관없이 기준 데이터들만 있으면 우리 회사 안에서 그 기능을 수행할 수 있다.
• Factory Pattern으로 다양한 외부 업체가 생겨도 안전하게 확장할 수 있게 되었다.

---

■ As-is

• 계산 기능은 해결 했지만, 실제 사용자의 데이터를 외부 업체에 전달해야 한다.
• 마찬가지로 서버와 개발팀이 없기 때문에 API 통신은 불가능하다.

■ Challenge

• 사용자의 데이터를 전달하기 위해 Email에 데이터를 적어 전달하기로 결정.
  • 데이터를 보호하기 위해 Apache PDF로 PDF를 만들고 외부 업체별로 암호를 설정하여 암호화.
  • Amazon SES를 사용하여 PDF 파일 전송.
  • 외부 업체의 Email 주소를 RDB에 저장하여, 변경에도 대응할 수 있도록 수정.

■ To-be

• Mail Server를 활용하여 API 데이터 전송없이, 사용자와 외부 업체와의 연결 시스템 구축.

---

 

■ As-is

• 보안이슈와 폐쇄망 환경으로 방화벽 아웃바운드 ALL OPEN이 불가능하다.
• Amazon 의 Mail Server IP가 비정기적으로 변경되어 Connection Timeout 에러가 발생한다.
  • Connection timeout 발생 시 사용자가 해당 에러가 뜰 때까지 계속 기다려야 한다.

■ Challenge

• Connection Timeout 발생시 빠른 대처를 해야한다.
  • Slack 으로 해당 에러를 Notice하도록 작성.
  • Notice를 보안팀에 공유하고 방화벽 설정을 요청 하도록함.
• 발송 실패 데이터를 저장하고 다시 Connnection이 되었을 때 발송.
  • 기록할 데이터가 아니고 이슈가 해결되면 없어질 데이터로 판단. RDB 대신 Redis를 사용하였다.
  • 수동, 자동으로 재발송이 되어야 하기때문에 Jenkins Scheduler로 해당 로직을 수행하도록 작성.
• 사용자관점에서 사용자는 문서에 내용을 잘 작성했다면, 전송 실패란 없다.
  • Amazon의 Mail Server로 요청하는 작업을 따로 분리하고, RabbitMQ를 사용하여 비동기로 해당 작업을 호출 하도록 작성.
  • 사용자는 무조건 성공이고, 이 이후에 에러는 회사에서 어떻게든 해결.

■ To-be

• 실제 메일 발송 성공여부와 상관없이 사용자는 불편함을 겪지않고 신청을 할 수 있게 되었다.

---

■ Will

• Amazon의 VPC endpoint를 사용하면 지속적인 방화벽 작업을 할 필요 없이 권한을 가지고 위 Connection문제를 해결할 수 있다고 한다.
• PDF전송기능 없이 외부 업체에서 자사 서비스에 접속하여 신청 데이터를 볼 수 있도록 Partner Center 구축.