정리 블로그

1. Private Subnet에서 인터넷 사용하는 방법

  - ㄱ. NAT-Gateway 사용하기

       1) NAT-Gateway를 Public Subnet에 위치시키고, Private Subnet의 라우팅을 NAT-Gateway로 설정

  - ㄴ. VPN 인스턴스 사용하기

       1) OpenVPN과 같은 NAT-인스턴스를 Public Subnet에 위치시키고, Private Subnet의 라우팅을 eni로 설정

2. Private Subnet에서 인터넷 사용 구성

  - ㄱ.

     -. NAT-Gateway가 위치한 Public Subnet의 라우팅은 igw로 설정하고, Private Subnet의 라우팅은 nat-gateway로 설정하여 'Private Server' -> 'NAT-Gateway' -> 'Internet-Gateway' 순으로 통신하도록 라우팅 설정.

  -ㄴ.

     -. 첫 번째 방법에서 NAT-Gateway 대신 VPN SERVER를 사용하는 방법. NAT-Gateway보다 비용이 저렴하지만, OpenVPN과 같은 VPN역할을 하는 직접 서버를 구성해야 한다. 번거로움이 있지만, 낮은 사양(t2.micro)으로 구성하기때문에 비용이 저렴하다. 물론, NAT 인스턴스(Server)는 외부와 통신할 수 있도록 Public IP(EIP)가 있어야 함.

3. Internet Gateway의 역할

  ㄱ. 인터넷게이트웨이는 VPC가 인터넷 통신을 할 수 있도록 하는 역할. 인터넷게이트웨이가 없다면 외부에서 VPC로 접근할 수 없을 뿐 아니라, 내부에서도 외부로 통신을 할 수 없다.

즉, VPN SERVER에 Elastic IP(Public IP)를 추가하더라도 인터넷 통신이 불가함.

Internet-gateway(IGW), NAT-gateway(VPN Server), Private Server 등 모든 준비가 되었더라도, Routing Table 설정이 정상적으로 되어있지 않다면 정상적으로 통신할 수 없으니 주의해야 한다.

1. RDS의 Character Default

 RDS의 Character Default는 'Latin-1'로 설정되어있기 때문에 한글의 경우 인코딩이 깨질 수 있음.

2. Parameter Group 변경

위 값을 dafult -> utf8 로 변경하여 사용하면 끝.

Parameter 변경은 이전 블로그 참고.

1. RDS Parameter 확인

- Parameter Group 및 Option Group은 각각의 RDS Engine과 Version마다 필요함.

- RDS를 생성하기 전 Parameter Group 및 Option Group을 생성해야 한다. 또한, Security Group도 사전에 만들어두면 나중에 바꿀 필요가 없음.

- Default Parameter Group과 Option Group의 속성 설정을 변경할 수 없기 때문에 초기에 설정 변경이 필요없다 하더라도, 먼저 버전에 맞는 그룹을 생성하고 세팅해줄 것 추천. 추후 변경 시, 재부팅 필요함 

- Security Group은 RDS를 생성 과정에서 신규로 생성할 수 없기 때문에(EC2 생성시에는 만들 수 있음) 정책이 없는 Security Group이라도 사전에 만들어서 Attach할 것.

2. RDS Parameter 및 Option 변경

- 현재 값과 변경될 값을 확인할 수 있음. 변경할 시점을 선택할 수 있음.

- Apply during the next scheduled maintenance window(해당 RDS에 유지보수 작업이 예정되면 해당 기간에 재부팅과 함께 변경됨.)

- Apply immediately(변경된 사항이 즉시 적용되며, 재부팅 필요.)

3. RDS Parameter 속성 변경

Parameter 속성 변경 후 재부팅이 필요한지 여부는 ‘Apply type’을 보고 확인 가능.

- Type이 Dynamic인 경우, 속성값 변경 후 재부팅이 필요 없음.

- Type이 Static인 경우, 속성값 변경 후 재부팅 필요.

* 속성값 변경 진행하기 전, Snapshot 생성 추천.

1. CloudFront??

-. AWS의 CDN(Contents Delivery Network) 서비스로 세계 어디서나 빠른 속도로 콘텐츠를 이용할 수 있도록 함.

-. CF는 Origin(ELB, S3 등)의 콘텐츠의 캐시값을 가지고 있으며, CF를 이용 시, 매 요청마다 Origin에 접근하지 않고 캐시를 이용하여 빠른 반환이 가능함.

2. CloudFront 설정

Web 방식

-. 정적, 동적 콘텐츠를 빠르게 전송(.html, .css, .php 등)

-. HTTP와 HTTPS를 통해 미디어 파일 분배

-. 이벤트 실시간 스트리밍

-. Origin에 파일을 저장. 배포 후에도 Origin 추가가 가능

RTMP 방식

-. 해당 방식은 2020년 12월 31일까지 제공하며, 배포 중단 예정

CF 설정 방법은 생성하면서 해당하는 부분의 정보를 확인해가며 만들었음.

3. CloudFront 구성

 여러 Site에서 taekisgood.tistory.com 을 입력한다고 가정했을 때, 여러 개의 Edge Location 중 접속한 곳에서 가까운 Edge Location을 통해 빠르게 CF와 연결이 되기 때문에 CDN 서비스를 이용할 수 있다.

CloudFront는 Origin(화면 기준 ELB)에 있는 정보를 캐싱(TTL 설정값 시간만큼)하고 있기 때문에 빠르게 반응해줄 수 있음.

또한, S3를 포함한 이유는 Log를 기록하기 위해서 작성하였음.

CloudFront는 Origin과 지속적으로 통신하며, 그 뒤로는 내부적으로 시스템을 설정 및 운영한다.

1. 인스턴스 Status Check

  인스턴스에 Status 알람이 1/2 와 같이 발생하는 경우가 있음.

2. 알람 원인

해당 경우는 두 가지의 경우.

   ㄱ. System Status Checks가 뜨는 경우

       - AWS는 사실 아마존에서 제공하는 장비를 빌려쓰는 것이며, 아마존의 장비에 문제가 생긴 경우 발생.

   ㄴ. Instance Status Checks가 뜨는 경우

       - OS에 행이 걸려 시스템에 문제가 생긴 경우 발생

3. 해결 방법

       - ㄱ,ㄴ 경우 모두 처리가 가능한 방법은 재부팅하는 방법이 있음. 이 때, AWS Console에서 Reboot(재부팅)이 아닌, Stop & Start 방법이 해결 방법. Reboot을 할 경우, 호스팅하는 하드웨어에 그대로 장착되지만, Stop을 하고 Start를 하는 경우에는 문제가 생긴 하드웨어에서 작동하지 않는다.

       - Config 설정을 잘못하는 경우에도 부팅이 제대로 이루어지지 않아 문제가 발생하는 경우도 있음. 이 경우에는 아무리 재부팅해봐야 정상적으로 진행할 수 없기 때문에 리눅스의 경우에는 이전 블로그를 참고할 것.

1. ELB 종류

 지난 블로그에도 적었던 것 처럼 Elastic Load Balancer는 3가지 종류가 있음.

ALB(Application Load Balancer), NLB(Network Load Balancer), CLB(Classic Load Balancer).

각각의 LB는 사용 용도에 따라 선택이 필요하며, 오늘 작성할 내용은 CLB(단순 LoadBalancing 역할)를 작성

2. CLB 생성하기

STEP 1.

- 첫 단계에서는 LB의 이름과 사용 포트를 정함.

CLB는 단순한 포트 포워딩만 가능. 위 캡쳐에서는 LB에 HTTP 80으로 들어온 통신을 LB에 연결된 EC2 80포트로 연결해주는 것을 나타냄.

- 내부에서만 사용하는 시스템에 적용하려면 'Internal Load Balancer'를 클릭 후 생성하면 외부에서 해당 LB를 통해 접속이 불가.(사실 여기서 Internal Load Balancer를 클릭하지 않더라도, LB의 Subnet을 Private으로 하면 외부에서 접속할 수 없음. 외부에서 nslookup 입력 시, 쿼리 확인 불가)

- Available Subnets는 LB가 위치할 Subnet을 추가.(AWS 권장은 LB를 Public에 두고, LB의 뒷 단(EC2)를 Private에 위치시켜 사용하는 방식. 즉, EC2는 외부에서 접속 불가하지만 LB를 통해 접속 가능

STEP 2, 3는 생략.(Security Group 설정)

STEP 4.

- LB는 기본적으로 Health Check를 통해 Healthy인 인스턴스로만 로드밸런싱 함.

- Healthy Check는 루트 경로의 파일의 ping port를 통해 진행되는데, 위와 같이 Ping Path에 해당 파일이 위치하고 있어야 한다. html을 사용하면 문제 없지만, 사용하지 않는 경우에는 'index.html'과 같이 비어있는 html 파일을 넣어둬도 체크가 가능하다.(단, 서비스에 이상이 생겼을 때, Healthy 상태를 유지한다는 단점이 있음.)

위 화면을 보면 조금 더 잘 보임. hello.html은 80포트를 이용하며, 30초 간격으로 Health Check. Timeout은 5초, 2번 체크가 되지 않으면 Unhealthy 상태로 변경되어, 해당 인스턴스는 밸런싱 되지 않음.

STEP 5.

- LB에 Attach 할 인스턴스를 지정하는 화면

- 하단에 Enable Cross-Zone Load Balancing은 해당 LB에 서로 다른 가용영역의 인스턴스를 넣을 수 있게 해줌. 위 화면에서는 둘 다 ap-northeast-2a를 사용했지만(보이지는 않음), ap-northeast-2c 등 다른 가용영역을 함께 사용할 수 있음

- 'Enable Connection Draining' 옵션은 LB에서 특정 인스턴스를 제거할 때, 해당 인스턴스에 신규 접속자는 차단하면서 기존에 인스턴스에 연결되어 서비스를 이용하는 사용자가 설정 시간동안 사용할 수 있도록 함.(위는 300초)

3. 포트 포워딩

* 예제에서 구성한 인스턴스는 80포트를 사용하는 중임.

- 'ELB주소:8080'을 입력하는 것과 'ELB주소:80'을 입력하는 것이 같은 페이지를 출력함.

- '여러 서비스를 사용할 때 쓸수 있나?'라는 생각을 가졌지만, 기본적으로 Health Check에서 80 포트를 체크하기 때문에 한 가지 서비스에 여러가지 포트를 사용할 때만 가능한 것 같다는 생각.(나중에 아닌 경우가 생각나면 수정해라)

4. AutoScaling과 연계

- LB를 설정하고 AutoScaling을 설정하여, 특정 임계치(CPU, Memory, Request Count 등의 지표)에 도달하면 새로운 인스턴스를 생성하여 LB에 Attach를 할 수 있다. 이 부분은 추후 작성예정이지만, 필요한 경우 구글링하면 금방 할 수 있을 것.

1. 신규 Instance 생성과 동시에 'Auto-assign Public IP' 기능을 사용할 경우

 - Instance를 생성하면서, 'Auto-assign Public IP'를 사용하면 EIP를 별도로 생성할 필요 없이 Public IP를 사용할 수 있다. 하지만, 해당 케이스는 Public IP가 변동되어도 상관 없다면 사용이 가능하다. 하지만, DDNS를 사용하지 않는다면 Public IP가 바뀔 때 마다, DNS 설정을 변경해줘야 하는 번거로움이 생긴다.

 ex) Auto-assign Public IP 기능을 사용하여 받은 Public IP가 10.10.10.10일 때, DNS서버에

'www.dennsworld.com' == '10.10.10.10' 로 되어있을 것이고, 인스턴스가 Stop이 된다면 이미 할당받은 '10.10.10.10'은 사라지게 된다. 그렇게 된다면, 사용자들은 'www.dennsworld.com' 에 접속할 수 없다.(DNS 통신 불가)

 - 'Auto-assign Public IP'는 서버 상태가 'STOP'이 될 경우, 할당 받은 Public IP가 사라진다. 사라진 Public IP는 'START'할 경우, '다른' Public IP와 함께 시작된다!

  ex) 인스턴스를 시작하면서 '11.11.11.11'이라는 Public IP를 가지고 시작되었다면

DNS서버에서 'www.dennsworld.com' == '11.11.11.11' 로 변경해야 사용자가 접속 가능.

2. 변경되지 않는 Public IP를 사용하려면..

 - Auto-assign Public IP를 기본 설정으로 둔다. 'Use subnet setting(Disable)'

 - 인스턴스 생성 방법은 취향과 필요에 맞춰 생성하도록 하고.. 다 만들고 나면 EC2 서비스의 좌측 패널 중간에 위치한 'NETWORK & SECURITY' -> 'Elastic IPs'로 들어가서 새로운 EIP를 할당받는다. (영문버전에서는 Allocate new address)

새롭게 할당받은 EIP와 인스턴스를 연결해줘야 한다.

Associate address를 통해 연결해 줄 수 있으며, 아래를 참고.

할당받은 EIP와 Instance ID를 연결해주자.. Instance의 Name을 통해 입력해줘도 되고, Private IP를 입력해줘도 되니 편할대로 하면 된다.

 * 경고 : 이렇게 할당받은 EIP는 서버를 중지시켜도 EIP에 대한 비용은 계속 청구되니, 별도의 주의가 필요하다.

* 서버가 STOP되어도 내가 가지고 있는 Public는 고정되어있다는 장점과 WEB 서버를 신규 구축하여 이전할 경우에도 할당받은 EIP를 신규 인스턴스와 연결해주면 새로운 서비스를 이용할 수 있다.(물론 대부분은 LB를 사용하기 때문에 EIP를 이동시키는 경우는 거의 없을 것이다..)

1. CLI ??

 CLI는 Command Line Interface의 줄임말이며, 말 그대로 명령어를 입력하여 사용하는 방식. 대부분의 사람들이 AWS Console을 이용해 손쉽게 AWS를 컨트롤하지만, CLI를 사용하면 조금 더 쉽게 원하는 내용만 추출할 수 있다는 장점이 있으며, 지속적으로 활용해볼 가치가 있음.

2. CLI 활용이 필요한 상황

 현재 사용하고 있는 여러개의 ALB 중 일부가 Access Log 기능이 활성화되어있지 않아 장애 발생 시, 로그 확인에 어려움을 겪을 수 있는 상황 발생. Access Log 기능이 활성화되어있는지를 확인하기 위해서는 한 개씩 모든 ALB를 확인하면 되지만 더 쉽게 찾아보기 위해 시도.

CLI를 통해 해당 문제가 완전히 해결된 상황은 아니지만, 혹여나 저와 비슷한 생각을 가지고 계신 분이 있지 않을까 하여 우선 작성.

CLI를 활용하기 위해서는 사용자 PC에 AWS CLI를 설치해야하며, 설치 방법은 검색해보시길..

3. CLI 활용 방법

 CLI는 리눅스와 마찬가지로 지속적으로 help 명령어를 통해 확인할 수 있음.

처음 사용을 어떻게 해야할지 모르겠을 때는, aws help를 입력하면 aws의 어떤 서비스들을 CLI를 통하여 사용가능한지 모든 서비스 확인 가능.

aws elbv2 describe-load-balancers

현재 aws cli를 설정한 계정에는 테스트를 위해 ALB 하나만 만들어 둔 상태이며, ALB에 대한 설명이 나옴.

하지만 제가 확인하고자 하는 정보는 해당 명령어를 통해 확인이 불가능하여 다른 명령어를 찾아 다시 입력.

aws elbv2 describe-load-balancer-attributes --load-balancer-arn arn:aws:(내소중한 정보)

해당 명령어를 입력하였을 때, 내가 찾고자 하는 "access_logs.s3.enabled", "false"가 나옴.(테스트를 위해 만든 ALB는 access log 비활성화 상태)

위의 명령어는 원하는 로드밸런서의 ARN(Amazon Resource Name)이 필요하기 때문에 VPC에 있는 모든 정보를 한번에 찾을 수 없다.

방법을 찾기위해 노력하는중..

시도했던 방법 1.

arn을 입력하여야 할 부분에 *를 사용하여 모든 arn을 검색하는 방법이 될까 싶어 시도해보았지만..내가 찾는것과는 다르지만 IAM의 무언가를 추출할 때도 ARN이 필요한 것을 알았으며, AWS측에서 가이드하는 아래 내용을 보고 포기.

시도중인 방법 2.

현재 내 계정내에 있는 모든 로드밸런서의 arn을 먼저 추출하여, 위 식에 대입해보는 방법

테스트를 위해 로드밸런서를 한개 더 생성하여(총 2개 로드밸런서) 모든 로드밸런서 arn을 추출하고,

arn을 사용해야 할 곳에 반복문이나 aws cli에서 사용가능한 논리연산을 사용하여 찾는 방법을 고민중...

*elbv2를 통해 ALB, NLB, CLB 모두 확인할 수 있는 명령어이며, 'elb'명령어도 있으니 필요에 따라 참고해서 사용하면 됨.

4. 느낀점

 CLI를 이리저리 잘만 사용하면 많은 AWS 리소스 컨트롤을 보다 쉽게 할 수 있을 것(모든 리소스를 사용자가 굳이 찾아 낼 필요 없이 추출)이라 생각하며, CLI를 활용하여 많은 테스트 진행 필요.