Monthly Archives: June 2017

Provisioning Tool

Chef
Vagrant
Puppet
Ansible

https://cloud.google.com/solutions/google-compute-engine-management-puppet-chef-salt-ansible

https://brunch.co.kr/@jiseon3169ubie/2

https://xebialabs.com/the-ultimate-devops-tool-chest/provisioning-config-management/

웹개발시 인프라 구성

다음과 같이 환경을 구성하고
여기에 맞춰서 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인스턴스 이외에는 항상동작

Ruby Version 관리 툴 – rvm.io rbenv

개요

rvm보다 가볍고 시스템에 영향을 주지 않는다(삭제하기쉽다)는 이유로 rbenv으로 루비 버전관리 툴의 대세가 넘어간 것 같다.

rvm

http://rvm.io 접속해서 스크립트로 설치

rbenv

설치는 좀 더 성가시다.
공식 주소 :
https://github.com/rbenv/rbenv
install명령을 쓰려면 이것도 깔아줘야한다 :
https://github.com/rbenv/ruby-build

ubuntu 17.04 desk

MSA서비스에서의 API

개요

MSA는 API를 이용해 통신을 한다.
그런데…. 의존성이 생기니까 관리가 힘들다.
버전관리가 필요.

버전관리 방법

동시배포

의존성이 있는 모든것을 동시배포
그냥 전체배포라고 보면 된다.
* 서비스가 작을 때 가능
* 오류가 나면 매우 난감함
* DB스키마가 변경됐을 가능성이 크기 때문에 rollback도 쉽지가 않다.

소스코드 내에서 버전을 관리

컨트롤러, 라우터 등등에서
/v1/
/v2/
이런방법으로 버전을 표시
* 버전업이 자주 발생하면?
* 헷갈리겠지

배포시 태깅

jenkins, git-tag, docker, kubernetes 등등 사용해서 해결할 수 있는 부분
해놓으면 편하긴 하겠지만… 구현자체가 복잡하다.

결론은…

어떻게 배포를 해도 오류가능성이 존재하겠지만… 관리가 쉬운편이 더 낫지 않을까
적절한 방법을 골라서 정책을 정하고 지키는게 중요.

MSA에 필요한 API Doc의 종류

Human – Machine

API Doc은 Hunam, Machine – 두가지 버전이 필요하다.

Human

swagger

Machine

Hataoes
그리고 json형태의 doc???
에러로깅 방식..??
등 지원

Versioning(API Change log doc)

  1. history
  2. plan
    1. deprecated 일정예고
  3. current
    세가지 정보를 모두 표현해야한다

검증테스트

build runtime 버전 check
의존성 api들을 모두 기록해놓는다.
depends on – (auth-1.1)
depends on – (gis-201610)
….
기록해놓은 부분은 내가 참조했 버전이 맞는지 버전만 호출해서 확인.
의존성이 있는 MS들의 test 인스턴스가 떠있거나
docker-compose, kubernetes 등으로 관리되고 있어야 가능한 부분.
아닌가.. 버전만 확인하니까 git 주소만 알아도 가능할 것 같다.

유닛테스트일수도 있는데 좀 더 강하게 빌드시 확인을 해야한다.

SSO(SingleSignOn) – Solution vs 직접개발

개요

요즘엔.. SSO 관련 개발은 거의 필수인데
막상개발하려면 여기저기 다 있는거 또 만드는 것 같은 생각이 들지만…
오픈소스나 뭐 갖다 쓰려고 하면 또 마땅한게 없다.

대안

OpenSource

JOSSO : 설치하면 실행된다. 쉽게 사용은 가능한데 커스터마이징도 쉬울까가 고민..
CAS : 코드가 매우 복잡.. 잘 이해가 안간다. 새로 만드는게 더 빠르지 않을까? 그냥 실행되는것도 아니라서 갖다쓰기도 편하지 않다.

상용Commercial

직접개발

관련기술

SAML : 삼를.. 잘 모르겠다.
http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/id_roles_providers_saml.html
OAuth : 오앗. 토큰받아다가 쓰는거. 많이 쓰니까 설명생략
GlobalCookie : 여러서버에서 동일한 네임의 쿠키를 바라본다. auth서버를 호출해야겠지
IP : 접속주소
MacAddress : 랜카드 주소기반
LDAP : 디렉토리 서비스 계층형으로 권한을 저장하는방식??/정도로 알고있는데..
Token : Stateless 호출에 사용. API에 많이 사용됨
등등…
다 지원되면 좋겠지만 다 하기는 힘들고 필요한것만 사용하는게 좋다.

~~~~~

위의 기술을 그대로 구현할수도 있고.. 유사하게 구현할수도 있고..라이브러리를 갖다쓸 수도 있고

이전에 쓸 때는 OAuth서버를 구현하고 OAuth(Like)방식으로 내부 SSO를 구현했는데…
좀 개선해보려면 어떻게 하는게 좋을지

API호출방법 – RESTful -> 멱등성Idempotent -> Stateless -> JWT

개요

멱등성 관련 : http://memo.polypia.net/archives/2505

  1. RESTful API를 쓰다보면
  2. 멱등성이 필요하고..
  3. 그러려면 Stateless 해야하고
  4. 그러기위해 JWT(JSON Web Token)를 지원하면 좋다.

JWT간략

JWT참고
http://bcho.tistory.com/999
https://jwt.io/
https://blog.outsider.ne.kr/1160

Claim기반 호출

HMAC을 이용한 보안
PPK필요

PPK(PublicPrivateKey)를 이용한 API인증

PlantUML Syntax:<br />
== authentication setting ==<br />
ResourceClient -> ResourceClient : when(deploy) generate ppk<br />
ResourceClient -> AuthDirector : send public key and target(ResourceProvider)<br />
AuthDirector -> ResourceProvider : push public key<br />
ResourceProvider -> AuthDirector : response success/fail<br />
AuthDirector -> ResourceClient : response success/fail</p>
<p>== call resource ==<br />
ResourceClient -> ResourceProvider : call resource with JWT<br />
ResourceProvider -> ResourceClient : response resource<br />

JWT을 적용해서 쓴다면 대략이정도 느낌이 되면 될것같다.
gradle, maven 테스트, 배포 타이밍에 적절한 조치가 필요할 것 같다.

local에서 할 때는 auth가 제역할을 못해줄 것 같으니

auth서버도 push를 하려면 ppk(auth-ppk)가 있어야하고 ResourceProvider은 auth-ppk(public key)를 가지고 있어야한다.

종이에 그릴땐 간단해보였는데 다시보니 좀 복잡해보인다. 좀 더 간소화 필요.

Hateoas – 왜 쓰는거지

개요

rest api 사용할 때 관련있는 api의 목록을 제공한다는 컨셉

참고 :
https://spring.io/understanding/HATEOAS
https://en.wikipedia.org/wiki/HATEOAS

그런데… 근본적으로 이해가 안간다.
보통 뭔가 기술적으로 정립된것들을 보면 나도 필요하다고 생각했던 경우가 많은데
이건 왜 스는건가 의아하다
이건 도큐먼트 아닌가
기계가 알아봐야하는 도큐먼트
generated doc의 일종이 되어야 할 것 같다.
/rest/api/user
/rest/doc/user
와 같은 관계가 되야하지 않을까

일단 비관적이고
뭔소린지는 알겠는데 공감이 가지 않는다.
안쓰겠다.

Load Balancing

개요

부하분산 방법

MSA
하드웨어방식 vs 소프트웨어 방식
예전에는 L4하드웨어방식만 썼는데 클라우드. 그리고 글로벌화되면서 상황이 좀 바뀌었다.

DNS

L$

L4
좋기야 하지.. 그런데 비싸다.
예전에는 많이 썼는데 요즘은??
클라우드에서도 L4를 지원해주긴하는데
속에서 몰래 소프트웨어방식으로 처리하는거 아닐까

Iptables

안해봤는데 될것같아

HaProxy

많이쓰는방법

ApacheHttpd – Proxy

Nginx – Proxy

restful 멱등성이 지원되도록 한다면

호출뻑할때가 많은데
멱등성이 필요할때가 많다.

unique조건. id값은 오차가 생길 수 있지만 unique를 활용하면 어느정도 처리할 수 있지 않을까

완전히 같을수는 없고
대신에 비슷한 요청이 올 때 update가 돼 버릴 수도 있다.

이게 상관없다면 이렇게 그냥 하는것도 괜찮지 않을까

상관없는 경우도 많으니

ajax호출이나 client에서 호출하는경우에 특히 중복호출이 많으니…

async로 한다면 더 심할 수 있다.

처리소요시간에 따라 적정 딜레이가 도움이 될 수도 있겠다.

cache처리하는것처럼 dynamic하게 관리되면 될 것 같다.

응답시간이 평균 5초정도라면 3초안에 중복요청은 무시해버리는식으로

사람이 많을때 서버성능을 향상시키는데도 도움이 될 것 같다.

설계는 다음에