Tag Archives: Cloud

서버 – 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 사용이 활발해질 것이다.

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