2016년 7월 24일 일요일

[node.js] Express.js 란?

Express.js는 Node.js 핵심 모듈인 http 와 connect 컴포넌트를 기반으로 하는 웹 프레임워크다.

node js 를 이용하여 애플리케이션을 개발할 경우 다음과 같은 유사한 작업들을 동일한 코드를
반복해서 작성할 가능성이 크다.
1. HTTP 요청 바디 파싱
2. 쿠키 파싱
3. 세션 관리
4. URL 경로와 HTTP요청 메소드를 기반으로 한 복잡한 if조건문을 이요한 라우트 구성
5. 데이터 타입을 기반으로 적절한 응답 헤더 결정

Express.js는 위 사항들 뿐만아니라, 추상화 및 코드 구성과 같은

별도의 문제들까지 해결한다. 프레임워크는 MVC 와 같은 구조를 제공한다.

2016년 6월 22일 수요일

tar.gz 압축/해제 명령어

서버 log 백업시에 많이 사용한다.

많이 쓰는 만큼 이참에 정리해 두자.

리눅스에서 대표적으로 사용하는 것으로 tar / tar.gz 이 있다.

보통 gzip 으로 많이 묵는다.

tar.gz 압축 명령어

tar -czvf 압축파일명.tar.gz 압축할 폴더/파일

ex) #tar -czvf log.tar.gz /service/log/*

tar.gz 압축 풀기 명령어

tar -xzvf 압축파일명.tar.gz

ex) #tar -xzvf log.tar.gz

위에서 사용하는 옵션에 대해서 간략하게 설명한다.

-v : 압축 또는 해제 시에 과정을 출력 (정확히 확인하기 위해 찍는게 좋음)

-f : 파일 이름을 지정

-c : 파일을 tar로 묶음

-z : gzip 으로 압축하거나 해제함.

-x : tar 압축을 품

이정도만 알고 있으면 리눅스에서 tar.gz 으로 묶거나 푸는데는

문제 없을 듯 하다.

[Git Flow] egit + git bash를 이용한 Eclipse 에서 관리 방법

Git에서 효율적으로 branch 관리를 하기 위해서 Git flow를 활용한다.

개발 툴로 Eclipse를 쓰고 있고 빌드는 Gradle로 하고 있으므로

이에 맞춰서 활용할 수 있는 방법을 설명한다.

먼저 그전에 Git Flow 에 대해서 설명한다.

1. Git Flow
Git Flow는 프로젝트 개발 시 사용하는 branch 모델 방법이다.
이 모델은 총 5가지의 Branch 전략을 제공한다.

feature – develop – release – hotfixes – master 로 되어 있으며 각각은 역할이 있다.

1) master : master 브런치는 최종 점검을 마치고 릴리즈한 안정화된 브런치다.
2) develop : 개발 중인 사항의 최종 통합 브런치다.
3) release : 제품 배포를 준비하는 브런치다.
4) feature : 조만간 제품을 배포하거나 또는 다음에 배포를 위한 기능 개발을 위한 브런치다.
5) hotfixes : 버그를 잡기 위한 긴급 수정을 위한 브런치다.

2. Git Flow 사용법
Git이 설치되어 있고 Eclipse 와 Egit Plugin이 설치되어 있다는 가정하에 진행한다.
또한 현재 프로젝트는 Git Project일 경우로 한하여 진행한다.

1) Git Flow를 설정할 프로젝트 폴더로 이동한다.

2) 마우스 우클릭 후 Git Bash Here을 선택

3) Git Bash에서 git status 명령어로 현재 이 프로젝트의 commit 상태를 확인한다.

4) 커밋할 사항이 아니면 gitignore 파일에 추가하거나 , git stash로 돌린다.

5) 그 후 git flow init 명령어로 git flow를 실행한다.

6) branch전략을 어떻게 할지 나오는데 계속 엔터치면서 지나가면 된다.

7) 끝나면 branch가 master에서 develop으로 바뀐 것을 확인할 수 있다.

8) 여기서 기능 개발을 하려고 한다면 feature 브런치를 만들어 주자.
9) 명령어 git flow feature start '[branch detail name]'

10) 작업이 완료되면 branch가 develop -> feature/[branch detail name] 으로 변경된다.

11) 개발이 끝나면 git flow feature finish '[branch detail name]' 명령어를 입력한다.
12) 배포 준비를 할 경우 release branch를 만들어 최종 release 점검을 진행한다.

13) 명령어 git flow release start '[branch detail name]'

14) branch 가 deveop -> release/[branch detail name] 으로 변경 된다.

15) 그 후 release 준비가 모두 끝나면 git flow release finish '[branch detail name]' 입력
16) Tag Edit 화면이 뜨면 리눅스 입력창과 똑같이 하면 된다. a키 누르고 tag 넣고
esc-> :wq 입력하면 저장된다.

17) 그러면 branch 가 master로 변경되며 최종 release가 왼료 된다.

참고

http://huns.me/development/1131

http://mobicon.tistory.com/280

2016년 5월 16일 월요일

MYSQL Date/DateTime/TimeStamp 차이

Mysql에서 시간을 나타낼 때 쓰는 Type은 3가지다.

Date , DateTime , TimeStamp

항상 쓸 때마다 왜 이거쓰더라 하면서 쓰지만 이번에는
정확히 알고 넘어가고 싶어서
이 3가지 타입에 대해 정리를 블로그에 해두기로 하자.

1. Date
- Date 타입은 날짜 값만을 필요로 할 때 사용된다.
- 시간 부분이 없으며 'yyyy-MM-dd' 포맷으로 출력한다.
- 지원되는 범위는 '1000-01-01' ~ '9999-12-31' 까지

2. DateTime
- DateTime 타입은 날짜와 시간 정보를 모두 가진다.
- 'yyyy-MM-dd hh:mm:ss' 포맷으로 출력된다.
- 지원되는 범위는 '1000-01-01 00:00:00' ~ '9999-12-31 23:59:59'까지.

3. TimeStamp
- TimeStamp 타입은 날짜와 시간 부분을 포함하는 값임.
- 범위는 UTC '1970-01-01 00:00:01' ~ UTC '2038-01-19 03:14:07'
- 즉 TimeStamp 타입은 UTC에 따라서 시간이 변경됨.
(따라서 클라우드 서비스에서 사용한다면 영향이 있을 수 있음)

2016년 5월 15일 일요일

[ZooKeeper] ZooKeeper 설치

ZooKeeper 는 분산환경의 상호 조정이 필요한 다양한 서비스를 제공하는
동기화가 보장되는 아파치 오픈소스이다.

분산 환경에서 락, 네이빙 서비스, 클러스터 멤버십 등을 쉽게 구현할 수 있는
분산 코디네이터 서비스를 쉽게 만들 수 있다.

일단 이번에는 설치 법을 소개 한다.

설치하는 환경은 다음과 같다

- OS : 우분투
- H/W : AWS EC2 t2.micro

※ Java 6 이상이 설치되어 있어야 한다.
자바 설치법은 다음을 참고
http://sarghis.com/blog/1050/

1. ZooKeeper Download

ZooKeeper는 http://apache.mirror.cdnetworks.com/zookeeper/ 에서 stable을 들어가서
다운 받습니다.

2. 파일 이동

filezilla 또는 FTP 파일을 이용해서 AWS의 OS로 이동 시켜 줍니다.

3. 압축 풀기 및 파일 이동

1) #wget http://apache.mirror.cdnetworks.com/zookeeper/stable/zookeeper-3.4.8.tar.gz
※ 끝의 파일 release는 바뀔 수 있습니다.

2) #tar zxvf zookeeper-3.4.8.tar.gz

3) #mv zookeeper-3.4.8.tar.gz /usr/local/zookeeper

4) #cd /usr/local/zookeeper/zookeeper-3.4.8

4. 설정파일 복사 및 수정

1) #cp conf/zoo_sample.cfg conf/zoo.cfg

2) zoo.cfg 수정

i) #cd conf/
ii) #vi zoo.cfg

설정파일 수정 내용
=====================
# The number of milliseconds of each tick
tickTime=2000
# The number of ticks that the initial
# synchronization phase can take
initLimit=10
# The number of ticks that can pass between
# sending a request and getting an acknowledgement
syncLimit=5
# the directory where the snapshot is stored.
# do not use /tmp for storage, /tmp here is just
# example sakes.
dataDir=/usr/local/zookeeper/data
# the port at which the clients will connect
clientPort=2181
============================================
dataDir 부분만 본인에 맞게 수정해주세요 스냅샷 데이터가 쌓이는 장소 입니다.

iii) 저장하고 나오면 됩니다.

5. 서버 구동
※ 4번까지 진행하시면 현재 위치는 /usr/local/zookeeper/zookeeper-3.4.8/conf
입니다.
# cd ..
# cd bin/
# ./zkServer.sh start
--> 서버가 구동 됩니다.

6. 클라이언트 접속하기
# ./zkCli.sh -server 127.0.0.1:2181

2016년 5월 10일 화요일

Redis에 대해 현재 개발에 필요한 내역 요약(Java)

Redis

Redis는 메모리 기반의 Key/Value Store 이다.

기존에 메모리 기반 NoSQL DB 인 MemCached 와 성능면에서 비등하면서

Data Structure 도 지원됨으로서 다양한 용도로 사용할 수가 있다.

( Ex) Messsage Queue , Shared Memory Server , Remote Dictionary , Pub/Sub 등.

여기서는 각각에 사용되는 모델 설명하고

현재 서버를 자바로 개발하고 있으므로 Java Client 중에 추천할만한 것을 소개하도록 한다.

1. Persistence

Redis 는 Memory 형 DB 이기 때문에 서버가 죽으면 데이터가 유실될 우려가 있겠지만, Redis는 Restart 될 때,

Disk 에 저장해 놓은 데이터를 다시 읽어서 메모리에 로딩하기 때문에 데이터가 유실되지 않는다.

Disk 에 데이터를 저장하는 방법은 2가지 인데, 스냅샷 방식과 AOF 2가지가 있다.

스냅샷 방식을 RDB 방식과 같다.

AOF는 Redis의 모든 write/update 연산 자체를 모두 log 파일에 기록하는 방식이다.

서버가 재시작 될 때 순차적으로 재 실행하여 데이터를 복구한다.

장점이라면, 당연히 어느 시점에 서버가 다운되더라도 데이터 유실이 발생되지 않는다. 다만 단점은, 복구시 서버 리스타트 속도가 무지막지 하게 느리며 파일이 너무 커진다.

AOF 와 스냅샷 방식에 자세한 내용은 이 문서를 참고해주기 바란다.
http://www.redisgate.com/redis/configuration/persistence.php

2. Pub/Sub Model

Redis는 Pub/Sub 모델에서도 활용될 수 있다. 하나의 Redis Client 가 메시지를 Publish 하면 Topic에 연결되어 있는 다른 Redis Client 가 메시지를 받을 수 있는 구조다.

좀 특이한 점은 pattern matching 을 통해서 다수의 Topic에서 Message를 subcribe 할 수 있다.

3. Redis 에서 지원되는 자료구조

1). String

문자열만 저장할 수 있는 것이 아니고, 이진 데이터도 저장이 가능하다.

   key 에 넣을 수 있는 Data 최대 크기는 512MB 다.

2). List

Lists (Array 형태로 Key 1개에 n개의 값을 가짐, 중복 값 가능)

- 배열이라고 생각하면 된다.

- 한 key에 넣을 수 있는 요소의 최대 개수는 4,294,967,295 개이다.

3). Set

   - 정렬되지 않은 집합 형으로 key에 중복된 데이터는 종재하지 않는다.

   - 추가 , 제거 및 존재 체크 시 소모되는 시간이 , sets에 포함된 요소의 수에 관계없이 일정하다.

- 한 key에 넣을 수 있는 요소의 최대 개수는 4,294,967,295 개이다.

4). Sorted-Set

   - Sorted-Set 은 Redis 에서 가장 많이 쓰이고, 가장 진보된 데이터 형이라고 한다.

- 랭킹시스템 등에서 사용되기 좋다.

- sets의 각 요소마다 score라는 실수 값을 가지고 있는 형태로 score 값으로 오름차순 정렬된다.

- key에 중복된 데이터는 존재하지 않지만 score 값은 중복 가능하다.

5). Hashes

   - lists와 비슷하지만, '필드명'/ '필드값' 의 연속으로 이루어져 있다.

- 한 key에 포함될 수 있는 field-value 쌍의 최대 개수는 4,294,967,295 개이다.

4. Redis Client

1) Java

Java Client 는 여러가지 종류가 있다. http://redis.io/clients#java

그 중에 6개월 내에 커밋이 일어나고 있는 것은 Jedis / JRedis / lettuce / RedisClient / Redisson 이렇게 5가지 이며,

그 중에 Redis 에서 추천하고 있는 Client 는 Jedis / lettuce / Redisson 이렇게 3가지 이다.

이 중에 추천하고 싶은 Client 는 Jedis 인데 이유는 다음과 같다.

a) 가장 많은 Contributor 를 보유하고 있는 오픈소스 프로젝트이며 가장 오래된 클라이언트이다.

- 컨트리뷰터 수가 다른 프로젝트와 많은 차이가 날 만큼 많다.

Jedis : 108 / lettuce : 12 / redisson : 26

또한 국내에서 Redis 로 유명하고 책도 많이 쓰신 카카오 강대명씨가 커미터로 활동하고 계신 프로젝트가 바로 Jedis 다.

b) jedis는 이슈와 피드백이 많다.

다른 클라이언트에 비해서 Jedis는 사용자가 많고, 커밋 시점이 오래되었고 지금도 활발한 편이여서 이슈나 피드백이 많다.

따라서, 예제소스 찾기가 쉬우며 그만큼 레퍼런스가 많은 편이다.

c) Jedis는 사용이 간편하다.

처음 접근하기에 사용이 간편하고 버그에 대한 피드백도 빠른편, 그리고 여러가지 기능을 붙이지 않는 것도 장점이다.

jedis Github : https://github.com/xetorthio/jedis

참고자료

http://www.redis.io/documentation

http://mydb.tistory.com/210

http://www.joinc.co.kr/w/man/12/REDIS/IntroDataType

2015년 1월 11일 일요일

[Spring Framework] IoC에 대해서 그리고 ApplicationContext

IoC

이름부터 생소한 IoC 한번 알아보도록 하자.

1. IoC 란?

IoC(Inversion of COntrol)를 풀이하면 제어의 반전..(뭔소린지..뭔 반전이여..)

누군가가 제어를 대신해준다는 의미 정도로 해석이 가능할 것 같음.

IoC 개념은 스프링에서 처음 등장한 것이 아니라 서블릿 컨테이너와 EJB 컨테이너에서

이미 사용하고 있는 개념이다. 단지 지금까지 제대로 알지 못했을 뿐...

IoC 컨테이너 개념이 최근에 이슈처럼 등장하고 있는 이유는 그 동안 서블릿과 EJB 컨테이너가 가지고 있던 제약사항을 극복하고 새로운 대안의 IoC 컨테이너를 제공하자는 것이다.

2. 사용하는 목적

IoC를 사용하는 목적에 대해서는 지금까지의 클래스 호출 방식의 변화를 살펴볼 필요가

있을 것 같다.

3. Spring 컨테이너의 IoC

DL(Dependency Lookup) - 의존성 검색

- 저장소에 저장되어 있는 Bean에 접근하기 위하여 개발자들이 컨테이너에서 제공하는

API를 이용하여 사용하고자 하는 빈(Bean)을 Look up 하는 것

DI (Dependency Injection) - 의존성 주입

- 각 계층 사이, 각 클래스 사이에 필요로 하는 의존 관계를 컨테이너가 자동으로

연결해주는 것

- 각 클래스 사이의 의존 관계를 빈 설정(Bean Definition) 정보를 바탕으로 컨테이너가

자동으로 연결해주는 것

4. ApplicationContext

Object 생성을 책임지는 DAOFactory에 대응하는 것이 ApplicationContenxt 이다.

Spring에선 이 ApplicationContext를 IoC 컨테이너라 하기도 하고, Spring컨테이너라고

부르기도 한다. 또는 Bean Factory 라고하기도 한다.

ApplicatoinContext에는 DaoFactory 클래스와는 달리 직접 Object를 생성하고 그 관계를

맺어주는 코드는 없고, 그런 생성정보와 연관관계 정보를 별도의 설정정보를 통해 얻는다.

5. ApplicationContext가 Bean을 가져오는 동작방식

1. ApplicationContext는 앞의 @Configure 가 붙은 DaoFactory 클래스를 설정정보로

등록해두고 @Bean 이 붙은 메소드의 이름을 가져와 Bean 목록을 만든다.

2. 클라이언트가 ApplicationContenxt의 getBean 메소드를 호출하면 Bean 목록에서 요청한 이름이 있는지 찾는다.

3. 있다면 Bean을 생성하는 메소드를 호출해서 오브젝트를 생성시킨 후 클라이언트에게

리턴해준다.