블로그

컨테이너에서 앱 확장 시 계층을 제거하기 위해 F5 BIG-IP 사용

로리 맥비티 썸네일
로리 맥비티
2018년 8월 2일 게시

아니면 좌절의 ‘눈물’인가? ¯\_(ツ)_/¯ 아마도 둘 다일 것이다.

 

네트워크와 애플리케이션 아키텍처 사이에는 관계가 있습니다. 일반적으로 우리는 애플리케이션 아키텍처의 변화와 전환이 솔루션과 아키텍처 측면에서 네트워크에 어떤 영향을 미치는지에 대해 이야기하고 싶어합니다. 하지만 그 반대도 사실입니다. 네트워크의 아키텍처와 동작은 애플리케이션과 해당 아키텍처에 상당히 극적인 영향을 미칠 수 있습니다.

즉, SOA 시절이 아니라 지금 모노리스가 여러 개의 마이크로서비스로 분해되는 이유 중 하나는 네트워크 때문입니다. 좀 더 정확하게 말하면, 네트워크 속도 때문입니다. SOA 시절에는 네트워킹의 특성(및 물리 법칙)으로 인해 3~4개가 넘는 서비스에서 단일 응답을 작성하는 것이 불가능했습니다. 글쎄요, 불가능한 것은 아니지만 각 통화에 걸리는 지연 시간 때문에 바람직하지 않습니다.

오늘날 우리는 더 빠르고 강력한 네트워크를 갖추고 있으며, 분해를 실현 가능하게 만드는 엄청나게 빠른 컴퓨팅을 갖추고 있습니다. 이를 더욱 쉽게 만드는 것은 컨테이너가 도넛과 커피처럼 마이크로서비스와 자주 결합되는 특성 때문입니다. 통신이 필요한 두 서비스 간의 "네트워크"는 종종 가상 구조이기 때문에(패킷은 실제로 호스트 서버를 떠나지 않으므로 "전선에 놓이는" 데 발생하는 지연이 발생하지 않음) 단일 요청에 응답하기 위해 호출할 수 있는 서비스 수는 SOA 시절에 합리적으로 달성할 수 있었던 것보다 훨씬 많습니다.

하지만 이는 요청에 응답하기 위해 통과해야 하는 연결과 홉의 수나 아키텍처가 애플리케이션 성능에 미치는 영향을 무시해야 한다는 의미는 아닙니다. 컴퓨팅이 더 빠르고 파이프가 더 굵어졌더라도 운영 오버헤드는 여전히 우리가 처리해야 할 문제입니다. 성능을 방해하는 요소. 운영 오버헤드를 처리하고 성능을 개선하는 가장 쉬운 방법 중 하나는 아키텍처에서 (불필요한) 계층을 제거하여 복잡성을 줄이는 것입니다.

컨테이너 환경의 복잡성 감소

대부분의 컨테이너 배포는 컨테이너 환경 내의 마이크로서비스/앱의 규모를 관리하기 위해 클러스터 내부에 어떤 유형의 로드 밸런서를 사용합니다. 그 이유는 이들이 종종 API의 L7 라우팅(이는 인그레스 제어)을 담당하고 기본 로드 밸런싱 구조가 iptables를 기반으로 하기 때문인데, 물론 iptables는 L7 라우팅 언어인 HTTP를 사용하지 않습니다. 클러스터 컨테이너 내부에는 여러 개의 L7 로드 밸런서가 있습니다.

이제 대부분의 배포에서는 클러스터 내부의 적절한 로드 밸런서로 외부 트래픽을 보내기 위해 클러스터 외부에서 로드 밸런싱이 필요합니다. 이를 위해 그들은 기존의 로드 밸런싱을 사용해 요청을 내부의 적절한 로드 밸런서에 분산시킵니다.

BIG-IP 외부의 로드 밸런서를 '내부 lb'라고 부르고, 클러스터 내부의 로드 밸런서를 ' 내부 lb'라고 부릅니다. 왜냐하면 이건 내 블로그이니까요.

문제는 내부 lb 인스턴스의 수가 (때로는 극적으로) 변동한다는 것입니다. 변화가 있을 때마다 BIG-IP가 알아야 합니다. 전통적으로 이는 수동 작업이어서 BIG-IP 소유자가 나가서 풀을 직접 수정해야 했습니다. 이는 개발자와 DevOps에게는 답답한 일이고, NetOps에게는 지루한 일입니다. 다시 말해, 누구도 이런 식으로 하기를 원하지 않습니다.

이것이 F5 컨테이너 커넥터 와 같은 솔루션이 존재하는 이유입니다. F5 컨테이너 커넥터는 컨테이너 오케스트레이터와 통합되고 환경을 관찰하는 컨테이너 네이티브 서비스입니다. 내부 lb에 영향을 미치는 변경 사항이 있으면 BIG-IP를 업데이트하는 프로세스가 트리거됩니다 . 즉, 수요가 변하든 변하든 BIG-IP는 자동으로 최신 상태로 유지되고 활성화되어 있고 건강한 내부 lb 에 요청을 적절히 분배할 수 있습니다. 수동으로 수정할 필요가 없습니다.

이 2계층 확장 아키텍처는 SSL/TLS를 종료할 수 있는 편리한 인바운드 위치(BIG-IP)를 제공하여 측정 가능한 성능 향상을 제공한다는 장점이 있습니다. 멋진.

하지만 거기서 멈추는 게 무슨 뜻일까요? BIG-IP는 L7 라우팅을 제공할 수 있습니다. F5 Container Connector의 서비스를 활용하면 내부 lb를 완전히 제거하여 성능을 더욱 향상시키고 운영 오버헤드를 줄일 수 있습니다. 정말. BIG-IP는 Kubernetes 및 Red Hat OpenShift에 대한 수신 컨트롤러 역할을 할 수 있습니다.

수신 책임을 BIG-IP로 옮기면 전체 계층의 규모( 내부 lb)가 제거되어 성능이 즉시 향상됩니다. 외부 lb 가 F5 BIG-IP 이므로 컨테이너 클러스터 내부가 아닌(또는 전혀 그렇지 않은) 접촉 지점에서 봇 방어 기능이 있는 고급 WAF와 같은 보안 중심 애플리케이션 서비스를 추가로 배포할 수 있습니다. 

클래시 오브 옵스 클랜스

컨테이너가 프로덕션에 더 자주 적용됨에 따라(그리고 그럴 것입니다) 이러한 종류의 개선 사항을 구현하고 앱의 확장성, 속도 및 보안을 보장하기 위해 DevOps와 NetOps 간의 협업이 더욱 중요해질 것입니다. 결국, 단순히 버튼을 누르고 셀프 서비스 파이프라인을 사용하는 것만이 아닙니다. 아키텍처는 DevOps와 NetOps의 의견을 반영하여 설계해야 하는 중요한 구성 요소입니다. 그렇지 않으면 애플리케이션 성능 등을 개선할 수 있는 기회를 무시하게 됩니다.

애플리케이션 성능은 팀 스포츠이기 때문입니다. 이는 코드(AppDev), 코드가 배포된 플랫폼(DevOps), 네트워크 아키텍처, 앱을 보호하고 확장하는 데 사용되는 애플리케이션 서비스(NetOps)의 영향을 받습니다. 가능한 경우 계층을 제거하여 아키텍처 최적화를 구현하는 것은 운영 및 사업 측면에서 합리적입니다. 하지만 그러기 위해서는 팀의 모든 선수의 참여가 필요합니다.

그러니 피자와 맥주를 주문하고 DevOps와 NetOps에 관해 이야기를 나눠보세요. 컨테이너 환경에서 불필요한 계층을 제거하여 앱 성능을 개선할 수 있는지 알아보세요.