[Ncloud, AWS] aws밖에 모르던 클라우드린이의 Ncloud 적응기(Feat.. 클라우드에 대한 이해)

<24.04.02 작성중>

 1. 학습 계기

 취준생 시절, 개인/팀 프로젝트에서 매번 배포를 도맡으면서 AWS EC2, RDS, S3 등을 통한 배포에 어느새 적응해가던 내게, 좋은 기회로 외주 프로젝트의 기회가 찾아왔다. 당연하게 AWS로 배포를 시도하려던 내게 대표님께서 기존 외주 작업자들이 사용중이던 Ncloud를 통한 배포를 요청하셨다.

 두구둥.. 그렇다 세상에는 AWS사를 제외하고도 수많은 클라우드 사가 존재했고, 최근 몇 년 간 ncloud사의 적극적인 영업으로 ncloud의 클라우드 시스템을 사용하는 회사들이 많아지기 시작했다고 들었다.

2. 이번 학습으로 인한 기대 효과

사실 기존에는 AWS를 사용하고 있었지만 "클라우드"라는 것에 대해서 완벽히 이해하고 사용하고 있다는 느낌은 받을 수 없었다. 단순히 '이런 상황에서는 이 기능을 사용하는것이 좋다'정도의 이해에 그치지 않았기에, 이번 기회에 aws와는 다른 클라우드 플랫폼을 이용해보면서 보다 더 클라우드 서비스를 이해할 수 있으면 좋겠다는 기대가 되었다.

 

---

3. 기존에 사용하던 AWS 클라우드 기능

우선, 기존에 사용하고있던 AWS의 주된 기능들은 아래와 같았다.

1. Amazon EC2 (Amazon Elastic Compute Cloud)
   • 크기 조정이 가능한 컴퓨팅 파워를 클라우드에서 제공하는 웹 서비스.
   • 주로 서버를 올리고 실제로 어플리케이션을 구동할 때에 사용해왔다.
2. Amazon RDS(Amazon Relational Database Service) 
   • MySQL, PostgreSQL, MariaDB, Oracle BYOL 또는 SQL Server용 관리형 기반 관계형 데이터베이스 서비스.
   • 주로 Mysql, PostgreSQL을 띄워서 dev, 운영용 DB를 운용하는데에 사용해왔다.
3. Amazon Route 53
   • DNS(도메인 이름 시스템) 웹 서비스
   • 주로 도메인 이름을 AWS 인스턴스로 라우팅 하는데에 사용해왔다.
4. Amazon S3(Simple Storage Service)
   • 객체 스토리지 서비스
   • 주로 server에 올리기엔 자원이 아깝거나, 혹은 server를 변경하더라도 유지되어야하는 리소스들을 업로드 하는데에 사용해왔다.

---

4. 각각의 AWS 기능에 대응하는 Ncloud의 기능과, 마주한 이슈들

1. Server
   • 대응하는 AWS 서비스 : Amazon EC2 (Amazon Elastic Compute Cloud)
   • 낯선 클라우드에서 만난 이슈
     • ncloud는 ssh pemkey 로그인을 기본으로 제공하지 않으며,  root계정으로 바로 접속된다..?(5-1에서 자세히..)
     • SG(Security Group)가 ACG(Access Control Group)로 이름을 바꾸고 나타났다!
2. Cloud DB for MySQL
   • 대응하는 AWS 서비스 : Amazon RDS(Amazon Relational Database Service). 
   • 낯선 클라우드에서 만난 이슈
     • 콘솔 접속을 통한 DB Config 변경과, 인스턴스 내 DB 생성, User 설정이 막혀있다..?(5-2에서 자세히..)
3. Global DNS
   • 대응하는 AWS 서비스 : Amazon Route 53
4. Object Storage
   • 대응하는 AWS 서비스 : Amazon S3(Simple Storage Service)
   • 낯선 클라우드에서 만난 이슈
     • Ncloud를 이용하는데 aws sdk를 사용하라구요? (5-3에서 자세히..)
5. Cloud Insight
   • 대응하는 AWS 서비스 : Amazon CloudWatch
   • Amazon CloudWatch는 개인적으로 사용해본적이 없지만, 이번에는 "보안"과 과도한 요금 청구를 걱정하시는 클라이언트를 위해 모니터링 및 alert를 추가하였다.

---

5. Ncloud의 각 기능에서 만났던 이슈들과, 고민해보아야 할 것들

5-1) SERVER에서 만난 고민들

default 기능만으로는 pem key접속 불가 + 비밀번호 로그인시 root 계정으로 바로 로그인

aws에서와 달리 네이버클라우드에서는 default로 비밀번호를 통한 ssh로그인만을 허용하며, 심지어 비밀번호 로그인시 바로 root계정으로 로그인이 되어버리는 상황이었다.

 

물론, ncloud에서도 keypair를 통해 server에 로그인 하고, user계정으로 로그인을 하는 방법은 분명 있다.

추후에 ncloud를 또다시 이용하게 된다면, 아래의 이유들 때문에라도 해당 게시글 참고해서 user 계정을 분리하고자 한다.

• user계정이 아닌 root계정으로 바로 로그인이 됨으로써 발생 할 수 있는 문제가 있지 않을까?
  • 정말 최악의 경우에 비밀번호가 탈취되는 경우 모든 권한을 가진 root계정이 바로 노출된다는 치명적 보안 단점이 있을 것 같다.
  • 한명이 server를 관리하는 상황이라면 모를까 여러명이서 server를 운영하는 상황이라고 한다면, 누가 어느작업을 했는지 추적이 불가능하기에, 분명히 user계정을 나누고 각각 허용된 권한만들 가지는것이 맞다는 생각이 든다.
  • 사담으로, ssh의 config를 이용해 cloud server에 편리하게 로그인해오던 내게는 조금 불편한 상황이었다..!

공인 IP 발급 후 포트포워딩 필수

aws에서와 달리, ncloud에서는 서버 접속용 공인 IP가 필요한 이유는 무엇일까?

• zone에 대해 알아보고 클라우드 컴퓨팅의 구성 이해하기
• 설정하도록 되어있는 포트포워딩을 기반으로 흐름도 그려보기

 

5-2) Cloud DB for MySQL(RDB)에서 만난 고민들

 

• 콘솔 접속을 통한 DB Config와, 인스턴스 내 DB 생성, User 설정이 막혀있는 이유 고민해보기

5-3) Ncloud에서의 AWS(Feat…AWS S3 SDK 지원)에서 만난 고민들

• Ncloud에서 Object Storage를 사용할 때 AWS의 SDK와 AWS관련 Spring 기능들을 사용하는 이유
  • 초기 : 아직 독립적인 SDK를 구성하지 못한건 아닐까?
  • 현재 : 기존 AWS사용자의 Ncloud 도입을 보다 쉽게 하기 위해서일 수 있겠다.