Offcanvas

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

“쉽고 빠른 마이크로서비스 개발 지원” C++용 비동기 프레임워크 베타 출시

현재 베타 상태인 ‘유저버(Userver)’의 개발팀은 효율적인 I/O 인터랙션 문제를 투명하게 해결할 계획이라고 밝혔다.  C++ 개발자라면 효율적인 I/O 인터랙션 문제를 해결하는 새 오픈소스 프레임워크 ‘유저버’를 통해 비동기식 마이크로서비스를 쉽고 빠르게 구축할 수 있다.    해당 프로젝트의 깃허브 리포지토리에 따르면 유저버라고 하는 비동기 프레임워크는 C++ 마이크로서비스, 서비스, 유틸리티의 ‘빠르고 편안한’ 생성을 위하여 일련의 추상화를 제공한다. 현재 이 프로젝트는 베타 상태다.  이어 개발팀은 효율적인 I/O 트랜잭션 문제를 투명하게 해결할 계획이라고 말했다. 아울러 C++의 속도, 파이썬의 단순함, 고랭의 코루틴(Coroutine) 모델도 제공한다고 덧붙였다.  유저버를 사용하면 일반적으로 실행 스레드를 일시 중단하는 작업이 수행되지 않는다. 대신, 스레드는 다른 작업을 처리하고 즉시 실행이 보장될 때만 작업 처리로 돌아간다. 개발자는 간단한 소스 코드를 얻고 OS에서 CPU를 많이 소비하는 컨텍스트 전환을 피하면서 적은 수의 실행 스레드를 통해 CPU를 효율적으로 활용할 수 있다고 개발팀은 설명했다. 유저버 프레임워크의 다른 기능은 아래와 같다.  • 캐시, 분산 잠금, JSON/YAML/BSON, 로깅, 메트릭, 통계, 작업에 관한 고급 구성요소 집합  • 즉각적인 서비스 구성 변경을 수행하는 기능  • 포괄적인 비동기와 저수준 동기화 기본 요소 및 OS 추상화 집합  • 몽고DB, 포스트그레, 레디스 및 기타 데이터베이스용 비동기 드라이버 • HTTP, GRPC 및 TCP를 포함한 데이터 전송 프로토콜 그리고 구성 및 취소를 포함한 작업용 비동기 드라이버 지난 7월 29일(현지 시각) 개발팀은 유저버의 베타 버전을 발표하면서, (이를 사용하면) 인턴과 학생도 일주일 만에 새 마이크로서비스를 작성하고 프로덕션에 배포할 수 있다며 유저버 개...

C++ 비동기 프레임워크 유저버 마이크로서비스

2022.08.03

현재 베타 상태인 ‘유저버(Userver)’의 개발팀은 효율적인 I/O 인터랙션 문제를 투명하게 해결할 계획이라고 밝혔다.  C++ 개발자라면 효율적인 I/O 인터랙션 문제를 해결하는 새 오픈소스 프레임워크 ‘유저버’를 통해 비동기식 마이크로서비스를 쉽고 빠르게 구축할 수 있다.    해당 프로젝트의 깃허브 리포지토리에 따르면 유저버라고 하는 비동기 프레임워크는 C++ 마이크로서비스, 서비스, 유틸리티의 ‘빠르고 편안한’ 생성을 위하여 일련의 추상화를 제공한다. 현재 이 프로젝트는 베타 상태다.  이어 개발팀은 효율적인 I/O 트랜잭션 문제를 투명하게 해결할 계획이라고 말했다. 아울러 C++의 속도, 파이썬의 단순함, 고랭의 코루틴(Coroutine) 모델도 제공한다고 덧붙였다.  유저버를 사용하면 일반적으로 실행 스레드를 일시 중단하는 작업이 수행되지 않는다. 대신, 스레드는 다른 작업을 처리하고 즉시 실행이 보장될 때만 작업 처리로 돌아간다. 개발자는 간단한 소스 코드를 얻고 OS에서 CPU를 많이 소비하는 컨텍스트 전환을 피하면서 적은 수의 실행 스레드를 통해 CPU를 효율적으로 활용할 수 있다고 개발팀은 설명했다. 유저버 프레임워크의 다른 기능은 아래와 같다.  • 캐시, 분산 잠금, JSON/YAML/BSON, 로깅, 메트릭, 통계, 작업에 관한 고급 구성요소 집합  • 즉각적인 서비스 구성 변경을 수행하는 기능  • 포괄적인 비동기와 저수준 동기화 기본 요소 및 OS 추상화 집합  • 몽고DB, 포스트그레, 레디스 및 기타 데이터베이스용 비동기 드라이버 • HTTP, GRPC 및 TCP를 포함한 데이터 전송 프로토콜 그리고 구성 및 취소를 포함한 작업용 비동기 드라이버 지난 7월 29일(현지 시각) 개발팀은 유저버의 베타 버전을 발표하면서, (이를 사용하면) 인턴과 학생도 일주일 만에 새 마이크로서비스를 작성하고 프로덕션에 배포할 수 있다며 유저버 개...

2022.08.03

‘닮은 듯 다른’ 월가 공룡들의 데브옵스 접근법

두 금융 서비스 회사는 중앙집중식 운영 및 SRE 하에서 개발자 팀의 공유 책임 모델을 구축하는 등 데브옵스 전환에 유사한 접근 방식을 취하고 있다.  ‘뱅가드(Vanguard)’와 ‘모건 스탠리(Morgan Stanley)’는 대규모 클라우드 전환을 진행하면서 소프트웨어 개발과 운영의 균형을 신중하게 맞추고 있다. 지난 2015년 뱅가드는 자체적으로 관리하던 서버 2,000대를 대부분 AWS로 이동시키는 전환을 시작했다. 그 결과 7,000명의 개발자가 분기마다 단일 애플리케이션을 업데이트하던 것에서 개별 팀이 구축하고 실행하는 일련의 마이크로서비스로 이동했다. 이러한 팀은 이제 표준화된 CI/CD 파이프라인 그리고 코드를 적용할 수 있는 인프라를 제공하는 중앙 플랫폼 팀의 지원을 받으며, SRE는 이러한 팀 전체에 중앙집중식 및 임베디드식 감독 기능을 제공한다.    모건 스탠리는 2018년 애자일 및 클라우드 전환을 시작했으며, (이를 위해) 마이크로소프트 애저와 협력했다. 이 이니셔티브는 1만 5,000명에 달하는 해당 은행의 기술 전문가를 대상으로 최신 데브옵스 및 SRE 관행을 확립하기 위한 3개년 교육 프로젝트로 출발했다. 이는 모건 스탠리의 애플리케이션 인프라 부문 전무이사 거스 폴이 식별한 3가지 핵심 영역을 기반으로 한다. 그는 데브옵스 엔터프라이즈 서밋(Devops Enterprise Summit)에서 “3가지 핵심 영역은 소프트웨어 개발 및 제공 가속화, 변화의 예측 가능성/빈도/품질 증가, 기술 운영 혁신”이라고 말했다. 모건 스탠리의 데브옵스 및 엔터프라이즈 기술 아키텍처 책임자 트레버 브로스넌은 “현재 자사는 제품 소유자, 개발 및 운영 전문 지식을 갖춘 엔지니어로 구성된 애자일 팀을 보유하고 있으며, 이러한 팀은 온프레미스 또는 클라우드 인프라를 타깃으로 하고 있다. 개인적인 철학은 모두에게 전문 분야가 있는 것이다. 모두는 기술에 능통할 수 있다”라고 밝혔다. 뱅가드와 모건 스탠리처럼 크고 ...

데브옵스 SRE 클라우드 AWS 마이크로소프트 애저 마이크로서비스 IT 관리

2022.06.03

두 금융 서비스 회사는 중앙집중식 운영 및 SRE 하에서 개발자 팀의 공유 책임 모델을 구축하는 등 데브옵스 전환에 유사한 접근 방식을 취하고 있다.  ‘뱅가드(Vanguard)’와 ‘모건 스탠리(Morgan Stanley)’는 대규모 클라우드 전환을 진행하면서 소프트웨어 개발과 운영의 균형을 신중하게 맞추고 있다. 지난 2015년 뱅가드는 자체적으로 관리하던 서버 2,000대를 대부분 AWS로 이동시키는 전환을 시작했다. 그 결과 7,000명의 개발자가 분기마다 단일 애플리케이션을 업데이트하던 것에서 개별 팀이 구축하고 실행하는 일련의 마이크로서비스로 이동했다. 이러한 팀은 이제 표준화된 CI/CD 파이프라인 그리고 코드를 적용할 수 있는 인프라를 제공하는 중앙 플랫폼 팀의 지원을 받으며, SRE는 이러한 팀 전체에 중앙집중식 및 임베디드식 감독 기능을 제공한다.    모건 스탠리는 2018년 애자일 및 클라우드 전환을 시작했으며, (이를 위해) 마이크로소프트 애저와 협력했다. 이 이니셔티브는 1만 5,000명에 달하는 해당 은행의 기술 전문가를 대상으로 최신 데브옵스 및 SRE 관행을 확립하기 위한 3개년 교육 프로젝트로 출발했다. 이는 모건 스탠리의 애플리케이션 인프라 부문 전무이사 거스 폴이 식별한 3가지 핵심 영역을 기반으로 한다. 그는 데브옵스 엔터프라이즈 서밋(Devops Enterprise Summit)에서 “3가지 핵심 영역은 소프트웨어 개발 및 제공 가속화, 변화의 예측 가능성/빈도/품질 증가, 기술 운영 혁신”이라고 말했다. 모건 스탠리의 데브옵스 및 엔터프라이즈 기술 아키텍처 책임자 트레버 브로스넌은 “현재 자사는 제품 소유자, 개발 및 운영 전문 지식을 갖춘 엔지니어로 구성된 애자일 팀을 보유하고 있으며, 이러한 팀은 온프레미스 또는 클라우드 인프라를 타깃으로 하고 있다. 개인적인 철학은 모두에게 전문 분야가 있는 것이다. 모두는 기술에 능통할 수 있다”라고 밝혔다. 뱅가드와 모건 스탠리처럼 크고 ...

2022.06.03

벤더 기고ㅣ빠르고 민첩한 기업으로의 혁신을 위한 제언

디지털 신기술을 통해 비즈니스 속도와 민첩성을 확보하여 시장을 리딩하는 기업이 있는 반면에 신기술 도입 이후에도 원하는 수준의 속도와 성과를 얻지 못하거나, 새로운 기술 환경에 적응하는 것조차 어려운 기업이 있는 이유는 무엇일까? 이에 대한 원인과 변화 방향에 대해서 살펴보고, 기업이 어떻게 하면 빠르고 민첩한 체제로 변화할 수 있는지 살펴보고자 한다.   테일러리즘과 기술 부채에 가로막힌 혁신 속도 오늘날 급변하고 있는 시장과 고객의 기대 수준은 기업 내 비즈니스 및 IT에게 더 빠른 속도의 대응을 요구한다. 특히, 디지털 기술을 통해 기업의 지속적인 체질 개선과 비즈니스 가치 창출이 일어나는 시대에서 많은 기업들이 빠르고 민첩한 기업이 되는 것을 핵심 목표로 삼고 있다.   하지만 모든 기업이 목표를 달성하고 있는 것은 아니다. 글로벌 컨설팅 기업 맥킨지의 설문조사 결과에 따르면 90%의 기업이 다양한 형태의 디지털 혁신 작업을 수행하고 있지만 6개 기업 중 1개 기업만이 본인들이 충분히 도전적인 목표를 가지고 기대하는 속도로 실행 중이라고 응답한 것으로 나타났다. 기업이 원하는 속도와 민첩성을 얻지 못하는 데는 여러 요인이 있지만 산업혁명 이후 기업 경영의 근간이 되고 있는 테일러리즘에서 그 원인을 찾을 수 있을 것이다. 테일러리즘은 효율적인 대량생산을 목적으로 제품 및 작업의 표준화, 전문화된 분업을 통해 혁신적인 생산성 향상을 달성해왔다. 오랜 기간동안 기업 성장의 밑거름이 되어 온 것은 물론, 현재도 많은 기업에서 활용 중인 검증된 방식이다.  아이러니하게도 테일러리즘은 시장과 고객의 요구에 창의적인 솔루션을 제시하고 피드백에 따라 민첩하게 변화 및 발전해 나가야 하는 최근의 시장 상황에서 여러 가지 방해요소로 작용한다. 테일러리즘의 특징인 중앙집중화된 의사결정 구조와 기능 중심으로 분화된 조직 구성으로 인해 상하간, 관련 조직간 이해관계 조율을 위한 과도한 커뮤니케이션이 발생하고 이는 의사결정의 어려움과 실행 속도...

AWS 아마존 웹 서비스 클라우드 테일러리즘 기술 부채 디지털 혁신 애자일 마이크로서비스 아마존닷컴 옐프 버라이즌 이노베이션 휠

2022.03.17

디지털 신기술을 통해 비즈니스 속도와 민첩성을 확보하여 시장을 리딩하는 기업이 있는 반면에 신기술 도입 이후에도 원하는 수준의 속도와 성과를 얻지 못하거나, 새로운 기술 환경에 적응하는 것조차 어려운 기업이 있는 이유는 무엇일까? 이에 대한 원인과 변화 방향에 대해서 살펴보고, 기업이 어떻게 하면 빠르고 민첩한 체제로 변화할 수 있는지 살펴보고자 한다.   테일러리즘과 기술 부채에 가로막힌 혁신 속도 오늘날 급변하고 있는 시장과 고객의 기대 수준은 기업 내 비즈니스 및 IT에게 더 빠른 속도의 대응을 요구한다. 특히, 디지털 기술을 통해 기업의 지속적인 체질 개선과 비즈니스 가치 창출이 일어나는 시대에서 많은 기업들이 빠르고 민첩한 기업이 되는 것을 핵심 목표로 삼고 있다.   하지만 모든 기업이 목표를 달성하고 있는 것은 아니다. 글로벌 컨설팅 기업 맥킨지의 설문조사 결과에 따르면 90%의 기업이 다양한 형태의 디지털 혁신 작업을 수행하고 있지만 6개 기업 중 1개 기업만이 본인들이 충분히 도전적인 목표를 가지고 기대하는 속도로 실행 중이라고 응답한 것으로 나타났다. 기업이 원하는 속도와 민첩성을 얻지 못하는 데는 여러 요인이 있지만 산업혁명 이후 기업 경영의 근간이 되고 있는 테일러리즘에서 그 원인을 찾을 수 있을 것이다. 테일러리즘은 효율적인 대량생산을 목적으로 제품 및 작업의 표준화, 전문화된 분업을 통해 혁신적인 생산성 향상을 달성해왔다. 오랜 기간동안 기업 성장의 밑거름이 되어 온 것은 물론, 현재도 많은 기업에서 활용 중인 검증된 방식이다.  아이러니하게도 테일러리즘은 시장과 고객의 요구에 창의적인 솔루션을 제시하고 피드백에 따라 민첩하게 변화 및 발전해 나가야 하는 최근의 시장 상황에서 여러 가지 방해요소로 작용한다. 테일러리즘의 특징인 중앙집중화된 의사결정 구조와 기능 중심으로 분화된 조직 구성으로 인해 상하간, 관련 조직간 이해관계 조율을 위한 과도한 커뮤니케이션이 발생하고 이는 의사결정의 어려움과 실행 속도...

2022.03.17

기고 | '대규모 마이크로서비스 구축 및 실행은...' 프라이스라인의 앱 현대화

‘혁신가의 딜레마’라는 책에도 나오듯이, 오늘날의 성공적인 조직은 번성하기 위해 계속해서 새로운 프로세스를 도입해야 하는 과제에 직면해 있다. 소프트웨어 개발에 의존해 경쟁 우위를 유지하는 현대의 조직이 이 끊임없는 변화의 필요성에 대처하려면 개발팀의 사고방식을 바꿔야 한다. 프라이스라인(Priceline)에서 이 말은 새롭고 혁신적인 기술 도입, 그리고 서비스를 구축하고 배포하는 방법에 있어서 완전히 새로운 사고방식을 의미한다. 프라이스라인은 월별 방문자 수가 수백만 명에 달하는 세계에서 가장 인기 있는 여행 사이트 중 하나이다.   경쟁이 극히 치열한 시장에서 성공을 지속하려면 완전히 새로운 서비스 제공 전략을 지원해야 하며, 이를 위해서는 기술 리더십의 치밀한 사고와 행동이 필요하다. 프라이스라인의 유능한 기술팀은 여행 업계의 기술 발전을 선도하고자 12요소(12 Factor) 앱 개발, 모노리포(Monorepo), 트렁크 기반 개발, 종속성 관리를 채택했다. 그러나 여전히 할 일이 많이 남아 있다.  컨테이너 기반 마이크로서비스를 생각해보자. 불과 몇 년 전과 비교해도 기업의 컨테이너 및 쿠버네티스 도입은 크게 늘었다. 2020 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation) 설문에 따르면, 프로덕션에서의 컨테이너 사용은 2016년 이후 300% 증가했다. 현재 프라이스라인 전체 제품 플랫폼의 80%는 구글 클라우드에서 컨테이너와 쿠버네티스를 기반으로 실행된다.  대형 IT 업체의 상당수는 이런 애플리케이션 개발 패러다임의 변화가 주는 혜택을 활용하고 있지만(새로운 과제도 발견), 많은 기업이 이제 막 이 여정을 시작하는 단계에 있다. 하지만 지금의 경제 상황을 보면 증가하는 소프트웨어 개발 수요를 충당할 만큼의 데브옵스와 SRE 전문가를 채용할 수는 없을 것이다. CTO는 애플리케이션의 탄력성과 확장성을 높일 방법뿐만 아니라 개발자에게 수작업의 부담을 지나치게 전가하지 않으...

마이크로서비스 데브옵스 컨테이너 쿠버네티스 12요소 모노리포 종속성 프라이스라인

2022.02.28

‘혁신가의 딜레마’라는 책에도 나오듯이, 오늘날의 성공적인 조직은 번성하기 위해 계속해서 새로운 프로세스를 도입해야 하는 과제에 직면해 있다. 소프트웨어 개발에 의존해 경쟁 우위를 유지하는 현대의 조직이 이 끊임없는 변화의 필요성에 대처하려면 개발팀의 사고방식을 바꿔야 한다. 프라이스라인(Priceline)에서 이 말은 새롭고 혁신적인 기술 도입, 그리고 서비스를 구축하고 배포하는 방법에 있어서 완전히 새로운 사고방식을 의미한다. 프라이스라인은 월별 방문자 수가 수백만 명에 달하는 세계에서 가장 인기 있는 여행 사이트 중 하나이다.   경쟁이 극히 치열한 시장에서 성공을 지속하려면 완전히 새로운 서비스 제공 전략을 지원해야 하며, 이를 위해서는 기술 리더십의 치밀한 사고와 행동이 필요하다. 프라이스라인의 유능한 기술팀은 여행 업계의 기술 발전을 선도하고자 12요소(12 Factor) 앱 개발, 모노리포(Monorepo), 트렁크 기반 개발, 종속성 관리를 채택했다. 그러나 여전히 할 일이 많이 남아 있다.  컨테이너 기반 마이크로서비스를 생각해보자. 불과 몇 년 전과 비교해도 기업의 컨테이너 및 쿠버네티스 도입은 크게 늘었다. 2020 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation) 설문에 따르면, 프로덕션에서의 컨테이너 사용은 2016년 이후 300% 증가했다. 현재 프라이스라인 전체 제품 플랫폼의 80%는 구글 클라우드에서 컨테이너와 쿠버네티스를 기반으로 실행된다.  대형 IT 업체의 상당수는 이런 애플리케이션 개발 패러다임의 변화가 주는 혜택을 활용하고 있지만(새로운 과제도 발견), 많은 기업이 이제 막 이 여정을 시작하는 단계에 있다. 하지만 지금의 경제 상황을 보면 증가하는 소프트웨어 개발 수요를 충당할 만큼의 데브옵스와 SRE 전문가를 채용할 수는 없을 것이다. CTO는 애플리케이션의 탄력성과 확장성을 높일 방법뿐만 아니라 개발자에게 수작업의 부담을 지나치게 전가하지 않으...

2022.02.28

지속적 배포의 핵심 전략··· ‘카나리 릴리즈’ 살펴보기

소규모 사용자 그룹이 새로운 기능 및 서비스를 사용할 수 있도록 하는 것은 위험을 줄이는 좋은 개발 전략이다.  클라우드와 마이크로서비스 이전 시대의 ‘개발, 테스트, 프로덕션, 재해 복구(DR)’ 배포 패러다임을 기억하는가? 당시에는 인프라를 구매하고, 구성하며, 유지관리하는 비용이 많이 들고 복잡했기 때문에 데이터센터 운영팀은 더 많은 환경과 배포 유연성을 확보하는 데 거의 동의하지 않았다.  오늘날 데브옵스 조직은 지속적 통합/지속적 제공(CI/CD)을 사용하여 딜리버리를 자동화하고, 코드형 인프라(Infrastructure as Code; IaC)를 활용해 인프라를 구성하며, 쿠버네티스를 통해 환경을 컨테이너화한다. 또 지속적인 테스트로 품질을 높이고, AI옵스(AIops)를 사용하여 모니터링 및 관찰 가능성을 중앙집중화한다. 이러한 관행 덕분에 배포 빈도를 높이는 동시에 변경으로 인한 보안, 성능, 안정성 위험을 최소화할 수 있다. 하지만 변경 사항과 액세스 권한에 따라 위험을 줄이고 릴리즈를 제어하고자 한다면 애플리케이션 또는 배포를 구성하고 관리하는 추가적인 기법이 필요하다.    릴리즈 파이프라인에는 유연한 관리 및 배포 옵션이 필요하다 배포를 제어하는 한 가지 방법은 기능 플래그를 활용하여 사용자별로 기능 액세스를 전환, A/B 테스트, 세분화하는 것이다. 데브옵스 팀은 기능 플래그를 사용하여 앱을 클라우드로 이동하거나, 단일 애플리케이션을 마이크로서비스에 리팩토링할 때 새롭게 개발한 기능을 검증할 수 있다. 기능 플래그는 앱 또는 마이크로서비스의 기능을 확인할 수 있는 사람을 통제하려는 개발팀과 제품 관리자에 유용하다. 하지만 때때로 데브옵스 또는 IT 운영팀은 배포를 관리하고 프로덕션 환경에 투입된 애플리케이션의 여러 버전을 관리할 수 있는 유연성이 필요하다. 몇 가지 예는 다음과 같다.  • 운영체제, 데이터베이스, 미들웨어 등의 중요한 시스템 구성 요소를 패치하거나 업그레이드할 때...

지속적 제공 지속적 배포 카나리 배포 카나리 릴리즈 소프트웨어 배포 애플리케이션 마이크로서비스 데브옵스 블루-그린 배포 애자일

2021.12.30

소규모 사용자 그룹이 새로운 기능 및 서비스를 사용할 수 있도록 하는 것은 위험을 줄이는 좋은 개발 전략이다.  클라우드와 마이크로서비스 이전 시대의 ‘개발, 테스트, 프로덕션, 재해 복구(DR)’ 배포 패러다임을 기억하는가? 당시에는 인프라를 구매하고, 구성하며, 유지관리하는 비용이 많이 들고 복잡했기 때문에 데이터센터 운영팀은 더 많은 환경과 배포 유연성을 확보하는 데 거의 동의하지 않았다.  오늘날 데브옵스 조직은 지속적 통합/지속적 제공(CI/CD)을 사용하여 딜리버리를 자동화하고, 코드형 인프라(Infrastructure as Code; IaC)를 활용해 인프라를 구성하며, 쿠버네티스를 통해 환경을 컨테이너화한다. 또 지속적인 테스트로 품질을 높이고, AI옵스(AIops)를 사용하여 모니터링 및 관찰 가능성을 중앙집중화한다. 이러한 관행 덕분에 배포 빈도를 높이는 동시에 변경으로 인한 보안, 성능, 안정성 위험을 최소화할 수 있다. 하지만 변경 사항과 액세스 권한에 따라 위험을 줄이고 릴리즈를 제어하고자 한다면 애플리케이션 또는 배포를 구성하고 관리하는 추가적인 기법이 필요하다.    릴리즈 파이프라인에는 유연한 관리 및 배포 옵션이 필요하다 배포를 제어하는 한 가지 방법은 기능 플래그를 활용하여 사용자별로 기능 액세스를 전환, A/B 테스트, 세분화하는 것이다. 데브옵스 팀은 기능 플래그를 사용하여 앱을 클라우드로 이동하거나, 단일 애플리케이션을 마이크로서비스에 리팩토링할 때 새롭게 개발한 기능을 검증할 수 있다. 기능 플래그는 앱 또는 마이크로서비스의 기능을 확인할 수 있는 사람을 통제하려는 개발팀과 제품 관리자에 유용하다. 하지만 때때로 데브옵스 또는 IT 운영팀은 배포를 관리하고 프로덕션 환경에 투입된 애플리케이션의 여러 버전을 관리할 수 있는 유연성이 필요하다. 몇 가지 예는 다음과 같다.  • 운영체제, 데이터베이스, 미들웨어 등의 중요한 시스템 구성 요소를 패치하거나 업그레이드할 때...

2021.12.30

‘다중 클러스터 쿠버네티스’의 과제 해결하려면... 고려해야 할 4가지

‘쿠버네티스(Kubernetes)’를 운영하는 데 따르는 어려움과 도전과제는 이를 확장하면 배가된다. 다중 클러스터 오케스트레이션을 관리할 때 고려해야 할 4가지 사항을 살펴본다.  일상생활의 많은 부분이 온라인으로 이동함에 따라 인터넷을 극적으로 확장해야 할 필요성도 커지고 있다. 이러한 경향은 수년 전부터 시작됐고(닷컴 붐 때라고 할 수 있다), 그 이후 기술적 발전이 거듭됐다.    최초의 퍼블릭 클라우드 서비스로 지난 2002년 출시된 AWS는 기업들이 IT 운영을 아웃소싱하고, 필요에 따라 리소스 소비를 줄이고 늘릴 기회를 열어줬다. 가상 머신(VM)은 물리적 하드웨어에서 애플리케이션 소프트웨어를 추상화했다. 그러자 곧 새로운 배포 패턴이 필요해졌다.  마이크로서비스는 고립돼 있고 느슨하게 연결된 서비스 모음이다. 주변 환경과 독립적으로 유지 및 구성할 수 있다. 이를 컨테이너(2014년 도커에 의해 상용화됐다)에 패키징하면 대규모로 배포할 수 있다.  컨테이너 오케스트레이션 분야의 주도권을 잡기 위해 랜처(Rancher), 도커 스웜(Docker Swarm), 메소스(Mesos) 등의 다양한 기술이 경쟁에 나섰다. 궁극적으로 컨테이너화된 마이크로서비스의 왕좌에 오른 것은 쿠버네티스였다. 기업들은 쿠버네티스의 이점을 확실히 알고 있었지만 타고난 복잡성과 가파른 학습 곡선이 항상 진입 장벽으로 작용했다. 소규모 기업은 이 거대한 기술을 성공적으로 관리하기 위한 운영 전문 지식과 리소스가 부족했고, 대기업은 클라우드 네이티브 도구 및 프로세스를 레거시 인프라에 통합하느라 고군분투했다.  쿠버네티스 복잡성과의 싸움 수년에 걸쳐 기업들이 쿠버네티스를 채택하고 컨테이너 오케스트레이션을 최적화할 수 있도록 지원하는 솔루션이 여럿 등장했다. 예를 들면 랜처(Rancher), 오픈시프트(OpenShift), 퍼블릭 클라우드 관리형 서비스(예: 애저 쿠버네티스 서비스(Azure Kubernetes Se...

쿠버네티스 컨테이너 다중 클러스터 마이크로서비스 클라우드 네이티브 클라우드

2021.12.23

‘쿠버네티스(Kubernetes)’를 운영하는 데 따르는 어려움과 도전과제는 이를 확장하면 배가된다. 다중 클러스터 오케스트레이션을 관리할 때 고려해야 할 4가지 사항을 살펴본다.  일상생활의 많은 부분이 온라인으로 이동함에 따라 인터넷을 극적으로 확장해야 할 필요성도 커지고 있다. 이러한 경향은 수년 전부터 시작됐고(닷컴 붐 때라고 할 수 있다), 그 이후 기술적 발전이 거듭됐다.    최초의 퍼블릭 클라우드 서비스로 지난 2002년 출시된 AWS는 기업들이 IT 운영을 아웃소싱하고, 필요에 따라 리소스 소비를 줄이고 늘릴 기회를 열어줬다. 가상 머신(VM)은 물리적 하드웨어에서 애플리케이션 소프트웨어를 추상화했다. 그러자 곧 새로운 배포 패턴이 필요해졌다.  마이크로서비스는 고립돼 있고 느슨하게 연결된 서비스 모음이다. 주변 환경과 독립적으로 유지 및 구성할 수 있다. 이를 컨테이너(2014년 도커에 의해 상용화됐다)에 패키징하면 대규모로 배포할 수 있다.  컨테이너 오케스트레이션 분야의 주도권을 잡기 위해 랜처(Rancher), 도커 스웜(Docker Swarm), 메소스(Mesos) 등의 다양한 기술이 경쟁에 나섰다. 궁극적으로 컨테이너화된 마이크로서비스의 왕좌에 오른 것은 쿠버네티스였다. 기업들은 쿠버네티스의 이점을 확실히 알고 있었지만 타고난 복잡성과 가파른 학습 곡선이 항상 진입 장벽으로 작용했다. 소규모 기업은 이 거대한 기술을 성공적으로 관리하기 위한 운영 전문 지식과 리소스가 부족했고, 대기업은 클라우드 네이티브 도구 및 프로세스를 레거시 인프라에 통합하느라 고군분투했다.  쿠버네티스 복잡성과의 싸움 수년에 걸쳐 기업들이 쿠버네티스를 채택하고 컨테이너 오케스트레이션을 최적화할 수 있도록 지원하는 솔루션이 여럿 등장했다. 예를 들면 랜처(Rancher), 오픈시프트(OpenShift), 퍼블릭 클라우드 관리형 서비스(예: 애저 쿠버네티스 서비스(Azure Kubernetes Se...

2021.12.23

마이크로서비스 아키텍처를 사용해야 하는 이유

현재 운영 중인 애플리케이션이 크다. 고객은 많고, 이들 고객은 애플리케이션의 여러 기능을 적절히 사용한다. 제품 카탈로그는 다채롭고, 스토어는 큰 규모에 기능도 풍부하다. 여기까지 보면 잘 되고 있다.  단, 문제가 있다.    애플리케이션이 너무 자주 멈춘다. 장애가 발생하면 항상 개발자가 투입되어 매우 빠르게 사이트를 수정하지만, 그 과정에서 시간과 에너지가 소비된다. 매달 한 번 이상 다운되고 일단 다운되면 몇 시간은 지속된다. 여기서 손실된 비즈니스를 상상해 보라.  개발팀도 문제를 해결하고 싶어한다. 사실 개발자는 원래 많은 것을 하고 싶어한다. 구현하려고 생각 중인 훌륭한 새 기능에 대해 항상 이야기는 하는데, 정작 만들 수는 없다. 버그 수정과 급한 불을 끄는 일에 온통 매달리고 있기 때문이다.  추가 인력 채용에 대해 논의했지만, 예산이 한정돼 있다. 게다가 퇴사하는 사람을 대신할 인력을 충원하기에도 급급하다. 더 큰 기술 회사로 이직하는 사람도 있고 너무 많은 야간 긴급 호출에 질려 퇴사하는 사람도 있다. 기술 문제는 회사와 IT팀에 무거운 짐이지만, 해결할 방법이 보이지 않는다. 회사와 IT 책임자 모두 덫에 걸린 것 같다. 많은 소프트웨어 업체, 그리고 비 소프트웨어 회사의 많은 IT 부서가 이 덫에 걸렸다. 모든 일을 처리할 수 있을 것 같은 대규모 모놀리식 애플리케이션을 만들었지만, 이 애플리케이션은 통제 불능이 될 정도로 너무 커지고 복잡해졌다. 아무도 애플리케이션에서 일어나는 모든 일을 파악하지는 못할 정도가 됐다. 여기저기에서 고장이 나고, 고치는 데는 하염없이 긴 시간이 걸린다. 새롭거나 개선된 기능을 추가하고자 하지만 변경 작업이 너무 뒤얽혀 빠르게 할 수가 없고, 완료된 다음에는 버그투성이다. 개발 속도는 느리고 갈수록 더 느려진다. 개발자 수를 늘리려고 노력하지만 그렇게 해도 개발 속도는 더 빨라지지 않는 것 같다. 또한 신규 개발자가 애플리케이션에 대해 배우기가 터...

마이크로서비스 아키텍처 컨테이너

2021.11.17

현재 운영 중인 애플리케이션이 크다. 고객은 많고, 이들 고객은 애플리케이션의 여러 기능을 적절히 사용한다. 제품 카탈로그는 다채롭고, 스토어는 큰 규모에 기능도 풍부하다. 여기까지 보면 잘 되고 있다.  단, 문제가 있다.    애플리케이션이 너무 자주 멈춘다. 장애가 발생하면 항상 개발자가 투입되어 매우 빠르게 사이트를 수정하지만, 그 과정에서 시간과 에너지가 소비된다. 매달 한 번 이상 다운되고 일단 다운되면 몇 시간은 지속된다. 여기서 손실된 비즈니스를 상상해 보라.  개발팀도 문제를 해결하고 싶어한다. 사실 개발자는 원래 많은 것을 하고 싶어한다. 구현하려고 생각 중인 훌륭한 새 기능에 대해 항상 이야기는 하는데, 정작 만들 수는 없다. 버그 수정과 급한 불을 끄는 일에 온통 매달리고 있기 때문이다.  추가 인력 채용에 대해 논의했지만, 예산이 한정돼 있다. 게다가 퇴사하는 사람을 대신할 인력을 충원하기에도 급급하다. 더 큰 기술 회사로 이직하는 사람도 있고 너무 많은 야간 긴급 호출에 질려 퇴사하는 사람도 있다. 기술 문제는 회사와 IT팀에 무거운 짐이지만, 해결할 방법이 보이지 않는다. 회사와 IT 책임자 모두 덫에 걸린 것 같다. 많은 소프트웨어 업체, 그리고 비 소프트웨어 회사의 많은 IT 부서가 이 덫에 걸렸다. 모든 일을 처리할 수 있을 것 같은 대규모 모놀리식 애플리케이션을 만들었지만, 이 애플리케이션은 통제 불능이 될 정도로 너무 커지고 복잡해졌다. 아무도 애플리케이션에서 일어나는 모든 일을 파악하지는 못할 정도가 됐다. 여기저기에서 고장이 나고, 고치는 데는 하염없이 긴 시간이 걸린다. 새롭거나 개선된 기능을 추가하고자 하지만 변경 작업이 너무 뒤얽혀 빠르게 할 수가 없고, 완료된 다음에는 버그투성이다. 개발 속도는 느리고 갈수록 더 느려진다. 개발자 수를 늘리려고 노력하지만 그렇게 해도 개발 속도는 더 빨라지지 않는 것 같다. 또한 신규 개발자가 애플리케이션에 대해 배우기가 터...

2021.11.17

마이크로서비스 모니터링 전략··· 'RED'의 개념과 장단점

요청 수(Rate), 오류율(Error), 소요 시간(Duration)에 중점을 두는 모니터링 기법 ‘RED’를 활용하면 최종 사용자를 대상으로 서비스가 어떻게 작동하는지 파악할 수 있다.  사용자에게 양질의 제품과 경험을 제공하는 데 있어 애플리케이션 모니터링은 필수적이다. 하지만 단순하게 수많은 애플리케이션 지표를 수집하는 것만으로는 실질적인 문제를 해결할 수 없다.  소프트웨어 회사는 사용자가 겪고 있는 문제를 신속하게 해결할 수 있도록 지표에서 실행 가능한 인사이트를 확보해야 한다. 여기서는 RED 기법을 살펴본다.   RED 기법이란? RED 기법은 톰 윌키가 구글에서 일하면서 터득한 것을 토대로 만든 모니터링 방법론이다. 구글의 SRE(Site Reliability Engineering) 팀에서 개발한 ‘4가지 황금 신호(Four Golden Signals)’에서 파생됐다. RED는 이전의 모니터링 철학과 기법(예: USE 기법(사용률, 포화도, 오류율 확인) 등)이 소프트웨어 회사 및 최신 소프트웨어 아키텍처의 목표와 완전히 일치하지 않았다는 것에 초점을 맞춘다.  USE가 하드웨어와 인프라에 더 많이 적용되는 반면 RED는 애플리케이션 사용자의 경험에 중점을 둔다. 다시 말해, RED 기법의 목표는 소프트웨어 애플리케이션이 무엇보다 최종 사용자를 위해 제대로 작동하는지 확인하는 것이다.  마이크로서비스 아키텍처, 컨테이너, 클라우드 인프라의 시대에서 하드웨어와 관련된 메트릭은 서비스 수준 목표(Service Level Objectives; SLO)가 충족되는 한 그다지 중요하지 않다.  RED는 요청 수(Rate), 오류율(Errors), 소요 시간(Duration)을 나타낸다. 이는 아키텍처의 각 서비스에서 모니터링해야 할 3가지 핵심 지표다. • 요청 수(Rate) - 서비스가 초당 처리하는 요청 수 • 오류율(Error) - 초당 실패한 요청 수 • 소요 시간(Durati...

마이크로서비스 애플리케이션 모니터링 RED 데브옵스 소프트웨어 개발 클라우드 컴퓨팅

2021.11.08

요청 수(Rate), 오류율(Error), 소요 시간(Duration)에 중점을 두는 모니터링 기법 ‘RED’를 활용하면 최종 사용자를 대상으로 서비스가 어떻게 작동하는지 파악할 수 있다.  사용자에게 양질의 제품과 경험을 제공하는 데 있어 애플리케이션 모니터링은 필수적이다. 하지만 단순하게 수많은 애플리케이션 지표를 수집하는 것만으로는 실질적인 문제를 해결할 수 없다.  소프트웨어 회사는 사용자가 겪고 있는 문제를 신속하게 해결할 수 있도록 지표에서 실행 가능한 인사이트를 확보해야 한다. 여기서는 RED 기법을 살펴본다.   RED 기법이란? RED 기법은 톰 윌키가 구글에서 일하면서 터득한 것을 토대로 만든 모니터링 방법론이다. 구글의 SRE(Site Reliability Engineering) 팀에서 개발한 ‘4가지 황금 신호(Four Golden Signals)’에서 파생됐다. RED는 이전의 모니터링 철학과 기법(예: USE 기법(사용률, 포화도, 오류율 확인) 등)이 소프트웨어 회사 및 최신 소프트웨어 아키텍처의 목표와 완전히 일치하지 않았다는 것에 초점을 맞춘다.  USE가 하드웨어와 인프라에 더 많이 적용되는 반면 RED는 애플리케이션 사용자의 경험에 중점을 둔다. 다시 말해, RED 기법의 목표는 소프트웨어 애플리케이션이 무엇보다 최종 사용자를 위해 제대로 작동하는지 확인하는 것이다.  마이크로서비스 아키텍처, 컨테이너, 클라우드 인프라의 시대에서 하드웨어와 관련된 메트릭은 서비스 수준 목표(Service Level Objectives; SLO)가 충족되는 한 그다지 중요하지 않다.  RED는 요청 수(Rate), 오류율(Errors), 소요 시간(Duration)을 나타낸다. 이는 아키텍처의 각 서비스에서 모니터링해야 할 3가지 핵심 지표다. • 요청 수(Rate) - 서비스가 초당 처리하는 요청 수 • 오류율(Error) - 초당 실패한 요청 수 • 소요 시간(Durati...

2021.11.08

"마이크로서비스 기반의 앱을 위한 데브섹옵스 구현" 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

“개발자의 약 50%, 2년 이내에 자카르타 EE로 이전할 계획” 이클립스 재단

이클립스 재단(Eclipse Foundation)의 엔터프라이즈 자바 구현 ‘자카르타 EE(Jakarta EE)’가 활기를 띠고 있다. 이 재단의 최근 개발자 설문조사 결과에 따르면 전체 응답자의 거의 절반이 자카르타로 이주했거나 2년 이내에 이전할 계획이라고 말했다.    지난 9월 13일 발표된 ‘2021 자카르타 EE 개발자 설문조사 보고서(2021 Jakarta EE Developer Survey Report)’에서 전체 응답자의 48%가 이미 ‘자바 EE(Enterprise Edition)’의 후속 플랫폼으로 이주했거나 아니면 6개월에서 2년 이내에 이전할 계획이라고 밝혔다.  또한 보고서는 클라우드용 비즈니스 애플리케이션 개발이 자카르타를 통해 가속화됐다고 언급했다. 2020년 12월 ‘자카르타 EE 9’ 출시 이후 자카르타가 두 번째로 많이 사용되는 클라우드 네이티브 프레임워크로 부상했다(47%가 이를 사용하고 있다고 답했다). 1위는 스프링/스프링부트(Spring/Spring Boot)가 차지했다(60%).  한편 이클립스는 지난 2017년 오라클에서 엔터프라이즈 자바의 관리 권한을 넘겨받았다. 해당 플랫폼의 이름은 자바 EE에서 자카르타 EE로 변경됐다.  이클립스의 설문조사는 자바 생태계 이해 관계자가 클라우드 네이티브 자바와 엔터프라이즈 개발자 커뮤니티의 요구사항, 우선순위 및 인식을 이해하기 위해 실시됐다. 이번 설문조사는 2021년 4월 6일부터 5월 31일까지 전 세계 930명의 개발자를 대상으로 진행됐다.  이 밖에 2021년 자카르타 EE 개발자 설문조사 보고서의 결과는 아래와 같다.  • 이클립스 마이크로프로파일 자바(Eclipse MicroProfile Java) 마이크로서비스 아키텍처 채택률이 2020년 29%에서 2021년 34%로 증가했다.  • 클라우드에서 자바 시스템을 구현하는 마이크로서비스 아키텍처의 사용량이 지난해 39%에서 올해 ...

개발자 이클립스 재단 자카르타 EE 자바 클라우드 애플리케이션 스프링 스프링부트 마이크로서비스 쿠버네티스 도커

2021.09.16

이클립스 재단(Eclipse Foundation)의 엔터프라이즈 자바 구현 ‘자카르타 EE(Jakarta EE)’가 활기를 띠고 있다. 이 재단의 최근 개발자 설문조사 결과에 따르면 전체 응답자의 거의 절반이 자카르타로 이주했거나 2년 이내에 이전할 계획이라고 말했다.    지난 9월 13일 발표된 ‘2021 자카르타 EE 개발자 설문조사 보고서(2021 Jakarta EE Developer Survey Report)’에서 전체 응답자의 48%가 이미 ‘자바 EE(Enterprise Edition)’의 후속 플랫폼으로 이주했거나 아니면 6개월에서 2년 이내에 이전할 계획이라고 밝혔다.  또한 보고서는 클라우드용 비즈니스 애플리케이션 개발이 자카르타를 통해 가속화됐다고 언급했다. 2020년 12월 ‘자카르타 EE 9’ 출시 이후 자카르타가 두 번째로 많이 사용되는 클라우드 네이티브 프레임워크로 부상했다(47%가 이를 사용하고 있다고 답했다). 1위는 스프링/스프링부트(Spring/Spring Boot)가 차지했다(60%).  한편 이클립스는 지난 2017년 오라클에서 엔터프라이즈 자바의 관리 권한을 넘겨받았다. 해당 플랫폼의 이름은 자바 EE에서 자카르타 EE로 변경됐다.  이클립스의 설문조사는 자바 생태계 이해 관계자가 클라우드 네이티브 자바와 엔터프라이즈 개발자 커뮤니티의 요구사항, 우선순위 및 인식을 이해하기 위해 실시됐다. 이번 설문조사는 2021년 4월 6일부터 5월 31일까지 전 세계 930명의 개발자를 대상으로 진행됐다.  이 밖에 2021년 자카르타 EE 개발자 설문조사 보고서의 결과는 아래와 같다.  • 이클립스 마이크로프로파일 자바(Eclipse MicroProfile Java) 마이크로서비스 아키텍처 채택률이 2020년 29%에서 2021년 34%로 증가했다.  • 클라우드에서 자바 시스템을 구현하는 마이크로서비스 아키텍처의 사용량이 지난해 39%에서 올해 ...

2021.09.16

칼럼 | 마이그레이션을 도중에 멈추면 안 되는 이유

애플리케이션 마이그레이션을 계획 중인가? 아마 온프레미스 애플리케이션을 클라우드로 이전하거나 모놀리식 애플리케이션을 서비스 지향 아키텍처나 마이크로서비스 아키텍처로 옮길 생각일 것이다.   이런 마이그레이션은 전력을 다해야 하는 일이다. 시간과 자원은 물론, 마음가짐과 기업의 역량을 모두 투여해야 한다.    하지만 마이그레이션은 완료하기가 쉽지 않다. 마이그레이션은 장기간의 점진적인 변화이고, 통상적으로 소비된 노력이 실현된 혜택과 바로 일치하지는 않는다. 혜택은 투자가 이루어지고 난 시점보다 훨씬 이후에 찾아온다. 때에 따라 좋아지기 전에 난관에 부딪히기도 한다.   그래서 마이그레이션을 도중에 종료하려는 유혹을 뿌리치기는 쉽지 않다.   도대체 마이그레이션을 도중에 종료하고 싶은 사람이 있기는 할까? 말도 안 되는 것처럼 보이지만 실제로 일어난다. 모놀리식 애플리케이션으로부터 서비스 지향 아키텍처로 이동한다고 하자. 마이그레이션을 시작한 지 얼마 되지 않아 중단한다면 애플리케이션은 마이그레이션 이전보다 훨씬 좋지 않은 상태로 남는다.   그렇다면 마이그레이션을 도중에 중단하려는 유혹을 어떻게 뿌리칠 것인가? 기대를 관리하는 것, 그리고 진정한 ROI를 이해하는 것이 핵심이다.     고통의 계곡   중대한 마이그레이션을 시작할 때, 특히 모놀리식 애플리케이션에서 마이크로서비스로 마이그레이션하는 등의 복잡한 마이그레이션을 시작한다면, 궁극적으로 얻게 될 혜택에 대한 일정한 기대가 있기 마련이다. 보통은 혜택이 투입된 시간과 노력에 상응할 것이라고 기대한다. ROI가 마이그레이션 노력을 정당화시킬 것이라고 생각한다.   그러나 이는 마이그레이션의 가치와 혜택을 판단하는 1차원적 시각이다. 단순 ROI 계산은 마이그레이션에 투여된 시간과 노력이 어떻게 혜택으로 변환되는지에 관한 이해를 충분히 포착하지 못한다. 일반적으로 <그림 1>에서 보듯이 혜택과...

마이그레이션 현대화 마이크로서비스 모놀리식

2021.09.03

애플리케이션 마이그레이션을 계획 중인가? 아마 온프레미스 애플리케이션을 클라우드로 이전하거나 모놀리식 애플리케이션을 서비스 지향 아키텍처나 마이크로서비스 아키텍처로 옮길 생각일 것이다.   이런 마이그레이션은 전력을 다해야 하는 일이다. 시간과 자원은 물론, 마음가짐과 기업의 역량을 모두 투여해야 한다.    하지만 마이그레이션은 완료하기가 쉽지 않다. 마이그레이션은 장기간의 점진적인 변화이고, 통상적으로 소비된 노력이 실현된 혜택과 바로 일치하지는 않는다. 혜택은 투자가 이루어지고 난 시점보다 훨씬 이후에 찾아온다. 때에 따라 좋아지기 전에 난관에 부딪히기도 한다.   그래서 마이그레이션을 도중에 종료하려는 유혹을 뿌리치기는 쉽지 않다.   도대체 마이그레이션을 도중에 종료하고 싶은 사람이 있기는 할까? 말도 안 되는 것처럼 보이지만 실제로 일어난다. 모놀리식 애플리케이션으로부터 서비스 지향 아키텍처로 이동한다고 하자. 마이그레이션을 시작한 지 얼마 되지 않아 중단한다면 애플리케이션은 마이그레이션 이전보다 훨씬 좋지 않은 상태로 남는다.   그렇다면 마이그레이션을 도중에 중단하려는 유혹을 어떻게 뿌리칠 것인가? 기대를 관리하는 것, 그리고 진정한 ROI를 이해하는 것이 핵심이다.     고통의 계곡   중대한 마이그레이션을 시작할 때, 특히 모놀리식 애플리케이션에서 마이크로서비스로 마이그레이션하는 등의 복잡한 마이그레이션을 시작한다면, 궁극적으로 얻게 될 혜택에 대한 일정한 기대가 있기 마련이다. 보통은 혜택이 투입된 시간과 노력에 상응할 것이라고 기대한다. ROI가 마이그레이션 노력을 정당화시킬 것이라고 생각한다.   그러나 이는 마이그레이션의 가치와 혜택을 판단하는 1차원적 시각이다. 단순 ROI 계산은 마이그레이션에 투여된 시간과 노력이 어떻게 혜택으로 변환되는지에 관한 이해를 충분히 포착하지 못한다. 일반적으로 <그림 1>에서 보듯이 혜택과...

2021.09.03

블로그 | 클라우드 네이티브의 코드 재사용이 철칙은 아니다.

코드 재사용은 필자가 초급 코볼 프로그래머였던 1980년대 이후로 개발자에게는 전쟁터의 함성 같은 것이었다. 우리는 여러 번 호출할 수 있는 함수를 정의했고, 구조적 프로그래밍의 시대가 시작됐다.   그때 이후 우리는 C나 객체 지향 C++ 같은 언어를 편력하며 재사용이 좋다는 관념을 확실히 했다. 그 다음은 분산 객체와 SOA(Service Oriented Architecture) 서비스로 흘러가면서 재사용은 하나의 애플리케이션 단위를 벗어나 성장했고, 느슨하게 연결되고 서로 다른 플랫폼에 있는 재사용할 수 있는 서비스로 발전했다. 지금은 클라우드 서비스나 API라는 개념, 그리고 새로운 차원의 세밀한 공유를 제공하는 마이크로서비스란 매력적인 개념도 있다. 재사용 또는 공유라는 개념은 클라우드와 비 클라우드 개발자 모두에게 새로운 의미를 갖는다. 2022년 현재 많은 개발자 DRY(Don’t Repeat Yourself)란 약어를 애플리케이션과 시스템을 구축하고 배치하는 새로운 슬로건으로 삼고 있다. 하지만 DRY는 말처럼 쉽지 않다.  필자는 오랫동안 서비스 기반 애플리케이션을 구축하면서 두 가지 서로 다른 실수를 저질렀다. 너무 많이 재사용하는 실수와 충분히 재사용하지 않는 실수이다. 과도한 재사용이란 같은 서비스를 반복적으로 사용함으로써 생산성이 감소하거나 심한 경우 생산성을 해칠 경우를 말한다. 애플리케이션의 요구를 만족하기 위해서는 추상화하고 일부 기능을 변경해야 하는 서비스를 재사용이란 개념을 고집해 그대로 이용한다면, 이런 결과를 낳을 수 있다. 예를 들어, 모든 고객의 정보가 있는 고객 신용 데이터에 액세스하는 서비스를 사용하지만, 해당 애플리케이션의 용도에서는 응답이나 데이터 스트림에서는 공통 데이터가 필요 없어 삭제해야 하는 경우가 있다. 이런 경우에도 억지로 재사용하는 경우가 많다. 애플리케이션 개발은 재사용되는 서비스의 혼합물이 되고 있으며, 반드시 재사용해야 하거나 그렇지 않거나 가리지 않는다. 게다가 이런...

클라이드네이티브 마이크로서비스 재사용 reuse

2021.07.22

코드 재사용은 필자가 초급 코볼 프로그래머였던 1980년대 이후로 개발자에게는 전쟁터의 함성 같은 것이었다. 우리는 여러 번 호출할 수 있는 함수를 정의했고, 구조적 프로그래밍의 시대가 시작됐다.   그때 이후 우리는 C나 객체 지향 C++ 같은 언어를 편력하며 재사용이 좋다는 관념을 확실히 했다. 그 다음은 분산 객체와 SOA(Service Oriented Architecture) 서비스로 흘러가면서 재사용은 하나의 애플리케이션 단위를 벗어나 성장했고, 느슨하게 연결되고 서로 다른 플랫폼에 있는 재사용할 수 있는 서비스로 발전했다. 지금은 클라우드 서비스나 API라는 개념, 그리고 새로운 차원의 세밀한 공유를 제공하는 마이크로서비스란 매력적인 개념도 있다. 재사용 또는 공유라는 개념은 클라우드와 비 클라우드 개발자 모두에게 새로운 의미를 갖는다. 2022년 현재 많은 개발자 DRY(Don’t Repeat Yourself)란 약어를 애플리케이션과 시스템을 구축하고 배치하는 새로운 슬로건으로 삼고 있다. 하지만 DRY는 말처럼 쉽지 않다.  필자는 오랫동안 서비스 기반 애플리케이션을 구축하면서 두 가지 서로 다른 실수를 저질렀다. 너무 많이 재사용하는 실수와 충분히 재사용하지 않는 실수이다. 과도한 재사용이란 같은 서비스를 반복적으로 사용함으로써 생산성이 감소하거나 심한 경우 생산성을 해칠 경우를 말한다. 애플리케이션의 요구를 만족하기 위해서는 추상화하고 일부 기능을 변경해야 하는 서비스를 재사용이란 개념을 고집해 그대로 이용한다면, 이런 결과를 낳을 수 있다. 예를 들어, 모든 고객의 정보가 있는 고객 신용 데이터에 액세스하는 서비스를 사용하지만, 해당 애플리케이션의 용도에서는 응답이나 데이터 스트림에서는 공통 데이터가 필요 없어 삭제해야 하는 경우가 있다. 이런 경우에도 억지로 재사용하는 경우가 많다. 애플리케이션 개발은 재사용되는 서비스의 혼합물이 되고 있으며, 반드시 재사용해야 하거나 그렇지 않거나 가리지 않는다. 게다가 이런...

2021.07.22

마이크로서비스에서 데이터를 중앙화하면 안 되는 3가지 이유

마이크로서비스 아키텍처는 최신 애플리케이션과 시스템에서 일반적으로 사용하는 개발 모델이다. 대형 애플리케이션의 비즈니스 책임을 분할해 독자적으로 개발, 관리, 운영, 확장할 수 있는 별개의 구성요소로 만드는 것이 장점이다. 마이크로서비스 아키텍처는 애플리케이션 자체를 확장하기에 효과적인 모델을 제공한다. 상대적으로 크고 분리된 팀이 대규모 애플리케이션을 함께 만들면서도 각자 부분을 독자적으로 작업할 수 있다. 일반적인 마이크로서비스 아키텍처에서는 비즈니스 로직의 구체적인 하위집합을 아우르는 개별 서비스가 생성된다. 마이크로서비스 전체를 연결하면 비즈니스 로직이 포함된 완전한 대형 애플리케이션이 된다. 이러한 모델은 코드 작성에는 매우 좋지만 데이터에는 어떨까. 특정 비즈니스 로직을 위해 개별 서비스를 만드는 경우 많은 개발자가 애플리케이션 데이터 전체를 중앙집중화해 데이터 저장소 한곳에 모아야 한다고 생각한다. 즉, 각 서비스에 필요할지 모를 데이터를 모두 이용할 수 있게 해 두자는 것이다. 이렇게 한 곳에 모인 데이터 저장소는 관리하기 쉽고 간편하다. 또한, 데이터 모델링도 애플리케이션이 사용 중인 서비스와 관계없이 전체 애플리케이션이 사용하기에 일관성을 가질 수 있다. 그러나 이런 장점에도 불구하고 이렇게 하면 안 된다. 데이터를 중앙 집중화했을 때의 문제를 3가지로 정리했다.   중앙집중화된 데이터는 확장하기 어렵다 전체 애플리케이션에 대한 데이터가 중앙집중화된 한 곳의 저장소에 있으면, 애플리케이션이 커질 때 애플리케이션 내의 모든 서비스의 수요를 맞추기 위해 전체 데이터저장소를 확장해야 한다. 이러한 상황은 <그림 1>의 왼쪽이다. 그러나 <그림 1>의 오른쪽을 보면 서비스마다 별도의 데이터저장소를 사용하는 것이 더 낫다는 것을 알 수 있다. 수요가 늘어난 서비스만 확장하면 되고 확장되는 데이터베이스는 비교적 작은 데이터베이스다. 결국 작은 데이터베이스를 크게 확장하는 것이 큰 데이터베이스를 더 크게 확장하기보다 훨...

마이크로서비스 MSA

2021.06.28

마이크로서비스 아키텍처는 최신 애플리케이션과 시스템에서 일반적으로 사용하는 개발 모델이다. 대형 애플리케이션의 비즈니스 책임을 분할해 독자적으로 개발, 관리, 운영, 확장할 수 있는 별개의 구성요소로 만드는 것이 장점이다. 마이크로서비스 아키텍처는 애플리케이션 자체를 확장하기에 효과적인 모델을 제공한다. 상대적으로 크고 분리된 팀이 대규모 애플리케이션을 함께 만들면서도 각자 부분을 독자적으로 작업할 수 있다. 일반적인 마이크로서비스 아키텍처에서는 비즈니스 로직의 구체적인 하위집합을 아우르는 개별 서비스가 생성된다. 마이크로서비스 전체를 연결하면 비즈니스 로직이 포함된 완전한 대형 애플리케이션이 된다. 이러한 모델은 코드 작성에는 매우 좋지만 데이터에는 어떨까. 특정 비즈니스 로직을 위해 개별 서비스를 만드는 경우 많은 개발자가 애플리케이션 데이터 전체를 중앙집중화해 데이터 저장소 한곳에 모아야 한다고 생각한다. 즉, 각 서비스에 필요할지 모를 데이터를 모두 이용할 수 있게 해 두자는 것이다. 이렇게 한 곳에 모인 데이터 저장소는 관리하기 쉽고 간편하다. 또한, 데이터 모델링도 애플리케이션이 사용 중인 서비스와 관계없이 전체 애플리케이션이 사용하기에 일관성을 가질 수 있다. 그러나 이런 장점에도 불구하고 이렇게 하면 안 된다. 데이터를 중앙 집중화했을 때의 문제를 3가지로 정리했다.   중앙집중화된 데이터는 확장하기 어렵다 전체 애플리케이션에 대한 데이터가 중앙집중화된 한 곳의 저장소에 있으면, 애플리케이션이 커질 때 애플리케이션 내의 모든 서비스의 수요를 맞추기 위해 전체 데이터저장소를 확장해야 한다. 이러한 상황은 <그림 1>의 왼쪽이다. 그러나 <그림 1>의 오른쪽을 보면 서비스마다 별도의 데이터저장소를 사용하는 것이 더 낫다는 것을 알 수 있다. 수요가 늘어난 서비스만 확장하면 되고 확장되는 데이터베이스는 비교적 작은 데이터베이스다. 결국 작은 데이터베이스를 크게 확장하는 것이 큰 데이터베이스를 더 크게 확장하기보다 훨...

2021.06.28

IT가 신규 매출을 견인했다 ‘최신 사례 5가지’

기업 IT 부문 다수는 팬데믹 기간 중 각종 디지털 이니셔티브를 통해 조직 운영에 일조했다. 하지만 재정적으로 어려운 한 해를 보낸 많은 기업들이 IT 리더들에게 새로운 수익 창출 이니셔티브를 개발하는 과업까지 맡기고 있다. CIO 중 대다수(96%)는 IDG의 2021 CIO 현황 보고서에서 스스로의 역할이 전통적인 IT 책임을 넘어 확대되고 있다고 답했다. 비즈니스 및 IT자동화, 고객과의 직접 상호작용, 고객 여정 개발 등 더욱 수익 지향적이 되거나 새로운 제품과 서비스 개발을 지원해야 하는 과정에 참여해야 하는 중요성이 더해졌다는 응답이었다. BDO디지털(BDO Digital)의 IT 서비스 수석 국내 책임자 수지 커밍스는 “지금까지의 접근법으로는 이제 부족하다”라고 말했다. 이제 조직의 트렌드는 과거 내부적으로 추진하지 않았을 수 있는 혁신을 위한 촉매를 찾는 것이라는 설명이다. 이 과정에서 임원들이 IT를 더욱 자주 고려하고 있다고 커밍스는 전했다.  커밍스는 “팬데믹으로 IT가 재조명되었고 모두가 재택근무와 직원 참여 유지를 위해 노력했으며 이제 IT가 기업에 가치까지 더해주어야 한다고 요구하고 있다”라고 말했다. 조직의 수익 창출을 위해 고민하는 IT 리더의 5가지 현실 사례를 살펴본다.   내부 앱을 제품화 시작은 컴퓨터에 삽입되고 시간이 지나면서 마모되는 녹색 보드인 내장 칩 슈터(Shooter)의 노즐을 대체하기 위한 이니셔티브였다. 이로 인해 칩은 잘못된 위치로 갈 수 있다고 글로벌 산업 자동화 및 정보 관리 시스템 공급업체인 로크웰 오토메이션(Rockwell Automation)의 수석 부사장 겸 CDIO 크리스 나르데치아가 말했다. 또한 유지보수가 필요할 때 다운타임이 발생할 수도 있었다. 나르데치아는 “노즐이 언제 고장 날지 알 수 있다면 좋겠다고 생각했다”라며 이야기를 시작했다. 약 18개월 전, 그의 데이터 및 분석팀은 이를 위한 머신러닝 알고리즘을 개발했다. 그는 “노즐 내장 기계를 제작하는 한 ...

매출 창출 IT 팬데믹 마이크로서비스 금융 애널리틱스

2021.06.11

기업 IT 부문 다수는 팬데믹 기간 중 각종 디지털 이니셔티브를 통해 조직 운영에 일조했다. 하지만 재정적으로 어려운 한 해를 보낸 많은 기업들이 IT 리더들에게 새로운 수익 창출 이니셔티브를 개발하는 과업까지 맡기고 있다. CIO 중 대다수(96%)는 IDG의 2021 CIO 현황 보고서에서 스스로의 역할이 전통적인 IT 책임을 넘어 확대되고 있다고 답했다. 비즈니스 및 IT자동화, 고객과의 직접 상호작용, 고객 여정 개발 등 더욱 수익 지향적이 되거나 새로운 제품과 서비스 개발을 지원해야 하는 과정에 참여해야 하는 중요성이 더해졌다는 응답이었다. BDO디지털(BDO Digital)의 IT 서비스 수석 국내 책임자 수지 커밍스는 “지금까지의 접근법으로는 이제 부족하다”라고 말했다. 이제 조직의 트렌드는 과거 내부적으로 추진하지 않았을 수 있는 혁신을 위한 촉매를 찾는 것이라는 설명이다. 이 과정에서 임원들이 IT를 더욱 자주 고려하고 있다고 커밍스는 전했다.  커밍스는 “팬데믹으로 IT가 재조명되었고 모두가 재택근무와 직원 참여 유지를 위해 노력했으며 이제 IT가 기업에 가치까지 더해주어야 한다고 요구하고 있다”라고 말했다. 조직의 수익 창출을 위해 고민하는 IT 리더의 5가지 현실 사례를 살펴본다.   내부 앱을 제품화 시작은 컴퓨터에 삽입되고 시간이 지나면서 마모되는 녹색 보드인 내장 칩 슈터(Shooter)의 노즐을 대체하기 위한 이니셔티브였다. 이로 인해 칩은 잘못된 위치로 갈 수 있다고 글로벌 산업 자동화 및 정보 관리 시스템 공급업체인 로크웰 오토메이션(Rockwell Automation)의 수석 부사장 겸 CDIO 크리스 나르데치아가 말했다. 또한 유지보수가 필요할 때 다운타임이 발생할 수도 있었다. 나르데치아는 “노즐이 언제 고장 날지 알 수 있다면 좋겠다고 생각했다”라며 이야기를 시작했다. 약 18개월 전, 그의 데이터 및 분석팀은 이를 위한 머신러닝 알고리즘을 개발했다. 그는 “노즐 내장 기계를 제작하는 한 ...

2021.06.11

MS, 비주얼 스튜디오 코드에 ‘프로젝트 타이’ 지원

마이크로소프트가 비주얼 스튜디오 코드(Visual Studio Code)에서 ‘프로젝트 타이(Project Tye)’를 사용할 수 있는 확장 기능을 제공한다. 프로젝트 타이는 마이크로서비스와 분산형 애플리케이션을 쉽게 구축하고 테스트하며 배포할 수 있는 닷넷(.NET) 도구다.    --> "마이크로서비스 개발을 쉽게"··· 마이크로소프트 '프로젝트 타이' 소개 현재 비주얼 스튜디오 마켓플레이스(Visual Studio Marketplace)에서 프리뷰로 다운로드할 수 있는/사용할 수 있는 이 확장 기능은 VS 코드에서 애플리케이션을 더 쉽게 보고 실행하며 디버깅할 수 있도록 지원한다.  이 확장 기능을 사용하면 타이 애플리케이션이 실행되는 즉시 타이 탐색기 인터페이스에 서비스가 표시된다. 개발자는 탐색기에서 서비스 로그를 보거나, 액세스 가능한 엔드포인트가 있는 서비스를 찾거나, 닷넷 서비스에 디버거를 연결할 수 있다. 브라우저 기반 타이 대시보드로 빠르게 이동할 수 있는 링크도 포함돼 있다고 회사 측은 덧붙였다.  또 이 확장 기능은 디버깅 없이 타이 애플리케이션을 실행하거나 서비스의 전체 또는 일부를 디버깅하는 기능으로 다양한 디버깅 시나리오를 지원한다. 이 밖에 watch 모드에서 서비스를 디버깅할 수 있는데, 여기서 디버거는 코드 변경사항을 감시하고 프로세스에 다시 연결하여 앱을 재시작하지 않고도 디버깅을 계속할 수 있다.  회사에 따르면 타이 애플리케이션을 실행 및 디버깅하려면 구성을 시작하는 명령이 필요하다. 이 확장 기능을 통해 Tye: Scaffold Tye Tasks 명령을 사용하여 기본 작업을 스캐폴드하고 구성을 시작할 수 있다. 이미 실행 중인 프로젝트 기반 서비스에 디버거를 연결하는 데 해당 확장 기능을 사용할 수도 있다.  한편 타이 자체를 사용하려면 도커(Docker)를 설치해야 한다. 개발자는 이곳(dotnet/tye)을 포함해 도움말 및 피드백 섹션,...

마이크로소프트 MS 비주얼 스튜디오 코드 개발자 프로젝트 타이 마이크로서비스 분산형 애플리케이션 닷넷

2021.06.11

마이크로소프트가 비주얼 스튜디오 코드(Visual Studio Code)에서 ‘프로젝트 타이(Project Tye)’를 사용할 수 있는 확장 기능을 제공한다. 프로젝트 타이는 마이크로서비스와 분산형 애플리케이션을 쉽게 구축하고 테스트하며 배포할 수 있는 닷넷(.NET) 도구다.    --> "마이크로서비스 개발을 쉽게"··· 마이크로소프트 '프로젝트 타이' 소개 현재 비주얼 스튜디오 마켓플레이스(Visual Studio Marketplace)에서 프리뷰로 다운로드할 수 있는/사용할 수 있는 이 확장 기능은 VS 코드에서 애플리케이션을 더 쉽게 보고 실행하며 디버깅할 수 있도록 지원한다.  이 확장 기능을 사용하면 타이 애플리케이션이 실행되는 즉시 타이 탐색기 인터페이스에 서비스가 표시된다. 개발자는 탐색기에서 서비스 로그를 보거나, 액세스 가능한 엔드포인트가 있는 서비스를 찾거나, 닷넷 서비스에 디버거를 연결할 수 있다. 브라우저 기반 타이 대시보드로 빠르게 이동할 수 있는 링크도 포함돼 있다고 회사 측은 덧붙였다.  또 이 확장 기능은 디버깅 없이 타이 애플리케이션을 실행하거나 서비스의 전체 또는 일부를 디버깅하는 기능으로 다양한 디버깅 시나리오를 지원한다. 이 밖에 watch 모드에서 서비스를 디버깅할 수 있는데, 여기서 디버거는 코드 변경사항을 감시하고 프로세스에 다시 연결하여 앱을 재시작하지 않고도 디버깅을 계속할 수 있다.  회사에 따르면 타이 애플리케이션을 실행 및 디버깅하려면 구성을 시작하는 명령이 필요하다. 이 확장 기능을 통해 Tye: Scaffold Tye Tasks 명령을 사용하여 기본 작업을 스캐폴드하고 구성을 시작할 수 있다. 이미 실행 중인 프로젝트 기반 서비스에 디버거를 연결하는 데 해당 확장 기능을 사용할 수도 있다.  한편 타이 자체를 사용하려면 도커(Docker)를 설치해야 한다. 개발자는 이곳(dotnet/tye)을 포함해 도움말 및 피드백 섹션,...

2021.06.11

벤더 기고ㅣ엔터프라이즈를 위한 서버리스 퍼스트 전략

아마존 CTO 버너 보겔스 박사는 2019년 re:Invent 키노트 세션을 통해 "AWS에서 기대하는 미래의 모습은, 개발자가 작성하는 모든 코드는 오직 비즈니스 로직일 뿐입니다"라고 언급했다. 이 짧은 한 문장은 많은 의미를 함축하고 있다. 일반적으로 개발자는 비즈니스 로직을 구현하는 것 외에 애플리케이션의 스케일링, 인프라 오케스트레이션, 가용성, 보안, 배포 등도 고려해서 개발한다. 대부분의 근무 시간을 비즈니스 로직 구현에 할당해야 하지만 현실은 부가적인 일에 생각보다 많은 시간을 할애하고 있는 것이 사실이다. * 벤더가 작성한 본 기고문은 벤더의 시각과 주장, 솔루션에 대한 직접적인 내용을 담고 있다. 하지만 가까운 미래에는 개발자가 비즈니스 로직을 구현하는 일에 보다 집중할 수 있는 환경이 될 것으로 전망한다. 필자는 ‘개발자가 비즈니스 로직을 구현하는 일에 집중’할 수 있다는 말의 배경에는 ‘서버리스 컴퓨팅(Serverless computing)의 확산과 발전’이 큰 역할을 할 것으로 본다. 컴퓨팅 환경의 진화 서버리스 컴퓨팅에 대해 얘기하기 전에 먼저 컴퓨팅의 환경이 어떻게 진화했는지 알아보고자 한다. • 우리가 알고 있는 '서버(Servers)' 불과 10여년 전만 해도 새로운 서비스를 개발하기 위해서는 물리 서버를 구매하는 것을 당연하게 생각했다. 일반적으로 5년(또는 3년)을 기준으로, 사용자 트래픽 증가를 고려해서 용량을 산정하고 그 용량을 기반으로 서버와 스토리지, 네트워크 장비 등의 스펙을 결정했다.  물리 서버들이 데이터센터에 입고되고 랙에 스택킹이 된 후 UTP 케이블이 서버에 연결되면 이때부터 본격적인 서버 작업이 시작된다. 이후 OS를 설치하고, 정책에 기술된 보안 패키지 설치와 구성 설정을 하고, 서버 관리를 위한 다양한 유틸리티를 설치하며, 네트워크 툴을 설치하고, 백업을 위한 스크립트 등 수 많은 작업을 수행했다. 보통 시스템 엔지니어들은 항상 수십(또는 ...

AWS 아마존 웹 서비스 엔터프라이즈 서버리스 컨테이너 서버 가상 머신 도커 AWS 람다 인프라 넷플릭스 쿠팡 배달의 민족 마이크로서비스 데브옵스

2021.06.01

아마존 CTO 버너 보겔스 박사는 2019년 re:Invent 키노트 세션을 통해 "AWS에서 기대하는 미래의 모습은, 개발자가 작성하는 모든 코드는 오직 비즈니스 로직일 뿐입니다"라고 언급했다. 이 짧은 한 문장은 많은 의미를 함축하고 있다. 일반적으로 개발자는 비즈니스 로직을 구현하는 것 외에 애플리케이션의 스케일링, 인프라 오케스트레이션, 가용성, 보안, 배포 등도 고려해서 개발한다. 대부분의 근무 시간을 비즈니스 로직 구현에 할당해야 하지만 현실은 부가적인 일에 생각보다 많은 시간을 할애하고 있는 것이 사실이다. * 벤더가 작성한 본 기고문은 벤더의 시각과 주장, 솔루션에 대한 직접적인 내용을 담고 있다. 하지만 가까운 미래에는 개발자가 비즈니스 로직을 구현하는 일에 보다 집중할 수 있는 환경이 될 것으로 전망한다. 필자는 ‘개발자가 비즈니스 로직을 구현하는 일에 집중’할 수 있다는 말의 배경에는 ‘서버리스 컴퓨팅(Serverless computing)의 확산과 발전’이 큰 역할을 할 것으로 본다. 컴퓨팅 환경의 진화 서버리스 컴퓨팅에 대해 얘기하기 전에 먼저 컴퓨팅의 환경이 어떻게 진화했는지 알아보고자 한다. • 우리가 알고 있는 '서버(Servers)' 불과 10여년 전만 해도 새로운 서비스를 개발하기 위해서는 물리 서버를 구매하는 것을 당연하게 생각했다. 일반적으로 5년(또는 3년)을 기준으로, 사용자 트래픽 증가를 고려해서 용량을 산정하고 그 용량을 기반으로 서버와 스토리지, 네트워크 장비 등의 스펙을 결정했다.  물리 서버들이 데이터센터에 입고되고 랙에 스택킹이 된 후 UTP 케이블이 서버에 연결되면 이때부터 본격적인 서버 작업이 시작된다. 이후 OS를 설치하고, 정책에 기술된 보안 패키지 설치와 구성 설정을 하고, 서버 관리를 위한 다양한 유틸리티를 설치하며, 네트워크 툴을 설치하고, 백업을 위한 스크립트 등 수 많은 작업을 수행했다. 보통 시스템 엔지니어들은 항상 수십(또는 ...

2021.06.01

'주류화되기에는 미흡'··· 깃옵스가 아직 준비되지 않은 이유

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

깃옵스 Gitops 컨테이너 쿠버네티스 마이크로서비스 데브옵스 애자일

2021.05.13

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

2021.05.13

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.4.0.31