Tag Archives: Cloud

IaC, Infra as Code – 인프라를 코드로 관리

클라우드로 넘어오면서 관심이 커진 분야

서버 프로비저닝 기술

  • Chef
  • Ansible
    클라이언트에 에이전트 설치 없이 원격으로 설치를 해 준다는 장점
  • Puppet
  • Saltstack
  • Packer
  • Groovy Infrastructure

요즘은 잘 안쓰는 설치 프로비저닝

SE를 안해봐서 모르겠지만.. 서버관리 하는 사람들은 이런거 USB 만들어서 들고다니지 않았을까
https://www.cyberciti.biz/tips/server-provisioning-software.html

  • Kickstart
  • FAI, Fully Automatic Installation
  • Cobbler
  • Spacewalk
  • OpenQRM
  • Foreman

클라우드 코드화(설정)

  • AWC Cloud Formation
    이건 그냥은 거의 못쓴다고 보면 된다
    AWS CDK를 활용
  • GCP – yaml
    따로 이름도 없는 것 같은데 구조가 잘 잡혀있어서 읽기 쉽고 재활용도 쉽다
  • Terraform
    클라우드 서버 인프라 뿐 아니라.. 여러가지 provider를 사용하면 github 설정도 코드화할 수 있다
  • 기타 ansible, chef 등에서 제공하는것들.. 플러그인 형태로 추가하면 되는 것 같은데 주류는 아닌 듯 싶다

클라우드 코드화(SDK)

  • AWS CDK
  • python boto
  • aws-sdk-rails

~

개인적으로 DSL형태의 설정을 좋아해서
Ruby계열 언어를 사용하는 프로그램이 많아지면 좋겠는데
대세는 yaml이나 파이썬 코드인 것 같다

서버 – Cloud vs IDC

그냥 다 귀찮으니 편하게 쓰고 싶다면 Cloud를 쓰는게 맞다. 서버 조그만거 껐다 켰다 하는 경우에는 Cloud가 가격도 싸고..
그런데 뭔가 조금만 무겁게 돌리려고 하면 Cloud의 GCP기준 2cpu 월3만원 4gb 서버는 좀 버거워 하는게 느껴진다.
Kubernetes가 자동으로 설치되고, Storage(s3, goosto..) 처럼 설치해서 관리하기 매우 난감한 솔루션도 종량제로이용 가능. minio, hdfs등을 설치해서 관리하려면 머리가 아프고 소규모로 쓰는데 이걸 설치하려면 골이 아프다.

서버2개정도로 빡빡하게 돌리려면 IDC
통큰아이 서버 중에 5만원~10만원 정도 하는거 두개쯤 쓰면 된다. 단기계약도 가능.

스케일업다운해가면서 테스트 할거면 Cloud

고정적으로 돌릴거면 IDC 코로케이션
http://www.koreaidc.com/03_colo/colo_type.html
액면가(협의가능) 쿼터렉(20Mbps) 25만, 하프렉(50Mbps) 60만, 풀렉(100Mbps) 110만
LG IDC
http://www.uplus.co.kr/biz/bzid/clct/RetrieveBzIdCoIt.hpi
부가포함 – 쿼터 44만, 하프 75.5만 풀 121만
네트워크나 기타 서비스 가격 차이가 있을 수 있다.
평촌IDC를 쓰면 AWS 다이렉트 연결도 가능.

하이브리드 사용을 하려면 AWS Direct 네트워크 연결이 되는 IDC를 선택하면 된다.

결론은

없지만… 개인적으로는 그냥 로컬서버(집에다가) 두개정도 돌려놓고 개발 하다가 클라우드에 한두개정도 올리고… 클라우드 비용이 100만원을 넘는 시점에 하이브리드 환경을 고려 해 보는게 좋지 않을까

요즘시대에 완전 온프레미스 환경을 구축하는건 좀 비효율적이라고 생각한다. s3와 같은 환경을 직접 구축하는건 … 필요해지는 순간이 오긴할까

서비스 베이스 프로젝트

뭔가 개발하려면 꼭 필요한 녀석들이 있다.
그리고 한번 개발 해 놓으면 계속 쓸 수도 있고
(나만그런가 싶기도 하지만)

Infra : DB, MQ, MemoryStorage, FileStorage

App : 파일저장, SSO

클라우드로 하면 되는데.. 왠지 클라우드를 쓰기 싫을 때도 있고

그럴 때 필요한 것들

FileStorage

하듭 파일시스템을 써야되나 고민했는데 아마존 S3처럼 쓸 수 있는게 있다고 한다.
minio https://www.minio.io/
https://github.com/minio/minio
fakes3 https://supso.org/projects/fake-s3
https://github.com/jubos/fake-s3

s3 기능을 많이 흉내내서 만들었다고 하는데 안정성은 잘 모르겠지만 남는피씨서버하드에 돌리기 좋아보인다.

MSA의 시대, 다시 주목받을 RPC

RPC : Remote Process Call 진영은

몇년째 딱 대표적인 기술이 떠오르지 않고 고만고만하게 유지되고 있다.

개인적으로 RPC가 더 편하다고 생각하는데, RestAPI가 너무 대세가 되서 인기를 잃어버려 아쉽다.

아니 먼 RestAPI 데이터를 브라우저로 봐서 뭐한다고?!?~!

지금당장 기억나는것은 이정도….

Thrift
Avro
gRPC
ProtocolBuffer
BSon

완전 RPC라고 하기는 좀 그런 시리얼라이징 기술도 넓게 보면 RPC아닐까…
아니 그냥 RPC인가? 그냥 다 포함시켰다.

아직까지는 연동 API 제공 한다고 하면 당연하다는 듯이 RestAPI를 제공한다.

API는 다양한 문제점을 가지고 있고 기술적으로 열등하기 때문에 점점 사용률이 낮아질거라고 본다.

표준기술로 사랑받아왔던 RestAPI의 문제점들

  • 무거운 http api만드는데 http를 돌리는데 코스트낭비가
  • 너무 자유로운 설계 json을 ?params=%XX%XX 형태로 받는 경우도 있고
  • http1 프로토콜에서 낭비되는 네트워크 리소스 http2로 사용하면 좀 더 낫긴하겠지만..

웹기반 기술에서는 계속 사용되겠지만 MicroService가 등장하며 내부 네트워크 부하가 더 심해지는판에.. 이걸 계속써야할까?

아니

여태까지는 아키텍처/UX까지 Request후 Response를 기다리는 형태로 설계가 되었으니 RestAPI를 써도 불편한줄을 몰랐다

async환경으로 변화는… 패러다임의 변화다. 설계까지 변경된다.

변화의 조짐은 보인다.

요즘 유행하는 기술 트렌드를 보면

MSA, Async, Functional Programming

이정도… 그리고 이런 트렌드가 지속/확대 된다고 봐도 될 것 같다.

왜냐? 작은조직의 효율적 개발, 클라우드환경, 늘어나는 네트워크 트래픽 등등의 상화을 봤을때 방향성이 그쪽을 향하고 있으니까…

새로운 트렌드는

MicroService사이의 통신을 위한 가벼운 프로토콜 + MQ(MessageQueue) 클러스터를 이용한 내부 통신채널 일원화 + Functional Programming을 통한 Async방식 개발

이 될 것이고

MQ를 이용한 Async프로그래밍을 도와주는 프레임워크이 등장하면서 RPC 사용이 활발해질 것이다.

이직후에 프레임워크 만들면서 쓸만해보이면 공개나 해볼까…