클라우드 네이티브와 클라우드 지원의 차이점
수많은 기업들이 기존 환경에 맞춰 시스템을 개발한 후 나중에 변화가 필요할 때 클라우드로 전환합니다.
클라우드 지원 시스템은 기존 환경에서도 실행되지만 이론적으로 클라우드에서도 실행될 수 있습니다. 잠시 동안이지만 클라우드 환경에서도 고객에게 서비스를 지원합니다.
하지만 이러한 시스템은 처음부터 클라우드를 고려해서 개발된 것이 아닙니다. 따라서 클라우드 네이티브 접근법을 토대로 개발된 시스템에 비해 더 쉽게 파괴될 수 있습니다. 또한 클라우드 네이티브 접근법을 통한 확장성과 신뢰성 및 안전성의 이점을 그대로 기대하기는 어렵습니다.
클라우드 네이티브 아키텍처의 장점과 단점
기존 시스템 아키텍처를 이용하면서 아무런 문제도 없다면 새로운 개발 방식을 익히는 것을 주저할 수도 있습니다. 위험을 감수할 만큼 이점이 크지 않은 경우도 있기 때문입니다. 하지만 클라우드 네이티브 아키텍처는 기존 프로젝트에서는 기대조차 할 수 없을 만큼 큰 이점을 제공할 때가 많습니다.
클라우드 네이티브 아키텍처의 이점은 다음과 같습니다.
- 낮은 비용. 표준 환경에서 구축할 경우 고객에게 서비스를 제공하려면 시스템이 항상 가동되어야 합니다. 하지만 클라우드를 선택하면 새로운 기능과 제품으로 관심을 돌릴 수 있습니다.
애널리스트들도 얘기하듯이 기존 시스템은 중단될 경우 고객과 불편한 관계를 피할 수 없습니다. 하지만 클라우드를 선택한다면 탄력성이 향상될 뿐만 아니라 시스템이 중단되는 것을 차단하여 비용을 절감하고 평판까지 높일 수 있습니다.
- 속도. 빠르게 움직이는 업무 환경에서는 항상 테스트하고, 변경하고, 개선해야 합니다. 그렇다고 모든 변화가 시스템 파괴로 이어진다면 견디기 쉽지 않습니다.
클라우드 환경을 구축하십시오. 그러면 지속적인 변화에 적합한 시스템을 만들 수 있습니다. 클라우드 환경에서는 보다 쉽게 애플리케이션을 개선하고 실행할 수 있습니다.
- 옵션. 클라우드 네이티브 설계는 플랫폼에 구애받지 않습니다. 지금 사용 중인 환경이 마음에 들지 않으면 처음부터 끝까지 다시 프로그래밍하지 않고도 환경을 쉽게 바꿀 수 있습니다.
클라우드 네이티브 아키텍처의 단점은 다음과 같습니다.
- 문제 해결. 기존 시스템 아키텍처에서는 선형적인 계획을 따르면 문제를 찾아낼 수 있습니다. 클라우드 네이티브 설계에서는 컨테이너가 서로 상호작용하면서 연결됩니다. 하지만 경로가 항상 명확하지는 않습니다. 문제의 원인이 다수의 컨테이너에 있는 경우도 있어서 문제를 규명하는 일이 쉽지 않을 수도 있습니다.
- 보안. 타사 클라우드 사업자를 이용하면 데이터와 액세스에 대한 제어까지 어쩔 수 없이 맡겨야 합니다. 하지만 이러한 사업자들은 데이터를 자신의 일처럼 관리하지 못하는 경우도 있습니다.
- 지식 격차. 클라우드 네이티브 방식의 개발은 새로운 언어를 학습하는 것과 다소 비슷합니다. 개념을 완벽하게 이해하고 접근 방식의 완성도를 높여야 합니다. 그렇지 않으면 작은 실수도 파국으로 이어질 수 있습니다.
모든 기업은 위의 장단점을 신중하게 고려하여 조직과 소비자 및 이해 관계자들에게 적합한 결정을 내려야 합니다. 또한 구축에 앞서 초기에 계획 논의를 거쳐 팀 전체가 클라우드 네이티브 접근법을 이해할 수 있게 해야 합니다.
클라우드 네이티브 인프라 아키텍처
클라우드 네이티브 환경에서는 작은 구성요소들이 모여 큰 시스템을 이루게 됩니다. 각 구성요소는 고유의 역할이 있으며, 모두 클라우드를 기반으로 실행됩니다. 하지만 전체 시스템을 처음부터 끝까지 구축할 필요 없이 각 요소를 개별적으로 구성해도 됩니다.
클라우드 네이티브 설계는 모두 이렇게 이루어집니다. 하지만 기업에게 가장 적합한 시스템을 설계할 때 몇 가지 사용할 수 있는 옵션이 있습니다. 가장 많이 사용되는 옵션은 다음과 같습니다.
- 기본. DNS가 로드 밸런서 2개 중 1개를 이용하고, 로드 밸런서는 애플리케이션과 연결됩니다. 마스터 데이터베이스와 슬레이브 데이터베이스에 중요한 데이터가 저장되고, 각 데이터베이스는 애플리케이션과 통신합니다. 전체 시스템 클라우드에 주기적으로 백업됩니다.
- 멀티 클라우드. DNS가 한 개의 애플리케이션 구성요소를 통해 다수의 클라우드 플랫폼과 연결됩니다. 그렇다고 실행할 때마다 시스템을 복제할 필요는 없습니다. 애플리케이션 구성요소가 두 플랫폼 환경에서 실행되며, 회사 건물 내 플랫폼으로 데이터가 반환됩니다.
- 하이브리드. DNS가 로드 밸런서 2개 중 1개와 연결되며, 로드 밸런서는 다시 애플리케이션과 통신합니다. 애플리케이션은 마스터 데이터베이스로 데이터를 푸시하는 반면 푸시된 데이터의 복제본이 다른 클라우드 또는 회사 건물에 있는 슬레이브 데이터베이스로 푸시됩니다. 또한 스냅샷 백업 기능으로 모든 것이 체계적으로 정리됩니다.
다이어그램과 차트를 사용해 완성된 아키텍처의 모습을 팀에게 설명하십시오. 또한 클라우드 애플리케이션은 쉽게 바꿀 수 있다는 점도 알고 있어야 합니다. 설계한 시스템이 기업에게 적합하지 않으면 폐기하고 처음부터 다시 설계하면 됩니다.
하지만 클라우드 환경에서는 마이크로서비스가 매우 중요합니다. 조금만 바뀌어도 다른 작업에 영향을 미치기 때문입니다. 마이크로서비스는 개별적으로 실행되지만 서로 연결되어 있어서 시스템이 가동되는 것입니다. 따라서 이러한 마이크로서비스가 없는 클라우드에서는 어떤 것도 개발하지 마십시오.
클라우드 네이티브 아키텍처의 원리
정보 아키텍트 중에는 자신이 직접 해봐야 가장 잘 배울 수 있다고 여기는 사람들이 있습니다. 이러한 사람들은 읽고 듣는 것보다는 코딩하고 데이터를 세밀하게 분석하는 것을 좋아합니다. 하지만 이러한 아키텍처의 원리에 대해 자세히 알고 있으면 전문가들이 시스템을 설계하면서 어떤 점을 고수하는지 알 수 있기 때문에 유용합니다.
클라우드 네이티브 아키텍처의 일반적인 원칙은 다음과 같습니다.
- 탄력성을 최우선으로 고려합니다. 이중화, 지역별 구축, 데이터 복제로 시스템을 항상 온라인 상태로 유지할 수 있습니다. 이러한 시스템에서는 장애가 발생하기 마련입니다. 따라서 아키텍트는 장애에 대비해야 합니다.
- 시스템이 여러 가지 요소로 구성됩니다. 아키텍트는 컨테이너를 사용해 애플리케이션을 작은 크기의 청크로 분할하며, 이렇게 분할된 청크가 모여 작업을 실행합니다.
- 자동화가 중요합니다. 클라우드를 고려해 설계하십시오. 그러면 온라인 툴을 사용해 워크로드와 컴퓨팅 부하를 줄일 수 있습니다. 클라우드를 구축할 때 자동화는 중요한 원칙입니다.
- 지연 시간도 역할이 있습니다. 사용자의 요청과 시스템의 응답 사이에서 미세하게 발생하는 지연 시간도 클라우드 네이티브 시스템의 일부입니다. 아키텍트는 이러한 지연 시간을 최소화할 방법을 알아내야 합니다.
- 백업을 통해 데이터를 보호합니다. 시스템이 병렬 방식으로 구축되기 때문에 클라우드 시스템이 마비되거나 그 외 다른 방식으로 중단되더라도 데이터가 손실되지 않습니다.
- 투명성은 시스템 설계의 일부입니다. 컨테이너는 마치 블랙박스와 같습니다. 하지만 모니터링을 통해 정상적으로 실행되고 있는지 확인할 수 있도록 컨테이너마다 일정 수준의 투명성을 확보하는 것이 중요합니다. 자동 업데이트가 가능한 것도 이러한 투명성 덕분입니다.
코딩 팀들은 클라우드 네이티브 아키텍처를 처리하는 방식과 관련하여 다양한 블로그와 매뉴얼을 작성합니다. 이러한 글을 읽어 보면 자신이 겪고 있는 문제를 다른 사람들은 어떻게 해결하는지 알 수 있습니다.
Okta가 도와드리겠습니다
세계 일류 테크놀로지 기업들이 클라우드 네이티브 아키텍처를 사용해 소프트웨어를 빠르고 안전하게 배포하고 있습니다. 빠르게 움직여서 고객의 피드백에 응답할 수 있는 능력은 중소기업과 대기업 모두에게 중요합니다.
하지만 일부 클라우드 벤더들은 이러한 아키텍처의 비전을 실현하지 못합니다. Okta는 고객의 요구사항을 가슴에 새기고 모범 사례에 부합하는 효과적인 시스템을 개발했습니다. 유용한 정보를 고객 여러분께 하루 빨리 알려드리고 싶습니다.
참고 자료
Cloud Native Computing Foundation Charter. (2018년 12월). The Linux Foundation.
Introduction to Cloud-Native Applications. (2020년 5월). Microsoft.
3 Reasons to Go Cloud-Native. (2018년 8월). The Wall Street Journal.
Cloud-Based vs. Cloud-Native Application Development: An Important Distinction. (2018년 9월). Digitalist Magazine.
5 Principles for Cloud-Native Architecture: What It Is and How to Master It. (June 2019). Google.
Cloud-Native Application Architecture. (2019년 2월). Medium.
How to Architect and Design Cloud-Native Applications. (2015년 12월). Gartner.
Cloud-Native Principles. IBM.
