Agile 개발을 촉진하기 위해 소프트웨어 로드밸런서를 사용하세요.

Agile 개발은 더 이상 단지 유행어가 아닙니다.
이것은 기업들이 모던한 애플리케이션을 통해 금융, 미디어 전달, 소매와 같은 기본적으로 모든 산업에서 훌륭한 사용자 경험을 제공하는 대상들과 경쟁하는 새로운 서비스를 구축하는 방법입니다.

결과적으로, 기업들은 매주, 매일, 심지어는 매시간 새로운 기능을 제공함으로써 경쟁에서 앞서가도록 개발자와 운영팀에 엄청난 압박을 가하고 있습니다.
그러나 그들이 이러한 기능을 배포할 때, 개발자들은 실시간으로 새로운 트래픽 라우팅 규칙을 적용받지 못합니다.
그들은 네트워킹팀이 하드웨어 로드 밸런서를 재구성하는 것을 기다려야 하는데, 이는 많은 시간, 일, 심지어는 주 단위일 수 있습니다.
이는 기업 내에서 엄청난 마찰을 발생시키는데, 전통적인 Networking팀의 문제임이 명백함에도 불구하고 자신들의 기능과 관련성을 유지하기 때문입니다.

목차

1. 네트워크팀의 잘못이 아닙니다. 로드 밸런서의 문제입니다.
2. 소프트웨어 로드 밸런서를 통한 Agile 운영
3. L7으로 전환한다고 해서 L4 투자를 폐기하는 것은 아닙니다.
4. NGINX는 고객이 Agile 개발을 이행하도록 돕습니다.

1. 네트워크팀의 잘못이 아닙니다. 로드 밸런서의 문제입니다.

네트워킹팀이 데이터 센터로 들어오고 나가는 모든 트래픽에 대한 단일 실패 지점이 된 것은 그들의 잘못이 아닙니다.
이 문제는 적어도 10년 전으로 거슬러 올라갑니다.
즉 기존의 아키텍처가 애플리케이션의 빠른 확장을 방해하여 증가하는 소비자 수요를 충족시키지 못했던 시점입니다.
대부분의 기업들은 F5 BIG-IP과 같은 하드웨어 로드 밸런서를 솔루션으로 채택했는데, 이는 대량의 트래픽을 처리하고 데이터 센터에서 호스팅되는 모든 애플리케이션에 로드를 균형있게 분배할 수 있을 만큼 강력했습니다.

결과적으로, 많은 다른 애플리케이션들의 라우팅 규칙들이 모두 같은 장치에 배포되었고, 네트워킹팀은 규칙들이 서로 충돌하지 않도록 확인해야 했습니다.
새로운 또는 수정된 애플리케이션을 Production에 배포하기 전에 필요한 신중한 테스트와 QA를 수행하는 데 시간이 걸렸습니다.

하지만 시대가 변했습니다. 애플리케이션은 이제 확장을 위해 설계될 수 있고, 트래픽 라우팅 규칙은 애플리케이션 생명 주기의 일부로서 NGINX Plus와 같은 소프트웨어 솔루션에 배포될 수 있습니다.
새로운 규칙들도 계속적인 통합/계속적인 배포(CI/CD) 파이프라인을 통해 업데이트가 배포되는 것과 같습니다. 트래픽 라우팅 규칙에 대한 책임이 DevOps팀으로 이동했고, 이 변화는 진정한 Agile 개발과 배포를 가능하게 하고 있습니다.
이 소프트웨어 전용 개발은 Infrastructure 코드의 완벽한 예입니다.

2. 소프트웨어 로드밸런서를 통한 Agile 운영

소프트웨어 로드 밸런서를 사용하면, 팀들은 완전히 Agile 세계에서 작업할 수 있습니다.
DevOps팀 (개발 속도로 운영 변경을 수행하는 사람들)은 몇 초 만에 구성을 변경할 수 있습니다.
이는 소프트웨어의 진정한 Agile 개발과 배포로 완전히 이동하는 것을 가능하게 합니다. 무엇보다, 이는 전체 조직의 출시 시간을 줄여주는데, 이것은 CIO와 CEO들이 깊게 신경 쓰는 부분입니다.

3. L7으로 전환한다고 해서 L4 투자를 폐기하는 것은 아닙니다.

이미 하드웨어 로드 밸런서에 투자한 경우, 그것들을 버릴 필요는 없습니다. 많은 NGINX 고객들은 기본적인 패킷 처리나 심지어 SSL Termination를 위해 Edge에서 계속 사용하고 있습니다. 그러나 개발팀에게 Layer 7의 지능적인 트래픽 라우팅을 하드웨어 박스나 하드웨어 박스의 클라우드 버전에 적용하도록 강요할 필요는 없습니다. 그런 방법은 업데이트하는 데 몇 일이나 몇 주가 걸리기 때문입니다.

4. NGINX는 고객이 Agile 개발을 이행하도록 돕습니다.

몇 주 전, Agile 개발 원칙을 이전부터 채택한 대형 NGINX 고객 중 한 고객이, 새로운 라우팅 규칙을 구현하기 위해 티켓을 로깅해야 한다면 그들의 전체 DevOps팀이 일제히 그만둘 것이라고 말했습니다.

또 다른 고객은, 자신의 팀이 NGINX를 사용하여 몇 초만에 새로운 라우팅 규칙을 배포할 수 있다고 자부심을 내부적으로 표현하고 있었습니다.
그와 반대로 다른 사업 부서의 동료들은 하드웨어 로드 밸런서에 의존하고 있어 몇 주 동안 기다려야 했습니다. 오늘날 우리가 살고 있는 경쟁적인 세계에서 왜 개발팀의 속도를 늦추어야 할까요?

민첩한 전환은 단지 개발자들만의 문제가 아니거나 개발자와 운영팀만의 문제도 아닙니다.
조직 전체적으로 이루어져야 합니다. CIO들은 개발팀이 쉽게 해결할 수 있는 병목 현상을 인정해야 합니다.
오늘날의 비즈니스와 고객 서비스에서 점점 빨라지는 주기에 따라가기 위해서는 적어도 애플리케이션 수준의 변경을 위해 소프트웨어 로드 밸런서로 전환해야 합니다.

Agile 프로세스에서 병목 현상에 어려움을 겪고 있나요? 아니면 이미 유연한 인프라에 투자하여 Agile 개발을 지원하고 있나요? 그렇다면, 저희는 여러분의 이야기를 듣고 싶습니다. NGINX STORE에 연락하여 여러분의 의견을 공유해 주세요.

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