클라우드 마이그레이션에 대한 정리 (개방형 클라우드 플랫폼 테크 엣지 세미나)
IT / DX 에 대해서 공부하는 것을
블로그에 기록해 볼려고 한다 . ㅎ .. ㅎ
내가 정리한게 틀린거라면
이 블로그를 보는 누군가가 알려주기도 하고,
내 글이
남들에게 도움이 될 수도 있을거란 생각이 급 들어서다
23.12.28 (목)
온오프믹스 닷컴에서 신청했던 클라우드 관련된 세미나를 오늘 들었다.
(아래 사진 참고)
강의 시간은 총 22분정도 걸렸고,
상세하게 알려주기보다는 이런 방법이 있다~ 정도만 알려줘서
나에겐 좀 어려운 세미나였다
강의에서 배운 것 보다
강의 PPT를 기반으로
인터넷 서칭하며 마이그레이션 방법과 도커 컨테이너 기술에 대해서 알게된게 더 크다
세미나 내용 :
K-PaaS 어플리케이션 플랫폼에 배포된
사용자 앱을 컨테이너 플랫폼으로 마이그레이션하는 방법
운영자 측면에서 마이그레이션 하는 방법 (2가지)
개발자 측면에서 마이그레이션 하는 방법 (3가지)
세미나 내용 정리가 아니라,
세미나를 듣고
추가로 공부하며 알게된 거를 정리한 글입니당
( 저는,, 클라우드 전문가가 아니라
배워가는 사람이라서 틀린 내용이 있을 수 있으니
틀린 부분은 언제든지 편하게 알려주세오)
클라우드 마이그레이션 유형
마이그레이션 = 전환
클라우드 마이그레이션하면
온프레미스에서 클라우드로 전환하는 것만 해당되는 줄 알았는데,
이 뿐만 아니라
A 클라우드 플랫폼 → B 클라우드 플랫폼
데이터센터 (프라이빗 클라우드) → 퍼블릿 클라우드 or 하이브리드 클라우드
앱 → 클라우드 네이티브 앱
오프라인 네트워크 장비, DB 등 → 클라우드
등등등등등
다양한 유형이 있다.
각각의 유형에 따라 다른 마이그레이션 방법이 있겠지만,
오늘 들은 세미나에서는
개방형 클라우드 플랫폼(K-PaaS) 애플리케이션 플랫폼 → 컨테이너 플랫폼
으로 전환하는 방법에 대해서 배웠다.
클라우드 마이그레이션 이점
마이그레이션을 왜 해야하는가?를 생각했을때,
그 답은
클라우드가 가지는 이점과 동일하다
비용 절감, 스케일 인아웃 용이 등등~
클라우드 마이그레이션 방법/전략
내가 정리한 것보다 더 많지만,
중요한것만 써봄
1. 리호스팅 Rehosting (Lift and Shift)
기존의 온프레미스에 있는 코드를 수정 없이
클라우드 환경에서 복붙해 사용
(장점) 빠르게 마이그레이션 가능
(단점) 클라우드 네이티브화가 되지 않아, 클라우드의 이점을 활용하는데 한계가 있음
2. 리팩토링 / 리아키텍팅 (Refactoring or Rearchitecting)
클라우드 맞춤을 위해 기존 코드의 대부분(일부~전체)을 바꾸는 방법
(클라우드 네이티브화)
클라우드 중심 기능을 최대한 활용하도록 앱을 재설계함
기업에서는 애플리케이션의 기존 환경에서는 실현하기 어려운 기능을 추가하거나, 확장하거나, 성능을 향상해야 할 때 이 접근 방식을 선택하는 경우가 많음
모놀리식 아키텍처를 마이크로 서비스 아키텍처(MSA)로 분해하거나,
기존 모듈을 완전관리형 클라우드 서비스로 대체할 수 있음
3. 리플래포밍 Replatforming
코드 살짝 수정해서 클라우드로 올리는 것
리호스팅(수정X)과 리팩터링(ALL 수정)의 중간 접근 방식입니다.
클라우드 기능을 활용하기 위해 앱 일부만 최적화해서 리팩터링만큼 광범위하지는 않음
고급 기능을 제공하는 클라우드 기반 서비스로 특정 구성 요소를 이전
4. 재구매
기존 SW 버리고, 클라우드 기반 제품으로 이전
일반적으로 애플리케이션의 기존 소프트웨어 라이선스를 포기하거나 교체
클라우드 중심 애플리케이션을 구매하고 기존 애플리케이션을 사용 중지하기로 결정하는 것
ex) 데이터 센터의 기존 가상 데스크톱 인프라(VDI)에서 완전관리형 클라우드 기반 VDI로 이전
5. 유지 Retain
온프레미스 형태로 쓰던 그대로 냅두는 것
특정 애플리케이션 또는 서비스를 현재 환경에서 유지하면서
클라우드를 다른 용도로 사용하는 것을 의미함
쿠버네티스 기반 마이그레이션
클라우드 네이티브
쿠버네티스 기반의 어플리케이션 배포 과정이다
이걸 보고,
왜 코드를 이미지로 빌드를 하는거지?
이미지 저장소는 뭐고 ,,?
이미지랑 어플리케이션 배포 관계는 뭐지 ?
CI / CD는 뭐지 ?
라는 생각을 하면서, 찾아보니
쿠버네티스에 대해서 더 알게된 것 같다.
Docker 이미지???
도커 이미지는 일반적인 사진, 그림이 아니라
앱과 그 실행환경을 포함하는 가상화된 패키지이다.
도커 이미지는 쿠버네티스 클러스터 내에서 컨테이너로 실행됨
2. 프로그램 소스 코드를 이미지로 패키징 ??
도커 컨테이너화 할려면은 소스를 이미지로 만들어서 저장해야 함 (패키징)
이미지로 빌드하는게 앱을 도커 컨테이너로 실행할 수 있도록 하는 과정이다
프로그램 소스 + 런타임 + 파일시스템 + 시스템 도구 + 라이브러리 등
앱이 실행하기 위한 모든 것을 한 세트로 묶어 두는것
도커는 이런 특징을 가지고 있어서,시스템과 독립된 환경에서 실행 가능함
따라서, 아래의 말이 성립함
(= 앱 환경과 종속성을 컨테이너 이미지에 캡슐화)
(= 도커 이미지로 패키징하면, 도커의 가상화 기술을 통해 환경의 일관성을 유지하고,
애플리케이션을 여러 환경에서 무리없이 실행할 수 있게 됩니다.)
(= 이 이미지를 사용하여 CI/CD 파이프라인에서 애플리케이션을 테스트하고 배포하는데 활용할 수 있습니다.)
3. 도커 이미지는 어떤 과정을 거쳐 만들어지고 배포되는가 ?
도커 파일 작성 (dockerfile)
dockerfile은 파일 루트 디렉토리에 위치 (최상위란 뜻)
도커 이미지를 빌드할 때 필요한 명령어와 설정이 포함
2. 도커 이미지 빌드
(첫번째, 도커 파일작성 과정인) dockerfile에 빌드를 위해 필요한 코드를 주루룩 쓰고
docker build 명령어를 사용하여 이미지를 빌드하면
도커 이미지가 생성 ~
(= dockerfile 을 기반으로 도커 이미지를 빌드함)
3. 도커 이미지 저장소(레지스트리) 등록
이미지를 저장하고, 관리, 배포하는 중앙 관리사무소 느낌스
4. 도커 이미지 배포
Kubernetes 클러스터, 도커 스웜, 또는 다른 컨테이너 오케스트레이션 툴을 사용하여
배포 가능
4. 클라우드 기반의 CI / CD 파이프라인 ??
SW개발 프로세스를 자동화하고 지속적으로 통합과 배포를 수행하는 방법
CI (Continuous Integration - 지속적 통합)
CI는 개발자가 작성한 프로그램 코드를 합치고 빌드한 뒤,
자동으로 (코드 측면에서) 테스트를 실행함
for 여러 개발자가 작성하더라도 충돌 방지
"코드"에 초점이 맞춰져서, 코드가 충돌 없이 잘 업뎃됐는지, 잘 돌아가는지 테스트
CD
CD는 CI를 거쳐 넘어온 SW 코드를 (앱 측면에서) 테스트하고 배포함
앱 전체를 테스트하고 "배포"하는것에 초점
CD는 2종류가 있다. (Continuous Delivery, Continuous Deployment )
조직, 서비스의 성격에 맞춰서 택1해서 활용됨
1. Continuous Delivery 지속적 전달
수동으로 프로덕션 배포 결정이 이루어지지만,
앱 측면에서 성능, 작동, 보안성 등을 테스트하고 스테이징 환경으로 자동 전달.
프로덕션 환경까지 자동으로 배포하지는 않음
신중하게 배포할때 사용
2. Continuous Deployment 지속적 배포
자동으로 프로덕션까지 배포됩니다.
테스트, 스테이징 환경으로 전달, 실제 사용자가 사용하는 프로덕션 환경까지 자동으로 배포
신속하게 릴리스를 해야하는 조직, 서비스에 사용
쓰다보니까 너무 길어져서
포스팅 2개를 쓸려고한다
이글은 클라우드 마이그레이션 세미나를 듣고
찾아보면서 알게된 마이그레이션과 쿠버네티스에 관해 정리했고,
다음글은 개방형 클라우드 플랫폼 테크 엣지 세미나에서
강의하신
사용자 앱을 컨테이너 플랫포믕로 전환하는 방법에 대해 정리하겠음
댓글
댓글 쓰기