AWS-Load-balance-Failover-time-test

로드벨런서의 사용용도는 뭘까?

말그대로 부하분산을 위한 장치이다.

부하분산을 위해선 기본적으로 헬스체크가 되어야 하고 헬스체크 간격과 인터벌이 중요하다.

예를들어 인터벌30초에 헬스체크2회 라고하면 Failover 의 기대 시간은 59초인것이다.

시작 점 0초 에서 헬스체크를 성공후에 1초부터 어플리케이션이 문제가 생기게 되면 총59초의 간격동안 마지막 헬스체크가 실패하여야 Failover가 발생한다.

이론상으로 그런데.......이게 좀 이상했다.

기대시간에 NLB가 전혀 미치지 못했다. 나열해 보자면..

ALB의 최소 상태검사 시간이다. 인터벌5초 임계값2 총 9초안에 인스턴스의 unhealthy를 감지하고 트래픽의 라우팅을 멈춘다. ALB는 기대스펙과 동일하게 작동했다.

proxy 방식이라 당연히 그러하리라 생각했다. 문제가 생긴것은 NLB 였다.

NLB는 헬스체크 방식이 여러가지다. NLB의 대상그룹을 만들기 위해선 HTTP/HTTPS 가 아닌 프로토콜로 대상그룹을 생성하면 된다. 예를 들기 위해서 TCP를 사용했다.

상태 검사 프로토콜이 TCP 일 경우 인터벌 30초 임계값2가 최소 스펙이다. ALB에 비해 엄청나게 느린것이다. 이것을 짧게 수정하고 싶다면 상태검사 프로토콜을 HTTP로 해야한다. 대상그룹의 대상 프로토콜은 TCP로 하되 상태검사는 HTTP로 하는것이다. 대상과 상태검사의 프로토콜을 별도로 사용할수 있는것이다.

이제 10초의 인터벌 2회의 임계값을 가지게 되므로 19초에 페일오버가 되어야 한다.
그런데 이게 잘 안됬다.

!/bin/sh
date +"%y%m%d%H" >> $(date +"%y%m%d%H").txt
while true

do
STATUS=$(curl -# -o /dev/null -I -w %{http_code} -s -XGET http://test11-26d09f1385549f3c.elb.ap-northeast-2.amazonaws.com)

if [ $STATUS -eq 200 ]; then
echo 성공 >> $(date +"%y%m%d%H").txt
else
count=$(($count+1))
echo 실패 >> $(date +"%y%m%d%H").txt
fi
count=$(($count+1))
echo $count >> $(date +"%y%m%d%H").txt
sleep 1

done

위 스크립트로 1초마다 사이트를 호출해서 상태코드가 200이면 성공 그외엔 실패를 찍게된다. 그리고 1번 돌때마다 카운트를 1씩 더 한다.

1차 테스트 - 71초

6
실패
.
.
77
실패

2차 테스트 - 53초

6
실패
.
.
59
실패

이후 테스트들은 대부분 비슷한 시간 50~79초 사이에 페일오버 되었다.

전환시간은 최대 79초 까지 걸렸다. 여기서 NLB의 TTL을 확인해 봤다.

[root@linuxer home]# nslookup -type=cname -debug http://test11-26d09f1385549f3c.elb.ap-northeast-2.amazonaws.com
Server:         10.0.0.2
Address:        10.0.0.2#53

------------
    QUESTIONS:
        http://test11-26d09f1385549f3c.elb.ap-northeast-2.amazonaws.com, type = CNAME, class = IN
    ANSWERS:
    AUTHORITY RECORDS:
    ->  elb.ap-northeast-2.amazonaws.com
        origin = ns-679.awsdns-20.net
        mail addr = awsdns-hostmaster.amazon.com
        serial = 1
        refresh = 7200
        retry = 900
        expire = 1209600
        minimum = 60
        ttl = 33
    ADDITIONAL RECORDS:
------------

nslookup -type=cname -debug http://test11-26d09f1385549f3c.elb.ap-northeast-2.amazonaws.com

명령어로 확인시에 TTL 이 minimum = 60으로 페일오버될때 까지 ttl 이 모두 소모될때까지 기다려야 페일 오버가 가능하다. 조금 이해가 안가는 부분이 있는데..이부분은 AWS 내부로직이라 추측을 했다.

https://aws.amazon.com/ko/about-aws/whats-new/2018/02/network-load-balancer-now-supports-cross-zone-load-balancing/

Network Load Balancer relies on Domain Name System (DNS) to distribute requests from clients to the Load Balancer nodes deployed in multiple Availability Zones.

이내용을보면 DNS round robin 방식으로 여러개의 노드에 연결해주고 노드에선 다시 인스턴스에 연결해준다. 노드는 헬스체크에 따라 라우팅 하게되는데 노드의 TTL은 알수없으니 어느곳의 TTL로 인하여 페일오버의 지연이 발생하는지 알수없으나,

내가 원한 시간에 NLB는페일오버를 할수 없었다.

3rd party 의 LB 등 고민을 해봤으나 비용과 현실적인 문제로 페일오버의 기준을 맞추기 어려웠다. 그러던중 CLB 로 눈길이 갔다.

CLB는 http ~ tcp 까지 지원하는 이전 형식의 로드벨런서다.

CLB는 TCP 지원에 인터벌5초 임계값2로 9초로 페일오버가 되어야한다.

테스트 결과를 남기지 않아 아쉽지만 CLB는 기대치대로 동작하였다.

이 테스트 과정에서 얻은것이 몇가지 있다.

참고자료
  1. 우리는 ELB의 성능을 모두 알 수 없다. 어디서도 ELB의 max limite 를 공식적으로 발표한 자료가 없다.
  2. NLB 와 CLB의 성능적인 차이는 있다.
  3. 최저 헬스체크 타임은 ALB9초=CLB9초>NLB19초 순이다.

결론: CLB또한 쓸데가 있었다.

NCP-to-AWS-IPsec-multi-Cloud

NCP와 AWS 의 IPsec VPN을 연결해 보았습니다. Site to Site VPN을 연결하는 것입니다.

아직 NCP에서는 VPC 모드에서 IPsec VPN을 지원하지 않아서 Classic 모드에서 만 연결이 가능합니다.

NCP IPsec VPN Gateway 를 먼저 만들어야 AWS Customer Gateway 를 생성할수 있습니다.

NCP IPsec VPN Gateway 를 생성하기 위해선 Private Subnet 을 먼저 생성해야 합니다.
저는 192.168.1.0/24 로 생성했습니다.

Encryption : aes


D-H Group 은 NCP 에선 1/2/5만 지원합니다.

hash 는 sha 입니다.

확인 버튼을 누르면 생성됩니다.

확인된 IP는 49.236.139.115 입니다. 이 IP를 Customer Gateway에서 사용하시면 됩니다.

다음과 같이 CGW를 만들어 줍니다. 그다음 VGW를 생성해 줘야 합니다.
Virtual Private Gateway 는 VPC 에 붙이는 가상의 게이트 웨이로 CGW- tunnel -VGW 구성으로 통신하게 됩니다.

VGW는 생성하면 VPC에 Attach 해야 합니다.

VPN으로 사용하려는 VPC에 연결해 주세요.

이제 터널을 생성해야 합니다.

Site to Site VPN 메뉴에서 터널을 생성하면 됩니다.

미리 생성한 VPG와 CGW를 잘 넣어주시고 라우팅 옵션을 static 으로 설정합니다. BGP는 지원하지 않습니다.

정적라우팅 대역을 미리 추가해 주는게 편합니다.
Local IPv4 Network Cidr 는 NCP의 대역을 넣어주셔야 합니다.
Remote IPv4 Network Cidr cidr은 AWS 의 대역입니다.

Edit Tunnel 1 Options 을 체크해서 터널 옵션을 넣어줍니다.

Pre-Shared Key for Tunnel 1 에서 key 라고 표기하지만 VPN 인증시에 사용하는 값이라 패스워드처럼 취급되기도 하므로..저는 rkskekfk 로 설정했습니다.

위 옵션은 NCP IPsec VPN의 옵션에 맞춰서 체크한 옵션입니다. 모두 체크해도 문제는 없을듯합니다.

AWS는 DPD 옵션을 ikev2에서만 지원하므로 AWS VPN 자체에서 터널을 시작하는 기능은 NCP 와의 IPsec VPN 설정에선 사용할수 없는 설정입니다. 이유는 NCP의 IPsec VPN은 ikev1만 지원하기 때문입니다.

지금 설정에선 단일터널만 사용하려기에 tunnel 1만 설정해주려 합니다.

버튼눌러서 생성후엔 NCP의 IPsec VPN을 추가해야 합니다.

NCP 콘솔로 이동해서 AWS 의 터널 IP를 이용해서 터널링을 맺어줘야 합니다.

AWS 콘솔에서 VPN Tunnel Details 를 보면 Tunnel 1 의 IP를 확인할 수 있습니다.

이 아이피로 Peer IP로 사용해 연결할겁니다.

NCP 에서 Local Network 는 NCP의 Private Subnet Cidr입니다.

Remote Network 는 172.31.0.0/16 으로 AWS 의 네트워크 입니다.

위 이미지대로 선택해주세요.

사실 설명이 필요한 부분이 좀 있는데..과감히 생략합니다.
이유는 터널시작과 터널통신은 각각 인증방식을 사용하는데 이부분이 NCP는 나누어져서 설정하고 AWS 는 같이 설정합니다....그래서 그냥 따라서 해보시고 어려우면 댓글 남겨주세요.

생성하시면 굉장히 빠른속도로 생성됩니다. 아직 터널을 개시한 상태가 아니기 때문에 inactive 로 보일겁니다. 이때 터널의 상태를 확인할수 있는 방법이 있습니다.

메뉴에서

현재 상태를 확인할 수 있습니다.

인터페이스 / 라우팅 / IPsec VPN Tunnel 상태를 확인할수 있습니다.

There are no ipsec sas
There are no IKEv1 SAs

두줄의 메시지를 확인할수 있으며, 아직 터널이 UP상태가 아니기 때문입니다.

이제 인스턴스가 필요합니다.

네트워크 인터페이스에서 서버에 인터페이스를 붙이고 아이피를 부여해주세요.

다음과 같이 글로벌 비공인 IP와 추가한 Private Subnet IP가 보입니다.

인스턴스 내부에서 인터페이스를 설정해주세요.

cat <<EOF > /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
BOOTPROTO=static
ONBOOT=yes
#Private Subnet IP로 변경해주세요.
IPADDR=192.168.1.13
EOF
ifup eth1

이제 라우팅을 추가해야 합니다.

ip route add 172.31.0.0/16 via 192.168.1.1 dev eth1

추가 명령어 입니다.

 ip route del 172.31.0.0/16 via 192.168.1.1

라우팅을 잘못 넣게 되면 ip route del 명령어로 라우팅을 삭제할수 있습니다.
라우팅이 정상적으로 잘 연결되면 이제 AWS 에도 라우팅 테이블을 추가해야 합니다.

맨아랫 줄에 추가된 라우팅 테이블은 제일 먼저 만들었던 VGW 입니다.
이제 양방향으로 통신할 라우팅이 모두 만들어 졌고, 서로 통신할수 있도록 NCP 의 ASG와 AWS 의 SG를 열어주세요.

그리고 NCP의 인스턴스에서 ping 을 날려줍니다. AWS ikev1 은 DPD를 이용할수 없기 때문에 상태방에서 터널을 개시해야 합니다.

[root@s17596a9a6e6 ~]# ifconfig | grep inet
        inet 10.41.151.70  netmask 255.255.254.0  broadcast 10.41.151.255
        inet 192.168.1.13  netmask 255.255.255.0  broadcast 192.168.1.255
        inet 127.0.0.1  netmask 255.0.0.0
[root@s17596a9a6e6 ~]# ping 172.31.36.10
PING 172.31.36.10 (172.31.36.10) 56(84) bytes of data.
64 bytes from 172.31.36.10: icmp_seq=1 ttl=62 time=3.93 ms
64 bytes from 172.31.36.10: icmp_seq=2 ttl=62 time=3.45 ms
64 bytes from 172.31.36.10: icmp_seq=3 ttl=62 time=3.33 ms
64 bytes from 172.31.36.10: icmp_seq=4 ttl=62 time=3.44 ms

정상적으로 Site to Site VPN이 연결된것을 확인할수 있습니다.

이렇게 정상적으로 VPN이 연결 되면 AWS 콘솔에선 터널이 UP 상태가 되고,
NCP 콘솔에선 active 로 표시됩니다. 그리고 마지막으로 정상적으로 터널링이 맺어져서 통신이 되면 NCP 콘솔에서 아래와 같이 확인할수 있습니다.

KEv1 SAs:

Active SA: 1
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1

1 IKE Peer: 3.34.211.29
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE
interface: outside
Crypto map tag: outside_map, seq num: 1, local addr: 49.236.139.115

access-list outside_cryptomap_1 extended permit ip 192.168.1.0 255.255.255.0 172.31.0.0 255.255.0.0
local ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (172.31.0.0/255.255.0.0/0/0)
current_peer: 3.34.211.29


#pkts encaps: 827, #pkts encrypt: 827, #pkts digest: 827
#pkts decaps: 764, #pkts decrypt: 764, #pkts verify: 764
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 827, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#TFC rcvd: 0, #TFC sent: 0
#Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
#send errors: 0, #recv errors: 0

local crypto endpt.: 49.236.139.115/0, remote crypto endpt.: 3.34.211.29/0
path mtu 1500, ipsec overhead 74(44), media mtu 1500
PMTU time remaining (sec): 0, DF policy: copy-df
ICMP error validation: disabled, TFC packets: disabled
current outbound spi: C7CCEEBF
current inbound spi : E2B83FD5

inbound esp sas:
spi: 0xE2B83FD5 (3803725781)
SA State: active
transform: esp-aes esp-sha-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 2, IKEv1, }
slot: 0, conn_id: 264200192, crypto-map: outside_map
sa timing: remaining key lifetime (sec): 108
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
spi: 0xEED2584F (4006762575)
SA State: active
transform: esp-aes esp-sha-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 2, IKEv1, Rekeyed}
slot: 0, conn_id: 264200192, crypto-map: outside_map
sa timing: remaining key lifetime (sec): 0
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
outbound esp sas:
spi: 0xC7CCEEBF (3352096447)
SA State: active
transform: esp-aes esp-sha-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 2, IKEv1, }
slot: 0, conn_id: 264200192, crypto-map: outside_map
sa timing: remaining key lifetime (sec): 108
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
spi: 0xC47BC9E1 (3296446945)
SA State: active
transform: esp-aes esp-sha-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 2, IKEv1, Rekeyed}
slot: 0, conn_id: 264200192, crypto-map: outside_map
sa timing: remaining key lifetime (sec): 0
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001

이 포스팅은 과정 자체만 설명하고 자세한 프로토콜이나, 인증방식은 설명하지 않았습니다.

사용자의 레벨에서 따라만 해도 VPN 터널링이 가능한 수준의 포스팅을 하려했으나, VPN이 조금 난이도가 있는거 같습니다.

진행하다가 궁금하신 부분은 댓글남겨주세요.

읽어주셔서 감사합니다.

AWS-CloudFront-custom-header-ALB-filter

https://www.notion.so/CloudFront-ALB-f0086dec48b64f0883e0c6de5fd9da4c

Noah.Seo 님의 이야기를 받아서 다른방법을 테스트하게 되었다.

4번째 방법이 번득 떠오른탓.

그럼 내가 생각하는 부분은 이렇다.

CloudFront -> ALB

끝...3번 방법은 WAF에서 X-Origin-Verify Custom Header 를 필터링 한다. ALB에서도 비슷한 기능이 있는바. 나는 이전부터 ALB에서 내 블로그 도메인이 아닌 ALB 도메인이나 IP로 접근하는것을 제한한 바가 있다.

이 규칙이 바로 그것이다. Host 조건에 따라 Host가 다르면 아무 대상이 없는 blackhole 로 전달하게 된다. 그렇다. Custom Header를 ALB에서 필터링 할거다.

CloudFront 에서 Origin 을 수정한다.

단점은 ALB의 부하가 올라간다는것. 규칙에 의해 LCU 사용량이 증가할수 있다는 점이다.

그럼 셋팅해 보자.

X-Origin-Verify 헤더 네임을 추가하고 Value 로 test를 추가한다.

그리고 ALB의 규칙을 추가한다. 도메인 기반하여 http 헤더가 일치하면 라우팅. 그렇지않으면 두번째 규칙에 의해 blackhole로 전달한다. 지금 현재 정상적으로 헤더가 일치하여 사이트가 뜨는 상태다.

https://www.linuxer.name/

로 접근해보면 503에러가 발생하는것을 볼수있다.

재미있는 테스트 거리를 주신 Noah.Seo 님께 감사를 드린다.

Amazon CloudFront Origin Shield-Review

Origin Shield 가 출시 되었다.

Origin 에 전달되는 리퀘스트의 횟수를 줄여 관리비용을 줄인다고 한다.

먼저 캐싱율을 보자.

70%대다.

개판이다..이게 어떻게 변할까?

Origin Shield Region 으로 서울리전을 선택했다.

설정자체는 어려울게 하나도 없고 일단....

기다려 봐야겠다.

그리고 하루정도 지난상태로 포스팅 쓰는것을 이어간다.

먼저 어제의 히트율

21 ~ 22일의 히트율.

22 ~ 23일 오? 효과가 있다.

더 모니터링 이후 내용을 추가하겠다.

오후에 추가한 내용 오...히트율이 엄청올라간다. 만세! 유효한 효과가 있음을 확인하였다.

AWS-IP-list

wget https://ip-ranges.amazonaws.com/ip-ranges.json

wget 으로 먼저 aws 의 IP list 를 받는다.

yum install jq

jq를 다운받는다.

jq '.prefixes[] | select(.region=="ap-northeast-2") | select(.service=="S3") | .ip_prefix' < ip-ranges.json
"52.219.60.0/23"
"52.219.148.0/23"
"52.219.56.0/22"
"52.219.144.0/22"

IP list를 필터하여 확인한다.

jq '.prefixes[] | select(.region=="ap-northeast-2") | select(.service=="S3") | .ip_prefix' < ip-ranges.json | tr -d '"'
52.219.60.0/23
52.219.148.0/23
52.219.56.0/22
52.219.144.0/22

tr 로 " 를 삭제한 예제.

AWS Certified Database - Specialty - DBS-C01

AWS Certified Database – Specialty

AWS Certified Database - Specialty 시험을 응시했다.

공부를 안하고 먼저 연습시험부터 봤다.

8월 17일 시험을봤다. 오늘까지 한달정도의 텀이 있었고 DOP를 보면서 DBS에 대한 공부도 어느정도 같이 진행이 되었다. 이때 연습시험에서 나온점수는 45%였다.

총점: 45%
주제별 채점:
1.Workload-Specific Database Design:75%
2.Deployment and Migration:0%
3.Management and Operations:50%
4.Monitoring and Troubleshooting:50%
5.Database Security:50%

공부를 하나도 안하고 본 연습시험이라 각이 보였다. 뭐 깊은 고민도 없는 상태였고, 쭉쭉 시험을 풀어나갈수있었기 때문이다.

DOP 시험후 연습시험을 또 봤다. 이시점엔 공부가 어느정도 진행된 상태였다.

공부라함은..DB 서비스들의 docs를 대충보고 FAQ를 탐독하여 어느정도 지식이 있는상태였다. 대부분의 디비를 쓴상태지만.. 넵튠은 넵튠은...! 생소했다. 그래서 좀 열심히 봤는데 이게또 한번 생성하는 거만 못했다. 16일 밤에 부랴부랴 생성해봤다.

총점: 65%
주제별 채점:
1.Workload-Specific Database Design:50%
2.Deployment and Migration:75%
3.Management and Operations:75%
4.Monitoring and Troubleshooting:50%
5.Database Security:75%

20%를 올렸다. 불안감이 엄습했다..허어....70%였으면 불안하지 않았으리라..근데 불안했다. 그래서 연습 시험보면서 봤던 문제들을 기억해서 넵튠 만들고 오로라로 전환하고 테스트를 했다. 오로라 생성이 좀 오래걸려서..새벽2시 까지 봤다. 이과정을 해보길 잘했지 안해봤으면 넵튠 문제 다 틀릴뻔했다.

https://aws.amazon.com/ko/products/databases/

일단 이걸 기반으로 공부해야한다.

아직 Timestream / QLDB / cassandra 는 시험에 나오지 않는다.

FAQ를 중점적으로 읽고 사용사례를 꼭 읽자.

DBS 는 이미 먼저 한번 공부를 했던 su - 현님의 리드가 있었기에 공부가 쉬웠다.

공부에 도움을 주신 su - 현님께 감사를 드린다.

읽어 주셔서 감사합니다.

또 읽어주세요!

AWS Certified DevOps Engineer - Professional-Review - DOP-C01

일명 DOP 라 불리는 시험으로 AWS 에서 존재하는 2개의 pro 시험중 하나이다.

1차 8월 30일
2차 9월 14일 오늘이다.

8월 30일 시험으로는

698 점이었다. 52점이 모자랐다.

시험을 보고난뒤 현타가 왔지만 자아성찰을 했다.

나는 서비스는 다써봤다.
안 써봤을리 없지.. 그많은 기간 테스트를 해봤으니, 그런데 단순테스트와 서비스에 대한 개념만으로는 나는 DOP를 통과할수 없었다. SAP 때의 지옥이 떠올랐다. 물론 SAP는 서비스 콤비네이션에 대한 질문이 주를 이루므로 각각의 상황에 알맞는 솔루션을 선택하는거라 나의 주종목인 넓고알기에 딱 어울리는 시험이었다. 그러나 DOP는 좀 달랐다.

나는 개발자로서의 경험이 1도 없는 사람이다. 엔지니어로서 오랜기간 일을했고, git 이나, svn, codecommit 등의 서비스를 써본적은 있어도 말 그대로 써본거지 실제로 내가 이걸 활용해 본적이 없는 것이다. 그렇기에 기능분기라던가 마스터 브랜치 같은 개념이나 아티펙트같은 개념이 잘 와 닿지 않았다.

이 모든건 내가 개발자가 아니기에 OPS의 의 영역엔 강할수 있어도 DEV의 영역에는 이해도가 낮았다 라고 판단했다. 그래서 시험에 떨어진 이후, 나는 CI/CD의 Best Practice를 주로 학습하고 여러명의 개발자가 코드분기 패턴이나 승인 패턴, 테스트패턴에 대한 학습을 했다.

그리고 오늘 시험보기 전에 어느정도 확신이 섰다. 내가 뭘몰랐는지에 대한 이유를 알았기 때문이었다. 역시 시험장은 솔데스크가 좋다. 영우글로벌도 좋은데..

각설하고 학습과정은 이렇다.

먼저 자격증의 요구사항을 분석한다.

https://d1.awsstatic.com/ko_KR/training-and-certification/docs-devops-pro/AWS-Certified-DevOps-Engineer-Professional_Exam-Guide.pdf

시험 안내서면 충분하다.

https://d1.awsstatic.com/ko_KR/training-and-certification/docs-devops-pro/AWS-Certified-DevOps-Engineer-Professional_Sample-Questions.pdf

샘플문항을 풀어본다.

각자의 공부방법이 있겠지만 acloudguru나 udemy 등을 이용해서 공부해도 좋다.
그리고 나는 youtube 도 애용하는 편이다.

서비스는 사실.. 뭐...


파틸아저씨의 블로그를 서비스 항목만 참고해서 aws 상에서 만들어 보고 혼자서 실습을 한다. 주로 헤딩을 하며, 생성 구성 사용을 해보고 docs를 나중에 본다.

정독은 쉽지 않다.

어느정도 준비가 되면 연습시험을 본다. 시험 한번합격시에 연습시험 쿠폰을 1개를 주니, 무료 연습시험을 꼭보자.

연습시험에서 낮은 점수를 기록했다해도, 본시험은 그보다 난이도가 낮은 문제가 많이 나오니 너무 걱정말자. 그렇지만.. 걱정 안했다가 내가 8월30일 불합격을 맛봤다.

그 이후 이주간 개발자의 방법을 알기위한 노력을 끊임없이 진행했다.

그중에 가장 많이본건 CI/CD다...

그외에 아키텍처부분은 뭐..그냥 쏘쏘.....

https://aws.amazon.com/ko/products/developer-tools/

크게는 여기서 개발자 툴의 범주를 확인했고

https://aws.amazon.com/ko/codepipeline/faqs/

https://aws.amazon.com/ko/codebuild/faqs/?nc=sn&loc=5

https://aws.amazon.com/ko/codecommit/faqs/

https://aws.amazon.com/ko/codedeploy/?c=dv&sec=srv

https://aws.amazon.com/ko/codeartifact/faq/

https://aws.amazon.com/ko/xray/?c=dv&sec=srv

람다를 운영에서 사용하는 방법을 봤다. .serverless 에서의 lambda는 컴퓨팅을 담당하지만 DOP에서의 lambda는 AWS에서의 서비스간 역할을 강하게 묶어주는 역할이 더많은것같다.

https://aws.amazon.com/ko/lambda/faqs/

AWS Lambda를 사용하여 AWS 이벤트 처리

이 부분이 중요하다. 그리고 또 Cloudfromation AWS 에서 IaC를 맡고 있으므로 굉장히 중요..그리고 Elasticbeanstalk 아직 ECS 나 EKS는 시험에 드물게 나온다.

또한 배포방식..

https://aws.amazon.com/ko/premiumsupport/knowledge-center/codepipeline-deploy-cloudformation/

이런 자습서 꼭 참고하자..보기만 해도 도움이 된다.

내가 DOP를 이해하기위해 본것들이다.

정리를 하며 본건 아니라서 좀 중구난방인데 도움이 되길 바란다.

890점으로 통과했고,

자격증 까지 나왔다.

근래에 자격증 발급속도가 당일 발급이라 만족스럽다.

읽어주셔서 감사합니다!

다음에 또 읽어주세요.!

AWS-EFS-policy

AWS의 콘솔들이 업데이트 되면서 기본정책이 변경되고 있다.

EFS의 생성 정책이 변경된것인데, 이건좀 좋다고해야할지 알지 못하는곳에서 비용이 발생할거라고 해야할지..애매하다.

평소처럼 EFS 생성을 했는데 좀 이상했다.

생성 누르면 바로 생성되는것이다.

원래는 보안그룹이나 태그 처리량 모드같은걸 설정해서 만들수 있었는데..
했더니 사용자 지정 모드가 생겼다.

자세히 봐야할건 기본 유형이 변경되었다는것이다.

사용자 지정을 누르면

자동백업과 수명주기 관리가 30일로 변경된것이다.

원래 설정은 자동백업도 없고 수명주기도 암호화도 없었다.

-_-;

뭐....그냥 사용자의 편의를 봐준거라 생각도 드는데..

음.............비용 어쩔꺼야..

성능 어쩔꺼야...ㅠㅠ

AWS-Linux-EBS-to-EFS

아키텍쳐를 수정중에 EBS에서 EFS로 파일을 넘길일이 생겼다.

300G 가량의 대량의 파일이 있는 디렉토리를 sync 해야했다.

EBS는 GP2로 400G, 1200IOPS를 가진 볼륨이었다. 스냅샷에서 볼륨을 생성해서 4T로 확장하여 12000IOPS를 가진 볼륨에서 테스트를 진행하였다.

새벽에 먼저 싱크를 진행한 내용이 있는데 network out 이 40mb를 넘지 않았다.

싱크는

rsync -av /src /dst

로 진행한것 같았다. rsync 의 속도를 끌어 올리기 위해 테스트했으나 실패. 속도는 40mb 에서 더 이상 올라가지 않았다.

그래서 강구한 방법이 tar 를 이용한 데이터 이동이었다.

tar -C <src> -cf - . | tar -C <dst> -xf -

속도는 170mb 정도 그러나, 치명적인 단점이 존재했다. 소유권과 퍼미션을 가져오지 않는것이었다.

-_-; 파일이동이라 함은..소유권과 퍼미션을 그대로 가져가야하는데...그게 안됬다. 그래서 임시 방편으로

tar -cvf /dst/file.tar /src

명령어로 EBS의 데이터를 tar 로 압축해서 EFS로 저장하는 명령어로 작업했다.

이때 속도는 170MB 정도.. tar로 압축하지 않고 pipeline 으로 보냈을때와 동일한 방식이지만 소유권과 퍼미션을 유지할수 있는 방법이다.

그렇지만 속도가 마음에 들지 않았다.

물망에 rclone / rdiff-backup 가 있었다.

rclone 은 씅광님이 추천해줘서 오후내내 테스트를 했다. 그런데 속도가 너무 잘나오는데 문제는 퍼미션과 소유권을 가져올수 없는것이다.

그래서 승광님께서 주신 힌트로 테스트를 진행했다.

clone sync /src /dst --checkers 128 --transfers 128

속도는 놀라웠다. T3a.medium type의 네트워크 성능(Gbps) 이라 표기된 5G를 모두쓰는것이었다.

이렇게 network 를 모두 사용하는것은 처음이라 신기할정도로 rclone는 빨랐다.

300G 모두 sync하는데 1시간 30분밖에 걸리지 않았으니까..

그런데 여기서 rclone은 문제가 발생한다.

https://rclone.org/local/#filenames

Filenames

Filenames should be encoded in UTF-8 on disk. This is the normal case for Windows and OS X.

There is a bit more uncertainty in the Linux world, but new distributions will have UTF-8 encoded files names. If you are using an old Linux filesystem with non UTF-8 file names (eg latin1) then you can use the convmv tool to convert the filesystem to UTF-8. This tool is available in most distributions' package managers.

If an invalid (non-UTF8) filename is read, the invalid characters will be replaced with a quoted representation of the invalid bytes. The name gro\xdf will be transferred as gro‛DFrclone will emit a debug message in this case (use -v to see), eg

인코딩 문제인데 이건...하...나중에 rsync 로 남은파일을 채워볼까 생각했지만 불확실성이 너무 컷다. 파일의 누락이 너무많았다

그래도 테스트는 그냥 진행했고 싱크속도 무지빠르고 쓸만했다.

그래서 이후에 소유권과 퍼미션을 넣어주는 작업을 궁리했다.

getfacl -R /src > file.list
sed 's/src/dst/g' file.list
cd /dst
setfacl --restore=file.list

4줄의 명령어로 소유권과 퍼미션을 그대로 가져오는 방법을 찾았다.

이제 인코딩 문제만 해결하면된다 생각했지만, 안정성의 문제때문에

tar로 압축해서 넘기를 방식으로 계속진행하기로 생각했다.

오늘 적당한 낚시와 어드바이스를 주신 승광님께 감사드린다!