혁신의 관문은 네트워크에 있습니다

미주리주 세인트루이스 프랑스, 오를레앙. 핫 게이츠, 그리스.

역사를 통틀어 특정 장소는 "_____로의 관문"이라는 용어로 불려 왔습니다. 이 장소들은 왕국(프랑스, 스파르타)의 방어에 전략적으로 중요한 것으로 유명하거나, 새로운 땅을 개척하기 위한 광범위한 노력의 시작(세인트 루이스)으로 유명합니다. 관문은 보통 중요한 장소, 다른 곳으로 이어지는 곳입니다. 당신이 그것을 통제하면, 누가 들어오거나 무엇이 나가는지 통제할 수 있습니다. 이는 침입이나 공격에 대항하여 보다 효율적인 보호 지점을 제공하는 동시에 접근에 대한 통제를 제공합니다. 현대 사회에서 우리는 국제 공항에서 "세관"을 통과해야 하거나 처음에 입국하기 위해 두려운 "보안"을 통과해야 할 때 전 세계 공항에 이러한 관문이 있는 것을 봅니다.   

따라서 기술 역사의 과정에서 전략적으로 중요한 것으로 간주되고 집합적으로 "게이트웨이"로 알려진 장치 그룹이 생겨난 것은 놀라운 일이 아닙니다.

애플리케이션의 경우, 이러한 장치(아키텍처의 전략적 지점을 차지함)는 새로운 기술의 보안, 확장성, 그리고 종종 상호 운용성을 제공합니다.

느슨하게 말하면, 네트워크 방화벽을 네트워크의 앱 중심 게이트웨이의 "첫 번째" 인스턴스로 간주할 수 있습니다. 초창기에는 그들이 수문지기였으니까요. 네트워크 방화벽이 액세스를 허용하는 경우에만 회사 네트워크 외부에서 앱에 액세스할 수 있습니다. 그러나 오늘날의 게이트웨이는 애플리케이션에 훨씬 더 정통하며 보안뿐만 아니라 확장성, 액세스 및 상호 운용성에 대한 요구 사항도 해결합니다.

이 모든 것은 사물인터넷 시대로 접어들면서 우려되는 핵심 사안입니다. Vanson Bourne이 실시한 최근 HCL 설문조사에 따르면 응답자의 93%가 보안에 대해 우려하고, 86%는 규모에 대해, 83%는 상호 운용성에 대해 우려하는 것으로 나타났습니다. 이는 놀랄 일이 아닙니다. 데이터를 수집하고, 명령을 교환하고, 사물을 모니터링하기 위해 앱에 액세스해야 하는 기기의 양이 엄청나게 많아지면 모든 네트워크에 엄청난 영향을 미칠 수밖에 없습니다. 회사가 다음 "제품"을 시장에 출시하기 위해 압력을 받는 속도는 보안에 해로운 영향을 미칩니다. 그리고 상호 운용성은 의도한 용도를 수행하는 것만큼 다른 사물 및 앱과의 통신에 크게 의존하는 새로운 시장에서 항상 어려운 문제입니다. 새롭게 생겨나는 시장은 빠르게 분산되는 경향이 있으며, 여러 표준을 중심으로 시장이 모여들다가 어느 날 하나나 두 가지 표준에 정착하게 됩니다. 하지만 초기에는 종종 복잡하고 혼란스러운 선택이 뒤따릅니다. 혁신가들은 먼지가 가라앉을 때까지 기다리고 싶어하지 않습니다. 결국 혁신가는 시장에 진출하여 승리합니다.

그러면 문제는 새로운 기술이 성숙해지고 표준이 논의되는 동안 보안, 확장성, 상호 운용성을 어떻게 처리할 것인가가 됩니다. 이에 대한 답은 일반적으로 게이트웨이입니다.

과거에는 XML과 SOAP 등의 다른 기술과 프로토콜과 관련된 동일한 과제를 처리하기 위해 게이트웨이가 생겨났습니다. 웹 서비스의 "표준"으로서 RPC/ENC와 DOC/LIT 간의 싸움을 기억하는 (그리고 아마도 움츠러드는) 사람은 저 혼자가 아닐 것입니다. 그리고 JSON과 XML 간의 최근 전투를 기억하는 사람은 저뿐만이 아닙니다. 오늘날 이러한 줄다리기는 MQTT와 CoAP, AMQP가 주도권을 잡기 위해 경쟁하는 IoT 분야에서 일어나고 있습니다.

하지만 혁신은 기다릴 수 없으며 새로운 기술과 프로토콜로 인해 발생하는 과제를 처리하기 위해 게이트웨이가 좌우로 등장하고 있습니다.

HTTP2 게이트웨이

HTTP2 게이트웨이는 주로 HTTP/1x와 HTTP/2 간의 상호 운용성 문제를 해결합니다. 이러한 장치는 최신 HTTP 표준을 사용할 때 더욱 민첩하게 작동하는 모바일 및 IoT 장치를 지원하기 위해 "외부"에서 HTTP2를 종료합니다. 이를 통해 혁신가는 새로운 표준을 지원하기 위해 앱과 네트워크 인프라를 업그레이드하는 데 필요한 엄청난 중단 없이 소비자와 사물에 HTTP2에 대한 지원을 제공할 수 있습니다. 물론 언젠가는 모든 사람이 HTTP2를 사용하게 될 것이라는 기대가 있지만, 그동안 HTTP2 게이트웨이는 혁신가들이 전력으로 앞서 나가는 데 필요한 상호 운용성을 제공합니다.

API 게이트웨이

API 게이트웨이의 등장은 나비가 고치에서 나오는 것과 비슷합니다. 처음에는 애벌레(SOA 게이트웨이)였지만 이제는 나비(API 게이트웨이)가 되었습니다. 물론 이 범주에 새로운 참가자가 전혀 없다는 것은 아닙니다. 새로운 참가자가 있기는 하지만 둘 다 기반이 HTTP에 있기 때문에 많은 유사점을 공유합니다. SOA 게이트웨이가 주로 XML과 SOAP와 관련된 반면, API 게이트웨이는 HTTP 엔드포인트를 사용하여 구현된 JSON과 RESTful API에 초점을 맞춥니다.

이러한 장치는 보안과 확장성을 제공하고, 어떤 경우에는 상호 운용성 서비스를 제공합니다. 이들은 앱 언어에 능통하여 JSON과 HTTP를 똑같이 쉽게 구사하고, API 호출을 애플리케이션뿐 아니라 여러 환경에 분산할 수 있는 마이크로서비스와 서버리스 와 같은 새로운 앱 모델을 지원하기 위한 강력한 기반을 제공합니다. API 게이트웨이는 할당량(호출의 속도 제한)을 적용하여 확장성을 보호하고 API 키 관리를 통해 액세스를 제어하는 역할도 합니다.

이것들은 단순한 "로드 밸런서"가 아니지만 로드 밸런싱을 통한 확장은 확실히 API 게이트웨이의 핵심 특징입니다. 이러한 솔루션은 단순한 로드 밸런싱을 넘어 일관된 소비자 중심 경험을 제공하고 동시에 개발자와 기업이 클라우드와 서버리스의 이점을 활용할 수 있도록 해야 합니다. API 게이트웨이는 API를 보호하고 확장하려면 "스마트"해야 합니다. 즉, 요청과 응답을 검사하고 OAuth2 및 JWT와 같은 외부 인증 공급자와 통합할 수 있어야 합니다.  

IoT 게이트웨이

IoT 게이트웨이는 오늘날 게이트웨이 중 가장 초기 단계이지만 이미 출시되어 있으며 IoT 이니셔티브의 성공에 매우 중요합니다. 아마도 해당 시장의 다른 게이트웨이보다 더 중요할 것입니다. 이는 프로토콜과 관련이 있는데, 이 프로토콜은 전혀 웹 친화적이지 않습니다. 많은 소비자 기기가 "웹"을 사용하지만, 사물 제작자가 MQTT 및 CoAP와 같은 IoT 전용 프로토콜을 사용하는 경우가 점점 더 늘고 있습니다. 이러한 프로토콜은 효율성이 높고 기기의 컴퓨팅 소모가 적기 때문입니다. 하지만 해당 데이터를 수신하는 앱이 반드시 MQTT를 사용하는 것은 아니며, 사용하더라도 (가능하면 뛰어난) 수요를 충족하도록 스스로 확장할 수 없습니다.

따라서 IoT와 웹 언어에 능통하고 동시에 확장성과 보안을 확보할 수 있는 IoT 게이트웨이가 등장했습니다. API 게이트웨이와 마찬가지로 이러한 게이트웨이는 요청과 응답을 번역하고 라우팅하고 악용을 방지하기 위해 이상이나 잘못된 동작을 감지할 수 있을 만큼 "스마트"해야 합니다.

구조적으로 게이트웨이는 네트워크와 애플리케이션에 대한 액세스를 제공합니다. 요청은 이러한 채널을 통해 전달되므로 액세스를 제어하고, 번역을 제공하고, 보안을 강화할 수 있는 전략적 제어 지점이 됩니다. 이러한 플랫폼은 새로운 기술이나 프로토콜이 등장할 때 발생하는 자연스러운 전환 기간 동안 조직이 기존 비즈니스와 앱의 혼란과 위험을 최소화하면서 혁신할 수 있는 능력을 제공하므로 새로운 기술을 구현하는 데 중요한 역할을 합니다.

게이트웨이는 건축적 구조물로 간주되는 경향이 있지만, 오늘날에는 기업이 신기술의 힘을 활용할 수 있도록 하는 혁신의 핵심 요소이기도 합니다.