365 new days, 365 new chances

회사에서 다른 팀의 outage report를 둘러 보던 중 Range Request 라는 키워드가 눈에 띄었다. 
정확히 어떤 종류의 요청인지 모르겠어서 Range Request 에 대해 찾아보면서 정리!

HTTP Range Request란?

• 서버 -> 클라이언트로 HTTP 메세지의 일부만 전송할 수 있도록 허용하는 기술
• 대용량 미디어 또는 파일 다운로드 도중 일시 정지, 다시 시작 기능, Pagination 기능 등에 유용히 사용됨
• 클라이언트가 Range 헤더를 통해 특정 리소스의 일부분만 요청하면 서버가 그 부분만 리턴하는 방식으로 동작
  • e.g test.zip 파일을 100byte ~ 200byte 부분만 다운로드하는 경우 등
• 해당 서버가 Range Request 지원 시, HTTP Header에 Accept-Ranges: Bytes 와 같은 설정 존재
• HTTP 응답 헤더 내 Accept-Ranges 설정이 없거나, Accept-Ranges: none 으로 설정되어 있는 경우 해당 기능 지원하지 않음

#HTTP request header
GET /test.zip HTTP/1.1
Range: bytes=100-200
...

References

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests

테스트용 Jenkins 를 구성하다보면 Production 환경의 Jenkins plugins들을 동일하게 설치하고 싶은 경우가 있다.

적게는 몇십 개부터 몇백 개까지 존재하는 plugins들을 일일이 따라 설치하거나 굉장한 중노동일것이다..

이때 유용하게 사용할 수 있는게 Rsync

Rsync를 활용해 Production 환경의 Jenkins plugins를  테스트용 Jenkins 서버에 copy 해보았다.

테스트 한 내역 설명에 앞서 Rsync 에 대해 먼저 짚어본다.

Rsync란?

• Remote Synchronization의 약어로 서로 다른 서버간에 파일들을 효율적으로 전송&동기화 시켜주는 utility
• 파일들의 timestamp와 수정 시간 등을 비교하며 synchronizing 수행
• delta encoding이라는 알고리즘을 사용하여 네트워크 사용량을 최소화함
• Package 관리 시스템들이 software repositories와 mirror sites를 synchronizing 하는 데 주로 사용하는 utility
• 파일 및 디렉토리의 소유자, 권한 정보 등도 복사됨
• SCP(Secure Copy)보다 속도가 빠름

Jenkins 를 구성하면 ${JENKINS_HOME}/plugins 디렉토리에 plugins 파일들이 위치하게 된다

아래와 같이 plugins 디렉토리 내 plugin 파일들 확인이 가능하다. (jenkins 처음 설치 시, recommended plugins만 설치한상태)

[irteamsu@hyewon-dev001-infraops-jp2v-dev .jenkins]$ cd plugins/
[irteamsu@hyewon-dev001-infraops-jp2v-dev plugins]$ ls -al
total 83576
drwxr-xr-x 78 irteamsu irteamsu     8192 Sep  7 17:42 .
drwxr-xr-x 13 irteamsu irteamsu     4096 Oct 12 15:47 ..
drwxr-xr-x  7 irteamsu irteamsu      124 Sep  4 16:20 ace-editor
-rw-r--r--  1 irteamsu irteamsu  4279042 Sep  4 16:20 ace-editor.jpi
drwxr-xr-x  4 irteamsu irteamsu       56 Sep  4 16:20 ant
drwxr-xr-x  4 irteamsu irteamsu       56 Sep  4 16:20 antisamy-markup-formatter
-rw-r--r--  1 irteamsu irteamsu  2858119 Sep  4 16:20 antisamy-markup-formatter.jpi
-rw-r--r--  1 irteamsu irteamsu    82963 Sep  4 16:20 ant.jpi
drwxr-xr-x  4 irteamsu irteamsu       56 Sep  4 16:20 apache-httpcomponents-client-4-api
-rw-r--r--  1 irteamsu irteamsu  1761975 Sep  4 16:20 apache-httpcomponents-client-4-api.jpi
drwxr-xr-x  4 irteamsu irteamsu       56 Sep  4 16:20 bouncycastle-api
-rw-r--r--  1 irteamsu irteamsu  4885133 Sep  4 16:20 bouncycastle-api.jpi
drwxr-xr-x  5 irteamsu irteamsu       70 Sep  4 16:21 branch-api
......

현재는 확장자가 .jpi 인 파일들만 확인되지만 Jenkins 를 운영하다보면 .hpi 확장자의 파일들도 종종 볼 수 있다.

본 내용 설명에 앞서 .jpi vs .hpi 파일을 잠깐 비교해 본다(나도 작업하면서 늘 궁금했지만 이제서야 찾아본다 ㅎㅎ..)

.hpi vs .jpi ?

• .hpi는 Jenkins가 Hudson이 었을 때 legacy 확장자 (h came from Hudson)
• .jpi는 Jenkins가 플러그인 설치 시, 생성되는 파일 확장자 (j came from Jenkins)
• 동일한 플러그인에 대해 .hpi, .jpi 파일이 둘 다 존재하는 경우, .jpi를 우선 인식하여 적용함

자 그럼 이제 production Jenkins의 plugins를 내 test 서버의 Jenkins로 동기화하기 위한 shell 스크립트를 짜본다

• copy_jenkins_plugins_to_test.sh

#!/usr/bin/env bash

set -eu

TARGET_HOST=hyewon-dev001-dev
TARGET_DIR=/home/www/jenkins/.jenkins/plugins

RSYNC_USER=$(whoami)
RSYNC_CMD=/usr/bin/rsync
RSYNC_OPTS="-avzh --delete"

RSYNC_EXCLUDE="--exclude=jobs/"
RSYNC_EXCLUDE="${RSYNC_EXCLUDE} --exclude=config-history/jobs/"
RSYNC_EXCLUDE="${RSYNC_EXCLUDE} --exclude=nodes/"

${RSYNC_CMD} ${RSYNC_OPTS} ${RSYNC_EXCLUDE} -e ssh ${TARGET_DIR}/ ${RSYNC_USER}@${TARGET_HOST}:${TARGET_DIR}

# Restart Jenkins(TARGET_HOST)
token='eqAY62UwzGK9Cl.n_sE27pTcLnYIWu/dR2T974X0'
body='{ "restartTask":{ "apache":"do nothing", "tomcat":"restart with clean working directory" }, "restartPlan":{ "numberOfConcurrentRestart":1 } }'
curl -vvv -XPOST -H "Authorization: Bearer ${token}" -H "Content-Type: application/json" -d "${body}" http://${deployment_system}/rDLgUpP2tJ/projects/jenkins-master-dev:test/restarts

[Oracle Developer Meetup 6th 참석 후기]

1) 일시: 2018.05.19

2) 장소: 아셈타워 15층 오라클

3) 주제: Kafka 제대로 이해하기

           - Kafka, 데이터 플랫폼의 최강자

4) 강연자: 고승범 (카카오 시스템셀 인프라팀 근무中) 

지원했던 프로젝트가 빅데이터 관련 프로젝트라 대용량 로그 데이터 수집 및 처리를 위해 Kafka를 사용했었다.

당시에는 개발환경 및 웹 프로젝트 구성 지원만해도 만만치않아, Kafka에 대해 따로 알아볼 여유가 없었는데

우연히 Kafka 관련 기초 세미나가 열린다해서 가봤당!

Kafka 에 대한 내용 뿐만아니라, 최신 IT 트렌드들을 공유하는 자리는 어떨까 하는 궁금증도 많았다.

어떤 사람들이 어떤 관심사를 가지고 모이는지도 궁금했구, 다른 사람들은 무슨일을 하고있나도 궁금했다

이제 막 도입해보려 온 사람들이 대부분이었지만, 벌써 Kafka를 도입해서 운영하고 있는 회사들도 생각보다 많았다.

이벤트로 Kafka 관련 책도 받았당!!!

#Kafka란?

Kafka란 대용량 메시지를 수집하고 실시간으로 처리하는 오픈소스 소프트웨어로, 2001년 LinkedIn이 개발하여

2011년 초 오픈소스 프로젝트(Apache Kafka) 로 전환되었다.

Kafka는 높은 데이터 처리량, 고 성능 분산 스트리밍 기능으로 빅데이터, 머신러닝, 블록체인 구현 시

자주 사용되는 기술로 떠오르고 있다.

#분산 스트리밍 플랫폼?

 - 메세지 큐 처리와 비슷하게 스트리밍 형태의 데이터를 publish 하고 subscribe 하는 시스템

 - 스트리밍 데이터 실시간 처리

#Kafka 언제 사용하면 좋을지?

  - 시스템 간에 안정적인 실시간 스트리밍 데이터 처리 파이프라인을 구축하고자 할 때

  - 데이터를 실시간으로 변형하거나, 반응해야 하는 실시간 스트리밍 어플리케이션 구축 시

  - 대용량 실시간 로그처리에 특화된 아키텍처 설계를 지녀 기존 메시징 시스템보다 우수한 성능의

    로그처리 시스템 구축하고자 할 때 유용

   >> 기존 메시징 시스템(ActiveMQ, RabbitMQ 등) 대비 차이점은 뭐지?

        Kafka가 좋다좋다 하는데, 기존 메시징 시스템도 써본 적이 없어..장점이 추상적으로 와닿는다.

        일단 기존 메시징 시스템 대비 Kafka가 갖는 장점은 아래와 같다고 한다.

        (1) 분산 시스템을 기본으로 설계되어, 기존 메시징 시스템에 비해 분산 및 복제 구성이 용이함

        (2) JMS API나 AMQP 프로토콜을 사용하지 않고, 단순히 메세지 헤더를 지닌 TCP 기반의 프로토콜을

            사용하여, 오버헤드 감소

        (3) 기존 메세징 시스템은 기본적으로 메시지를 메모리에 저장하지만, Kafka는 메시지를 파일 시스템에 저장함

            --> 별도의 설정을 하지 않아도 데이터의 영속성이 보장됨

            --> 기존 메세징 시스템은 처리되지 않은 메시지 수가 많을 수록 시스템 성능이 현저히 감소하나,

                 Kafka는 이에 영향 받지 않음. 실시간 처리뿐만 아니라 주기적인 배치 작업에 사용할 데이터를

                 쌓아두는데도 용이함

            --> 처리된 메시지를 바로 삭제하지 않고 파일 시스템에 보관후 설정한 유효기간이 지나면 삭제.

         (4) 기존 메시징 시스템은 Push 방식(broker가 consumer에게 메시지 push) 이지만, Kafka는 consumer가

              직접 메시지를 가지고 가는 Pull 방식으로 동작함. Consumer는 자신의 처리능력만큼만 pull 해오기 때문에

              최적의 성능을 낼 수 있음 (broker의 메시지 관리 부담 경감)

            --> 강연하셨던 고승범님도 이부분을 많이 강조하셨었다. 운영하다보면 consumer 쪽에 에러가 발생한 경우가 있는데

                 기존 메시징 시스템은 push 방식이다보니, 장애가 발생한 consumer에도 메시지를 push하고, 그 결과

                 리턴값도 에러가 발생하여 broker까지 consumer의 장애에 영향을 받을 수 있는 위험이 있었다.

                 Kafka 사용 시, pull 방식으로 동작하여, 문제가 있는 consumer는 subscribe 작업을 하지 않아

                 메시징 시스템에는 영향을 주지 않게된다.

#Kafka 기본 구성요소 및 동작 프로세스

  1) 구성요소

     : Producer(Publish 담당), Consumer (Subscribe 담당)

  2) 기본 프로세스 모델

     : Publish - Subscribe 모델을 기반으로 동작함

     : producer가 특정 topic의 메세지를 생성하여 broker에게 전달

     : broker가 전달받은 메세지를 topic 별로 분류하여 관리 (broker는 cluster로 구성됨)

     : 해당 topic을 subscribe하는 consumer가 메세지를 가져가 처리

동작 프로세스는 이해가 되는데, 실제로 내가 직접 사용해보고 동작 프로세스 정리하는게 나을 것 같다

동작 프로세스 외에 가장 궁금했던 건,

#Kafka 사용 케이스?

  (1) Kakao - 전사 리소스 모니터링 시스템(KEMI)

  첫 번째 세션을 강의하셨던 고승범 엔지니어가 일하고 있는 Kakao에서는 '전사 리소스 모니터링 시스템(KEMI)'에

  Kafka를 활용하고 있다. 서버, 컨테이너와 같은 리소스의 데이터를 수집하여 보여주고, 설정한 임계치에 따라

  알림을 보내주고, 수집한 로그를 대시보드 형태로 보여주거나 실시간 알림을 보내도록 구성되어있다 한다..

  구성도를 보는데 Kakao의 서비스 규모가 느껴진다...... ㅎㅎ

  ** 참고: http://tech.kakao.com/tags/kafka/

  (2) Kakao - 카카오 실시간 추천 시스템(RUBICS)

      루빅스는 카카오 사용자 반응을 실시간으로 분석하여 콘텐츠를 추천하는 실시간 추천시스템

      (다음뉴스, 카카오채널 등에 사용중)

      특히, 뉴스 콘텐츠는 다른 데이터에 비해 생명주기가 짧아 최대한 실시간으로 빠르게 수집/처리하여

      추천 랭킹에 반영해야하는 요구사항을 갖고있었다고 한다. 대용량의 사용자 피드백 메시지를

      안전하게 저장하기 위해 Apache Kafka를 사용.

   (3) Naver - 실시간 데이터 분석 플랫폼

       네이버 TV 연예 서비스에 사용되는 실시간 데이터 분석 플랫폼.

       사용자가 콘텐츠를 소비하면, 해당 콘텐츠 정보가 데이터로 변환되어

       Spring과 Kafka producer로 전송. 메시지 시스템 Kafka가 메시지 처리, 데이터 소비는

       Storm 클러스터에 배포된 토폴로지가 담당. 분석된 데이터 결과 저장은 nBase-ARC(네이버에서 사용하는 분산저장플랫폼) 가 담당.

       ** 참고: https://d2.naver.com/helloworld/7731491

사용 사례들을 살펴보니 활용성이 좀 와닿는다. 기술은 정말 무궁무진~~~

나도 저걸 활용할데가 있을까?_?

담번에는 한번 사용해보고 정리해봐야겠다

여러모로 생각도 많이 해보고, 동기부여가 된 재밌는 시간이었다!

후기끝~!!

프로젝트 설계단계에서 개발가이드 검토 중, 데이터 전달 형태를 Map으로 써야할 지 VO를 써야할 지 결정을 하지 못했다.

사실 둘의 차이를 명확하게 모르니 현 프로젝트에 어떤게 더 적합한지 판별하지 못했다.

과장님께 여쭤보고 들은 답변과 좀 더 찾아본 자료들을 합쳐 정리해두어야 겠다~

Q) Map과 VO의 차이는? 언제 Map을 쓰고 언제 VO를 써야하는가? ==> 목적에 맞게 ^_^

Q) VO란?

우선 관련 개념 정의는 아래와 같다.

(1) Java Beans

    : A Java Bean is a reusable software component that can be manipulated  visually in a builer tool.

    : 일반적으로 자바빈은 속성과, 그 속성에 대한 getter, setter 메서드로 구성된 데이터 객체(VO, Value Object)를 말하며

      데이터 전송에 사용되는 객체를 말한다.

    : 자바로 작성된 재사용 가능한 소프트웨어 컴포넌트

    : getter, setter 메서드를 통해 컴포넌트에 접근가능

    ** Java Bean Spec

     - Support for “introspection” so that a builder tool can analyze how a bean works

     - Support for “customization” so that when using an application builder a user can customize the appearance and behaviour of a bean.

     - Support for “events” as a simple communication metaphor than can be used to connect up beans.

     - Support for “properties”, both for customization and for programmatic use.

     - Support for persistence, so that a bean can be customized in an application builder and then have its customized state saved away and reloaded

       later.

(2) DTO

    : Data Transfer Object

    : 계층간 데이터 교환을 위한 객체

    : 일반적인 DTO는 로직을 가지고 있지 않다. 순수한 데이터 객체이며 속성과 속성에 접근하기 위한 getter, setter메서드로만 구성되는 POJO

      (** POJO: 특정 인터페이스 또는 클래스를 상속하지 않는 일반 자바 개체)

Q) VO 작성 시, getter setter  왜 필요한건지?

내가 개발자분들한테 DTO로 VO 사용하라고 가이드했으면서 사실 VO 자체에 대한 명확한 지식이 없었던 것 같다.

왜 변수를 private 으로 선언해 써야하는 건지, getter setter는 왜 매번 필요한건지?

생각해보면 다들 가이드 받은대로 VO 카피해서 사용하기 바쁘지 왜 이렇게 사용하는 것일까 생각은 많이 안하는 것 같다.

실제로 알아보니, 많은 프로그래머 사이에서 getter setter 가 정말 필요해서 쓰는 경우가 몇 프로나 될까 의심하는 사람들이 많았다.

아무 생각없이 써왔던거라 계속 쓰기는 하는데 개발자에게는 소스 작성은 귀찮고, 그에 비해 효과는 잘 모르겠는 존재인 것이다.

쓰더라도 알고쓰자는 심정으로 조사 좀하고 정리해보았다.

우선 VO에 getter, setter를 쓰는 경우

  - 변수에 새로운 값을 할당할 때마다 validation 검사 가능

  - lazy loading 가능

  - read와 write 권한 다르게 설정 가능(public, private 사용)

  - getter, setter는 캡슐화(encapsulation)를 구현하는 가장 기본적인 형태이다. 언뜻보면 그냥 변수를 public으로 선언하여 접근하는 것과

    별반 달라보이지 않는다. 하지만 public으로 선언하여 외부에서 객체의 각 변수에 접근하여 값을 변경하는 경우가 발생할 수 있다.

    객체의 상태는 오직 그 객체의 동작에 의해서만 접근/변경되도록 하는 게 맞다. 한 객체가 다른 객체의 필드를 변경하려는 경우, public

    method를 통해 객체의 상태(필드 값)를 변경해야 한다. 또한 외부에서 접근 가능한 public method는 최소한으로 해야한다.

정리하고 나니 의문이 드는점은, 캡슐화를 위한 방법으로 getter, setter 밖에 없는걸까? 이다. getter, setter 메서드로 접근할 수 있도록

하는 것이 진정한 캡슐화가 맞냐는 의문들도 많던데.. 캡슐화를 위해 사용했다고 하면, getter, setter말고는 다른 방법이 없는 것인지 궁금하다

또, 데이터 객체에 대한 정보 은닉이 항상 필요한가?? 라는 의문도 든다.  의례적으로 쓰고있는 건 아닌지....

(1) Map 사용 시

    [장점]

      - 현재 사내 프레임워크 권장사항은 select 시에는 Map으로, 나머지 CUD 작업은 VO 사용이다. select 하는 경우는 보통 2개 이상의 테이블을

        조인하여 조회하는 경우가 많아 VO로는 표현이 복잡하기 때문

    [단점]

      - Map의 key 또는 value가 null인 경우 Map은 해당 필드 자체를 key로 가져가지 않는다. 따라서 쿼리 수행 시, key 값 자체가 존재하지 않아

        오류 발생 (이 경우를 대비하여 쿼리에 jdbcType 선언 필요, 해당 값이 null일 경우 초기화 타입 지정)

      - 여러 타입을 담아야 하기 때문에 Map은 Value 선언 시 Object로 할 수 밖에 없다. 그러나 Object는 최상위 타입이기 때문에 type 이 매치되지

        않는 경우가 발생해도 실제로 돌려보지 않는 한 알 수가 없다.

      - Object로 선언하여 모든 타입을 담기 때문에, 부가적인 casting 작업이 발생 가능하다.

(2) VO 사용 시

    [장점]

      - 비즈니스 로직 상 데이터가 명확해야 하는 경우 VO 권장 (ex: 정산, 공수 산정, 매표 등)

      - 특정 값의 key 또는 value(필수 값인 경우)가 null 인 경우 VO 클래스 내에 선언된 타입으로 초기화 수행됨. 쿼리 수행 시 null로 인한 오류가

        나지 않음

      - 멤버변수에 대한 구체적인 타입을 선언하기 때문에 타입이 매치되지 않는 경우 컴파일 에러가 발생하여 바로 알아챌 수 있다.

      - 반드시 값이 필요한 변수에 대해 생성자 파라미터로 필요한 값을 넣을 수 있어, 이 값이 없는 경우 컴파일 에러가 발생한다.

    [단점]

      - Map에 비해 소스가 많아진다.

      - getter, setter 메서드를 일일이 작성해주어야 하는 번거로움이 있었지만 현재 lombok을 사용하면 annotation 형태로 조금 더 간편하게 사용 할 수

        있다 (@Getter, @Setter)

__________________________________________________________________________________________________________________________________________________________
** 본 포스팅에 대해 수정해야할 부분이나 추가 의견 등이 있으신 분들은 댓글 달아주세요. 언제나 환영입니다 :)
** 본 포스팅은 아래의 reference 들을 참고하여 내용을 덧붙인 글입니다. 혹시, 문제가 되는 경우 알려주시면 조치하도록 하겠습니다.

    - https://www.slipp.net/questions/22
    - http://zgundam.tistory.com/65

** 본 포스팅을 reference 자료로 참고하실 분들은 출처를 꼭 밝혀주시기 바랍니다.

[AA Role] 프로젝트 정의단계 / 산정/ 인터페이스 설계

분석기술

 - 유즈케이스는 중요한 분석 도구

 - 프로토타이핑

 - 프로젝트 영역 식별

 - 비기능요구사항: 기능요구사항은 어플리케이션이 수행해야 하는 것 정의, 비기능요구사항은 기능적인 요구사항을 어플리케이션이

                        성취하는 방법에 대한 제약사항 명시

범위정의와 산정

 - 업무측에 유즈케이스에 대한 동의를 얻는다

 - 프로젝트 범위를 결정하는데 사용된 가정을 문서화한다

 - 팀에서 가장 늦은 자원을 기준으로 산정한다

외부 어플리케이션 인터페이스 설계

 - 인터페이스 방법 선택(ex: 직접 외부 어플리케이션 DB 활용, 웹 서비스, 메시징, EJB, REST 서비스 등)

   (1) 외부 어플리케이션 DB 직접 읽기

       : 구현이 가장 쉽고, 비용이 적게 듬

       : 외부 어플리케이션 팀의 개입이 거의 필요 없음

       : 항상 최신의 데이터 제공

       : 외부 어플리케이션의 변화에 역으로 영향 받을 리스크 존재

       : 오라클은 예외지만 대부분의 데이터베이스는 읽을 때 로크가 걸림(성능에 영향 줄 수 있음)

    (2) 웹 서비스

       : 웹 서비스는 다른 인터페이스 메서드에 비교하여 개발하고 유지, 보수하기 어렵다

       : 웹 서비스는 대량의 데이터를 가져오는 데 최적화되어 있지 않다

       : 필요할 때 웹 서비스를 사용하지 못할 수 도 있다. 대처 전략 필요

       : 플랫폼 중립적

       : 웹 서비스는 자유롭게 리팩토링 및 재설계 가능(해당 어플리케이션에는 아무런 영향을 미치지 않음)

     (3) RESTful 서비스

       : RESTful 웹 서비스는 구조화된 URL을 사용하여 정보 요청 명세를 커뮤니케이션 한다.

       : 플랫폼 중립적

       : 웹 서비스보다 소비하기 쉽다

       : 필요할 때 사용할 수 없을 수도 있다. 대처 전략 필요.

       : 웹 서비스의 WSDL 자체가 서비스를 설명하는 문서로 제공되는 반면에 RESTful 서비스는 이러한 내장된 문서화 전략을 제공하지 않음

     (4) 메시징 서비스 활용

       : 비동기적인 커뮤니케이션 방법. 요청이 전달되지만 응답이 즉시 이루어지지 않을 수 있음

       : JMS

       : 전달을 보장한다

       : 플랫폼 중립적

       : Java EE 컨테이너 지원을 받음

       : 내장된 문서화 전략을 제공하지 않음

 - 데이터 구조

     (1) 외부 어플리케이션에 전달되는 모든 데이터 문서화

 - 컨텐츠 교환 트리거 이벤트

 - 에러 처리 프로시저와 책임

     (1) 모든 외부 어플리케이션 인터페이스는 에러 알림 프로시저를 가져야 한다

     (2) 자동으로 에러를 알려주는 방식을 사용

     (3) 에러를 로깅할 때 상세한 설명을 포함시키는 것이 좋다

 - AA는 인터페이스 설계 논의를 중재해야 한다

     (1) 외부 어플리케이션에 전송하고 요청하는 모든 사항을 기록한다

     (2) 에러 처리 로직 적절하게 테스트

[출처] JAVA EE 아키텍트 핸드북 2판

계획단계에서 AA의 역할은 기업마다 크게 달라짐

- 업무 분석 주도 및 문서화

- PM을 지원하여 프로젝트 범위 정의

- 필요한 시간과 리소스 산정

- 외부 어플리케이션과의 인터페이스 정의 및 설계

1) AA는 프로젝트에서 사용될 기술을 선택한다

   : 기업수준 --> 하드웨어, 운영체제, 소프트웨어, 언어 등

     AA수준 --> ex) XML parser, third party package, utility 등

2) AA는 프로젝트에서 사용할 개발방법론과 프레임워크를 추천한다

3) AA는 어플리케이션의 종합적인 설계와 구조를 제공한다

4) AA는 어플리케이션 설계를 적절하게 문서화해야 한다

   : 설계 문서화는 개발자들과 커뮤니케이션 하는 중요한 단계

   : 문서는 프로젝트 중간에 사람이 교체되더라도 프로젝트가 제대로 유지될 수 있도록 한다

5) AA는 코드 작성 가이드라인을 수립한다

   : 예외처리, 로깅, 테스트, 스레딩, 캐싱, 설정 등

6) AA는 인프라스트럭처 요구사항을 정의한다

[AA와 사람들] AA와 PM

1) AA는 PM에게 구현 작업을 식별해주어야 한다

   : AA는 PM이 현실적으로 프로젝트 계획과 산정을 할 수 있도록 도와주어야 한다

2) AA는 PM을 도와 관리를 위한 프로젝트 비용과 효과를 산정한다  

3) AA는 PM이 개발자 위치에 대한 인사결정을 할 수 있도록 도와준다

4) AA는 PM에게 기술적인 충고와 가이드를 제공해야 할 책임이 있다

[AA와 사람들] AA와 PL

예외처리 관련 참고문서

http://www.nextree.co.kr/p3239/

로깅(Logging) 관련 참고문서

http://www.nextree.co.kr/p5584/

'조대협의 블로그'에 방문해서 이런저런 글을 보다가 아키텍트 키워드가 눈에 들어오길래 쭉 읽어봤다 ㅎㅎ

공감되는 말이 많아 퍼왔다. 

아키텍트

아키텍트는 전체 시스템을 디자인하고 설계하는 역할을 가지는 사람이다.
아키텍처링은 크게 두가지로 나뉘어 지는데 첫번째는 비지니스 아키텍쳐, 다음은 테크니컬 아키텍쳐이다.
비 지니스 아키텍쳐랑, 해당 시스템이 비지니스적으로 어떤 의미를 갖는지에 대한 내용으로 사업 전략,비젼,요구사항 분석과 같은 범주와 관련이 된다. 시스템의 구현 목적은 어떤 비지니스의 목적을 달성하기 위함이다. 사업 전략이야 COO 분들이나, 아니면 비지니스 컨설턴트가 진행을 하기는 하지만, 비지니스 요건을 어떻게 시스템으로 구현하여 효과를 낼지는 IT 아키텍트의 역할이다. 그래서, 비지니스에 대한 아키텍쳐링도 매우 중요하다. 
다음이 테크니컬 아키텍쳐인데, 전체 시스템의 그림을 그리고, 비지니스 요건을 충족하기 위한 기술적인 설계를 하는 역할이다.
 강조하고자 하는 바는 비지니스 요건을 잘 이해해야 한다는 것이다.
예를 들어 분산 트렌젝션 요건이 있다고 하자. "주문과 결재" 두가지 기능을 묶어야 할경우, 여러가지 선택이 있다.
XA기반의 분산 트렌젝션을 사용하는 방법, 보상 트렌젝션 처리, 로깅을 통해서 유실분에 대한 처리, 아니면 유실되는 것 데로 놔두는 것...
고급 기능과 아키텍쳐에는 돈이 든다. 물론 XA기반으로 구현하면 좋겠지만, 해당 시스템이 느린 경우 LOCK 경합 문제가 발생할 수 도 있고, 복잡도가 높아지는 만큼 테스팅에 대한 코스트도 높아진다.
 유료 회원 가입 프로세스 경우 차라리 에러가 나는데로 놔두는 것이 비용 측면에서 훨씬 유리할 수 있다. 공짜로 가입되었다고 Complain할 사람은 그리 없으니까는.
 즉. 완벽한 보안 장치를 하기 위해서, 서랍에 자물쇠를 하느냐 몇천만원짜리 지문 인식 장치를 하느냐가 아닐까?

아키텍트의 능력 중에서 중요한 것은

출처: http://bcho.tistory.com/252 [조대협의 블로그]

# WebSquare5 연동하기

프로젝트에서 UI/UX 툴로 WebSquare5를 사용하게 되었다. 서버 사이드와 데이터 통신을 하기 위해

서버 사이드에 웹스퀘어 연동 모듈을 구현해 주어야 했다.  잘 확장하면 웹스퀘어 외에 다른 UI/UX 툴도 연동 시 활용할 수 있을 것 같다.

잘 정리해두어 다음 번에 또 참고해야지 ㅎㅎ

우선 websquare에서는 데이터 통신 객체로 'submission'이란 것을 사용하는데, 여기에 사용 가능 한 데이터는 XML, JSON, Plain Text, Request Parameter(K,V) 등이 있다. 요새는 JSON을 가장 많이 권장한다는데 왜 JSON이 가장 권장될까?  

1)  JSON vs XML 비교

     - XML과 JSON은 모두 구조화된 문서를 전송가능 하게 만드는 텍스트 포맷이다. 

     - XML과 JSON은 특정한 의미를 가진 데이터를 담는 포멧을 정의한다.

     [XML]

       - 텍스트로만 정보가 이루어져 어느 환경에서건 구애받지 않고 사용 가능한 포맷

       - 기존 SGML의 복잡성을 줄이고, HTML의 편의성을 지닌 XML은 강력한 통신수단으로 자주 사용된다

       - 태그 구조로 가독성이 좋다. 작성도 간편

     [JSON]

       - JSON 역시 텍스트 형식의 데이터 포맷을 의미하는데, XML 의 단점을 보완하여 나왔다.

       - 함축적인 내용으로 최소의 정보만 내포

       - XML 대비 용량이 적고, 속도가 빨라짐

       - 객체 구조와 배열의 구조를 모두 사용가능하여 효율적인 데이터 구성이 가능하다 

       - 파싱이 간편하고 빠름

       - JSON은 자바스크립트로 작성됐다. 본래 자바스크립트와의 손쉬운 상호운용성을 위해 자바스크립트에서 사용하는 문법을 그 자체의

          데이터 형식으로 뽑아내도록 정의됐다.

        - XML은 적절하게 파싱(Parsing)을 거쳐도 BL(Billion Laughs) 공격 또는 EE(External Entity) 공격 같은 보안 취약성을 일부 갖고 있다. XML은 이런 

          기능을 실수로 활성화하면 시스템이 상당한 위험에 처하게 되지만 JSON은 그렇지 않다. JSON을 이용해 이런 위험에 노출되는 툴을 개발하기는 

          어렵다. 반면 XML을 사용할 때는 반드시 개발자가 능동적으로 확인하고 피해야 한다

XML보다 간결하고 파싱 속도가 빠르다는 장점이 대부분인데, 실제로 몇십만 건, 몇백만건의 데이터로 테스트를 해봐야 

정확히 XML보다 얼마나 빠른지, 경량화된건지 알 수 있을 것 같다. 

우선 깊은 테스트는 뒤로 하고 ㅎㅎ  웹스퀘어 연동으로 다시 돌아가면 

2) WebSquare5 통신방식

 웹스퀘어와의 통신은 아래와 같이 이루어진다. 

  - 웹스퀘어에서 통신객체 Submission에 XML 또는 JSON 데이터를 담아 서버로 전송하면

  - 서버 사이드의 어댑터에서 이를 Java Object (Collection 객체 Map/ List, VO) 로 변환한다. 

  - 서버 사이드에서는 화면으로 리턴할 Java Object를 다시 어댑터를 통해 XML/JSON으로 변환하여 전달한다.

  - 간단하게 설명하면 위와 같은 프로세스를 거쳐 통신하게 되는 것! ㅎㅎ 

  - 주고 받는 데이터 포맷에 대해 자세히 살펴보면 아래와 같다.

3) 연동 방법

    - 위와 같은 프로세스로 이루어지는 연동을 실제로 하는 방법은 여러가지가 있을 수 있겠지만 

      이번엔 아래와 같이 연동했다.

   (1) websqaure 라이브러리 설정

       - pom.xml 에 (Maven 프로젝트임) websquare 라이브러리 설정

       - websquare 라이브러리 설정 이외에도 websquare가 사용하는 몇몇 라이브러리들을 별도로 설정해줘야 했다..(엑셀 관련 등..)

       - 참고로, WebSquare은 상용 툴이기 때문에 라이센스를 별도로 구매해야 한다. 이와 관련된 중요 정보는 본 포스팅에서 언급하지 않을게용

(2) web.xml : servlet-mapping 설정

     - wq 확장자에 대한 요청을 처리할 servlet-mapping을 추가 

(3) dispatcher-servlet.xml : 웹스퀘어 view 및 resolver 선언

     - custom resolver 선언

     - 웹스퀘어 view 등록

(4) 각 클래스의 역할

  4.1 CutsomRequestMappingHandlerAdapter

       - RequestMappingHandlerAdapter 확장