기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
Example Corp. Automotive에서의 사용 사례
백서의 이 섹션에서는 최적의 하이브리드 네트워크 설계를 결정하는 데 도움이 되는 고려 사항, 요구 사항 정의 질문 및 의사 결정 트리를 사용하는 방법을 보여줍니다. 요구 사항은 의사 결정 트리의 입력으로 사용되므로 요구 사항을 식별하고 파악하는 것이 중요합니다. 요구 사항을 미리 파악하면 추가 설계 반복을 피할 수 있습니다. 설계를 다시 검토해야 하는 경우 프로젝트를 완전히 중단하고 귀중한 리소스를 보류하는 것을 최소화할 수 있으며, 요구 사항을 미리 이해하면 이상적으로는 이러한 상황을 피할 수 있습니다.
Example Corp. Automotive는 이 섹션 전체에서 예시 고객으로 사용될 것입니다. 이 회사는 처음에 AWS에서 첫 번째 분석 프로젝트를 배포하려고 합니다. 이 분석 프로젝트는 회사에서 제조하는 자동차의 데이터와 회사 데이터 센터에 이미 존재하는 기타 데이터 세트를 분석하는 데 중점을 두고 있습니다. 처음에 이 회사의 아키텍처 그룹은 프로덕션 및 개발 환경을 호스팅하기 위해 AWS 계정 계정과 Amazon VPC, 그리고 몇 개의 서브넷이 필요할 것이라고 생각했습니다. 프로젝트 팀은 빨리 시작하고 싶어서 가능한 한 빨리 개발 환경 액세스를 요청했습니다. 이들은 지금부터 3개월 후에 프로덕션에 들어가는 것을 목표로 하고 있습니다.
Example Corp. Automotive는 또한 향후 6개월 동안 ERP 시스템, 가상 데스크톱 인프라(VDI) 및 기타 20개 애플리케이션을 온프레미스에서 AWS로 마이그레이션하는 등 여러 추가 프로젝트에 AWS를 사용할 계획입니다. 추가 프로젝트에 대한 일부 요구 사항은 아직 정의 중이지만 AWS 클라우드 사용량이 증가할 것이라는 점은 분명합니다.
아키텍처 팀은 이 백서에 설명된 접근 방식을 활용하기로 결정했습니다. 각 고려 사항 아래에 설명된 요구 사항 정의 질문을 사용하여 설계 결정을 내리는 데 필요한 정보를 수집했습니다.
이러한 요구 사항은 다음 표에 요약되어 있는 연결 유형과 관련된 요구 사항부터 시작합니다.
표 4 - Example Automotive Corp의 신뢰성 입력
| 연결 유형 선택 고려 사항 | 요구 사항 정의 질문 | 답변 |
|---|---|---|
| 배포 시간 | 배포에 필요한 일정은 어떻게 됩니까? 몇 시간, 며칠, 몇 주 또는 몇 달입니까? |
|
| 보안 | 보안 요구 사항 및 정책에 따라 인터넷을 통한 암호화된 연결을 사용하여 AWS에 연결하도록 허용합니까, 아니면 프라이빗 네트워크 연결 사용을 의무화합니까? |
|
| 프라이빗 네트워크 연결을 활용할 때 네트워크 계층이 전송 중 암호화를 제공해야 합니까? | 아니요. 애플리케이션 계층 암호화가 사용됩니다. | |
| SLA | 하이브리드 연결 SLA와 서비스 크레딧이 필요합니까? |
|
| 가동 시간 목표는 어떻게 됩니까? |
|
|
| 전체 하이브리드 네트워크가 가동 시간 목표를 준수하고 있습니까? |
|
|
| 성능 | 필요한 처리량은 얼마입니까? |
|
| 온프레미스 네트워크와 AWS 간의 허용 가능한 최대 지연 시간은 얼마입니까? |
|
|
| 허용 가능한 최대 네트워크 Jitter는 얼마입니까? |
|
|
| 비용 | 한 달에 얼마나 많은 데이터를 AWS로 전송하시겠습니까? |
|
| 한 달에 얼마나 많은 데이터를 AWS에서 전송하시겠습니까? |
|
|
| 이 연결은 영구적입니까? | 예 |
접수된 요구 사항에 따라 아키텍처 팀은 그림 9의 연결 유형 결정 트리를 따랐습니다. 이를 통해 아키텍처 팀은 개발, 테스트 및 프로덕션 환경의 연결 유형을 결정할 수 있었습니다. 프로덕션 환경의 경우 즉각적인 요구 사항과 향후 요구 사항을 고려했습니다. 개발 및 테스트를 위해 Example Corp. Automotive는 인터넷을 통해 사이트 간 VPN을 구축할 예정입니다. 프로덕션의 경우 서비스 공급자와 협력하여 기업 네트워크를 AWS Direct Connect에 연결할 예정입니다. Example Corp. Automotive는 처음에 Direct Connect 호스팅 연결 사용을 고려했지만, AWS가 제공한 SLA
연결 유형을 결정한 후 다음 단계는 연결 설계 선택에 영향을 미치는 요구 사항을 파악하는 것입니다. 이는 연결을 구성하는 방법, 비즈니스 및 기술 요구 사항을 지원하는 데 사용할 AWS 서비스 등과 같은 논리적 설계와 관련이 있습니다.
확장성 및 통신 모델 요구 사항을 파악하기 위해 아키텍처 팀은 이 백서의 관련 섹션에 있는 요구 사항 정의 질문을 사용했습니다. 이러한 두 고려 사항과 관련된 요구 사항은 다음 표에 요약되어 있습니다.
표 5 - 요구 사항 정의 질문
| 연결 설계 선택 고려 사항 | 요구 사항 정의 질문 | 답변 |
|---|---|---|
| 확장성 | 온프레미스 사이트에 연결해야 하는 VPC의 현재 또는 예상 수는 몇 개입니까? | 처음에는 2개였다가 6개월 만에 30개로 증가 |
| 이러한 VPC는 단일 AWS 리전 리전에 배포됩니까, 아니면 여러 리전에 배포됩니까? | 단일 리전 | |
| AWS에 연결해야 하는 온프레미스 사이트는 몇 개입니까? | 데이터 센터 2개 | |
| AWS에 연결해야 하는 고객 게이트웨이 디바이스는 사이트당 몇 개 있습니까? | 데이터 센터당 라우터 2개 | |
| AWS VPC에 광고될 것으로 예상되는 경로의 수와 AWS측에서 수신될 것으로 예상되는 경로의 수는 몇 개입니까? |
|
|
| 가까운 장래에 AWS 연결의 대역폭 증가를 고려할 계획이 있습니까? |
|
|
| 연결 디자인 모델 | (리전 내 및/또는 리전 간)VPC 간 통신을 활성화해야 하는 요구 사항이 있습니까? | 예, AWS 리전 내에 있음 |
| 온프레미스에서 직접 AWS 퍼블릭 엔드포인트 서비스에 액세스해야 합니까? | 예 | |
| 온프레미스에서 VPC 엔드포인트를 사용하여 AWS 서비스에 액세스해야 합니까? | 아니요 |
아키텍처 팀은 의견을 바탕으로 연결 설계 섹션의 의사 결정 트리를 따랐습니다. 향후 6개월 내에 VPC 수가 2개에서 30개로 증가할 것으로 예상한 후 아키텍처 팀은 연결 및 VPC 간 라우팅을 위한 종료 게이트웨이로 AWS Transit Gateway를 사용하기로 결정했습니다. 독립적인 AWS Transit Gateway는 개발 및 테스트와 AWS Direct Connect와의 프로덕션 연결에 사용되는 VPN 연결을 종료합니다. 분리된 AWS Transit Gateway를 사용하면 변경 관리가 단순해지고 개발 및 테스트 환경과 프로덕션 환경을 명확하게 구분할 수 있습니다. 프로덕션에는 AWS Transit Gateway 때문에 AWS Direct Connect 게이트웨이가 필요합니다. 퍼블릭 VIF는 AWS 퍼블릭 엔드포인트 서비스에 액세스하는 데 사용됩니다. 그림 14는 수집된 요구 사항을 기반으로 의사 결정 트리에서 선택되는 경로를 보여줍니다.
그림 14 - Example Corp. Automotive 연결 설계 의사 결정 트리
확장성 및 통신 모델 요구 사항을 충족하는 솔루션을 결정한 후 다음 단계는 신뢰성과 관련된 요구 사항을 파악하는 것입니다. 이는 필요한 가용성 및 복원력 수준과 관련이 있습니다.
신뢰성 요구 사항을 파악하기 위해 아키텍처 팀은 이 백서의 관련 섹션에 있는 요구 사항 정의 질문을 사용했습니다. 요구 사항은 다음 표에 요약되어 있습니다.
표 6 - 신뢰성 요구 사항 질문
| 연결 설계 선택 고려 사항 | 요구 사항 정의 질문 | 답변 |
|---|---|---|
| 신뢰성 | AWS에 대한 연결 장애가 발생할 경우 비즈니스에 미치는 영향은 어느 정도입니까? |
|
| 비즈니스 관점에서 AWS에 대한 연결 실패에 따른 비용이 매우 안정적인 연결 모델을 AWS에 배포하는 데 드는 비용보다 큽니까? |
|
접수된 의견을 바탕으로 아키텍처 팀은 이 백서에서 이전에 다룬 신뢰성 고려 사항 섹션의 의사 결정 트리를 따랐습니다. 아키텍처 팀은 프로덕션 연결의 가동 시간 목표인 99.99% 와 서비스 중단이 발생할 경우 비즈니스에 미치는 영향이 크다는 점을 고려한 후 2개의 Direct Connect 위치를 사용하고 각 온프레미스 데이터 센터에서 각 Direct Connect 위치로 연결되는 2개의 링크를 설치하기로 결정했습니다(총 4개 링크). 개발 및 테스트에 사용되는 VPN 연결에도 추가 이중화를 위해 두 개의 VPN 연결이 사용됩니다. 신뢰성 섹션에서 설명하는 경로 엔지니어링 기술을 사용하여 연결은 다음과 같이 구성됩니다.
-
개발 및 테스트를 위해 기본 데이터 센터로 향하는 2개의 터널을 통해 ECMP를 사용하여 트래픽을 로드 밸런싱할 예정입니다. 이를 통해 처리량을 높일 수 있습니다. 보조 데이터 센터로 연결되는 터널은 기본 터널에 장애가 발생할 경우를 대비해 사용될 예정입니다.
-
프로덕션의 경우 Direct Connect 위치 중 하나를 통한 온프레미스와 AWS 간의 지연 시간은 매우 유사합니다. 이 경우 기본 데이터 센터에 배포된 온프레미스 시스템의 경우 기본 데이터 센터로 가는 두 연결을 통해 AWS와 온프레미스 간의 트래픽을 로드 밸런싱하기로 결정했습니다. 마찬가지로 보조 데이터 센터에서 실행되는 온프레미스 시스템의 경우 보조 데이터 센터로 연결되는 두 연결 간에 트래픽이 로드 밸런싱됩니다. 연결이 실패하는 경우 BGP는 자동 장애 조치를 용이하게 합니다.
그림 15는 수집된 요구 사항을 기반으로 의사 결정 트리에서 선택되는 경로를 보여줍니다.
그림 15 - Example Corp. Automotive 신뢰성 의사 결정 트리
