정리 블로그

- [Code] 1.xx(조건부 응답)

: 조건부 응답. 일부 요청을 받았으며, 서버는 지속적으로 요청을 대기중인 상태.
    -. 통신 흐름

   case) 2번의 Request, 1번의 Response 와 같은 상태

- [Code] 2.xx(성공)

: 클라이언트와 서버 간 정상적으로 통신하는 상태.
    -. 통신 흐름

   ex) Request의 건 수만큼, Response의 건 수도 동일한 상태

- [Code] 3.xx(리다이렉션)

: 클라이언트에서 서버로 요청 시, 요청을 마치기 위해 추가 동작이 필요한 상황. 사용자가 특정 사이트 접속 시, 해당 사이트에서 다른 사이트로 전달하는 상황. 접속한 사이트에서 페이지 이동도 포함
    -. 통신 흐름

   ex) Request를 다른 서버로 Redirect하여, 클라이언트가 다른 서버를 확인하는 상황

- [Code] 4.xx(요청 오류)

: 클라이언트가 서버로 요청 시, 서버로 가는 중에 이상이 발생하
는 경우에 발생하는 오류 코드. 해당 코드가 발생하면 서버 운영자 입장에서는 '클라이언트' → '서버'에 도달하는 모든 구간을 하나씩 체크해봐야 함.
    -. 통신 흐름

ex) 클라이언트의 Request 시, Server까지 해당 요청이 정상적으로 도달하지 않는 상태.

- [Code] 5.xx(서버 오류)

: 클라이언트가 서버로 요청하였으며, 요청은 정상적으로 되었지만 서버에서 오류가 발생한 상황. 해당 상황에서는 서버 개발자가 서버 내부를 점검해야하는 문제가 대다수임.
    -. 통신 흐름

   ex) 클라이언트의 Request는 정상적으로 도달하나, Server의 오류로 인해 정상적으로 Response를 하지 못하는 상태.

1. IGW가 설정되어야 구성한 VPC가 외부와 인터넷 통신이 가능. 만약 인터넷을 쓰지 않으려면 IGW가 없어도 됨. 단, VPC로 연결하려면 VPN과 VPC를 연결하는 IPSec-VPN을 연결하거나, Custom Gateway 등의 구성을 해야 VPC 내부로 접속이 가능하다. 보통의 경우, NAT-Gateway나 Bastion Host를 통해 VPC 내부와 통신하기 때문에 IGW가 필요함.

2. WEB 서버일지라도 Public Subnet보다는 Private Subnet에 위치시키고, Internet-facing LB를 통해 WEB용도의 인스턴스에 접속되게 하는 것이 보안상 안전.

3. NAT 인스턴스의 역할은 VPC내 생성된 인스턴스를 터미널(linux계열) 혹은 원격데스크톱(윈도우 계열)을 통해 접속하기 위해 필요함. 또한, Private Subnet에 위치한 인스턴스가 인터넷을 사용할 수 있게 해주는 역할도 할 수 있다.

4. AZ는 이중화를 하여 구성할 것을 추천. 단일 AZ를 사용할 경우, LB를 통해 무중단을 위한 구성에 제약이 있음.(사용 가능한 AZ 개수는 리전마다 다름)

5. Subnet은 기본적으로 6개의 구성(Public Subnet 2EA, Private Subnet 4EA)을 하고, 특별한 이유가 있지 않다면 Private Subnet에 인스턴스를 구성하여 외부에 노출되지 않도록 한다. 각각의 subnet은 필요에 따라 라우팅을 달리하여 용도에 따라 통신경로를 지정해줄 수 있다.

6. LB는 Internet-facing을 통해 대외 서비스를 할 수 있도록 한다. 대내 서비스의 경우, Internal 구성을 하도록 하자.

*위 구성도에서 DevOps User도 IGW를 통해 VPC 내부로 접속하는게 맞음.

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. Timezone 변경 방법

  1. rdate : 서버와 NTP 서버(ex. time.bora.net) 시간을 동기화하는 방법

  2. timedatectl : 내가 설정한 시간 확인이 가능하며, 옵션을 통해 설정 변경 가능

  timedate set-timzone을 통해 hwclock(Hardware Clock)까지 변경 가능.

date

명령어를 입력하면 system의 시간 입력

hwclock

하드웨어 시간 출력

2. rdate

rdate -s time.bora.net

위 명령어를 입력하면 time.bora.net(보편적으로 사용하는 NTP 서버)의 시간을 동기화할 수 있음.

rdate는 경우에 따라, 설치가 필요할 수 있으니 인터넷이 되는 환경에서 yum을 통해 설치.

- time.bora.net 서버가 나타내는 시간은 -p 옵션을 통해 확인 가능.

- NTP 서버와 통신을 위해서 포트가 열려있는지 확인이 필요함.(UDP 37, UDP 123 오픈 필요)

3. timedatectl

timedatectl

Local time(한국 기준 KST), Universal time(UTC)를 확인 가능. 해당 명령어는 NTP서버를 보고 있는게(?) 아니기 때문에 시스템이 재부팅되더라도 HW시간, 서버을 걱정하지 않아도 됨. 경우에 따라 재부팅 시에 시스템 시간을 따라가는 경우가 있고, 하드웨어 시간을 따라가는 경우도 있음.

timedatectl set-timezone [대륙/지역]

위에서는 'timedatectl set-timezeon America/New_York'이 입력되었으며, America/New-York은 탭키를 누르면서 찾을 수 있음(ex. Asia/Tokyo는 A + 'tab'/Toky + 'tab' 키를 입력하여 찾을 수 있음)

timedatectl을 추천합니다.

* 주기적으로 시간을 맞춰주고자 할때는 crontab을 같이 사용.