http://terracotta.org/

Java용 분산 객체 저장소? 정도입니다. 자바만 쓸 줄 알면 쓸 수 있다고 하는데, 튜닝이야 어려운 작업이겠지만 기본적 사용방법은 간단합니다.

public class HelloClusteredWorld
{
    private static int counter;

    public static void main(String[] args) 
    {
        counter++;
        System.out.println("Counter is: " + counter);
    }
}

<tc:tc-config xmlns:tc="http://www.terracotta.org/config">
  <application>
    <dso>
      <roots>
        <root>
          <field-name>HelloClusteredWorld.counter</field-name>
        </root>
      </roots>
    </dso>
  </application>
</tc:tc-config>

그리고 서버 띄우고, 클라이언트는 dso_java HelloClusteredWorld 하면 끝.

그러나 이런 shared data가 왔다갔다 하는 시스템을 볼 때마다 느끼는 점이 하나 있습니다. 바로, 데이터는 오고 가는데 그것에 대한 처리는 오고가지 않는다는 점입니다. 예를들어, 렌더링을 하는 프론트엔드는 백엔드에서 오는 데이터를 어떻게 처리할지 알지 못합니다. 그러면 보통 프레임웍은 이런식으로 작성되죠.

Frontend(FE) - Backend(BE) - Database(DB)

문제는 FE가 단 하나가 아닐 때 발생합니다. FE는 BE를 통해 데이터에 대한 추상화를 쉽게 진행하지만, 만약 또 다른 누군가가 FE2를 만들고자 한다면?

FE -    BE - DB
        /
FE2 -

그런데 만약 BE가 FE2로 넘겨주는 데이터 구조가 바뀌면 어떻게 할까요. 그럴때는 구글의 protocol buffer와 같은 versioning을 지원하는 포멧이 적당할 것입니다.

하지만, 만약 그 데이터를 다루기위한 공통된 코드가 필요하다면 어떻게 될까요. 예를 들어 BE뒤에 DB만 있었는데 DB2가 생겼다고 해보겠습니다. FE2는 DB와 DB2에서 오는 정보를 사용하고, FE는 DB에서 오는 정보만 사용한다고 해보겠습니다. 정리하면,

1) FE – DB 사용
2) FE2 – DB, DB2 사용

이런 환경입니다.

역시 protocol buffer(pb)는 이런 환경에서도 살아남습니다. FE에서는 pb에서 자기가 다루겠다고 생각한 부분만 다루고, FE2는 자기가 다루겠다고 생각한 pb 내 필드만 보면 되기 때문이죠.

문제는 실환경은 이렇게 간단하지 않다는 것입니다. 어떤 시스템도 멈춰있는 시스템은 없고, 따라서 DB나 DB2에서 오는 값은 불안정합니다. 만약 DB는 FE2 개발자와는 별도의 팀이고, FE2개발자가 DB에서 넘어오는 값이 하도 불안하여 sanitize 를 실시하기로 마음먹었다고 하겠습니다. 우연찮게 FE도 그 불안성을 알고 있어 BE와는 별도로 DB에서 오는 값에 sanitize를 합니다. 그렇다면, 이 경우 FE2 개발자팀은 FE 개발자팀의 코드를 *우연히* 보고 ‘아하.. 이런 sanitize를 해야하는구나’ 하면서 코드를 카피해오는 수 밖에 없습니다.

하지만, 만약 pb에서 sanitize() 란 메소드를 제공한다면 이 문제는 더 쉬울 것입니다. FE2 개발자는 FE개발자가 pb내에 만든 sanitize를 호출하면 간단하게 문제를 해결할 수 있으니까요. 어찌보면 당연한 수순입니다. 초기엔 데이터가 있었고(struct를 FE와 DB가 공유), 추상화가 있으면(protocol buffer), 다음은 코드가 옮겨다닐 차례(code mobility)입니다. Code mobility의 답은? 아직 모르겠습니다.