Azure-네트워크 구성 및 망분리

azure 에서 망분리가 먼저 선행되어야 할 과제이다.
aws 에서의 망분리는 계층적 망분리로 서브넷과 라우팅 테이블을 이용하여 망분리를 구현한다. 하지만 gcp / azure는 망분리의 개념이 좀 다르다.

서브넷을 통한 망분리가 아닌 공인IP의 유무로 망분리를 구현한다.

근래에 구성도를 작성하면서 한편으로 계층적 망구성이 구성도 그리긴 불편한 생각이 들긴한데 그래도 익숙하고 편한데 azure 와 gcp 를 보니까 aws 의 망구성이 관리의 편의성이 떨어지는 느낌이기도 하고..조금 애매한 느낌이 든다.

azure 에서는 어떤 인프라도 리소스그룹안에서 만들어진다. gcp의 프로젝트 개념과도 같다. 그렇지만 좀 다른게 리전에 종속된다.

한국리전은 중부와 남부로 나뉘는데 중부를 azure 에선 중부를 주로 추천하는데 나는 중부말고 남부를 선택했다.

요구하는 바는 구독 그룹네임 리전 리소스 그룹다음에는 virtual network 를 생성하는데 VN은 서브넷을 생성하게 된다.

가상네트웤의 최대 크기는 10.0.0.0/8 까지로 16777216개 주소 를 사용할수 있다.

서브넷을 3개로 나누었고 서브넷은

보안그룹을 서브넷에 설정하여 접근제어가 가능하다.

aws 의 구성의 경우엔 az 별 서비스별 서브넷을 설정했지만 azure 는 az가 명시적으로 지정되지 않아 서비스별 서브넷을 생성해서 사용하는것이 최선으로보인다.

서브넷의 보안그룹으로 막으려면 tag ip id 로 명시적으로 막자.

서브넷별 nsg 가 구성되는게 좋을것 같다.

가상머신은 공용아이피를 없앤 채로 생성한후 나중에 공용IP를 부여할수있었다.

직렬연결은 가상화 머신의 화면을 그대로 포워딩해주는 방식으로 보이며 공용IP가 없는 상태에서도 연결할수 있었다.

굉장히 불편한 부분은 이다음에 발생했는데 lb 는 sku 개념덕분에 혼파망이 되었다.

sku는 basic / standard 두가지로 나누어져있는데

Configures outbound SNAT for the instances in the backend pool to use the public IP address specified in the frontend.

인터넷 통신

기본적으로 VNet의 모든 리소스는 인터넷으로 아웃바운드 통신을 할 수 있습니다. 공용 IP 주소 또는 공용 Load Balancer를 할당하여 리소스에 대해 인바운드로 통신할 수 있습니다. 공용 IP 또는 공용 Load Balancer를 사용하여 아웃바운드 연결을 관리할 수도 있습니다. Azure의 아웃바운드 연결에 대한 자세한 내용은 아웃바운드 연결, 공용 IP 주소 및 Load Balancer를 참조하세요.

하...모든인스턴스는 인터넷과 통신이 가능하다. 이거때문에 한참을 헤멧다.

nat gw가 필요가 없다..............................충격 막으려면 NSG로 막아라.

그래서 일단 정리하자면 azure 의 모든 네트워크 접근제어는 네트워크 단위가 아니라 NSG에서 모두 컨트롤한다.

선택한 서브넷 'linuxer-subnet-pri(10.0.0.0/24)'이(가) 네트워크 보안 그룹 'pri-sub-sg'에 이미 연결되어 있습니다. 여기에 새 네트워크 보안 그룹을 만드는 대신 기존 네트워크 보안 그룹을 통해 이 가상 머신과 연결을 관리하는 것이 좋습니다.

azure LB사용할땐 가용성 집합을 이용해서 VM을 만든다.

리소스그룹-vpc-subnet-가용성집합-vm-lb 순으로 생성하게 된다.

LB는 베이직과 스텐다드..하 sku 개념이 제일짜증난다.

LB를 베이직으로 생성시에

???같은 가용성 집합인데????

음...이유는 다음에 찾아보기로 하고..

sku 가 스텐다드인경우엔 잘 된다..음 베이직이라 제한이 있는것으로 이해하고 지나가기로 한다.

상태 체크는 로드벨런스 안에서..아니면 zure monitor 을 이용하자.

근데 LB에서 페이지가 뜨는건 잘안됬다 왜지?

그리고 스터디를 마치고 집에와서 백엔드 규칙만 재생성하니 정상적으로 잘됨..뭐야이거..빡치네..

2020년 1월 19일 by Azure 0

aws-cloudfront-s3-lambda cross-account access

cloudfront - s3 를 이용하게되면 결국 OAI를 이용한 Bucket policy를 사용하게 된다.

단일 계정에서 사용할 경우엔 cloudfront 에서 자동으로 생성까지 해주므로 어려울것이 전혀없다.

그런데 이제 이게 파트너사를 통해서 cloudfront 전용계정을 사용하게 된다던거 multi account 로 프로젝트를 진행할경우 자동으로 생성이 되지 않는다. 이 경우에 어떤방식으로 s3 Bucket policy 를 설정해야 하는지 포스팅하려 한다.

먼저 Bucket policy 를보자

{
"Version": "2012-10-17",
"Id": "PolicyForCloudFrontPrivateContent",
"Statement": [
{
"Sid": " Grant a CloudFront Origin Identity access to support private content",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E39X8K28W3EQ"
]
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::*"
}
]
}

일반적으로 계정에서 버킷정책을 설정하면 위와같은 형태로 적용을 한다.
가끔 정상적으로 적용이되지않는경우엔

{
"Version": "2012-10-17",
"Id": "PolicyForCloudFrontPrivateContent",
"Statement": [
{
"Sid": " Grant a CloudFront Origin Identity access to support private content",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity 49821f785cce6ee4f575de3f01c503dade8a7b15003aa337faa471d830d07493cbb195eec14f0d86d4a914622e1e42"
]
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::*"
}
]
}

이런식으로 caninucal user id 를 이용하여 정책을 설정하면 자동으로 OAI ID로 정책이 적용되게 된다.

여기까진 아주 쉬웠다. 그런데

람다 엣지를 이용한 리사이즈를 하는 프로세스에서 단일계정이 아니라 교차계정을 구성하게 되면 lambda가 A 계정에서 B 계정으로 접근하게 해줘야한다. 이부분에서 조금 헤멧는데 결국엔 굉장히 간단한 부분이었다.

s3 Bucket policy 에서 계정의 role을 허용해주면 끝..

{
"Version": "2012-10-17",
"Id": "PolicyForCloudFrontPrivateContent",
"Statement": [
{
"Sid": " Grant a CloudFront Origin Identity access to support private content",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E39X8K58WRN3EQ",
"arn:aws:iam::328341115633:role/lambda-resize-cloudfront"
]
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::linuxer-resize/*"
}
]
}

arn:aws:iam::328341115633:role/lambda-resize-cloudfront

json 문법에 또 약해서 좀 해멧는데 금새 해결할수 있었다..

2020년 1월 18일 by AWS 0

aws-EFS-backup-restore

EFS를 사용하고 백업/복구 이야기를 하려고한다.

EFS는 NFS기반의 편리한 서비스다. aws backup로 스냅샷 방식의 백업이 가능하다.

현재 측정크기가 6.0kib인데

# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 475M 0 475M 0% /dev
tmpfs 492M 0 492M 0% /dev/shm
tmpfs 492M 404K 492M 1% /run
tmpfs 492M 0 492M 0% /sys/fs/cgroup
/dev/xvda1 8.0G 4.6G 3.5G 57% /
tmpfs 99M 0 99M 0% /run/user/0
fs-7eb4fb1f.s.ap-northeast-2.amazonaws.com:/ 8.0E 0 8.0E 0% /mnt/efs

root@ip-10-0-0-12 wordpress]# cd /mnt/efs
# du --max-depth=1 -h
258M ./ftp
258M .

실제론 그렇지 않다. 일정 GB이상의 데이터가 쌓여야 명령어가아닌 gui에서 확인할수 있다.

오늘은 이 파일시스템을 백업할거다.

aws backup를 사용할때 유의할점은 백업볼트를 생성할때 각각 목적에 맞게 분할해서 사용하라는 거다. 급하게 작업하다가 관리가 너무 불편해져서 결국 나눴다.

일반적으론 볼트생성->계획생성->규칙생성->리소스할당 순서다.

리소스할당은 tag 기반으로도 가능하고 리소스ID 유형으로도 가능하다.

여기까지 백업계획을 이용한 스케줄 백업이었고 단발성 백업은 대시보드에서 온디멘드 백업으로 진행하면 된다.

진행중인 jab는 작업부분에서 확인할수 있다.

용량이 작어서 금방 백업이 완료됬다.

백업은 증분방식이고 복구지점에 카운트가 올라간다.

복원을 진행해 보면

전체/부분/소스/새 이렇게 선택지가 나눠지는데 얼마전 나에게 혼란을 줬던 부분은 전체-소스 파일 시스템에 복원이다.

복원을 누르면 작업탭에 복원에서 확인할수 있다.

Pending-> Running -> Completed 단계를 거친다.

Pending 이 한국어 에선 보류중으로 나오는데 처음에 좀 당황했다.
보류...??????????????????????????????????????????????
하고 Pending 좀 오래걸린다. 거의 10분 이상걸린적도있다.

root@ip-10-0-0-12 ~]# cd /mnt/efs/
root@ip-10-0-0-12 efs]# ll
total 16
drwxr-xr-x 4 root root 6144 Jan 18 11:24 aws-backup-restore_2020-01-18T03-33-30-039Z
drwxr-xr-x 4 root root 6144 Jan 18 11:24 aws-backup-restore_2020-01-18T03-47-22-912Z
drwxr-xr-x 4 root root 6144 Jan 18 11:24 aws-backup-restore_2020-01-18T03-49-03-261Z
drwxr-xr-x 3 jth-ftp jth-ftp 6144 Aug 21 21:20 jth-ftp

aws-backup-restore_2020-01-18T03-33-30-039Z 같은 형식으로 복원 시작시간으로 디렉토리가 생성되고 복원이 된다. 당연히 복원되는 양에 따라서 속도도 다르다.

3번 복원을해서 3개의 디렉토리가 추가 생성된거다. 사용용량이 df 로는 안보이지만 aws 콘솔에선 보인다.

처음 복구할 땐 덮어쓰기로 생각해서 한참을 기다려도 복구가 안되는거같아 EFS의 /를 마운트 해보고서야 알았다. 아 디렉토리 생성 후 복구되는구나.

그래서 이제 추가로 파일 복구를 해보기로 했다.

root@ip-10-0-0-12 wp-admin]# pwd
/mnt/efs/jth-ftp/wordpress/wp-admin
root@ip-10-0-0-12 wp-admin]# ll
total 980

/mnt/efs/jth-ftp/wordpress/wp-admin 디렉토리를 복구해보겠다.

부분 복원으로 선택하고~ 작업은 부분복원이 좀더 걸리는거 같았다.

/mnt/efs/aws-backup-restore_2020-01-18T04-09-39-782Z/jth-ftp/wordpress/wp-admin

경로로 이동해서 복구 확인해봤다.

root@ip-10-0-0-12 wp-admin]# ll
total 980

정상적으로 잘복구 된것을 확인할수 있었다.

efs 를 매우 애용하는 입장에서 파일복구가 가능해진것은 매우 반길 일이다.

아 추가로 EFS 에서 Bursting 모드를 사용할경우 BurstCreditBalance 를 가지게 되고 사용시 소모가 된다. 그런데 백업이나 복구시에는 크레딧을 따로 소모하지 않았다.

읽어주셔서 감사하다!

2020년 1월 18일 by AWS 1

aws-dynamic-cloudfront

오늘의 주제는 dynamic cdn / 동적 cloudfront 다.

cloudfront 는 cdn 이다. cdn 이 뭔가?

Contents Delivery Network 컨텐츠를 빠르게 전송하기 위해서 사용자에게 가까운 edge 에서 응답해주는 방식이다. - edge 는 aws에서 말하는 용어이고 보통 pop라고 한다.

많은 지역에 pop이 존재하고 이 pop에선 원본 컨텐츠를 캐싱하여 user에게 전달한다.

구성도로 보자면 다음과 같다.

user 가 네임서버에 domain 에대한 확인을 하고 cf의 위치를 알려주면 user는 가장가까운 pop에 연결된다.

간단하게 확인하려면 f12를 눌러서 cloudfront 의 헤더를 확인해 보면 된다.

https://cdn.linuxer.name/test/iu.jpg

x-amz-cf-pop : ICN50 이부분이 근처의 팝인것이다.

이렇게 정성스럽게 설명하는 이유는 간단하다.

오늘 설정할 부분이 일반적인 CDN의 사용방법이 아니기때문이다.

사이트의 응답속도를 빠르게 하려면 어떻게 해야할까?

많은 방법이 있는데 제일 좋은 방법은 먼저 컨텐츠에 도달하는 속도를 올리는 방법이다. 컨텐츠에 대한 도달속도를 확인하는 방법은 첫번째로

tracert 이다.

테스트하는 도메인의 구성이다.

>tracert 리눅서.com
1 1 ms <1 ms <1 ms 192.168.2.1
2 1 ms 1 ms 1 ms 121.125.68.225
3 2 ms 3 ms 3 ms 100.127.39.21
4 3 ms 4 ms 2 ms 10.222.41.224
5 3 ms 2 ms 3 ms 10.222.14.73
6 2 ms 2 ms 6 ms 211.210.54.34
7 * * * 요청 시간이 만료되었습니다.
8 * * * 요청 시간이 만료되었습니다.
9 * * * 요청 시간이 만료되었습니다.
10 * * * 요청 시간이 만료되었습니다.
11 4 ms 5 ms 4 ms 52.93.248.221
12 4 ms 3 ms 4 ms 54.239.123.121
13 3 ms 3 ms 3 ms 54.239.122.38

54.239.122.38 IP는 아마존 IP로 아마존 내 네트워크 까지 연결된것을 확인할수 있었다.

그다음 도메인은 cf에 연결된 도메인이다.

>tracert linuxer.name
1 1 ms <1 ms <1 ms 192.168.2.1
2 1 ms 1 ms 1 ms 121.125.68.225
3 1 ms 3 ms 3 ms 100.127.36.21
4 4 ms 2 ms 2 ms 10.222.41.230
5 2 ms 1 ms 1 ms 10.222.15.91
6 2 ms 3 ms 3 ms 211.210.54.34
7 3 ms 3 ms 3 ms 52.93.248.36
8 3 ms 2 ms 2 ms 52.93.248.83
9 2 ms 2 ms 2 ms 54.239.41.13
10 * * * 요청 시간이 만료되었습니다.
11 * * * 요청 시간이 만료되었습니다.
12 * * * 요청 시간이 만료되었습니다.
13 2 ms 2 ms 2 ms server-54-230-181-122.icn50.r.cloudfront.net [54.230.181.122]
추적을 완료했습니다.

지금 구성에서 linuxer.name 과 리눅서.com 사이트의 동작 자체는 동일하나 리눅서.com은 로드벨런서를 다이렉트로 바라보고 있고 linuxer.name 은 cloudfront 로 연결되어 오리즌을 로드벨런서로 바라보고 있는상태이다.

그럼 라우팅은 정상적으로 cloudfront 쪽이 빠른걸 확인했으니 컨텐츠에 대해 접근이 빠른지 확인해 보려면 어떤방법을 사용해야할까? TTFB와 여러지표를 확인하기로 했다. 웹개발자 도구로 timing을 확인하면정확하게 확인할수 있을거라 생각했다.

ttfb 가 312.65ms 다 그럼 다이렉트로 로드벨런서에 연결된 도메인은 속도가 얼마나 나올까?

ttfb 가 435.53ms 다. 오잉? 생각보다 속도 차이가 있다.

그럼 일단 더테스트하려면...어쩔까..간단하게 해외로 간다!

18353km 떨어진 상파울루 리전의 win ec2 이용하여 테스트 하겠다.

cf가 적용되어있는-linuxer.name

cf가 적용되지 않은 리눅서.com

상황에 따른 응답속도의 차이가 있긴하지만 확실히 dynamic cdn 을 적용한 도메인쪽이 좀더 빨리 떳다.

어느정도 유효한 결과를 확인했다는 뜻이다.

물론 내블로그는 가벼우므로..또르륵

https://aws.amazon.com/ko/cloudfront/dynamic-content/

https://aws.amazon.com/ko/blogs/korea/how-to-improve-dynamic-contents-delievery-using-amazon-cloudfront/

직접 경험해야 하는터라 다하고나니까 문서를 봤다 ㅋㅋㅋ

그래서 이제 어느정도 검증이 끝났고 설정방법이다.

Cache Based on Selected Request Headers -> ALL 로 수정하면 끝이다.

나머지는 자신의 설정대로..잘하면 된다.

끝. 좋은하루 되시라!

2020년 1월 18일 by AWS 0

gcp terraform-3 vpc-nat create

vpc-nat 를 연결하기로 했다.
어젠 subnet 을 만들었고 오늘은 망분리 환경을 구성하기 위해 nat 를 넣었다.

main.tf

resource "google_compute_subnetwork" "us-central1-subnet" {
name = "${local.name_suffix}-us-central1-subnet"
ip_cidr_range = "10.2.0.0/16"
region = "us-central1"
network = "${google_compute_network.vpc.self_link}"
}
resource "google_compute_router" "us-central1-router" {
name = "${local.name_suffix}-us-central1-router"
region = google_compute_subnetwork.us-central1-subnet.region
network = google_compute_network.vpc.self_link
}
resource "google_compute_address" "address" {
count = 2
name = "${local.name_suffix}-nat-manual-ip-${count.index}"
region = google_compute_subnetwork.us-central1-subnet.region
}
resource "google_compute_router_nat" "nat_manual" {
name = "${local.name_suffix}-us-central1-router-nat"
router = google_compute_router.us-central1-router.name
region = google_compute_router.us-central1-router.region
nat_ip_allocate_option = "MANUAL_ONLY"
nat_ips = google_compute_address.address.*.self_link

source_subnetwork_ip_ranges_to_nat = "LIST_OF_SUBNETWORKS"
subnetwork {
name = "${local.name_suffix}-us-central1-subnet"
source_ip_ranges_to_nat = ["10.2.0.0/16"]
}
}

resource "google_compute_network" "vpc" {
name = "${local.name_suffix}-vpc"
auto_create_subnetworks = false
}

backing_file.tf

locals {
name_suffix = “linuxer”
}
provider “google” {
region = “us-central1”
zone = “us-central1-c”
}

vpc 와 nat nat route 까지 정상적으로 만들어져서 동작하는 것을 확인할 수 있었다.

리전당 nat는 1개를 꼭만들어야 했다.

현재 생성한 tf는 subnet 하나에 대한 설정이다. 다른 리전으로도 네임만 수정을 적절히 하면 수정해서 쓸수 있다.

2020년 1월 5일 by GCP 3