위험 대 보상: 소프트웨어 컨테이너 이해 가이드

우리 중 나이가 많은 사람은 소프트웨어가 주로 물리적 매체를 통해 전달되던 날을 기억할 수 있습니다. 광대역 인터넷과 스마트폰의 보급은 우리를 웹 서비스의 시대로 이끌었습니다. 즉, 브라우저 및 앱과 같은 사용자 클라이언트가 액세스하는 클라우드에서 호스팅되는 소프트웨어입니다.

얼마 전까지만 해도 웹 애플리케이션은 개인 데이터 센터의 물리적 시스템에서 직접 실행되었습니다. 관리 용이성을 위해 이러한 응용 프로그램은 일반적으로 모놀리식이었습니다. 단일 대형 서버에는 모든 백엔드 코드와 데이터베이스가 포함됩니다. 이제 Amazon과 같은 웹 호스팅 서비스와 하이퍼바이저 기술의 보급으로 모든 것이 바뀌었습니다. Amazon Web Services(AWS)와 VirtualBox와 같은 도구 덕분에 전체 OS를 단일 파일에 쉽게 패키징할 수 있게 되었습니다.

EC2와 같은 서비스를 사용하면 머신 이미지를 패키징하고 가상 서버 세트를 함께 묶는 것이 쉬워졌습니다. 마이크로서비스 패러다임이 등장했습니다. 소프트웨어 아키텍처에 대한 접근 방식은 대규모 모놀리식 앱이 한 가지를 잘 수행하는 소규모 집중 서비스로 나뉩니다. 일반적으로 이 접근 방식을 사용하면 병목 현상을 더 빨리 찾고 시스템 변경 사항을 더 쉽게 분리할 수 있으므로 확장 및 기능 개발이 더 쉬워집니다.

가축에 애완 동물

저는 이 트렌드의 정점에 있는 인프라 엔지니어가 되었습니다. 일련의 bash 스크립트를 사용하여 Amazon에서 첫 번째 프로덕션 환경을 구축했던 것을 기억합니다. 서버는 나에게 애완 동물과 같았습니다. 각각 귀여운 이름을 지어주었어요. 나는 그들을 주의 깊게 관찰했다. 나는 경보에 신속하게 대응하고 건강을 유지했습니다. 사랑하는 애완동물처럼 그것들을 대체하려고 애쓰는 것이 고통스러웠기 때문에 나는 그러한 경우들을 사랑과 애정으로 대했습니다.

구성 관리 도구인 Chef가 등장했고 거의 즉시 내 생활이 쉬워졌습니다. Chef 및 Puppet과 같은 도구를 사용하면 클라우드 시스템 관리와 ​​관련된 수작업의 고통을 대부분 없앨 수 있습니다. "환경" 구성을 사용하여 개발, 스테이징 및 프로덕션 서버를 분리할 수 있습니다. "데이터 백" 및 "역할"을 사용하여 구성 매개변수를 정의하고 변경 사항 세트를 푸시할 수 있습니다. 이제 내 "애완 동물"서버는 모두 순종 학교를 졸업했습니다.

그런 다음 2013년에 Docker가 등장했고 새로운 시대가 시작되었습니다. 가축으로서의 소프트웨어 시대입니다. 컨테이너 패러다임은 구성 관리가 아니라 오케스트레이션 중 하나입니다. Kubernetes, Docker Compose 및 Marathon과 같은 도구는 실행 중인 인스턴스의 구성 값을 조정하는 대신 사전 정의된 이미지를 이동하는 데 중점을 둡니다. 인프라는 변경할 수 없습니다. 컨테이너가 고장나면 고치려고 하지 않고 머리에 총을 겨누고 교체합니다. 우리는 개별 동물보다 무리의 건강을 더 중요하게 생각합니다. 더 이상 서버에 귀여운 이름을 지정하지 않습니다.

보상

컨테이너는 많은 것을 더 쉽게 만듭니다. 그들은 기업이 자신의 특별한 소스에 더 집중할 수 있도록합니다. 기술 팀은 인프라 및 구성 관리에 대해 덜 걱정하고 대신 대부분 앱 코드에 대해 걱정할 수 있습니다. 기업은 한 단계 더 나아가 MySQL, Cassandra, Kafka 또는 Redis와 같은 관리 서비스를 사용하여 데이터 계층을 전혀 처리할 필요가 없도록 할 수 있습니다. 기업이 인프라에 대해 걱정하지 않고 정교한 분석을 수행할 수 있도록 "플러그 앤 플레이" 기계 학습 서비스를 제공하는 여러 신생 기업이 있습니다. 이러한 추세는 팀이 단일 VM 또는 컨테이너를 관리하지 않고도 소프트웨어를 릴리스할 수 있도록 하는 소프트웨어 아키텍처 접근 방식인 서버리스 모델에서 정점에 달했습니다. S3, Lambda, Kinesis 및 Dynamo와 같은 AWS 서비스가 이를 가능하게 합니다. 비유를 확장하기 위해 우리는 애완 동물에서 가축, 일종의 주문형 동물 서비스로 이동했습니다.

이 모든 것이 매우 멋집니다. 열두 살짜리 아이가 클릭 몇 번으로 정교한 소프트웨어 시스템을 가동할 수 있는 시대에 살고 있다는 사실이 놀랍습니다. 얼마 전까지만 해도 이것이 불가능했다는 사실을 기억해야 합니다. 몇 년 전만 해도 물리적 미디어가 표준이었고 대기업만이 소프트웨어를 제조하고 배포할 수 있는 수단을 갖고 있었습니다. 버그 수정은 사치였습니다. 이제 그 12살짜리 아이는 AWS 계정을 만들고 자신의 소프트웨어를 전 세계에서 사용할 수 있게 만들 수 있습니다. 버그가 있는 경우 누군가 Slack에서 버그를 수정하고 몇 분 안에 모든 사용자를 위한 수정 사항이 제공됩니다.

위험

매우 훌륭하지만 가격이 만만치 않습니다. Amazon과 같은 클라우드 제공업체에 대한 의존은 대기업과 독점 기술에 대한 의존을 의미합니다. Richard Stallman과 Edward Snowden이 그런 일에 대해 걱정하게 만들지 않았다면 최근 Facebook과 관련된 재앙은 확실히 있어야 합니다.

하드웨어에서 더 멀리 추상화하면 투명성과 통제력이 떨어질 위험이 있습니다. 수백 개의 컨테이너를 실행하는 시스템에서 문제가 발생하면 감지할 수 있는 곳에서 오류가 발생하기를 희망해야 합니다. 문제가 호스트 운영 체제 또는 기본 하드웨어에 있는 경우 확인하기 어려울 수 있습니다. VM을 사용하면 20분 안에 해결할 수 있는 중단이 올바른 도구가 없는 경우 컨테이너로 해결하는 데 몇 시간 또는 며칠이 걸릴 수 있습니다.

Docker와 같은 문제에 대해 걱정해야 하는 것은 실패뿐만이 아닙니다. 보안 문제도 있다. 우리가 사용하는 컨테이너 플랫폼이 무엇이든 백도어나 공개되지 않은 보안 취약점이 없다는 것을 믿어야 합니다. 오픈 소스 플랫폼을 사용하는 것도 안전을 보장하지 않습니다. 시스템의 일부에 대해 타사 컨테이너 이미지에 의존하는 경우 취약할 수 있습니다.

마무리

가축 패러다임은 여러 가지 이유로 매력적이지만 단점이 없는 것은 아닙니다. 전체 스택을 컨테이너화하기 위해 서두르기 전에 기술 팀은 올바른 선택인지 여부를 생각하고 부정적인 영향을 완화할 수 있는지 확인해야 합니다.

개인적으로 컨테이너 작업을 좋아합니다. 새로운 플랫폼과 패러다임이 등장함에 따라 향후 10년 동안 상황이 어디로 갈지 기대됩니다. 하지만 전직 보안 컨설턴트로서 모든 일에는 대가가 따른다는 것을 알기에 충분히 조심스럽습니다. 사용자 및 개발자로서의 자율성을 포기하지 않도록 주의를 기울이는 것은 엔지니어의 몫입니다. 세상에서 가장 쉬운 CD/CI 워크플로라도 비용을 들일 가치가 없습니다.