회사마다 db를 살리기 위한, 또 잘 활용하기 위한
여러가지 방법들을 활용하고 있다.

db를 실시간으로 따라가는 slave db를 두는 것은 물론이고,
3시간 마다 스냅샷을 찍고, 필요한 데이터쿼리를 해보기 위한 db를 따로 두는 등 기존에 쌓여진 데이터를 잘 활용하는 것도 너무나도 중요하고 기존의 데이터를 지키는 것도 너무나도 중요하다.

db를 실시간으로 따라가는 것은
mysql replication 설정으로 가능하다.

하지만 해당 부분이 깨지게 되면 굉장히 귀찮게 체크해줘야할 부분이 많다.
이미 설정되어 있다는 가정하에 체크해볼 것을 체크해보자.

master db 현재 설정된 replication 확인

  • mysql 접속
  • show processlist\G
  • => 현재 replication된 정보들을 볼 수 있음

slave db 접속

  • mysql 접속
  • show slave status\G
  • => 현재 master를 따라가고 있는 replication의 상태를 볼 수 있음
  • 여기서 보이는 에러 로그를 확인하고 google에 검색하여 해결

여기서 에러 로그가 보인다면 해결이 필요

=> 이런 에러를 접하게 되었다.

[해결 방법]

Relay log를 읽어오는 과정에서 오류가 있었던 것으로 보아 현재 slave 에 생성된 Relay log 파일이 깨진것으로 보임. 그렇기에 relay log를 master로 부터 다시 읽어오면 됨. 

참고 블로그:
[황제펭귄의 IT](http://egloos.zum.com/darkit/v/215603)

오잉 근데 우리 시스템에는 
MASTER_AUTO_POSITION is active 
때문에 따로 change master 경로를 변경하는게 불가하였다.

결국 reset slave를 해준 뒤 문제 있던 부분을 바꿔주려고 했으나
그냥 start slave를 해주면서 해결되었다!

mysql> stop slave;
mysql> reset slave;
mysql> start slave;

참고 하였던 좋은 블로그 글들을 공유하면서 총총
[[MySQL] MySQL Replication 구성하기](https://gangnam-americano.tistory.com/12)

'서버' 카테고리의 다른 글

Error: Unknown command: cask 에러를 만났을 때  (3) 2021.03.13
Graphql이란  (0) 2020.09.26
nslookup 이란  (0) 2020.08.31
초보자를 위한 REST API  (0) 2020.06.21
Docker란(도커란)  (0) 2020.06.02

brew를 통해 자바 개발 킷을 설치하는 도중
아래와 같은 에러를 만났다.

terminal에서 
brew cask install adoptopenjdk8 명령어를 입력했는데
Error: Unknown command: cask 와 같은 에러가 나왔다.

구글링 해본 결과 사용방법이 변경되었다고 한다.

brew install --cask adoptopenjdk8 로 변경해서 입력하면 잘 해결된다.

관련 스택오브플로우

stackoverflow.com/questions/30413621/homebrew-cask-option-not-recognized

 

Homebrew cask option not recognized?

I am following an online resource for installing two Mac utilities http://www.economyofeffort.com/2014/08/11/beyond-ctrl-remap-make-that-caps-lock-key-useful/ Here is the pertinent section: Instal...

stackoverflow.com

 

'서버' 카테고리의 다른 글

mysql replication 설정  (0) 2021.09.08
Graphql이란  (0) 2020.09.26
nslookup 이란  (0) 2020.08.31
초보자를 위한 REST API  (0) 2020.06.21
Docker란(도커란)  (0) 2020.06.02

기본적 정의 : 

GraphQL은 페이스북에서 만든 데이터 질의어이며, 'gql'이라고 한다. gql은 서버에 작성된 쿼리를 통해 데이터를 조회하는 방식이 아니라, 클라이언트에서 쿼리를 작성하여 필요한 데이터만 조회하는 방식을 제공한다. 또한, 하나의 EndPoint를 가지기 때문에 개발 규모에 따라 EndPoint의 복잡도가 증가하는 REST API보다 개발이 간편하다. 여러 데이터 집합에서 데이터를 조회하는 경우 gql은 하나의 쿼리로 조회가 가능하지만, REST API는 Request를 여러번 시도해야 한다. REST API도 한번의 Request로 처리가 가능하지만, 매번 여러개의 데이터 집합을 조회하기 때문에 자원의 낭비를 초래한다.

 GraphQL은 데이터의 구조를 정의하는 스키마(Schema)와 데이터 조회를 위한 쿼리(Query), 데이터 위한 뮤테이션(Mutation), 조회 결과에 대한 구현을 위한 리졸버(Resolver)로 구성되며, 이 외에 API명세서의 기능을 하는 인스로펙션(Instropection)으로 구성된다.

 

혼자서 공부하며 내린 정의 :

기존 rest api에서 발생하는 문제는  크게 2가지 였습니다.

overfetch와 underfetch

그 중 overfetch는

user의 정보를 요청하는 api를 보냈을 때, 내가 필요한 정보보다 훨씬 많은 정보들이 넘어오는 것이었습니다.

보통 프론트에서는 현재 user의 name만 필요로 하겠지만, 보통 rest api에서 고객 정보를 요청하면 해당 고객의 모든 정보를  보내주도록 구현되어 있어서, 더 많은 리소스 낭비로 이어졌습니다.

그리고 underfetch의 경우, 

만약 고객의 장바구니 정보, 혹시 좋아요한 물품 정보를 모두 함께 보고 싶다고 했을 경우,

user/cart/ 뿐만 아니라 user/wish/ 등 여러가지 api를 요청해야 하는 이슈가 있습니다. 무엇보다 중요한 것은 이게 점점 서비스의 규모가 커져감에 따라서 관리해야 하는 endpoint들이 기하급수적으로 늘어날 수 있다는 것입니다. 이는 개발자나 클라이언트에게 부담이 될 수 있습니다.

 

GRAPHQL은 위에서 설명한 것처럼 REST API의 한계를 극복하기 위해 나왔습니다.

endpoint는 통상 1개만 생성하고, 클라이언트에서 필요한 데이터는 클라이언트에서 직접 쿼리를 작성하여 호출 반환하도록 합니다.

 

위의 overfetch문제를 graphql에서는 간단하게 해결 가능합니다.

query {

    user(id:1){

        name

    }

}



{

    "data" : {

        "user":{

            "name" : 'byeonguk'

        }

    }

위의 underfetch 문제도 graphql에서는 간단하게 해결 가능합니다.

query {

    user(id:1){

        name

        cart {

            product_name,

            product_price

        }

        wish {

            product_name,

            product_price

        }

    }

와 같이 해결 할 수 있습니다.

 

물론 장단점이 있습니다.

 

장점으로는

  • 클라이언트가 필요한 데이터만 반환할 수 있고

  • 1번의 호출로 원하는 데이터를 한번에 가져올 수 있습니다. (REST API의 N+1 problem을 해결할 수 있습니다.)

  • 확장이 용이합니다.

 

단점은

  • 러닝커브

  • 캐싱 기능 구현이 어려움( 대부분의 언어에서 라이브러리로 직접 구현)

 

'서버' 카테고리의 다른 글

mysql replication 설정  (0) 2021.09.08
Error: Unknown command: cask 에러를 만났을 때  (3) 2021.03.13
nslookup 이란  (0) 2020.08.31
초보자를 위한 REST API  (0) 2020.06.21
Docker란(도커란)  (0) 2020.06.02

nslookup은 

Name server lookup의 약자로서

 

DNS 서버로 부터 여러 가지 정보를 얻을 수 있는 명령어 이다.

호스트 이름으로 부터 IP주소를 얻어낼 수 있다.

 

도메인 네임서버는 IANA(IANA(Internet Assigned Numbers Authority)는 인터넷 할당 번호 관리기관의 약자로 IP 주소최상위 도메인 등을 관리하는 단체이다. 현재 ICANN이 관리하고 있다. 처음에는 서던캘리포니아 대학교 정보 과학 학회의 존 퍼스텔이 서던캘리포니아 대학교 정보 과학 학회와 미국 국방부 간에 맺어진 계약 아래 관리했으며, 퍼스텔은 미국 상무부 계약으로 ICANN이 설립 될 때까지 이 업무를 수행했다.)

라는 곳에서 실제 도메인 주소를 가지고 오나 

이러한 요청을 계속 주게 되면 네트워크상에 부하가 가중되기 때문에,

한 번 가져온 주소는 DNS server에 저장하고

호스트의 요청시 그 안에 정보를 가지고 온 후 반환해준다.

 

test

 

 

궁금증 : 

그럼 해당 Address로도 접근이 가능해야 하는데 왜 접근이 불가능할까?

=> 원래는 접근 가능해야 하나, 요즘은 보안상의 이슈로 직접 IP접속을 차단한 경우가 많아,

열리지 않는 경우가 많다.

 

참고 : [네트워크 - nslookup 이란 무엇인가 : 네이버 블로그](https://m.blog.naver.com/PostView.nhn?blogId=on21life&logNo=221364857511&proxyReferer=https:%2F%2Fwww.google.com%2F)

'서버' 카테고리의 다른 글

Error: Unknown command: cask 에러를 만났을 때  (3) 2021.03.13
Graphql이란  (0) 2020.09.26
초보자를 위한 REST API  (0) 2020.06.21
Docker란(도커란)  (0) 2020.06.02
NAS란(나스란)  (0) 2020.06.01

말 그대로 정말 초보자를 위한 REST API 설명이다.

그 동안 개발을 하면서 RESTFUL하게 코드를 설계하였나? 라고 하면...
딱히 대답할 말이 없었다.

REST가 무엇인지 몰랐고, 또 이게 왜 필요한지도 잘 몰랐다.
사실 그 동안 REST API에 대해서 검색도 많이 해보고 많이 찾아보기도 했는데,
그 당시의 나의 수준에서 이해하기 어려웠는지, 이해가 잘 되거나 와닿지 않았다.

그러다가 정말 초보자 수준에서 이렇게 설명하면 좋을 것 같다는 생각이 들어
내가 느낀 대로 REST API를 정리해보려고 한다.

일단 REST API를 알려고 하면 API를 알아야 한다.

API는 Application Programming Interface의 줄인 말이다.
Application들이 서로 통신할 수 있도록 도와준다고 생각하면 될 것 같은데,
우리는 프론트와 서버가 통신하기 위해 API를 활용한다.

예를 들어 보자.


이런 상황은 얼마든지 발생할 수 있다. 또 반대로 금은방에 가서 돼지 불백을 주문하는 불상사가
생길 수 있다. 사실 이런 상황은 프론트와 서버와의 통신간에 더 많이 발생할 수 있다.

그러기 위해 서로 약속을 해야 한다. 이런 인터페이스를 사용하겠다는..
그게 API다. 다시 API의 보면 Application Programming Interface이다.

Programming Interface 개발을 위한 인터페이스인데, Application 간의 통신을 위한 인터페이스

자 여기서 한번 더 들어가보자. 이제 프론트와 서버간의 통신을 위한 인터페이스는 정했고,

그럼 REST API란 무엇일까?

아래의 상황을 보자.

음식점에 왔고, 손님은 이번에는 금값을 묻거나 그런 것이 아니라 정말 "음식"이라는 것을 잘 주문했다.
이 상황을 보고 나면 사실 인터페이스 뿐만 아니라 또 한번의 "약속"이 필요하다는 것을 느낄 것이다.

즉 어떻게 요청 할 것인지에 대한 약속. 그것을 위해 생겨난 것이 REST API다.(와 길게 왔다...)

REST API는 서버와 프론트 간에 어떻게 요청하고, 어떻게 전달 받을지에 대한 "약속" (효율을 높이기 위해!) 이라고 하면 좋겠다.

일단 REST API에 대한 정의를 보자.

참고 : mangkyu.tistory.com/46

일단 CRUD를 알아야 할텐데 Create, Read, Update, Delete의 줄인 말이다.
사실 우리가 통신할 때 하는 행동은 대부분 위의 4가지 이다. 이거는 조금만 고민해 보면 아는데, 게시판에 글을 적는다는 것은 Create하는 행위 일 것이고, 다른 게시판으로 이동하는 것은 Read하는 행위, 게시글을 수정하는 것은 Update, 게시글을 지우는 것은 Delete이다.

그럼 이 CRUD한 요청을 보내기 위한 "약속"이라고 볼 수 있는데 REST API에는 3가지의 구성 요소가 있다.

URI : product/32(id) => 서버는 요청에 대한 고유 id의 값을 가지고 있고, 해당 id로 요청을 보낸다는 것 1가지

METHOD : GET/POST/PUT/DELETE => 여기 드디어 나왔다. GET과 POST!

Representation of Resource : Json, XML, TEXT => Json은 여기에 숨어 있었다. JSON!

API의 효율적 통신을 위해 다시 한번 약속을 한 것이 REST API라고 했다. 이제 하나씩 보자.

URI에 대한 것은 조금만 눈치가 빠른 사람이라면 알 수 있다.
아래의 네이버 영화 페이지의 URL이다.
https://movie.naver.com/movie/bi/mi/basic.nhn?code=180378

여기서 제일 위의 code=180378 이라고 나오는데 여기 코드 번호를 하나만 바꾸면 또 새로운 영화로 바뀌면서 영화 정보가 나오는 것을 볼 수 있다.

그럼 다시 REST API 3가지 구성 요소 중 URI에 대한 부분을 보자.
"서버는 요청에 대한 고유 id의 값을 가지고 있고, 해당 id로 요청을 보낸다"

이제 이 말이 조금은 이해가 될 것이다. 해당 API(영화 정보를 조회하는 api는 https://movie.naver.com/movie/bi/mi/basic.nhn?

여기 제일 위에 code= 와 같이 조회할 영화 정보를 넣는다는 것이 REST API 약속 중 한 가지이다.

그럼 2번 째 드디어 나온.. 우리가 너무 자주쓰고 있는 GET과 POST가 나왔다.

"정보를 요청할 때는 GET 요청을 보내고,
정보를 입력할 때는 POST로 요청을 보낸다."
이렇게 약속을 해놓은 것이다. 이렇게 되면 서버에서는 프론트에서 GET 요청이 올 때는 DB에서 데이터를 조회해서
보내주는 로직으로 구성하면 되고, POST 요청이 오면 작성에 대한 로직을 구성하면 되기 때문에 굉장히 효율이 높아지게 된다.

이렇듯 REST API는 API 통신이 원활하기 위해 또 한번 약속을 해놓은 것이라고 볼 수 있다.

실제 REST에 대한 백과사전을 찾아보면

REST(REpresentational State Transfer) :

“Representational State Transfer라는 용어의 약자로서 2000년도에 로이 필딩 (Roy Fielding)의 박사학위 논문에서 최초로 소개됨. 로이 필딩은 HTTP의 주요 저자 중 한 사람으로 그 당시 웹(HTTP) 설계의 우수성에 비해 제대로 사용되어지지 못하는 모습에 안타까워하며 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표”

와 같은 글을 볼 수 있다.

그럼 이제 마지막 Representation of Resource : Json, XML, TEXT 을 보자.

서버에서 프론트로 값을 줄 때 항상 JSON 형태로 전달을 하고 있어서 그냥 그런가 보다 생각을 했었는데,
이것도 REST API의 일부였다..!! 

서버에서 프론트로 결과 값을 줄 때 JSON/XML/TEXT 등의 값으로 반환한다는 것을 정의 해놓은 것인데,
이렇게 되면 프론트엔드 쪽에서도 어떤 형태로 값이 넘어올지 미리 예상할 수 있어 이렇게 맞추어 코딩을 하면 된다.

현재는 JSON 위주로 쓰이고 있어서 우리는 보통 서버에서 프론트로 반환 값을 줄 때 JSON형태로 전달하고 있다.
JSON은 key와 value로 이루어진 값의 모임인데 간단하게 형태를 예시로 들어보면 아래와 같다.

 

와 이제 정말 다 설명했다.

정리를 다시 해보자면

API 사용하기 위해서는 약속이 다시 한번 필요했고! 이 약속을 효율적으로 한 것이 REST API라는 것.

RESTFUL하게 구성하였냐는 이 REST의 구성요소 들을 잘 지키면서 API를 작성했는지에 대한 것이다.

나처럼 헤메고 있는 누군가에게는 도움이 좀 되었으면 좋겠다.


ps . 저와 같이 초보자를 위해 정리한 것이라 다소 틀린 부분이 있을 수 있습니다.

'서버' 카테고리의 다른 글

Graphql이란  (0) 2020.09.26
nslookup 이란  (0) 2020.08.31
Docker란(도커란)  (0) 2020.06.02
NAS란(나스란)  (0) 2020.06.01
MOUNT란  (0) 2020.06.01

 

docker란?

  • 컨테이너 기반의 오픈소스 가상화 플랫폼

  • 도커는 환경 분리를 도와준다.

  • 작업물을 서버에 올렸는데 작동하지 않는다.

    • 나의 작업 환경은 윈도우고, 서버는 리눅스

  • docker를 통해 다른 머신에서도 같은 환경을 조성해준다.

 

docker image

 

  • 컨테이너 실행에 필요한 파일과 설정값등을 포함하고 있는 것으로 상태값을 가지지 않고, 변하지 않는다.

  • 컨테이너는 이미지를 실행한 상태라고 볼 수 있고 한 이미지로 여러개의 컨테이너를 생성할 수 있다.

  • 이미지는 컨테이너를 실행하기 위한 모든 정보를 가지고 있기 때문에 더 이상 의존성 파일을 컴파일 하고 이것저것 설치할 필요가 없다.

  • docker 이미지는 docker hub에 등록하거나, docker registry 저장소를 직접 만들어 관리할 수 있다.

 

dockerfile

  • 이미지를 만들기 위해 dockerfile이라는 파일에 DSL(Domain-specific-language 언어를 이용하여 이미지 생성과정을 적는다.) 

  • docker에서 사용하고 싶은 환경을 설정한다.

  • 우분투, 파이썬, 깃 등등

  • 이 파일을 통해 로컬에서와 서버에서 같은 환경을 조성해준다.

 

docker 특징

  • docker는 서로 독립적이라서 하나의 서버가 많은 수의 컨테이너를 가질 수 있다.

  • docker 덕분에 매번 새로운 서비스를 만들 때마다 새로운 서버를 사고 설정할 필요가 없다.

  • 그냥 docker container를 더 늘리면 된다.

  • 원하는 개발 환경을 파일에 저장하면 docker는 내가 원하는 해당 환경을 시뮬레이션 해준다.

  • 각각의 환경들은 독립적으로 존재하기 때문에 무슨 환경이든 모듈식으로 관리 가능하다.

    • python server, java server, db server 등 모두 따로 구매해줄 필요 없다.

 

볼륨(데이터)을 공유 하지 않으면 서로 같이 쓸 수가 없다.

  • docker volume

  • docker를 사용하다보면 container안에서의 데이터 휘발성 때문에 

  • volume을 사용하게 된다.

  • 하나의 서버안에서도 여러개의 docker가 돌 수 있고, 

  • 특정 docker안에서 만들어진 파일은, 공유할 수 없다.

  • 이런 불편함을 막기 위해 서버 안에 디스크를 mount 해놓고 사용하면 된다.

  • docker 컨테이너는 언제든지 추가되고 삭제 될 수 있기 떄문에 데이터는 반드시 컨테이너 내부가 아닌 외부 스토리지에 저장해야 한다.

 

참고 : [초보를 위한 도커 안내서 - 이미지 만들고 배포하기](https://subicura.com/2017/02/10/docker-guide-for-beginners-create-image-and-deploy.html)

'서버' 카테고리의 다른 글

nslookup 이란  (0) 2020.08.31
초보자를 위한 REST API  (0) 2020.06.21
NAS란(나스란)  (0) 2020.06.01
MOUNT란  (0) 2020.06.01
디자인패턴  (0) 2020.03.16

NAS란 Network Attached Storage의 줄인 말로

네트워크와 연결된 저장소이다.

 

네트워크로 연결되어 있기 때문에 언제 어디서든

pc, 모바일로 나스에 저장된 파일에 접근할 수 있다.

 

쉽게 이야기하면 저장소인데, 

이게 네트워크로 연결되어 있다고 생각하면 편할 것 같다.

 

따라서 다른 곳들에서도 NAS의 장점으로 드는게

확장 가능하며, 비용이 저렴하다는 것이다.

 

요즘은 클라우드 서비스들에서도 NAS를 

제공하고 있다.

 

참고 : [NAS - Storage - NAVER CLOUD PLATFORM 네이버 클라우드 플랫폼](https://www.ncloud.com/product/storage/nas)

[클라우드 파일 스토리지란 무엇입니까? – AWS](https://aws.amazon.com/ko/what-is-cloud-file-storage/)

 

이렇게 NAS 볼륨을 여러 대의 서버에서 함께 mount해서 사용하면

어떤 서버에서는 해당 데이터에 접근하여 사용할 수 있다.

 

근데 mount해서 사용한다는 것은 

반대로 종속성을 가지게 된다는 말이다. 

 

우리가 NAS에 데이터를 넣는 방법에는 여러가지가 있겠지만,

실제 가능한 상황을 2가지로 생각할 수 있다.

 

  1. docker내에서 해당 volume을 mount해서 사용하는 것

  2. 직접 NAS에 파일을 업로드 하는 것

 

현재 우리는 1번의 혀태로 사용하고 있는데,

docker내에서 해당 volume에 바로 접근할 수 있어서

굉장히 편하다.

 

하지만 이런 형태는 종속성을 갖는다.

즉 서버를 새롭게 만들 때 마다 해당 환경을 다시 셋팅해줘야하는

불편함이 이다.

 

그에 비해 2번으로 구현을 해놓으면 종속성이 없어진다.

 

2번 방법이 관리 측면에서는 더 좋은 방법이라고 볼 수 있지만,

계속 1번으로 하고 있는 것은, 그것보다 편한 것이 더 큰게 아닐까?

 

갑자기 2번으로 하려고 하니 머리가 아프다 질끈 @.@

'서버' 카테고리의 다른 글

초보자를 위한 REST API  (0) 2020.06.21
Docker란(도커란)  (0) 2020.06.02
MOUNT란  (0) 2020.06.01
디자인패턴  (0) 2020.03.16
nginx 기본에 대해서 알아보기  (0) 2020.01.20

# 마운트에 대한 간단한 정리


우리가 컴퓨터를 사용할 때 외장하드를 연결하면

D드라이브와 같이 새로운 폴더가 내컴퓨터에 만들어진다.

 

이렇게 디스크와 같이 물리적 장치를 특정 위치 즉 디렉토리에

연결시켜주는 것을 마운트라고 한다.

 

윈도우에서는 이것을 직접해줘서 

우리가 마운트라는 이야기를 들어본적이 없지만,

리눅스에서는 직접 MOUNT 작업을 해줘야 한다.

 

리눅스는 윈도우와 다르게 하나의 디렉터리로부터 뻗어지는

single directory tree구조를 갖고 있다.

따라서 마운트를 진행하면 /media/cdrom과 같은 형태를 띄게 된다.

 

리눅스 서버에서 mount라는 명령어를 입력하면

현재 mount 되어 있는 것들의 list를 쭉 볼 수 있다.

 

추가적으로 df 명령어를 통해 현재 마운트 된 disk들의 

정보를 볼 수 있다. 

 

현재 우리 서버에서는 nas를 mount해서 사용 중에 있는데,

해당 nas를 mount 해준다는 정보는 docker-compose안에 

volumes 설정에 있다. 

 

'서버' 카테고리의 다른 글

Docker란(도커란)  (0) 2020.06.02
NAS란(나스란)  (0) 2020.06.01
디자인패턴  (0) 2020.03.16
nginx 기본에 대해서 알아보기  (0) 2020.01.20
몽고DB와 NoSQL  (0) 2019.12.04

디자인패턴, 디자인패턴 너무나도 많이 들어보았는데, 딱히 사용하고 있지 않은 것 같은 느낌이 들어서 찾아보니, 이미 잘 사용하고 있었다.(django는 MVC디자인패턴을 사용하고 있었다!!. 찾아본 내용에 대해서 정리)

디자인패턴의 개요 

  • 서로 여러 사람이 함께 개발하기 때문에, 유지보수 하거나, 새로운 기능을 추가하거나 최적화를 하기에 힘든 구조적 결함이 있다.

  • 프로그램등을 개발하는 중에 발생했던 문제점들을 정리 및 특정한 '규약'을 통해 좀 더 쉽고 편리하게 쓸 수 있는 형태로 만든 것

  • 한마디로 코딩 방법론이나, 코딩 컨벤션에 가깝다.

 

MVC 패턴

  • Model, View, Controller

  • User-View-Controller-Model-Controller-View User의 구조

  • 시각적인 부분과 이면의 동작과 제어를 처리하는 부분을 분리하여 서로에 미치는 영향 없이도 응용프로그램을 변경할 수 있도록 한다.

  • django도 MVC패턴을 따르며, django에서 model은 model, View는 template, Controller역할은 View가 한다.

  • 가장 전형적인 OOP구조로서 가장 단순하며, 보편적으로 많이 사용되는 디자인패턴

  • OOP참고 [[번역] OOP를 빨리 잊을 수록 여러분과 여러분의 소프트웨어에 좋습니다 | rinae's devlog](https://rinae.dev/posts/the-faster-you-unlearn-oop-the-better-for-you-and-your-software-kr)

 

 

MVP 패턴

  • Model. View. Presenter

  • MVC와 다르게 컨트롤러 대신에 Presenter가 View와 Model 사이를 중계해주고 있다. 따라서 Model과 View는 서로를 알 필요가 전혀 없이 Presenter만 가리키게 된다. 따라서 View와 Model의 의존성은 사라지게 된다.

  • 모델은 위 MVC패턴과 동일하며 뷰와 프리젠터에서 구성 요소의 변화가 있다.

  • V(View) 기본적으로는 MVC와 같이 화면에 보여지는 요소를 맡는 것은 동일하나 Controller가 사라짐에 따라서 이제 사용자의 입력을 받는 역할을 겸하게 된다. MVC에서 Controller의 역할의 일부를 얻게 되었다고 이해하면 좋다.

  • P(Presenter) View에서 요청한 정보로 Model을 가공하여 View에 전달해주는 부분이다. 본질적으로는 MVC의 컨트롤러와 같지만 뷰에 연결되는 것이 아니라 그냥 인터페이스라는 점이 다르다.

 

MVP패턴의 장/단점

  • 장점 MVC와 달리 View와 Model의 의존성이 사라졌다.

  • 단점 View와 Model 사이의 의존성은 해결되었지만 대신에 View와 Presenter 사이에 높은 의존성을 가지게 되었다. 이는 MVC와 마찬가지로 어플리케이션이 복잡해질수록 View와 Presenter 사이의 의존성이 더욱 강해지고 복잡해진다.

 

MVVM 패턴

  • Model , View, ViewModel

  • VM(ViewModel) 뷰에 필요한 데이터를 준비하고 모델에 필요한 이벤트를 전달한다. 그러면서도 뷰에 종속되지 않는 뷰만을 위한 모델이라고 할 수 있다.

  • 어떻게 뷰와 뷰모델, 뷰모델과 모델간에 의존성이 사라지게 되느냐. 그것은 바로 Command패턴과 Data Binding 덕분인데, 이 패턴과 라이브러리로 인해서 의존성이 완전히 사라지게 된다.

  • Command패턴과 Data Binding은 각각 또 하나의 문서를 할애해서 설명이 필요할 만큼이나 긴 설명이 필요해서 해당 포스팅의 목적과 엇나갈 수 있으므로 간략하게만 짚고 넘어가자.

  • Command패턴은 앞서 설명한 여러가지 디자인 패턴들 중에 하나이며 요청을 객체의 형태로 캡슐화하여 저장, 로깅, 취소를 할 수 있는 패턴이다.

  • Data Binding은 XML에 만든 View들을 자동으로 알아서 만들어주는 안드로이드 라이브러리이다.

  • 요약하자면 여전히 MVP패턴처럼 View를 통해 사용자의 입력이 들어오게 되면 Command패턴으로 ViewModel에 요청한다. ViewModel은 Model에게 필요한 데이터를 요청하고 Model은 응답한뒤 ViewModel에서 다시 가공해서 저장한다. 여기서 View로 다시 안돌려주냐고 할 수 있는데, View는 Data Binding을 통해 자동으로 갱신하게 된다.

 

MVVM 패턴의 장/단점

  • 장점

  1. Command 패턴과 Data Binding을 사용하여 View와 Model, 심지어 View와 View Model 사이의 의존성 또한 없앴다.

  2. 테스트와 모듈화가 쉽다

  3. 뷰와 모델을 연결하기 위해 사용해야 하는 연결 코드를 줄일 수 있다.

  • 단점

  1. View Model의 설계가 쉽지 않다.

  2. 뷰가 변수와 표현식 모두에 바인딩될 수 있어서 시간이 지남에 따라 관계없는 프리젠테이션 로직이 늘어나 유지 관리하기 번거롭다.

 

참고 : [신입 개발자 면접 질문 시리즈](https://www.notion.so/54d624628a634c879cc93d94f54cd2d1#0c4b1ec1ee49475ebebbf3897e5d7818)

'서버' 카테고리의 다른 글

NAS란(나스란)  (0) 2020.06.01
MOUNT란  (0) 2020.06.01
nginx 기본에 대해서 알아보기  (0) 2020.01.20
몽고DB와 NoSQL  (0) 2019.12.04
Webhook과 api의 차이  (0) 2019.12.04

WEB + FTP + EMAIL : 인터넷

http: 통신 규약이다. (인터넷 위에서 동작하는 웹이라는 서비스를 이용하기 위해서 준수해야 하는 통신규약) 즉 클라이언트가 서버에 어떻게 요청하고 어떻게 응답해야 하는지에 대한 규칙

그 통신 규약을 지켜서 작동하는 Server를 HTTP Server 다른 말로 web server라고 한다.

Web Server : 가장 대표적인게 apache이다. nginx 역시 web server 중의 한개이다.

NGINX: 차세대 웹서버로 불린다. 더 적은 자원으로 더 빠르게 데이터를 서비스 할 수 있다.

apache 처리 방식 출처 : [넌 뭐니 NGINX? - sjk5766 - Medium](https://medium.com/sjk5766/%EB%84%8C-%EB%AD%90%EB%8B%88-nginx-9a8cae25e964)
nginx 처리 방식 출처 : [넌 뭐니 NGINX? - sjk5766 - Medium](https://medium.com/sjk5766/%EB%84%8C-%EB%AD%90%EB%8B%88-nginx-9a8cae25e964)

=> 기존에 apach가 client에서 요청이 많이 들어오면 여러개의 process를 만들어서 처리하거나 스레드를 이용하여 처리했다면 nginx는 비동기 방식으로 효율적으로 작업을 처리하여 process 또는 thread 생성 비용이 존재하지 않는다.

추가 질문

그럼 web server와 web application 서버의 차이점은 무엇일까?

해당 내용은 다음 번에 추가 공부!

 

'서버' 카테고리의 다른 글

NAS란(나스란)  (0) 2020.06.01
MOUNT란  (0) 2020.06.01
디자인패턴  (0) 2020.03.16
몽고DB와 NoSQL  (0) 2019.12.04
Webhook과 api의 차이  (0) 2019.12.04

그동안 nosql을 들을 때 마다, 데이터베이스가 없다고 생각했다... 띠용...

와 왜 이렇게 모르는 단어를 듣고도 찾아보지 않았나 후회가 된다.

NoSQL은 "Non Relational Operation Database SQL"의 줄인말로서 관계형 데이터베이스가 아닌 SQL이다.(SQL은 Structured Query Language로 관계형 데이터베이스 관리 시스템의 데이터를 관리하기 위해 설계된 특수 목적의 프로그래밍 언어이다.)

일반적인 관계형 데이터베이스에서는 데이터의 중복을 제거하고 무결성을 보장하기 위해서 정규화를 하게 되는데, 이러한 정규화가 과도한 JOIN으로 인해 성능 저하가 있을 수 있다.

그동안 지속적으로 관계형 데이터베이스만을 보아왔는데, 그런 형태가 아닌 

Nosql 예시(출처 :[01. MongoDB(몽고디비) Study - NoSQL 이란? 그리고 MongoDB 소개](https://cionman.tistory.com/44))

위와 같은 형태로 DB가 구성될 수 있다는 것이다.

이런 형태로 DB가 구성된다는 것부터가 이미 굉장히 신기했다. 

NoSQL의 장점은

1. 불필요한 JOIN의 최소화

2. 데이터 분산에 용이

3. 복제 및 장애대응에 용이

4. 데이터를 고속으로 처리할 필요가 있는 경우

등 굉장히 많은 장점들이 올라와 있는데, 아직까지 직접 사용해보지 않아서 잘 와닿지 않는다.

추가적으로 비정형 데이터로 인해 관계형 데이터베이스보다 1.5배 정도 용량을 많이 차지한다는 것도 신기했다. (Nosql이라고 해서 아예 데이터를 쌓지 않는다고 생각한 무식이 슬프다..)

NoSQL에도 종류가 여러가지 있고 그 중에서 이번에는 MongoDB를 처음 접해보았는데, 조금 더 공부하면서 배운 것들을 다시 정리해야 되겠다. 

 

'서버' 카테고리의 다른 글

NAS란(나스란)  (0) 2020.06.01
MOUNT란  (0) 2020.06.01
디자인패턴  (0) 2020.03.16
nginx 기본에 대해서 알아보기  (0) 2020.01.20
Webhook과 api의 차이  (0) 2019.12.04

Webhook과 API. 

참 개발을 하면서 많이 듣는 단어이다.

api는 (Application Promgramming interface)의 줄인 말로 API는 응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다.라고 위키에 나와있다.

오히려 이런 정의를 접하고 나니깐 더 어려워진다. 응용 프로그램은 우리가 만들고 있는 서비스 혹은 제품이라고 생각하면 될 것 같고, 운영 체제나 프로그래밍 언어는 우리에게 정보를 제공해주는 곳이라고 생각하면 될 것 같다.

우리는 정보를 제공해주는 곳에 API를 보내면 해당 정보들로 반환을 해서 준다. 흐헝 이것도 어려우니깐 이해가 잘 되도록 적어놓으신 글을 첨부 [API 란? - 초보개발자 - Medium](https://medium.com/@dydrlaks/api-%EB%9E%80-c0fd6222d34c)

아무튼 특정 서비스에서 정보를 얻어오는 방법은 크게 2가지로 나뉘어진다.

Webhook 혹은 API, 2가지 모두 그 서비스에서 제공을 해줘야지만 가지고 와서 쓸 수 있다.

webhook과 api의 가장 큰 차이는 api는 우리가 요청했을 때 해당 서비스에서 요청한 자료를 주는 것이고 webhook의 경우에는 해당 서비스에서 우리가 설정해놓은(또는 제공해주는) 특정 변화가 있을 때 해당 정보들을 보내준다.

웹훅의 이점에 대해 atlassian에서 잘 정리해놓아서 가지고 와본다.

Advantages of webhooks

Without webhooks, if you want to detect when events occur in Bitbucket Cloud, you need to poll the API. However, polling the API is inconvenient, inefficient, and error-prone. Consider how SMS messages work on mobile phones. You don't have to check your messages every 5 minutes to see if you have a text because your phone sends you a notification. In the same way, webhooks work like the notification so that the API does not have to check for the same activity every minute.

  • 즉 우리의 휴대폰에서 5분마다 메시지가 왔는지 확인하는 것은 매우 비효율적이다. 따라서 우리는 메시지가 올 때만 알람을 듣고 확인하게 하는데, 5분마다 폰을 켜서 메시지가 왔는지 확인하는 것은 api, 그리고 그 메시지가 왔을 때 알람을 주는 것은 webhook이다.

 

=> 해당 글은 현재까지의 이해도를 바탕으로 작성하고 있어, 틀린 부분이 많을 수 있습니다. 댓글 적어주시면 앞으로 고쳐가도록 하겠습니다!

'서버' 카테고리의 다른 글

NAS란(나스란)  (0) 2020.06.01
MOUNT란  (0) 2020.06.01
디자인패턴  (0) 2020.03.16
nginx 기본에 대해서 알아보기  (0) 2020.01.20
몽고DB와 NoSQL  (0) 2019.12.04

+ Recent posts