클라우드가 처음 등장했을 당시, 많은 이들이 클라우드가 조직에 격변을 불러올 것이라고 예측했습니다. 많은 사람은 유형의 제품에서 거의 실체가 없는 제품으로 전환하기가 매우 어렵다는 점에서, 다가올 혼란이 기존 인프라 시장에 미칠 영향에 주목했습니다. 실제로 그 예측은 맞았으며, 인프라 시장이 클라우드를 염두에 둔 소프트웨어 중심의 관점으로 회귀하는 과정(혁신이 아니라 회귀라는 점에 유의하십시오)은 순탄치 않았습니다.
이러한 변화가 물리적 세계뿐만 아니라 비즈니스 세계에도 파괴적인 영향을 미친다고 지적한 전문가는 많지 않았습니다. 애플리케이션(및 API) 경제에서 성공하는 데 필요한 네트워크와 인프라를 구축하기 위해 클라우드와 소프트웨어 중심의 접근 방식을 도입하려면 비즈니스 모델도 전환해야 했습니다. 특히 라이선싱을 비롯해 수많은 네트워크 및 인프라 구성 요소를 관리하는 방식이 달라져야 했습니다.
단일 장비에 라이선스를 부여하는 일은 (상대적으로) 쉽습니다. 라이선스를 구매해 적용하면, 짜잔! 이제 여러분의 것이죠. 하지만 소프트웨어는 단 한 번도(정말 단 한 번도) 그렇게 간단했던 적이 없습니다. 여러분 중 일부는 2000년대 초반, 몇몇 소프트웨어 대기업이 수년간 사용해 온 단일 CPU 라이선스 모델에서 다중 CPU, 다중 코어라는, 이른바 ‘새로운 수학’으로도 쉽게 풀 수 없는 수학적 악몽으로 다소 다급하게 전환하려다 거센 논란을 불러일으켰던 일을 기억하실 겁니다.
클라우드에서도 같은 일이 벌어졌습니다. 사용량 기반 과금 모델 때문에 소프트웨어로 다시 전환하는 일은 단순히 가상 또는 클라우드 기반 하이퍼바이저에 맞게 코드를 조금 수정하는 것보다 훨씬 더 어려웠습니다.
이제 모든 것을 ‘지속적’으로 수행한다는 개념을 내세운 DevOps가 등장하면서, 라이선스는 네트워크 및 인프라 시장이 반드시 넘어야 할 중대한 장벽이 되었습니다. 문제는 네트워크 및 인프라 서비스를 갑자기 빠른 속도로 프로비저닝하고 구성해야 한다는 점뿐만 아니라 변화의 속도에도 있습니다. 과거에는 인프라 구성 요소를 배포하면 그대로 유지되었습니다. 하지만 이제는 수많은 인프라 구성 요소를 배포하며, 때로는 하루, 일주일 또는 한 달에도 여러 번 배포합니다. 변화의 빈도는 높아지고 있으며, 이러한 변화에 대한 요구는 필연적으로 네트워크 영역까지 확산되고 있습니다. 지속적 통합(CI)과 지속적 전달(CD)은 애플리케이션 개발 및 운영의 영역입니다. 하지만 지속적 배포에는 소프트웨어 배포의 전체 과정에 걸친 협업이 필요하며, 여기에는 프로덕션 환경도 포함됩니다.
해당 파이프라인의 초기 단계(프로덕션이 아닌 테스트 또는 QA 단계)에서 테스트하는 것은 빠른 배포뿐 아니라 안정적인 배포를 달성하는 데 매우 중요합니다. 즉, 네트워크 및 인프라 아키텍처의 차이로 인해 프로덕션 환경에서 문제가 발생해 개발자의 시간을 빼앗는 일이 없는 배포를 구현해야 합니다.
유연한 소프트웨어 중심의 라이선싱 접근 방식은 이러한 과제를 완화하는 동시에 프로덕션 네트워크에 필요한 민첩성을 높일 수 있습니다. 라이선스를 풀링하고 중앙에서 관리하며 API 호출만큼 간편하게 할당할 수 있는 수단을 제공함으로써 조직은 개발 환경과 프로덕션 환경을 동일하게 구성할 수 있으며(이는 안정성과 일관성에 중요함), 네트워크 및 인프라 플랫폼의 소프트웨어 버전을 사용할 때 프로덕션 환경에서 확장해야 하는 요구 사항도 충족할 수 있습니다.
이러한 이유로 BIG-IQ 5.0과 iWorkflow 2.0은 수천 개의 BIG-IP 인스턴스에 대한 애자일 라이선싱을 지원합니다. 라이선스가 부여된 인스턴스 자체가 아니라 라이선스를 관리할 수 있어야 한다는 점은 개발팀과 운영팀이 프로덕션 이전 배포 단계에서 더 일찍 통합하고 테스트할 수 있도록 하는 데 매우 중요합니다. BIG-IQ 5.0은 BIG-IP 관리에 중점을 두지만, 오늘날 DevOps가 만들어 가는 더욱 빠르고 민첩한 개발 환경을 지원하는 유연한 모델을 통해 최대 5,000개의 BIG-IP 인스턴스에 대한 라이선스도 관리할 수 있습니다. 이는 아키텍처가 진화하면서 로드 밸런싱과 같은 앱 서비스가 아키텍처의 일부로서 앱(및 마이크로서비스)과 더욱 긴밀하게 결합되고 외부에 덧붙이는 방식의 요소에서 벗어나고 있기 때문에 특히 중요합니다.
운영 방식과 비즈니스 모델 모두에서 클라우드가 본질적으로 가져온 혁신의 여파는 오늘날에도 계속되고 있습니다. 하지만 단순히 “코드를 VM/컨테이너에 넣는” 접근 방식만으로는 충분하지 않습니다. 클라우드가 도입했고 어쩌면 의도치 않게 가까운 미래의 표준으로 자리 잡게 한 변화된 비즈니스 모델에도 적응해야 합니다. F5 BIG-IP 5.0과 iWorkflow 2.0은 이러한 “방식”에 부합하도록 설계되었으며, 조직이 물리적이든 일시적이든 자체 데이터 센터에 이 기반을 도입할 때 필요한 앱 서비스를 신속하게 제공할 수 있도록 지원합니다.
작성자 소개
Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.
Lori Mac Vittie의 다른 블로그 게시물관련 블로그 게시물
성평등을 향한 여정: 사이버 보안 분야에서 성공적인 커리어를 개척하는 방법에 관한 Jenn Gile과의 Q&A
F5의 ‘성평등을 향한 여정’ 시리즈 네 번째 Q&A에서는 Rachael Shah와 NGINX 제품 마케팅 책임자 Jenn Gile이 사이버 보안 직종에 대한 오해를 바로잡고, 사이버 보안 분야의 성별 격차를 해소하기 위한 조언과 그 이점에 대해 이야기합니다.
TLS 검사에서 피터 파커 원칙 다루기
“큰 힘에는 큰 책임이 따른다.” 볼테르와 처칠도 이와 비슷한 말을 남겼지만, 이 문구는 스파이더맨 코믹스에서 벤 삼촌의 말로 가장 널리 알려져 있습니다. 물론 이 문구가 문화적으로 널리 통용되는 이유 중 하나는 TLS 검사를 비롯해 수많은 상황과 주제에 적용할 수 있기 때문입니다.
Venafi와 F5를 통한 머신 아이덴티티 보호
‘머신 아이덴티티’란 간단히 말해 자동화된 프로세스가 자신의 신원을 식별할 수 있도록 하고, 다른 자동화 시스템과 프로세스가 관련 리소스에 적절한 수준의 접근 권한을 부여하도록 하는 방법을 의미합니다. 이 개념 자체는 새로운 것이 아닙니다. 비교적 새로운 점은 이를 구현해야 하는 규모입니다.
마이너와 미니언: 데이터 유출만이 비용을 초래하는 것은 아닙니다
물론 데이터 유출은 더 큰 비용을 초래할 수 있고(적어도 지금은), 실패 사실을 세상에 드러낼 수밖에 없게 합니다(통지 의무가 있으니까요). 하지만 보안을 단순히 데이터 노출 문제로만 봐서는 안 됩니다. 요즘은 데이터가...
내 클라우드에서 나가!
F5의 Jay Kelley가 전하는 최신 소식에는 Microsoft Office 365용 신규 ID 및 액세스 솔루션을 배포할 때 고려해야 할 사항이 정리되어 있습니다.
Shift(웹 앱) 보안 레터
웹 앱 보안을 개발 초기 단계로 앞당기세요. F5 블로그에서 DevOps 파이프라인 초기에 보안을 통합하여 취약점을 예방하고 시간을 절약하는 방법을 알아보세요.