운영의 상품화

옛날에는 자동차의 변속장치가 수동이었습니다. 어떤 사람들은 기어를 바꾸는 장치 덕분에 이것을 "스틱"이라고 부를 수도 있습니다. 그 당시 자동 변속기는 종종 주문해야 하는 특별한 것이었습니다. 그 이름은 자동차가 자동으로 기어를 바꿔주는 방식에서 유래되었습니다. 솔직히 말해서 꽤 괜찮은 것 같아요. 결국, 수동으로 기어를 바꾸려고 할 때는 관리해야 할 변수가 많이 있습니다. 

오늘날에는 자동 변속기가 표준입니다. 대부분의 사람들에게 매뉴얼은 미스터리입니다. 나는 세 명의 가장 나이 많은 자녀에게 모두 자동차를 운전하는 법을 가르치려고 노력했습니다. 만약 당신이 그것을 시도하는 것을 고려하고 있다면, 나는 그것을 권장하지 않습니다. 자동차에 변속기가 제대로 작동하는 걸 좋아한다면 그럴 필요가 없습니다. 

저는 운영에 대한 논의에 앞서 기대와 기준의 이러한 변화를 언급하겠습니다. 주로 네트워크 및 애플리케이션 서비스 인프라에 적용되지만 해당 영역 외부에도 적용됩니다. 

운영상의 기대 

이러한 변화는 자동화를 향한 것이지만, 인프라를 운영하는 데 필요한 지식과 관련된 기대의 변화이기도 합니다. 

제가 예로 들었던 변속 장치 비유로 돌아가면, 수동 변속 장치를 운전한다면 관리해야 할 변수가 많습니다. 클러치와 가스의 조화를 맞춰야 합니다. 엔진 소리를 듣고 언제 기어를 바꿔야 할지 알아야 합니다. 또한 어떤 기어를 사용하고 있는지, 어떤 기어로 갈 것인지, 그리고 그곳에 도달하기 위해 "스틱"을 어떻게 움직여야 하는지도 알아야 합니다. 

이는 네트워크 및 애플리케이션 서비스 인프라를 수동으로 배포하는 데 필요한 지식 종류를 반영합니다. 트래픽이 한 장소에서 다른 장소로 전달되도록 하려면 네트워크가 어떻게 작동하는지에 대해 많은 것을 알아야 합니다. 

클라우드 도입으로 이러한 '표준'으로부터 기대가 벗어나는 전환이 시작되었습니다. 여전히 기본적인 네트워킹 개념을 이해해야 하지만, 반드시 그 개념이 어떻게 작동하는지 이해할 필요는 없습니다. 컨테이너가 도입되면서 IP 주소를 생각할 필요조차 거의 없게 되면서 기대 수준은 더욱 높아졌습니다. 

이로 인해 운영상의 기대치가 바뀌게 됩니다. 우리는 전문가 중심의 운영 경제에서 상품화된 운영 경제로 이동하고 있습니다. 오늘날, 네트워크와 애플리케이션 서비스 인프라를 구축하는 운영 측면은 조직 내의 더 다양한 역할자들이 접근할 수 있을 것으로 기대됩니다. 목표에 도달하려면 단순화가 필요합니다. 

구체적으로 말하면, 운영을 단순화하는 것입니다. 셀프 서비스 옵션을 통해 네트워크 및 애플리케이션 서비스를 제공하는 것만으로는 충분하지 않습니다. 이를 활용할 사람이 사용할 수 있어야 합니다. 지금보다 더 간단해져야 합니다. 

이는 조작성을 위해 구성 가능성을 희생해야 한다는 것을 의미할 수 있습니다. 

구성 가능성 대 작동성 

클라우드와 컨테이너와 마찬가지로, 네트워크와 애플리케이션 서비스 인프라 위에 놓인 추상화는 해당 추상화의 사용으로 확장됩니다. 제가 말하는 건 속어입니다. 용어 데이터 모델 실제 구성 . 

프로그래머가 아닌 사람들을 위해 제가 말하고자 하는 것은 각 구성 요소에는 "객체"를 구성하는 연관된 속성이 많이 있다는 것입니다. 가상 서버 객체에는 IP 주소, 애플리케이션 풀, 이벤트, 이름 및 기타 여러 특성이 있습니다. 이러한 특징 중 일부는 실제로 객체이거나 객체 목록입니다. 이러한 구조를 탐색하는 것은 복잡할 수 있습니다. 인프라를 미세 조정할 때는 구성 가능성이 필수적이기 때문입니다. 성능이나 용량을 최적화하려면 Nagle 알고리즘을 전환하거나 TCP 창 크기를 변경하는 등 매우 구체적인 특성을 조정할 수 있는 기능이 필요합니다. 

이제 상품화된 운영 모델에서 - 우리가 나아가고 있는 방향이기도 한데 - 구성 가능성보다 운용성이 더 중요합니다. 옵션은 적고 가동 시간은 빠릅니다. 

하지만 이는 단순히 선택권을 없애는 것을 의미하지는 않습니다. 단순히 옵션 조정 기능을 제거하는 것은 작동성에 대한 기본적인 요구 사항을 충족할 뿐이며, 단순화된 작동 경험에 대한 기대에는 부응하지 못합니다. 여전히 객체 모델을 이해해야 합니다. 필요한 것은 모델을 좀 더 간단한 것으로 추상화하는 것입니다. 가상 서버를 IP 주소, 이름, 애플리케이션 인스턴스 목록으로 줄여 보겠습니다. 

상품화에는 표준화가 필요하다

이것은 애플리케이션 서비스 인프라가 운영되는 공통 모델이 없기 때문에 중요한 프로젝트입니다. 가상 서버, 유입 제어 및 보안 정책이 표현되는 방식은 제품마다, 서비스마다 다릅니다. 

개발 측면이든 IT 측면이든 운영 부서는 평균 14개의 애플리케이션 서비스를 배포하고 운영하기 위해 다양한 모델을 이해하는 것이 필요합니다. 이 서비스는 앱을 제공하고 보안하는 데 사용됩니다 . 과거에는 이러한 서비스를 관리하는 데 필요한 전문성을 검증하는 데 필요한 수많은 자격증이 필요했을 만큼 변화가 많았습니다. 

또 다른 운영상의 변화는 이런 접근 방식에서 벗어나는 것 입니다. 이는 장치별 운영 모델로 인해 발생하는 기술적 부채를 줄이는 방법으로 단순성, 사용 편의성 및 제품 전반의 공통성에 대한 기대입니다. 이는 표준화 에 대한 기대이며, 네트워크 인프라 분야에 이미 존재하는 프로토콜이나 네트워크 동작에 대한 기대는 아닙니다. 하지만 우리가 해당 프로토콜과 네트워크 동작을 어떻게 표현하는지 에 대해서는.

컨테이너화에 대한 설문 조사 에서 이러한 현상이 나타나는 것을 확인할 수 있는데, 응답자 4명 중 1명(24%)이 필수 기술을 도입의 주요 저해 요인으로 꼽았고, 33%는 중간 정도의 저해 요인이라고 답했습니다. 컨테이너와 컨테이너 오케스트레이션 시스템이 오늘날 프로덕션 환경에서 널리 사용되고 있는 인프라는 기술 부족과 상품화된 운영에 대한 속도에 대한 욕구로 인해 주도되고 있습니다. 

그러한 욕구와 필요는 해당 인프라 서비스를 설명하려는 Kubernetes 리소스 파일의 자연스러운 채택에서 드러납니다. 이러한 리소스는 모든 운영에 주어진 서비스의 배포 및 구성을 설명하는 데 공통된(상품화된) 데이터 모델(형식)을 사용하도록 강제합니다. 오늘날 IT 운영이 조직에서 컨테이너 도입을 이끄는 가장 큰 요인(35%)이라는 점을 고려하면( Diamanti의 2019년 컨테이너 도입 설문 조사 기준) 개발자(16%)보다 거의 2배, 통합 DevOps팀(9%)보다 4배나 영향력이 큽니다. 따라서 이러한 변화를 인식하고 새로운 인프라가 상품화된 운영 환경에 어떻게 들어맞는지(또는 들어맞지 않는지) 신중하게 고려하는 것이 중요합니다. 

공식적인(작업반이나 재단) 노력이 있든 없든, 상품화를 통해 사실상의 표준이 운영에 도입될 것입니다. 그리고 사실상의 표준은 구성 가능성 보다 조작성을 강조하는 표준이 될 것입니다.