애플리케이션 개발 과정에 ‘네트워크 전문가’가 꼭 필요한 이유

최근 필자가 대화를 나눈 47곳의 기업 중 하이브리드 클라우드를 사용하지 않는 곳은 단 한 곳도 없었다. 하지만 다른 클라우드 모델을 사용한 적 있는 기업과 “모든 것을 클라우드로 이전할 것”이라고 말한 기업 역시 모두 0곳이었다.

이는 하이브리드 클라우드가 얼마나 중요한지, 하지만 그것에 대한 이해는 얼마나 부족한지 잘 보여준다. 중요한 것을 잘 이해하지 못했다는 것은 좋지 않은 일이지만, 기업의 IT 기획 프로세스에 참여하려는 네트워크 전문가에게는 오히려 좋은 기회일 수 있다.
 

애플리케이션 개발 과정에 네트워크 전문가가 참여해야 하는 이유는 간단하다. 개발자는 기능과 호스팅 요구사항을 이해하고 IT 운영 담당자는 호스팅 및 비용 관리를 이해한다. 네트워크 전문가는 이 모든 것을 하나의 경험으로 묶는 워크플로우를 이해한다.

네트워크 전문가는 워크플로우에 초점을 맞춰 논의함으로써 해당 애플리케이션 아키텍처의 중요 영역, 애플리케이션이 수행하는 작업, 연결 방법, 비용을 결정하는 데 많은 기여를 한다. 하이브리드 클라우드에서는 이런 점이 더욱 분명하게 드러난다.

사용자를 왼쪽에 두고 하이브리드 클라우드 애플리케이션의 구조를 그려본다면 먼저 ‘클라우드’라는 원에 양방향 화살표를 그리고 해당 원에서 ‘데이터센터’라고 표시된 원(오른쪽)으로 연결되는 다른 화살표를 그리면 된다. 이것이 하이브리드 클라우드 애플리케이션의 일반적인 레이아웃이다. 

사용자(작업자, 파트너 또는 고객/잠재 고객 등)는 잘 설계된 GUI를 통해 클라우드와 상호작용한다. 애플리케이션의 클라우드 부분은 이런 상호작용을 트랜잭션으로 전환하여 데이터센터로 전송한다. 그곳에서 무언가(애플리케이션, 데이터베이스)가 결과를 생성하고, 그 결과는 클라우드 GUI를 통해 사용자에게 반환된다.

네트워크에 얽매이지 말고 상호작용이 생성하는 워크플로우에 대해 생각해 보자. 애플리케이션 설계와 구성요소는 워크플로우와 상호작용에 종속된다. 사용자에서 클라우드로, 또는 클라우드에서 데이터센터로의 상호작용을 제한하는 설계가 가장 비용 효율적인 최상의 설계다. 바로 이것이 클라우드 다이어그램에서 고려해야 할 중요한 부분이다. 

애플리케이션 개발 회의에 네트워크 전문가가 왜 참석해야 하며, 이들이 회의에서 어떤 점을 강조해야 하는지 살펴보자. 

사용자-클라우드 트래픽 최소화

사용자-클라우드 상호작용은 비용을 증가시키고 네트워크 연결을 복잡하게 하며, QoE(Quality of Experience)을 저하시킬 수 있다. QoE를 저하하지 않고 상호작용 수를 가능한 한 낮게 유지하는 것이 시작점이지만, 실제 과제는 막대한 비용 초과 위험을 감수하지 않고 클라우드의 이점을 극대화하는 것이다.

클라우드의 가치는 부하 상태에서 확장할 수 있고 실패한 구성 요소를 빠르게 교체할 수 있는 능력에 있다. 확장성의 일반적인 속성이다. 사용자와 연결되고 워크플로우를 처리하는 애플리케이션 구성요소에서는 확장성이 가장 중요하다. 확장성을 원한다면 작업을 분할하기 위해 일종의 로드 밸런싱이 필요할 수 있지만, ‘상태(state)’ 문제에 대해서도 생각해야 한다.

여기서 상태란 개발자가 말하는 ‘다단계 대화 상자에서 현재 위치’를 의미한다. 사용자는 거의 항상 클라우드와 다단계 상호작용을 하므로 메시지를 올바르게 처리하려면 어떤 단계에 있는지 파악하는 것이 중요하다. 개발자라면 각 대화 단계를 전용 마이크로서비스에서 처리하는 것을 자동으로 떠올린다. 하지만 이렇게 하면 구성요소의 수가 증가하고 클라우드 네트워크의 비용과 복잡성이 증가한다.

이에 대한 대안이 상태 제어다. 상태 제어는 사용자의 앱이나 클라우드 데이터베이스가 대화 상자 상태를 유지·관리한다. 즉, 단일 마이크로서비스가 여러 단계, 어쩌면 전체 대화 상자를 처리할 수 있고 여러 사용자가 각 마이크로서비스의 인스턴스를 공유할 수 있다. 이 모든 것이 마이크로서비스와 연결 수를 줄여 비용과 대기 시간을 줄인다.

이 문제에 대한 논의를 시작하는 가장 좋은 방법은 개발자에게 클라우드 내에서 워크플로우가 어떻게 연결되는지 매핑하도록 요청하는 것이다. 이런 과정에서 마이크로서비스와 연결의 수에 관한 문제를 신속하게 발견하고 2가지 문제를 모두 해결할 애플리케이션 설계 최적화 논의를 시작할 수 있다. 

개발자는 문제를 파악하고 해결 방법을 이해하는 속도가 빠르다. 그리고 이런 문제를 누가 처음에 지적했는지 기억할 것이다. 

MPLS 및 SD-WAN 사용 최적화

이제 데이터센터 측면을 살펴본다. 클라우드와 데이터센터 간의 관계에는 많은 옵션이 있으며, 대부분은 좋지 않다. 가령 클라우드 구성요소가 데이터센터에서 호스팅되는 데이터베이스를 ‘읽기’하면 많은 트래픽이 발생하게 돼 비용이 많이 들 뿐 아니라 액세스 지연이 발생하여 QoE가 매우 나빠질 수 있다. 대신 데이터센터에 필요한 모든 데이터베이스 작업 및 처리를 요청하는 단일 메시지를 보내고 결과만 다시 보내도록 할 수 있다.

하이브리드 애플리케이션 대부분은 특정 레코드 또는 레코드 세트(예 : 사용자의 관심사와 일치하는 제품)를 찾기 위한 ‘조회’를 데이터센터에서 먼저 수행한 다음, 하나의 레코드 상태(예 : 구매)를 변경하는 ‘업데이트’를 진행한다. 클라우드 데이터베이스를 사용하는 좋은 예는 사용자가 옵션을 탐색하는 동안 조회 결과를 보관하는 것이다. 이렇게 하면 추가적인 레코드를 위해 계속 데이터센터로 돌아갈 필요가 없어지므로 클라우드 서비스의 트래픽 요금이 발생하지 않고 클라우드와의 네트워크 연결을 부담하지 않으며, 누적된 지연을 줄일 수 있다. 업데이트가 이루어지면 변경 사항이 데이터센터로 전송된다.

데이터센터 워크플로우에서 나오는 질문 중 하나는 회사 VPN의 역할이다. 기업 모두 MPLS VPN을 사용하며, 때로는 SD-WAN VPN으로 보완하거나 대체한다. 데이터센터에 대한 연결은 VPN을 통해 이뤄지거나 인터넷에서 데이터센터로 직접 연결될 수 있다. 전자의 경우 VPN을 클라우드로 확장하거나(추가 비용 발생), 하나 이상의 원격 사이트 위치에서 클라우드 트래픽을 드롭하여 데이터센터로 다시 가져올 수 있다. 이는 일반적으로 클라우드 호스팅의 여러 지리적 영역이 있는 경우 선택할 수 있는 옵션이다. 워크플로우를 매핑하고 각 옵션의 비용과 지연 시간에 대한 기여도를 살펴보면 항상 최선의 답을 결정할 수 있다.

확장성 및 구성요소화 조정

마지막 단계는 사용자 상호작용과 데이터센터 상호작용을 연결할 클라우드 워크플로우를 정의하는 것이다. 이 단계에서는 ‘과도한 확장성’과 ‘과도한 구성요소화’에 주의해야 한다. 데이터센터의 데이터베이스에는 일반적으로 최대 트랜잭션 속도와 확장성에 대한 제한이 있다. 

잘 설계된 하이브리드 클라우드 애플리케이션 대부분은 사용자 측면에서는 확장성이 뛰어나지만, 데이터센터 연결로 갈수록 확장성이 떨어진다. 클라우드 구성요소 간의 워크플로우를 살펴보면 사용자와 연결된 클라우드 구성요소와 데이터센터와 연결된 클라우드 구성요소 사이의 과도한 확장성을 파악할 수 있다.

워크플로우는 모든 애플리케이션의 모든 측면을 공고히하므로 애플리케이션 개발 과정에서 네트워크 전문가의 역할은 워크플로우에 따라 결정된다. 각 워크플로우는 기업 예산에서 클라우드 서비스 제공업체, 소프트웨어 및 하드웨어 공급업체 및 네트워크 서비스 제공업체로의 현금 흐름을 의미한다. 각 워크플로우는 지연 시간을 늘리고 복잡성을 가중시키며, 개발 및 유지 관리 시간과 비용을 증가시킨다. 인터넷과 클라우드 내부에서는 연결이 암묵적으로 이루어지기 때문에 IT 전문가는 ‘잘 작동한다’는 이유로 워크플로우와 그 결과를 무시하기 쉽다.

하지만 네트워크 연결은 워크플로우를 수반하기 때문에 네트워크와 네트워크 전문가를 애플리케이션, 클라우드, 그리고 가장 중요한 공식적인 IT 계획에 연결한다. 그러니 네트워크 전문가들이여, 워크플로우 번들을 쥐고 자리에 앉을 준비를 하자.
editor@itworld.co.kr