Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.

컨테이너

풀루미로 알아보는 코드형 인프라 툴의 “벗어날 수 없는” 매력

현대적인 인프라란 셰프(Chef)를 사용해 몇 개의 가상머신에 소프트웨어를 프로비저닝하는 것, 또는 테라폼(Terraform)을 사용해 두어 개의 VM 라이프사이클을 관리하는 것을 의미하던 시절이 있었다. 지금은 아니다. 오늘날 가장 성공적인 개발팀은 수십 또는 수백 개의 클라우드 인프라 구성요소를 관리하던 형태에서 벗어났으며, 대신 수천 개의 클라우드 리소스에 대해 생각해야 한다. 현재의 컨테이너와 쿠버네티스 세계에서 인프라의 규모와 복잡성은 방대하고, 변화의 속도는 무한히 더 빨라지며, 애플리케이션과 인프라 사이의 구분은 흐려졌다.    이 세계에서 개발자는 풀루미(Pulumi)와 같은 IaC(Infrastructure as Code, 코드형 인프라) 툴에 점점 더 의존하고 있다. 필자는 폴라(Polar), HCL과 같은, 이 분야의 선언적 언어를 소개한 적이 있지만, 풀루미의 접근 방식은 개발자에게 타입스크립트와 같은 각자 선호하는 언어로 코드를 작성하면서도 다양한 클라우드 및 SaaS 제공업체에 걸쳐 API를 호출할 수 있는 기능을 제공한다. 유망한 접근 방법이지만, 과연 희망대로 될지 살펴보자.   IaC가 필요한 이유  저스틴 이더리지는 클라우드 세계에서 IaC는 있으면 좋은 부가적인 요소가 아니라 필수 요소인 이유를 잘 설명했다. 여러 이점(반복 가능성, 감사 가능성, 이식성 등) 중에 이더리지가 꼽은 첫 번째 이유는 나머지 모든 이유의 중심, 바로 확신이다. “코드형 인프라는 복구 불가능한 상태가 될 수 있다는 두려움 없이 변화를 적용할 수 있는 자유를 부여한다. 또한 현재 환경의 원리에 대한 이해를 높일 수 있고, 이를 통해 더 확신을 갖고 필요한 변경을 수행할 수 있다”는 것이다.  이유는 그렇다 치고, IaC의 약속을 실현할 방법도 이유 못지않게 중요하다. 기업의 클라우드 도입 과정을 돌아보면 첫 번째 단계에서는 개발자가 단일 VM의 범위 내에서 작업을 했다. 개발자는 시간을 들여 우분투 ...

코드형인프라 컨테이너 IaC 2021.03.11

애저 앱 서비스에서 컨테이너 실행하기

현대 클라우드의 중심에서는 두 가지 철학이 긴장 관계를 이루고 있다. 클라우드 서비스 업체가 관리하는 호스트 시스템 패브릭에 가상 인프라를 구축하는 IaaS, 그리고 클라우드 서비스 업체가 관리하는 런타임에 대해 이들의 서비스 API를 대상으로 코드를 쓰는 PaaS다. 두 가지 접근 방식 모두 개발자가 애플리케이션에 집중할 수 있도록 물리 인프라와 호스트 운영의 추상화 계층을 제공한다.    컨테이너는 이 두 가지 방법 사이의 중간 지대를 제공해 클라우드 서비스 업체가 관리하는 플랫폼에 의존하면서 더 복잡한 코드를 쓰고 필요한 애플리케이션 및 기타 종속성을 패키지화할 수 있게 해준다. OS 수준 보안 또는 업데이트를 직접 관리할 필요가 없고, 플랫폼 런타임에서 지원하는 언어와 API로 제한되지도 않는다. 효과적인 타협안이다. 또한 쿠버네티스(Kubernetes)와 같은 기술은 필요한 컨테이너 수준 시스템 관리 툴을 제공한다.  애저 쿠버네티스 서비스(AKS)와 같은 툴을 사용한다 해도 쿠버네티스가 복잡한 것은 사실이다. 분산 애플리케이션을 대규모로 실행하기 위한 툴이기 때문이다. 코드는 높은 수요에도 견딜 수 있어야 하고, 글로벌 규모로 실행하면서 전 세계 곳곳에 걸쳐 노드를 복제한다. AKS를 사용하면 컨테이너 클러스터를 배포하고 실행 상태를 보장하면서 새 버전이 사용할 준비가 되는 즉시 CI/CD(지속적 통합/지속적 제공) 파이프라인에서 바로 배포할 수 있다.  컨테이너의 혜택을 누릴 수 있는 또 다른 종류의 애플리케이션은 글로벌 규모가 불필요한 웹사이트와 서비스 뒤에서 실행되는 코드다(물론 안정적인 운영이 보장된다면 좋지만). 사용자 수가 수백만 단위는 아니지만 수백, 수천 명의 사람들이 코드를 사용하고 여러 기업이 이 코드에 의존할 수 있다.    애저 앱 서비스: 애저의 첫 서버리스 플랫폼  애저 앱 서비스는 애저 PaaS에서 가장 오래된 요소다. 애저 앱 서비스는 웹 및 모...

애저 앱서비스 컨테이너 2021.02.18

IDG 블로그 | 쿠버네티스가 답이 아닐 때

쿠버네티스는 많은 환경에서 견실한 해법을 제공하는 강력한 최신 기술이다. 내로라하는 기업이 모두 쿠버네티스 관련 기술을 선택한 것으로 보일지 모르겠지만, 모든 애플리케이션에 맞는 기술은 아니다. 어떤 기술이 이렇게 많은 지지자를 확보하면, 해당 기술을 사용하는 것이 이미 정해진 결론이 되기도 한다. 하지만 바로 이때 실수가 생기고 프로젝트가 탈선한다.   클라우드 기반 플랫폼으로 이전하려는 기업 대부분은 컨테이너와 쿠버네티스 사용을 생각한다. 클라우드를 사용하는 기업의 많은 수가 이미 쿠버네티스를 사용하고 있다. 쿠버네티스는 마이크로서비스를 포함해 분산 시스템을 좀 더 쉽게 관리하고 확장할 수 있는 많은 자원을 제공한다. 또한 오케스트레이션 시스템으로, 프로세스와 서비스를 묶어 좀 더 크고 통일적인 솔루션으로 구축할 수 있다. 공식 쿠버네티스 문서화 웹 사이트에 제시된 것처럼, “쿠버네티스는 복구성 있는 분산 시스템을 구동하는 프레임워크를 제공한다. 쿠버네티스는 애플리케이션의 확장과 페일오버를 관리하며, 배치 패턴 등을 제공한다.” 자동화와 오케스트레이션은 쿠버네티스를 이용하는 주된 이유 중 하나이다. 그런데 자동화와 오케스트레이션은 종종 혼동되기도 한다. 자동화는 소프트웨어나 하드웨어가 특정 작업을 수행하는 데 인력의 개입을 줄이거나 제거해 비즈니스 프로세스를 더 효율적으로 만드는 것이다. 예를 들어, 자동화는 어떤 프로세스에서 특정 원료의 공급이 일정 수준 이하인 것을 발견하면 자동으로 원재료를 재주문하는 프로세스를 실행할 수 있다. 이와는 달리 오케스트레이션은 워크플로우를 자동화한다. 오케스트레이션은 정해진 순서와 활동이 지켜지도록 하는 것이 주된 역할이며, 워크플로우의 일부인 단일 작업의 자동화를 시작할 수도 있다. 오케스트레이션은 쿠버네티스의 강력한 무기로, 서로 다른 시스템에 걸쳐 데이터베이스를 액세스해야 하는 서비스를 가능하게 해준다. 지금의 문제는 많은 개발자와 아키텍트가 오케스트레이션 엔진을 사용해 프로세스를 자동화하려고 쿠...

쿠버네티스 마이크로서비스 컨테이너 2021.01.27

IDG 블로그 | 컨테이너에는 좋은 아키텍처가 필요하다

가트너는 2023년까지 컨테이너 도입이 계속 증가할 것이라고 예측한다. 가트너의 설문 조사 데이터에 따르면, 애플리케이션과 데이터의 컨테이너화는 폭증하고 있다. 애플리케이션의 절반 이상을 컨테이너화환 기업의 비율도 23%에서 29%로 증가했다. 또한 애플리케이션의 10% 이하만 컨테이너화했다는 기업은 32%에서 21%로 줄었다.   컨테이너가 클라우드 기반 애플리케이션의 기본 구조가 되고, 이런 리서치 회사의 설문 조사를 인용하는 데도 도움이 될 정도로 확산하고 있다. 이제 기업이 할 일은 단 하나. 클라우드 개발팀은 컨테이너가 클라우드 네이티브로 가는 대중적인 방법이라는 것을 잘 이해하고, 쿠버네티스 같은 컨테이너 오케스트레이션 기술을 사용해 그 이식성과 확장성을 제대로 활용해야 한다. 컨테이너의 문제는 컨테이너 자체나 컨테이너 오케스트레이션을 사용하는 것이 아니라 사용하는 설계 패턴에 있다. 컨테이너는 본질적으로 복잡하고 계층화된 분산 애플리케이션이다. 리프트 앤 시프트 방식으로 기존 애플리케이션을 컨테이너로 이전할 수도 있지만, 이런 식으로는 얻을 수 있는 이점이 매우 적다. 컨테이너를 플랫폼이자 아키텍처로 명확하게 설계하지 않으면, 컨테이너의 역량을 이용할 수 없다. 몇 가지 팁을 소개한다. 첫째, 컨테이너화된 애플리케이션을 기능에 따라 논리적인 그룹으로 조각조각 분해하는 법을 배운다. 완전히 새로운 앱이든 기존 앱이든 관계없다. 이를 통해 몇 가지를 얻을 수 있다. 특수 제작한 코드를 데이터베이스 액세스 같은 도메인에 배치할 수 있고, 트러블슈팅이나 운영도 개선할 수 있다. 또한 컨테이너를 최고의 성능을 제공하는 클러스터에 배치할 수 있다.  둘째, 보안을 위한 논리적인 그룹을 만든다. 보안은 컨테이너화된 애플리케이션을 구축할 때 흔히 나중에 생각하는 항목이 되곤 한다. 실제로 복잡하고 분산된 애플리케이션, 즉 컨테이너 기반 애플리케이션 대부분은 안전하게 보호하기가 어렵다. 또한 컨테이너가 기본적으로는 플랫폼 상에서 구동하는...

컨테이너 아키텍처 플랫폼 2021.01.13

아태 지역의 중견기업이 직면한 주요 인프라 동향 및 의사결정 - IDC InfoBrief

본 InfoBrief는 아시아 태평양 지역에서 활동하는 902명의 IT 의사 결정자들을 대상으로 설문조사를 기반으로 이 지역에 위치한 중견기업의 IT 실무자 대상으로 IT 환경에 영향을 미치는 주요 동향과 서버 운영 체제 환경(S-OSE)의 역할에 대한 인사이트를 제공합니다. 아태 지역의 많은 중견기업이 전략적 IT 프로젝트를 통해 노후화된 IT 환경이 현대화로 전환되는 과정에 있습니다. 하이브리드 클라우드, 컨테이너, 데이터 관리 및 IT 인프라 등 주요 인프라의 현황을 알아보고, 운영체제 환경 선택을 위한 비즈니스 및 기술 고려사항도 살펴 봅니다. <15p> 주요 내용  - IT 인프라 환경 현황 - 하이브리드 클라우드 사용 계획 - OSE 선택을 위한 주요 비즈니스 및 기술 고려 사항 - 현재 운영 체제에 대한 만족도 및 OSE 공급업체의 주요 역할

하이브리드 컨테이너 인프라 2021.01.12

“인프라리스 쿠버네티스로 극한의 비용 최적화” 쿠버네티스의 가치를 극대화하는 애플리케이션 중심 인프라 전략 - IDG Tech Dossier

클라우드 네이티브 환경은 탁월한 민첩성과 효율성으로 기업 IT 환경을 빠르게 잠식하고 있다. 하지만 이 가볍고 빠른 애플리케이션을 지원하는 인프라를 구현하는 것은 간단하지 않다. 퍼블릭 클라우드의 유연성을 이용하는 것도 좋은 방법이지만, 한순간의 방심으로 엄청난 요금고지서를 받을 수 있다. 쿠버네티스 환경을 원활하게 지원하는 서버와 스토리지 인프라를 구현하는 것이 왜 어려운지 살펴보고, 넷앱이 제시하는 애플리케이션 중심 인프라를 통해 성능과 가용성, 비용까지 모든 요소를 최적화하는 인프라 전략을 알아본다. 주요 내용 - ADI가 보장하는 인프라 걱정 없는 쿠버네티스 환경 - 쿠버네티스 환경을 위한 엔터프라이즈급 데이터 서비스 ‘프로젝트 아스트라’ - 독보적인 기능으로 클라우드 비용 최대 90% 절감 - 티켓마스터, 스팟으로 비용 줄이며 AWS 도입 가속화 - 근본 원인 파악을 위한 풀스택 모니터링

서버리스 스토리지리스 쿠버네티스 2020.12.31

“속도보다 학습과 협업” 데브옵스 성공 확률을 높이는 넷앱 방법론

기업 조직은 애플리케이션 혁신을 확장하고 시장에 새로운 기능을 제공하기 위해 데브옵스(DevOps) 방법론으로 전환하고 있다. 그러나 데브옵스는 단순한 툴이나 최적화된 워크플로우의 모음이 아니다. 단순히 얼마나 빨리 개발하느냐가 중요한 것이 아니라 얼마나 빠르게 잘 개발하느냐가 중요하다. 데브옵스는 서비스 딜리버리와 더 높은 품질의 혁신을 더 빠른 속도로 달성하기 위해 애자일 방법론이나 린 프로세스를 통합하는 데 초점을 둔 문화적 변화를 가리킨다고도 말할 수 있다. 이에 맞게 넷앱이 데브옵스에 제시하는 방법론은 온프레미스부터 클라우드에 이르는 고객의 소프트웨어 개발 및 데브옵스 파이프라인을 간소화한다.  밴드위스(Bandwidth)의 인프라 아키텍트 제프 스파는 “넷앱은 데이터 패브릭을 사용한 데이터 모빌리티 측면에서 강점이 있고, 지금 우리는 잠재력의 극히 일부만 활용하고 있다. 자동화의 성숙도를 계속 높여 나가는 과정에서 넷앱은 개발자를 위한 단절 없는 환경을 보장하는 동시에 하이브리드 클라우드 효율성을 활용하도록 돕는다”고 평가했다.   일관성과 효율성을 보장하는 데브옵스 환경 넷앱이 제시하는 데브옵스 솔루션은 간략하게 3가지로 말할 수 있다.    소프트웨어 개발 및 데브옵스 파이프라인 프로세스 간소화  빠른 IT 딜리버리 문화 구축  빠른 문제 해결 및 계획 되지 않는 작업 및 재작업 부담 경감 인프라 자동화는 몇 주가 아닌 몇 시간 단위로 개발 환경을 제공할 수 있도록 지원한다. 또한 클라우드 전반에서 애플리케이션 모빌리티를 실현하고 컨테이너를 위한 영구 스토리지를 제공할 수 있다. 휴 네트웍스 시스템의 시스템 엔지니어 지저스 핀토는 “데브옵스에 관심을 갖기 시작했을 때는 가능하리라고 생각하지 못했다. 우리 환경이 너무 복잡하다고 생각했다. 그러나 환경의 여러 부분을 자동화하기 시작하면서부터 확신을 갖게 됐다”고 말했다.   과제와 해법 애플리케이션 개발 속도가 전례 없는...

넷앱 데브옵스 하이브리드클라우드 2020.12.18

하이브리드 쿠버네티스 애플리케이션 생태계를 향한 넷앱의 도전장 ‘프로젝트 아스트라’

엔터프라이즈 컴퓨팅 환경은 빠르게 애플리케이션 현대화의 길을 걷고 있다. 그리고 이 중심에는 쿠버네티스 기반 컨테이너 환경이 있다. 쿠버네티스는 레거시 애플리케이션을 클라우드 기반 환경으로 이전하는 징검다리이자, 마이크로서비스 아키텍처 기반의 클라우드 네이티브 애플리케이션 개발의 토대이기도 하다. 이런 이유로 많은 기업이 컨테이너 기반 인프라 현대화 여정에 박차를 가하고 있다. 쿠버네티스 클러스터 구축과 운영을 확대할 때 기업이 직면하는 가장 큰 도전 과제로 데이터 관리를 꼽는다. 이것이 바로 넷앱이 ‘프로젝트 아스트라(Astra)’를 시작한 이유다.      쿠버네티스 클러스터를 위한 데이터 관리와 보호 대책 절실  엔터프라이즈의 쿠너베티스 활용 전략의 핵심은 특정 서비스와 기술 종속 없이 하이브리드, 멀티 클라우드 환경에서 현대화된 애플리케이션을 개발, 배포, 운영하는 것이다. 개발부터 운영까지의 흐름은 데브옵스(DevOps)를 바탕으로 이어진다. 이를 위해 전통적인 CI/CD 파이프라인 역시 클라우드 시대에 맞게 빠르게 재편하는 조직이 늘고 있다.  쿠버네티스가 제공하는 범용성, 이식성, 이동성의 특징을 살리는 쪽으로 개발과 운영 전략이 바뀌고 있는 가운데 관리자가 풀지 못한 고민이 하나 있다. 바로 데이터 관리와 데이터 보호 대책 마련이다. 엔터프라이즈 워크로드는 온프레미스나 클라우드나 모두 고가용성 구성을 전제로 복원력과 탄력성을 보장하는 것이 매우 중요하다. 이를 위한 핵심 관리 활동인 데이터 관리와 보호는 전통적인 스토리지 기술과 개념으로는 접근에 제약이 있다. 이를 해결하기 위해 등장한 개념이 프로젝트 아스트라다.  아스트라는 완전 관리형 SaaS 서비스다. 이 서비스를 이용하면 조직은 컨테이너 기반 워크로드에 대한 데이터 관리를 간편히 수행할 수 있다. 쿠버네티스 클러스터의 위치는 따지지 않는다. 온프레미스, AWS, GCP, Azure 등 어디건 SaaS를 이용해 쿠버네티스 클러스터...

넷앱 컨테이너 쿠버네티스 2020.12.18

업계 최초, 업계 유일의 AI 기반 애플리케이션 현대화 도구, Mono to Micro

아직도 엔터프라이즈 워크로드의 80%는 온프레미스에 존재하며, 클라우드에 최적화되지 못했습니다. 비즈니스 애플리케이션 현대화를 위한 가장 좋은 방법은 마이크로서비스로의 리팩토링입니다. 하지만 기존 애플리케이션의 마이크로서비스 리팩토링은 기존 코드를 분석할 수 있는 수준 높은 이해와 분석 능력을 필요로 하고, 반복적인 수동 작업이 많고, 아키텍처의 재구성이나 재구현이 필요하기도 합니다. AI 기술을 통해 자동화할 수 있다면 어떨까요? IBM의 AI 기반 애플리케이션 현대화 도구인 M2M(Mono to Micro)로 더욱 쉽고 빠르게 클라우드 환경에 최적화된 클라우드 네이티브로 진화할 수 있습니다. <3P>   주요 내용 - IBM Mono2Micro 소개 - 비즈니스 로직 기반 그룹화 - 데이터 종속성 및 자연스러운 이음새 기반 그룹화 - IBM Cloud Pak for Applications

Mono2Micro AI MSA 2020.12.10

클라우드를 향한 여정의 길잡이 - IBM Cloud Pak for Applications

기업의 애플리케이션 현대화는 방대하고 지속적인 과정입니다. 조사 결과, 번거롭고 복잡한 현대화 여정 때문에 전체 워크로드의 20%만 클라우드로 전환된 상태입니다. IBM Cloud Pak for Applications에 포함된 IBM Transformation Advisor는 리플랫폼, 리패키징, 리팩토링 중 애플리케이션에 가장 적합한 방법을 파악하고, 대체 플랫폼, 시간과 난이도 등의 절감 효과를 추산합니다. 마이그레이션 전에 먼저 정확한 공수를 파악하고 비교할 수 있으며, 빠르게 새로운 애플리케이션을 빌드하고 배포할 수 있습니다.  정확한 분석에 기반해 쉽고 민첩한 기업의 현대화 여정을 지원하는 IBM Cloud Pak for Applications에서 제공하는 Transformation Advisor의 특징과 장점을 알아보세요. <9P>   주요 내용 - 리플랫폼과 리패키징 개념 설명 - 클라우드 네이티브 개발을 위한 리팩토링 단계 및 절감 효과 - 클라우드 네이티브 개발을 위한 리패키징 단계 및 절감 효과 - 애플리케이션 배포 후 CI/CD 효율성 - IT팀이 Cloud Pak for Applications로 누릴 효과

앱현대화 클라우드 네이티브 Cloud Pak for Applications 2020.12.10

IBM Power Systems에 OpenShift 컨테이너 환경 구축하기

클라우드 환경에서 빠른 개발과 서비스 적용을 위해 컨테이너가 매우 중요한 요소가 되었습니다. 컨테이너는 일종의 가상머신으로 기본적으로 영구 스토리지를 지원하지 않고 OS를 가상화하지 않기 때문에 매우 가볍고 빠른 배포가 가능하며, 서비스 단위의 모듈화도 가능합니다. 오늘 이 영상에서는 코드로써 인프라를 관리하고 그렇게 만들어진 OpenShift 클러스터의 pv(persistent volume)를 PowerVC의 볼륨으로 연결해보는 데모를 진행해보겠습니다. Terraform과 Ansible을 사용해 코드로써 인프라를 관리하고, 생성된 OpenShift 클러스터의 pv로 PowerVC의 볼륨을 붙여보는 데모로 이런 구조를 통해 OpenShift 내부의 컨테이너들은 OpenShift가 관리하고, OpenShift 클러스터 자체는 PowerVC에서 관리할 수 있게 됩니다. <15분>

PowerSystems 오픈시프트 컨테이너 2020.11.30

컨테이너가 위기에서 빛나는 3가지 이유

리눅스 컨테이너는 변화의 시기에 유연하고 민첩하고 안전한 개발 환경을 제공한다. 위기가 닥쳤을 때 오히려 번창하는 사람이 있다. 이런 사람은 주위에서 무슨 일이 일어나도 맡은 일 이상을 해내는 능력이 있을 뿐만 아니라 어려운 상황에서 기회를 찾아내고 주변 사람을 최대한 돕는다. 누구라도 조직 내에 이런 위기 극복 챔피언이 있어서 조직을 이끌어 주기를 바랄 것이다.   기술 중에도 이런 것이 있다. 어떤 기술은 평상시에는 충분히 잘 동작하다가 압박을 받으면 무너지고 만다. 이때 기술 세계의 위기 극복 챔피언이 등장한다. 이런 기술은 상황이 어떻든 맡은 바 임무를 계속 수행하는 것은 물론, 가장 압박이 심한 새 요구사항을 충분히 만족할 만큼 유연하고 복구성이 좋다. 리눅스 컨테이너와 쿠버네티스 생태계가 대표적인 예다. 위기라는 말은 과거에도 너무 많이 사용됐지만, 만약 세상이 “극심한 어려움과 곤란, 위험”의 시기에 처한다면 지금이 바로 그때이다. 코로나19 팬데믹이 사회의 근간을 바꿔 놓으면서 사람이든 제품이든 위기 극복 챔피언이 필요한 상황이다. 물론 리눅스 컨테이너가 세상의 모든 문제를 당장 고칠 수 있다는 말은 아니다. 하지만 이 기술은 조직의 생존뿐만 아니라 힘든 시기에도 번창할 수 있도록 지원할 잠재력이 있다.  컨테이너가 어떻게 위기 상황에 도움이 되는지 알기 위해 컨테이너에 대한 단순한 설명부터 시작하자. 쉽게 말해 리눅스 컨테이너란 다른 시스템과 격리된 일련의 프로세스이다. 프로세스를 실행하는 데 필요한 파일은 개별적인 이미지로 제공되는데, 이런 모델 덕분에 컨테이너는 개발과 테스트, 프로덕션 전반에 걸쳐 이식성과 일관성을 유지한다. 위기에서 컨테이너가 제공하는 세 가지 큰 이점은 다음과 같다.   컨테이너는 정말 민첩하다.  변화는 언제나 있는 것이지만, 2020년에는 전혀 새로운 수준의 변화가 찾아왔다. 코로나19 팬데믹이 발발한 지 몇 개월 만에 기업은 공급망과 일터, 공급하는 제품과 서비스의 종...

컨테이너 쿠버네티스 리눅스 2020.11.24

서비스 메시가 데이터센터 네트워킹에서 중요한 이유

마이크로서비스에 의존하는 애플리케이션은 데이터센터 인프라와 관리자에게 많은 것을 요구하지만, 서비스 메시(Service Mesh)는 인력의 지속적인 개입 없이도 마이크로서비스 간의 라우팅 요청을 최적화할 수 있다. 마이크로서비스 방식의 애플리케이션은 신속하고 안정적인 응답을 위해 빠르고 믿을 수 있는 네트워크 인프라에 의존하며, 서비스 메시는 이를 가능하게 하는 강력한 도구가 된다. 이와 함께 서비스 메시 인프라는 대규모 환경에서는 배치와 관리가 어려울 수 있고, 작은 규모의 애플리케이션용으로는 너무 복잡할 수도 있다. 따라서 기업은 특정 환경과 관련해 서비스 메시의 장단점을 신중하게 고려할 필요가 있다.   서비스 메시란? 서비스 메시는 애플리케이션이 필요로 하는 마이크로서비스 간의 빠르고 안정적인 커뮤니케이션을 제공하는 인프라 소프트웨어이다. 서비스 메시의 네트워킹 기능에는 애플리케이션 인식, 로드 밸런싱, 인증, 암호화 등이 있다. 네트워크 요청은 서비스와 함께 구동하는 프록시를 통해 마이크로서비스 사이로 라우팅된다. 이들 프록시는 그물형 네트워크를 형성해 개별 마이크로서비스를 연결한다. 중앙의 컨트롤러는 네트워크 및 성능 관리는 물론, 액세스 제어 기능도 제공한다. 서비스 메시는 마이크로서비스 애플리케이션을 네트워크 라우팅 및 보안 요구사항의 복잡성으로부터 논리적으로 격리한다. 서비스 메시가 제공하는 추상화는 데이터센터 네트워킹팀이 지속적으로 개입하지 않아도 되기 때문에 빠르고 유연하게 마이크로서비스를 배치할 수 있다. 마이크로서비스 기반 앱에 서비스 메시가 필요한 이유 마이크로서비스를 기반으로 하는 애플리케이션은 하이퍼바이저 기반 애플리케이션과 아키텍처가 다르다. 이들 앱은 서로 다른 서버나 코어 상에서 개별적인 컨테이너로 구동되는 수많은 서비스를 가지고 있다. 그리고 단일 애플리케이션 내에서 이들 마이크로서비스 간의 잦은 트랜잭션 때문에 낮은 지연과 상당한 대역폭이 필요하다. 게다가 하나 이상의 애플리케이션이 같은 마이크로서비스에...

서비스메시 마이크로서비스 컨테이너 2020.10.08

나머지 80%의 선택은? 현실적인 클라우드 여정

IBM 퍼블릭 클라우드 총괄 책임자인 Harish Grama를 통해, 워크로드의 전환, 관리 및 실행에 대한 자세한 이야기와 함께 가트너 피어 인사이트를 통해 고객 최고의 피드백을 받은 IBM 퍼블릭 클라우드의 경쟁력에 대해 확인해보세요. <16분>

개방형 엔터프라이즈급 레드햇 2020.09.22

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

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

Copyright © 2022 International Data Group. All rights reserved.