🌈 [Section4] 13. [Cloud] 운영 전략

📕 오늘 배운 내용!

• 프록시 서버
• 로드밸런서
• 오토스케일링
• TOMCAT
• JETTY
• NGINX
• VPC

---

✏️ 프록시 서버 (Proxy Server)

• 클라이언트가 서버와 소통할 때, 서버에 바로 접근하지 않고 자신을 통해 서버에 접근할 수 있도록 해주는 일종의 대리 서버

✔ 프록시 서버의 종류

[참고]

✔️ Forward Proxy

• 클라이언트 가까이에 위치한 프록시 서버
• 클라이언트를 대신해 서버에 요청 전달
• 주로 캐싱을 제공하는 경우가 많아 사용자가 빠른 서비스 이용을 할 수 있도록 도와줌
  
  
• 장점
  • 캐싱을 통해 빠른 서비스 이용 가능
    ➜ 클라이언트가 서버가 아닌 프록시 서버와 소통하면서,
    동일한 요청을 보내는 경우 첫 응답 결과를 캐시에 저장해놓고,
    이후에 재요청을 보내지 않아도 저장해 놓았던 결과로 빠르게 전달 가능
    
    
  • 보안
    ➜ 클라이언트의 요청이 프록시 서버를 거친 후 서버에 도착하기 때문에,
    서버에서 클라이언트의 IP 추적을 하면 프록시 서버의 IP가 전달됨
    ( 클라이언트의 IP를 숨겨 보안 가능 )

---

✔️ Reverse Proxy

• 서버 가까이에 위치한 프록시 서버
• 서버를 대신해서 클라이언트에 응답 제공
• 분산처리를 목적으로 하거나 보안을 위해 이용
  
  
• 장점
  • 분산처리
    ➜ 프록시 서버로 요청이 들어오면 여러대의 서버로 나누어 요청을 전달하기 때문에,
    서버의 부하를 분산 가능
    
    
  • 보안
    ➜ 서버의 응답을 프록시 서버를 거쳐 클라이언트에게 보내주기 때문에,
    클라이언트에서 서버의 IP 추적을 하면 프록시 서버의 IP가 전달됨
    ( 서버의 IP를 숨겨 보안 가능 )

---

✏️ 로드밸런서

( 하나의 서버에 너무 많거나 잦은 요청을 보낸다면 서버에는 과부하오는데, 이를 해결하기 위한 방법들임 )

✔️ Scale-Up

• 물리적으로 서버의 사양을 높이는 하드웨어적인 방법
• 반대로 서버의 사양을 낮추는 것은 Scale-Down
  
  
• 장점
  • 서버의 수를 늘리지 않고 프로그램 구현에 있어 변화가 필요없음
• 단점
  • 서버의 사양을 높이는데 굉장히 높은 비용
  • 하드웨어의 업그레이드엔 한계가 있음
  • 사양을 늘린만큼 클라이언트의 요청이 더 많아진다면, 서버에 발생하는 부하는 여전히 해결 X
    
    

✔️ Scale-Out

• 서버의 갯수를 늘려 하나의 서버에 줄 부하를 분산시키는 방법
  ➜ 많은 요청이 오더라도 여러대의 서버가 나눠서 처리
• 요청을 여러 서버에 나눠 처리해줄 수 있도록 교통정리 해주는 역할 필요
  ➜ 로드 밸런서 필요
• 반대로 서버 개수를 줄이는 것은 Scale-In
  
  
• 장점
  • 서버의 사양을 높이지 않고도 비교적 저렴한 방법으로 부하 처리 가능

💡 로드 밸런싱

• 여러 서버에 교통정리를 해주는 기술 or 프로그램

---

💡 로드 밸런서 종류

• L2
  ➜ 데이터 전송 계층에서 Mac 주소를 바탕으로 로드 밸런싱
  ⠀
• L3
  ➜ 네트워크 계층에서 IP 주소를 바탕으로 로드 밸런싱
  ⠀
• L4
  ➜ 전송 계층에서 IP주소와 Port를 바탕으로 로드 밸런싱
  ⠀
• L7
  ➜ 응용 계층에서 클라이언트의 요청을 바탕으로 로드 밸런싱
  Ex. 엔드포인트

---

✏️ 오토스케일링

• Scale-Out 방식으로 서버를 증설할 때, 자동으로 서버(리소스)를 관리해주는 기능
  ➜ 클라이언트의 요청이 많아져 서버의 처리 요구량이 증가하면 새 리소스를 자동으로 추가하고,
  반대로 처리 요구량이 줄어들면 리소스를 감소시켜 적절한 분산 환경을 만들어줌
  
  

✔ 장점

• 동적 스케일링
  ➜ 사용자의 요구 수준에 따라 리소스를 동적으로 스케일링 가능
  ➜ 스케일 업 할 수 있는 서버의 수 제한 X
  ( 필요한 경우 서버 두 대에서 수백 ~ 수만 대의 서버로 즉시 스케일 업 가능 )
  
  
• 로드 밸런싱
  ➜ 리소스를 동적으로 스케일 업 혹은 스케일 다운
  ➜ 로드 밸런서와 함께 사용하여,
  사용자가 정의한 규칙에 따라 워크로드 효과적으로 분배 / 관리 가능
  
  
• 타겟 트래킹 
  ➜ 사용자는 특정 타겟에 대해서만 Auto Scaling 가능
  ➜ 사용자가 설정한 타겟에 맞춰 EC2 인스턴스의 수 조정
  
  
• 헬스 체크 / 서버 플릿 관리
  ➜ EC2 인스턴스의 헬스 체크 상태를 모니터링 가능
  ( 모니터링 중, 특정 인스턴스의 문제가 감지되면, 자동으로 다른 인스턴스로 교체 )
  ➜ 적정 수준의 서버 플릿 용량을 유지하는 데도 도움
  ( 모니터링 중, 특정 인스턴스가 다운되면, 원래의 처리 용량을 유지하기 위해
  부족한 만큼의 서버를 추가로 실행시켜 서버 플릿 유지 )

💡 서버 플릿 (Fleet) (feat. AWS)
➜ 다수의 EC2 서버에서 애플리케이션을 호스팅 하는 경우에, 그 EC2 서버들의 집합

---

✔ EC2 Auto Scaling 활용

✔️ 시작 템플릿 (Launch Configuration)

• 인스턴스에 대한 모든 정보를 담고있음 ( 인스턴스 구성 템플릿 )

Ex. AMI 상세 정보, 인스턴스 타입, 키 페어, 시큐리티 그룹 등

• 시작 템플릿을 통해 어떤 서버를 사용할지 결정

💡 시작 구성
- EC2 Auto Scaling이 사용자를 위해 생성하는 EC2 인스턴스 유형을 지정한다는 점에서 시작 템플릿과 비슷

---

💡 시작 구성 vs 시작 템플릿
- 시작 템플릿
   - 수정 불가
   - But, 버전 관리가 가능하여 여러 템플릿 생성 가능

- 시작 구성
   - 한번 생성하면 변경 불가
   - 아예 다시 만들고 업데이트 해야함

[참고]

 

 

•  

✔️ Auto Scaling 그룹 생성

• 스케일 업 / 스케일 다운 규칙들의 모음
• EC2 인스턴스 시작부터 삭제까지의 모든 동작에 대한 규칙과 정책을 담고 있음
• Auto Scaling 그룹 생성을 위해 스케일링 정책 및 유형에 대해 잘 숙지해야함

✔️ Scaling 유형

• 인스턴스 레벨 유지
  • 기본 스케일링 계획
  • 항상 실행 상태를 유지하고자 하는 인스턴스의 수 지정 가능
  • 일정한 수의 인스턴스가 필요한 경우 최소, 최대 및 원하는 용량에 동일한 값 설정 가능
• 수동 스케일링
  • 기존 Auto Scaling 그룹의 크기를 수동 변경 가능
  • 사용자가 직접 (콘솔이나, API, CLI 등을 이용해) 수동으로 인스턴스를 추가/삭제 해야함
  • 해당 방식은 추천하지 않는 방식
• 일정별 스케일링
  • 예측 스케일링트래픽의 변화를 예측할 수 있고, 특정 시간대에 어느 정도의 트래픽이 증가하는지 패턴에 따라 규칙 추가하는 방식

Ex. 낮 시간대에는 트래픽이 최고치에 이르고 밤 시간대에는 트래픽이 거의 없다면,
낮 시간대에 서버를 증설하고 밤 시간대에 스케일 다운 하는 규칙 추가

• 동적 스케일링
  • 수요 변화에 대응하여 Auto Scaling 그룹의 용량을 조정하는 방법
  • CloudWatch가 모니터링 하는 지표를 추적하여 경보 상태일 때 수행할 스케일링 규칙 정함

Ex. CPU 처리 용량의 80% 수준까지 급등한 상태가 5분 이상 지속될 경우,
Auto Scaling이 작동돼 새 서버를 추가

• • 항상 스케일 업과 스케일 다운 두 가지의 정책 모두 작성해야 함

---

✏️ TOMCAT

• Apache사에서 개발한 서블릿 컨테이너만 있는 오픈소스 웹 애플리케이션 서버
  
  
• 자바 애플리케이션을 위한 대표적인 오픈소스 WAS(Web Application Server)
  ➜ 비용 부담 X
  
  
• 자바 서블릿 컨테이너에 대한 공식 구현체 ( Spring Boot의 내장 서버 )
  ➜ 별도의 설치 필요 X
  
  
• 독립적으로도 사용 가능 / Apache 같은 다른 웹 서버와 연동하여 함께 사용도 가능
  
  

💡 Tomcat 의존성

• • Intellij 내의 View > Tool Windows > Gradle > Dependencies 에서 확인 가능
    
    
    

---

✏️ Jetty

• 이클립스 재단의 HTTP 서버이자 자바 서블릿 컨테이너
  ( 웹 애플리케이션 서버 )
  
  
• Tomcat과 같이 자바 서블릿 컨테이너이자 서버로 사용 가능
  ➜ 개발자가 원하는 서버를 선택하여 프로젝트 구성 가능
  
  
• 2009년 이클립스 재단으로 이전하며 오픈소스 프로젝트로 개발됨
  타 웹 애플리케이션 대비 적은 메모리 사용
  ➜ 가볍고 빠름
  
  
• 애플리케이션에 내장 가능
  
  
• 경량 웹 애플리케이션
  ➜ 소형 장비, 소규모 프로그램에 더 적합

💡 Tomcat 대신 Jetty로 변경하는 법
➜ 아래와 같이 기본 서블릿 컨테이너인 Tomcat 의존성을 제외해주고,
Jetty 의존성을 추가 !

dependencies {
    implementation ('org.springframework.boot:spring-boot-starter-web') {
        exclude module: 'spring-boot-starter-tomcat' // tomcat 의존성 제외
    }
    implementation ('org.springframework.boot:spring-boot-starter-jetty') // jetty 의존성 추가
}

그리고 build를 진행하면 아래와 같이 변경된 걸 볼 수 있다 !

---

✏️ Nginx

• 가볍고 높은 성능을 보이는 오픈소스 웹 서버 소프트웨어

💡 Tomcat과 Jetty는 자바 서블릿 컨테이너 or 웹 애플리케이션 서버

• 클라이언트에게 정적 리소스를 빠르게 응답하기 위한 웹 서버로 사용 가능
• 트래픽이 많은 웹 사이트의 확장성을 위해 개발된 고성능 웹 서버
• 비동기 이벤트 기반
    ➜ 적은 자원으로 높은 성능 / 높은 동시성
• 다수의 클라이언트 연결을 효율적으로 처리 가능
• 클라이언트 - 서버 사이에 존재하는 리버스 프록시 서버로 사용 가능
• Nginx를 클라이언트와 서버 사이에 배치하여 무중단 배포 가능
• Nginx로 프록시 서버 구축 가능
  ➜ 클라이언트 - Nginx(80번 포트) - Spring Boot(8080번 포트)

---

✏️ VPC (Virtual Private Cloud)

• 클라우드 내 프라이빗 공간을 제공하여,
  클라우드를 Public과 Private 영역으로 논리적으로 분리할 수 있게하는 서비스
• 확장성
• 네트워크에 대한 완전한 통제권 가질 수 있음

✔ IP Address

( 이거 앞에 어딘가 블로그 작성한 거 있음 )

• 컴퓨터 네트워크에서 장치들이 서로를 인식하고 통신을 하기 위해서 사용하는 특수한 번호
• IPv4 / IPv6로 나뉘며 혼용하여 사용
• .으로 구분한 4개의 옥텟으로 이루어짐
  ➜ 각각 Network Address/Host Address/Host Address/Host Address

✔️ IP Address Class
- (이전에는) IPv4 주소에서 호스트가 연결되어 있는 특정 네트워크를 가리키는 8비트의 네트워크 영역(Network Address)과 해당 네트워크 내에서 호스트의 주소(Host Address)를 가리키는 나머지 영역을 구분하기 위해 클래스(Class) 사용

- A, B, C, D, E의 5개 클래스로 나뉨

( 궁금하면 더 찾아보기 )

---

✔ CIDR (Classless inter-domain routing)

• 클래스가 없는 도메인 간 라우팅 기법
• 1993년 도입되기 시작한 국제 표준의 IP주소 할당 방법
• IP Address Class 방식을 대체한 방식
• 원하는 블록만큼 Network Address를 지정하여 운용 가능
  ( 블록은 정해져 있음 - 검색해보기 )

Ex. 172.16.0.0 /16 이면,
여기서 /16은 첫 16bit를 Network Address로 사용한다는 의미
⠀
➜ 총 2^16인 65,536개의 IP주소를 사용할 수 있는 커다란 네트워크 블록을 이러한 방식으로 표시

---

✔ 서브넷 (Subnet)

• 서브네트워크(Subnetwork)의 줄임말
• IP 네트워크의 논리적인 하위 부분을 가리킴
• 서브넷을 통해 하나의 네트워크를 여러 개로 나눌 수 있음
• VPC의 CIDR 블록을 이용해 정의
  ( 최소 크기의 서브넷은 /28 )
• VCP를 사용하여 필요에 따라 다양한 서브넷을 생성 가능
  • 퍼블릭 서브넷
    ➜ 인터넷을 통해 연결 할 수 있는 서브넷
  • 프라이빗 서브넷
    ➜ 인터넷을 연결하지 않고, 보안을 유지하는 배타적인 서브넷
  • VPN only 서브넷
    ➜ 기업 데이터 센터와 VPC를 연결하는 서브넷
    
    

⚠️ 서브넷은 AZ당 최소 하나를 사용할 수 있고, 여러 개의 AZ에 연결되는 서브넷은 만들 수 X

💡 AWS가 확보한 서브넷 중 처음 네 개의 IP주소와 마지막 IP주소는 인터넷 네트워킹을 위해 예약되어있음 !

Ex. 10.0.0.0/24 체계의 CIDR 블록이 있는 서브넷에서 10.0.0.0, 10.0.0.1, 10.0.0.2, 10.0.0.3, 10.0.0.255 등 5개의 IP주소는 예약 되어 있음

---

✔ 라우팅 테이블 (Routing Table)

• 하나의 지점에서 또 다른 지점으로 가기 위한 모든 정보를 제공하기 위한 테이블

( 트래픽의 전송 방향을 결정하는 라우트와 관련된 규칙을 담은 테이블로 목적지를 향한 최적의 경로로 데이터 패킷을 전송하기 위한 모든 정보 담고 있음 )

• 모든 서브넷은 항상 라우팅 테이블을 가짐
  ( 하나의 라우팅 테이블 규칙을 여러 개의 서브넷에 연결하는 것도 가능 )

Ex. 특정 VPC의 서브넷이 라우팅 테이블에 인터넷 게이트웨이를 포함하고 있다면, 해당 서브넷은 인터넷 액세스 권한 / 정보를 가집

• 서브넷을 생성하고 별도의 라우팅 테이블을 생성하지 않으면
  클라우드가 자동으로 VPC의 메인 라우팅 테이블 연결함

✔️ 게이트웨이
➜ VPC와 인터넷 간 통신을 가능하게 하는 구성요소

---

😜 실습

✔️ Nginx 1개 서버 연결 실습

1. 이 링크에서 아래와 같이 윈도우용 Stable 버전 다운로드 !

( 나는 C:\Program Files\nginx-1.22.1 이 위치에 설치했다 ! )

2. nginx.exe을 실행하면 윈도우는 기본으로 80포트로 연결이 될 것 !
( localhost:80으로 접속하면 아래와 같은 화면이 나타남 )

3. nginx를 프록시 서버 역할로 만들기 위해 conf > nginx.conf 파일에
아래와 같이 80 포트를 프록시로 8080 포트까지 연결할 수 있도록 코드 수정 후 저장

server {
     listen       80;
...
     location / {
             ...
             proxy_pass http://localhost:8080; # 추가 - 요청을 8080 포트로 넘김
             proxy_set_header X-Real-IP $remote_addr; # 추가
             proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 추가
             proxy_set_header Host $http_host; # 추가
     }
}

 

4. cmd를 열어서 nginx -s reload 명령어로 재시작

5. 이후 localhost:80로 접속하면 아래와 같은 페이지가 나타남 !
( 아직 8080 포트가 실행중이 아니기 때문 )

6. intellij나 터미널로 프로젝트를 빌드 후 실행시킨 후 다시 localhost:80으로 들어가면,
아래와 같이 8080 포트로 실행시킨 프로젝트의 화면이 나타날 것 !

 

7. 'nginx -s stop` 명령어로 nignx 종료 가능

---

✔️ Nginx 2개 서버 연결 실습 (로드밸런서 사용)

[참고]

1. 한 프로젝트는 8080 포트 / 다른 하나의 프로젝트는 8081 프로젝트로 빌드 후 실행하고

2. 아까 설정한 부분을 주석으로 처리하고, 8080 포트와 8081 포트를 추가해줌

http {
 upstream backend { # 추가
     server localhost:8080; # 추가
     server localhost:8081; # 추가
 }
 location / {
     proxy_pass http://backend; # 추가 ( 아래는 주석으로 만들어줌 )
//          root    html;
//          index index.html index.htm;
//        proxy_pass http://localhost:8080; # 추가 - 요청을 8080 포트로 넘김
//          proxy_set_header X-Real-IP $remote_addr; # 추가
//          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 추가
//          proxy_set_header Host $http_host; # 추가
 }
}

3. 이후 다시 nginx재시작 하고 localhost:80으로 접속하여 새로고침을 누르면,
두 프로젝트의 화면이 번갈아 나오는 것을 확인할 수 있음 !!

---

🌈 느낀점

이번 학습은 그래도 어려움 없이 잘 끝냈고 !!
프록시 서버가 뭔지 감이 잘 안잡혔었는데 직접 눈으로 확인할 수 있어서 더 이해도 잘 됐고 재밌었다 ㅎㅎ

 

( 본 게시물은 2022/12/10에 작성한 글을 옮긴 글입니다. 원문은 요기에 있음! )

728x90