어서 와, 인프라는 처음이지?

1. ‘인프라’가 뭐죠?

현재 백엔드 개발자로 일하고 있으면서 이런 말 하긴 좀 창피하긴 한데…
솔직히 애플리케이션 밖에서 무슨 일이 일어나는지에 대해서는 잘 모릅니다. 🤨
그래서 이런 고민들을 자주 해봤는데요.

• 왜 리눅스 명령어들은 하나같이 외계어 같은지…
• 애플리케이션 성능이 안 나올 때 어디를 봐야 하는지…
• 잘나가는 IT 회사들은 어떻게 서비스를 운영하는지…

이런 고민들을 해결하기 위해서 눈여겨보던 교육 과정이 있었습니다.
바로 넥스트스텝에서 운영하는 ‘인프라 공방’ 인데요.
이번에 강의 개설 알림이 오자마자 바로 결제해서 모집 정원에 들어갈 수 있었습니다.
‘자바지기’ 박재성 대표님의 말씀으로는 ‘9분’만에 마감되었다고 하네요. 😱

이번 포스트에서는 1주차 1단계 미션을 진행하면서 얻은 경험들을 적어보려고 합니다.
원래 주 단위로 정리해보려고 했는데, 아무래도 내용이 길어지면 글의 퀄리티가 떨어질 것 같아서…는 개뿔🤦‍♂️

다만 아무래도 인프라에 대한 지식이 터무니없이 부족하다보니,
여기서는 실제로 미션을 진행하며 얻은 인사이트나 팁 등을 위주로 서술하며
네트워크 개념이나 원리 등에 대한 전문적인 내용은 깊게 다루지 않음을 말씀 드립니다.

이번 교육 과정에서 인프라에 대한 모든 걸 마스터한다기보다는
인프라가 무엇인지, 현업에서 실제로 어떻게 운영되는지를 대략적으로 경험해보고
앞으로 인프라에 대해 스스로 학습할 수 있는 기반을 만드는 과정으로 보시면 될 것 같습니다.

‘인프라’라는 단어를 들으면 가장 먼저 무슨 생각이 드시나요?
저는 가장 먼저 ‘인프라’를 누구보다 사랑하시는 대표적인 인물이 생각나는데요.

여윾씌 빽엔두 개발짜다...
지굼 보시믄 아시게찌마는, 헨재 우녕 중인 애프리케숀에스
에라가 난 위치를 증화키 찌버내는 메카니즈믄 솽당히 조크든요?
즈응말 모니트링 자래요.
제가 그듭 말씀드리지마는, 즈른 복짜판 로지게스
침차카게 에라 지저믈 차즐 수 잉는 개발짜가 그릏게 만치 안타...
그릏기 때무네 인뿌라가 중요흔 그에요.

아니 야구 말고 IT 인프라란, 애플리케이션을 운영하기 위해 필요한 하드웨어나 OS, 미들웨어, 네트워크 등 IT 서비스의 기반이 되는 시스템 및 구조를 말하는데요.
인프라 공방에서의 1주차 미션은 ‘그럴듯한 인프라’를 실제로 만들어보는 과정이었고,
그 중 1단계 미션은 바로 ‘통신망을 분리’해보는 것이었습니다.

2. 통신망 분리하기

얼마 전 금융감독원에서 망 분리 규제를 위반한 핀테크 기업들에 과태료를 부과했다는 뉴스가 있었죠. 그만큼 망 분리는 최근에, 특히 핀테크 업계에서는 핫한 이슈인데요.
이 망 분리를 AWS의 VPC(Virtual Private Cloud)를 통해 실습해봤습니다.
미션을 통해 구성해본 통신망의 대략적인 구조는 다음과 같은데요.

이게 다 뭔 소리래요? 🤯

인프라에 대해서 잘 아시거나 기존에 AWS를 사용해보신 분들이라면
이 용어들이 익숙하시거나 저보다 훨씬 더 잘 이해하고 계실거라 생각합니다.
저는 대부분의 용어분들과는 초면인지라 많이 어렵더라구요. 🥵
다행히 리뷰어분들과 구글신 덕분에 이번 망 구성 미션을 잘 마칠 수 있었는데요.
이번 미션을 통해서 얻은 통신망 구성 시 고려해야 할 주의사항과 팁은 다음과 같습니다.

(1) 서브넷을 구성할 땐 가용 영역을 나누어서 구성해라.

AWS에는 리전(Region)과 가용 영역(Availability Zone, AZ)이라는 개념이 있는데요.
리전이란, AWS가 서비스를 제공하는 지리적 위치🌏를 말하며
가용 영역이란, 하나의 리전 안에서 사용할 수 있는 데이터 센터의 그룹📱📱을 의미합니다.
우리는 가까운 대한민국 서울 리전의 가용 영역을 사용하면 되는데요.
서울 리전에는 2020년 7월 17일을 기점으로 4번째 가용 영역까지 추가되었습니다.

자 그럼 서울 리전에 VPC를 생성하면 끝이냐? 그럼 미션 제목이 ‘망 분리하기’가 아니죠.
이제 VPC 안에서 ‘서브넷’이라는 걸 생성하여 통신망을 나눕니다.
서브넷(Subnet)이란, 하나의 네트워크를 다시 작은 부분으로 나눈다는 건데요.
여기서는 생성한 VPC 안에서 사용 가능한 전체 IP 개수를 작은 그룹으로 나누는 겁니다.

그럼 왜 서브넷을 생성하는 걸까요?
여러가지 장점이 있는데 효율적인 IP 관리, 보안 성능 향상 등이 있습니다.
예를 들면 회사 내 부서마다 다른 IP 대역을 할당함으로써 네트워크 구성도를 더 효율적으로 관리할 수 있고, 특정 서버에는 특정 부서만 접근 가능하도록 보안을 구성하기에도 용이하죠.
이번 미션에서는 내부 네트워크를 통해서만 통신할 수 있는 내부망(private)과
외부 인터넷을 통해서도 통신할 수 있는 외부망(public)으로 구성하는 것이 목표입니다.

서브넷을 구성할 땐 가용 영역을 분리하세요 👨🏼‍🏫

그런데, 서브넷을 구성할 때 왜 가용 영역을 나눠야 할까요?
바로 다음을 고려해야 하기 때문입니다.

개인정보의 안전성 확보조치 기준 제11조(물리적 안전조치)

예를 들면, 현재 서울 리전에 사용할 수 있는 가용 영역은 네 곳이나 있는데
‘아마존 같은 대기업에서 관리하는데 뭐 별 일이야 있겠어?😌’라며 대수롭지 않게
가용 영역 중 ap-northeast-2a 한 곳에 서브넷 구성을 몰빵(?)했다고 가정해봅시다.
그런데 정말 만약에 천재지변⚡️🌪🌊이나 인재(人災)🔥가 발생하여 ap-northeast-2a 데이터 센터가 정전되거나 무너지게 된다면, 우리가 운영 중인 서비스도 운명을 같이 하겠죠? 😱
이런 혹시나 모르는 일에 대비하기 위해 가용 영역을 나눠서 구성하는 것이 안전합니다.

그럼 가용 영역을 나누긴 했는데, 데이터 센터들이 따닥따닥 붙어있진 않을테고…
물리적으로 떨어져 있는 가용 영역 간에 통신할 때 속도가 다소 지연되지 않을까요? 🤔

그건 AWS가 알아서 처리했으니 안심하라구! 🦝

위의 주의사항을 적용하여 실제 미션 수행 시 구성한 서브넷은 다음과 같습니다.

서브넷을 외부망(public-a, public-b)과 내부망(management, internal) 각각 2개씩 구성했는데,
각 망마다 가용 영역을 2a와 2b로 나누어서 구성한 걸 보실 수 있습니다.
하나의 가용 영역에 외부망과 내부망이 한 세트씩 존재한다고도 볼 수 있겠네요.
추가로 외부망에는 외부 인터넷과의 통신을 위해 인터넷 게이트웨이를 설정해주면 되겠죠.

실제 서비스 운영을 위해서가 아닌 단순히 하나의 미션을 진행하는 거지만
이런 부분부터 신경 써서 망을 분리하는 것이 얼마나 중요한지를 배울 수 있었습니다.

(2) 배스천 호스트를 구성하고, 여기에 보안을 집중해라.

배스천(Bastion)이란, 사전적 의미로 ‘요새’, ‘보루’를 뜻하는 단어인데요.
그림으로 보다시피 성 외곽을 적으로부터 효과적으로 방어하기 위한 수단입니다.
네트워크 보안에서도 이런 의미를 가져와서 보호된 네트워크에 접근하기 위해
유일하게 외부에 노출되는 호스트를 ‘배스천 호스트’라고 정의하고 있습니다.

우리가 운영 중인 리눅스 서버에 접속할 때 보통 SSH(Secure Shell) 22번 포트를 이용하잖아요?
그런데 우리의 중요한 서버들을 회사 내부가 아닌 외부 네트워크에서 22번 포트로 접속할 수 있게 되면 안 되겠죠?
그럼 운영 중인 모든 서버에 보안을 설정해놓으면 되지 않느냐고 물으실 수 있는데,
그러기엔 추후에 보안 정책을 하나 추가하기에도 모든 서버에 적용하기엔 비용이 많이 들고
관리해야 할 부분도 많아지는 단점이 있습니다.

하지만 배스천 호스트를 구성하여 여기에 보안을 집중하면, 배스천 호스트에 악성 루트킷이나 랜섬웨어 등으로 문제가 생겨도 배스천 호스트만 교체하면 되므로 유지보수가 용이합니다.
또한 내부 서버들로의 접근은 이 배스천 호스트를 통해서만 가능하도록 설정하기 때문에,
위에서 언급한 외부 네트워크로부터의 접근에 노출되지 않고 안전하게 보호될 수 있습니다.

하지만 물론 배스천 호스트에도 단점은 있습니다.
일단 귀찮죠😞. 운영 중인 서버 하나에 접속하기 위해 다른 서버를 거쳐야 하니까요.
그리고 만약 배스천 호스트가 공격을 당해서 함락됐을 때, 내부 네트워크에 존재하는 서버들의 안전 또한 보장할 수 없겠죠. 야 이 xxx 너만 믿고 가만히 있었는데 이제 어떻게 할 거야 🤬
그렇기 때문에 ‘난공불락’의 요새를 만들기 위해서, 여러가지 보안 강화 대책과 로깅 등을 통해 만반의 준비를 갖춰놓는 게 중요할 것입니다.

이번 실습에서는 배스천 호스트의 역할을 하는 EC2 인스턴스를 생성하고,
이 인스턴스를 통해서만 다른 EC2 인스턴스에 SSH로 접근할 수 있게끔 구성해봤는데요.
이 때 인스턴스로의 접근을 제한하기 위해 보안 그룹(Security Group)을 설정해야 합니다.

배스천 호스트 역할의 EC2 인스턴스 보안 그룹 설정

위의 그림을 보시면, 보안을 위해 가렸지만 현재 SSH 22번 포트로 접근할 수 있는 IP 주소를 단 하나만 설정해놨습니다. 나머지 IP 주소로는 배스천 인스턴스에 접근할 수 없다는 뜻입니다.
그리고 내부 서버로 사용할 EC2 인스턴스들의 보안 그룹 규칙에는 배스천 인스턴스에 적용한 보안 그룹을 설정하면 앞으로 배스천 인스턴스를 통해서만 SSH 접속이 가능하게 됩니다.

내부 EC2 인스턴스 보안 그룹 설정

보시다시피 내부 EC2 인스턴스의 보안 그룹 설정 시, SSH 22번 포트로 접근하기 위한 인바운드 규칙에 배스천 인스턴스의 보안 그룹을 적용하였습니다.
만약 배스천 인스턴스의 보안 그룹을 제외한 상태에서, 배스천 인스턴스에서 내부 인스턴스로 접근을 시도하면 어떻게 될까요?

‘Connection timed out’ 메시지와 함께 접속에 실패했네요. 😭
하지만 보안 그룹을 적용하고 다시 배스천 인스턴스에서 내부 인스턴스로 접근을 시도하면?

정상적으로 내부 인스턴스에 접속이 된 것을 확인할 수 있습니다. 😃
(물론 배스천 인스턴스에서 공개 키를 생성하여 내부 인스턴스에 추가해야 하는 작업 등이 필요합니다.)

3. 마치며

사실 실습하면서 더 많은 내용을 배우고 경험했지만, 너무 길어질 것 같아서 자세한 개념이나 내용은 따로 깊게 정리를 해볼까 합니다.

인프라 문외한이라 생소한 단어와 개념들이 너무 많이 나와서 이것저것 찾아보느라 헤매기도 하고 시간도 오래 걸렸지만, 다행히 저에겐 모르는 걸 물어봤을 때 바로바로 답해주실 수 있는 리뷰어분들이 계셔서 가능했던 일인 거 같아요. 이 자리를 빌어 다시 한 번 감사 드립니다.

앞으로 새로운 네트워크 통신망을 구성하게 된다면 이번에 배운 내용을 바탕으로 효율적이고 안전한 네트워크를 생성할 수 있을 것 같아서 뿌듯합니다.
다음에는 ‘2단계 - 배포하기’ 미션 후기로 찾아올 것 같네요.

잘못된 내용의 지적은 언제나 환영입니다.
긴 글 읽어주셔서 감사합니다.