직접 구축하기 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 기반이고
커스터마이징이 불편해서 별도로 작업이 많이 필요하다.

OpenWRT 커스텀펌웨어 라우터 – Linksys WRT3200ACM

목적

홈네트워크 구축
이라고 하지만… 그냥 iptime에서 해도 된다.
openwrt설치된 장비가 갖고 싶어서

구매

OpenWRT에 추천디바이스로 나와있어서 직구
https://www.linksys.com/us/support-product?pid=01t340000046sOsAAI
세금은 따로 없다. 전파인증을 따로 받아야 하는거라 국내판매는 당분간 힘들지 않을까
IPTIME에서 쓸만한게 있으면 사려고 했는데 없는 것 같다

설치

펌웨어 다운받아서 설치하면 끝
여기서 https://openwrt.org/toh/linksys/linksys_wrt3200acm
이걸 받아서 http://downloads.openwrt.org/releases/19.07.7/targets/mvebu/cortexa9/openwrt-19.07.7-mvebu-cortexa9-linksys_wrt3200acm-squashfs-factory.img
192.168.1.1로 접속
펌웨어 선택하고 설치… 경고는 무시
이렇게 쉬워도 되나?

설치된 후 바로는 뭔가 돌아가고 있어서 그런지 bad request오류가 지속적으로 발생한다
브라우저 캐시 제거하고 10분쯤 있다가 접속하니 잘 된다
무엇 때문에 해결된걸까
– 브라우저 캐시제거
– 10분쯤 있다가 접속

설정

라우터 스펙이 좀 좋다보니 할 수 있는게 많아서 할 게 많다

  • 라우터 비밀번호 설정
  • LAN 설정
  • USB 연결
  • Http Proxy
  • 내부 DNS
  • DDNS 연결
  • DHCP
  • VPN
  • Radius
  • Kerberos
  • 무선랜

라우터 비밀번호 설정

root / password

웹 인터페이스에서 비밀번호를 적당히 설정 해 준다.
비밀번호 설정을 안 해 주면 위에 경고가 계속 뜬다.

LAN 설정

Network – Interfaces – LAN – Edit

IPv4 address : 192.168.1.1이 기본인데 필요한 경우 192.168.0.1이라던가 바꾸고 싶은대로 변경.
Use custom DNS servers : kt는 168.126.63.1~2, 구글은 8.8.8.8, 4.4.4.4
로컬DNS가 있다면 주소를 잡아준다
OpenWRT에서 설정가능

USB 연결

내부 저장용량이 적어서 http캐시나 다른 일들을 시키려면 마운트를 해 줘야한다
https://openwrt.org/docs/guide-user/storage/usb-drives

Http Proxy

Software squid
usb에서 잡아준 mount 디렉토리로

내부 DNS

d

DDNS 연결

상용제품은 자기네가 지원 해 주는게 있는데 오픈소스다 보니 별도로 설정 해 줘야한다
돈안내고 쓰는 서비스 중에서 해킹위협이 없는 쪽으로

DHCP

d

VPN

OpenVPN, L2TP
https://openwrt.org/docs/guide-user/services/vpn/libreswan/openswanxl2tpvpn
d

Radius

dd

Kerberos

dd

무선랜

따로 잡아줘야 함

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

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

[도서] Chef Solo 입문 : 인프라스트럭처 자동화 프레임워크 – 뒤늦은 완독

기술서도 완독이라는 표현을 쓰나? 잘 안쓰는 것 같기도 하고..

클라우드가 나와서 일반 개발자가 직접 인프라를 운영해서 kubernetes, hadoop 등등 클러스터를 대규모로 운영할 일은 잘 없다보니.. 인기가 많이 식었지만

개발피씨, 개발서버, local vagrant 등을 설정할 때는 여전히 유용할 것 같다.

좀 사양기술이기도 하고 책도 옛날거라 예제도 다 오류나서 해서 안보려고 했는데, vagrant 개발환경 구성하다가 왠지 chef를 적용 해 보고 싶어서 다시 보기 시작했다.
보통은 docker를 쓰는데 이번엔 몇개 프로젝트 함께 돌리는거라 프로젝트별로 설정 해 놓은 docker를 쓰기는 좀 껄끄러운 상황…
아닌가? 그냥 vagrant를 쓰고 싶었다.

옛날버전이라 책으로는 개념만 익히고 웹튜토리얼이랑 도큐먼트쪽 명령어 찾아 보면서 공부할 수 밖에 없었는데 그러다 보니 시간이 많이 걸렸다.(이틀정도..)

chef 공부하기 힘든 이유가 몇 가지 있다

  • 개념이 뒤죽박죽… chef-solo chef-client –local-mode 비슷한게 섞여있고
  • 용어는 지맘대로.. 들어도 뭔지 모름 chef, kitchen, knife
  • 버전업하면서 legacy 다 바뀜

이런 난관을 넘고 vagrant 정도는 chef로 설정할 수 있게 되어 버렸다.ㅎ

이제 안쓸수가 없군.

추가로

Chef, 클라우드 서비스 설정관리 자동화 도구.

라는 책도 있는데 이건 되는게 더없고 개념이해도 더 힘들다.
두꺼운 책이 오류나니까 더 답도없다.
(책이 처음 쓰여질때는 오류가 아니었겠지 deprecated책이라)

절대 사서 보지 말기 바람.

Serverless Architcture 적용 – 기술조사

올해의 핫 키워드 서버리스 아키텍처

갑자기 떠올랐다고 해야되나.. 내가 갑자기 알게된건가

AWS서밋2018 가서 보고 이게 이렇게 핫한 기술이라는걸 알게 됐다.

컨테이너 기반 개발/배포에 어느정도 익숙해져 갈 즈음이라… 이게 왜 필요한지 잘 이해가 안 갔었달까
(뭐 그냥 로그수집 할 때나 쓰면 적당하겠군)

그런데 최근 파일업로드 서버를 만들다가 갑자기 생각이 들었다.

여기다가 쓰면 되는거구나…

한번 생각나고 나니까 여기저기 적용할만한 구석이 보이기 시작한다.

개발환경

테스트 없이 배포까지 한 번에 할 수 있는 사람이 있긴할까?

역시 테스트가 필수적이다. 실서버에 배포를 하면 시간도 오래 걸리고, 돈도 들고, 운영중인 서비스라면 서비스가 중단된다.

로컬에서 빠르게 코딩-테스트할 환경이 필요한데

AWS, GCP 모두 테스트 환경을 제공 해 주고 있다.

로컬에 설치해서 개발이 가능한 솔루션도 많이 있다. 집에다가 한개 설치 해 놓고 개발용으로 써도 될 것 같다.

서버리스 솔루션

https://github.com/kubeless/kubeless
https://fission.io/
https://www.openfaas.com/
https://openwhisk.apache.org/

FAAS

AWS는 다양한 언어를 제공 해 주고 있는 데 반해.
GCP는 아직 걸음마 단계… js만 사용가능하다.

kubernets 기반에 설치해서 사용이 가능한 fission도 있고
다른 서버리스 솔루션들을 kubernetes에 설치해서 써도 될 것 같지만….
그럴거면 그냥 컨테이너를 띄우지…

Serverless가 간편하다고 하지만.. SpringBoot나 다른기술들에 어느정도 익숙하다면 시간차이는 크지 않다.
AWS를 쓰면 구축 난이도가 좀 높은 API게이트웨이까지 사용할 수 있어서 더 좋을 것 같다.
AWS의존적인 시스템을 만들지 않으려고 했지만.. 이건 뭐 답이 없다. 그냥 의존적으로 가다가 문제가 생기면 빼는게 나을 것 같다.

로컬테스트는 이것저것 해보겠지만… 실 서비스는 AWS, API Gateway, DynamoDB/Aurora가 거의 확정.

웹개발시 인프라 구성

다음과 같이 환경을 구성하고
여기에 맞춰서 devops 구성을 하면 된다.

1. dev

개발환경
Vagrant, Docker등 활용해서 환경구성

1-1 dev-local

각자 DB, MQ 구동

1-2 dev-remote

동일 DB, MQ 구동

2. real

idc, cloud 환경

2-1 real-stage

product 배포전 테스트
확인 후 인스턴스 종료

2-2 real-product

product실제서버 batch인스턴스 이외에는 항상동작