#90DaysOfDevOps - Data & Application Mobility - Day 90

데이터 및 애플리케이션 이동성

90DaysOfDevOps 챌린지 90일 차! 이번 마지막 세션에서는 데이터와 애플리케이션의 이동성에 대해 다뤄보겠습니다. 특히 Kubernetes에 초점을 맞출 예정이지만, 플랫폼 간 및 플랫폼 전반의 요구사항은 계속 증가하는 요구사항이며 현장에서 볼 수 있는 것입니다.

"워크로드, 애플리케이션 및 데이터를 한 위치에서 다른 위치로 이동하고 싶다"는 사용 사례는 비용, 위험 또는 비즈니스에 더 나은 서비스를 제공하기 위한 것 등 여러 가지 이유가 있을 수 있습니다.

이 세션에서는 워크로드를 가지고 한 클러스터에서 다른 클러스터로 Kubernetes 워크로드를 이동하는 방법을 살펴보되, 이 과정에서 대상 위치에서 애플리케이션이 있는 방식을 변경할 것입니다.

여기에는 재해 복구에서 겪었던 많은 특징이 사용됩니다.

요구 사항

현재 Kubernetes 클러스터로는 수요를 감당할 수 없고 비용이 천정부지로 치솟고 있기 때문에 프로덕션 Kubernetes 클러스터를 다른 퍼블릭 클라우드에 위치한 재해 복구 위치로 이전하여 확장 기능을 제공하면서도 더 저렴한 요금으로 운영하고자 하는 비즈니스 결정이 내려졌습니다. 또한 대상 클라우드에서 사용할 수 있는 일부 기본 클라우드 서비스를 활용할 수도 있습니다.

현재 미션 크리티컬 애플리케이션(Pac-Man)에 데이터베이스(MongoDB)가 있고 느린 스토리지에서 실행되고 있는데, 더 빠른 새로운 스토리지 계층으로 옮기고 싶습니다.

현재 Pac-Man(NodeJS) 프론트엔드는 확장이 잘되지 않으며, 새로운 위치에서 사용 가능한 pod의 수를 늘리고 싶습니다.

IT팀에 문의하기

간략하게 설명했지만, 실제로는 이미 재해 복구 Kubernetes 클러스터에 임포트한 상태입니다.

가장 먼저 해야 할 일은 재해 복구 테스트를 위해 89일에 수행한 복원 작업을 제거하는 것입니다.

"standby" Minikube 클러스터에서 kubectl delete ns pacman을 사용하여 이 작업을 수행할 수 있습니다.

시작하려면 Kasten K10 대시보드로 이동하여 애플리케이션 카드를 선택합니다. 드롭다운에서 "Removed"을 선택합니다.

그러면 사용 가능한 복원 지점 목록이 표시됩니다. 여기에는 미션 크리티컬 데이터가 포함되어 있으므로 사용 가능한 지점을 선택합니다. (이 예에서는 복원 지점이 하나만 있습니다.)

재해 복구 프로세스를 작업할 때는 모든 것을 기본값으로 두었습니다. 그러나 애플리케이션을 변환해야 하는 재해 복구 프로세스가 있는 경우 이러한 추가 복원 옵션을 사용할 수 있습니다. 이 경우 스토리지와 복제본 수를 변경해야 합니다.

"Apply transforms to restored resources" 옵션을 선택합니다.

수행하려는 변환에 대한 두 가지 기본 제공 예제가 요구 사항에 필요한 것입니다.

첫 번째 요구 사항은 기본 클러스터에서는 csi-hostpath-sc라는 스토리지 클래스를 사용했지만, 새 클러스터에서는 standard를 사용하고자 하는 것이므로 여기서 변경을 수행할 수 있습니다.

이제 하단의 변형 만들기 버튼을 누르세요.

다음 요구 사항은 pacman 프론트엔드 배포를 "5"로 확장하는 것입니다.

이 과정을 잘 따라가셨다면 아래와 같이 두 가지 transform을 모두 보실 수 있을 것입니다.

이제 아래 이미지에서 아래 나열된 모든 아티팩트를 복원할 것임을 알 수 있으며, 원한다면 복원하려는 대상을 더 세분화할 수도 있습니다. "Restore" 버튼을 누릅니다.

다시 한번 작업을 확인하라는 메시지가 표시됩니다.

마지막으로 터미널로 돌아가서 클러스터를 살펴보면, 이제 pacman pod에 대해 5개의 pod가 있고 스토리지 클래스가 표준 대 csi-hostpath-sc로 설정된 것을 볼 수 있습니다.

변환을 통해 다양한 옵션을 얻을 수 있습니다. 마이그레이션뿐만 아니라 재해 복구, 테스트 및 개발 유형 시나리오 등에도 적용할 수 있습니다.

API 및 자동화

API를 활용하여 이러한 작업 중 일부를 자동화하는 기능에 대해서는 언급하지 않았지만, 이러한 옵션은 존재하며 UI 전체에 걸쳐 일부 이동 경로가 자동화 작업에 API를 활용할 수 있는 명령 집합을 제공합니다.

Kasten K10에서 주목해야 할 중요한 점은 배포 시 Kubernetes 클러스터 내부에 배포된 다음 Kubernetes API를 통해 호출할 수 있다는 것입니다.

이것으로 데이터 저장 및 보호에 관한 섹션을 마무리하겠습니다.

자료

Closing

이 챌린지를 마무리하면서, 정보가 항상 관련성이 있는지 확인하기 위해 계속해서 피드백을 요청하고 싶습니다.

또한 데브옵스 주제와 관련하여 미처 다루지 못했거나 더 깊이 파고들지 못한 많은 주제가 있다는 점에 감사드립니다.

이는 내년에 이 챌린지를 다시 시도하여 90일 분량의 콘텐츠와 워크스루를 다시 만들 수 있다는 것을 의미합니다.

다음은 무엇인가요?

우선, 잠시 글쓰기를 쉬면서 2022년 1월 1일에 이 챌린지를 시작해서 2022년 3월 31일 19시 50분(BST)에 마쳤습니다! 슬로건이었죠. 하지만 제가 오랫동안 말하고 말했듯이이 콘텐츠가 한 사람에게 도움이 된다면 항상 공개적으로 배울 가치가 있습니다!

앞으로 이 콘텐츠를 어디로 가져갈지에 대한 몇 가지 아이디어가 있는데, 이 콘텐츠가 깃허브 저장소 외에 다른 곳에서 활용될 수 있기를 바라며 전자책이나 실제 책으로도 제작하는 것을 검토해 볼 수 있기를 바랍니다.

그런 일이 일어나기 전에 각 게시물을 다시 살펴보고 모든 것이 문법적으로 올바른지 확인해야 한다는 것도 알고 있습니다. 마크다운을 인쇄물이나 전자책으로 만드는 방법에 대해 알고 계신 분이 있다면 피드백을 주시면 감사하겠습니다.

언제나 그렇듯이 이슈와 홍보를 계속 보내주시기 바랍니다.

Thanks! @MichaelCade1