지금 컨테이너보다 더 주목받는 것이 있다면 아마 서버리스처럼 컨테이너를 기반으로 한 기술일 것입니다. 현재 가장 ‘핫한’ 기술일 뿐만 아니라, 현대 애플리케이션에서 자동화와 오케스트레이션*이 얼마나 중요한지를 잘 보여주는 핵심 분야이기도 합니다.
거의 매일 컨테이너 아키텍처에 새로운 구성 요소가 추가되고, 그에 걸맞은 수준의 자동화도 함께 이루어집니다. 컨테이너 환경에서 자동화할 수 있는 것은 무엇이든 자동화될 것입니다. 수많은 API와 구성/템플릿 기반 아티팩트에 대한 의존은 컨테이너 기반 환경에서 자동화가 거의 끊임없이 발전하도록 이끕니다. API 경제가 비즈니스의 디지털 트랜스포메이션에 중요하다면, 또 다른 API 경제는 IT의 디지털 트랜스포메이션에 필수적입니다.
컨테이너 환경도 예외는 아닙니다. 컨테이너가 프로덕션 환경에 계속 도입됨에 따라 업스트림(N-S) 서비스는 변동성이 매우 큰 이러한 환경 내에서 확장되고 제공되는 애플리케이션을 전달할 수 있어야 할 뿐만 아니라, 자동화 및 오케스트레이션 계층에서 컨테이너 환경과 통합되는 것이 점점 더 중요해지고 있습니다.
이는 이 기술 “스택”의 일부 계층이 다른 계층보다 변동성이 더 크기 때문입니다. 예를 들어 컨테이너의 생성과 삭제는 전체 클러스터의 생성 및/또는 삭제보다 훨씬 더 빈번하게 이루어집니다. 실제로 Data Dog HQ의 Docker 도입 현황 보고서에 따르면 “2017년 3월 기준, Docker를 실행하는 Datadog 고객 중 약 40%가 Kubernetes, Mesos, Amazon ECS, Google Container Engine 또는 다른 오케스트레이터도 함께 사용하고 있었습니다.” 자동화/오케스트레이션은 컨테이너의 성공에 매우 중요하며, 특히 핵심 영역에서 더욱 그렇습니다. 따라서 앞으로 나아가는 과정에서 일부 자동화 요구 사항은 가능한 한 신속하고 철저하게 충족되어야 합니다. 이러한 요구 사항이 다른 모든 것의 기반이 되기 때문입니다.
클라우드 환경에서도 마찬가지입니다. 자동화와 오케스트레이션의 필요성을 높이는 요인은 변동성뿐만 아니라 민첩성이기도 합니다. 클라우드 컴퓨팅과 관련된 복잡한 ‘셀프서비스’ 모델을 구현하려면 유틸리티 컴퓨팅 모델 내에서 탄력적이고 온디맨드 방식으로 운영되는 클라우드 컴퓨팅 아키텍처를 지원하는 자동화가 필요합니다. 클라우드와 컨테이너에 공통으로 적용되는 자동화 요구 사항을 명확히 파악하면 자동화가 비즈니스에 제공하는 가치를 이해하는 토대를 마련할 수 있습니다.
매슬로의 욕구 단계 이론과 마찬가지로, 자동화 욕구 단계는 성장을 가능하게 하는 상위 욕구로 나아가기 위해 먼저 충족되어야 하는 ‘결핍’ 욕구가 존재한다는 전제를 바탕으로 합니다.
더 높은 수준의 성장 욕구를 충족하는 단계로 나아가려면 먼저 낮은 수준의 결핍 욕구를 충족해야 한다. 결핍 욕구가 충족되면 그 욕구는 사라지고, 우리의 행동은 아직 충족하지 못한 다음 단계의 욕구를 충족하는 방향으로 자연스럽게 향하게 된다. 그러면 이러한 욕구가 우리의 주된 욕구가 된다. 그러나 성장 욕구는 계속해서 느껴지며, 일단 추구하기 시작하면 오히려 더 강해질 수도 있다. 이러한 성장 욕구가 어느 정도 충족되면 자아실현이라고 하는 가장 높은 단계에 도달할 수 있다. -- https://www.simplypsychology.org/maslow.html
본질적으로 이 자동화 욕구 단계는 애플리케이션과 이를 구성하는 서비스의 확장에 필요한 기본적인 요구 사항에 초점을 맞춥니다. 이 개념을 처음 소개한 뛰어난 F5 엔지니어의 설명은 다음과 같습니다. “하위 단계의 자동화는 가장 빈번하게 이루어지고 애플리케이션의 지속적인 가동에 필수적이므로 가장 가치가 높습니다. 반면 상위 단계의 자동화는 실행 빈도가 낮고(어쩌면 단 ‘한 번’뿐일 수도 있으며), 이미 많은 사람이 수동 작업을 수행하는 시점에 이루어지므로 가치가 가장 낮습니다.”

컨테이너/가상 머신 및 앱의 생성과 삭제를 자동화하는 것은 이러한 ‘기본적인’ 요구 사항에 해당하며, 단순한 확장뿐 아니라 확장의 효율성을 위해서도 매우 중요합니다. 이러한 효율성은 비용을 억제하고, 기존에 (비용이 많이 드는) 수작업 운영에 부과되던 확장 부담을 줄이는 데 중요합니다. 오늘날 이러한 이벤트가 발생하는 규모와 빈도를 고려하면 자동화는 있으면 좋은 것이 아니라 필수입니다. 이는 결핍 욕구에 해당합니다. 즉, 이 욕구가 충족되지 않으면 더 상위 단계에서 드물게 발생하는 자동화를 고민할 이유가 거의 없습니다.
이는 특히 컨테이너의 경우에 더욱 그러하며, Data Dog가 “컨테이너의 평균 수명은 2.5일인 반면, 전체 기업에서 기존 VM과 클라우드 기반 VM의 평균 수명은 23일이다”라고 언급한 내용으로 다시 한번 입증되는 듯합니다. 이는 자동화의 영향을 받는 것으로 보입니다. “오케스트레이터와 함께 Docker를 사용하는 조직에서는 일반적인 컨테이너 수명이 하루 미만입니다. 반면 Docker를 오케스트레이션 없이 사용하는 조직에서는 컨테이너의 평균 수명이 5.5일입니다.”
컨테이너와 그에 따른 애플리케이션의 생성 및 삭제를 자동화하는 역량은 조직이 기존 환경과 클라우드 기반 환경 모두에서 컨테이너의 이점을 누리는 데 필요한 확장 속도와 민첩성을 확보하기 위해 반드시 필요합니다.
상위 수준의 자동화 요구 사항은 대부분 라우팅과 관련되며, 이른바 성장 욕구에 해당합니다. 성장 욕구는 기본적(결핍) 욕구가 충족된 후에 추구됩니다. 클러스터 생성 및 제거와 라우팅 변경은 자주 발생하지 않으며, 애플리케이션이 구축되어 확장할 수 있게 된 후에야 가치를 발휘합니다. 환경이 개발/테스트 단계에서 프로덕션 환경으로 전환되고, 애플리케이션을 제공하여 비즈니스 가치를 창출하는 데 의존하게 되면 이는 필수적이 됩니다. 결국 응답할 수 없는 애플리케이션으로 라우팅하는 것은 굶주린 사람을 안아 주는 것과 같습니다. 따뜻하고 포근한 느낌만으로는 음식이라는 기본적인 욕구를 해결할 수 없습니다. Mesosphere가 사용자를 대상으로 실시한 2016년 설문조사에 따르면 응답자의 62%가 이미 프로덕션 환경에서 컨테이너를 사용하고 있었습니다. 컨테이너 중심 콘퍼런스인 DockerCon에서 실시된 Portworx의 2017년 설문조사에서는 응답자의 67.2%가 프로덕션 환경에서 컨테이너를 사용하고 있는 것으로 나타났습니다. 이는 적어도 컨테이너를 도입하는 조직들 사이에서는 라우팅 요구 사항의 중요성이 빠르게 커지고 있음을 의미합니다.

기업의 자아실현이 지향하는 궁극적인 목표인 성장은 전체 계층 구조가 충족될 때까지, 즉 전체 ‘스택’이 자동화되고 오케스트레이션될 때까지 달성할 수 없습니다. 따라서 주로 N-S 데이터 플레인에서 활동하는 조직은 상향식으로 오케스트레이션하여 먼저 환경의 확장 요구 사항을 충족한 다음, N-S 트래픽이 E-W 트래픽으로 전환되는 라우팅 요구 사항까지 단계적으로 해결해 나가야 합니다. 이는 Kubernetes와 같은 컨테이너 오케스트레이터를 중심으로 더욱 긴밀하게 결합된 에코시스템이 지속적으로 발전하고 있다는 점에서도 분명히 드러납니다. 최근에는 N-S에서 E-W 서비스로 원활하게 전환되도록 계층 7(URI/API)에서 라우팅하는 인그레스 컨트롤러를 도입하여 ‘라우팅’ 요구 사항을 해결하는 데 초점을 맞춘 발전이 이루어졌습니다. 이 구성 요소 역시 궁극적으로 통합(자동화)되어야 라우팅 요구 사항을 충족하고 조직이 계층 구조의 상위 단계로 계속 나아가 성장을 실현할 수 있습니다.
이를 컨테이너별 구성 요소로 변환하면 컨테이너 환경의 자동화 요구 사항을 성장에 필요한 확장을 지원하는 네트워크 서비스에 매핑할 수 있습니다. 컨테이너와 네트워크/애플리케이션 서비스 구성 요소 모두 자동화가 필요합니다. 애플리케이션을 확장하기 위해 컨테이너 100개를 생성하면서 제공 과정에서 이를 관리하는 서비스까지 동시에 자동화하지 않으면 요구 사항을 충족할 수 없습니다. 이러한 네트워킹 구성 요소는 컨테이너 네이티브 구성 요소로 구현하거나, 기존 애플리케이션 서비스를 컨테이너 환경에 자연스럽게 통합되도록 조정하여 구현할 수 있습니다. 구현 세부 사항은 아키텍처와 운영 요구 사항에 따라 달라지지만, 성공을 실현하려면 기본적인 요구 사항인 확장과 성장에 필요한 요구 사항인 라우팅을 충족할 수 있도록 두 유형의 구성 요소가 모두 필요합니다.
어떤 경우든 컨테이너와 클라우드의 성공은 해당 생태계에 크게 좌우되며, 이는 디지털 트랜스포메이션 이니셔티브를 통한 비즈니스 성장에 필수적인 자동화와 오케스트레이션을 구현하기 위해 또 다른 API 경제에 의존해야 한다는 의미입니다.
* 컨테이너 세계에서 자동화와 오케스트레이션이라는 개념이 서로 혼동되어 마치 같은 의미인 것처럼 뒤섞여 쓰이는 점이 답답하게 느껴진다. 하지만 지금은 일단 그 점은 무시하고, 내 안의 깐깐한 면은 있어야 할 곳에 가둬두도록 하겠다. 바로 내 머릿속에. 비명을 지르며. 필사적으로.
작성자 소개

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 파이프라인 초기에 보안을 통합하여 취약점을 예방하고 시간을 절약하는 방법을 알아보세요.