안녕하세요. 오늘은 베스핀글로벌 D&A실 노현식님이 작성해 주신 클라우드 아키텍처 설계 원칙 및 설계 기준에 대해 알아보겠습니다. 궁금하신 부분이 있으시면 댓글을 달아주세요:)
1. 아키텍처 설계 개요
클라우드 도입 시 아키텍처 설계 원칙 및 설계 기준에 따라 클라우드 환경 구축을 위해 필요한 아키텍처 요소들을 정의함
2. 아키텍처 설계 원칙
클라우드는 IT 자원의 신속한 탄력성을 확보하고 서비스의 연속성 및 비용 최적화를 지원하는 아키텍처 설계를 제공해야 함
2-1. 아키텍처 설계 원칙
클라우드 환경은 보안적으로 안전해야 하며 사용 가능한 스토리지 옵션 및 수평 확장이 용이한 아키텍처 구조를 활용하여 구성되어야 함
3. 아키텍처 설계 기준 > 개요 (1/2)
클라우드 아키텍처 설계 시 총 8개 영역에 대한 기준을 정의하였으며 이를 바탕으로 아키텍처 설계를 하여 환경을 구축해야 함
3-1. 아키텍처 설계 기준 > 개요 (2/2)
클라우드 아키텍처 설계 시 총 8개 영역에 대한 기준을 정의하였으며 이를 바탕으로 아키텍처 설계를 하여 환경을 구축해야 함
3-2. 아키텍처 설계 기준 > 3.1 클라우드 컴퓨팅 (1/2)
클라우드에서 컴퓨팅 파워의 규모를 간단하게 변경 할 수 있는 웹 서비스 정책을 이용하여 클라우드 컴퓨팅 설계 시 각 단계별 기준을 정의함
3-3. 아키텍처 설계 기준 > 3.1 클라우드 컴퓨팅 (2/2)
클라우드에서 컴퓨팅 파워의 규모를 간단하게 변경 할 수 있는 웹 서비스 정책을 이용하여 클라우드 컴퓨팅 설계 시 각 단계별 기준을 정의함
3-4. 아키텍처 설계 기준 > 3.2 Naming (1/2)
클라우드 환경 내 Naming 정책은 각 단계별로 기준을 수립하여 운영/관리해야 함
3-5. 아키텍처 설계 기준 > 3.2 Naming (2/2)
클라우드 환경 내 Naming 정책은 각 단계별로 기준을 수립하여 운영/관리해야 함
[Backup] AWS 자원 Naming Rule 정책
AWSNaming 정책은 고객의 필수 코드를 포함하되 AWS 환경의 특성에 따른 자원타입 코드, AZ, 관리(VPC) 용도, 자원 상세 내용 등을 쉽게 파악할 수 있도록 항목을 추가하여 설계함
| • 각 요소의 구분 및 요소 내 세부 정보 사이는 “-”로 구분 • 자원타입 코드는 기존 AWS 자원 ID(Resource ID)와의 구분을 위해 대문자를 원칙으로 하며, 아래 지정된 코드를 사용 • 관리(VPC) 용도는 Server Naming Convention과 동일하게 설정 |
[Backup] AWS 자원 Naming 설계
AWSNaming 정책은 고객의 필수 코드를 포함하되 AWS 환경의 특성에 따른 자원타입 코드, AZ, 관리(VPC) 용도, 자원 상세 내용 등을 쉽게 파악할 수 있도록 항목을 추가하여 설계함
3-6. 아키텍처 설계 기준 > 3.3 Tagging (1/2)
클라우드 리소스에태그 지정 사용을 적용하여 리소스에 대한 액세스를 정밀하게 제어할 수 있으며 추적관리에 대한 정책은 아래와 같이 정의함
3-7. 아키텍처 설계 기준 > 3.3 Tagging (2/2)
클라우드 리소스에태그 지정 사용을 적용하여 리소스에 대한 액세스를 정밀하게 제어할 수 있으며 추적관리에 대한 정책은 아래와 같이 정의함
[Backup] 리소스 태깅 관리를 위한 표준 태그 정의
클라우드 환경 태그 카테고리와 태깅 전략을 고려하여 리소스 관리를 위해 허용하게 될 표준 태그를 아래와 같이 제공 가능해야 함
3-8. 아키텍처 설계 기준 > 3.4 클라우드 네트워크(VPC) (1/5)
클라우드 전용 네트워크 설계 시 총 5개 단계(설계, 생성, 관리, 운영, 삭제) 기준에 대해 정의함
3-9. 아키텍처 설계 기준 > 3.5 클라우드 네트워크(VPC) (2/5)
클라우드 전용 네트워크 설계 시 총 5개 단계(설계, 생성, 관리, 운영, 삭제) 기준에 대해 정의함
3-10. 아키텍처 설계 기준 > 3.5 클라우드 네트워크(VPC) (3/5)
클라우드 전용 네트워크 설계 시 총 5개 단계(설계, 생성, 관리, 운영, 삭제) 기준에 대해 정의함
3-11. 아키텍처 설계 기준 > 3.5 클라우드 네트워크(VPC) (4/5)
클라우드 전용 네트워크 설계 시 총 5개 단계(설계, 생성, 관리, 운영, 삭제) 기준에 대해 정의함
3-12. 아키텍처 설계 기준 > 3.5 클라우드 네트워크(VPC) (5/5)
클라우드 전용 네트워크 설계 시 총 5개 단계(설계, 생성, 관리, 운영, 삭제) 기준에 대해 정의함
[Backup] BGP & CIDR 설명 요약
3-13. 아키텍처 설계 기준 > 3.6 가상 사설망(VPN) (1/2)
가상 사설망 서비스는 온프레미스 네트워크와 클라우드 환경 네트워크 사이에 네트워크 트래픽을 보호하는 네트워크를 제공하며 각 단계별 기준을 아래와 같이 정의함
3-14. 아키텍처 설계 기준 > 3.6 가상 사설망(VPN) (2/2)
가상 사설망 서비스는 온프레미스 네트워크와 클라우드 환경 네트워크 사이에 네트워크 트래픽을 보호하는 네트워크를 제공하며 각 단계별 기준을 아래와 같이 정의함
3-15. 아키텍처 설계 기준 > 3.6 클라우드 연결(DX) (1/2)
클라우드 연계 전용선 서비스는 온프레미스 네트워크와 클라우드 환경 네트워크 사이에 네트워크 트래픽을 보호하는 네트워크를 제공하며 각 단계별 기준을 아래와 같이 정의함
3-16. 아키텍처 설계 기준 > 3.6 클라우드 연결(DX) (2/2)
클라우드 연계 전용선 서비스는 온프레미스 네트워크와 클라우드 환경 네트워크 사이에 네트워크 트래픽을 보호하는 네트워크를 제공하며 각 단계별 기준을 아래와 같이 정의함
[Backup] 국내 클라우드 전용회선 사업자 현황
[Backup] 클라우드 네트워크 도입 시 고려 사항
3-17. 아키텍처 설계 기준 > 3.7 백업 (1/2)
클라우드 환경 내 백업 정책은 각 단계별 아래와 같이 정의하며, 비용적 측면을 고려하여 백업이 필수적으로 필요한 업무에 한해 수행함
3-18. 아키텍처 설계 기준 > 3.7 백업 (2/2)
클라우드 환경 내 백업 정책은 각 단계별 아래와 같이 정의하며, 비용적 측면을 고려하여 백업이 필수적으로 필요한 업무에 한해 수행함
[Backup] 백업 및 복구 (1/4)
클라우드 시스템의 장애 발생 시 신속한 복구를 위하여 백업/복구 절차 및 방안을 수립하고 유사시에 데이터 복구 절차에 따라 긴급 복구를 수행함
[Backup] 백업 및 복구 (2/4)
백업/복구 절차 준비 시 인스턴스 백업에 대해서는 AWS에서 제공하는 아래와 같은 백업 및 복구 도구를 활용하여 수행하며, OS 시스템, DB 시스템, Disk Volume을 대상으로 함
[Backup] 백업 및 복구 (3/4)
사전 검토된 백업 정책에 의해 AWS에서 제공하는 백업 및 복구 도구를 활용하여 EC2 인스턴스에 적용하며 백업 주기 및 보관 기간을 고려하여 일관된 관리를 수행함
[Backup] 백업 및 복구 (4/4)
RDS에 대한 백업은 AWS에서 서비스로 제공되는 Snapshot 백업 및 Auto 백업 기능과 Point In Time 복구 기능을 사용하여 데이터를 보호함
3-19. 아키텍처 설계 기준 > 3.8 DR (1/2)
전통적인 DR 구축 설계는 신속한 복구를 위해 많은 자원 확보가 필요하며 높은 투자/유지보수 비용 발생이 불가피하였으나 클라우드를 이용할 경우 낮은 비용에 신속한 복구가 가능해짐
3-20. 아키텍처 설계 기준 > 3.8 DR (2/2)
기존상일동 IDC와 여의도 DR 센터 On-Premise 시스템에서 구현된 DR 구성과 다르게 클라우드에서는 가용 영역(Availability Zone)을기반으로 DR을 구성하게 되며 HA와 DR 구현이 동시 가능함
[Backup] K카드 구성 사례 – M업무 DR 이중화
서울 리전에서 제공하는 두개 가용영역(AZ)에 인프라를 분산 배치하여 센터 이중화(운영센터 및 DR센터)로 구성하고 실제 서비스용으로 사용하는 구성임
감사합니다 🙂
문의: info@bespinglobal.com | 대표번호: 02-1668-1280