oday Keys : Direct Connet, AWS, Dedicated, Hosted, Process, 절차, 회선, 개통, LOA, CFA, cloud, 클라우드



이번 포스팅은 Direct Connect를 구성하기 위한 절차에 대한 도표입니다.

보다 자세한 절차가 인터넷 상에서도 있고, 아래와 같은 절차도 AWS 세미나에서도 정리되서 공개되어 있지만, 

제 입맛에 맞춰서 살짝 조금 수정한 버전입니다. ^^;

Direct Connect를 구성하기 위한 전체적인 흐름을 보시는 데 도움이 되시길 바랍니다. 


※ 관련 포스팅 : AWS - Direct Connect : Part 2 [Hosted Connected] - Hosted Connection 구성 절차






Posted by 네떡지기

Today Keys : VPC, AWS, 아마존, Cloud, 클라우드, 서브넷, Subnet, 라우팅, Routing, NAT, Gateway, IGW


이번 포스팅은 예전 포스팅에서 마법사를 통해서 만들었던 VPC를 마법사를 통하지 않고

각 개별 항목 별로 생성해보는 실습 예제입니다. 

마법사를 통한 구성은 편리하지만, 직접 개별 항목으로 생성해 보는 작업을 통하면 실제 VPC의 구성이 어떻게 이뤄지는지

이해하는 데 많은 도움이 되리라 생각됩니다. 

관련 포스팅 : AWS - VPC : Part 3 [VPC 생성 및 테스트:마법사]


이번 포스팅에서 만들게 될 VPC 구성은 다음과 같습니다. 

하나의 VPC 내에 공인 서브넷과 사설 서브넷을 각각 1개씩 구성합니다.

VPC가 외부와 통신하기 위해서 Internet Gateway와 사설 서브넷이 외부와 통신하기 위한 NAT Gateway를

각각 만들고, 라우팅 테이블을 조정 합니다.

 

 

먼저 VPC를 생성합니다

VPC 생성 시에는 VPC에서 사용한 네트워크를 선언하는 데, 초기에 설정한 네트워크(CIDR)은

삭제나 변경이 불가하며, 초기 설정한 대역을 기준으로 추가 CIDR 설정도 영향을 받기 때문에 잘 설계하여 결정해야 합니다.

 

 

 

  생성된 VPC의 정보는 다음과 같이 확인 할 수 있습니다. 

 

  VPC가 만들어졌으며, 이제 VPC 내에서 사용할 서브넷을 생성합니다.

여기에서는 공인 서브넷과 사설 서브넷을 각각 1개씩 생성합니다. 서브넷에서도 네트워크 대역을 정해야 하는 데,

VPC 내의 서브넷의 네트워크 대역은 VPC의 네트워크 내에 포함되어야 합니다.  

 

  본 예제에서는 AZ는 1개로만 구성하였습니다. 

 

  생성된 서브넷 정보는 다음과 같이 확인 할 수 있습니다. 

 

  이제 외부와 통신하기 위한 Internet Gateway를 생성합니다.

 Internet Gateway를 생성 할 때는 별다른 정보없이 Name만 지정합니다. 

 

  생성된 Internet Gateway는 아직 어느 VPC에서 사용될지 결정된 상태가 아니기 때문에 상태 값이 detached 입니다.  

 

  이제 처음에 만들었던 VPC에서 사용하기 위해서 방금 만든 Internet Gateway를 VPC에 연결합니다. 

 

   VPC를 선택해서 Internet Gateway를 연결하고나면,

 

  Internet Gateway의 상태가 attached로 되고, 연결된 VPC의 정보가 뜹니다.  

 

 다음은 라우팅 테이블입니다. VPC 생성 시에 만들어진 라우팅 테이블에는 VPC의 네트워크(CIDR)이 Local로 되어 있으며,

추가적인 라우팅이 없습니다. (Local이기 때문에 VPC 내에서 설정한 서브넷 간에는 통신이 가능합니다.)

 

 

 인터넷을 나가기 위해서 라우팅 테이블의 Default Route(0.0.0.0/0)의 Target(Next Hop)을 앞에서 만들었던

Internet Gateway로 지정합니다.

 

다음은 Elastic IP를 생성합니다.

 

Elastic IP는 바로 할당 버튼을 누르면 별다른 정보 입력없이 다음과 같이 바로 할당이 됩니다.

 

Elastic IP를 만든 것은 사설 서브넷이 인터넷과 통신하기 위한 NAT Gateway를 만들기 위한 것이었습니다.

사설 서브넷이 인터넷과 통신하기 위해서 만들지만, NAT Gateway를 생성할 때 설정하는 서브넷은

사설 서브넷이 아니라, 공인 서브넷으로 설정하고, 방금 전에 할당받은 Elastic IP를 연결합니다.

 

 

실제  서브넷 정보를 보면 공인 서브넷으로 생성한 '~cefe1' 로 끝나는 ID임을 확인할 수 있습니다.

 

이제 사설 서브넷을 위한 라우팅 테이블을 추가로 만듭니다.

서브넷 별로 라우팅 테이블을 적용 할 수 있습니다.

 

라우팅 테이블 생성하고  라우팅 정보를 수정합니다.

사설 서브넷을 위한 라우팅 테이블이기 때문에 Default Route에 대한 Target(Next hop)을 NAT Gateway로 합니다.

 

이제 초기에 만든 사설 서브넷의 기본 라우팅 테이블을을 확인해서

 

 방금 전에 만든 사설 서브넷용 라우팅 테이블로 변경합니다.

서브넷에 대한 라우팅 테이블을 변경하면 해당 라우팅 테이블의 정보를 볼 수 있습니다.

 여기까지하면, VPC 마법사를 통해서 만든 VPC 구성을 직접 만드는 작업이 끝나게 됩니다.

이제 실제 EC2를 생성해서 여기서 만든 공인 서브넷과 사설 서브넷으로 할당해서 각각 외부와 통신이 되는지

사설 서브넷의 EC2의 경우 공인 IP 주소가 NAT Gateway에 할당된 Elastic IP로 보이는지 확인하면 됩니다.

 

앞서 얘기 했듯이 AWS에서 제공되는 VPC를 생성하는 마법사를 이용하면 좀 더 쉽고 빠르게

VPC를 구성 할 수 있지만, 직접 만드는 작업을 통해서 실제 VPC 구성에 대한 이해를 도울 수 있을 것 입니다.

 

그리고 이렇게 만들어진 VPC는 최소한의 통신을 위한 기본 구성이기 때문에 VPC 설계를 위한 다른 컴포넌트들은

추가로 적절하게 생성하여 연결해야 합니다.

 

Posted by 네떡지기

Today Keys : AWS, outposts, on-premise, hybrid, 하이브리드, 클라우드, 온프레미스, azure, stack, re.Invent

 


이번 주에 진행 중인, AWS re.Invent 2018에서

On-premise에서 사용 가능한 AWS 버전인 AWS Outposts에 대한 내용이 발표되었다고 합니다. (실제 출시는 내년 하반기 이후?)

개인적으로 기존의 Azure의 강점 중의 하나가 On-Premise에서 사용 가능한 Azure Stack을 통해서

사용자에게 Public 과 동일한 Cloud 환경을 제공하는 것이라고 생각했는 데,

AWS에서도 Outposts를 통해서 진행하게 되는 것 같습니다.

이번 포스팅에서는 AWS의 Outposts에 대해서 아주 간략히(?) 정리해 봅니다.


 

AWS Outposts

AWS를 Public Cloud로써의 환경이 아닌 on-premise로 제공하기 위한 서비스

▪ AWS 디지안한 하드웨어로 구축된 컴퓨팅/스토리지랙을 사용하여 On-premise에서 구축

▪ AWS 클라우드에서 사용되는 동일한 native AWS API를 사용 가능

▪ 기존 AWS의 환경을 그대로 사용 할 수 있는 AWS native variant와 AWS에서 제공되던 VMware variant 환경을 제공

▪ AWS Outposts에 대해서도 AWS에서 관리 및 지원을 하며, public AWS region와 마찬가지로 자동으로 관리하고 업데이트

    - 인프라에 대한 업데이트나 패치에 대한 부분 지원

 

AWS Outposts에서 사용 가능한 옵션

▪ AWS native variant

  - AWS native variant 를 사용하는 경우에는 AWS에서 사용하는 것과 동일한 API 및 Control Plane을 사용

  - 초기에는 EC2, EBS에 대해서 지원하며, 향후 RDS, ECS, EKS, SageMaker, EMR 서비스 등을 추가 예정

VMware variant

   - 기존의  AWS에서 제공하던 'VMware Cloud on AWS'를 On-Premise에서 구축. 서비스 제공. AWS

   - VMware 의 API 및 Control Plane 사용 가능.

 

AWS Outposts에서 제공되는 Type 및 사이즈와 서비스

▪ 현재 EC2와 스토리지에 대해서 선택 가능한 옵션

   - EC2 : C5, M5, R5

   - 스토리지 : EBS, Local instance storage Local disk

▪ 단일 Outposts 서버로 시작해서, quarter, half, full Outposts 랙으로 증설 가능.

▪ 다양한 컴퓨팅, 메모리, 스토리지 옵션을 선택할 수 있음은 물론이고 최신의 하드웨어로 손쉽게 업그레이드 할 수 있음.

 

 

정리하고.

 이번 주에 발표된 내용이기도 하고, 아직 많은 내용의 자료도 공개된 게 없어서 큰 내용은 없습니다.

 기존의 Micro Azure Stack에 이어서 AWS Outposts까지... 좀 더 안정적인 Hybrid Cloud를 위한 Public과 동일한 환경의

 On-premise Cloud 솔루션들이 시장을 얼마나 차지할런지는 모르겠습니다.

 다만, 이러한 솔루션과 방향성이 결국 운영 입장에서는 On-premise와 Public 환경에서의

 Cloud 선택지에서 중요 선별 포인트가 되지 않을까 싶습니다.

 

 

 

 

Posted by 네떡지기
Today Keys : Hybrid, Direct, Connect, Direct Connect, 전용회선, AWS, VPC, VPN, VGW, BGP, DX, 클라우드, Cloud, 하이브리드



이번 포스팅은 AWS와 On-premise와 연결하는 Direct Connect에 대한 첫 번째 포스팅입니다.

기존에 포스팅 중이던 VPC와 함께 포스팅 될 예정입니다. 

최초에 작성하고 내용을 일부 수정하느라 크리스마스 이브 밤에 정식 포스팅을 시작합니다. 

아마도 기본 내용의 포스팅이라서 추가적으로 나중에 업데이트 되지 않을까 싶습니다. 



AWS와 On-Premise의 연결

 ▪ AWS와 On-Premise 와의 연결을 위한 방법으로는 다음의 3가지 방법으로 나눌 수 있음

    1. 일반 인터넷망

    2. VPN

          - Software VPN으로 구성 혹은 전용 하드웨어 VPN으로 구성

    3. Direct Connect




Direct Connect

 ▪ AWS와 On-Premise 데이터센터 간의 전용회선을 통해서 연결하는 구성

 ▪ 일반 인터넷망이나 VPN망에 비해서 망 대비 안정적인 성능을 제공할 수 있으며, 보안적으로도 우수

 ▪ 1G/10G 혹은 LAG를 통한 최대 40G 구성도 가능. 1G 이하의 속도도 제공하지만, 구성 방식이 다름

      - 아래의 'Direct Connect 구분' 참조

  VPN의 경우 연동 시에 Static Routing과 Dynamic Routing으로 BGP를 함께 지원하지만,  Direct Connect는 BGP만 지원

      - 단, Sub 1G를 사용하는 Hosted Direct Connect는 APN Partner를 통해서 BGP 구성하고 사용자는 Static으로 구성 가능.

 ▪ MTU 1500 & 9001 지원

     * 2018년 10월 11일부터 점보프레임(MTU 9001) 지원

 ▪ 별도의 SLA(서비스 수준 계약)는 제공하지 않음


Direct Connect 연결 지점

 ▪ Direct Connect를 사용하기 위해서는 On-Premise와의 전용선을 연결하기 위한 DX Location이란 지점이 필요

 ▪ 전 세계 16개 리전 80여개의 접속 지점이 존재(2018년 기준 - AWS Summit 자료)

 ▪ On-Premise 데이터센터의 라우터에서 직접 DX Location 내에 있는 AWS Direct Connect 라우터에 연결 할 수도 있고,
    DX Location에 상면을 임대하여, 로컬 구간만 케이블을 구성할 수도 있음.

 ▪ 한국 리전에는 KINX(서울 가산), LG U+(경기 평촌)에 DX-Location이 존재



Direct Connect 구분

 ▪ Dedicated 방식

   - 사용자 단 장비와 직접 AWS Direct Router 장비가 연결

   - Direct Connect 연결을 위한 Virtual Interface를 사용자 측에서 직접 생성

   - AWS Direct Connect 연결을 위한 BGP 설정을 사용자 단 장비에 설정

   - 1G 혹은 10G 속도 지원

   - Connection을 생성하여 요청하면 실제 케이블이 연결된 정보를 승인받아서 할당받고, Cross Connection 연결을 요청



  Hosted 방식

   - 사용자 단 장비는 APN Partner 장비와 전용선을 연결

   - Direct Connect 연결을 위한 Virtual Interface은 APN Partner에게 요청한 후 할당 받음.

   - APN Partner는 APN Partner 계정에서 VIF를 만들어서 사용자 계정에 할당하고 사용자가 이를 수락하는 방식

   - AWS Direct Router와는 APN Partner 장비가 연결된 상태이기 때문에 별도의 Cross Connection 연결 과정이 없음. 

   - AWS Direct Connect 연결을 위한 BGP 설정을 사용자 단 장비에 설정을 하지만,
     APN Partner에 요청하여 BGP 연동은 APN Partner 장비에서 하고, 사용자와의 연결은 

   - 1G 이하의 속도 연결 필요 시에 사용


  

 

 

Direct Connect 연결을 위한 장비 요건

 ▪ Singlemode 광 연결

 ▪ 802.1Q 지원
     - VIF에서 VLAN ID를 사용하여 구분

 ▪ BGP 지원
     -
VPN을 통한 연결은 Static Route와 BGP를 모두 지원하지만, Direct Connect는 BGP만 지원

 ▪ RFC 3021(Using 31-Bit Prefixes on IPv4 Point-to-Point Links) 지원
     - Public VIF에서 AWS의 Public IP 주소를 이용할 때만 필요

  


Direct Connect 구성

 Direct Connect는 Virtual Interface(VIF)를 생성하여 VGW(VPC)와 연결(Private VIF)하거나, 해당 Region의 직접 연결(Public VIF)

 VIF가 연결되는 VGW는 Direct Connect를 갖고 있는 계정이 아닌 다른 계정에도 연결 가능

    - 즉, 계정을 분리하여 관리하더라도 하나의 Direct Connect 구성 가능.

    - 하나의 회사에서 공용의 전용선을 구성하고, 회사 내의 구분 단위 별(팀,그룹,본부 등)로 별도 계정으로 공용 전용선 사용 가능.



Private VIF & Public VIF

 ▪ Private VIF

   - Private VIF 생성 시에 해당 VIF를 연결 할 VGW(VPC)를 선택 

   - AWS 내의 생성한 VPC 내의 네트워크를 Direct Connect를 통해서 연결하는 경우에 사용



  

 ▪ Public VIF

    - AWS의 VPC 내에 존재하는 것이 아닌 S3, API Gateway와 같은 Public Service를 인터넷망이 아닌 Direct Connect 연결 시 사용

    - Public VIF를 연결하게 되면 해당 리전의 Public Service를 위한 공인 대역을 BGP를 통해서 On-Premise로 광고

    - On-Premise로 광고된 대역에 대해서는 Longest match Rule에 의해서 기존의 인터넷망이 아니 Direct Connect 경로로 통신

    - 만약 AWS 내의 전체 Public Service가 아니라 특정 서비스에 대해서만 Direct Connect로 통신하고자 할 때에는 

       특정 서비스에 대한 CIDR을 확인하여, 해당 대역을 제외하고는 Filtering을 통해서 라우팅 광고를 제한적으로 수신

         * 각 서비스별 CIDR은 AWS에서 확인 가능



Direct Connect 한도


Posted by 네떡지기
분류없음2016.01.14 13:12

Today Key : Cloud Native App, CNA, Microsoft, Service, MSA, Immutable Infrastructure

 

이번 포스팅은 Cloud Native App에 관한 포스팅입니다.

이 포스팅은 2번에 걸쳐서 나눠서 올려지며, 이번에는 간단한 발표용으로 만든 프레젠테이션 이미지를 포스팅하며

이번 주말 전까지는 일반 포스팅 형식으로 같은 내용을 포스팅 할 예정입니다.

본 자료는 슬라이스쉐어로도 업로드되어 있으니, 다운로드는 아래 링크에서 받으시면 됩니다.
( 슬라이드쉐어 : http://www.slideshare.net/ssuserc08d76/cloud-native-app )


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Posted by 네떡지기
분류없음2016.01.08 09:57

AWS 한국 리전

1 7(어제) AWS Cloud 세미나에서 AWS Seoul Region 정식 오픈 발표와  한국 Region 서비스를 시작.

   -  전세계 12번째, 아시아 태평양 지역의 5번째 리전

서울 리전은 2개의 Availability Zone(AZ)으로 구성

  - AZ 2곳이지만, 실제 국내 IDC 3(KT[목동], SKB[일산], 롯데정보통신+현대정보기술[용인]) 임차.

 

 

 

                                                                                  < AWS 전체 Region >

 

 

 

AWS 한국 리전 가용한 서비스 목록(1 7 오픈 기준)

 

 

 

 

AWS 한국 서비스 속도

한국 Region 경우 10ms 응답 속도 (EC2 기본 서버 테스트)

     - 일본 Region 경우 30~50ms 응답 속도

 

 

 

 

서비스 비용 (EC2)

한국 Region 경우에는 일본 Region 거의 비슷하거나 조금 낮은 수준의 비용.

      - 물론, 미국의 버지니아 동부 Region 비해서는 높은 수준. (미국 Region 중에서도 버지니아 Region이 가장 저렴)

       ※ ap-northeast-2 : 한국 Region

 

 

 

 

Etc..

AWS 한국 Region 아니라, 올해 MS Azure 한국(부산[LG CNS]) 상륙하게 되면 앞으로 국내 클라우드 시장은 치열해질 듯…

 

Posted by 네떡지기
분류없음2015.10.07 09:12

Microservice, 마이크로서비스, Cloud, MSA, Architectures, 아키텍처, Monolithic, 클라우드 :Today keys.

 

이번 포스팅은 마이크로 서비스에 대한 포스팅입니다.

'안' 개발자로서, 이런저런 자료를 찾아보며 정리해 보았습니다.

새로운 내용들을 보다보면, 역시나 IT 분야내에서는 이런 저런 다양하게 알아야 할 것들이 많다는 것을 느끼게 됩니다.

아마도 이번달까지는 관련 내용을 정리해서, 좀 더 포스팅을 하게되지 않을까 싶습니다. (혹은... 정리만.. 포스팅은 다음달?..)

 


 

 

마이크로 서비스 아키텍처(MSA : Micro Service Architectures)

 

 

 

 

 

마이크로 서비스 아키텍처란?

   독립적이고 단순한 개별 서비스들로 전체의 서비스를 구성

   단일 Application 나누어서 작은 서비스들의 조합으로 구성

   기존의 Monolithic Architecture 대비되는 개념

   2012년 ThoughtWorks James Lewis Java the Unix way라는 제목의 발표에서 언급.

     2014 3 James Lewis Martin Flowler Microservices 라는 타이틀로 패러다임을 정립한 기사 발표

 

마이크로 서비스 아키텍처의 배경

   Cloud 서비스 환경에서의 기존의 Monolithic Architectures 적용의 어려움

        - Monolithic Architectures에서는 코드의 크기가 크기 때문에 배포에 대한 부담

        - 서비스 변화의 속도에 따른 배포 주기가 짧아지는 것에 대한 부담

   갈수록 복잡해지는 비즈니스에 따른 거대한 서비스 생성

   OpenSource Internet 등으로 인해 짧아지는 기술 수명 주기

   서비스 연계성으로 인한 문제

       - 일부 서비스 부분에 변경 시에도 연계 시스템에 대한 Re-Build 필요

 

 

Micro Service Architectures vs Monolithic Architecture

 

 

 

 

마이크로 서비스 아키텍처 구성 방식

   마이크로 서비스 간에는 HTTP 기반 API 등을 통해서 통신.

 

 

 

   각 서비스는 개별 서비스로 동작하기 때문에 서로 다른 독립적인 언어로 개발 가능. (Polyglot Programming)

 

   서비스가 복잡할 경우에는 서비스 간의 연결을 직접 구성하게 경우에 복잡도가 증가하므로, 중간에 API 관리하는 서비스 오케스트레이션 계층으로서의 API Gateway를 구성 가능.

 

 

 

마이크로 서비스 아키텍처의 특징

   Decoupled : 서비스 간의 종속성 배제

   Well Defined Interface : 서비스 간의 통신을 위해서 정의된 API 필요

   Independent : 서비스 별로 독립적으로 개발 운영할 있음

   Conway's Law 적용 :  "Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure." / 결국 서비스의 구성 디자인은 서비스를 구현하는 조직의 모습에 기반한다.

 

 

 

 

마이크로 서비스 아키텍처의 장점/단점

     장점

         - 서비스에 대한 확장성이 좋고, 개발 배포 사이클 관리 용이

         - 서비스 파트에서 제공하는 서비스에 최적하는 방법/언어 사용 가능(Polyglot Programming)

         - 작은 서비스로 구성되기 때문에 서비스에 대한 민첩성 확보.

         - 컴포넌트와의 종속성이 배제되어 서비스 변경이 쉬움

        

    단점

         - 서비스 간의 연계성 다양한 기술 사용으로 인한 운영 테스트 복잡도 증가

         - 서비스 간의 외부 호출로 인한 성능 비용 증가(Latency)

         - 설계 시의 고려해야 사항이 많아짐

         - 서비스의 세분화됨에 따라, 서비스 간의 코디네이션(Chief Architect) 필요.

         - 배포와 운영에 자동화를 사용하지 않으면, 오히려 기존 방식보다 어려움(개별 서비스이기 때문에 수량이 많아짐)

 

 

마이크로서비스 설계시 고려사항들

    개별 서비스에 대한 기능 적합성 성능에 대한 효율성

    서비스 간의 호환성

    서비스에 대한 신뢰성 서비스 간의 통신 시의 보안

    개별 서비스에 대한 유지보수성 이식성

 

Posted by 네떡지기

티스토리 툴바