NCP 사용기

클라이밍 앱을 개발하게 된 계기는 기존 서비스에서 사용자가 느끼는 불편함을 해결하고자 했다.

• 클라이밍 관련 앱들에 개인에 맞게 영상을 편집하고 분류할 수 없어 사용자들이 불편함을 느낀다는 조사 결과가 있었다.

많은 시행착오가 있었지만 런칭 데이까지 개발을 완료하고 배포할 수 있었다.

클로그 앱 - App StoreApp Store

팀원들의 많은 수고로 완성된 클라이밍 앱 서비스이다.

디프만 16기 IOS의 서비스를 운영하기 위해서는.. 반드시 클라우드가 필요하다. (홈 서버가 없다ㅋㅋ)

이전에도 AWS에서 하고 싶은 걸 맘껏 하다가.. 자유분방한 결제 요금을 마주한 적이 있다.

하지만 디프만에서는 그럴 걱정이 없었다. 바로 Naver Cloud Platform 크레딧을 지원해준다.

NCP를 처음 사용해보기 때문에 서버를 운영하기 위해서는 최소한의 기능들을 파악해야 한다.

Container Registry

백엔드 개발자라면 docker를 대부분 사용할 것이다. NCP의 Container Registry는 프라이빗 도커 컨테이너 이미지 저장소이며 특징과 장점을 간단하게 알아보려고 한다.

특징

1. 컨테이너 이미지 관리:

• 도커 컨테이너 이미지 업로드(push), 다운로드(pull)이 가능하다.

1. Object Storage 연동:

• 컨테이너 이미지는 NCP의 Object Storage에 저장된다. (공짜는 아님)

1. public/private endpoint 제공

• public: 외부 인터넷에서 접근이 가능하다.

• private: NCP 내부 네트워크에서만 접근이 가능하다.

사용법

1. Object Storage 생성: Container Registry를 사용혀려면 먼저 Object Storage 버킷을 생성해야 한다.

2. Registry 생성: 레지스트리를 생성하고, 생성한 레지스트리와 Object Storage를 연동해야 한다.

3. Docker CLI 연동: 도커 CLI를 통해 Registry에 로그인할 수 있는데, API 인증키가 필요하다.

생성된 레지스트리를 확인하면 Configuration에 앞서 얘기한 Public/Private Endpoint가 존재한다.

우리 프로젝트는 Github Actions을 활용해서 배포 자동화를 구성할 것이기 때문에 Public Endpoint는 열어둬야 한다.

docker login access-command

접근 명령어를 입력하면 username:password를 입력해야 하는데, {API 인증 Key의 Key ID}:{API 인증 Key의 Scret Key}를 입력하면 된다.

• API 인증키는 마이페이지 -> 계정 관리 -> 인증키 관리 탭에서 확인할 수 있다.

장점

1. 이미지 관리

• Container Registry는 도커 이미지를 저장하고 관리할 수 있는 중앙 저장소 역할을 한다. 그래서 이미지를 업로드하거나 다운로드를 통해 배포 관리가 용이해진다.

1. 통합된 CI/CD

• Github Actions, Jenkins와 같은 도구와 통합하여 CI/CD 파이프라인과 같은 워크플로우 구성이 가능하다. (우리팀도 github actions로 쉽게 관리하고 있다.)

1. 운영 간소화

• 아무래도 제일 큰 강점이라고 생각한다. 자체 레지스트리를 구성할 필요 없이 클라우에서 제공하는 것을 이용만 하면 되기 때문에 복잡한 작업을 생략이 가능하다.

간단하게 정리해서, 만약 Docker를 사용한다면 Container Registry를 함께 사용하는 게 좋다. 그럼 이미지 저장이나 배포가 간편해지고 보안과 같은 부분도 신경 쓰지 않아도 된다. 특히 CI/CD를 구성한다면 안 쓰고는 못 배긴다.

Object Storage

NCP를 접하기 전, 먼저 AWS를 사용해서 객체 데이터(이미지, 파일,, etc)를 저장해 봤다면 쉽게 이해할 수 있다.

NCP의 Object Storage도 클라우드 기반의 객체 스토리지 서비스이다. 데이터를 객체 단위로 저장하는 대용량 스토리지라고 보면 된다. 위에서 언급한 Container Registry도 여기에 저장한다.

특징

1. 데이터 저장:

• 데이터를 GB 단위에서 최대 PB(페티바이트) 단위까지 저장 가능하며, 단일 파일 크기는 최대 10TB까지 지원한다.

1. S3 호환 API 제공

• 아마존 S3와 호환되는 RESTful API를 제공해서, 기존 S3 기반 응용 프로그램을 사용할 수 있다. (사용 안해봄.)

1. 권한과 접근

• 버킷(저장소)과 오브젝트(파일) 단위로 세부적인 권한 설정이 가능하고 공개/비공개 설정도 지원한다.

• ACL(Access Controll List)를 통해서 사용자별로 접근 권한 부여도 가능하다.

이 외에도 다양한 데이터 유형을 지원하고, HTTPS를 통해서 높은 수준의 보안도 제공한다고 한다.

사용법

사용법은 간단하다.

1. 버킷 생성:

• NCP에서 Object Storage 서비스를 활성화 후 버킷을 생성한다.

• 버킷 이름은 리전 내에서 유일해야 하고 생성 후 변경할 수 없다.

1. 파일 업로드/다운로드

• 최대 2GB 파일 업로드가 가능하며 API를 활용하면 5TB까지도 가능한 것 같다.

1. API 연동

• S3와 호환되는 API를 사용하려면 인증키를 발급 받아서 애플리케이션과 연동하면 된다.

장점

1. 확장성

• 저장 공간을 동적으로 확장 가능하기 때문에 필요에 따라 유연하게 대응이 가능하다.

1. 효율성

• 비정형 데이터를 효율적으로 저장할 수 있으며, NCP의 다른 서비스와 연계해서 사용이 가능하다.

• Data Life Cycle 관리로, 오래된 데이터는 아카이브 스토리지로 이동해서 비용 절감도 가능하다.

• 대량 데이터도 저렴한 비용으로 이용이 가능해 운영 비용을 줄일 수 있다.

1. 서버 부하 감소

• 파일을 외부 저장소에 직접 전송하므로, 서버에 가해지는 부하가 줄어든다. (가장 큰 장점이라고 생각한다.)

장점을 모두 작성한 것은 아니지만 이 정도만 놓고 봐도 그냥 사용하는 게 맞다고 생각한다.

Server

실제 애플리케이션을 구동해야 할 서버이다. 서버를 구성하기 전, NCP는 두 개의 플랫폼을 지원하는 것을 알아야 한다.

Platform(Classic vs VPC)

1. Classic 플랫폼

• 공유 네트워크를 사용하며 CSP(Cloud Service Provider)가 할당한 사설 IP를 기반으로 운영된다.

• 리전 간 사설 통신이 가능함.

• 네트워크를 세분화할 수 없어서 설정이 매우 간단하기 때문에 소규모 프로젝트에 적합하다고 한다.

• ACG(Access Control Group)을 통해 네트워크 접근을 제어하는 데, 서버 생성 시 ACG를 설정한다.

  • AWS를 이용해 봤다면 보안 그룹 정도로 이해하면 될 것같다. 이를 통해 네트워크 inbound 트래픽을 제어할 수 있다.

1. VPC 플랫폼

• public/private subnet으로 네트워크를 세분화해서 토폴로지 구성이 가능하다. (이런 면에서 보안이 좀 더 우수하지 않을까 한다.)

• 서버 인스턴스를 생성하기 전 VPC를 먼저 생성해야 한다.

VPC에 대한 이해가 있어야 각각의 플랫폼이 어떤 특성을 가지는지 더 쉽게 이해하겠지만, VPC까지 다룬다면 NCP 소개와 좀 멀어지는 느낌이 들어서 이 부분은 패스 한다... (나도 잘 모른다.)

결과적으로 우리 팀은 VPC를 선택했다. 팀원들이 모두 운영을 바라보고 있을뿐더러 실 사용자가 유치된다면 보안에 민감해야 할 텐데, 그러한 부분을 고려해 보면 보안이 더 우수한 VPC를 초기에 구축하는 것이 더 좋은 결정이라고 생각한다.

1. VPC 생성

위에서 말했듯, 서버 생성 시 VPC를 생성해야 하기 때문에 VPC를 먼저 생성해야 한다.

• Cloud Service -> VPC -> VPC Management에 들어가면 생성하기 버튼이 바로 보인다.

VPC 이름, IP 주소 범위, 유형을 선택해야 한다.

IP 범위는 사설 IP 주소 범위를 나타내며, 보통 0.0.0.0/20을 많이 사용한다고 한다.

유형은 NORMAL 그대로.

2. Subnet 생성

서브넷은 VPC 내에서 IP 주소 범위를 나누어 논리적으로 분리된 네트워크를 생성하는 단위이다.

크게 public/private subnet으로 나눌 수 있다.

• public subnet: Internet Gateway를 통해 외부 인터넷과 통신하는 네트워크

• private subnet: 외부 인터넷과 직접 연결되지 않고 내부 통신에서만 사용되는 네트워크

우리는 public/priavte 각 1개씩 서브넷을 구성했다. 이유는 다음과 같다. (2개 이상 만드는 이유)

• 민감한 데이터 혹은 내부 시스템은 외부 인터넷에 노출되지 않도록 private subnet에 배치하여 외부 연결을 제한하는 것이 좋다. (보안 강화)

• 개발, 프로덕션 환경이 따로 구성될 경우 다른 서브넷에 각각 배치하면 환경 간 간섭을 최소화할 수 있다. 또한 가용 영역이 다운되더라도 다른 영역에 직접적인 영향을 주지 않는다.

그래서 서브넷 구성 사례를 보면

1. public subnet: 웹 서버, API 게이트웨이와 같이 외부와 직접 통신하는 리소스를 배치

2. privagte subnet: DB 서버나 내부 애플리케이션 서버 등 민감한 리소스를 배치

이렇게 VPC에 서브넷을 2개 이상 구성하는 것은 보안, 네트워크 효율성 및 가용성을 높이는 데 도움이 된다.

그리고 최소한 하나의 public/private subnet을 구성하는 것이 best practice라고 하며, 이를 통해 안전하고 유연한 설계를 할 수 있다고 한다.

3. Network ACL

VPC를 생성하면 기본적으로 NACL(Network Access Control List)도 같이 생성된다.

ACL도 살짝 정리하면...

• Stateless 방식으로 작동하기 때문에, 인바운드 규칙에서 허용된 트래픽이라도 아웃바운드 규칙에서 명시적으로 허용되지 않으면 차단한다.

• 특정 서브넷에 적용되며, 해당 서브넷에 배포된 모든 인스턴스에 영향을 준다. 이를 통해 서브넷 단위로 보안 관리가 가능하다.

• 특정 IP 주소, 포트에 대해서 허용(Allow) 또는 거부(Deny) 규칙을 설정할 수 있다.

얼핏 보면 보안 그룹(Security Group)과 유사하지만 차이점을 보면...

특징	Network ACL	Security Group
적용 범위	서브넷 수준	인스턴스 수준
규칙 유형	허용 및 거부 규칙 지원	허용 규칙만 지원
Stateful/Stateless	Stateless (상태 기억 없음)	Stateful (상태 기억 있음)
우선순위	낮은 번호의 규칙부터 순서대로 평가	모든 규칙을 동시에 평가
사용 목적	서브넷 전체의 트래픽 제어	개별 인스턴스의 트래픽 제어

결과적으로 NACL 재구성의 필요성은 느끼지 못해서 default를 사용하기로 했다.

ACL을 subnet에 적용하는 과정은 다음과 같다.

• Subnet Management -> 생성된 subnet 클릭 -> Network ACL 변경 클릭

4. Server 인스턴스 생성

https://www.ncloud.com/product/compute/server#pricing

링크는 서버 스펙에 맞는 비용 정보이다.

우리는 어드민, 사용자 애플리케이션 서버가 분리되어 있고 추가적으로 Elastic도 사용해야 하기 때문에 s2-g3(vCPU 2EA, Memory 8GB)를 선택했다. (이것도 부족한 느낌.)

서버 인스턴스 생성은 크게 어렵지 않다. 서버 스펙, 이전에 생성한 VPC, OS, Storage를 선택하면 된다.

Summary

이 정도 정보만 알아도 NCP에서 서버를 구성하는 데 큰 어려움은 없을 것이라 생각한다.

최종 서버 아키텍처

나는 매우 거지이다.. 그래서 이렇게 구성하고 운영하려면 상당한 지출이 발생할 텐데 NCP의 후원으로 구성해 보고 싶은 것들로 마음껏 구성해 볼 수 있었다.

서버 구성에 날개를 달아준 NCP 후원에 진심으로 감사함을 느끼고 있다.