인프라를 공부하기 전에

Public Cloud는 유명한 AWS(Amazon Web Service), GCP(Google Cloud Platform)처럼 클라우드로 제공해주는 서버를 의미해요.
Saas (Software-as-a-Service), On-Premise, Private Cloud 같은 용어들을 잘 모른다면, 아래 영상을 참고해주세요.

사물궁이 최고 👍( https://www.youtube.com/watch?v=CpPEJyWwIgY )

📌 왜 Public Cloud 를 사용하는걸까요, 뭐가 다르죠?

우선, 사용자 입장에선 우리집에 설치하든, 서버실에 직접 구성하든(On-premise), AWS(Public-cloud)로 만들던 아무 상관 없어요.

파일, 데이터베이스에 저장된 데이터를 안전하게 보관하며
원하는 형태로 서버에서 가공하여
사용자 또는 필요한 곳에 네트워크로 전달만 잘하면 됩니다.

문제는 시대가 발전하면서, 서버 인프라 구성이 점점 더 어렵고 복잡해진다는거죠.

📌 우리집에서 서버를 구성한다면

데이터는 어떻게 관리해야 할까요? :: 정전이 나거나 도둑이 든다면 어쩌죠, 보안적인 이슈나 백업은 어떻게 구성하죠?
서버는 어떻게 관리해야 할까요? :: 컴퓨터에 다른 프로그램을 설치해도 괜찮을까요, 장비가 망가지면 서비스도 중단해야할까요?
네트워크는 어떻게 관리해야 할까요? :: 장애가 발생했을 때 외부에서는 어떻게 접근할까요, 한번에 몇명이나 접속가능할까요?

📌 사무실에서 직접 서버실을 운영한다면

서버가 간단한 경우, 사무실에 두고 운영하는 방법도 있겠죠. 하지만 여전히 모든 문제가 해결되지는 않습니다.
전기세, 물리적인 장비 구매 및 관리, 네트워크 및 서버 관리 비용을 생각해보면 보통 Public Cloud가 훨씬 저렴한 경우도 많습니다.

데이터는 어떻게 관리해야 할까요? :: 다른 팀과 데이터, 코드, 파일은 어떻게 공유해야 할까요? 백업 구성은 어떻게 하죠?
서버는 어떻게 관리해야 할까요? :: 서버 장비관리, OS 설치는 누가하죠, 남는 장비나 서버 확장은 어떻게 처리해야할까요?
네트워크는 어떻게 관리해야 할까요? :: 사무실 서버가 공격받는다면 업무가 마비될까요? 네트워크 장비는 누가 관리할까요?

📌 데이터 센터를 활용한다면

그렇다면 업체가 제공해주는 데이터센터를 클라우드로 사용한다면 위의 문제들이 전부 해결되는걸까요? 당연히 아닐겁니다.

기술적인건 물론이고 보안이나 서버구성에 법적으로도 문제가 됩니다. 관리적/물리적인 안전조치를 따로 해야합니다.

아직 어떤 서비스를 만들지도 정하지 않았는데, 고려해야할 대상이 너무 많습니다. 저 수많은 요소들을 누가 구축하고 관리해야할까요?

📌 Public Cloud 를 사용한다는 것은

Public Cloud를 사용하는 이유는 바로 여기에 있습니다. 핵심은 관심사의 분리입니다.

클라우드를 사용한다는건 단순히 서버를 원격으로 관리한다는걸 의미하는게 아닙니다. 위의 문제들에 대한 관심사를 클라우드 업체에게 맡기고, 우리가 가진 리소스를 더 중요한 대상(ex 서비스)에 집중하는 것에 의의가 있습니다.

🍀 네트워크에 대한 이해

* 아래 설명은 AWS를 기준으로 설명합니다. 하지만 내부 원리를 이해하면 다른 클라우드를 사용하더라도 쉽게 적응할거에요.

대부분의 서비스는 네트워크를 통해 제공됩니다. 네트워크 상의 이슈는 서비스상의 심각한 문제를 만들 수 있어 대비가 필요합니다.
우리가 쓰는 네트워크는 OSI 7 Layer 를 표준으로 이용하여 구축되어있습니다. 이에 대해 잘 모른다면 아래 글을 참고해주세요.

2021.09.08 - [👀기본 지식/웹 기본지식] - 네트워크 OSI 7계층, TCP/IP 4계층

📌 통신망 (Network)

보통 3계층 IP로 식별할 수 있는 하나의 대상을 Node(= 장치)라고 부릅니다. 참고로 Node는 여러 곳에서 다양한 의미로 쓰여요.

이러한 노드들을 연결한 시스템을 통신망이라고 합니다. 즉, 하나의 서브넷(10.0.0.1/16)을 하나의 망이라고 칭할수도 있죠.

예를 들어 AWS에서는 [ 국가/지역(Region) ] - [ 데이터센터(Availablilty Zone) ]- [ VPC ] 단위로 통신망을 구분해 관리하고 있습니다.
참고로 통신망과 다른 통신망을 연결하는 것을 Peering이라 하고, AWS 에는 VPC Peering과 Transit Gateway 도구를 제공해줍니다.

VPC는 Virtual Private Cloud 란 의미로, AWS 에서 (논리적으로) 격리된 네트워크를 의미해요.

아래에 추가로 설명하겠지만, 논리적인 네트워크 망인 VPC 를 몇개로 나눠서 관리하는가는 회사 정책에 따라 정하기 나름이에요
인터넷에 접근 가능한 Was 망, 내부서비스만 이용하는 서브넷등 목적에 따라 여러 형태로 나눌 수 있습니다.
한번 정한 VPC를 확장하는건 절대 쉬운일이 아니기에, 보통은 VPC를 IP B-Class로 크게 잡은 뒤 서브넷으로 쪼개서 많이 사용합니다.

서비스가 복잡하지 않다면 하나의 VPC만 사용해서 구축하는 회사도 있어요.
결제비용 기준으로 VPC를 분리하는 방법도 있어요
계정, 서비스 기준으로 VPC를 나누는 방법도 있어요.

여담이지만, 네트워크 장비 성능만 좋다면 서브넷을 많이 나누더라도 느려지거나 하진 않습니다.

물론 서브넷 내의 IP 개수를 작게 잡는다면 VPC를 효율적으로 관리할 수 있겠지만, 요즘은 관리 도구들이 좋아져서 그럴 필요가 잘 없죠.

반대로 VPC나 서브넷을 너무 크게잡으면 관리하기 어렵기도하고, 특수한 경우가 아닌 이상 망을 많이 나누지 않는 추세이기도 합니다.
-> AWS 보안 그룹이 참조가 가능해서, 접근 제한을 유연하게 할 수 있거든요. 그래서 같은 목적(보안정책을) 가진 망을 AZ(데이터 센터) 내부에서 서브넷으로 나누는건 요즘은 별 의미가 없긴해요.

# 참고로 서버, 서브넷등을 이용해 만든 통신망의 구조를 Network Topology 라고 부릅니다. 토폴로지의 형태는 구성하기 나름이겠죠

AWS을 이용해 각 Node를 통신망(VPC)로 구분하여 네트워크 토폴로지를 구성한 모습

📌 망 분리의 필요성 (Network Isolation)

무식하게 물리적인 장비로 내부망(회사용), 외부망(인터넷)을 나누는 방법도 있지만, 네트워크를 이용한 논리적 망 분리도 가능합니다.

참고로 한국의 정보통신망법과 개인정보보호법에 따르면 망분리는 법적으로도 필수입니다. 실제로 2013년 3월 사이버테러 에 국내 방송사-대기업-제1금융권이 동시다발적으로 피해를 입었으나, 망분리가 이루어진 기업은 피해를 입지 않아 망분리의 중요성이 화두가 되었죠.

https://www.youtube.com/watch?v=YPSfR8QnKO0

📌 네트워크 통신은 어떻게 이루어지나요?

1973년에 TCP/IP가 도입되고 전세계가 인터넷으로 연결되었죠. 하지만 연결되었다고 내가 원하는 목적지를 한방에 찾아갈 수는 없습니다.
실제 서버에서는 스위치, 라우터 같은 네트워크 장비를 통해 목적지를 찾아 요청을 적절한 위치에 전달합니다.

2021.09.08 - [👀기본 지식/CS 기본지식] - 네트워크 L4, L7 로드밸런싱 (Load balancing)

2021.07.17 - [👀기본 지식/웹 기본지식] - HTTP #2 인터넷 네트워크의 이해

엄밀히 따지면 허브 OSI 1계층, 스위치는 OSI 2계층이긴 하지만, 요즘 장비들은 이것저것 다 지원하긴 합니다.

위 그림처럼 하나의 네트워크 도메인(주소)을 여러 PC가 사용하는 걸 다중접속환경(MA, Multiple Access)라 합니다.

3계층 라우터는 라우팅 테이블에 있는 Public IP를 이용하여, 외부 네트워크의 요청을 목적지(컴퓨터)까지 빠르게 연결시켜줍니다.
이 때, 아무런 장치없이 여러 장치가 하나의 Public IP를 공유해 사용하면 충돌(Collision Domain)이 발생해 통신이 불가능합니다.
어려운 말로, Half Duplex(송신, 수신 동시에 안됨 둘 중 하나만 가능)로 MA를 구성하면 Collision Domain이 일어난다고 표현해요.
1계층 허브를 사용하면, 하나의 신호를 여러개로 증폭 시킬 수는 있으나, 도메인(Public IP) 충돌을 막을 수는 없습니다.
2계층 스위치를 사용하면 신호 증폭과 함께 전송되는 Mac 주소를 확인해 Port 를 구분지어 충돌(Collision Domain)을 방지합니다.

AWS에서도 마찬가지로, 사용자가 직관적으로 알 수 있는 가상의 L2 Switch 와 Router 를 생성해서 서버를 구성합니다.

내부 네트워크간 통신은 가상의 L2 Switch를 이용합니다.
외부 네트워크, 또는 서로 다른 네트워크간 통신은 가상의 Router 를 이용합니다.

AWS 내부에 생성한 통신망(VPC)에서 외부와 네트워크를 연결하기 위해선, 인터넷 업체에서 제공하는 Public IP 대역이 필요합니다.
참고로 Private IP의 경우 내부망이니 아무 숫자나 사용해도 되지만, 192.168.x.x 처럼 표준에 정의된 권장 Private IP 대역이 존재합니다.

라우터는 내부에서 사용하는 Private IP가 목적지로 있는 경우, 라우팅 테이블에 정보가 없기 때문에 해당 요청을 Drop 합니다.
즉 외부와 통신하기 위해선 VPC 에서 오고가는 Public-Private 요청들을 적절하게 변환해주어야합니다.
이를 해주는 장치를 네트워크 변환 게이트웨이(Network Address Translation)라 하며, 줄여서 NAT Gateway 라고 부릅니다.
당연한 이야기지만, 외부의 요청을 변환해서 내부와 연결시켜주는 NAT Gateway 장비는 외부망에 존재해야 합니다.

참고로 모든 대역을 허용하고 싶다면, 0.0.0.0/0 (전체대역)으로 설정하면 됩니다.

📌 IP 클래스

최초의 IP는 [ 8비트의 네트워크 주소 / 나머지 호스트 주소 ] 로 사용했으나, 너무 비효율적이라 주소길이를 유동적으로 바꿉니다.

Network Address:그룹(네트워크 를 식별하기 위한)
Host Address: 개인(네트워크의 호스트 컴퓨터를 식별하기 위한 것)
보통 A Class 는 정부나 큰 기관이, B Class 는 중소기업이 많이 사용합니다.
C Class 는 누구나 사용할 수 있으며 D Class 는 멀티캐스트용(여러 IP 를 묶어 한번에 보낼 때), E Class는 사용이 불가합니다.

제일 앞에 고정된 주소를 이용해 각 클래스를 구분합니다. 이 시기에는 서브넷 마스크가 없었어요

첫 시작(=0 으로 채운 주소)은 네트워크 자체인 라우터 주소를 의미하고, 마지막(=1로 채운 주소)은 자기 자신인 루프백 주소를 의미합니다.

A클래스 ( 2^24 개 )
네트워크 주소 0.0.0.0 (00000000.00000000.00000000.00000000)
루프백 주소 127.255.255.255 (01111111.11111111.11111111.11111111)
B 클래스 ( 2^16개 )
네트워크 주소 128.0.0.0 (10000000.00000000.00000000.00000000)
루프백 주소 191.255.255.255 (10111111.11111111.11111111.11111111)
C 클래스 ( 2^8 개 )
네트워크 주소 192.0.0.0 (11000000.00000000.00000000.00000000)
루프백 주소 223.255.255.255 (11011111.11111111.11111111.11111111)

https://ko.wikipedia.org/wiki/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC_%ED%81%B4%EB%9E%98%EC%8A%A4

📌 CIDR 서브네팅 (Subneting)

인터넷이 발달함에 따라 B Class를 할당받는 사이트가 많아졌고, IPv4가 부족해져 1993년 IP Class는 CIDR로 대체되게 됩니다.
CIDR은 네트워크 주소 길이를 유동적으로 변경할 수 있으며 네트워크 길이를 표시한 서브넷 마스크값(255.255.255.0)으로 설정합니다.
클래스 구분이 없는 내부 도메인 라우팅, Classless Inter-Domain Routing(CIDR) 란 기존 IP 클래스의 기준을 따르지않고, 서브넷 마스크로 내부망을 여러 개(또는 반대로 하나로 합쳐)로 구분하는 방법을 의미합니다. 참고로 CIDR와 옛날 기존 클래스를 같이 사용하며, 기존 것들은 클래스가 있는 Classful 라우팅 방법이라고 부릅니다.

192.168.0.2(255.255.255.255) 이렇게 적어도 되지만, 가독성이 떨어지므로 보통 네트워크 주소의 길이를 표기해서(/32) 사용합니다.

255.255.255.128는 CIDR 표기법으로 /25 에요. 전체 IP를 2개의 서브넷으로 각각 128개씩 관리할 수 있죠.

Class (C,B,A)는 기존 IP 클래스 체계로 구분지었을 때 사용가능한 네트워크 주소 개수를 의미해요.

예를 들어 198.168.32.0 이 네트워크 주소이고, 32개의 호스트가 있다면 198.168.32.0 ~ 192.168.32.255

📌 AWS와 서브네팅

AWS에서는 [ 국가/지역(Region) ] - [ 데이터센터(Availablilty Zone) ]- [ VPC ] 단위로 통신망을 구분해 관리하고 있습니다.

하나의 VPC는 여러 개의 서브넷을 가질 수 있고, 각각의 서브넷은 VPC 주소의 CIDR 내에 구성할수 있습니다.

여기서 말하는 CIDR은, 위에서 설명한 서브넷 마스크(255.255.255.128, /25)를 사용해 내부에서 망을 쪼개 사용한다는걸 말하는거에요

VPC는 가상의 구분이라, 서브넷을 구성할 때 실제 위치인 AZ(Availablilty Zone)을 함께 설정할 수 있는데요, 재해 및 재난 대비 개인정보처리 시스템의 안전조치를 고려해서 서브넷의 AZ를 다르게 구성해야합니다. 물리적으로 다른 데이터센터에 있더라도 통신이 가능하도록 만들어놨거든요. 물론 통신속도가 조금 느려지지만, 요즘은 거의 무시할 수준이긴 해요.

설마 IDC에 자연재해가 일어나겠나 싶긴하지만, 2022년에도 SK C&C IDC센터 화재로 3만2천대의 서버가 꺼지면서 카카오의 모든서비스가 먹통되는 일이 있었죠. (물론 카카오가 그걸 몰랐을 리는 없고, 대형서비스이니 전체를 이중화 하지 못하는 다른 이유가 있었겠지만요.)

Quiz. 외부망대역(네트워크) 64개씩 서브넷 2개, 내부망 대역(호스트) 32개씩 서브넷 2개로 구성할 경우, 어떻게 CIDR 를 정해 서브네팅 해야할까요?

일단 VPC가 가진 IP 대역을 4개로 나눠 서브넷을 만들어야 합니다.

외부망으로 사용할 Subnet : 64개씩 2개 (AZ를 다르게 구성)
내부망으로 사용할 Subnet : 32개씩 1개
관리용으로 사용할 Subnet : 32개씩 1개
subnet은 private 2개와 public 2개에 대해 가용 영역(ap-northeast-2a, ap-northeast-2c)을 나누어 1개씩 생성
vpc를 192.168.99.0/24 로 만들면 cidr은 192.168.99.0 ~ 192.168.99.256 사이!
/26, /27 은 서브넷 마스크의 숫자. 26을 하면 64개(그 중 4개 + 1개는 자동 제외되어 59개 범위 중 하나의 IP가 할당 된다), 27을 하면 32개 이다. 첫번째 서브넷을 192.168.99.0/26 로 지정하게 된다면 그 다음은 192.168.99.65/26 와 같이 하나의 서브넷 마스크 숫자 갯수만큼 간격을 주어야 함

Tip) AWS VPC 설정 시, 아래와 같은 제약사항이 있어요.

VPC에서 제공하는 CIDR은 /16 ~ /28 사이에요

해당 주소의 5개는(0, 1, 2, 3, 255)는 AWS에서 자동으로 예약되어 사용할 수 없어요

CIDR 힌트

내가 만든 CIDR 주소의 IP 개수와 범위를 알고 싶다면, CIDR 계산기 사이트 또는 아래 표를 이용해서 쉽게 알 수 있어요

사이트로 계산해도 되지만, 사용하는 IP 대역까지 알 수 있는 아래 [ 서브넷 마스크(/CIDR) 표 ] 를 보면 조금 더 편하답니다.

x.x.x.x /25 (서브넷 마스크 11111111.11111111.11111111.10000000, 십진수로 255.255.255.128)
x.x.x.x /26 (서브넷 마스크 11111111.11111111.11111111.11000000, 십진수로 255.255.255.192)
X.x.x.x /27 (서브넷 마스크 11111111.11111111.11111111.11100000, 십진수로 255.255.255.224)
x.x.x.x /28 (서브넷 마스크 11111111.11111111.11111111.11110000, 십진수로 255.255.255.240)

예를 들어 서브넷 224(/27)을 사용하면, 한 서브넷당 32개의 IP를 가지고, 총 8개의 서브넷이 만들어져요.

64개 아이피를 가진 서브넷을 만든 이후, IP 32개 서브넷을 추가하고 싶다면 아래와 같이 192.168.0.64/27로 추가하면 됩니다.

정답 (==AWS 서브넷 생성방법)
Tip. SSH 접속시, 키 페어가 pem 확장자여야합니다. AWS에서 만들었다면 내용은 pem 인코딩이므로 확장자만 바꾸셔도 동작합니다.
ssh -i KEY-jiwondev.pem ubuntu@등록한퍼블릭아이피

VPC는 만들면 됩니다. 참고로 VPC 주소기준으로 서브넷 주소도 생성되는걸 잊지마세요.
서브넷 생성 방법
- VPC > 내가 생성한 VPC 선택
- 서브넷 이름 > jiwondev-subnet-public-1, jiwondev-subnet-public-2, jiwondev-subnet-private-1, jiwondev-subnet-private-2 와 같이 구분가는 이름으로
- 가용 영역 : public1, private1 > ap-northeast-2a, public2, private2 > ap-northeast-2c
- IPv4 CIDR 블록 : /26의 경우 64 간격, /27의 경우 32 간격으로 아이피를 적절히 배분(이미지를 참고하자) → 서브넷 생성 완료

다만 AZ만 2개로 나눴을 뿐, 아직 NAT 게이트웨이와 라우팅 테이블을 설정해주지 않았죠. 아직 외부망이 아니에요

Internet Gateway 연결 (외부망 -> VPC)

서버와 연결할 때 입구 역할
인터넷 게이트웨이 생성 방법
- 이름 태그 작성 > 생성된 게이트웨이를 클릭 > 우측 상단 '작업 -> VPC에 연결' 선택 > 내 vpc와 연결 > 연결 완료

Route Table 생성 (연결은 되었으나, 어디로 가야할지 모름 -> 요청 drop)

VPC, 인터넷 및 VPN 연결 내 서브넷 간에 패킷이 전달되는 방법을 지정
라우팅 테이블 생성 방법
- private 2개, public 1개 총 3개 생성
- 내 VPC 선택 > 생성 완료
생성한 라우팅 테이블 설정
- public 라우팅 테이블 선택 > 하단 라우팅 선택 > 라우팅 편집 클릭 > 라우팅 추가 > 대상 IP : 0.0.0.0/0, 대상 igw : 내 igw 선택
- 서브넷 연결 선택 > 명시적 서브넷 연결 > 서브넷 연결 편집 클릭 > 서브넷 클릭 > 생성한 서브넷 3개 클릭 > 연결 저장

NAT 게이트웨이 생성 (외부망 요청-> 내부망 주소로 변환)
- 옛날에는 EC2를 따로 하나 더 띄워 NAT 게이트웨이를 구성했었는데, 이제 AWS에서 쉽게 만들 수 있게 되었어요

private - public 간 연결
NAT 게이트웨이 생성 방법
- 이름 : mins99-nat-2a, mins99-nat-2c (각 리전에 대한 NAT 게이트웨이 이자 public 서브넷에 대한 NAT)
- 연결 유형 : public
- 탄력적 IP 할당 ID > 우측 탄력적 IP 할당 클릭 → NAT 게이트웨이 생성 완료
- 생성 완료 후 라우팅 테이블 메뉴에서 각 private 라우팅 테이블에 대해 라우팅을 추가

그림으로 보면 외부망에서 접속한 후, 외부망에 있는 NAT 게이트웨이를 통해 내부망으로 전달되는 모양이에요.
당연한거지만 내부망에 연결된 라우팅 테이블에서, NAT Gateway에서 오는 모든 인바운드 요청을 허용하도록 해야 됩니다

Security Group 설정 (요즘은 ACL, Access Controll list는 잘 사용하지 않아요)

외부망(public)
- 전체 대역 : 8080 / 80 / 443 포트 오픈(서버에서 실행하는 모듈의 포트 or nginx 포트에 맞춰서 설정)
- 관리망 : 22번 포트 오픈
내부망(private)
- 외부망 : 3306 포트 오픈
- 관리망 : 22번 포트 오픈
관리망(bastion)
- 자신의 공인 IP : 22번 포트 오픈

서버 생성

외부망에 웹 서비스용도의 EC2 2개 생성
내부망에 데이터베이스용도의 EC2 1개 생성
관리망에 bastion 서버용도의 EC2 1개 생성

도메인 생성

https://내도메인.한국/

'☁️서버 인프라' 카테고리의 다른 글

AWS (0)	2023.08.20

블로그의 정보

JiwonDev

인프라를 공부하기 전에

📚 참고서

🎯 목표