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.

리팩터링

“마이크로소프트 365도 옮겼다” 윈도우 앱을 컨테이너로 옮기는 방법

마이크로소프트 플랫폼 상에서 구축 작업을 하는 개발자라면 누구나 알고 있는 오랜 격언은 “어떤 마이크로소프트 제품이 전성기를 맞이할 준비가 되었는지 파악하려면, 그 제품이 마이크로소프트의 주력 애플리케이션이나 서비스에 사용되는지 여부를 보면 알 수 있다”는 것이다.  즉, 올리언스(Orleans) 분산 애플리케이션 프레임워크는 헤일로(Halo)의 대부분을 구동했을 때, 플루이드 프레임워크(Fluid Framework)는 팀즈(Teams) 내에 들어갔을 때 등등이 본격적으로 사용할 때가 되었다는 의미이다. 최근에 승인 도장을 받은 서비스는 애저 쿠버네티스 서비스(Azure Kubernetes Service, AKS) 상의 윈도우 컨테이너다. 마이크로소프트는 코로나19 대유행에 따른 급속한 업무 패턴의 변화를 고려한 확장성 및 유연성 제고를 위해 마이크로소프트 365 플랫폼의 대부분을 AKS로 옮기는 작업에 지난 1년 정도를 보냈다.       마이크로소프트 365, 클라우드 네이티브 컨테이너로 이전 마이크로소프트 365 규모의 서비스를 컨테이너로 옮기는 과정은 복잡했다. 오피스 온라인(Office Online) 단일 테넌트 시스템을 멀티 테넌트 가상화 아키텍처로 옮기는 일은 특히 CI/CD로의 이전을 동반한 경우 충분히 어려웠다. 제일 먼저 이전한 것은 컨테이너로의 이전에 필요한 아키텍처 개선의 많은 부분이었다. 무엇보다도 애플리케이션 VM에서 마이크로소프트 그래프(Microsoft Graph)로 옮기는 것이 중요했다. 그러나 많은 서비스, 특히 테넌트를 구성하는 서비스와 시스템 사이의 네트워킹을 지원하고 가용성을 관리하는 용도의 서비스는 여전히 커스텀 방식이었다.  이 접근법은 일관성 부재로 이어졌다. 애플리케이션 빌드는 특정 플랫폼을 목표로 해야 했다. 그 결과, 아키텍처의 비효율성이 발생했다. 서로 다른 VM을 호스팅하려면 서로 다른 서버 종류가 필요했기 때문이다. 마이크로소프트 365 서비스를 호스팅한 ...

마이크로소프트365 마이그레이션 리팩터링 2022.08.22

AWS, 메인프레임 마이그레이션 서비스 정식 출시

AWS가 메인프레임 사용 기업의 앱을 클라우드로 이전할 수 있도록 지원하는 서비스 AWS 메인프레임 모더나이제이션(AWS Mainframe Modernization) 서비스를 정식 출시했다. 지난 해 11월부터 프리뷰 상태로 공개된 이 서비스는 메인프레임 애플리케이션의 클라우드 마이그레이션을 관리하는 툴과 인프라, 소프트웨어를 제공한다.   기업은 AWS가 제공하는 툴을 이용해 코볼 같은 개발 언어로 작성된 워크로드를 리팩터링할 수 있으며, 아니면 기존 워크로드를 그대로 유지하면서 최소한의 코드 변경으로 AWS로 플랫폼만 바꿀 수도 있다. 매니지도 런타임 환경은 이전한 애플리케이션을 실행하는 데 필요한 컴퓨트, 메모리, 스토리지를 제공하며, 용량 프로비저닝이나 보안, 로드밸런싱, 확장, 애플리케이션 상태 모니터링 등의 세부 운영은 자동화된다. 이 서비스를 위한 AWS 마이그레이션 허브는 한 지점에서 AWS와 파트너 서비스 전반에 걸쳐 애플리케이션 마이그레이션의 진행 상태를 추적할 수 있다. 파트너로는 액센츄어, DCX 테크놀로지, 타타, 아토스, 마이크로 포커스, 인포시스 등이 참여한다. 참고로 AWS 외에도 구글 클라우드와 마이크로소프트 애저 등이 메인프레임 현대화 서비스를 제공한다. 하지만 메인프레임 기반의 기업이 모두 클라우드를 원하는 것은 아니다. 이런 기업을 위해 IBM 역시 메인프레임과 관련 생태계를 꾸준히 개선하고 있다. 지난 4월 IBM은 AI나 보안, 하이브리드 클라우드, 오픈소스 등 현대 기업의 요구사항을 초점을 맞춘 z16 메인프레임을 발표했다. 특히 텔럼(Telum) 프로세서에 AI 가속기를 탑재해 하루 3,000억 건의 추론을 수행할 수 있도록 관련 기능을 강화했다. 용량과 암호화 기능을 강화해 미션 크리티컬 애플리케이션을 안전하게 구동하는 한편, 퍼블릭 클라우드 서비스도 이용할 수 있도록 했다. 이런 성능과 확장성으로 하이브리드 클라우드 환경에서 메인프레임의 활용도를 높였다.  AWS의 새 서비스 요금제는...

메인프레임 마이그레이션 AWS 2022.06.10

IDG 블로그 | 클라우드 마이그레이션에는 6R 이상이 필요하다

클라우드 마이그레이션의 카테고리는 6R(Retire, Retain, Replace, Rehost, Re-platform, Refactor)이다. 필자도 6R이 어디서 어떻게 시작됐는지는 모르지만, 클라우드 마이그레이션 프로젝트의 발표자료에서 이런 저런 형태로 볼 수 있다.   6R이 중요한 이유는 단순하다. 기업은 워크로드가 있고, 이들 워크로드는 보통 애플리케이션 및 관련 데이터가 클라우드에 있지 않다. 그리고 기업은 이들 워크로드가 앞으로 어떻게 될지를 카테고리로 나누고자 한다. 이런 맥락에서 6R은 다음과 같은 의미를 갖는다.   Retire : 워크로드를 완전히 제거하거나 수명을 끝낸다. Retain : 현재 상태로 유지한다. Replace : SaaS 시스템이나 다른 유사한 대체제를 찾는다. Rehost : 들어서 옮긴다. 즉 별다른 수정없이 그대로 클라우드로 옮긴다. 예를 들어, 온프레미스 리눅스 환경을 클라우드 리눅스 환경으로 옮기는 식이다. 필자는 리호스트를 리팩터링과는 다르게 보는데, 리호스팅에서 애플리케이션은 클라우드에서 구동될 뿐, 클라우드 네이티브 서비스를 이용하지는 않는다. Replatform : 이전하고자 하는 클라우드에서 기존 플랫폼과 유사한 대체재를 찾을 수 없다면, 새로운 플랫폼으로 이전한다. 예를 들어, 리눅스를 윈도우로 바꾸는 식이다. 간혹 새로운 데이터베이스나 기타 플랫폼을 변경하기도 한다. 이 때문에 워크로드는 새로운 플랫폼에 맞도록 수정해야 하지만, 클라우드 네이티브 서비스를 반드시 이용해야 하는 것은 아니다. Refactor : 워크로드를 대폭 수정해 클라우드 보안이나 거버넌스, 모니터링, 감사 등 클라우드 네이티브 기능의 이점을 이용할 수 있도록 한다. 물론, Replace 대신 Repurchase를 넣을 수도 있고, 정의가 조금 다른 경우도 있다. 자신이 알고 있는 내용과 약간 차이가 있더라도 오늘의 주제에는 큰 문제가 되지 않는다. 기업은 수백 수천의 워크로드를 보고 6R 중...

마이그레이션 리호스팅 리팩터링 2022.01.12

IDG 블로그 | 클라우드옵스의 벽에 부딪혔을 때 해야 할 일

신임 CIO의 수요일 아침 9시. IT 운영 책임자와 긴급 줌 회의를 갖는다. 화면에 나타난 얼굴은 침울한 표정이며, 이유는 회의의 목적을 설명하면서 분명해진다. IT 운영팀은 올해 100만 달러의 예산을 받았는데, 예기치 않은 비용 때문에 40만 달러를 초과 사용해야 할 것으로 보인다. 최근 퍼블릭 클라우드로 이전한 일군의 애플리케이션과 데이터베이스를 운영하는 데 필요한 운영 인력과 툴 때문이다.   무슨 일이 일어난 것일까? ‘클라우드옵스의 벽(Cloudops wall)’에 부딪힌 것으로 보인다. 클라우드에 배치한 시스템 운영 비용을 20~30% 낮게 잡은 것이다. 많아도 온프레미스 시스템보다 10% 더 잡은 정도일 것이다. 실제로 업계에서는 운영 비용이 줄어들 것이라고 말한다. 하지만 현실은 몇 가지 일이 일어나기 마련이다. 첫째, 코로나19 팬데믹으로 많은 기업이 다음에 이전할 계획이었던 시스템을 클라우드로 옮겼다. 처음에 옮기지 않은 것은 더 복잡하고 설계도 좋지 않았기 때문이다. 게다가 이들 시스템은 새로운 방식으로 동작한다. 예를 들어, 데이터를 소비하는 클라우드 기반 데이터베이스는 같은 데이터센터에 있는 전통적인 데이터베이스와는 다르다. 둘째, 클라우드 마이그레이션이 속도전으로 이루어졌기 때문에 많은 실용적인 단계를 압축하거나 건너뛰었다. 클라우드 네이티브 서비스를 이용하는 데 필요한 리팩터링이나 일부 이전 시스템의 컨테이너화도 빼먹고 더 빠르고 저렴한 리프트 앤 시프트 프로세스를 선택했다. 마지막으로, 가장 중요한 문제는 회사 내의 누구도 이런 종류의 시스템을 대상으로 클라우드옵스를 수행해 본 적이 없다는 것이다. 예를 들어, 메인프레임 기반 시스템을 퍼블릭 클라우드 이전하는 것은 조금 더 현대적인 LAMP 스택을 이전하는 것과는 아주 다르다. 이런 기술력이 없다 보니, 계획 수립의 대부분이 어림짐작으로 이루어질 수밖에 없다. 클라우드옵스의 벽 문제를 바로잡는 몇 가지 방법을 소개한다. 첫째, 클라우드로 이전할 때 리팩...

클라우드옵스 리팩터링 최적화 2021.09.15

IDG 블로그 | 비용과 확장성을 최적화하는 클라우드 아키텍처 3가지

클라우드 기반 플랫폼의 가장 잘 알려진 이점은 사용한 만큼 내는 비용과 거의 무제한에 가까운 자원으로 확장할 수 있는 역량이다. 수요가 있기 전에 자원을 미리 구매할 필요도 없으며, 물리 하드웨어와 소프트웨어가 얼마나 필요할지 추정할 필요도 없다. 하지만 기업 IT 부서는 클라우드 컴퓨팅에서 확장성과 비용은 서로 연결된 개념이라는 것을 알아야 한다. 자원을 더 많이 사용할수록, 더 많은 비용을 내야 한다. 따라서 클라우드 비용은 자원 자체의 가격만큼이나 아키텍처 패턴에 따라 달라진다.   클라우드 기반 시스템을 구축할 때, 클라우드 아키텍처는 정말로 수많은 정답을 만들어 낸다. 물론 잘못된 결정을 내린다고 처벌을 받지는 않는다. 단지 덜 최적화될 뿐이다. 어떻게든 동작만 하면, 확장성과 비용을 완벽하게 최적화한 아키텍처보다 2배나 많은 비용을 낸다는 사실을 감춰준다.  아키텍처는 특정 클라우드 플랫폼에 최적화하기 위해 애플리케이션을 리팩터링하거나 다시 작성할지를 결정할 때 매우 중요한 요소이다. 아니면 마이크로서비스나 이벤트 지향, 컨테이너, 컨테이너 오케스트레이션 등 핵심 구현 기술을 선택할 때도 중요하다. 이런 결정이 모여 월말에 받아보는 클라우드 요금 고지서의 숫자가 결정된다.  그렇다면, 클라우드 아키텍트가 비용과 확장성 측면에서 생각해야 할 것은 무엇일까? 몇 가지 범용적인 아키텍처 패턴을 소개한다. 클라우드 기반 애플리케이션을 애플리케이션에 필요한 모든 클라우드 서비스의 최적화에 맞춰 튜닝하는 법을 배운다. 다시 말해, 애플리케이션을 데이터를 처리하고 기능을 수행하는 데 최소의 자원을 사용하도록 최적화해야 한다.  이런 아키텍처 최적화는 컴퓨팅의 초창기, 즉 8KB 메모리를 탑재한 1970년대 장비를 다룰 때는 흔한 일이었다. 요즘 개발자는 애플리케이션을 작성할 때 이런 미니멀리즘 접근법으로 최적화하는 데 익숙하지 않다. 하지만 이렇게 하기만 한다면, 애플리케이션은 더 빨리 무한대로 확장하는 비용 증가...

확장성 아키텍처 리팩터링 2021.01.20

IDG 블로그 | 애플리케이션 성능 튜닝과 비용 효율성

퍼블릭 클라우드 컴퓨팅의 탄력적인 용량은 장점과 단점이 있다. 모든 자원을 프로비저닝해 성능 문제를 해결할 수 있다. 하지만 좋든 싫든 이런 상황에 돈을 투여하는 것으로는 문제의 근본 원인을 바로 잡지 못한다. 문제는 보통 잘못된 설계나 잘못된 코딩으로 인한 것이기 때문이다.   하지만 일부 클라우드 애플리케이션 개발과 설계의 기본적인 기법만으로 많은 성능 문제를 해결하거나 최소한 완화할 수 있다. 이에 따라 클라우드 사용 요금 역시 절감할 수 있다. 애플리케이션 성능을 개선하고 비용 효율성도 높일 수 있는 세 가지 방안을 소개한다. 서버리스 컴퓨팅을 이용한다. 서버리스를 이용하면 비용이 더 많이 나온다는 보고서도 적지 않지만, 필자의 경험은 다르다. 애플리케이션 코드와 데이터베이스 구조를 파헤쳐 성능 문제를 세밀하게 조정할 것이 아니라면, 서버리스 컴퓨팅은 자원 프로비저닝을 클라우드 서비스 업체에 맡긴다. 서비스 업체는 어떻게 하면 자원을 더 최적화할 수 있는지 사용자보다 더 잘 알고 있다.  개념적으로 서버리스 시스템은 애플리케이션의 실시간 자원 요구사항을 기반으로 하기 때문에 오버프로비저닝이나 언더프로비저닝은 일어나지 않는다. 클라우드 자원의 최적화는 서버리스 플랫폼 자체의 책임이 된다. 최적화하지 않은 애플리케이션과 데이터베이스를 서버리스 환경에 맞춰 리팩터링하면 성능이 개선되는 것을 알게 될 것이다. 기술적인 미봉책에 불과하다고 생각할 수도 있는데, 사실이다. 애플리케이션을 재설계하거나 재코딩, 재배치할 수 없지만, 서버리스 플랫폼으로 이식할 수는 있다는 가정 하에 사용하는 방법이다. 물론 첫 달에 서버리스 환경으로 이전하는 데는 비용이 들겠지만, 전후의 비용을 비교할 지표를 모아야 할 것이다. 데이터를 애플리케이션과 같은 위치에 배치하라. 데이터를 애플리케이션과 가능한 한 가까운 곳에 저장하는 것은 기본적인 아키텍처 원칙이다. 하지만 여전히 데이터베이스를 애플리케이션과 다른 리전이나 다른 클라우드, 심지어 퍼블릭 클라우드...

튜닝 데이터베이스 리팩터링 2020.12.03

IDG 블로그 | 클라우드 마이그레이션의 “같은 툴 다른 결과”와 대응 방안

수요일 아침 9시, 경영진 앞에서 클라우드 마이그레이션 프로젝트의 진행 현황을 보고한다. 최근의 코로나19 팬데믹 동안 발견된 취약점 대부분을 제거할 계획이다. 이번이 세 번째 마이그레이션 프로젝트로, 워크로드 100개, 데이터 세트 10개 정도를 마이그레이션한다. 모든 것은 병렬로 진행되었고, 서로 다른 클라우드 마이그레이션팀 모두가 참여했다.   경영진은 프로젝트 간의 측정치가 매우 다르다는 점을 지적한다. 첫 프로젝트는 코드 리팩터링과 테스트, 배치, 보안 구현 등에서 80%의 효율을 기록했다. 다른 프로젝트는 30~40% 정도이다. 왜 차이가 나는가? 효율성 문제 대부분은 정적인 마이그레이션 접근법과 툴 때문에 생겨난다. 현재 클라우드 마이그레이션을 진행하는 사람 대부분은 과거 프로젝트에서 잘 사용했던 구체적인 프로세스와 접근법, 마이그레이션 툴 스위트에 비중을 둔다. 이런 정적인 접근법은 매우 폭넓은 종류의 마이그레이션 프로젝트와 문제에 특정 프로세스와 툴을 강요한다. 하지만 특정 프로세스와 툴을 마치 범용 솔루션처럼 잘못 사용하면 실패로 이어지기 쉽다. 이 문제의 핵심은 업계에서 ‘동급 최강’으로 여겨지는 특정 툴 스위트와 기술 묶음을 찾으려는 것과 베스트 프랙티스를 이용하고자 하는 욕심에 있다. IT 분야 사람들은 주류를 따르는 것을 좋아한다. “이 툴과 접근법에 대해 읽었는데, 우리랑 비슷한 업종인 철수와 영희네 회사에 잘 맞았으니, 우리한테도 잘 맞을 거야.” 선택은 상황에 따라 다르기 마련인데, 직접 선택하지 않는 것으로 위험을 제거할 수 있다는 잘못된 가정을 하는 것이다. 이 분야의 전문가로서 필자도 모두의 요구를 만족할 표준 마이그레이션 툴 목록을 제시하고 싶다. 하지만 현실적인 답변은 마이그레이션하려는 애플리케이션과 데이터베이스의 요구사항을 기반으로 툴과 접근법을 선택해야만 한다는 것이다.  마이그레이션 프로젝트의 대표적인 프로젝트 범주와 검토 과정은 다음과 같다.   현재 플랫폼 평가 애플리케...

마이그레이션 리팩터링 2020.10.12

IDG 블로그 | 애플리케이션 마이그레이션, 회색 음영을 살펴라

클라우드로 이전할 애플리케이션의 리팩터링에서 클라우드 네이티브의 필요성을 강하게 주장했지만, 현실은 그렇게 흑백으로 나뉘지 않는다. 애플리케이션을 퍼블릭 클라우드로 이전하는 일반적인 접근법은 클라우드 네이티브 기능의 이점을 활용할 수 있도록 애플리케이션을 수정하는 것이다. 애플리케이션이 클라우드 네이티브 관리 시스템, 보안 시스템, 기타 네이티브 서비스와 이야기할 수 있도록 하는 것이다. 대안으로 리프트 앤 시프트 방식이 있다. 가능한 한 애플리케이션을 거의 수정하지 않고 이전하는 방식이다. 이 경우, 클라우드 네이티브 기능을 함께 이용하는 것은 포기해야 한다.   베스트 프랙티스는 양쪽 극단의 접근법, 즉 클라우드 네이티브에 올인하거나 전혀 이용하지 않는 두 가지로 나뉘어 나타났다. 하지만 현실은 이렇게 양분된 결정이 아니며, 많은 기업이 찾는 해답은 스펙트럼에 걸쳐 동작하는 것이 될 수도 있다. 첫째, 우리는 애플리케이션이 서로 다른 비즈니스 문제를 해결하기 위해 서로 다른 목적으로 만들어졌다는 것을 잘 알고 있다. 이런 애플리케이션의 리팩터링에 모든 문제를 해결하는 만능 해법식 접근을 하는 것은 현실적이지 않다는 것도 이미 알고 있다.  둘째, 많은 기업이 자사의 목적을 고려해 애플리케이션의 올바른 리팩터링 접근 방안을 골라야 한다는 사실을 모른다. 애플리케이션 마이그레이션이 실패하는 주된 이유이기도 하다. 필자가 가장 자주 보는 실수는 범용적인 접근법을 선택하는 것이다. 애플리케이션의 기능성을 살펴보지도 않고, 모든 애플리케이션에 클라우드 네이티브 보안과 암호화가 필요하다고 결정해 버린다. 하지만 정작 해당 애플리케이션은 클라우드 네이티브 관리 서비스도 AI나 서버리스, 머신러닝 같은 떠오르는 기술도 이용할 필요가 없다. 이런 일은 편의성 때문에 일어난다. 개발자에게 특정 기능을 일관성 있게 사용하고 나머지는 신경 쓰지 말라고 하는 것이 훨씬 쉽기 때문이다. 더 적은 자체 기술력과 더 적은 툴로 버틸 수 있고, 그래서 개...

리팩터링 마이그레이션 리프트앤시프트 2020.07.29

IDG 블로그 | 2020년 클라우드에서의 서비스 현황

생각해 보면, 서비스란 정말로 오래된 것이다. 우리는 API를 지원하는 애플리케이션을 둘러싼 초기의 힘든 시절로부터 객체 지향 프로그래밍으로, CORBA 기반 서비스로, SOA로, 컨테이너로, 서버리스 함수로, 그리고 오늘날의 마이크로서비스까지 발전해 왔다.   이 여정에서 공통된 것이 있다면, 무엇인가를 한 번 작성하면 그것을 서로 다른 애플리케이션이나 유틸리티에서 여러 번 사용할 수 있다는 믿음이 기반이 되었다는 것이다. 물론 여러 서비스를 조합해 그 자체로 새로운 서비스를 만들 수 있는 역량은 말할 것도 없다. 이는 서비스 해체를 통해 이루어졌다. 오늘날 ‘서비스’란 말은 남용되고 있다. 클라우드 컴퓨팅 세계에서 서비스란 말은 퍼블릭 클라우드 서비스 업체가 드러내는 모든 것을 설명하는 단어로 사용된다. 최소한 필자가 이해하는 방식에서 서비스란 행위와 그 행위에 연결된 데이터 모두를 개발자가 좀 더 생산적일 수 있는 방식으로 드러내는 역량이다. 예를 들어, 서비스는 전달되는 모든 종류의 데이터 세트에서 예측 분석을 수행할 수 있도록 구축할 수도 있다. 그래서 이 서비스는 재고 관리 애플리케이션이나 영업 주문 등록 시스템에서 호출할 수 있다. 만약 서비스가 변경되거나 개선되면, 이들 애플리케이션 역시 혜택을 얻는다. 또한 단일 서비스를 변경하는 것으로 수백 줄의 코드를 골라내거나 애플리케이션에서 해당 기능을 수정하거나 개선하지 않고도 예측 분석 수행 방식을 변경할 수 있다. 개발자는 일종의 변동성을 해당 영역에 배치한 셈인데, 이는 좋은 아키텍처의 기반이 된다. 나쁜 소식도 있다. 리프트 앤 시프트 방식은 클라우드 네이티브 기능은 물론, 서비스 지향 환경의 적이다. 서비스 가능성을 고려하지 않고 최대한 빨리 애플리케이션을 클라우드로 이전하는 것은 좋지 않은 생각이다. 안타깝게도 지금까지 클라우드 마이그레이션에 가장 많이 사용된 방식이기도 하다. 이 방식은 세 가지를 놓친다. 우선 서비스 재사용성과 서비스가 가져다주는 생산성이 불능화된다....

서비스지향 클라우드네이티브 리팩터링 2020.07.15

"리팩터링, 린트, 프로필"...완성된 코드를 개선하는 16가지 팁

작성한 코드가 모든 테스트에서 정상으로 나왔다. 지속적 통합 파이프라인도 끝까지 실행됐다. 기능 목록의 모든 체크박스를 확인했고, 벽에 붙여 둔 포스트잇 메모는 모두 완료 구역으로 이동됐다. 휴…   이쯤 되면 코드가 완성되었음을 선언하고 휴가를 떠나고 싶은 마음이 굴뚝같다. 그럴 만한 자격이 있다. 한동안 코드가 작업을 수행하도록 두면 된다. 애초에 그렇게 하려고 만들지 않았던가? 벽 너머로 던져 거기서 실행되도록 하면 그걸로 우리 일은 끝이다.   그러나 현실에 만족하는 시대는 끝났다. 요즘은 끝난다는 개념이 없다. 버그를 없앤, 기능하는 프로그램을 전달했다고 해서 쉬어도 된다는 뜻은 아니다. 그 시점에도 코드를 개선하기 위해 할 수 있는 일이 십여 가지는 있기 때문이다. 다음 팀을 위해 코드를 잘 정비하는 모범적 개발자로서 해야 할 일도 있고, 새로운 여정의 시작이라 할 만한 것도 있다.   잠깐의 휴식과 재충전 후에 돌아와서 해야 할 16가지 일을 살펴보자.   린트 린트(lint) 또는 린터(linter)라고 하는 이 툴은 일종의 코드 리뷰 로봇으로, 수백, 수천 가지의 의미 체계 규칙을 적용한다. 공백 문자의 수를 하나하나 세고 공백을 너무 많이 또는 너무 적게 사용한 개발자를 질책하는 강박적 잔소리꾼이 만든 규칙도 있고, 나중에 보안 결함으로 이어질 수 있는 모호한 의미 체계 패턴을 지적하는 깐깐한 사람들이 만든 규칙도 있다. 프로그래밍 팀이라면 이미 선택해둔 린터 모음이 있을 테니, 이제 그 린터를 실행할 시간이다.   프로필 돈 커누스는 전에 “너무 이른 최적화는 만악의 근원”이라고 말한 적이 있다. 코드에서 가끔씩만 실행될 부분을 개선하느라 시간을 허비하는 것은 어리석은 일이기 때문이다. 이제 코딩을 끝냈으니, 프로파일러를 실행해서 포화가 집중되는 지점을 찾을 시간이다. 많은 경우 코드의 10%가 90%의 시간 동안 실행된다. 때로는 조밀한 내부 루프가 사이클의 99%를 흡수하는 경우도 있다. 지금...

코드 서버리스 리팩터링 2020.03.04

IDG 블로그 | 클라우드 컴퓨팅을 어렵게 만드는 “예상치 못한 요인”

컨설팅 업체 캐피타(Capita)가 후원한 한 보고서에 따르면, 영국 기업의 60%가 클라우드 컴퓨팅이 지나친 약속을 하고 실제로는 기대를 충족시키지 못했다고 평가했다. 이 보고서는 영국 내 IT 의사결정권자 200명이 참여한 설문조사를 통해 10명 중 9명의 응답자가 클라우드 마이그레이션이 “예상치 못한 요인”으로 지연되거나 중단되었다고 털어놓았다.   필자의 경험상 이런 “예상치 못한 요인”은 보통 다음의 세 가지 문제 중 한두 가지를 포함한다. 예상치 못한 클라우드의 복잡성은 새로 구성된 클라우드옵스 부서에 엄청난 스트레스를 주어 실제로 서비스 중단이나 침해 사고의 위험마저 생긴다. 이 문제는 아직 본격적으로 논의가 이루어지지 않고 있지만, 필자는 현실적인 문제라고 생각한다. 이 보고서의 정보뿐만 아니라 2019년의 클라우드 성장률이 기대만큼 높지 않은 것도 같은 맥락인데, 복잡성 문제가 해결되지 않는 한 클라우드 성장률은 계속 둔화될 것이다. 리프트 앤 시프트 방식에 대한 잘못된 믿음 때문에 많은 기업이 빠르고 비용이 적게 드는 방식으로 애플리케이션을 클라우드로 이전했다. 그리고는 퍼블릭 클라우드의 이점을 제대로 이용하기 위해서는 애플리케이션을 리팩터링해야 한다는 것을 깨닫는다. 결국 마이그레이션을 두 번 하게 된다. 클라우드 전문 인력의 부족이 성장을 제한한다. 고위 임원의 대다수인 63%가 인력 부족이 소속 조직의 주요 우려사항 중 하나라고 답했다.  이 세 가지 문제에 대한 해답은 실용적이고 근본적인 클라우드 기술 이용으로 돌아가는 데 있다. 사실 모든 기술이 그렇다. 성공적인 클라우드 컴퓨팅은 현실적인 기대치와 견실한 계획을 필요로 한다는 것을 이해해야 한다는 의미이다.  클라우드 기술 솔루션 업체는 고객이 클라우드 컴퓨팅 기술의 실용적인 활용 방안을 이해할 수 있도록 좀 더 지원해야 한다. 지나친 약속은 과도한 마케팅 과정에서 나온다. 실제로 쉬운 클라우드 마이그레이션은 극히 드문데, 퍼블릭 클라우드로의 ...

마이그레이션 리팩터링 리프트앤시프트 2020.03.04

필드에서 바로 적용 가능한 애플리케이션 현대화 방법론

애플리케이션 현대화 기업들은 시장 출시 시간 단축과 애플리케이션 현대화의 압력에 직면해 있습니다. 또한 기존의 자산을 현대화하기 위한 최적의 접근 방식도 결정해야 합니다. 컨테이너, 쿠버네티스 및 마이크로서비스는 속도와 단순성을 제공할 수 있음을 입증하였으며 신속하게 도입되고 있습니다. IBM과 함께라면 이 모든 과정이 간편해집니다. 본 백서에서는 필드에서 바로 적용 가능한 IBM의 애플리케이션 현대화 접근방법론을 단계적으로 설명합니다. <32p> 주요 내용 - 애플리케이션 현대화의 개념 이해 - 애플리케이션 현대화로 가는 여정의 모든 팁 - 현대화 과정과 단계별 설명 : 애플리케이션 인벤토리부터 리팩토링, 클라우드 전환까지 - IBM의 독자적인 접근 방법론

마이그레이션 컨테이너 현대화 2020.02.13

IDG 블로그 | 클라우드 애플리케이션의 미래를 보장하는 방법

클라우드에서 애플리케이션을 완전히 새로 구축할 수도 있고, 서버리스 컴퓨팅이나 머신러닝 같은 클라우드 네이티브 기술을 사용할 수도 있다. 아니면 기존 애플리케이션을 이식할 수도 있다. 클라우드 네이티브 서비스를 이용할 수 있도록 리팩터링을 하거나 코드나 데이터를 거의 수정하지 않는 ‘리프트 앤 시프트’ 방식을 선택할 수도 있다.   그런데, 이렇게 구축한 애플리케이션이 클라우드에서 몇 년 이상 간다고 보장할 수 있는가? 다시 말해, 이들 애플리케이션의 미래를 어떻게 보장할 것인가? 몇 가지 핵심 권장사항을 제시한다. 우선, 장기적으로 갈 것 같지 않은 네이티브 클라우드 서비스 사용을 주의하라. 요즘에는 모두가 서버리스 시스템을 좋아하지만, 이 역시 몇 년이면 바뀌고 말 것이다. 어떤 때는 변화가 애플리케이션을 좋아하기도 한다. 즉 애플리케이션은 끊임없이 개선된다. 사용 기술이 인기를 잃으면 시스템 역시 클라우드 시장의 관심에서 멀어질지 모른다. 서버리스 개발과 배치의 인기를 지적하는 것은 아니다. 클라우드 네이티브 머신러닝이 될 수도 있고, 클라우드 네이티브 데이터베이스가 될 수도 있다. 간단히 말해, 우리는 이들 기술이 애플리케이션 개발과 배치를 위한 편리한 길을 제공할 것이라는 데 판돈을 건다. 하지만 이 길은 언젠가는 더 뛰어난 기술에 가려질 기술에 종속될 가능성도 생긴다. 둘째, 오픈소스의 신에게 기도를 올리고 오픈소스 기술에 전부를 걸 수도 있지만, 반대 급부가 있다. 물론 오픈소스 시스템의 장점은 프라이빗 클라우드와 퍼블릭 클라우드 대부분이 지원하며, 사용자 커뮤니티에 의해 유지된다는 것이다. 게다가 요즘에는 너무나 많은 오픈소스 솔루션이 있다. 단점은 위험을 줄이는 대가로 추가 작업을 많이 해야 한다는 것이다. 오픈소스 제품을 사용해 클라우드 기반 애플리케이션을 구축하려면, 아키텍처와 코딩에 더 많은 시간을 투여해야 한다. 서버리스 개발과 배치와 같은 클라우드 네이티브 시스템을 사용해 비슷한 애플리케이션을 구축하는 속도와 편의성...

개방성 수명 서버리스 2019.11.11

“메인프레임의 부활” 보안과 병렬 처리 성능으로 블록체인과 컨테이너에 탁월

메인프레임이 죽기는커녕 되살아나고 있다. 이제 코볼을 실행하지도 않는다. 블록체인과 컨테이너와 같은 현대 기술의 주목을 받고 있기 때문이다. 153명의 IT 의사결정권자를 대상으로 한 설문조사에서 응답 기업의 50%는 메인프레임을 계속 사용할 것이며, 향후 2년간 오히려 활용도가 증가할 것이라고 답했다. 메인프레임 활용을 줄이거나 메인프레임을 폐기할 것이라는 응답은 5%에 불과했다. 이번 조사는 포레스터 리서치가 하이브리드 IT 서비스 업체인 엔소노(Ensono), IT 컨설팅 서비스 업체인 와이프로(Wipro)의 의뢰로 진행했다. 메인프레임에 대한 이런 확신은 온프레미스 데이터센터를 줄이거나 없애고 클라우드로 이전하는 최근의 흐름에서 볼 때 다소 놀라운 것이 사실이다. 하지만 기업은 인프라에 하이브리드 접근방식을 취하고 있다., 일부 애플리케이션은 클라우드로 이전하는 한편, 가장 중요한 애플리케이션은 온프레미스 인프라나 메인프레임에 유지하는 전략이다. 포레스터의 이번 조사에서 메인프레임은 오래된 기술을 구동하는 것뿐만 아니라 현대 비즈니스용으로도 여전히 핵심 인프라로 고려되는 것으로 나타났다. 물론 전통적인 엔터프라이즈 애플리케이션과 워크로드는 확실히 많은 비중을 메인프레임에 의존하고 있다. ERP의 44%, 재무 회계의 45%, HR 관리의 44%, ECM의 43%가 메인프레임에서 구동되는 것으로 나타났다. 하지만 설문 응답자 중 25%는 모바일 사이트와 애플리케이션이 메인프레임으로 옮겨졌고, 27%는 새로운 블록체인 구상과 컨테이너 애플리케이션을 구동하는 데 메인프레임을 이용한다고 답했다. 포레스터는 블록체인과 컨테이너 애플리케이션은 메인프레임에 내재된 통합된 보안과 대규모 병렬 처리 성능의 이점을 잘 활용할 수 있다고 설명했다.   엔소노의 기술 및 전략 담당 최고 부사장 브라이언 클링베일은 발표문을 통해 “이번 조사는 메인프레임이 레거시용이라는 선입견에 도전한다”며, “메인프레임 현대화는 기업에 기존 레거시 애플리케이션을 계속 구동할 ...

메인프레임 설문조사 컨테이너 2019.10.22

IDG 블로그 | 엔터프라이즈 데이터베이스를 클라우드로 옮기기

데이터베이스는 자동차와 비슷하다. 모두가 뒤돌아볼 만한 빈티지 자동차를 몰고 다닌다고 생각해 보자. 아마도 처음 이 자동차가 만들어진 1970년대와 비교해 유지 비용이 20배는 더 들 것이다. 물론 새로운 자동차도 있을 것이다. 이 자동차는 엄청나게 매력적이지는 않지만, 30년 된 자동차보다는 더 빠르고 주행거리도 길고 최신 기술도 적용되어 있다.   많은 데이터 세트가 클라우드로 재배치되고 있다. 그리고 이제는 이렇게 워크로드와 데이터를 이전하는 것으로 비용을 물어야 하는 데이터베이스는 적절한 옵션을 고려해야 한다. 첫 번째 옵션은 자체 엔터프라이즈 데이터베이스 라이선스를 퍼블릭 클라우드 서비스 업체로 옮기는 것이다. 이른바 BYOL(Bring Your Own License)이다. 가장 저항이 적은 방안으로, 기업이 해야 할 것은 A 데이터베이스의 데이터를 다른 플랫폼에서 호스팅하는 A 데이터베이스로 옮기는 것뿐이다. 단지 새 플랫폼이 퍼블릭 클라우드일 뿐이다. 가장 간단한 방법이지만, 가장 저렴하지는 않다. 매년 라이선스비를 지불해야 하지만, 이 데이터베이스에는 클라우드 네이티브 데이터베이스가 제공하는 기능이나 성능을 제공하지 않을 것이다.  기업의 요구사항에 따라 다르겠지만, 일반적으로 클라우드 네이티브 데이터베이스는 클라우드에 데이터를 재배치하는 더 나은 방법으로 평가된다. 단점이라면, 데이터를 새로운 네이티브 스토리지 모델에 맞춰 재구성해야 한다는 것. 물론 이 데이터베이스에 액세스하는 애플리케이션도 수정해야 한다. 물론 필자라면 어떤 식으로든 클라우드 네이티브 서비스를 이용할 수 있도록 애플리케이션을 리팩터링하는 것이다. 새 클라우드 네이티브 데이터베이스에 맞춰 리팩터링해야 할지도 모른다. 이 방식은 일부 기업에는 너무 높은 진입 장벽이 될 수 있지만, 최종적으로 더 성능이 좋고 더 많은 기능을 제공하고 사용하는 데 드는 비용도 더 저렴한, 그리고 무엇보다도 기업의 특별한 사용례에 맞춰 구축한 애플리케이션과 데이터베이스를...

데이터베이스 마이그레이션 라이선스 2019.08.14

IDG 블로그 | 클라우드 네이티브, 싸지 않지만 치러야 할 비용

클라우드 네이티브(Cloud Native)는 클라우드에서 더 잘 동작하고 더 저렴하다. 하지만 일반적으로 레거시 소프트웨어를 클라우드 네이티브 애플리케이션으로 변환하는 데는 계획했던 것보다 더 많은 비용이 든다. 클라우드에도 예상을 뛰어넘는 가격 때문에 놀라는 것이 있다. 한숨 나오는 IaaS 퍼블릭 클라우드 요금 고지서가 아니다. 애플리케이션을 클라우드로 이전하면서 클라우드 네이티브 기능을 이용할 수 있도록 변경하는 비용이다. 애플리케이션을 클라우드로 마이그레이션하는 데는 3가지 방법이 있다. 리프트 앤 시프트(Lift and shift), 즉 기존 애플리케이션을 아무런 수정없이 그저 퍼블릭 클라우드로 옮기고 잘 되기를 기도하는 방식이다. 부분적인 리팩터링(Refactoring)은 애플리케이션을 부분적으로 수정해 일부 클라우드 네이티브 기능을 이용할 수 있도록 하는 방식이다. 완벽한 리팩터링은 애플리케이션 대부분을 재작성해 클라우드 네이티브 기능의 이점을 충분히 활용하는 것이다. 물론 리프트 앤 시프트는 가장 저렴한 방식이고, 그래서 많은 기업이 클라우드 마이그레이션 전략으로 채택한다. 단점은 애플리케이션이 있는 클라우드 플랫폼의 이점을 살리지 못하고 높은 비용 고지서와 느린 애플리케이션으로 이어진다는 것. 그리고 애플리케이션이 퍼블릭 클라우드 플랫폼에서 할 수 있는 것을 모두 하지는 못하게 된다. 기업은 클라우드로 이전하는 애플리케이션을 리팩터링하려고 한다. 필요한 작업에 대한 비용도 측정한다. 이런 리팩터링 작업은 단지 애플리케이션 자체를 재작성하는 것만이 아니라 테스트와 배치, 그리고 새로운 데브옵스 조직과 툴 체인을 사용하는 것까지도 포함한다. 문제는 비용이다. 기업이 처음에 예상했던 것보다 세 배 이상이 들어간 경우도 본다. 이는 대부분 해당 애플리케이션이 처음에 생각했던 것보다 엉망이었기 때문이며, 주요 알맹이를 먼저 괜찮은 아키텍처로 만든 다음에 클라우드 네이티브 상태로 만들어야 했다. 마치 틱틱거리는 소리...

마이그레이션 클라우드네이티브 리팩터링 2018.08.06

IDG 블로그 | “클라우드 네이티브가 나쁠 때도 있다”

클라우드 네이티브화되는 것은 좋다. 적어도 모두가 그렇게 이야기한다. 클라우드 네이티브화는 기존 애플리케이션을 리팩터링(부분적으로 재코딩하는 것)해 클라우드 네이티브 기능을 이용할 수 있도록 하는 것을 말한다. 클라우드 서비스 업체에 따라 다르겠지만, 네이티브 API부터 스토리지 시스템, 데이터베이스 시스템, 보안 시스템까지 많은 것을 누릴 수 있다. 클라우드 네이티브화하면 더 나은 성능, 더 낮은 애플리케이션 운영 비용, 더 쉬운 운영 등 수많은 이점을 클라우드 플랫폼이 발전하면 할수록 더욱 더 많이 누릴 수 있다. 하지만 클라우드 네이티브화의 어두운 면도 있으므로, 애플리케이션의 리팩터링에 상당한 시간을 들이기 전에 고려해 봄직하다. 고려사항은 다음과 같다. 종속성 문제. 기존 애플리케이션의 이식성 전부나 일부를 포기하지 않고 클라우드 네이티브 애플리케이션을 만들 수 없다. 애플리케이션을 AWS나 구글 클라우드 플랫폼, 마이크로소프트 애저에 맞춰 만든다면, 이들 애플리케이션의 네이티브 API에 맞춰 코딩해야 한다. 네이티브 API를 사용함으로써 해당 코드를 다른 코드로 옮기는 것도, 다시 리팩터링하지 않고는 온프레미스로 돌아가는 것도 어려울 것이다. 애플리케이션의 복잡성에 따라 다르겠지만, 상당한 시간은 물론 추가 위험도 감수해야 하는 일이 될 수 있다. 항상 누릴 수는 없는 클라우드 네이티브의 이점. 네이티브 서비스를 사용하면 어떤 방식이나 형태, 형식으로 이점을 얻을 수 있다. 하지만 언제나 그런 것은 아니다. 많은 IT 부서가 네이티브 API를 사용하지만, 운영기간 동안 이들 API 사용의 이점을 보지 못한다. 이들 API가 제공하는 이점이 무엇인지 이해하고, 일단 배치된 후에 이들 이점을 측정할 필요가 있다. 네이티브 기능의 변경. 클라우드 네이티브 API를 이용해 클라우드 서비스를 호출하도록 애플리케이션을 리팩터링하는 것은 충분히 어려운 일이다. 하지만 이들 서비스가 변한다면 더 어렵다. 비록 API 호출이 정적이...

API 클라우드네이티브 리팩터링 2018.05.28

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

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

Copyright © 2022 International Data Group. All rights reserved.