NGINX Plus 사용 사례: mobilcom-debitel

mobilcom-debitel의 엔터프라이즈 Architect인 Felix Colaci는 회사가 API Gateway 솔루션을 Apigee에서 NGINX Plus 로 대체한 경험을 공유했습니다. Apigee와 같은 더 복잡한 API 관리 솔루션 대신에 언제 NGINX Plus 를 사용해야 하는지 궁금하다면 계속 읽어보세요!

Felix는 회사의 여정을 설명하면서 다음을 강조했습니다.

  • mobilcom-debitel이 API Gateway가 필요한 이유
  • Apigee와 마주한 도전과제
  • NGINX Plus가 더 나은 솔루션으로 선택된 이유
  • Rip-and-replace가 성공적으로 이루어진 결과

목차

1. API 관리의 필요성
2. Apigee는 너무 복잡했습니다.
 2-1. 가장 중요한 것에 집중하세요
3. 해결책: NGINX Plus
 3-1. NGINX Plus 를 통한 테스트 가능성
 3-2. 관리 용이성
 3-3. NGINX Plus 를 통해 개발자 경험 개선
4. NGINX Plus 교체로 인한 성과
5. API 관리를 위해 NGINX Plus 사용 시작하기

1. API 관리의 필요성

2012년, mobilcom-debitel은 애플리케이션 전달 전략을 재고하고 인프라 전체에 걸쳐 존재하는 다양한 시스템을 대체하기 위해 회사 전체적인 API 아키텍처에 초점을 맞추기로 결정했습니다. 주요 목표는 자사 애플리케이션뿐만 아니라 파트너의 애플리케이션과의 개발, 전달 및 통합을 가속화하는 것이었습니다. 또한, 회사는 시스템 간의 결합도를 낮추는 것을 가능하게 하고자 했습니다. 아키텍처의 핵심 구성 요소는 다음 네 가지 주요 사용 사례를 처리하는 API Gateway였습니다.

  • 요청 라우팅
  • 트래픽 모니터링
  • 인가
  • 추적

당시 사용 가능한 API 관리 솔루션 중에서 mobilcom-debitel은 NGINX Plus 대신 Apigee를 선택했습니다.

2. Apigee는 너무 복잡했습니다.

그러나 시간이 지나며, mobilcom-debitel은 Apigee가 그들의 API 관리 요구에 적합한 솔루션이 아니라는 것을 깨달았습니다. 그 이유는 간단히 말해서 너무 복잡했기 때문입니다.

네 가지 주요 사용 사례 외에도, mobilcom-debitel은 Apigee의 오케스트레이션 및 개발자 포털 기능만 필요로 했으며, Apigee가 제공하는 API 수익화 도구는 필요하지 않았습니다. 제품의 다양한 기능은 복잡한 아키텍처를 가져와 관리, 구성 및 사용자 정의가 어려웠습니다. 이 정도로 복잡한 구성 때문에 Felix와 팀원들은 50%의 시간을 API를 유지하는 데 할애했습니다.

Apigee는 개발자 포털을 포함한 일곱 개의 별도로 구성된 서비스와 하나의 논리적인 환경에 30개 이상의 가상 머신(VM)이 필요했습니다. 기술적인 한계와 이식성의 문제점도 있었습니다 (Felix는 최신 버전의 Apigee에서 이러한 문제가 해결될 수 있다고 언급했습니다). OpenID Connect가 완전히 구현되지 않았으며, 코드로 구성하는 것을 지원하지 않았으며, 대부분의 mobilcom-debitel 개발자가 사용하는 Windows에서 실행되지 않았으며, Red Hat Enterprise Linux만 지원되었으며 무료 오픈 소스 운영 체제는 지원되지 않았습니다.

또한, Felix의 팀은 Apigee의 신뢰성과 지원에도 만족하지 못했습니다. 업데이트가 때로는 플랫폼 충돌을 일으키고 롤백(rollback)해야 했습니다. 서비스들은 서로 강하게 결합되어 있어 한 가지 서비스에 문제가 발생하면 전체 플랫폼에 영향을 미쳤습니다. Felix는 또한 Apigee 지원의 응답 시간에도 만족하지 못했습니다.

2-1. 가장 중요한 것에 집중하세요

2017년, Felix와 팀은 새로운 API Gateway를 찾기로 결정했습니다. 그러나 Apigee와의 경험을 통해 이번에는 조금 다른 방식으로 접근했습니다. 네 가지 주요 사용 사례 외에도, 비즈니스에 어떻게 영향을 미치고 발전시킬지에 대해서도 고려했습니다. 최종적으로, 테스트 가능성, 관리 용이성 및 개발자 경험을 우선시하기로 결정했습니다.

NGINX Plus 가 등장했습니다.

3. 해결책: NGINX Plus

NGINX Plus 의 간단하면서도 강력한 솔루션 덕분에 Felix의 팀은 개발자들이 자신의 API를 쉽고 편리하게 게시할 수 있도록 만들었습니다. 그들은 나쁜 코드가 프로덕션 환경에 들어가는 것을 방지하기 위해 여러 가지 방어선을 확보했습니다. 또한, NGINX Plus는 단일 구성 요소이기 때문에 관리하기가 매우 쉬웠습니다. 각 우선순위를 어떻게 달성했는지 살펴보겠습니다.

해결책으로 NGINX Plus 사용

3-1. NGINX Plus 를 통한 테스트 가능성

NGINX Plus Data Plane(API Gateway)은 지구에서 가장 빠른 속도로 여러 환경에 배포할 수 있으며, 예비 테스트를 위해 Docker를 포함한 여러 환경에 배포할 수 있습니다. Docker 컨테이너에 수동 인스턴스를 배포함으로써 Felix는 사용자에게 영향을 미치지 않고도 API 구성이 의도한 대로 정확히 작동하는지 쉽게 확인할 수 있습니다.

3-2. 관리 용이성

7개의 서비스 대신 하나의 서비스를 사용하고, 간단한 분석 통합으로 구성 및 가시성을 용이하게 만들었습니다. OAuth와 OpenID Connect를 사용하여 NGINX Plus API Gateway는 인증과 애플리케이션 수준의 권한 부여를 처리하며, Felix의 팀은 지원되는 Lua 동적 모듈을 활용하여 사용자 수준의 권한 부여를 구현했습니다.

3-3. NGINX Plus 를 통해 개발자 경험 개선

NGINX Plus는 코드로 구성을 지원하기 때문에 mobilcom-debitel의 소프트웨어 전달 파이프라인과 CI/CD 프로세스에 완벽하게 통합됩니다. 개발자들은 이제 기존의 파이프라인을 통해 API의 테스트와 릴리스를 쉽고 효율적으로 관리할 수 있습니다. 또한, Lua 스크립팅 덕분에 개발자는 권한 부여를 활성화하기 위해 스크린샷에 표시된 NGINX Plus 구성의 강조된 설정을 편집하기만 하면 됩니다.

개발자 경험을 개선하는 NGINX Plus

4. NGINX Plus 교체로 인한 성과

성능이 좋지 않은 API Gateway를 대체하는 것은 시간과 노력을 들일 가치가 없다고 생각할 수도 있습니다. 그러나 Felix는 몇 가지 설득력 있는 반론적인 데이터 포인트를 제시했습니다! Apigee에서 NGINX Plus 로 80개의 API를 Migration 하는 데는 단 8개월이 걸렸으며, Downtime이나 Production에 영향을 미치지 않았습니다. Felix는 이 경험을 한 마디로 요약했습니다.

우리는 고객에게 아무런 영향을 주지 않고 전체 API 플랫폼을 새로운 솔루션으로 전환할 수 있었습니다.

모빌컴-데비텔은 NGINX Plus로 전환함으로써 장기적인 이점을 누리고 있습니다. 그 중 하나는 6자리 수준의 비용 절감입니다. 환경당 가상 머신(VM) 수가 30개 이상에서 2개로 줄어들어 서버 및 라이선스 비용을 낮추고 유지 보수 비용을 60% 절감했습니다. 운영 측면에서 코드 변경을 프로덕션으로 전환하는 데 걸리는 시간은 단 몇 분입니다. NGINX Plus는 Apigee보다 신뢰성이 높으며, Felix는 팀이 도움이 필요한 경우에 NGINX 지원을 “뛰어난”이라고 평가했습니다.

Felix가 API 플랫폼 팀에게 마지막으로 조언하는 내용은 다음과 같습니다:

비즈니스를 강화하고 제품 팀이 고객 경험을 향상시키기 쉽도록하기 위해 API 플랫폼 팀이 정말 필요한 것에 집중해야 합니다.

5. API 관리를 위해 NGINX Plus 사용 시작하기

API 관리 요구 사항에 맞는 NGINX 솔루션을 살펴볼 준비가 되셨나요?

아래 뉴스레터를 구독하고 NGINX와 NGINX STORE의 최신 정보들을 빠르게 전달 받아보세요.

NGINX STORE를 통한 솔루션 도입 및 기술지원 무료 상담 신청

* indicates required