'분류 전체보기'에 해당되는 글 161건

  1. 2021.07.12 베스트브리드 홀리스틱 캣다이어트 급여 후기
  2. 2021.02.22 첫 만남
  3. 2020.11.16 [AWS] Direct Connect
  4. 2020.06.05 Define a “Subtype”
  5. 2020.05.20 우린 늘 그렇듯 언제가 이별하겠지만...
  6. 2020.03.19 [Redshift] Amazon Redshift Cluster 설정 시 주의할 3가지
  7. 2020.01.23 Can a conceptual data model contain attributes?
  8. 2020.01.23 Amazon VPC(Virtual Private Cloud)생성하기
  9. 2018.11.17 묘연(猫緣) (1)
  10. 2017.11.19 Oracle sequence구현하기

베스트브리드 홀리스틱 캣다이어트 급여 후기

나의 동거묘(猫)이야기 2021. 7. 12. 00:40

저희 첫 째가(만3세) 요즘 식욕 폭발로 몸무게가 5kg을 넘어 다이어트 사료(오리젠 피트&트림)를 먹이고 있었습니다.

이 사료도 물론 아주 잘 먹습니다.

그러던 중 우연히 베스트브리드 홀리스틱 캣다이어트 체험단 모집 공고를 보게되었습니다.

바로 문제의 첫 째가 1살 무렵(중성화 이후) 베스트브리드 그레인프리켓다이어트를 먹였었는데,

처음에는 잘 먹다가 어느순간부터 깨작깨작 먹기시작하여

기호성 좋고 성분좋다던 로우즈로 바꾸고 쭉~먹이다. 체중관계로 오리젠피트&트림으로 먹이고 있는 중이었습니다.

결론

사료를 개봉하는 순간 주변에 와서 계속 관심을 보이다.

식기에 담아주니 숨도쉬지않고 먹었습니다.

한 보름정도 먹이고 있는데 지금도 역시 아주 잘 먹습니다.

이제 얼마 안남았는데 그냥 이 사료로 쭈~욱 먹이려 합니다.

좋은 기회주셔서 감사합니다.

 

Trackbacks 0 : Comments 0

Write a comment


첫 만남

나의 몰튼(Moulton)이야기 2021. 2. 22. 17:41

어느날 나의 오랜 친구가 한 자전거를 소개시켜줬다.

그 놈을 보자마자 운명처럼 빠져들어버렸고, 미친듯이 미니벨로 장터에서 몰튼을 찾게 되었다.

어느날 마음에 쏙 드는 녀석이 나타났고, 나를 몰튼에 세계로 인도한 그 놈과 대구까지가서 그 녀석을 맞이하러 갔다.

이게 그 녀석과의 첫 만남이었다.

 

'나의 몰튼(Moulton)이야기' 카테고리의 다른 글

첫 만남  (0) 2021.02.22
Trackbacks 0 : Comments 0

Write a comment


[AWS] Direct Connect

Cloud Computing/AWS 2020. 11. 16. 17:30

What is AWS Direct Connect?

AWS Direct Connect는 고객의 On-premise에서 AWS로 전용 네트워크 연결을 쉽게 구축할 수 있는 클라우드 서비스 솔루션입니다. AWS Direct Connect를 사용하면 AWS와 데이터 센터, 사무실 또는 코로케이션 환경 간에 사설 연결을 설정할 수 있으며, 이를 통해 대부분 네트워크 비용을 줄이고 대역폭 처리량을 높이며 인터넷 기반보다 일관된 네트워크 환경을 제공할 수 있습니다.
AWS Direct Connect를 사용하면 네트워크와 AWS Direct Connect 위치 중 하나 사이에 전용 네트워크 연결을 설정할 수 있습니다. 업계 표준 802.1q VLAN을 사용하여 이 전용 연결을 여러 가상 인터페이스로 분할할 수 있습니다.
이를 통해 퍼블릭 환경과 프라이빗 환경 간의 네트워크 분리를 유지하면서 퍼블릭 IP 주소 공간을 사용하는 Amazon Simple Storage Service (Amazon S3)의 저장된 객체와 같은 퍼블릭 리소스와 VPC ( Virtual Private Cloud )에서 프라이빗 IP공간을 사용하는 Amazon Elastic Compute Cloud (Amazon EC2) 인스턴스와 같은 프라이빗 리소스에 동일한 연결을 할 수 있습니다.
변화하는 요구를 충족시키기 위해 언제든지 가상 인터페이스를 재구성할 수 있습니다.



New Connectivity Model

NSX-T는 “Tier-0” 논리적 라우터 개념을 고객 연결 VPC와 같은 외부 네트워크, VPN 터널을 통한 다른 고객 VPC, 다른 쪽의 직접 연결 또는 인터넷을 통한 사내 네트워크와 같은 SDDC 컴퓨팅과 관리 네트워크 사이의 단일 연결 지점으로 사용합니다.
Tier-0 라우터는 또한 이전 NSX-V 모델에서 두 개의 별도 VM 대신 Tier-0 라우터에서 별도의 프로세스로 실행되므로 CGW와 MGW 간의 연결을 단순화합니다.

그림1 - AWS Direct Connect를 사용하여 VMware SDDC에 연결

AWS와 VMware의 공동 엔지니어링 작업을 통해 NSX-T에 대한 완벽한 Direct Connect 지원이 추가되었습니다. 이 기능을 사용하면 DX 공개 VIF 또는 인터넷을 통한 IPSec 터널 없이 SDDC와 연결된 경우 호스팅 된 Direct Connect Private VIF를 통한 고객의 온-프레미스 시설에 대한 SDC 논리 네트워크 및 관리 트래픽에 대한 기본 알림을 사용할 수 있습니다. 이 모델은 NSX-T와 NSX-V 기본 클러스터의 vMotion과 같은 사용 사례에 대한 연결 요구 사항을 크게 단순화합니다.

이 새로운 기능을 통해 고객은 호스팅 된 단일 프라이빗 VIF를 사용하여 SDDC에 연결할 수 있습니다. 이 프라이빗 호스팅 VIF를 사용하면 고객이 오버레이 네트워크의 워크로드 가상 머신과 호스트 관리 및 어플라이언스 네트워크와 통신할 수 있습니다.

Hosted Private VIF를 사용하면 계정 번호만 지정하여 다른 계정에서 VIF를 생성할 수 있습니다. 대상 계정은 계정에서 이 VIF를 수락해야 합니다.

이 경우 고객은 자신의 계정에서 Hosted Private VIF를 생성하고 VIF의 VMware Cloud on AWS 계정 번호를 입력할 수 있습니다. 이 계정 번호는 그림 2 와 같이 VMware Connect on AWS 콘솔의 Direct Connect> VMC AWS 계정에서 얻을 수 있습니다.

 

그림2 - VMware Direct on AWS Direct Connect 콘솔

Hosted VIF가 생성되면 고객은 VMware Cloud on AWS 콘솔에서 이를 수락할 수 있습니다. VMware SDDC는 이 VIF를 사용하여 모든 논리 네트워크를 광고하며 고객은 온 프레미스 네트워크를 SDDC에도 광고할 수 있습니다. 이를 통해 Direct Connect에서 1G 또는 10G 대역폭 연결을 활용하면서 고객을 위한 전체 연결 옵션을 단순화할 수 있습니다.

 

그림 3과 같이 콘솔의 알려진 BGP 경로 섹션에서 VMware Cloud SDDC에서 프레미스로 알려진 경로와 프레미스에서 받은 경로를 볼 수 있습니다. VMware Cloud SDDC에서 온-프레미스로 보급할 수 있는 최대 논리 네트워크 경로는 16개이며 평가 시 VMware에서 늘릴 수 있습니다.

그림3 -  AWS Direct Connect에서 보급 및 학습된 BGP 경로

이 기능은 현재 모든 VMware Cloud on AWS 리전에서 사용할 수 있습니다. 요금은 Direct Connect 연결의 계정 소유자가 시간당 연결 요금을 지불하고 VIF를 호스팅하는 계정이 데이터 송신 요금을 지불하는 AWS 요금 모델과 유사합니다.
이 경우 고객은 포트 요금을 지불하고 VMware는 송신 데이터 요금을 지불한 다음 고객에게 청구합니다. Direct Connect Gateway는 아직 VMware Cloud on AWS에서 지원되지 않습니다.



Conclusion

NSX-T 네트워킹으로 지원되는 새로운 VMware Cloud on AWS SDDC는 단일 Virtual Private Interface를 통해 인프라 (언더 레이) 및 오버레이 네트워크에 대한 완벽한 라우팅 지원을 제공합니다. 이 모델은 암호화가 필요하지 않은 경우 VPN 터널 없이 BGP 라우팅을 사용하여 SDDC와 온-프레미스 환경 간의 라우팅 요구 사항을 단순화합니다.
AWS Direct Connect는 1Gbps 및 10Gbps의 연결 속도를 제공합니다. AWS Direct Connect를 지원하는 APN 파트너는 50Mbps, 100Mbps, 200Mbps, 300Mbps, 400Mbps 및 500Mbps의 속도를 주문할 수 있습니다.
데이터 센터 확장, 재해 복구 또는 하이브리드 환경 구축을 위해 설계하는 고객은 AWS Direct Connect를 사용하여 VMware Cloud on AWS SDDC에 프라이빗 연결을 하실 수 있습니다.

 

 

원문 : aws.amazon.com/ko/blogs/apn/simplifying-network-connectivity-with-vmware-cloud-on-aws-and-aws-direct-connect/

Trackbacks 0 : Comments 0

Write a comment


Define a “Subtype”

DATABASE/Articles 2020. 6. 5. 16:54

항상 그러하듯이 'Subtyping'에 대해 일단 정의부터 내려보자.

 

Subtyping은 엔터티가 독립성을 유지한 상태로 엔터티 內 공통속성을 그룹화화는 과정이다.

위 정의에는 데이터모델링에 대한(특히 엔터티에 대한) 많은 개념이 들어가 있다.

위 정의를 바탕으로 Subtype/Subtyping에 대해 살펴보자.

 

엔터티의 독립성1)을 유지한 상태로 엔터티 내 공통속성을 그룹화하는 과정이라고 했는데,

공통속성 그룹화를 하는 이유는(즉, Subtype을 도출하는 이유는) 아래와 같다.

- 커뮤니케이션을 향상 시킬 수 있다.

- 모델단에서 강제적으로 비즈니스 룰을 적용하여 향후 데이터 정합성을 향상 시킬 수 있다.

 

간혹, 엔터티 통합/분할의 관점에서 Subtype을 얘기하는 경우가 있는데

맞는 얘기이긴 하지만 이게 전부는 아닌데, 아래와 같이 정의하여 Subtype을 결과론적 '행위의 결과'로만 이해(오해)할 수 있게 하는것은 바람직하지 않다고 생각한다.

굳이 이 얘기를 하는 이유는 최근 국내에서 가장 많이 팔린 모델링 책 중 하나에서 아래와 같이 정의했기 때문이다.

엔터티를 통합하거나 분리하는 행위의 결과가 서브타입입니다.

 

3가지 관점에서 Subtype을 정리해 보면...

 

1. Subtype 장단점

- 장점: Subtype을 도출하는 이유와 같다.

  . 커뮤니케이션을 향상 시킬 수 있다.

  . 모델단에서 강제적으로 비즈니스 룰을 적용하여 향후 데이터 정합성을 향상 시킬 수 있다.

- 단점: 무분별하게 Subtype을 도출할 경우

  . 모델을 복잡하게 하고,

  . 그에 따라 이해도가 떨어지고, ex) "왜 Subtype을 도출했지?"라는 불필요한 생각에 따른 에너지 소비 등..

  . 물리 모델 전환 시, 쓸데없는 고민을 하게한다. ex) 하나의 엔터티에 3가지의 경우의 수가 발생한다.

 

2. Subtype 도출시점

위에서 얘기한 두 장점이 필요한 시점이라고 생각한다.(물론 장점은 더 있을 수 있다)

즉, 개념모델링 단계일 수 도 있고, 논리모델링 단계일 수 도 있다.(주로 논리모델링 단계에서 도출된다)

하지만, 물리모델링 단계에서는 원칙적으로 도출할 수 없다. 이유는 Subtype은 RDB(Relational Database)에서 존재하지 않는 개념이기 때문이다.

 

3. Subtype 물리모델 전환 방법(가정: Subtype은 두 개)

방법1) Rolling down

Super type 엔터티를 제거하고, 모든 데이터 element 및 관계들을 Subtype엔터티로 이동 시킨다.(2개 Table)

 

방법2) Rolling up 

Subtype엔터티를 제거하고 모든 데이터 element 및 관계들을 Supertype 엔터티로 이동 시킨다.(1개 Table)

 

방법3) Identity: 

Supertype, Subtype 엔터티들을 모두 유지한다.(3개 Table)

 

 

 

1) 엔터티의 독립성은 너무 중요한 개념이다. 이 주제만으로 정말 많은 얘기를 할 수 있고, 그 만큼 중요하다.

하지만 그 주제에 대해 깊이 들어가지 않겠다. 알고있다는 전제하에 얘기하고자 한다.(궁금하신 분은 구글링하면 엄청 나오니 찾아보시길 바란다)

'DATABASE > Articles' 카테고리의 다른 글

Define a “Subtype”  (0) 2020.06.05
Can a conceptual data model contain attributes?  (0) 2020.01.23
Define a “Thing”  (0) 2016.02.13
Modifying Foreign Key Definitions  (0) 2014.04.21
Trackbacks 0 : Comments 0

Write a comment


우린 늘 그렇듯 언제가 이별하겠지만...

나의 동거묘(猫)이야기 2020. 5. 20. 18:51

https://post.naver.com/viewer/postView.nhn?volumeNo=28263000&memberNo=2060019

 

우린 늘 그렇듯 언젠가 이별하겠지만

[BY 아트인사이트] 노랗고 커다란 눈망울에 홀리면 헤어나올 수 없는 마성의 생명체. 먼 예로부터 불운과...

m.post.naver.com

 

마음 참 따듯해 지는 글이다...

Trackbacks 0 : Comments 0

Write a comment


[Redshift] Amazon Redshift Cluster 설정 시 주의할 3가지

Cloud Computing/AWS 2020. 3. 19. 16:58

1. Master user사용

2. 싱글 스키마

3. 기본 WLM Queue사용 

 

1. Master user사용

Redshift Cluster를 처음 생성할 때 반드시 Master user를 지정해야하지만,

이 user를 계속 사용하기 보다는 업무별로 사용자를 구분하여 관리하는것이 좋다. 예) ETL, BI, AD-HOC

이유는 사용자 별로 WLM설정 시 대기열을 지정함으로써 효율적인 Queue관리가 가능하기 때문이다.

 

2. 싱글 스키마

Redshift Cluster를 생성하면 자동으로 PUBLIC스키마가 생성된다.

기본으로 모든 사용자가 이 스키마에 대한 사용권한을 가지고 있으므로 사용을 피하고,

user group 및 user별로 스키마를 구성하여야 한다.

 

3. 기본 WLM Queue사용 

Redshift Cluster를 생성하면 기본으로 아래의 Queue가 생성된다.

  - default

  - superuser

queue에 대한 상세한 설명은 나중에 따로 하기로 하고 우선 간단하게 얘기해 보자면,

default queue는 5개의 쿼리를 동시에 실행할 수 있도록 5개의 슬롯이 할당되고, superuser queue는 하나의 슬롯이 할당된다.(콘솔에는 보이지 않음) superuser queue는 시스템 장애 등 정말 위급한 상황에 관리자만 사용가능한 queue이므로, 절대 일반적인 상황에서 사용하지 말아야한다. 아무생각없이 이 queue를 사용하다 정말 위급한 상황이 생길때 손을 쓰지 못하는 경우가 발생할 수 있다.

쿼리가 실행할 queue를 찾지 못할때 default queue를사용하게되는데 이 queue는 이를위해 그냥 두고,

업무별로 user group 및 user를 관리하는것 처럼 queue도 이를 바탕으로 컨커런시와 메모리를 설정하여 효율적인 구성이 가능하다.

 

 

Amazon Redshift Cluseter구성 시 주의해야할 3가지를 살펴보았다.

이 글을 읽고 너무 당연하다고 생각할 수 있으나, 생각보다 이 3가지를 모두 지키지 않는 사용자가 많다는게 현실이다.

Trackbacks 0 : Comments 0

Write a comment


Can a conceptual data model contain attributes?

DATABASE/Articles 2020. 1. 23. 18:11

이번에 소개할 내용은 

개념 데이터 모델(CDM, Conceptual Data Model)에 속성(Attribute) 도출을 해야하는가?

이다.

 

사실 필자는 개념 데이터 모델에 속성을 도출하는것을 지양하는 편이다.

이유는 개념 데이터 모델(이하 CDM)의 정의에서 찾을 수 있는데, 개념 데이터 모델의 정의를 먼저 살펴보도록 하자.

 

개념 데이터 모델(CDM, Conceptual Data Model) : 기호나 텍스트1)로 비즈니스의 개념을 잘 표현한 데이터 모델

즉, CDM으로 비즈니스의 개념을 잘 파악할 수 있어야 하는데, 속성이 도출되어 있을 경우 핵심인 '비즈니스의 개념'보다 해당 속성에 포커싱이 맞추어지는(또는 이슈가 되는) 경우가 생각보다 많이 발생한다는 것이다. 이와 같은 이유로 필자는 가급적 불필요한 논쟁(?)을 피하고자 CDM에서는 속성을 도출하지 않는 편이다. 여기에서 주의할 것은 일반적으로 이렇게 한다는 것이지 반드시 그렇다는 것은 아니다. 프로젝트 초기에 CDM을, 일반적으로 우리가 생각하는 CDM과 LDM2)사이로 정의한다면 CDM에 식별자 또는 후보식별자(Natural key, Business key 등)를 포함한 중요 속성도 함께 도출해야 한다. 이후 계속, 지겹게 얘기하겠지만, 데이터 모델링에 정확한 규칙이나 방법3)은 없다. 다양한 비즈니스 환경에 맞게 유연하게 진행해야한다. 그렇기 때문에 데이터 모델링이 어려운 것이다.  

 

원문

https://stevehoberman.com/can-a-cdm-contain-attributes/

 

1) 여기에서 '기호나 텍스트'는 데이터 모델링 표기법(Notation)을 말한다.

2) LDM(Logical Data Model)

3) 물론 정확한 규칙이나 방법은 없지만, 방법론, 기업 및 집단의 표준화된 규칙이나 방법은 존재한다.

'DATABASE > Articles' 카테고리의 다른 글

Define a “Subtype”  (0) 2020.06.05
Can a conceptual data model contain attributes?  (0) 2020.01.23
Define a “Thing”  (0) 2016.02.13
Modifying Foreign Key Definitions  (0) 2014.04.21
Trackbacks 0 : Comments 0

Write a comment


Amazon VPC(Virtual Private Cloud)생성하기

Cloud Computing/AWS 2020. 1. 23. 18:00

VPC는 Virtual Private Cloud의 약어로 아마존 클라우드 내에서 Private IP를 사용하는, 일종의 가상 Private network를 만들게 해주는 서비스이다. 아마존 웹사이트에서는 아래와 같이 설명한다.

 

Amazon Virtual Private Cloud(Amazon VPC)에서는 사용자가 정의한 가상 네트워크로 AWS 리소스를 시작할 수 있습니다. 이 가상 네트워크는 AWS의 확장 가능한 인프라를 사용한다는 이점과 함께 고객의 자체 데이터 센터에서 운영하는 기존 네트워크와 매우 유사합니다.

 

VPC 핵심 개념은 다음과 같다.

  • VPC는 사용자의 AWS계정 전용 가상 네트워크이다.
  • 서브넷(Subnet)은 VPC의 IP주소 범위이다.(=네트웍크 주소공간을 분할 = IP Group)
  • 라우팅테이블(Routing table)에는 네트워크 트래픽을 전달할 위치를 결정하는데 사용하는 라우팅이라는 규칙 집합이 포함되어 있다.
  • 인터넷 게이트웨이(Internet gateway)는 수평 확장되고 가용성이 높은 중복 VPC구성 요소로, VPC의 인스턴스와 인터넷과 통신할 수 있게 해주므로 네트워크 트래픽에 가용성 위험이나 대역폭 제약 조건이 발생하지 않는다.
  • VPC 엔드포인트(End point)를 통해 인터넷 게이트웨이, NAT디바이스, VPN연결 또는 AWS Direct Connect연결을 필요로 하지 않고 Private link 구동 지원AWS서비스 및 VPC 엔드포인트 서비스에 비공개로 연결할 수 있습니다. VPC인스턴스는 서비스 리소스와 통신하는데 퍼블릭 IP주소가 필요하지 않다. VPC와 기타 서비스 간 트래픽은 Amazon 네트워크를 벗어나지 않는다.

VPC

VPC는 아마존 콘솔에서 생성하고, VPC범위는, 하나의 VPC는 하나의 region내에서만 생성이 가능하다. 즉 VPC를 두 개 이상의 region에 걸쳐 사용이 불가능하다. 단 하나의 VPC는 여러개의 Amazon Availibilty Zone(이하 AZ)을 가질 수 있다. 또한 하나의 VPC가 가질 수 있는 IP주소의 range는 2^16=65535로 제한된다.

CIDR표현으로 10.0.0.0/16(10.0.0.0 ~ 10.0.255.255) 범위가 된다. CIDR에 대한 개념과 계산법은 아래 사이트에서 계산할 수 있다.

http://www.subnet-calculator.com/cidr.php

 

Subnet

VPC를 생성했으면 각각의 Subnet을 생성해야한다. Subnet의 범위를 다시 한번 살펴보면,

VPC는 앞서 설명한 것 처럼, 하나의 region내에서 여러개의 AZ에 걸쳐서 생성이 가능하다. VPC안에서는 여러개의 subnet을 생성할 수 있는데, 하나의 subnet은 VPC안에서 하나의 AZ에만 생성이 가능하다.

 

 

 

Route Table

각 Subnet에는 default로 subnet과 밖을 연결해주는 router가 생성되고, 이 router는 route table을 가지고 있다.

대상 IP Address에 routing경로를 정의하는 것으로 subnet에서 밖으로 나가는 outbound traffic에 대한 routing경로를 정의한다. 이 route table은 AWS콘솔에서 설정이 가능하고, routing경로는 target의 타입에 따라서 크게 3가지로 구분할 수 있다.

  • Local: VPC내의 다른 subnet으로 traffic을 routing한다.
  • Internet gateway: Internet gateway를 통해서 외부 인터넷으로 traffic을 routing한다.
  • Virtual  private gateway: 관리자가 임의로 정의한 destination으로 traffic을 routing한다. VPN연결을 위한 VPN gateway등이 그 예가 된다.

아래와 같이 설정해 놓으면 10.0.0.0 ~ 10.0.255.255는 VPC 내부로 routing되고, 이외의 모든 traffic은 igw-06eb1f727711c1d09(Internet gateway로 정의)라고 정의한 router로 routing된다.

 

모든 Subnet은 1개의 Routing table을 가져야 하며, 하나의 Routing table은 여러개의 subnet에 중복되서 적용될 수 있다.

 

Public subnet & Internet gateway

VPC내에 생성되는 EC2 Instance는 10.0.x.x와 같은 private IP이외에 Elastic IP(이하 EIP)를 통해서 일반 인터넷 주소인 Public IP까지 총 2개의 IP를 가질 수 있다.

Subnet 내의 EC2 Instance들이 직접 인터넷 EIP를 통해서 in/out bound connection이 연결 가능한 subnet을 public subnet이라고 정의 하는데, 이 in/out bound traffic은 internet gateway(이하 IGW)를 통해서 이루어지며, 콘솔 설정으로 만들 수 있고, 생성 후 VPC에 attach한 후, 사용하고자 하는 subnet의 routing table에 설정을 해주면 된다.

위 그림과 같이 subnet에서 인터넷으로, traffic은 EC2의 EIP를 통해서 router를 타고 router에 의해 정의된 routing경로를 따라 internet gateway를 거쳐서 인터넷에 연결된다.

 

Private subnet & NAT

Public subnet이 있으면 당연히 Private subnet도 있다. Private subnet은 EIP를 가지지 않고 private IP만 가지고 있으며, Internet으로 in/out bound연결이 불가능하며, 단지 다른 subnet으로만 연결이 가능하다.

보통 일반적인 회사에서 private network구성을 할 때 많이 사용하는 방법인데, private IP를 쓴다 하더라도 외부 시스템으로의 접속이 필요한 경우가 있다. 예를 들어 다른 서버와 connection을 하거나 patch를 읽어오는 것과 같은 outbound connection은 사용되는 경우가 많다. 일반 private network의 경우에는 outbound connection에 대해서 public IP를 binding하여 연결을 제공하는 방식으로 NAT(Network Address Translator)라는 장비를 사용하는데, Amazon에서도 마찬가지로 이러한 NAT를 이용해서 Private subnet 내의 instance가 Internet으로 나가는 outbound traffic이 지원될 수 있도록 한다.

NAT를 이용한다고 해서 특별한 기능을 Amazon이 제공하는 것이 아니고, Software기반의 NAT를 public subnet에 설치한 후에 private subnet에서 Internet으로 나가는 outbound traffic에 대한 routing경로를 이 NAT를 통하게 하는 것이다.

조금 사용을 편리하게 하기 위해서 Amazon에서는 AMI이미지 형태로 미리 NAT EC2이미지를 제공하고 있기 때문에, 별도의 선호 제품이 없을 경우에는 이 이미지를 사용하면 된다.

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html

보통 이 NAT를 사용할 경우, 전체 VPC에 대해서 한 두 개의 NAT만 사용하는 경우가 있는데, 애플리케이션이 private subnet에서 밖으로 나가는 outbound protocol이 많을 경우에 이 NAT자체가 병목 구간이 될 수 있기 때문에 NAT에 대한 traffic을 수시로 확인하고 알맞은 용량으로 운영을 해야 한다. 또한 Amazon 내부 서비스라 하더라도 Private IP가 아니고 Public IP를 사용하는 경우가 많고, 이 경우 private subnet에 있는 EC2인스턴스들은 NAT를 거치기 때문에 Amazon서비스에 대한 호출도 NAT를 사용함을 인지하고 NAT용량을 체크해야 한다. (예, S3는 public IP만 제공한다. 그래서 private subnet에서 S3로 traffic은 모두 NAT를 거치게 된다.)

 

VPN

VPN은 Virtual Private Network의 약자로 Public(인터넷)망을 통해서 회사의 Private network망에 연결하게 해주는 서비스이다. 예를 들어 회사가 10.0.1.xx 대역의 네트웍을 쓰고 있고, 내가 집에서 노트북으로 회사의 네트웍에 접속하고자 한다고 하자. 내 IP는 Public IP로 198.12.x.x를 사용한다고 하자. 회사 네트워크는 private망이기 때문에 접속이 불가능하다. 그래서 VPN gateway를 회사 네트워크와 내 PC에 설치해 놓으면 가상으로 내 PC를 회사 네트워크와 연결하여 같은 네트워크 대역으로 사용할 수 있게 해준다. 개인 PC와 회사 private 네트워크 뿐만 아니라, 물리적으로 분리되어 있는 지역간 사무실이나 네트워크까지 이 VPN 네트워크를 사용하면 하나의 private network으로 묶을 수 있다.

Amazon에서도 역시 VPN을 사용할 수 있는데, VPN을 사용하기 위해서는 VPN gateway를 설치해야 한다. 직접 소프트웨어 기반의 VPN을 설치할 수 도 있지만, Amazon에서 제공하는 VPN을 사용할 수 도 있다. VPN은 그 보안 및 암호화 방법에 따라 IPESC, IKE 등 여러가지 방법을 제공하는데, Amazon에서 제공하는 VPN의 경우에도 상당히 다양한 방법의 VPN프로토콜을 지원한다.(IPSEC, IKE, SHA-1방식의 Hashing, BGP peering 등) 자세한 내용은 아래 링크 참고.

http://docs.aws.amazon.com/AmazonVPC/latest/NetworkAdminGuide/Introduction.html

VPN을 통해서 VPC에서 할 수 있는 것은 region간 서로 다른 VPC를 같은 subnet으로 묶거나, 또는 회사 데이터 센터의 subnet을 VPN을 통해서 VPC와 같은 네트워크 대역으로 묶을 수 있다.

VPN을 구성할 때 고려해야 할 점은, VPC를 구성할 때 VPN을 통해서 다른 region이나 데이터 센터(회사)와 연결할 가능성이 있다면, subnet의 IP주소를 이에 맞게 구성해야 한다는 것이다. 만약에 vpc를 구성할 때 처음부터 10.0.0.0/16으로 Full range를 다 사용해 버리면 나중에 다른 데이터 센터와 VPC로 연결할 때 IP가 겹칠 수 있고, 이를 바꾸어야 하는 대 작업이 생길 수 있기 때문에 VPC디자인 시 먼저 subnet의 IP대역을 적절하게 분할하여 설계할 필요가 있다.

 

Security Group

Security Group은 VPC안에서 일종의 방화벽 처럼 사용된다. VPC가 아니더라도 Security group은 AWS에서 필수적으로 사용되는데, Security group은 inbound 또는 outbound traffic에 대해서 port별로 접근을 제어할 수 있는 기능을 제공한다. 마치 방화벽과 같은 기능을 하는 서비스라고 생각하면 된다. VPC안에서의 Security group의 차이점은 VPC를 사용하지 않는 경우 Security group에서는 inbound traffic에 대해서만 접근 제어가 가능한데, VPC내의 Security group의 경우에는 in/outbound traffic 모두에 대해서 접근 제어가 가능하다. 그 외에도 접근할 수 있는 Security group수나 지원하는 프로토콜의 종류가 차이가 있는데, 자세한 내용은 아래 링크를 참고하기 바란다.

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html#VPC_Security_Group_Differences

Security group을 이용하면, Hosting환경에서 사용하는 DMZ와 같은 개념을 구현할 수 있다. 아래 아키텍처는 Web, REST API, DBMS 세 가지 계층으로 이루어진 시스템이다.

Web layer는 public subnet으로 구성하고, 인터넷으로 부터 들어오는 모든 TCP 80(HTTP) traffic을 받도록 Security group을 구성한다. REST API를 제공하는 subnet은 Web server들이 위치한 subnet으로 부터 들어오는 TCP 8080 traffic만 받도록 하고, DB들이 위치한 subnet은 API server용 subnet에서 들어오는 DB연결용 3306포트만 받도록 한다. 이런식으로 네트워크를 구성하면 조금 더 높은 수준의 보안을 제공할 수 있다.

 

Bastion

VPC를 사용하면, private subnet의 경우에는 외부에서 telnet이나 SSH로 접근 할 수 있는 방법이 없다.(Public IP가 없기 때문에) 또한 Public subnet에 있는 EC2 instance의 경우에도 모든 인스턴스에 SSH연결을 열어 놓게 되면 보안상으로 문제가 발생할 수 있는 가능성이 있다. 그래서 Bastion이라는 개념을 사용하는데, 일종의 Telnet접속 콘솔이라고 생각하면 된다.

VPC내의 모든 Instance들은 이 Bastion으로부터 Telnet 또는 SSH접속만을 허용하도록 Security group을 설정하고, 이 Bastion역시 SSH접속을 운영자나 PC운영센터(회사)의 IP대역을 통해서 SSH접속만을 할 수 있도록 Security group을 설정해 놓으면 VPC로의 접근을 안전하게 통제할 수 있으며, 단일 접속 지점만을 제공하기 때문에 모든 사용자의 접근 내용을 한군데로 logging해서 감시할 수 있는 장점이 있다. Bastion은 단일 접속 지점인 만큼 하나의 Instance로 운영하는 것보다는 HA를 사용하거나 일반적인 접속을 위한 Bastion과 Super user(Admin)만을 위한 별도의 Bastion을 포함하여 2개 이상을 운영하는 것이 좋다.

 

VPC Scenarios

지금까지 간략하게 VPC의 기능에 대해서 알아보았다. VPC를 제대로 사용하면 상당히 다양한 구조의 network을 구성할 수 있다. 반대로 얘기하면, 모르면 구성이나 사용이 매우 어렵다는 이야기가 된다. Amazon에서는 VPC에 대한 주요 사용 패턴에 따른 약 4가지 시나리오를 이미 준비해 놓고, VPC Wizard에서 지원하고 있다.

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenarios.html를 보면 Amazon에서 제공하는 주요4가지 시나리오에 대한 설명과 설정 방법을 참고할 수 있다.

 

 

이 문서는 아래 조대협님 글을 기준으로 작성하였습니다.

https://bcho.tistory.com/779

Trackbacks 0 : Comments 0

Write a comment


묘연(猫緣)

나의 동거묘(猫)이야기 2018. 11. 17. 16:56

집 근처에 자주 들르는 장소가 있다.

하나는 죽집

또 하나는 안경원

마지막 하나는 짜장면집


이곳을 가끔 퇴근 후, 주말/휴일에 식사 등으로 자주 들른다.

안경원은 최근에 콘택트 렌즈를 사용하면서 이것저것 궁금한 것들이 많아 자주 간다.

이러던 중...

옆 건물에 '바른분양'이라는 상호를 쓰는, 한 곳이 인테리어 공사를 하고 있었다.

그 때만해도 "또 어떤 가게가 생기나보다..."라고 생각했다.

(광교 주변에 상가는 자주 바뀐다. 주변 점포 점주 말로는 임대료가 좀 비싸다 했다.)


지난 10월 초(初)로 기억한다.

그 때도 저 위 세 곳 중, 한 곳을 들렀다.


그냥 들른것이었다. '그냥'

좌측엔 댕댕이들, 우측엔 냥이들이 있었다.

내 기억엔 팻샵을 처음 간 것이었다. 신기한 나머지 아이들 얼굴을 보면서 이것저것 질문을 했드랬다.

그 중 한 놈(?)이 눈에 들어왔다.

그 뿐이었다.


일주일 정도가 흘렀다.

그냥 갑자기 그 아이 얼굴이 떠오르기 시작했다.

자기전, 일하는 도중, 멍때리다가도...

처음엔 그러려니 했는데, 계속 그랬다.

기분이 이상했다. "뭐지? 이런 느낌은...??"


일부러 그 곳을 찾아갔다.

그 아이를 다시 만났다. 그 자리에 있었고, 여전히 사랑스러웠다.

고양이 사육에 대해 이런저런 대화를 사장님과 나누었고, 죽을 먹으러갔다.

죽을 먹는도중 고양이 사육 시 주의사항 등에 대해 열심히 스마트폰을 들여다 보았다.

죽을 다 먹고, 다시 찾았다. 또 다시 이것저것 물어보 후, 2~3일정도 생각해보고 다시 오겠다고 말하고 집으로 향했다.

마지막에 "그 때 저 아이가 없으면 어쩌죠?"라고 했더니,

"그러면 인연이 아니겠지요..."라고 했다.

이렇게 그 아이와 나의 인연 아니, 묘연(猫緣)은 시작되었다.







tags : 고양이, 묘연
Trackbacks 0 : Comments 1
  1. jini 2018.11.17 17:59 Modify/Delete Reply

    몽이다~

Write a comment


Oracle sequence구현하기

DATABASE/SQLServer 2017. 11. 19. 17:46

Oracle sequence 구현하기


1. http://roqkffhwk.tistory.com/138


2. Sequence를 테이블로 만들어 관리하기

http://www.databaser.net/moniwiki/wiki.php/MS-SQL%EC%97%90%EC%84%9COracle%EC%9D%98Sequence%EB%94%B0%EB%9D%BC%ED%95%98%EA%B8%B0




Trackbacks 0 : Comments 0

Write a comment