4주차 인프라

[YangDaJin0104]

📌인프라

1. 인프라 정보

• 서버 위치(Zone) KR-1
• 하이퍼바이저 XEN
  • 가상 머신을 생성하고 관리하는 소프트웨어
  • 물리적 서버에서 여러 가상 서버를 실행할 수 있도록 한다.

---

• 리전 내의 가용 영역을 의미하며 리전이 물리적으로 나뉜 여러 데이터 센터로 구성된 경우 각 데이터 센터를 Zone이라고 한다.

2. 인프라 구성 환경

• 스토리지 구성
  • 스토리지 이름 sopt-server의 기본 스토리지
    • 서버에 연결된 기본 저장소
    • 데이터가 저장되는 물리적 디스크이다.
  • 크기 50GB
  • IOPS 4000
    • 초당 입출력 작업 수
    • 데이터 1/O 속도 성능을 나타낸다.
  • 연결 정보 /dev/xvda로 마운트된다.
    • 리눅스에서 이 스토리지가 연결된 위치

---

• 스토리지는 주로 SSD와 HDD로 구분된다.
  • SSD : 빠른 읽기/쓰기 속도가 필요할 때
  • HDD : 대용량이지만 속도가 덜 중요할 때
• 스냅샷 설정 : 스토리지의 백업본을 만들어 데이터 복구가 필요할 때 활용할 수 있도록 하는 기능이다.

---

서버와 스토리지의 상호작용

• 서버는 VPC와 서브넷을 통해 네트워크에 연결된다. 서버에 연결된 네트워크 인터페이스가 서버의 IP주소를 할당받고 외부/내부와 통신이 가능하게 한다.
• 스토리지는 서버의 데이터를 저장하는 공간이다. 위와같이 특정한 디스크가 서버에 연결되고 리눅스 경로로 마운트되어 파일 시스템이 접근할 수 있게 된다.
• 작동과정
  1. 사용자가 애플리케이션을 통해 데이터를 서버에 요청하면, 이 요청을 네트워크를 통해 서버로 전달된다.
  2. 서버는 스토리지에 데이터를 저장하거나 읽어오는 작업을 수행한다.
  3. 데이터는 서버가 요청한 대로 처리되고, 응답은 다시 네트워크를 통해 사용자에게 전달된다.

스토리지 및 데이터 보안

• 민감한 데이터의 보안을 위해 스토리지 암호화를 활성화 할 수 있다.
• 반납 보호 : 반납 보호 설정이 해제되어 있는데 이는 서버를 실수로 삭제할 위험이 있다. 이 설정을 활성화하면 실수로 서버를 삭제하는 것을 방지할 수 있다.

3. 네트워크 구성

• VPC sopt-35-sever
  • 서버가 속한 독립적인 네트워크
• 서브넷 sopt-35-server | KR-1 | 192.168.0.0/28 | Public
  • VPC 내의 세분화된 네트워크로 IP 주소 범위가 제한되었다.
  • Public은 외부와의 연결이 가능하다는 뜻이다.
• 공인 IP 223.130.160.184
  • 외부에서 이 서버에 접근할 수 있는 IP 주소
• 비공인 IP 182.168.0.8
  • VCP 내에서만 접근 가능한 내부 IP 주소

---

• CIDR : 서브넷의 IP 주소
• NAT 게이트웨이 : 사설 IP를 사용하는 서버가 인터넷에 접근할 수 있도록 중계 역할을 하는 장치이다. NAT 게이트웨이를 통해 사설 서버가 외부인터넷에 요청을 보낼 수 있지만 외부에서는 직접적으로 서버에 접근할 수 없다.

---

VPC, Subnet, 공인IP와 비공인IP

• VPC는 서버가 속하는 가상 네트워크, 서브넷은 VPC를 작은 네트워크 구역으로 나누는 역할, 공인 IP는 외부 네트워크에서 서버로 접근할 수 있게 해주는 주소, 비공인IP는 내부 통신에만 사용된다.
• 작동과정
  1. 서버가 네트워크에 연결되면 VPC와 서브넷에서 비공인 IP가 할당된다.
  2. 외부 클라이언트가 서버에 접근하려면 공인 IP를 통해 네트워크 요청이 전달된다.
  3. VPC와 서브넷이 외부 접근을 허용하고, 설정된 보안 그룹 규칙을 통해 허용된 포트로만 접근할 수 있게 제한한다.

4. 보안 그룹 ACG 설정

• ACG
  • 각 서버에 대해 인바운드와 아웃바운드 규칙을 설정

---

네트워크 인터페이스와 보안그룹 ACG 작동

• 인바운드 규칙에서 HTTP와 HTTPS를 허용하고, SSH를 특정 IP에서만 허용하면, 웹 트래픽과 특정 IP의 SSH접근만 가능하게 된다.
• 아웃바운드 규칙에서는 특정 포트로 나가는 요청을 제어해 외부 서비스에 제한된 접근만 허용할 수 있다.
• 작동과정
  1. 외부 클라이언트가 서버의 공인 IP로 HTTP 요청을 보내면 네트워크 인터페이스가 이를 수신한다.
  2. 보안그룹의 인바운드 규칙이 요청을 검사하고, 허용된 포트로 온 요청만 서버로 전달한다.
  3. 서버가 요청을 처리하고 아웃바운드 규칙에 따라 외부로의 응답을 전송한다.

5. 모니터링

[CPU Used]

• 빌드했을때 아주 조금 CPU사용량이 증가함을 볼 수 있다.

[Memory Used]

• 메모리 사용량은 거의 일정한데, 이는 시스템이나 다른 기본 서비스들이 메모리를 사용하고 있을 가능성이 크다.

[Disk Write]

• 빌드 작업을 중지하면 디스크에 더이상 새로운 빌드 파일을 기록하지 않기 대문에 쓰기 작업이 줄어드는 것이 일반적이지만, 그래프에서의 급증은 다른 시스템 로그 기록이나 백업 작업, 혹은 자동으로 실행된 다른 프로그램에 의해 발생했을 가능성이 있다.
• 백그라운드 프로세스에서 로그 파일을 쓰거나, 기타 일회성 작업이 발생했을 때 이러한 변화가 일어날 수 있다.

[Networt in]

• 백그라운드에서 실행 중이던 애플리케이션이 외부 서버와 데이터를 주고 받았다면 , 해당 프로세스가 종료되면서 네트워크 크래픽이 감소할 수 있다.
• 빌드 작업을 할 때는 네트워크 크래픽이 크게 증가하지 않지만 빌드 중에 의존성 라이브러리를 다운로드하거나 외부 API 호출을 사용하면 네트워크 트래픽이 증가할 수 있다.

CORS

• CORS Cross-Origin Resource Sharing

  • 웹 브라우저가 한 도메인에서 실행 중인 웹 애플리케이션이 다른 도메인의 리소스에 접근할 수 있도록 허용하는 보안기능이다. CORS는 이러한 제한을 우회하여 서버가 혀용한 경우에 한해 특정 도메인 간 리소스 공유를 가능하게 한다. CORS 정책을 설정하려면 서버는 요청에 대해 허용할 도메인, 메서드, 헤더를 명시하여 응답 헤더에 추가해야 한다.

  • 웹 페이지에서 다른 사이트의 데이터를 가여올 때 허락을 받기 위한 규칙

  • 웹 보안을 강화하기 위해 CORS가 존재한다. 웹 애플리케이션은 다른 도메인의 리소스에 접근해야 할 때가 많기때문에 CORS는 서버가 명시적으로 허용한 경우에 한해서만 다른 도메인의 접근을 허용하도록 해준다.

    → 기본적인 보안을 유지하면서도 정상적인 데이터 공유를 가능하게 해주는 규칙

• 브라우저는 기본적으로 다른 도메인에 대한 요청을 차단해 데이터를 보호하려 한다. 따라서 서버에서 요청을 명시적으로 허용하지 않으면 브라우저가 해당 리소스를 차단한다. 이로써 의도치 않은 데이터 접근을 막을 수 있다.

• Postman에서는 서버의 CORS 설정에 관계없이 자유롭게 요청을 보낼 수 있다. API 테스트 툴은 웹 브라우저가 아니기 때문에 동일 출처 정책이 적용되지 않기 때문이다.

• 요청 유형

  • 단순 요청 : 메서드만 사용하고, 기본 헤더만 포함하는 요청. 브라우저는 바로 요청을 보내고, 서버가 Access-Control-Allow-Origin헤더로 허용 여부를 반환한다.
  • 사전 요청 : 단순 요청이 아닌 요청. 특정 헤더를 포함한 요청에 대해 OPTIONS 메서드를 통해 사전 요청을 보내 허용 여부 확인. 서버는 OPTIONS 요청에 대해 허용할 메서드, 헤더, 출처 등을 응답 헤더에 추가하여 CORS설정을 알려줌으로써 브라우저가 이후 실제 요청을 보내도록 한다.

• CORS 동작방식

  • 단순 요청
    • 브라우저가 서버에 단순 요청을 보낸다 → 서버가 허용하려면 리소스를 반환
  • 사전 요청
    1. 클라이언트가 OPTIONS 메서드를 통해 서버에 요청을 보낸 후 허용 여부 확인
    2. 서버는 응답에서 Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers와 같은 헤더로 허용 규칙을 설정
    3. 브라우저가 이 응답을 받아 허용된 경우에만 실제 요청을 보내도록 한다.

• CORS 정책 설정

  1. 서버에 응답 헤더 설정하기
     • 서버가 다른 도메인에서 요청을 받아들일 수 있도록 특정 HTTP 헤더를 응답에 추가한다.
     • 일반적으로 Access-Control-* 헤더를 사용하여 설정한다.
       • Access-Control-Allow-Origin : 어떤 도메인에서의 요청을 허용할지 말지 명시
         • Access-Control-Allow-Origin: https://sopt.com/이라면, https://sopt.com에서 온 요청만 허용한다. 모든 출처에서 요청을 허용하려면 *를 사용
       • Access-Control-Allow-Methods : 허용할 HTTP 메서드를 설정한다.
       • Access-Control-Allow-Headers : 요청에 포함될 수 있는 허용할 헤더를 명시
       • Access-Control-Allow-Credentials : 쿠키와 같은 자격 증명을 포함한 요청을 허용할지 여부 설정

• 스프링에서 CORS 사용방법

  • @crossorigin 애너테이션 사용하기
    • origins : 허용할 출처 지정
    • methods : 허용할 HTTP 메서드 지정
    • allowedHeaders : 요청에 포함될 수 있는 허용할 헤더 명시
    • allowCredentials : 자격증명을 포함할지 여부 설정
  • WebMvcConfigurer르르 사용한 전역 설정
    • 모든 컨트롤러에서 CORS를 설정하고 싶다면 인터페이스를 구현해 설정
  • application.properties파일에 설치