인프콘 후기 - 인프런 아키텍쳐 / 이동욱 CTO

• 인프런은 하나의 거대한 레거시 프로젝트를 리펙토링하고 있었음.

• 하나의 서비스에 개발팀, PM팀, 디자이너 팀 등 큰 하나의 공동체로 조직화 되어 있었음

• 개발 속도 개선을 위해 5개의 팀으로 나누어 각각의 서비스를 개발함

문제: N개의 서비스가 생겨나면서, N배의 인프라가 필요

• IaC(Infrastructure as Code) 를 통해 코드를 통해 아키텍쳐를 생성할 수 있도록 함.

• 이후 같은 코드를 실행하면 같은 아키텍쳐를 만들어낼 수 있음

문제: API 호출마다 퍼블릭 IP와 path를 이용한 분기를 이용하다보니 불필요한 네트워킹, 트래픽 비용이 발생

• 퍼블릭 도메인으로 요청을 하지 않고, Private Load Balancer 를 통해 내부적으로 API 통신하여 해결함.

문제: 내부 API 호출이 많아지면서 타 서비스의 로직까지 알아야하고, API 예외 로직을 추가로 만들어 처리해야함

• 타 서비스에 대한 API 요청은 우리 서비스가 알 필요 없음

• 따라서, SNS를 통해 API를 호출하겠다는 정보만 남김

• 이후, SQS를 통해 SNS를 구독하여 정보를 받아 API를 호출하도록 처리

• 비동기적으로 처리하여 서비스간 종속성을 제거하고, 빠른 처리가 가능함.

• SQS를 통한 api 호출은 re-try가 가능하므로 최종적 일관성이 보장됨.

문제: 서비스는 여러 개 있지만 단일 DB를 사용

• 파생되는 문제점

  • DB 정보에 대한 팀들간 정보의 공유가 필수적임

  • 어느 서비스에서 에러 쿼리를 실행했는지 정확히 파악하기 힘듦

• 해결

  • DDL 마다 Slack에 연동하여 정보를 공유함

  • 서비스마다 계정을 나누어 어느 서비스의 문제인지 확인함

어설픈 추상화/공통화 보다는 삭제하기 쉬운 중복이 낫다.

이외: 인증 인가를 서비스마다 처리해주어야하는 로직 중복 문제 => API 게이트웨이를 통해 하나의 엔드포인트에서 관리