우리는 애플리케이션 아키텍처에 있어서 중요한 전환의 와중에 있습니다. Cisco(글로벌 클라우드 지수)에 따르면: 2016~2021년 사이에 새로운 앱 워크로드 인스턴스의 85%가 컨테이너 기반이었습니다. 즉, API 중심, 마이크로서비스 원칙에 크게 의존하는 최신 앱 아키텍처를 사용하여 설계 및 개발되고 있음을 의미합니다. 이러한 아키텍처는 인터넷이 안정적인 비즈니스 수단으로 등장한 이래로 애플리케이션 분야를 지배해 온 기존의 3계층 웹 아키텍처와는 현저히 다릅니다.
하지만 전통적인 응용 프로그램도 사라지지는 않을 것입니다. 연구에 따르면 기존(레거시) 애플리케이션의 수명이 다른 직업보다 길어 20년에 달한다고 합니다. 실제로 BMC의 조사에 따르면 응답자의 51% 이상이 데이터의 절반 이상을 메인프레임에 저장하고 있는 것으로 나타났습니다. 응답자들은 거래량(59%), 데이터 양(55%), 애플리케이션 변경 속도(45%)가 증가했다고 추가로 밝혔습니다.
이러한 아키텍처는 기술 선택을 포함한 여러 가지 특성에 따라 구분됩니다.
기존 앱은 웹 서버, 앱 서버, 관계형 데이터베이스에 의존합니다. 최신 개발을 위해서는 컨테이너, 앱 엔진, NoSQL 데이터베이스가 적합합니다. 기존 앱은 주로 온프레미스에 상주하며 공유 리소스를 활용합니다. 최신 앱은 클라우드에 있으며 앱 전용 리소스가 제공되기를 기대합니다.
또한 모든 앱이 보안을 강화하고, 가용성을 보장하고, 성능을 개선하기 위해 의존하는 서비스를 제공하는 데 사용되는 아키텍처에서도 대조를 발견했습니다. 명확히 하자면, 이러한 격차는 실제로 애플리케이션 서비스 사용에 따른 것이 아니라 그러한 애플리케이션을 제공하는 플랫폼의 효율성에 따른 것입니다.
2019년 애플리케이션 서비스 현황 에 따르면 디지털 전환에서 가장 바라는 결과는 효율성입니다. 조직의 70%가 경쟁 우위(46%)나 새로운 사업 기회(45%)와 같은 '유행어 빙고'적 이점보다 IT 최적화(효율성)를 꼽았습니다. 2019년 CIO 현황 조사에 따르면, 응답자의 40%가 올해 IT 투자를 촉진하는 가장 중요한 이니셔티브로 운영 효율성 증대를 꼽았습니다.
효율성이 중요합니다. 문제는 전통적 건축과 현대적 건축 사이의 격차와 함께 효율성을 정의하는 방식에도 격차가 생긴다는 것입니다.
기존의 전송 아키텍처는 연결당 비용과 같은 거래 가치를 기반으로 효율성을 측정합니다. 시스템은 공유 인프라와 리소스를 전제로 구축되었으며, 이를 통해 애플리케이션 서비스를 제공하는 데 필요한 안정성과 확장성이 뛰어난 플랫폼이 필요했습니다. 단일 애플리케이션 제공 플랫폼은 평균 130개가 넘는 다양한 애플리케이션에 대한 게이트웨이 역할을 합니다. 효율성은 연결당 비용(용량)에 따라 결정되며, 일반적으로 낮을수록 좋습니다. 높은 용량을 달성하는 한 복잡성은 허용됩니다.
오늘날의 클라우드 네이티브 및 컨테이너 기반 애플리케이션 접근 방식은 모놀리식 이전 제품과 동일한 보안 및 확장성을 필요로 하는 "애플리케이션"의 폭발적 증가를 나타냅니다. 단일 애플리케이션이 더 이상 수백만 개의 연결로 확장될 것으로 기대되지 않습니다. 오히려 그 수백만 개의 연결은 수백 개(또는 수천 개)의 소규모 애플리케이션에 분산될 것입니다. 애플리케이션 서비스는 수백만 개의 연결로 확장할 필요가 없습니다. 왜냐하면 "애플리케이션"은 더 이상 수직적으로 확장되지 않고 수평적으로 확장되기 때문입니다. 각각은 전체 연결에서 아주 작은 부분만을 담당합니다. 따라서 해당 연결을 분산시키는 애플리케이션 서비스도 그렇게 높은 용량을 필요로 하지 않습니다.
그 대신, 효율성은 단순성과 속도를 기준으로 측정됩니다. 디지털 경제에 대한 증가하는 욕구를 충족시키려면 빠르고 빈번한 변화가 필요합니다. 2017년 SDxCentral 컨테이너 및 클라우드 오케스트레이션 보고서에 응답한 사람 중 무려 62%가 "더 빠른 스핀업 및 스핀다운" 속도를 위해 컨테이너를 배포합니다. 거의 절반(47%)이 관리가 더 쉬워서 컨테이너를 배포합니다. 따라서 애플리케이션 서비스는 현대적 아키텍처 내에서 쉽고 빠르게 획득, 배포, 운영될 수 있어야 합니다. 이것이 오픈소스가 CI/CD 툴체인을 장악하고 NGINX가 많은 개발자와 DevOps 커뮤니티에 매력적인 도구가 되는 이유입니다.
현대적 배송 플랫폼은 기존 아키텍처에서는 그다지 효율적이지 못하고, 기존 배송 플랫폼은 현대적 아키텍처에서는 그다지 효율적이지 않습니다. 특히 애플리케이션 보안을 살펴보면 이러한 사실이 분명하게 드러납니다. 애플리케이션 보안은 주로 외부(공개) 공격이 애플리케이션, 서버, 데이터 소스에 도달하는 것을 방지하도록 설계되었습니다. 효과적이고 효율적인 애플리케이션 보안은 공격 출처에 가능한 한 가까운 곳에서 이루어집니다. 공격이나 악성 페이로드가 애플리케이션에 감지될 때는 보통 너무 늦습니다. 자원이 소모되었습니다. 악성코드가 전달되었습니다. 악성코드는 이미 그 자체로 침투했습니다.
아키텍처 측면에서 볼 때, 이는 일반적으로 애플리케이션 보안이 기존(NS) 아키텍처에 가장 효율적으로 배포되어 악성 트래픽이 두 가지 환경(즉, 현대적이든 기존이든)에서 실행되는 애플리케이션에 도달하는 것을 방지한다는 것을 의미합니다.
간단히 말해서, 이는 NGINX 인수 로 채우고자 하는 기존의 아키텍처적 격차를 요약한 것입니다. 고객은 자체 효율성 방정식을 충족시키기 위해 기존 및 현대적 딜리버리 아키텍처에 대한 옵션이 필요합니다. 우리는 고객이 기존(NS) 아키텍처와 최신(EW) 아키텍처 간의 격차를 메울 수 있도록 하기 위해 두 가지 모두 필요하다고 생각합니다.
오늘날 두 아키텍처 모두 기업이 디지털 역량을 더 빠르고 빈번하게 제공하는 데 성공하는 데 유효하고 필요하며, 가장 중요한 점은 가장 가치 있는 자산, 즉 여러 세대에 걸친 애플리케이션 포트폴리오를 지원하는 가장 효율적인 방식으로 지원한다는 것입니다. 우리는 이제 전통적 및 현대적 서비스 아키텍처의 장점을 결합하여 이러한 격차를 메울 때가 왔다고 믿습니다.
F5와 NGINX를 결합하는 것의 이점에 대해 자세히 알아보려면 F5 CEO가 소개한 'Bridging the Divide' 블로그 시리즈 게시물을 확인하세요.