딥블루딥블루

public class BaseHTableInterfaceFactory implements HTableInterfaceFactory {
	
	private HTablePool hTablePool;
	
	public BaseHTableInterfaceFactory(Configuration config, int maxSize) {
		hTablePool = new HTablePool(config, maxSize);
	}
	
	@Override
	public HTableInterface createHTableInterface(Configuration config, byte[] tableName) {
		return hTablePool.getTable(tableName);
	}

	@Override
	public void releaseHTableInterface(HTableInterface table) throws IOException {
		table.close();
	}
}

  public HTable(Configuration conf, final byte [] tableName)
  throws IOException {
    ...
    int maxThreads = conf.getInt("hbase.htable.threads.max", Integer.MAX_VALUE);
    if (maxThreads == 0) {
      maxThreads = 1; // is there a better default?
    }
    long keepAliveTime = conf.getLong("hbase.htable.threads.keepalivetime", 60);

    // Using the "direct handoff" approach, new threads will only be created
    // if it is necessary and will grow unbounded. This could be bad but in HCM
    // we only create as many Runnables as there are region servers. It means
    // it also scales when new region servers are added.
    this.pool = new ThreadPoolExecutor(1, maxThreads,
        keepAliveTime, TimeUnit.SECONDS,
        new SynchronousQueue(),
        Threads.newDaemonThreadFactory("hbase-table"));
    ((ThreadPoolExecutor)this.pool).allowCoreThreadTimeOut(true);

    /* 설명:
     기본 생성자의 설정이다.
     coreThread=1, maxThreads=Integer.MAX_VALUE 이고, SynchronousQueue를 사용한다.
     따라서 region 서버 수만큼 Thread를 생성하고 keepAliveTime 동안 유지했다가 Thread를 죽인다.
     뜨문 뜨문 호출되는 경우 Thread가 만들어졌다 없어졌다를 반복할 것이므로, 환경에 맞게 조정해서 사용하라.
    */
  ...
  }

참고: 소스분석 & O'Reilly - HBase 완벽 가이드

(1) 컬럼 조합 IN 쿼리

id|select_type|table  |type|possible_keys|key |key_len|ref |rows|Extra
1 |SIMPLE     |mytable|ALL |NULL         |NULL|NULL   |NULL|172 |Using where

index를 타지 않는다.

(2) FROM절 subquery

id|select_type|table     |type |possible_keys|key|key_len|ref|rows|Extra
1 |PRIMARY    |<derived2>|ALL  |NULL|NULL|NULL|NULL|15|Using where
2 |DERIVED    |mytable   |range|PRIMARY,idx_userid_createtime|PRIMARY|8|NULL|15|Using where

userid가 index를 탄다. groupid도 인덱스를 걸어줘야 할 듯.

(3) 각 컬럼에 대해서 IN query

id|select_type|table  |type |possible_keys|key|key_len|ref|rows|Extra
1 |SIMPLE     |mytable|range|PRIMARY,idx_userid_createtime|PRIMARY|16|NULL|9|Using where

결론) 3번이 가장 나아보임.

데이터와 서버를 동일한 주소 공간에 배치.

데이터의 키 값과 분산 서버 ID는 동일한 해시 함수로 동일한 주소 공간에 데이터와 노드를 배치.

중앙 서버 없이도 데이터를 관리하는 서버를 찾는 룩업에 성능이 좋다.

클러스터에 참여하는 서버의 추가/제거가 자동으로 이뤄지게 구성할 수 있다.

부하가 집중되지 않고 분산된다는 큰 장점이 있어, 극단적으로 큰 규모의 노드들도 관리할 수 있다.

종래의 순수 P2P에서 채용되었던 방식에서는 수십만 노드 정도가 한계였으나, DHT의 사용으로 수십억개의 노드를 검색범위로 할 수 있게 되었다. 그러나 DHT는 실제 구현이 어렵다.

키 공간 분할(keyspace partition)과 오버레이 네트워크(overlay network)로 구성된다.

- keyspace partition:

  * 분산된 서버에 키를 어떻게 배치시킬 것인가를 결정하는 것

  * 데이터의 hash(key) 값을 이용해 키 영역을 파티셔닝 시킨다.(range, interval)

- overlay network:

  * 물리적인 서버의 연결과 상관없이 논리적인 서버 간의 연결 관리와 키를 담당하는 노드를 찾아가는 메커니즘을 제공.

  * 특정 키를 서비스하는 노드를 찾아가는 라우팅 알로리즘을 제공한다.

DHT를 활용한 대표적인 시스템으로 비트토렌트(DHT를 확장하여 사용), eDonkey 등이 있다.

참고: 클라우드 컴퓨팅 구현 기술(에이콘), 위키백과

tcp 소켓을 닫을때 일반적으로는 normal tcp termination(4way closing handshake) 과정을 거치게 된다.

이 때, 소켓을 먼저 close한 쪽에 TIME_WAIT 상태로 소켓이 남아 있게 된다.

만약 서버가 먼저 close한 경우 TIME_WAIT 소켓이 가득차서 더 이상의 소켓을 accept 할 수 없는 상황이 발생할 수 있다.

이럴 때의 대안으로 normal tcp termination이 아닌 abortive close로 TIME_WAIT이 발생하지 않도록 할 수 있다.

(TIME_WAIT 상태가 왜 있는지 정확히 알고, 특정 상황에서만 사용하자.)

SO_LINGER with timeout 0

로 설정하고 close()를 호출하면 TCP FIN 대신 RST 이 나간다.

peer는 그 유명한 "Connection reset by peer" 에러가 발생하게 된다.

상세는 다음 글을 참조하자.

according to "UNIX Network Programming" third edition page 202-203, setting SO_LINGER with timeout 0 prior to calling close() will cause the normal termination sequence not to be initiated.

http://stackoverflow.com/a/13088864

gywn.net 의 텀블러와 Gizzard 분석 내용.

- http://gywn.net/2012/05/how_to_shard_big_data_in_tumblr/

- http://gywn.net/2012/03/new-tweet-store/

- http://gywn.net/2012/03/gizzard-a-library-for-creating-distributed-datastores/

대용량 시스템을 위한 데이타베이스 아키텍쳐-Sharding & Query Off Loading

- http://bcho.tistory.com/670

id sharding (인스타그램)

-http://charsyam.wordpress.com/2011/12/04/instagram-%EC%97%90%EC%84%9C-id-%EC%83%A4%EB%94%A9%ED%95%98%EA%B8%B0/

<TBD>...

Forward Proxy

클라이언트가 타겟서버의 주소를 프록시에 전달하여, 프록시가 요청된 내용을 가져오는 방식

  예) 클라이언트 Proxy 설정에 proxy.com을 설정하고, 주소창에 target.com을 입력하여 브라우징.

Reverse Proxy

프록시 서버로 요청을 보내면 프록시 서버가 '배후'서버로 요청하여 내용을 가져오는 방식. 이 때 Reverse는 "거꾸로, 역전"이 아닌 "배후, 뒷쪽"의 의미임. 클라이언트는 '배후' 서버를 알 수 없다.

  예) 클라이언트가 proxy.com에 요청하면 프록시 서버가 target.com 서버로 요청하여 결과를 반환.

  예) 많이 쓰는 nginx의 proxy_pass 설정은 reverse proxy 이다.

LongPolling 구현이 문제된 경우

 - 서버를 직접 만들고 경험한 내용이다.

 - Parent창이 longpoll 세션을 하나 열고, Child창을 띄워 별도의 longpoll 세션을 또 하나 열었다.

 - 각 세션에 논리 세션ID를 부여하고 서버측에서 데이터를 관찰.

 - 몇번 데이터가 왔다갔다 하면, Parent창과 Child창이 서로 다른 소켓으로 데이터를 보냄.

 - 브라우저가 물리 소켓을 pool 처럼 사용하는 것으로 추측. ?> pool처럼 사용한다고 함.

브라우저 동작 방식

 - 브라우저별 OS별 설정이 다르긴 하지만, 브라우저 프로세스 내에서 같은 도메인에 대해 열 수 있는 소켓 수는 제한적이다.

   * http 1.1 버전에서는 default=2 개라고 함. (사실 여부는 표준 문서 등 확인 필요)

   * 도메인별로 기본적으로 하나는 브라우저 메인이 사용하고, 나머지는 추가로 열어서 쓸 수 있다. 제한수가 2라는 의미는 추가로 열 수 있는 소켓수가 1이란 뜻이다.

   * 제한수를 넘어서 소켓을 열면 이전 소켓중 하나가 닫힌다고 함(역시 표준 문서 등 확인 필요)

 - 요즘 브라우저는 창을 여러개 띄우더라도 프로세스는 하나이고 쓰레드를 여러개 띄우는 형태.

 - 따라서, 창을 여러개 열어도 도메인이 같으면 제한된 소켓만 오픈할 수 있다.

 - 구글은 이런 브라우저 특성 때문에 빠른 로딩을 위해서 이미지 서버 도메인을 여러개 두고 한 화면 안의 img 태그에 여러개의 이미지 서버 도메인을 넣어 사용한다고 함. 병렬로 동시에 로딩 가능하다.

※ 위의 LongPolling구현의 문제는 Parent창이 추가로 longpoll 세션을 열었는데(2개), Child창이 뜨면서 세션을 하나더 연 경우(3개)가 됨.

해결

 - Child창을 띄우지 말고, Parent창 하나만 longpoll을 사용하거나,

 - Child창은 다른 도메인으로 longpoll 세션을 연다. (세션서버에 도메인을 여러개 등록) --> 잘 됨!

※ 더 정확한 내용 아시는 분은 댓글 부탁드립니다.

Generate a private key

key 파일 생성

$ openssl genrsa [-des3] -out test.key 1024

Generate Root CA Certificate

루트 인증기관(Root CA) 인증서 생성

$ openssl req -new -x509 -keyout cakey.pem -out cacert.pem -days 3650

Generate Self Signed Certificate

자체 서명 인증서 생성

$ openssl req -new -x509 -keyout cacert.pem -out cacert.pem -days 3650

keyout과 out에 같은 파일명을 주면되며, 분리하고 싶은 경우는

RSA PRIVATE KEY부분과 CERTIFICATE부분을 다른 파일로 분리하면 된다.

Generate Certificate signing request

인증 요청서(Certificate Signing Request) 생성

$ openssl req -new -key test.key -x509 -out test.csr

Sign certificate with private key

키로 인증서에 서명하기

$ openssl x509 -req -days 3650 -in test.csr -signkey test.key -out test.crt

[Optional] key에서 Password phase 삭제

Remove Password Requirement

$ cp test.key test.key.secure

$ openssl rsa -in test.key.secure -out test.key

Generate dhparam file(Diffie-Hellman)

$ openssl dhparam -out dh512.pem 512

※ if an error, "digest too big for rsa key", occures, simply use 1024 bits. (happens on openssl-1.0.x later)