IT로 세상을 이롭게

1. 조물주가 이 땅에 특별한 목적을 가지고 생명체를 창조해내었다면, 

프로그래머 역시 어떠한 목적이 있기 때문에 한 객체를 시스템내에서 창조한다.

창조된 생명체는 자신의 역할을 다할 책임이 있다.

<모델링>

Object oriented programming, 이른바 OOP라 불리우는 개념의 기본이다.

흔히 모델링을 접하게 되면 현실세계를 컴퓨터속으로 투영시키는 작업이 모델링이라는 말을 듣게 된다.

RDB모델링에서는 Entity를 도출하고 각 Entity간의 Relation을 정의하는 것이 시작이 된다.

어떠한 정보를 저장하는 가에 중점을 두고 작업을 진행하는 것이 DB모델링이라면

하나의 Object가 어떻게 동작하는가에 중점을 두고 작업을 진행하는 것이 Application모델링.

그중에서도 OOP에 해당한다.

<Responsibility>

 Object는 속성과 행위를 갖게 되며 각각 변수와 메소드라는 형태로 표현이 된다. 개발자는 이 object를 통해서 본인이 의도한 바를 구현하고자 한다. 본인이 하고 싶은 일을 대신 시킨다고 봐도 무방하다.

하나의 object로 모든 일을 처리할 것인지, 여러개의 object로 나누어서 처리할 것인지, 나눈다면 몇개로 어떻게 나눌것인지는 만드는 사람의 몫이다. 해당 시스템이 궁극적으로 이루고자 하는 목적과 범위가 무엇인지를 명확히 파악하고 그에 맞게 적절하게 구성하는 것이다.

 하나의 object로 모든 일을 처리하는 방식을 흔히 God object라고 부르며 이는 대표적인 anti-pattern의 하나이다. 모든 변경사항에 영향을 받기 때문에 항상 변경될 수밖에 없다.

이는 유지보수성을 심각히 저하시켜서 결국 재개발을 할 수 밖에 없다.

 하나의 변경사항에 대한 수정의 범위는 한곳 이 되는 것이 바람직하며(coupling), 유사한 기능에 대해서도 한곳에 모여있는 것이 좋다. (cohesion)

IT시스템의 구현은 현실세계와 밀접한 관련이 있다고 생각합니다.

짧지않은 기간동안 공부하고 경험한바를 바탕으로 마구 써내려가봅니다.

=========================================================================================

1. 조물주가 이 땅에 특별한 목적을 가지고 생명체를 창조해내었다면, 

프로그래머 역시 어떠한 목적이 있기 때문에 한 객체를 시스템내에서 창조한다.

창조된 생명체는 자신의 역할을 다할 책임이 있다.

2. 어떠한 생명체도 혼자서 모든 것을 수행하지는 못한다.

자신이 할 수 있는 것은 자신이 하고, 그 역할을 벗어나는 것은 전달하여 요청한다.

그리고 의사소통이 가능한 존재들끼리만 요청을 주고 결과를 받을 수 있다.

3. 자연세계에서 한 객체가 다른객체에게 간접적으로 영향을 받을지언정, 직접적으로 영향을 받는 경우는 거의 없다.

소프트웨어에서 역시 가장 이상적인 객체라 함은, 다른 객체에 의해서 영향을 받는 것이 최소화되며 자신의 창조목적을 다하는 것이 기본으로 본다. 가끔 특수한 경우가 있을 수는 있지만 빈번하게 발생한다면 이는 자연스럽지 못하다.

4. 생태계에서 어떤 객체가 자신의 life cycle을 최대화 시키기 위해서는 변화에 잘 적응해야만 한다.

변하는 부분과 변하지 않는 부분을 구분하고, 변하는 부분에 있어서는 최대한의 유연성을 발휘한다.

그러나 변하지 않는 부분에 대해서는 견고함을 최우선으로 삼는다.

최초에 설계된 유연성을 넘어서는 경우에는 변화를 수용하지 못하고 파괴의 순간을 맞이하는 것이 공통적인 부분이다. 이 세상에 영원한 것은 없다.

5. System을 우리는 계 라고 표현한다.

하나의 계는 여러가지 공통의 속성을 공유한다. 우리의 환경을 예로 들자면 비슷한 온도, 습도, 토양, 공기, 일조 를 공유하는 곳이다. 계 안에서는 여러 생물이 각자 평안함을 유지하면서 살게된다.

그러나 그 안의 공유하는 균형이 깨지는 순간 심각한 이상현상을 초래한다.

거꾸로 계 내에서 살던 생명체가 다른 계 로 이동하는 순간 동일한 행위를 보장하지는 못한다.

소프트웨어에서는 이러한 경계안 쪽을 시스템 안정성,표준선을 보장하는 최소의 단위로 본다.(boundary)

계는 계의 집합으로 구성된다. 각 생명체는 하나의 계를 유지하며, 여러 생명체가 모여서 생태계를 구성하며, 다양한 생태계가 모여서 지구를 구성하고 있다.

6. 어떠한 객체이던지 점진적으로 발전한다.

태어날때부터 모든 기능이 완벽한 생물은 없다. 성장하면서 주위의 변화를 습득하면서 점차 부분부분의 기능을 강화해나간다. 때로는 필요에 따라서 기능을 퇴화시키기도 하고, 특정기능을 발전시키기도 한다.

중요한 것은 이러한 점진적 발전을 위해서는 기능의 규모에는 관계없이 반드시 최소Set은 가지고 있어야 한다는 점이다. 기본적으로 머리,몸통,팔,다리는 있어야지, 팔만 있어서는 발전의 가능성조차 없다.

7. 연관성이 없는 객체는 없는 존재의 의미가 없으며, 비슷한 연관성을 가진 객체는 서로 라이벌이다.

직접적이던 간접적이던 객체들은 서로 연관성을 가지고 있다.

다른 객체와 연관성이 전혀 없이 홀로 있는 객체라면 그것은 이미 객체가 아니다. 사라진다.

이와는 반대로 서로 비슷한 연관성을 가진 객체가 있다면 이 객체들은 서로 라이벌이다.

어느 한순간이 되면 하나의 객체만 남게될 것이다.

=========================================================================================

이렇게 정리하다보면 각 객체를 특별하게 구분할 수 있는 요소는 결국 관계성으로 보입니다.

객체가 가지고 있는 하나하나의 기능에 집중해서 보다보면 큰 그림을 놓치게 되고요,

객체들이 살고있는 환경만 바라보게 되면 작은 그림을 놓치게 됩니다.

그래서 저는 시스템을 구축하거나 분석/설계 해야하는 업무를 수행할 때 아래와 같은 순서로 접근합니다.

1. 이 시스템의 목적은 무엇인가? 어디까지가 시스템의 범위인가?

2. 그 목적을 이루기 위해서 구성되고 있는, 또는 구성되어야 하는 컴포넌트는 무엇인가? 최소필요기능은 무엇인가?

3. 컴포넌트들이 보인다면 서로 관계는 어떻게 맺어야 하는가? 

4. 유사한 관계 혹은 충돌되는 관계는 없는가?

5. 컴포넌트안에는 구체적으로 어떤 객체들이 만들어져야 하는가? 얼마나 많이 만들어져야 하는가?

6. 이제는 보다 상세하게 각 객체들의 책임을 상세하게 정의해보자.

영화Matrix를 보면 아키텍트가 곧 창조주이죠.

이러한 모든 요소를 고려하여 각 객체들이 오래~ 행복하게~ 살수 있는 하나의 계를 구축해주는 것이 목표아니겠습니까. 만들어는졌으나 아무것도 하는일이 없는 객체, 혼자서 모든 일을 도맡아 하는 객체는 얼마나 힘들까요.

신처럼 처음부터 끝까지를 모두 완벽히 해낼 수 있다면 가장 이상적이겠지만 현실은 불가능입니다..

akka를 보던 중 at most once 전달이기 때문에 메시지의 유실이 발생할 수 있다는 내용이 보인다.

(http://doc.akka.io/docs/akka/snapshot/general/message-delivery-reliability.html)

그렇다면 akka를 못 쓰는 것인가? 보완하도록 메커니즘을 구성해야 되겠네....

생각난김에 메시지전송 패턴에 대해서 간략히 정리를 해본다. 

• at-most-once delivery means that for each message handed to the mechanism, that message is delivered zero or one times; in more casual terms it means that messages may be lost.
• at-least-once delivery means that for each message handed to the mechanism potentially multiple attempts are made at delivering it, such that at least one succeeds; again, in more casual terms this means that messages may be duplicated but not lost.
• exactly-once delivery means that for each message handed to the mechanism exactly one delivery is made to the recipient; the message can neither be lost nor duplicated.

1. At least once

 실패가 일어나더라도 메시지의 유실이 발생해서는 안되고 복구에 너무 오랜시간이 걸려도 안된다.

메시지는 최소한 한번 이상 전달되어야 한다

<context>

메시지의 전달을 확실히 보장하는 것이 최우선이며, 중복이 발생해도 무방하다.

<solution>

각 메시지를 수신했을 때 ack응답을 되돌려주도록 한다. 만약에 ack를 정해진 시간내에 못 받을경우 다시 보낸다.

2. At most once

 메시지는 많아도 한번 전달된다.

 <context>

 중복없이 빠르게 처리하는 것이 목표이다. 유실되어도 critical하지 않은 경우

 <solution>

 전송에 관련된 상태등을 기억하지 않는다. fire-and-forget

3. Exactly one

 메시지는 정확하게 한 번만 전달되어야 한다. 금융권이나 기타 트랜잭션을 반드시 보장해야하는 경우다. 중복x!

 <context>

 분산처리 환경에서 매우 중요한 요건으로 메시지 유실이 발생해서도 안되고, 중복이 발생해도 안된다.

 <solution>

 메시지를 생성할 때 unique message identifier를 붙인다. 이 identifier를 이용해서 송신자와 수신자간에서 발생한 중복메시지를 filter처리한다.

http://www.cloudcomputingpatterns.org/

 최근 몇 년전만 해도 응답시간 수초, 수십개의 서버, 기가단위의 데이터로 시스템이 구성되었지만 오늘날에는 모바일, 수천대의 클라우드 기반환경으로 변화하면 millisecond단위의 응답시간, 페타바이트 데이터 등의 요건으로 인해서 과거의 소프트웨어 아키텍처로는 이를 수용하기가 어려운 상태이다.

 결국 우리는 Responsive, Resilient, Elastic and Message Driven 한 시스템을 원하고 이것을  Reactive Systems이라고 부른다. ( 보다 유연하고 scalabe하면서 장애도 방지하는 그런 시스템)

Reactive Systems are:

과거에는 WAS기반으로 앞단에 load balancer를 두는 아키텍처가 일반적이었다. 현재도 일반적이다.

이러한 구조는 일단 확장이 어렵다. WAS를 추가하거나 서버를 추가할때 들어가야 할 설정들도 많고, 배포정책도 정해져야 한다. 기동/재기동에 따라서 묶이는 서비스의 단위(도메인)가 커서 영향범위도 넓다고 생각한다.

이를 보완하기 위해서 따라서 scale out이 쉽게 가능한 micro service 아키텍처가 많이 거론되고 있다.

뒷받침되어야 할 것들에 대해서 생각해보았다.

1. 외부로부터 데이터 입력/출력을 담당하는 부분

 데이터 사용량에 따라서 쉽게 scale out이 가능해야 한다. 이는 별도의 설정없이 slave node의 추가만으로 사용이 가능해야 한다. zookeeper나 hadoop의 구조를 생각하면 될 것 같다.

=> 4번과도 연관성이 있으며 다양한 형태의 서비스(ex, spring/storm/spark)와 효과적으로 연결되기 위한 grid bus형태가 필요하지 않을까 고민된다.

2. 실제 비니지스를 담당하는 어플리케이션의 모듈화

 각 어플리케이션을 설계할때 참조관계를 깊이 고려해야 한다. 이는 배포의 단위와 직결되며, 커지면 커질수록 단위 서비스를 위해 필요한 작업들이 증가하게 된다. application design에서는 cohension과 coupling으로 예전부터 강조되어왔던 개념이며 refactoring, restructuring을 통해서 초기단계뿐만 아니라 개발/운영단계가 진행될 때에도 계속 병행되어야 한다.

=> 이 부분은 framework개발을 할때부터 고민해왔던 부분인데(온라인/배치/센터컷을 어떻게 자연스럽게 연결할 것인지.. @.@), 앞으로도 계속 봐야할 것 같다.

 변하는 부분과 변하지 않는 부분에 대한 식별이 잘 이루어져야 한다. 무한하게 유연한 설계는 있을 수가 없다. 있다한들 엄청 복잡해지면서 아무도 사용하지 않게된다.. ㅜㅜ

3. immutable state

2번과 연관되는 내용이다. 어플리케이션 인스턴스가 일을 할때에는 순수히 메시지에 의존해서 일을 하도록 해야한다. state를 가지게 되는 순간 다양한 메시지에 대해서 어떻게 반응해야 하는지 고려가 되어야 하며(과거 java멤버변수들..), 설계복잡도가 급격히 증가하게 된다.

=> reactive programming를 보다가 과거에 나왔던 actor model에 대해서도 자연스럽게 접하게 되었고 akka도 보고 있다..  scala를 공부하면서 느끼는 내용은 함수형+객체형 언어스타일대로 구현하다보니 이게 자연스럽게 이루어진다. scala에서는 val을 최대한 사용할 것을 권장하고 있다. ^^;

4. 실시간 대용량 데이터 처리

 이미 hadoop기반의 배치성 빅데이터 분석은 어느정도 정착이 된 상태이고, storm이나 spark streaming을 통한 실시간 데이터분석도 많이 활용되고 있다. scale out과 연관되어서 약간은 다른 부분을 생각해보고 싶은 것은 분석대상이 될 데이터에 수집/처리에 대한 부분이다. 역시 1번과 연관성이 있지만 5번과 연관성이 더 깊다고 본다. 저장소에 대한 고민도 필요한 것 같다. 쉽게 쌓고, 쉽게 접근할 수 있어야 한다.

=>수집/처리/분석에 대한 Storage를 하나의 아키텍처로 가는것은 부담이 있기 때문에 NoSQL, HDFS, RDB의 적절한 조합이 필요하다고 생각한다. 수집부분에서는 NoSQL로 무조건 쌓아두고, ACID가 보장되어야 하는 데이터들에서는 RDB처리한다. 수집과 처리가 끝난부분에 대해서 선택적으로 HDFS로 옮겨서 분석을 수행한다.(사실 Spark가 너무 좋아져서 이부분이 점점 의미가 없어지기는 한다..;)

5. 클라우드 기반

 하나의 서버를 추가하는 것이 손쉽게 이루어져야 한다. 서버자원이 많이 남아돌아서 이를 충분히 활용하기 위해서 가상화기술이 발달해왔다면 앞으로는 어플리케이션 레벨에서의 가상화를 위해서 발전될 것으로 예상한다.

=> docker 기술이 또 주목받고 있다. 하나의 서비스를 이미지화하여 서비스사용량이 증가하면 쉽게 대응할 수도 있고, 어플리케이션 변경이나 버전업이 생길경우에도 이미지를 새로 생성하여 배포하도록 한다. OS가 포함되지 않아서 이미지크기도 부담이 없다.

 그 외에도 데이터가 올라와야 하는 Device나 Web, Open API들의 표준화, 다양한 서비스를 효과적으로 연계하기 위한 메시지 포멧/프로토콜 등 고민해야 할 부분이 많다. 하지만 시도해볼 가치는 있다고 생각한다.

 이와 같은 아키텍처를 통하면??

메뉴에서 각 버튼이 하는 액션을 하나의 서비스로 정의하여 구현 => 사용자가 많이 클릭하는 서비스는 인스턴스를 많이 띄우면 된다!

앞으로의 목표는 다양한 사업에서 적용될 수 있는 클라우드 기반 아키텍처가 포함된 플랫폼을 만들어서 사용자(비니지스 개발자)에게 쉽게 제공하는 것!

========================================================================================================

 소프트웨어는 역시 코드로 말해야 한다. 워낙 다양한 오픈소스가 있어서 받아보고, 돌려보고, 읽어보고 해야하는 내용도 많고 이들을 엮어서 사용하는 것도 쉽지 않다. 또한 중요한 것은 해당 프로젝트의 개념과 목적을 명확히 이해해야 한다.

1)용도에 맞지 않게 사용하거나,

2)비슷한 개념을 가진 오픈소스를 섞어쓰거나

3)비슷한 목적이지만 구현방법이 다른 오픈소스를 같이 쓰게 되면 두고두고 고생한다.

빅데이터 배치처리외에 실시간 대량데이터에 대한 처리요건도 늘어감에 따라 스터디를 진행하고 있다.

대표적으로 Storm이 있는데 Spout와 Bolt의 연결을 이용한 Stream 처리 엔진으로 보면 될 것 같다.

모든 책에서 대표적으로 소개되고 있는 로그파일처리부분을 살펴보면 

- 로그파일은 flume을 통해서 읽고

- kafka를 통해서 message 병렬분산 처리를 한다.

- storm과의 연결은 kafka spout를 통한다. (인터넷에 다양한 spout가 이미 존재한다.)

각 구성요소의 개념을 간단히 살펴보면

1. Spout
데이터를 입력받는 곳이다. 공식사이트에서 수도꼭지로 표현되며 단어의 의미는 주둥이,분출

데이터를 끌어오는 개념이며 현재 다양한 source로 부터 받을 수 있도록 spout이 존재한다.

spout과 spout간의 연결도 가능하다.

- open메소드 : 최초 한 번 수행되며 일반적으로 환경구성이 필요한 내용들이 들어간다.

- nextTuple 메소드 : 데이터가 넘어올 때 마다 수행되며, 실제 데이터를 분출시키는 부분이다.

SpoutOutputCollector를 통해서 데이터를 전달한다. (collector.emit메소드를 호출)

- declareOutputFields  : 보내는 데이터에 대해서는 key값을 정의해주어야 OutputFieldsFieldsDeclarer.declare메소드를 호출한다. 해당 Spout에 연결된 Spout/Bolt에서는 이 Key값을 통해서 Value를 가져올 수 있다.

전달 키값을 동일하게 쓰면 받는 쪽에서는 구분없이 하나의 데이터 처리가 가능하며 
전달 키값을 분리하면 분리 처리도 가능함

키값에 대해서는 Topology정의시 상수화 하는 것도 하나의 방법이 될 수 있다.

ack / fail은 필요에 따라 구현한다.

2. Bolt
실제 각 활용영역별로 커스터마이징이 이루어져야 하는 부분이다.

- prepare : 최초 한 번 수행되며 준비에 필요한 내용들이 들어간다. (ex, 환경, IP 등)

- execute : 실제 넘어온 Tuple을 가지고 로직을 수행한다. tuple.getValueByField 메소드를 호출하여 사전에 정의된 Key값을 통해서 value를 가지고 올 수 있다.

- declareOutputFields  : Spout와 동일함

3. Topology

만들어진 Spout와 Bolt를 서로 연결하여 망을 형성한다.

TopologyBuilder를 통해서 구성하고 subtmit한다.

이후 해당 Topology는  사전에 기동된 Storm 프로세스 ( Nimbus )에 전달되고 Nimbus는 각 Supervisor로 할당하여 작업을 수행한다.

작업이 수행되면 별도로 Worker 프로세스가 기동되며 Worker 프로세스내에 Topolog상의 component가 분배되어 Thread로 수행된다. 커스터마이징을 통해서 수동으로 component위치를 지정하여 자원사용량을 분산시키는 것도 가능한다. 

topology 별로 최소 worker 1개 이상이 필요하고 그 이상 지정도 가능하다.

4. Architecture

Nimbus : HDFS의 Namenode와 유사하여 마스터 노드의 역할을 한다. Topology를 받아서 각 Supervisor에게 배포하고 작업을 수행하며 추적한다.

Supervisor : Nimbus로부터 명령을 받아서 Worker 프로세스르 구동한다.

Worker : 실제 컴포넌트 (Bolt, Spout)가 할당되어 task를 수행한다.

5. 정리
분산 병렬처리를 위해서는 기본적으로 Key/Value형태의 데이터로 구성되어야 핞다. (ex, Map/Reduce, Spark 등)

Storm도 마찬가지로 데이터 전달시 Key/Value형태로 전달하도록 되어있다.

빅데이터를 이야기 할 때 항상 나오는 Iteration 과 Interactive를 좀더 공부할 필요가 있다.

6. Storm과 Spark 간단비교

 a. Storm
Apache에서 Storm을 보면 Distributed, real-time computation system으로 소개된다.

실제 Spout나 Bolt의 구현부를 보면 건단위의 흐르는 데이터 (Streaming...) 처리에 적합한 구조로 되어있다.

로그파일은 어쨌든 파일인데 왜 Storm으로 처리하는 예제가 나올까라는 의문을 가졌었는데 로그파일의 경우 실시간 row단위로 쌓이는 데이터이기 때문에 흘러가는 데이터로 보는게 맞다는 생각이 들었다.

어쨌든 Storm은 데이터를 저장하는 것이 아니라 계속 흘려보내는 의도로 출발된 구조로 보면 되겠다.

번외로 Spout와 Bolt간의 특정데이터를 공유해야 할 필요가 있을때는 IMDG를 사용할 수 있을 듯 하다.

 b. Spark

Apache에서 Spark는 Fast and general engine for large-scale data processing 으로 소개된다.
내용과 실제 구현방법을 보면  배치성처리 컨셉이 강하며, 기본적으로는 Map/Reduce처리방식과 유사하다.

RDD개념을 도입하여 Disk I/O를 최소화 했기 때문에 iteration에 강하고, 결과를 다시 인풋으로 받는 (ex, kmeans) 알고리즘 구현시 강점이 있다. Stream처리를 위한 개념으로 Spark Streaming도 있지만 결국 간격이 짧은 배치를 수행하는 컨셉이다.
기본적으로 RDD생성은 파일 또는 다른 RDD에서만 가능하기 때문에 실시간 Stream에는 적합하지 않는 것으로 보인다.