AWS – 세계에서 가장 머대리 클라우드

없었으면 더 좋았을 eksctl

eks는 사회악이다.
잘못 만들어진 툴은 없느니만 못하다
이딴게 있으면 다른게 만들어질 여지조차 막아버리니까

eksctl이 없으면 다른방향으로 de facto가 생겼을텐데

aws의 대부분이 널리 사용되고 기능많은 애매한 실패작이다
소니-애플로 이어지는 심플하고 쓰기좋은 제품군이 나오기 전의
복잡한 툴을 보는 느낌이다

오동작은 하지 않는다

클라우드의 아이폰은 뭘까

aws cli로 하면 될 것 같은데 애매하게 cloud formation을 만들어내는 eksctl 때문에 cli기능이나 다른 프로비저닝 툴이 활성화가 덜 됐다.

AWS의 대머리 메시지

You do not have permission to access the specified resource

eni를 지우려는데 이상한 소리를 하면서 안 지워진다

검색하다 보니 누구는 EB가 누구는 lambda가 남아있어서 그렇다고 한다.
lambda에서 생성한건 다른데서 삭제가 안된다고?

씨이발 그럼 어디어디 지워야할지 알려주던가
루트계정으로 들어갔는데 권한이 없다니

iam복잡하게 만들려다가 다 망쳐먹은듯

내 경우에는 rds가 생성 돼 있어서 삭제가 안됐었다

직접 구축하기 vs 돈내고 쓰기

이성적으로는 돈 내고 쓰면서 빠르게 개발하는게 낫다는걸 알지만
하나하나 구축하려는 욕심이 든다
적정기준을 정해놓고 따르는게 좋을 것 같은데

서비스 구축을 하면서 사용해야 하는 서비스가 몇가지 있는데

  • 인프라
    • 그냥 서버.. linux, unix, windwos ..
    • k8s cluster
    • object storage
    • cdn
  • DevOps
    • 빌드
    • 배포
  • Logging & 모니터링
    • 로그수집
    • 모니터링
    • 알림

구축하는데 들어가는 비용이 이익을 상회하지 않는 경우
비용: 시간, 돈, 인력
이익: 만족감, 기술발전, 속도, 돈

비교

인프라

IDC에 서버 올려서 직접 구축하면 제일 싸긴하다… 효율적으로 사용할 수 없다.
초기비용이 크고 서버 관리하는 기술도 생각보다 어렵고
경험이 없으면 삽질을 엄청 많이 하게 된다
코드만 만지던 사람들이 생각도 못한 변수가…

그리고 서버를 코드화 할 수 없으면 곤란한 상황이 많이 발생한다.
메이저 클라우드 업체를 쓰면 서버를 완전 코드화할 수 있다.

  • AWS
  • GCP
  • Azure
  • Heroku

서버만 쓸 수도 있지만 클러스터까지 쓸 수도 있고

  • k8s
  • ecs

네이버 클라우드 등 국내 서비스는 안됨. XXX

CDN, ObjectStorage는 클라우드플레어 등 다른 회사를 써도 되고 메이저 클라우드를 써도 되는데 다 코드화가 가능하다.
코드화가 가능하면 인프라 구축이 매우 쉬워진다.
SI도 아닌데 한번 구축하면 끝이지 왜 환경을 재현해야 하냐고???? 하는 경우가 있는데

  • CloudFlare

인프라 코드화의 장점

  • 테스트 환경 구축: production 환경에
  • 서비스 확장이 간편: 인프라 규모를 확장할 때 오류 가능성이 낮다.
  • 테스트 자동화가

DevOps

위에 있는거에서 DevOps는 코드화 해서 쉽게 할 수 있고
githubaction같은 무료서비스도 많으니 그냥 써도 된다. 서버를 직접구축하면 조금 더 빠르긴한데 취향에 따라 마음대로 해도 되는 부분…
아직 돈내고 써서 엄청 좋아지는 서비스가 없다

  • kustomize
  • gitops
  • githubaction
  • gitlabaction?
  • drone
  • argocd
  • keel

로깅 & 모니터링

hadoop, elastic search, prometheus 거의 이 중 한쪽 생태계와 주변기술 아닐까

구축하는게 튜토리얼대로 하면 금방 할 수 있기도 한데…
서비스에 맞게 튜닝을 하려면 신경쓸게 많다.
생각보다 잘 안되는 편

어떻게 보면 진짜 비핵심적인 부분이기도 해서
진짜 필요한 부분에서는 직접 로그를 DB에 저장하던지 하고
전체적으로는 돈내고 써야하는 분야

sentry, datadog, … 등등 검색하면 많다

클라우드에서 기본 제공해주는 서비스는 대부분 ES, Hadoop 기반이고
커스터마이징이 불편해서 별도로 작업이 많이 필요하다.

Synology NAS – 사용후기 – 누구에게도 필요없는 물건

신세계라고?

모르겠다
충동구매로 지른 후 몇달인가 1년쯤 됐나?
지금 설정 해 놓은게…

  • DNS
  • VPN
  • Cloud 백업
  • 디스크
  • 사진
  • 동영상
  • 다운로드
  • Docker
    • 블로그
    • gitlab
    • nexus
    • 등등 개발용툴

기존에는 개인서버에서 docker-compose로 실행시키면 별로 손가는 일도 없었다
오히려 코드화가 힘든 synology nas가 설정에 더 손이 많이 가는 느낌?
장점은 저전력에 크기가 작고 raid 지원이 잘 된다는 점 정도일까
요즘 폐급 메인보드도 소프트웨어raid 정도는 지원되고 raid0(mirror)은 컨트롤러 없어도 잘 터지지는 않으니까 상관없지 않나. 앵간한 폐급 피씨 주서다 셋팅해도 synology nas보다 빠르고

718이랑 하드두개 해서 거의 100만원을 쓴 것 같은데 왜 샀나 모르겠다. 그냥 미쳤나보다

비교

클라우드, NAS, 개인서버

솔직히 NAS도 관리하는게 손이 꽤 많이 가고 쉽지가 않다.
어차피 공부해서 할 생각이라면 개인서버 쓰는게 낫고
편하게 쓰려면 클라우드 쓰는게 낫다.

iCloud 기준
5G 무료
50G 1100원/월
200Gb 3300/월 (가족)
2TB 11,100/월 (가족)

GoPro Plus
무한용량?? $ 4.99/월

Dropbox
2TB $9.99/월

SynologyNAS 718+ 기준
45만 + 30만(4TB*2) + 램추가(8G 5만)
전기요금 누진세포함 대강 5천추가
수명3년으로 잡고 2.7 만/월
너무 비싸서….다시
수명5년으로 잡고 1.3 만/월

용량차이 좀 감안해도 NAS보단 클라우드 쓰는게 나아보인다.
자주 안 쓰는 데이터만 BlueRay나 HDD에 담아두면 기본요금만 써 되독

클라우드 쓰다가 날라가면 어쩌냐고 하기도 하는데
집에쓰는 하드도 잘 날라간다

클라우드는 비싸다고 하는데
100만원+전기요금 5천원추가정도 생각하면 큰 차이없지 않나

가용성도
드랍박스 중단되는거 뉴스에 뜨기도 하고 하지만
집에 인터넷 끊기거나 기계 고장나거나 정전나는건 뉴스에안나오지만 훨씬 자주 발생한다

tvheaden인가 뭐 이런거 쓰려면…
어차피 Synology nas 스펙이 구려서 힘들다

동영상을 온라인으로 올려놓고 보고싶다면
Synology 스펙구려서 힘들다
개인서버 돌리고 오픈소스로 나온거 설치해서 쓰는게 낫지 않을까
Dropbox나 iCloud에서 지원도 될 것 같다

파일공유
Nextcloud로 해도 된다

단점나열

  • 업데이트가 은근 느린 포인트가 많다
    letsencrypt 적용해야되는데 *.주소 지원이 아직도 안된다. 작년부터 계획중
    node4로 돌아가는 앱이 아직도 있네? package 업데이트가 안되서 생긴문제
  • 중요 기능은 ssh접속해서 해야된다
    개씨발포인트 – 디렉토리 구조나 권한설정도 지좆대로 되어 있는걸 건드리려니 더 힘들다
  • 기존서버운영방식을 모르면 Synology도 못한다
    쉽게따라하기 메뉴같은거 전혀 없다.. 어차피 이거나 저거나 공부하면서 해야됨
  • 저가형제품에서 할수있는게 없음
  • 전송속도 느림
  • 비슷한 유틸 엄청많아서 헷갈림
  • package를 직접 만들어 쓰려고 봐도 이거 손댈 수 있는 구조가 아니고 정보제공도 안됨

결론은

Synology에서 제공하는 다양한 기능을 사용하려면 쓰는것도 괜찮았었었었다
Docker가 나오기 전까지는
요즘은 그냥 버리는 서버에 NAS용하드 두개 사다가 레이드걸고 쓰는게 낫다.

복잡한 설정 못할 것 같으면 그냥 cloud서비스 iCloud, GoogleCloud, Dropbox, naverCloud, 통신사클라우드 대강 골라서 쓰면된다. 하드한개 사서 백업을 하던가 안해도 되고

이거 고장나거나 느려지면 다시 사진 않을 것 같다

Terraform – AWS 사용 후기

사용법은 매우 간단해서 몇 시간 삽질해보면 금방 익힐 수 있는 수준

그래도 tutorial은 필요해 보인다

  • install terraform
  • provider
  • terraform init
  • vpc, subnet, ec2, rds 작성
  • terraform plan
  • terraform apply
  • terraform destroy

세부적인 부분은 도큐먼트가 잘 나와있어서 검색하면서 추가하면 될 것 같다
https://www.terraform.io/docs/providers/aws

웹 콘솔을 켜놓고 확인하면서 돌려봤는데 의도한 대로 잘 만들어지는 편이다.

좀 힘들다 싶으면 기존 웹콘솔로 설정을 한 다음에 떠다가 써도 될 것 같다
https://github.com/dtan4/terraforming
cloud formation도 복잡한 설정은 이런식으로 하는게 편했는데

cloud formation을 사용하지 않고 로컬에 .tfstate파일에 서버 상태를 저장한다

이걸 git에 저장 해 놓고 관리해야 하는데

.tfstate를 ignore 하라고 돼 있다. 어째야하는거지?

상태값은 git에 올리지 말고 별도로 관리하라는건가?

서버에 상태값이 명확히 관리되지 않는다면 그리고 aws 콘솔에서 인프라를 수정해서 state파일과 값이 맞지 않게 되는경우 문제가 발생할 가능성이 있어 보인다.
이건 cloud formation에서도 마찬가지였지만

코드화를 하려면 격리수준을 잘 잡아놔야 할 것 같다.

vpc단계, 태그, organization 등등 여러 방법이 있겠지만…

Organization을 아예 서비스별로 분리해서관리하면 문제가 발생할 여지가 작아질 것 같다.
terraform destroy가 company destroy가 되지 않도록 하는 안전장치도 별도로 마련해야 할 것 같고

~~

CloudFormation은 Provider에 따라
* Mailgun
* AWS
* Docker
* Github
* Yandex
* Helm
* Trello
* Tumblr

별 쓸데없는것까지 다 할 수 있는 것 같다.
요즘엔 클라우드 엔지니어도 아닌데 인프라만 너무 만지는거 아닌가

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를 선택하면 된다.

클라우드

  • AWS
  • GCP
  • Azure
  • naver cloud
  • nhn toast cloud
  • kt cloud XXXXX
  • cloudv
  • digital ocean
  • heroku

호스팅

  • 통큰아이

코로케이션

  • cloudv 쿼터렉50만원인데 50%할인이라고써있음 할인해야 정상가격
  • 통신사(kt,lg,sk) Idc 직계약
  • 그냥 호스팅회사들 통해서 하는거 하나도안싼게특징
  • korea idc 쿼터렉 25만
    https://www.koreaidc.com/colocation/c-colocation.php
  • https://kdtidc.kr/wp/%ec%bd%94%eb%a1%9c%ec%bc%80%ec%9d%b4%ec%85%98
  • http://www.maruidc.com/colocation/rack_cost.html
  • http://www.coredata.co.kr/idc/colocation/package_cost.html
  • https://www.hostmeca.com/colocation.php
  • http://idc.viaweb.co.kr/coapp.php

결론은

없지만… 개인적으로는 그냥 로컬서버(집에다가) 두개정도 돌려놓고 개발 하다가 클라우드에 한두개정도 올리고… 클라우드 비용이 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 사용이 활발해질 것이다.

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