단일 유리창의 신화

제가 기억하는 한 - 그리고 꽤 오랜 시간 동안 - 인프라를 살펴보고 운영할 수 있는 단일 창구라는 사이렌 소리가 IT를 유혹해 왔습니다. 성배처럼 이것은 결코 발견되지 않았으며 많은 IT 전문가들은 이것의 존재에 대해 냉소적인 태도를 취했습니다.

디지털 혁신으로 인해 이러한 신화적인 관리 구조는 종식되고 대신 단일 통제 평면이라는 새로운 구조가 탄생했습니다.

좋은 소식은 과거의 대담한 IT 탐험가들이 추구했던 단일 창구와 달리 단일 제어 평면이 이제 우리 손 안에 들어올 수 있다는 것입니다. GUI가 아닌 API를 기반으로 하기 때문이죠.

그냥 API가 아니라 선언적 API입니다.

그 이유를 알아보려면, "인프라 2.0"이라는 용어가 유행했던 2010년으로 돌아가 보겠습니다.

아키텍처의 가장 최하위 계층은 Infrastructure 2.0 입니다. 인프라 2.0은 네트워크와 애플리케이션 전송 네트워크 인프라 전반에서 역동성과 협업을 활성화하는 데 중점을 두고 있습니다. 이는 전통적으로 통신 및 관리 관점에서 분리되어 있던 데이터 센터의 기반 구성 요소에 연결하고 협업할 수 있는 기능을 부여하는 방식입니다. 이는 주로 다양한 프로그래밍 방식(오케스트레이션 시스템, 사용자 정의 애플리케이션 또는 기존 데이터 센터 관리 솔루션과의 통합)을 통해 호출할 수 있는 세부적인 운영 기능 세트를 제공하는 개방형 표준 기반 API를 통해 달성됩니다. 인프라 2.0은 관리와 런타임(실행) 관점에서 모두 네트워크를 더욱 스마트하게 만드는 것이지만, 클라우드와 서비스로서의 IT 와의 관계에서는 주로 관리에 초점을 맞춥니다.

인프라 2.0에는 라우터에서 스위치, 로드 밸런서에서 애플리케이션 가속 , 방화벽에서 웹 애플리케이션 보안 구성 요소, 서버(물리적 및 가상) 인프라에 이르기까지 모든 것의 서비스 활성화가 포함됩니다. 핵심적인 본질은 API 지원 구성 요소입니다.

출처 < https://devcentral.f5.com/articles/infrastructure-20-cloud-it-as-a-service-an-architectural-parfait >

익숙한 내용인가요? 우리는 더 이상 이를 인프라 2.0이라고 부르지 않습니다. "지속적인 배포"와 "자동화" 및 기타 DevOps 유형 용어로 부릅니다. 하지만 개념은 똑같습니다. 이 아이디어에는 "단일 유리창"이 결코 실현되지 않은 이유가 내재되어 있습니다. 그러한 신화적 구성이 존재하려면 단일 솔루션에 다양한 네트워크, 애플리케이션 서비스 및 보안 솔루션을 통합(수동 방식으로 통합)해야 합니다.

그런 일은 결코 일어나지 않을 겁니다.

솔직히 말해서, 대부분의 인프라가 API를 지원 하더라도 그런 일은 절대 일어날 수 없었습니다. 왜? 모든 API가 필수적이었고, GUI와 마찬가지로 각 장치의 개체 모델과 밀접하게 결합되어 있었기 때문입니다. 명령형 API는 본질적으로 장치/서비스별 개체 모델에 묶여 있어서 이를 사용하려는 사람에게 운영 전문 지식에 대한 큰 부담을 줍니다. 이제 여러 공급업체의 라우터, 스위치, 보안 장치 및 다섯 가지 범주의 애플리케이션 서비스를 운영적으로 관리 할 수 있는 IT 조직의 모든 분야를 아우르는 담당자를 상상해 보세요.

정확히. 이런 생물은 빅풋과 같다. 종종 들어보지만, 실제로 존재한다는 것이 증명된 적은 없습니다.

그 말은 무슨 뜻인가요? 제 말은 이겁니다:

예를 들어, 우리가 풀이나 VIP(가상 IP 주소), 또는 VLAN(가상 LAN)을 표현하는 방식은 Cisco , Citrix 또는 Juniper가 동일한 네트워크 객체를 표현하는 방식과 다릅니다. 실제로, 우리의 용어도 다를 수 있습니다. 우리는 풀(pool)을 사용하고, 다른 ADC 공급업체는 같은 개념을 나타내기 위해 "팜(farm)"이나 "클러스터(cluster)"를 사용합니다. 가상화까지 추가하면 또 다른 용어가 추가되는데, 이는 종종 네트워크 인프라 공급업체가 사용하는 용어와 충돌합니다. " 가상 서버 "는 VMWare 나 Microsoft 와 같은 가상화 공급업체에서 사용하는 경우와 애플리케이션 제공 공급업체에서 사용하는 경우 완전히 다른 의미를 갖습니다.

출처 < https://devcentral.f5.com/articles/making-infrastructure-20-reality-may-require-new-standards >

이것이 우리가 단 한 장의 유리창처럼 좋은 것을 가질 수 없는 이유입니다. 왜냐하면 이 산업은 인프라를 살펴볼 수 있는 단일한 창문을 갖고 있지 않기 때문입니다.

하지만 이 글은 여러분을 우울하게 만들거나 영원히 기기별 관리로 훼손된 IT 업계의 길로 인도하기 위해 쓰여진 것이 아닙니다. 그 반대로. 선언적 - 진정한 선언적 API는 단일 제어 평면으로 이어질 수 있습니다.

하지만 그렇게 하려면 선언적이라는 개념이 장치 구성을 JSON이나 YAML로 인코딩한다는 의미에서 벗어나야 합니다. 이는 여전히 장치별 개체 모델에 연결된 운영 도메인 전문 지식에 의존하기 때문에 진정한 선언적이라고 할 수 없으며, 다른 사람은 이를 수집하여 사용할 수 없습니다.

선언적 모델의 예로 Kubernetes Service 및 Endpoint 리소스 설명을 사용해 보겠습니다.

가상 서버를 구성하는 데 필요한 모든 것이 이 매우 간결하고 구현에 독립적인 정의에 들어 있습니다. 외부 IP 는 가상 IP 주소, 즉 사용자나 모바일 앱이 통신할 주소입니다. "my-Service"라는 이름은 가상 서버를 설명하며, 사양 에서는 사용할 포트 와 사용할 풀("MyApp")과 같은 네트워크 세부 정보를 제공합니다. Endpoint 리소스는 "my-service"를 구성하는 각 노드를 설명하고 "MyApp" 풀에 대한 멤버를 제공합니다. 여기서 빠진 것은 라운드 로빈 이상의 작업을 수행할 수 있는 서비스에 대한 부하 분산 알고리즘을 선택하는 방법뿐입니다.  그리고 우리는 서비스 설명의 " 사양 " 부분을 쉽게 확장하여 "알고리즘"을 포함할 수 있습니다. 모든 로드 밸런싱 솔루션에 보편적으로 적용 가능한 "RR | WRR | LC | FR" 옵션입니다. 거기. 완료.

이론상, 이 동일한 리소스를 10개의 서로 다른 부하 분산 솔루션 중 하나에 공급할 수 있으며, 각 솔루션은 설명의 의도를 모델링하고 구현하는 방법을 결정할 것입니다. 설명의 의도는 80.11.12.10 포트 80에 위치한 가상 서비스를 구성하여 HTTP 요청을 포트 80의 1.2.3.4와 2.3.4.5에 위치한 두 개의 애플리케이션 인스턴스로 확장하는 것입니다.

이 문제를 생각해 볼 수 있는 또 다른 방법은 "페퍼로니 피자를 주세요"와 더 지루한 "피자 반죽을 섞은 다음 직경 10인치의 원형으로 펴주세요"의 차이입니다. 토마토 소스를 얹으세요. 모짜렐라 치즈를 얹고, 그 위에 페퍼로니를 얹으세요. 425도에서 15분간 굽습니다."

이런 것들 중 하나는 더 쉽지만 세부 사항을 알아내기 어렵게 만듭니다. 다른 하나는 당신이 원하는 것이 무엇인지(페퍼로니 피자) 뿐만 아니라 그것을 만드는 방법도 알아야 합니다. 바로 운영 전문성이죠.

피자를 주문하는 것처럼 Kubernetes 리소스 설명은 일반적입니다. 여기에는 리소스를 수집하는 장치에 특정 개체 모델이나 구현 방법을 강제하는 내용은 없습니다. 이는 무엇이 존재해야 하는지 설명하지만, 그것을 어떻게 구현해야 할지에 전혀 영향을 미치지 않습니다.

진정으로 선언적이란 의도 와 원하는 최종 상태를 전달하는 수단을 제공한다는 의미입니다. 언젠가는 "내 앱에 대한 가상 서비스를 구성하세요"라고만 말하면 되는 날이 올 겁니다! 메타데이터와 애플리케이션 태그, 자동화된 지능형 검색을 사용하여 서비스는 처음부터 끝까지 자체적으로 구성됩니다*. 

단일 제어 평면의 이상향에 도달하려면 우리는 힘을 합쳐 중립적인 선언적 사양을 고안해야 하며, 이를 통해 데이터 센터의 모든 장치를 명령형 API로 통합할 필요가 없습니다. 사실 기기별 API 통합은 기기별 관리와 크게 다르지 않습니다.

우리는 좋은 것을 원해요. 우리는 통일된 단일 통제 평면을 원합니다. 하지만 거기에 도달하려면 업계는 선언적 인터페이스를 고집하는 것보다 더 나은 방법을 찾아야 하며, 누구도 선언적 인터페이스를 수집하여 사용할 수 없다면 원래부터 선언적이지 않다는 사실을 인식해야 합니다.

*소녀도 꿈을 꿀 수 있지 않나요?