Offcanvas

���������������

"마이크로서비스 기반의 앱을 위한 데브섹옵스 구현" NIST, 새 가이드 공개

미국 연방정부도 민간 기업과 마찬가지로 클라우드, 데브섹옵스(Devsecops), 그리고 클라우드 네이티브 애플리케이션을 위한 마이크로서비스 기반 아키텍처로 전환하는 중이다. 미국표준기술연구원(NIST)은 업계가 모범사례를 채택할 수 있도록 표준과 가이드를 제공하고 혁신을 장려한다.   이를 위해 NIST는 지난 9월 서비스 메시(Service Mesh)를 사용한 마이크로서비스 기반 애플리케이션을 위한 데브섹옵스 구현을 발표했다(800-204C). 데브섹옵스 구현, 그리고 마이크로서비스 아키텍처에 클라우드 네이티브 애플리케이션을 호스팅하기 위한 서비스 메시를 사용한 참조 플랫폼 사용에 관한 포괄적인 가이드다. 이 문서는 현재 초안 형식이며, 전 미공군 최고 소프트웨어 책임자인 니콜라스 챌라인과 서비스 메시 분야 선두업체인 테트레이트(Tetrate)의 협업으로 작성됐다. 이 가이드는 성공적인 데브섹옵스 구현을 위한 구성 요소라고 할 수 있는 프리미티브(primitive) 개념을 사용했다. 데브섹옵스 프리미티브는 민첩한 개발을 위한 마이크로서비스 기반 애플리케이션에 가장 적합하다. 또한 데브섹옵스가 클라우드 네이티브 애플리케이션에 필요한 비즈니스 민첩성 요구사항을 촉진한다는 개념도 지원한다. NIST 가이드의 각 세션 내용을 분석해 보자. 데브섹옵스 프리미티브 구현을 위한 참조 플랫폼 이 가이드는 컨테이너 오케스트레이션과 관리 플랫폼 맥락에서 참조 플랫폼을 다룬다. 예를 들어 분류된 또는 연결이 끊긴 엄격한 환경(물리적) 또는 AWS, 애저와 같은 클라우드 서비스 제공업체(CSP) 환경과 같은 가상화된 환경 등 물리적 또는 가상 기반 인프라 위에 구축하는 방식이다. 가이드는 컨테이너 오케스트레이션 및 리소스 관리 플랫폼 사용을 권장한다. 가장 인기 있는 오픈소스 컨테이너 오케스트레이션 플랫폼인 쿠버네티스(Kubernetes)가 대표적이다. 쿠버네티스는 컨테이너화된 애플리케이션을 호스팅하는 팟(pod)을 기반으로 물리적 또는 가상 머신에 배포할 수...

데브섹옵스 NIST Devsecops 마이크로서비스 서비스메시 Service Mesh

2021.11.01

미국 연방정부도 민간 기업과 마찬가지로 클라우드, 데브섹옵스(Devsecops), 그리고 클라우드 네이티브 애플리케이션을 위한 마이크로서비스 기반 아키텍처로 전환하는 중이다. 미국표준기술연구원(NIST)은 업계가 모범사례를 채택할 수 있도록 표준과 가이드를 제공하고 혁신을 장려한다.   이를 위해 NIST는 지난 9월 서비스 메시(Service Mesh)를 사용한 마이크로서비스 기반 애플리케이션을 위한 데브섹옵스 구현을 발표했다(800-204C). 데브섹옵스 구현, 그리고 마이크로서비스 아키텍처에 클라우드 네이티브 애플리케이션을 호스팅하기 위한 서비스 메시를 사용한 참조 플랫폼 사용에 관한 포괄적인 가이드다. 이 문서는 현재 초안 형식이며, 전 미공군 최고 소프트웨어 책임자인 니콜라스 챌라인과 서비스 메시 분야 선두업체인 테트레이트(Tetrate)의 협업으로 작성됐다. 이 가이드는 성공적인 데브섹옵스 구현을 위한 구성 요소라고 할 수 있는 프리미티브(primitive) 개념을 사용했다. 데브섹옵스 프리미티브는 민첩한 개발을 위한 마이크로서비스 기반 애플리케이션에 가장 적합하다. 또한 데브섹옵스가 클라우드 네이티브 애플리케이션에 필요한 비즈니스 민첩성 요구사항을 촉진한다는 개념도 지원한다. NIST 가이드의 각 세션 내용을 분석해 보자. 데브섹옵스 프리미티브 구현을 위한 참조 플랫폼 이 가이드는 컨테이너 오케스트레이션과 관리 플랫폼 맥락에서 참조 플랫폼을 다룬다. 예를 들어 분류된 또는 연결이 끊긴 엄격한 환경(물리적) 또는 AWS, 애저와 같은 클라우드 서비스 제공업체(CSP) 환경과 같은 가상화된 환경 등 물리적 또는 가상 기반 인프라 위에 구축하는 방식이다. 가이드는 컨테이너 오케스트레이션 및 리소스 관리 플랫폼 사용을 권장한다. 가장 인기 있는 오픈소스 컨테이너 오케스트레이션 플랫폼인 쿠버네티스(Kubernetes)가 대표적이다. 쿠버네티스는 컨테이너화된 애플리케이션을 호스팅하는 팟(pod)을 기반으로 물리적 또는 가상 머신에 배포할 수...

2021.11.01

김진철의 How-to-Big Data | 빅데이터 괴담

이번 글은 필자가 지금까지 데이터 과학자로 경력을 쌓아오면서 경험했거나 듣고 읽었던 빅데이터 활용 사례들을 중심으로 빅데이터를 활용하는 과정에서 많은 조직이 흔히 저지르는 실수와 오해, 시행착오에 대해서 살펴보고, 이를 어떻게 개선할 수 있을지 같이 생각해보기로 한다. 소개하는 사례들은 실제 사례들이 아니라 필자가 경험했거나 들은 사례들을 각색하여 만든 가상의 사례들이며, 필자가 전달하고자 하는 메시지를 부각하기 위해 조금 과장했음을 미리 알려 둔다. 지금까지 같이 생각해봤던 빅데이터 활용의 교훈을 되새기고 독자들의 시행착오를 줄이는 것을 돕기 위해 만들 사례들이니 사실이 아닌 것을 염두에 주고 가볍고 즐겁게 읽었으면 좋겠다.   사례 1: 데이터 호수가 너무 넓어서 ROI가 나지 않아 곤란한 A 기업의 CIO 이야기 많은 사람에게 널리 알려진 A 회사에서 빅데이터를 앞세워 승승장구한 C는 요즘 고민이 많다. 문제는 바로 그에게 회사에서 승승장구한 경력을 만들어준 데이터 레이크 시스템 때문이다. C는 2011년도 빅데이터 붐이 일기 시작할 즈음 승진을 위한 기획 아이템으로 뭘 앞세울까 고민하다가 그 당시 막 떠오르고 있던 빅데이터를 앞세워서 A 회사에 하둡 기반의 빅데이터 시스템을 구축하는 기획안을 만들어 임원의 승인을 받는 데 성공했다.  당시 NexR과 같이 오픈소스 하둡을 기반으로 빅데이터 솔루션을 상용화하는 스타트업이 막 등장하고 있었다. 이런 스타트업 중에서 괜찮은 회사 하나를 잘 골라서 같이 일하면서 키우면 자신의 승진에 많이 도움이 될 것 같았다. 운이 좋다면 자신의 직속 임원이 이 스타트업을 인수, 합병하여 사업 성과를 낼 수 있도록 하면서 그 회사의 고급 소프트웨어 엔지니어들을 자연스럽게 회사로 영입하여 자신의 세력으로 키울 수 있을 것 같았다. C는 당시 하둡 기반 빅데이터 스타트업으로서 같이 하둡 시스템 구축 사업을 수행한 D사를 잘 활용하여 예상보다 빠르게 하둡 시스템을 안정적으로 구축할 수 있었다. 이후 프...

김진철 빅데이터 데이터 과학 데이터 과학자 시행착오 데이터 레이크 하둡 스타트업 스파크 플링크 에어플로우 데이터웨어하우스 도커 서비스메시 쿠버네티스

2021.03.29

이번 글은 필자가 지금까지 데이터 과학자로 경력을 쌓아오면서 경험했거나 듣고 읽었던 빅데이터 활용 사례들을 중심으로 빅데이터를 활용하는 과정에서 많은 조직이 흔히 저지르는 실수와 오해, 시행착오에 대해서 살펴보고, 이를 어떻게 개선할 수 있을지 같이 생각해보기로 한다. 소개하는 사례들은 실제 사례들이 아니라 필자가 경험했거나 들은 사례들을 각색하여 만든 가상의 사례들이며, 필자가 전달하고자 하는 메시지를 부각하기 위해 조금 과장했음을 미리 알려 둔다. 지금까지 같이 생각해봤던 빅데이터 활용의 교훈을 되새기고 독자들의 시행착오를 줄이는 것을 돕기 위해 만들 사례들이니 사실이 아닌 것을 염두에 주고 가볍고 즐겁게 읽었으면 좋겠다.   사례 1: 데이터 호수가 너무 넓어서 ROI가 나지 않아 곤란한 A 기업의 CIO 이야기 많은 사람에게 널리 알려진 A 회사에서 빅데이터를 앞세워 승승장구한 C는 요즘 고민이 많다. 문제는 바로 그에게 회사에서 승승장구한 경력을 만들어준 데이터 레이크 시스템 때문이다. C는 2011년도 빅데이터 붐이 일기 시작할 즈음 승진을 위한 기획 아이템으로 뭘 앞세울까 고민하다가 그 당시 막 떠오르고 있던 빅데이터를 앞세워서 A 회사에 하둡 기반의 빅데이터 시스템을 구축하는 기획안을 만들어 임원의 승인을 받는 데 성공했다.  당시 NexR과 같이 오픈소스 하둡을 기반으로 빅데이터 솔루션을 상용화하는 스타트업이 막 등장하고 있었다. 이런 스타트업 중에서 괜찮은 회사 하나를 잘 골라서 같이 일하면서 키우면 자신의 승진에 많이 도움이 될 것 같았다. 운이 좋다면 자신의 직속 임원이 이 스타트업을 인수, 합병하여 사업 성과를 낼 수 있도록 하면서 그 회사의 고급 소프트웨어 엔지니어들을 자연스럽게 회사로 영입하여 자신의 세력으로 키울 수 있을 것 같았다. C는 당시 하둡 기반 빅데이터 스타트업으로서 같이 하둡 시스템 구축 사업을 수행한 D사를 잘 활용하여 예상보다 빠르게 하둡 시스템을 안정적으로 구축할 수 있었다. 이후 프...

2021.03.29

"쿠버네티스, 왜 이리 배우기 어려운가?" 공동 창업자가 내놓은 답변 보니

쿠버네티스 공동 창업자는 컨테이너 오케스트레이션 소프트웨어가 리눅스 커널처럼 보편화되고 구성도 용이해져, 도입을 넘어선 그 다음 단계로 넘어가기를 바라고 있다.  쿠버네티스의 공동 창업자인 조 베다는 컨테이너 오케스트레이션 툴이 학습하기 까다롭다고 인정하면서, 쿠버네티스가 도입을 넘어 다음 단계로 나아가려면, 커뮤니티가 쿠버네티스 기술을 리눅스 커널처럼 보편화하는 데 초점을 맞춰야 한다고 전했다.   베다는 브라이트토크에서 진행된 ‘무엇이든 물어보세요’ 세션에서 "이제 쿠버네티스는 다양한 생태계의 근간이자 애플리케이션 배포 및 관리를 위한 방식으로 여겨지고 있다"라고 말했다. 쿠버네티스 초창기에는 생각하지 못했던 바다. 베다는 “이렇게 될 것이라고는 예상하지 못했다”라고 말했다.   쿠버네티스가 엔터프라이즈 개발자들이 사용하는 핵심 기술이 된 만큼 베다는 두 가지 목표를 갖고 있다. 하나는 쿠버네티스를 안정적이면서 유용한 플랫폼으로 만들어, 리눅스 커널처럼 운영체제의 기본 구성요소로 자리잡을 수 있도록 하는 것이다.  다른 하나는 쿠버네티스에 흥미롭고 새로운 기능을 구축하는 것이다. 베다는 "사람들이 (쿠버네티스에) 놀라운 기능들을 구축하고 있다. 이를 바탕으로 흥미로운 작업을 해볼 수 있을 것이다. 쿠버네티스를 활용한 여러 프로젝트들이 이미 있다"라고 말했다.     베다는 2014년에 쿠버네티스를 위한 첫 번째 커밋을 작성했다. 그는 구글에서 10년간 근무한 후 현재 VM웨어의 수석 엔지니어로 일하고 있다. 베다가 사람들과 대화를 나누는 가운데 쿠버네티스에 대해 받은 핵심 질문 두 가지에 대한 답을 아래와 같이 정리했다.  왜 이스티오는 쿠버네티스와 별도로 존재하는가? 베다가 아주 흥미로워 했던 질문 중 하나는 다음과 같다. 오픈소스 서비스 메시인 이스티오(Istio)는 보통 쿠버네티스와 한쌍을 이루고, 구글 엔지니어들이 주로 개발했는데 왜 쿠버네티스와 좀...

쿠버네티스 조 베다 오케스트레이션 리눅스 커널 이스티오 오픈소스 구글 링커드 서비스메시 YAML 베어메탈 코드형 인프라

2021.02.03

쿠버네티스 공동 창업자는 컨테이너 오케스트레이션 소프트웨어가 리눅스 커널처럼 보편화되고 구성도 용이해져, 도입을 넘어선 그 다음 단계로 넘어가기를 바라고 있다.  쿠버네티스의 공동 창업자인 조 베다는 컨테이너 오케스트레이션 툴이 학습하기 까다롭다고 인정하면서, 쿠버네티스가 도입을 넘어 다음 단계로 나아가려면, 커뮤니티가 쿠버네티스 기술을 리눅스 커널처럼 보편화하는 데 초점을 맞춰야 한다고 전했다.   베다는 브라이트토크에서 진행된 ‘무엇이든 물어보세요’ 세션에서 "이제 쿠버네티스는 다양한 생태계의 근간이자 애플리케이션 배포 및 관리를 위한 방식으로 여겨지고 있다"라고 말했다. 쿠버네티스 초창기에는 생각하지 못했던 바다. 베다는 “이렇게 될 것이라고는 예상하지 못했다”라고 말했다.   쿠버네티스가 엔터프라이즈 개발자들이 사용하는 핵심 기술이 된 만큼 베다는 두 가지 목표를 갖고 있다. 하나는 쿠버네티스를 안정적이면서 유용한 플랫폼으로 만들어, 리눅스 커널처럼 운영체제의 기본 구성요소로 자리잡을 수 있도록 하는 것이다.  다른 하나는 쿠버네티스에 흥미롭고 새로운 기능을 구축하는 것이다. 베다는 "사람들이 (쿠버네티스에) 놀라운 기능들을 구축하고 있다. 이를 바탕으로 흥미로운 작업을 해볼 수 있을 것이다. 쿠버네티스를 활용한 여러 프로젝트들이 이미 있다"라고 말했다.     베다는 2014년에 쿠버네티스를 위한 첫 번째 커밋을 작성했다. 그는 구글에서 10년간 근무한 후 현재 VM웨어의 수석 엔지니어로 일하고 있다. 베다가 사람들과 대화를 나누는 가운데 쿠버네티스에 대해 받은 핵심 질문 두 가지에 대한 답을 아래와 같이 정리했다.  왜 이스티오는 쿠버네티스와 별도로 존재하는가? 베다가 아주 흥미로워 했던 질문 중 하나는 다음과 같다. 오픈소스 서비스 메시인 이스티오(Istio)는 보통 쿠버네티스와 한쌍을 이루고, 구글 엔지니어들이 주로 개발했는데 왜 쿠버네티스와 좀...

2021.02.03

기고 | 관찰가능성이 시스템 모니터링의 미래인 이유

클라우드로의 전환은 여전히 업계의 주요 추세지만, 마이그레이션을 수행하는 방법은 조직마다 상당히 다르다. 언론에 자주 오르는 기업은 철저한 트랜스포메이션을 실행한 기업이다. 클라우드 네이티브를 따르는 전면적인 개편과 급진적인 구조조정에 관한 이야기가 아무래도 눈길을 끌기 때문이다.    그러나 이것이 시장의 전부는 결코 아니다. 모든 기업이 똑같은 방식으로 클라우드 도입을 추진하는 것은 아니고, 아직 클라우드로 이전하지 않은 애플리케이션과 기업도 많다. 또한 부분적으로만, 또는 전통적인 “리프트 앤 시프트” 방식에 가깝게 마이그레이션한 기업도 상당수 존재한다.  예를 들어 오라일리 레이더(O’Reilly Radar)는 다양한 업종의 엔지니어, 설계자, IT 책임자 1,283명을 대상으로 2020 클라우드 도입 설문을 실시했는데, 여기서 응답자의 88% 이상은 어떤 형식으로든 클라우드를 사용한다고 답했다. 응답자가 속한 조직의 90% 이상은 향후 12개월 동안 클라우드 사용이 증가할 것으로 예상하고 있으며, 대기업 조직(직원 수 1만 명 이상) 응답자 중 이미 클라우드로 100% 애플리케이션을 이전했다고 답한 응답자는 17%에 불과했다. 결국 전 세계적으로 클라우드 마이그레이션 여정은 아직 진행 중인 단계다.  무엇이 가로막고 있을까? 한 가지 피할 수 없는 간단명료한 결론은 소프트웨어가 전보다 훨씬 더 복잡하다는 것이다. 클라우드의 영향력이 갈수록 커지고 있지만, 동시에 많은 수의 이기종 스택이 존재한다. 오라일리 설문 응답자의 절반 이상이 복수의 클라우드 서비스를 이용 중이며, 마이크로서비스를 구현했다고 답했다. 클라우드 서비스와 솔루션 제공업체 중에서 경쟁에서 압도해 지배적인 위치에 올랐다고 할 만한 확실한 승자는 없다. 사실 인기 있는 솔루션의 다양성은 앞으로도 줄어 들기는커녕 더 늘어날 가능성이 높다.    APM에서 관찰가능성으로  이처럼 다양성이 꾸준히 중시되는 이유 중 하나는 기...

모니터링 관찰가능성 APM 서비스메시

2020.08.18

클라우드로의 전환은 여전히 업계의 주요 추세지만, 마이그레이션을 수행하는 방법은 조직마다 상당히 다르다. 언론에 자주 오르는 기업은 철저한 트랜스포메이션을 실행한 기업이다. 클라우드 네이티브를 따르는 전면적인 개편과 급진적인 구조조정에 관한 이야기가 아무래도 눈길을 끌기 때문이다.    그러나 이것이 시장의 전부는 결코 아니다. 모든 기업이 똑같은 방식으로 클라우드 도입을 추진하는 것은 아니고, 아직 클라우드로 이전하지 않은 애플리케이션과 기업도 많다. 또한 부분적으로만, 또는 전통적인 “리프트 앤 시프트” 방식에 가깝게 마이그레이션한 기업도 상당수 존재한다.  예를 들어 오라일리 레이더(O’Reilly Radar)는 다양한 업종의 엔지니어, 설계자, IT 책임자 1,283명을 대상으로 2020 클라우드 도입 설문을 실시했는데, 여기서 응답자의 88% 이상은 어떤 형식으로든 클라우드를 사용한다고 답했다. 응답자가 속한 조직의 90% 이상은 향후 12개월 동안 클라우드 사용이 증가할 것으로 예상하고 있으며, 대기업 조직(직원 수 1만 명 이상) 응답자 중 이미 클라우드로 100% 애플리케이션을 이전했다고 답한 응답자는 17%에 불과했다. 결국 전 세계적으로 클라우드 마이그레이션 여정은 아직 진행 중인 단계다.  무엇이 가로막고 있을까? 한 가지 피할 수 없는 간단명료한 결론은 소프트웨어가 전보다 훨씬 더 복잡하다는 것이다. 클라우드의 영향력이 갈수록 커지고 있지만, 동시에 많은 수의 이기종 스택이 존재한다. 오라일리 설문 응답자의 절반 이상이 복수의 클라우드 서비스를 이용 중이며, 마이크로서비스를 구현했다고 답했다. 클라우드 서비스와 솔루션 제공업체 중에서 경쟁에서 압도해 지배적인 위치에 올랐다고 할 만한 확실한 승자는 없다. 사실 인기 있는 솔루션의 다양성은 앞으로도 줄어 들기는커녕 더 늘어날 가능성이 높다.    APM에서 관찰가능성으로  이처럼 다양성이 꾸준히 중시되는 이유 중 하나는 기...

2020.08.18

클라우드 네이티브 환경을 위한 범용 정책 엔진 OPA의 이해

조직이 클라우드를 도입하면 클라우드 네이티브 스택의 역동성과 규모로 인해 훨씬 더 복잡한 보안과 컴플라이언스 환경이 필요하게 된다. 예를 들어 쿠버네티스와 같은 컨테이너 오케스트레이션 플랫폼의 사용이 늘면 개발자와 데브옵스팀은 컴퓨팅, 스토리지, 네트워킹과 같은 전통적인 영역과 함께 승인 제어와 같은 정책 영역에 대한 새로운 책임도 맡게 된다. 또한 각 애플리케이션과 마이크로서비스 또는 서비스 메시에 각각의 권한 부여 정책이 필요한데, 개발자들이 난관을 겪는 부분이다.   이러한 이유로 조직은 클라우드에서 정책을 만들고 시행하고 관리할 더 간단하고 시간 효율적인 방법을 찾는다. 개방형 정책 에이전트(Open Policy Agent, OPA)의 역할이 그것이다. 4년전 오픈소스로 만들어진 도메인 중립적 정책 엔진인 OPA는 현재 클라우드 네이티브 정책의 사실상 표준으로 자리잡고 있다. 실제로 넷플릭스, 핀터레스트, 골드만삭스와 같은 기업은 쿠버네티스의 승인 제어 및 마이크로서비스 API 권한 부여와 같은 사용례를 위해 이미 OPA를 프로덕션 환경에 구축했다. 또한 OPA는 아틀라시안(Atlassian) 제품군, 셰프 오토메이트(Chef Automate)와 같은 익숙한 여러 클라우드 네이티브 툴에도 사용된다. OPA는 클라우드 네이티브 조직에 통합 정책 언어를 제공해 다양한 언어와 툴에 개별적으로 맞춤 정책을 하드코딩하지 않고 앱과 API, 인프라 등 전반에서 공통적인 방법으로 권한 부여 결정을 표현할 수 있게 해준다. 또한 OPA는 권한 부여를 목적으로 만들어진 만큼 여러 성능 최적화를 제공하므로 정책 작성자는 성능 문제는 OPA에 맡기고 올바른, 유지 관리 가능한 정책을 쓰는 데 시간을 투자할 수 있다. OPA 권한 부여 정책의 사용례는 컨테이너 오케스트레이션을 위한 가드레일 설치부터 SSH 액세스 제어 또는 컨텍스트 기반 서비스 메시 권한 부여에 이르기까지, 스택 전반에 걸쳐 매우 많다. 그 중에서 많은 OPA 사용자에게 좋은 출발점이 되는 ...

OPA 정책 쿠버네티스 서비스메시 승인제어 마이크로서비스

2020.08.11

조직이 클라우드를 도입하면 클라우드 네이티브 스택의 역동성과 규모로 인해 훨씬 더 복잡한 보안과 컴플라이언스 환경이 필요하게 된다. 예를 들어 쿠버네티스와 같은 컨테이너 오케스트레이션 플랫폼의 사용이 늘면 개발자와 데브옵스팀은 컴퓨팅, 스토리지, 네트워킹과 같은 전통적인 영역과 함께 승인 제어와 같은 정책 영역에 대한 새로운 책임도 맡게 된다. 또한 각 애플리케이션과 마이크로서비스 또는 서비스 메시에 각각의 권한 부여 정책이 필요한데, 개발자들이 난관을 겪는 부분이다.   이러한 이유로 조직은 클라우드에서 정책을 만들고 시행하고 관리할 더 간단하고 시간 효율적인 방법을 찾는다. 개방형 정책 에이전트(Open Policy Agent, OPA)의 역할이 그것이다. 4년전 오픈소스로 만들어진 도메인 중립적 정책 엔진인 OPA는 현재 클라우드 네이티브 정책의 사실상 표준으로 자리잡고 있다. 실제로 넷플릭스, 핀터레스트, 골드만삭스와 같은 기업은 쿠버네티스의 승인 제어 및 마이크로서비스 API 권한 부여와 같은 사용례를 위해 이미 OPA를 프로덕션 환경에 구축했다. 또한 OPA는 아틀라시안(Atlassian) 제품군, 셰프 오토메이트(Chef Automate)와 같은 익숙한 여러 클라우드 네이티브 툴에도 사용된다. OPA는 클라우드 네이티브 조직에 통합 정책 언어를 제공해 다양한 언어와 툴에 개별적으로 맞춤 정책을 하드코딩하지 않고 앱과 API, 인프라 등 전반에서 공통적인 방법으로 권한 부여 결정을 표현할 수 있게 해준다. 또한 OPA는 권한 부여를 목적으로 만들어진 만큼 여러 성능 최적화를 제공하므로 정책 작성자는 성능 문제는 OPA에 맡기고 올바른, 유지 관리 가능한 정책을 쓰는 데 시간을 투자할 수 있다. OPA 권한 부여 정책의 사용례는 컨테이너 오케스트레이션을 위한 가드레일 설치부터 SSH 액세스 제어 또는 컨텍스트 기반 서비스 메시 권한 부여에 이르기까지, 스택 전반에 걸쳐 매우 많다. 그 중에서 많은 OPA 사용자에게 좋은 출발점이 되는 ...

2020.08.11

마이크로서비스를 위한 서비스 메시 기술 ‘이스티오’가 뜨는 이유

작년 이스티오(Istio) 서비스 메시 기술에 대한 관심과 움직임에는 흥미로운 측면이 확실히 있었다. 이스티오의 버전은 아직 0.8인데, KubeCon/CloudNativeCon 이벤트에서 계속 뜨거운 화두가 됐다. 이유가 무엇일까? 이스티오의 인기 이유를 살펴보기 전에 서비스 메시부터 소개해 보자. 다소 포괄적인 용어인 서비스 메시는 예를 들어 다양한 무선 디바이스 간 통신 방법을 정의하거나 개별 애플리케이션이 다른 애플리케이션과 직접 통신할 수 있는 시스템을 나타내는 등 여러 가지 맥락에서 사용된다. 최근에는 애플리케이션 또는 마이크로서비스 네트워크, 그리고 이러한 요소 간의 관계와 상호 작용을 나타내는 데 사용되고 있다. 여기서는 후자에 초점을 맞춘다. 레드햇이 클라우드 네이티브와 마이크로서비스 영역에 참여해왔다는 사실, 특히 레드햇 오픈시프트(OpenShift)가 약 4년 전에 쿠버네티스와 도커에서 택한 방향을 보면 서비스 메시 기술, 특히 이스티오의 중요성을 이해하는 데 도움이 된다. 필자가 생각하는 이스티오가 인기를 끄는 네 가지 이유는 다음과 같다. 마이크로서비스와 트랜스포메이션 코드를 작성한 시점과 이 코드가 프로덕션에 배포되는 시점 사이의 간격이 너무 길어 개발자는 이미 다른 프로젝트로 이동했고 피드백 루프는 비생산적이거나 관련성이 없는 상황은 이 분야에서 흔히 겪게 되는 일이다. 지금 그런 상황에 처해 있는 사람도 있을 것이다. 이 ‘리드 시간’을 단축하기 위해 일부 기업은 몸집이 큰 애플리케이션을 함수 또는 마이크로서비스와 같은 작은 조각으로 나눠 효율성을 개선하는 방법을 택한다. 많은 기능을 가진 하나의 애플리케이션(패키지)이 각각 독립적으로 업데이트가 가능한 개별 패키지로 분할된다. 물론 이런 방식도 가치가 있지만, 이러한 시나리오는 개별 서비스와 그 사이의 인터페이스에 대한 더 많은 관리 필요성을 수반한다는 점도 감안해야 한다. 예를 들어 애플리케이션 내의 API 호출의 일부로 정의됐...

레드햇 컨테이너 넷플릭스 리프트 쿠버네티스 마이크로서비스 서비스메시 오픈시프트 이스티오

2018.05.28

작년 이스티오(Istio) 서비스 메시 기술에 대한 관심과 움직임에는 흥미로운 측면이 확실히 있었다. 이스티오의 버전은 아직 0.8인데, KubeCon/CloudNativeCon 이벤트에서 계속 뜨거운 화두가 됐다. 이유가 무엇일까? 이스티오의 인기 이유를 살펴보기 전에 서비스 메시부터 소개해 보자. 다소 포괄적인 용어인 서비스 메시는 예를 들어 다양한 무선 디바이스 간 통신 방법을 정의하거나 개별 애플리케이션이 다른 애플리케이션과 직접 통신할 수 있는 시스템을 나타내는 등 여러 가지 맥락에서 사용된다. 최근에는 애플리케이션 또는 마이크로서비스 네트워크, 그리고 이러한 요소 간의 관계와 상호 작용을 나타내는 데 사용되고 있다. 여기서는 후자에 초점을 맞춘다. 레드햇이 클라우드 네이티브와 마이크로서비스 영역에 참여해왔다는 사실, 특히 레드햇 오픈시프트(OpenShift)가 약 4년 전에 쿠버네티스와 도커에서 택한 방향을 보면 서비스 메시 기술, 특히 이스티오의 중요성을 이해하는 데 도움이 된다. 필자가 생각하는 이스티오가 인기를 끄는 네 가지 이유는 다음과 같다. 마이크로서비스와 트랜스포메이션 코드를 작성한 시점과 이 코드가 프로덕션에 배포되는 시점 사이의 간격이 너무 길어 개발자는 이미 다른 프로젝트로 이동했고 피드백 루프는 비생산적이거나 관련성이 없는 상황은 이 분야에서 흔히 겪게 되는 일이다. 지금 그런 상황에 처해 있는 사람도 있을 것이다. 이 ‘리드 시간’을 단축하기 위해 일부 기업은 몸집이 큰 애플리케이션을 함수 또는 마이크로서비스와 같은 작은 조각으로 나눠 효율성을 개선하는 방법을 택한다. 많은 기능을 가진 하나의 애플리케이션(패키지)이 각각 독립적으로 업데이트가 가능한 개별 패키지로 분할된다. 물론 이런 방식도 가치가 있지만, 이러한 시나리오는 개별 서비스와 그 사이의 인터페이스에 대한 더 많은 관리 필요성을 수반한다는 점도 감안해야 한다. 예를 들어 애플리케이션 내의 API 호출의 일부로 정의됐...

2018.05.28

IDG 설문조사

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.

10.5.0.9