mirror of
https://github.com/MichaelCade/90DaysOfDevOps.git
synced 2025-02-06 09:09:23 +07:00
128 lines
7.7 KiB
Markdown
128 lines
7.7 KiB
Markdown
---
|
|
title: '#90DaysOfDevOps - Data & Application Mobility - Day 90'
|
|
published: false
|
|
description: 90DaysOfDevOps - Data & Application Mobility
|
|
tags: 'devops, 90daysofdevops, learning'
|
|
cover_image: null
|
|
canonical_url: null
|
|
id: 1048748
|
|
---
|
|
|
|
## 데이터 및 애플리케이션 이동성
|
|
|
|
90DaysOfDevOps 챌린지 90일 차! 이번 마지막 세션에서는 데이터와 애플리케이션의 이동성에 대해 다뤄보겠습니다. 특히 Kubernetes에 초점을 맞출 예정이지만, 플랫폼 간 및 플랫폼 전반의 요구사항은 계속 증가하는 요구사항이며 현장에서 볼 수 있는 것입니다.
|
|
|
|
"워크로드, 애플리케이션 및 데이터를 한 위치에서 다른 위치로 이동하고 싶다"는 사용 사례는 비용, 위험 또는 비즈니스에 더 나은 서비스를 제공하기 위한 것 등 여러 가지 이유가 있을 수 있습니다.
|
|
|
|
이 세션에서는 워크로드를 가지고 한 클러스터에서 다른 클러스터로 Kubernetes 워크로드를 이동하는 방법을 살펴보되, 이 과정에서 대상 위치에서 애플리케이션이 있는 방식을 변경할 것입니다.
|
|
|
|
여기에는 [재해 복구](day89.md)에서 겪었던 많은 특징이 사용됩니다.
|
|
|
|
### **요구 사항**
|
|
|
|
현재 Kubernetes 클러스터로는 수요를 감당할 수 없고 비용이 천정부지로 치솟고 있기 때문에 프로덕션 Kubernetes 클러스터를 다른 퍼블릭 클라우드에 위치한 재해 복구 위치로 이전하여 확장 기능을 제공하면서도 더 저렴한 요금으로 운영하고자 하는 비즈니스 결정이 내려졌습니다. 또한 대상 클라우드에서 사용할 수 있는 일부 기본 클라우드 서비스를 활용할 수도 있습니다.
|
|
|
|
현재 미션 크리티컬 애플리케이션(Pac-Man)에 데이터베이스(MongoDB)가 있고 느린 스토리지에서 실행되고 있는데, 더 빠른 새로운 스토리지 계층으로 옮기고 싶습니다.
|
|
|
|
현재 Pac-Man(NodeJS) 프론트엔드는 확장이 잘되지 않으며, 새로운 위치에서 사용 가능한 pod의 수를 늘리고 싶습니다.
|
|
|
|
### IT팀에 문의하기
|
|
|
|
간략하게 설명했지만, 실제로는 이미 재해 복구 Kubernetes 클러스터에 임포트한 상태입니다.
|
|
|
|
가장 먼저 해야 할 일은 재해 복구 테스트를 위해 89일에 수행한 복원 작업을 제거하는 것입니다.
|
|
|
|
"standby" Minikube 클러스터에서 `kubectl delete ns pacman`을 사용하여 이 작업을 수행할 수 있습니다.
|
|
|
|
![](/2022/Days/Images/Day90_Data1.png)
|
|
|
|
시작하려면 Kasten K10 대시보드로 이동하여 애플리케이션 카드를 선택합니다. 드롭다운에서 "Removed"을 선택합니다.
|
|
|
|
![](/2022/Days/Images/Day90_Data2.png)
|
|
|
|
그러면 사용 가능한 복원 지점 목록이 표시됩니다. 여기에는 미션 크리티컬 데이터가 포함되어 있으므로 사용 가능한 지점을 선택합니다. (이 예에서는 복원 지점이 하나만 있습니다.)
|
|
|
|
![](/2022/Days/Images/Day90_Data3.png)
|
|
|
|
재해 복구 프로세스를 작업할 때는 모든 것을 기본값으로 두었습니다. 그러나 애플리케이션을 변환해야 하는 재해 복구 프로세스가 있는 경우 이러한 추가 복원 옵션을 사용할 수 있습니다. 이 경우 스토리지와 복제본 수를 변경해야 합니다.
|
|
|
|
![](/2022/Days/Images/Day90_Data4.png)
|
|
|
|
"Apply transforms to restored resources" 옵션을 선택합니다.
|
|
|
|
![](/2022/Days/Images/Day90_Data5.png)
|
|
|
|
수행하려는 변환에 대한 두 가지 기본 제공 예제가 요구 사항에 필요한 것입니다.
|
|
|
|
![](/2022/Days/Images/Day90_Data6.png)
|
|
|
|
첫 번째 요구 사항은 기본 클러스터에서는 `csi-hostpath-sc`라는 스토리지 클래스를 사용했지만, 새 클러스터에서는 `standard`를 사용하고자 하는 것이므로 여기서 변경을 수행할 수 있습니다.
|
|
|
|
![](/2022/Days/Images/Day90_Data7.png)
|
|
|
|
이제 하단의 변형 만들기 버튼을 누르세요.
|
|
|
|
![](/2022/Days/Images/Day90_Data8.png)
|
|
|
|
다음 요구 사항은 pacman 프론트엔드 배포를 "5"로 확장하는 것입니다.
|
|
|
|
![](/2022/Days/Images/Day90_Data9.png)
|
|
|
|
이 과정을 잘 따라가셨다면 아래와 같이 두 가지 transform을 모두 보실 수 있을 것입니다.
|
|
|
|
![](/2022/Days/Images/Day90_Data10.png)
|
|
|
|
이제 아래 이미지에서 아래 나열된 모든 아티팩트를 복원할 것임을 알 수 있으며, 원한다면 복원하려는 대상을 더 세분화할 수도 있습니다. "Restore" 버튼을 누릅니다.
|
|
|
|
![](/2022/Days/Images/Day90_Data11.png)
|
|
|
|
다시 한번 작업을 확인하라는 메시지가 표시됩니다.
|
|
|
|
![](/2022/Days/Images/Day90_Data12.png)
|
|
|
|
마지막으로 터미널로 돌아가서 클러스터를 살펴보면, 이제 pacman pod에 대해 5개의 pod가 있고 스토리지 클래스가 표준 대 csi-hostpath-sc로 설정된 것을 볼 수 있습니다.
|
|
|
|
![](/2022/Days/Images/Day90_Data13.png)
|
|
|
|
변환을 통해 다양한 옵션을 얻을 수 있습니다. 마이그레이션뿐만 아니라 재해 복구, 테스트 및 개발 유형 시나리오 등에도 적용할 수 있습니다.
|
|
|
|
### API 및 자동화
|
|
|
|
API를 활용하여 이러한 작업 중 일부를 자동화하는 기능에 대해서는 언급하지 않았지만, 이러한 옵션은 존재하며 UI 전체에 걸쳐 일부 이동 경로가 자동화 작업에 API를 활용할 수 있는 명령 집합을 제공합니다.
|
|
|
|
Kasten K10에서 주목해야 할 중요한 점은 배포 시 Kubernetes 클러스터 내부에 배포된 다음 Kubernetes API를 통해 호출할 수 있다는 것입니다.
|
|
|
|
이것으로 데이터 저장 및 보호에 관한 섹션을 마무리하겠습니다.
|
|
|
|
## 자료
|
|
|
|
- [쿠버네티스 백업과 복원이 쉬워졌다!](https://www.youtube.com/watch?v=01qcYSck1c4&t=217s)
|
|
- [Kubernetes 백업, 업그레이드, 마이그레이션 - Velero와 함께](https://www.youtube.com/watch?v=zybLTQER0yY)
|
|
- [7가지 데이터베이스 패러다임](https://www.youtube.com/watch?v=W2Z7fbCLSTw&t=520s)
|
|
- [재해 복구와 백업: 차이점은 무엇인가요?](https://www.youtube.com/watch?v=07EHsPuKXc0)
|
|
- [Veeam 이동성 및 클라우드 이동성](https://www.youtube.com/watch?v=hDBlTdzE6Us&t=3s)
|
|
|
|
### **Closing**
|
|
|
|
이 챌린지를 마무리하면서, 정보가 항상 관련성이 있는지 확인하기 위해 계속해서 피드백을 요청하고 싶습니다.
|
|
|
|
또한 데브옵스 주제와 관련하여 미처 다루지 못했거나 더 깊이 파고들지 못한 많은 주제가 있다는 점에 감사드립니다.
|
|
|
|
이는 내년에 이 챌린지를 다시 시도하여 90일 분량의 콘텐츠와 워크스루를 다시 만들 수 있다는 것을 의미합니다.
|
|
|
|
### 다음은 무엇인가요?
|
|
|
|
우선, 잠시 글쓰기를 쉬면서 2022년 1월 1일에 이 챌린지를 시작해서 2022년 3월 31일 19시 50분(BST)에 마쳤습니다! 슬로건이었죠. 하지만 제가 오랫동안 말하고 말했듯이이 콘텐츠가 한 사람에게 도움이 된다면 항상 공개적으로 배울 가치가 있습니다!
|
|
|
|
앞으로 이 콘텐츠를 어디로 가져갈지에 대한 몇 가지 아이디어가 있는데, 이 콘텐츠가 깃허브 저장소 외에 다른 곳에서 활용될 수 있기를 바라며 전자책이나 실제 책으로도 제작하는 것을 검토해 볼 수 있기를 바랍니다.
|
|
|
|
그런 일이 일어나기 전에 각 게시물을 다시 살펴보고 모든 것이 문법적으로 올바른지 확인해야 한다는 것도 알고 있습니다. 마크다운을 인쇄물이나 전자책으로 만드는 방법에 대해 알고 계신 분이 있다면 피드백을 주시면 감사하겠습니다.
|
|
|
|
언제나 그렇듯이 이슈와 홍보를 계속 보내주시기 바랍니다.
|
|
|
|
Thanks!
|
|
@MichaelCade1
|
|
|
|
- [GitHub](https://github.com/MichaelCade)
|
|
- [Twitter](https://twitter.com/MichaelCade1)
|