예를들어 인터벌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씩 더 한다.
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 로 눈길이 갔다.
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시 까지 봤다. 이과정을 해보길 잘했지 안해봤으면 넵튠 문제 다 틀릴뻔했다.
나는 서비스는 다써봤다. 안 써봤을리 없지.. 그많은 기간 테스트를 해봤으니, 그런데 단순테스트와 서비스에 대한 개념만으로는 나는 DOP를 통과할수 없었다. SAP 때의 지옥이 떠올랐다. 물론 SAP는 서비스 콤비네이션에 대한 질문이 주를 이루므로 각각의 상황에 알맞는 솔루션을 선택하는거라 나의 주종목인 넓고알기에 딱 어울리는 시험이었다. 그러나 DOP는 좀 달랐다.
나는 개발자로서의 경험이 1도 없는 사람이다. 엔지니어로서 오랜기간 일을했고, git 이나, svn, codecommit 등의 서비스를 써본적은 있어도 말 그대로 써본거지 실제로 내가 이걸 활용해 본적이 없는 것이다. 그렇기에 기능분기라던가 마스터 브랜치 같은 개념이나 아티펙트같은 개념이 잘 와 닿지 않았다.
이 모든건 내가 개발자가 아니기에 OPS의 의 영역엔 강할수 있어도 DEV의 영역에는 이해도가 낮았다 라고 판단했다. 그래서 시험에 떨어진 이후, 나는 CI/CD의 Best Practice를 주로 학습하고 여러명의 개발자가 코드분기 패턴이나 승인 패턴, 테스트패턴에 대한 학습을 했다.
그리고 오늘 시험보기 전에 어느정도 확신이 섰다. 내가 뭘몰랐는지에 대한 이유를 알았기 때문이었다. 역시 시험장은 솔데스크가 좋다. 영우글로벌도 좋은데..
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‛DF. rclone 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
