int(0)
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.

컨테이너

2020년 3분기 멀티클라우드 컨테이너 개발 플랫폼 평가 : Forrester Wave

Forrester Research는 고객 분석 기술에 대한 29가지 기준 평가에서 가장 뛰어난 8개 업체(Canonical, D2iQ, Google, Mirantis, Platform9 Systems, Rancher, Red Hat-IBM, VMware)를 선정하고, 이들 업체를 연구 및 분석한 후 점수로 평가했습니다. 이 보고서는 각 공급업체를 측정한 방법을 설명하고 인프라 및 운영 전문가가 요구 사항에 맞는 업체를 선정할 수 있도록 지원합니다. <15p> 주요 내용 - 선두를 달리는 Red Hat-IBM, Google, Rancher - 주요 차별점: 개발 경험, 분산 운영 및 에코시스템 통합 - 공급업체 제품 및 프로필 - 평가 개요 : 공급업체 포함 기준  

멀티클라우드 컨테이너 포레스터 2021.07.15

컨테이너 및 쿠버네티스 보안에 대한 계층화된 접근 방식

컨테이너는 애플리케이션과 그 종속 요소를 단일 이미지로 패키징하여 개발에서 테스트, 프로덕션에 이르는 전 과정에서 활용할 수 있다는 장점 때문에 광범위하게 사용되고 있습니다. 컨테이너를 사용하면 물리 서버, VM(가상 머신), 프라이빗 클라우드 또는 퍼블릭 클라우드와 같은 다양한 배포 대상과 환경에 걸쳐 일관성을 쉽게 유지할 수 있습니다. 쿠버네티스는 기업용 컨테이너 오케스트레이션 플랫폼입니다. 많은 조직에서 컨테이너를 사용하여 필수 서비스를 실행하는 오늘날, 컨테이너의 보안 유지는 무엇보다 중요한 문제입니다. 이 문서에서는 컨테이너화된 애플리케이션을 위한 핵심 보안 요소에 대해 설명합니다. <16p> 주요 내용 - 컨테이너와 쿠버네티스의 포괄적 보안: 계층 및 라이프사이클 - 애플리케이션 자체에 보안 구축 - 배포: 배포에 필요한 구성, 보안 및 컴플라이언스 관리 - 실행 중인 애플리케이션 보호 - 강력한 에코시스템으로 폭넓은 보안 범위 제공  

컨테이너 쿠버네티스 보안 2021.07.15

'레거시와 클라우드의 연결' 꾀하는 모던 APM의 중요성

엔터프라이즈 애플리케이션 개발, 운영, 배포 방식은 세대를 거듭하면서 더 효율적이고 빠른 방향으로 발전하고 있다. 최근 추이는 서버리스(serverless) 환경에서의 데브옵스(DevOps) 파이프라인 운영을 목표로 삼는 것이다. 이와 관련해 레거시 시스템을 컨테이너 기반 환경으로 옮겨 애플리케이션 현대화의 첫 삽을 뜨고, 이후 신규 개발 시스템을 마이크로서비스 아키텍처 환경에서 클라우드 네이티브 방식으로 개발하고 운영하는 로드맵을 따르는 곳이 많다. 이런 흐름 속에서 APM(Application Performance Management)은 어떤 역할을 하면서 가치를 인정받고 있을까?   복잡성 높을 수록 모니터링 중요성도 커져  APM의 등장 배경을 보면 예나 지금이나 도전 과제가 비슷하다. 쓰리 티어(3 Tier) 구조의 웹 기반 컴퓨팅이 자리를 잡았을 때를 떠올려 보자. 눈에 보이던 것들이 보이지 않게 되면서 복잡성이 커졌다. 계층화된 컴퓨팅 환경에서 일관성 있게 성능을 보장하려면 가시성을 확보해야 한다. 이를 해결하기 위해 등장한 것이 APM이었다. 지금은 어떠한가? 모놀리식 구조의 스택이 마이크로서비스 아키텍처 환경으로 바뀌면서 기능은 더 작은 단위로 쪼개졌고, 인프라와 플랫폼의 추상화 수준은 더욱 높아졌다. 마이크로서비스 환경 구축 시 현장에서 복잡성과 가시성 문제를 호소하는 이유다. 이 문제 역시 해결책은 APM에서 찾을 수 있다.    동적 환경 모니터링까지 소화하는 APM  LG CNS의 APM 솔루션인 TunA와 같은 현대화된 APM은 마이크로서비스 아키텍처 환경에 대한 모니터링까지 기술적, 기능적으로 고려한다. 컨테이너 플랫폼에 배포, 운영하는 애플리케이션은 동적인 특성을 띤다. 안정화를 거친 후 큰 변화 없이 운영하는 모놀리식 구조의 애플리케이션과는 아주 다르다. 생성과 소멸을 빠른 주기로 반복하며, 필요에 따라 자유롭게 사내와 사외 컨테이너 환경 사이를 이동하기도 한다. 쉽게 말해 애플리케이...

LG CNS APM 마이크로서비스 2021.07.08

사일로스케이프, 윈도우 컨테이너 넘어 쿠버네티스 클러스터에 백도어 설치

클라우드 컨테이너를 대상으로 한 악성코드 공격은 새롭지는 않지만 지금까지는 리눅스 환경을 집중적으로 노렸다. 리눅스가 가장 보편적인 운영체제이며, 컨테이너가 탄생한 곳이기도 하기 때문이다. 그런데 이제는 윈도우의 도커(Docker) 환경을 표적으로 하는 공격이 일어나고 있다. 윈도우 서버 컨테이너에서 벗어나 쿠버네티스(Kubernetes) 클러스터를 감염시키도록 만들어진 새로운 악성코드 프로그램이 발견됐다. 사일로스케이프(Siloscape)로 불리는 이 악성코드는 상당한 수준으로 난독화되어 있으며, 거의 알려지지 않은 윈도우 컨테이너 이스케이프 기법을 사용하고 명령 제어 통신에는 토어(Tor)를 사용한다. 사일로스케이프의 목적은 쿠버네티스 노드와 클러스터에 대한 접근 권한을 획득한 후 공격자의 후속 명령을 대기하는 것이다. 도커 및 윈도우 서버 컨테이너 도커와 쿠버네티스는 클라우드 인프라에 컨테이너화된 애플리케이션을 배포하기 위한 주된 기술이다. 또한 현대 소프트웨어 개발에서 마이크로서비스 아키텍처의 인기를 이끈 직접적인 이유이기도 하다. 마이크로서비스 아키텍처에서는 소프트웨어가 각자의 안전한 컨테이너에서 독립적으로 실행되는, 느슨하게 결합된 복수의 서비스로 분할된다. 도커는 컨테이너를 설정하는 데 사용되는 기술로, 리눅스 커널에 탑재된 커널 기반 가상화 기능을 기본으로 한다. 쿠버네티스는 네트워크(클러스터)로 그룹화되는 여러 호스트(노드)에 걸쳐 이러한 컨테이너와 컨테이너 안에서 실행되는 애플리케이션을 관리하는 데 사용된다. 두 플랫폼이 소프트웨어 개발과 배포에서 엄청난 인기를 끌자 마이크로소프트는 윈도우 서버에서도 도커와 쿠버네티스 실행이 가능하기를 원했지만 리눅스에서 컨테이너가 동일한 커널을 공유할 수 있게 해주는 몇몇 프로세스와 파일시스템 격리 기능이 윈도우 커널에는 없었다. 마이크로소프트는 이런 기능 가운데 일부를 개발해 윈도우 서버 2016에 처음으로 통합해 윈도우 컨테이너라는 기능을 구현했다. 윈도우 컨테이너는 2가지 격리 모드를 지원...

사일로스케이프 윈도우 컨테이너 2021.06.15

“유지보수 비용 절감하고 관리 효율화”··· 충남대학교 클라우드 기반 정보 인프라 구축 사례 - IDG Case Study

충남대학교가 인텔Ⓡ 제온Ⓡ 플래티넘 9242 프로세서를 탑재한 인텔Ⓡ 9200WK 서버 시스템과 티맥스 하이퍼클라우드를 기반으로 클라우드 기반 정보 인프라를 구축했다. 구축 작업을 마친 현재는 이전 단계를 진행하고 있다. 프라이빗 클라우드로 학내 모든 정보 시스템을 통합한 건 국내 대학에서는 유일하다. 쉬운 일은 아니었다. 참고할 만한 선례가 없었기에 모든 걸 처음부터 만들어가야 한다는 부담이 있었다. 2020년 12월 착수해 기본 설계부터 클라우드 정보 보안 체계까지 구축했던 해당 프로젝트는 2021년 4월 결실을 맺었다. 충남대가 인텔Ⓡ 프로세서와 티맥스 클라우드의 조합으로 정보 인프라를 직접 구축하고 차별화된 경쟁력을 확보하기까지의 과정을 살펴본다.  주요 내용  - “자체 클라우드 기반 정보 인프라가 필요했다” - 인텔Ⓡ 프로세서+티맥스 클라우드를 선택한 이유 - 비즈니스를 위한 탁월한 조합  

인텔 티맥스 인텔 제온 2021.06.02

IDG 블로그 | 쿠버네티스를 좀 더 공격적으로 이용해야 하는 이유

쿠버네티스 활용이 폭발적으로 증가했다는 것은 더 이상 비밀도 아니다. VM웨어가 이런 쿠버네티스를 적극적으로 활용하는 247곳을 설문조사한 “2020년 쿠버네티스 현황 보고서”를 발표했다. 조사에 참여한 응답자는 대부분 대형 개발팀으로, 개발자가 2,500명 이상인 곳도 24%이다.   이 보고서는 개발팀이 여전히 주요 의사결정권자라는 것을 보여주는데, 38%는 개발팀이 쿠버네티스 기술 사용을 결정했다. 57%는 10개 이하의 쿠버네티스 클러스터를 운영하며, 59%는 쿠버네티스를 프로덕션 환경에 사용한다. 50개 이상의 쿠버네티스 클러스터를 운영하고 곳은 20%였다. 이 보고서에서 유추할 수 있는 것은 쿠버네티스가 아직은 초기 단계라는 것이다. 비록 쿠버네티스가 광범위하게 사용되고 있지만, 많은 프로젝트가 쿠버네티스를 제한된 방식으로 사용한다. 게다가 많은 쿠버네티스가 클라우드에 배치되어 있지 않다. 온프레미스 환경에 쿠버네티스를 배치한 비율이 60%, 클라우드에 배치한 배율은 42%에 불과했다. 필자에게는 다소 놀라운 결과이다. 쿠버네티스는 불과 5년 만에 스스로 플랫폼이 되었으며, 견실한 기술 생태계를 구축하고 매월 수많은 쿠버네티스 개발자와 아키텍트를 배출하는 교육 기반이 되었다.  그렇다면, 이제 쿠버네티스를 다음 단계로 발전시키려면 어떻게 해야 할까? 어떤 기술이라도 아기 걸음마처럼 신중하게 단계를 진행하는 것이 좋지만, 지금은 쿠버네티스의 좀 더 공격적인 사용례를 찾아 나서도 될 시점이다. 또한 쿠버네티스가 멀티클라우드의 숨 막히는 복잡성을 제거할 수 있는지도 확인해야 한다. 필자는 멀티클라우드가 쿠버네티스의 성장에 가장 큰 장애물이라고 생각한다. 다음은 쿠버네티스를 배치해야 할 몇 가지 문제 패턴이다.   제일 큰 문제. 여러 클라우드 브랜드의 클라우드 페더레이션(Federation). 이는 AWS와 구글, 구글과 애저처럼 하나 이상의 클라우드 브랜드에 걸쳐 연합된 쿠버네티스 배치를 사용하는 것을 의미한다...

쿠버네티스 컨테이너 사용례 2021.05.12

깃옵스가 '아직' 주류로 부상할 준비가 되지 않은 이유

깃옵스(Gitops)는 2017년 처음 고안된 이후, 특히 요즘 유행하는 분산 컨테이너 전반에 배포되고 쿠버네티스(Kubernetes)에 의해 조율되는 마이크로서비스를 구축하는 기업에서 데브옵스, 코드형 인프라, CI/CD 원칙과 같은 현대 소프트웨어 개발 방식의 자연스러운 발전 방향으로 부상했다. 그러나 업계에서 깃옵스가 애자일 및 데브옵스가 지금까지 이룬 규모의 주류 기술로 채택되기 위해서는 업계가 극복해야 할 여러 중대한 문화적, 기술적 장애물이 아직 남아 있다.   깃옵스란 무엇인가? 깃옵스는 데브옵스를 더욱 확장해 코드를 인프라로 다뤄 애플리케이션과 기반 인프라가 코드로 취급되고 버전 제어 시스템(주로 깃)에 저장되어 개발자와 운영자에게 단일 진실 공급원(single source of truth)을 제공할 수 있도록 한다. 제대로 구현되면 모든 변경 사항이 선언형 코드를 통해 푸시되고, 바람직한 상태로부터 이탈되는 경우 자동화된 단계를 통해 교정된다. 이론적으로는 흠잡을 데가 없지만, 펠로톤(Peloton), 볼보(Volvo), 티켓마스터(Ticketmaster), 저스트 잇 테이크어웨이닷컴(Just Eat Takeaway.com) 등 깃옵스 방식을 테스트 중인 것으로 알려진 기업 가운데 어느 한 곳도 현재 단계에 대해 본지와의 인터뷰에는 응하지 않았다.  IDC의 데브옵스 솔루션 부문 연구 책임자인 짐 머서는 “깃옵스 이니셔티브를 도입 중인 기업과 대화를 해본 적이 없다. 내가 대화를 나눈 기업은 깃옵스라는 말을 들어본 적도 없는 경우가 대부분”이라고 말했다. 2018년 컨테이너 기술 전문업체 애플라틱스(Applatix)를 인수한 후 깃옵스 조기 도입 기업이 된 핀테크 업체 인튜이트(Intuit)의 내부 개발자 플랫폼 부문 제품 관리 책임자인 무쿨리카 카파스는 “깃옵스의 성숙도는 여전히 초기 단계”라고 말했다. 그보다는 소규모 클라우드 네이티브 기업이 소프트웨어 제공 프로세스를 개선하기 위한 깃옵스의 가능성을 탐색하기...

깃옵스 Gitops 컨테이너 2021.05.12

"너무 복잡해" 쿠버네티스 관리, 아무도 원하지 않는 이유

쿠버네티스 관리는 결코 쉽지 않다. 많은 조직이 컨테이너 오케스트레이션 책임의 상당 부분을 관리형 서비스 제공업체에 넘기고 해결이 필요한 다른 엔지니어링 문제에 집중하는 것이 낫다는 것을 깨닫고 있다.   현재 가장 인기 있는 관리형 쿠버네티스 옵션(서비스형 쿠버네티스, 즉 KaaS라고 하기도 함)은 아마존 엘라스틱 쿠버네티스 서비스(EKS), 애저 쿠버네티스 서비스(AKS), 구글 쿠버네티스 엔진(GKE)이다. 각 클라우드 제공업체는 2018년 처음 출시한 이후 GKE 오토파일럿(Autopilot), 서버리스 EKS 파게이트(Fargate) 등 이와 같은 서비스의 관리형 버전을 계속해서 늘리는 중이다. 랜처(Rancher), 레드햇 오픈시프트(OpenShift), VM웨어 탄주(Tanzu) 같은 옵션도 있지만 빅3 클라우드 업체가 지배적인 위치에 있다.   클라우드 업체들은 고객이 필요한 요소를 제어하고 통합하도록 허용하는 것과 까다로운 자동 확장, 업그레이드, 구성 및 클러스터 관리 작업을 추상화하는 것 사이에서 적절한 균형점을 찾기 위해 노력해왔다. 이와 같은 관리형 서비스가 성숙하면서 자체 쿠버네티스 클러스터가 부담이 되고 갈수록 더 불필요해지는, 차별화와도 무관한 작업이 되고 있음을 인식하게 된 조직도 많다.   쿠버네티스 공동 창안자이며 VM웨어 탄주 수석 엔지니어인 조 베다는 “오픈소스 바이너리를 다루며 직접 툴을 만드는 경우는 상당히 극단적인 사례다. 정말 독특한 방식으로 쿠버네티스를 사용하는 경우가 아닌 한 지금은 그렇게 할 이유가 거의 없다”고 말했다.   아마존 웹 서비스의 컴퓨팅 서비스 부문 부사장인 디팩 싱은 “쿠버네티스를 직접 운용할 수 있는 강력한 엔지니어링과 운영 역량을 갖춘 조직이라면 예외에 해당하겠지만 대부분의 고객에 쿠버네티스 직접 관리는 벅찬 일이 됐다. 쿠버네티스 확장에 따르는 과제, 제어 평면, API 계층, 데이터베이스 관리의 복잡함 등은 결코 쉬운 일이 아니다”라고 말했다. &nbs...

쿠버네티스 오픈시프트 KaaS 2021.04.15

컨테이너의 도입 : 민첩하고 유연한 소프트웨어 정의 하이브리드 클라우드 인프라

컨테이너와 쿠버네티스 기술이 널리 보급되면서 애플리케이션 위치에 상관없이 클라우드 환경에서 애플리케이션을 개발하고 배포하는 새로운 방식이 등장하게 되었습니다. 이러한 기술은 다양한 조직과 애플리케이션 전반에서 이미 디지털 트랜스포메이션과 애플리케이션 현대화 작업을 가속화하고 있습니다. Red Hat OpenShift는 엔터프라이즈용 컨테이너와 쿠버네티스를 혁신하고 패키징하여 애플리케이션의 프로비저닝, 관리 및 확장을 자동화할 수 있으므로, 개발자는 새로운 아이디어를 실현하기 위한 코드 작성에 집중할 수 있습니다. <6p> 주요 내용 - 가상화를 뛰어넘는 혁신: - 컨테이너가 제공하는 다양한 비즈니스이점 - IT 팀의 디지털 트랜스포메이션 가속화 지원 - 하이브리드 및 멀티클라우드 배포를 위한 Red Hat OpenShift

컨테이너 하이브리드 멀티클라우드 2021.04.14

멀티클라우드 컨테이너 개발 플랫폼 8대 공급업체 및 선정 이유 : 포레스터 리서치

Forrester Research는 고객 분석 기술에 대한 29가지 기준 평가에서 가장 뛰어난 8개 업체(Canonical, D2iQ, Google, Mirantis, Platform9 Systems, Rancher, Red Hat-IBM, VMware)를 선정하고, 이들 업체를 연구 및 분석한 후 점수로 평가했습니다. 이 보고서는 각 공급업체를 측정한 방법을 설명하고 인프라 및 운영 전문가가 요구 사항에 맞는 업체를 선정할 수 있도록 지원합니다. <15p> 주요 내용 - 개발 경험, 운영 및 통합에서 차별화되는 공급업체 - Red Hat-IBM, Google, Rancher - VMware, D2iQ, Platform9 Systems - Mirantis, Canonical

멀티클라우드 컨테이너 포레스터 2021.04.14

“디지털 혁신의 성패를 결정한다” 하이브리드 클라우드를 위한 컨테이너 플랫폼 가이드 - IDG Tech Insight

컨테이너의 확산과 함께 기업 IT 인프라가 하이브리드 클라우드 환경으로 빠르게 진화하고 있다. 컨테이너의 탁월한 효율성과 이동성이 퍼블릭 클라우드와 온프레미스 클라우드 간의 매끄러운 연결을 위한 해법으로 부상하면서 한 가지 기술에 승부를 걸기 보다는 다양한 기술을 적재적소에 배치해 더 효과적인 환경을 구현할 수 있기 때문이다. IT 인프라의 최종 목적지로 평가되는 하이브리드 클라우드 관점에서 컨테이너 기술의 역할과 조건을 살펴보고, 최적의 컨테이너 플랫폼과 인프라를 구축하는 방법을 제시한다. 주요 내용 - 컨테이너를 사용해 디지털 트랜스포메이션 속도를 높이는 4가지 방법 - 하이브리드 멀티클라우드가 기술적으로 더 유리한 시나리오 - 하이브리드 클라우드를 위한 컨테이너 플랫폼의 조건과 HPE 에즈메랄 - “클라우드 시대 서버 관리에 필수” 코드형 인프라의 이해 - 클라우드 네이티브 환경을 위한 인프라의 조건과 HPE 시너지

컨테이너 클라우드네이티브 쿠버네티스 2021.04.05

독일 물류회사 슈넬레케, IoT 컨테이너로 투명한 공급망 구현

슈넬레케 그룹(Schnellecke Group)은 독일 볼프스부르크에 본사를 둔 국제 물류 서비스 회사이다. 이 그룹의 슈넬레케 로지스틱스(Schnellecke Logistics)는 특히 자동차 산업을 위한 서비스에 중점을 두고 있다. 슈넬레케는 2020년 독일 디지털 리더 어워드에도 참여한 곳으로, JiT(Just in Time) 또는 JiS(Just in Sequence)가 일상 업무의 일부로 자리 잡고 있다.   슈넬레케는 기존의 JiT와 JiS 프로세스를 새로운 수준으로 높여 프로세스 흐름 초기에 발생할 수 있는 문제를 파악해 해결하고자 했다. 이런 슈넬레케의 디지털 물류 전략에서 지능형 운송 컨테이너가 중요한 역할을 맡았으며, 새로운 디지털 비즈니스 모델의 기반을 마련하는 효과도 가져왔다.   비용 요소로서의 운송 컨테이너 운송 컨테이너는 비싸고 무시할 수 없는 비용 요소이다. 슈넬레케가 손실을 방지하기 위해 이들 컨테이너를 가능한 한 효율적으로 사용하고자 하는 것도 이런 이유이다. 여기에 더해 고객사가 컨테이너가 부족해 슈넬레케에 새로운 컨테이너를 요청하는 일도 잦았다. 이런 요청은 고객사의 현장에서 사용하지 않는 컨테이너의 위치를 찾는, 시간이 많이 드는 작업으로 이어졌다. 더 까다로운 것은 이런 작업이 현장에서만 기록되는 것이 아니라 때로는 서류 수작업도 필요하다는 것. 컨테이너를 찾으면, 관련 정보는 전화나 이메일을 통해 전달되었다. 기존 방식으로는 실시간 컨테이너로의 전환 계획은 실현 가능성이 낮았고, 공급망 추적은 말할 것도 없었다. 자동으로 컨테이너 데이터를 기록하고 실시간으로 처리하는 것이 가장 자연스러운 방안으로, 고객사는 컨테이너와 자사의 제품을 생산 현장의 조립라인에서 추적할 수 있게 된다.     기존 슈넬레케 IX+ 생태계와의 통합 물론 시장에는 이런 요구에 대응하는 솔루션이 있었지만, 슈넬레케 로지스틱스의 요구사항을 온전히 만족하지는 못했다. 슈넬레케가 원하는 시스템은 모듈식 구조...

IoT 공급망 컨테이너 2021.03.31

“사람과 프로세스를 위해” 컨테이너에도 표준 운영 환경이 필요한 이유

“컨테이너 안녕? 나는 네 표준 운영 환경인 SOE야. 혹시 나를 기억하니? 물론 못하겠지. 네 덕분에 모든 사람들이 고도로 자동화된 애플리케이션 모음을 구축, 관리, 유지하는 역량에 부정적인 영향을 미치지 않으면서 아무 때나, 아무 기술이라도 사용할 수 있다고 믿게 되었으니까. 그렇지 않다는 걸 너는 알겠지. 그건 사실이 아니야. 너에게는 내가 필요하고, 기업에도 내가 필요해. 같이 예전으로 돌아가자.” 그리 멀지 않은 과거에는 모두가 표준 운영 환경(Standard Operating Environment, SOE)을 사용했다. 일반적으로 SOE는 기본 운영체제(커널 및 사용자 공간 프로그램), 맞춤형 구성 파일, 조직 내에 사용되는 표준 애플리케이션, 소프트웨어 업데이트, 서비스 팩을 포함하며, 운영 환경의 보안을 강화하고 프로세스를 간소화하고 코드를 자동화하도록 설계된다. 관리자는 SOE를 조직 내의 대규모 배포를 위한 디스크 이미지, 킥스타트 또는 가상머신 이미지로 구현한다.  SOE는 서버, 데스크톱, 노트북, 씬 클라이언트, 모바일 디바이스, 컨테이너 디바이스에 적용할 수 있다. 물론 컨테이너 이미지에도 해당된다. 사실 SOE는 컨테이너화된 애플리케이션을 배포, 구성, 유지, 지원, 관리하는 데 소요되는 시간을 줄여줄 수 있다.  그런데 컨테이너가 사실상 SOE를 버린 이유는 무엇일까?  잃어버린 표준  일각에서는 표준화가 혁신에 방해가 되고 대체로 개발 및 배포 프로세스의 속도를 저하시킨다고 주장한다. 그러나 생각해볼 점이 있다. 개발팀은 코드 품질과 구문, 나아가 노트북에서 새로운 개발 환경을 설정하는 방법까지 자연스럽게 표준을 둔다는 점이다. 느린 것이 꾸준하고, 꾸준한 것이 순조롭고, 순조로운 것이 빠르다는 말이 있다. 컨테이너 기본 이미지를 표준화하면 개발자의 작업 속도를 높이는 데 도움이 될 수 있다.  또한 표준화가 보안을 강화한다는 데는 이론의 여지가 없다. 하지만 SOE 반대론자는...

컨테이너 표준운영환경 SOE 2021.03.22

클라우드 네이티브 환경을 위한 애플리케이션 딜리버리 전략 : 국내 게임사 사례 - IDG Summary

클라우드 네이티브 환경이 확산하면서 애플리케이션 딜리버리의 현대화가 주요 과제의 하나로 떠올랐다.  수많은 마이크로서비스를 원활하게 다루어야 하고 잦은 업데이트 릴리즈도 매끄럽게 소화해야 하기 때문이다. 특히 네트워크는 마이크로서비스 기반 애플리케이션의 모든 서비스 요청과 연결을 위한 공기와 같은 존재이다. 이 때문에 애플리케이션 딜리버리의 핵심 요소로 ADC(Application Delivery Controller)가 주목을 받고 있다. 애플리케이션 딜리버리 관점에서 클라우드 네이티브 환경의 주요 특징과 해결과제, 핵심 아키텍처를 살펴보고, 국내 대형 게임사의 실제 사례도 소개한다.  주요 내용 - 클라우드 중심 애플리케이션 딜리버리의 과제 - ADC를 이용한 네 가지 애플리케이션 딜리버리 아키텍처 - 국내 게임사 A 사례 : 개발자의 희망대로 구현되는 클라우드 네이티브 구현 - “현황부터 원인 분석까지” 클라우드 네이티브 관찰성의 조건 - 클라우드 네이티브를 완성하는 애플리케이션 딜리버리 현대화

클라우드네이티브 마이크로서비스 컨테이너 2021.03.16

채널계와 계정계에 컨테이너 기반 클라우드 플랫폼 구축 완료한 롯데카드

롯데카드의 클라우드 전환 속도는 타의 추종을 불허한다. 대부분의 금융 기관이 IaaS 중심의 클라우드 전환을 추진할 때, 롯데카드는 여기서 한발 더 나아가 PaaS 기반 로드맵을 실행에 옮겼다. 롯데카드는 2018년 채널계를 시작으로 2021년 계정계까지 컨테이너 기반 PaaS 환경을 구축했다.    신생업체 못지않은 민첩성 확보를 위한 선택 ‘MSA'  롯데카드가 PaaS 여정에 남들보다 빨리 뛰어든 이유는 디지털 중심의 시장 재편 속에서 민첩성을 확보하기 위해서다. 디지털 경제 시대를 맞아 금융 서비스는 더 쉽고, 안전하고, 편리한 쪽으로 발전하고 있다. 이를 주도하는 이들은 디지털 네이티브 기업이다. 핀테크 신생업체부터 거대 플랫폼 사업자까지, 지금껏 없던 사용자 경험을 앞세우면서 금융 서비스 이용자들의 기대를 한껏 높이고 있다. 롯데카드는 시장의 변화와 높아진 사용자 눈높이에 적응하려면 마이크로서비스 아키텍처(MSA) 환경에서 새로운 비즈니스 아이디어를 빨리 서비스로 만들어 배포하고, 사용자 경험을 끊임없이 개선해야 한다고 판단했다. 이런 전략 하에서 2018년 MSA로 가는 교두보인 컨테이너 기반 PaaS 구축을 시작했다.   IBM을 동반자로 클라우드 여정 시작  롯데카드의 클라우드 여정 동반자는 IBM이다. 롯데카드는 두 가지 이유로 IBM과 손을 잡았다. 하나는 카드사 업무 환경에 대한 깊은 이해다. 클라우드 전환은 모든 것을 새로 시작하는 것이 아니다. 기존 시스템을 업무와 서비스 차질 없이 현대화하면서 클라우드 네이티브 서비스 체제로 나아가야 한다. 롯데카드도 카드사 업무 환경과 시스템에 대한 깊은 이해를 바탕으로 현재 환경을 분석해 클라우드 전환 전략을 수립하고, 실제 마이그레이션을 지원할 수 있는 파트너가 필요했다.  두 번째는 기술이다. 카드사의 과거와 현재 비즈니스뿐만 아니라 디지털 경제 시대에 맞는 미래 비즈니스 전략을 수립하고 실행에 옮길 클라우드 기반 아키텍처 설계와 운영을...

IBM PaaS 롯데카드 2021.03.15

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

현대적인 인프라란 셰프(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 | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

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

Copyright © 2022 International Data Group. All rights reserved.