풍뎅아 공부하자.

ERP

- 기업 경쟁력을 강화시키는 역할을 하는 통합정보 시스템

- 기업경영에 필요한 자원의 효율적 투입과 관리를 통해 기업가치 극대화를 위한 전사적 자원관리 시스템

- 기업 내 생산, 물류, 재무, 회계, 영업과 구매, 재고 등 경영 활동 프로세스들을 통합적으로 연계해 관리해 주며, 기업에서 발생하는 정보들을 서로 공유하고 새로운 정보의 생성과 빠른 의사결정을 도와주는 전사적자원관리시스템 또는 전사적통합시스템을 말한다

ERP 구성도

XRP 구성도

ERP VS XRP

ERP VS ERP II

SCM 정의

- 공급망 관리. 제품의 생산과 유통 과정을 하나의 통합망으로 관리하는 경영전략시스템

- 제품 생산을 위한 원자재 수급부터 고객 전달까지의 공급체인 전 과정을 통합 연결, 최적화하는 공급망 관리 시스템

- 기업에서 원재료의 생산·유통 등 모든 공급망 단계를 최적화해 수요자가 원하는 제품을 원하는 시간과 장소에 제공하는 '공급망 관리'를 뜻함

SCM의 고도화는 공급자관계관리(SRM), 제품주기관리(PLM), 성과측정지표(BSC), 능률원가측정(ABC) 등의 애플리케이션을 기업애플리케이션통합(EAI) 및 기업포털(EP)작업에 연계함으로써 협력사들과의 총체적인 협업체계를 구현하는 데 목적이 있다.

주요 특징

- VALUE CHAIN

- 부가가치 창출

- 기업 가치 향상

SCM 개념도

SCM 구축의 CSF(Critical Success Factor) 

- 기업 내 프로세스 중심 -> 기업 간 협업 프로세스 중심

- 불활실성 및 지연이의 수동적 수용 -> 불화실성의 능동적 제거

- 환전한 분산관리 -> 정보의 통합관리

- 기업간 경쟁관계 -> 기업 간 동반자 관계

* CSF : 기업이나 개인이 성공하기 위하여 반드시 수행해야 하는 핵심적인 요소. 주요 성공 요인은 숫자가 제한되어 있으며, 이들 관리만 잘하면, 개인 · 부서 또는 기업 전체의 성과가 향상되는 특징을 갖고 있다.

SCM과 ERP 비교

SCM 주요 기술

* EDI

EPC

JIT

VMI

QR

ABC

ERP

DW

CRM

SCM2.0

- 재고 감축에 초점을 맞춘 SCM1.0을 바탕으로 차별적 경쟁력을 확보하기 위해 탄력, GREEN, 고객 지향을 추구하여 유연성을 확보하는 SCM

등장배경

- 차별적 경쟁력 확보 수단 필요

- 글로벌 환경 대응 한계 극복

SCM2.0 구성도

3대 트랜드

어떤 조건이 만족되었을 때에 지정된 서비스를 제공하는 것

- 특정 위치 기반 이벤트가 발생하였을 때 자동으로 서비스를 제공받는 것.

  즉, 푸시 서비스는 위치 기반 트리거링(Location Triggering) 서비스라 하기도 함(네이버 지식백과)

- 시스템에 관련된 작업을 수행하는 Background process를 통칭하는 용어

- 부팅 단계부터 지정된 데몬이 동작하며, 서비스의 요청이 없을 때는 유휴 상태를 유지함

- 예약된 시간이나 이벤트의 요청이 발생했을 때 지정된 서비스가 실행

즉,  처리해야 할 작업 조건이 발생하면 자동으로 작동하여 필요한 작업을 실행

Jenkins는 Java로 제작된 오픈 소스 CI(Continuous Integration) 서비스를 제공하는 도구이다. 

GIT 개념 : 다수의 개발자들이 하나의 프로그램을 개발할 때 버전 충돌을 방지하기 위해 각자 작업한 내용을 공유 영역에 있는 저장소에 빈번히 업로드함으로써 지속적 통합이 가능하도록 해 준다

본래 Hudson이라는 이름의 소프트웨어였으나 오라클과의 상표권 분쟁으로 인하여 

Jenkins라는 이름으로 바꾸었다.

Apache Tomcat 같은 Servlet Container 위에 돌아가는 서버 기반 시스템이다. 

AccuRev, CVS, Subversion, Git, Mercurial, Perforce, Clearcase, RTC와 같은 SCM 툴을 지원한다. 

또한 SonarQube 등의 코드 품질관리 플랫폼과 셸 스크립트, 윈도우 배치 프로그래밍, Ant/Maven/Gradle 기반 프로그램도 지원한다. 

서버에 기능을 추가 하려면 개발자가 개발자 노트북에서 개발을 하고 테스트까지 한 다음에 이상이 없으면 사용자가 사용할 수 있게 수정된 내용을 서버에 반영해야 한다.

빌드는 서버에 올릴 수 있는 상태로 만드는 것을 빌드(Build)라고 한다.

서버에 올려서 사용자가 사용 할 수 있게 하는 것은 배포(Deploy)라고 한다.

Build를 자동화 해야하는 이유

빌드는 하루에 한번을 할 수도 있고 안할수도 있지만 1주일, 1달로 따지면 꽤 많이 한다. 그리고 이게 1년이면 꽤 많은 시간이라고 할 수 있다.

예를들면 옛날에는 자바를 빌드 할 때 javac라는 커맨드를 직접 사용 했지만 지금은 IDEA를 쓰면 main()메소드를 실행하면 javac를 하고 java가 실행이 된다.

이렇게 반복되는 과정은 버튼 하나 또는 단축키로 자동화 시킬 필요가 있다.

왜냐하면 이 작업을 하는데도 집중력, 긴장감 등이 소모 되기 때문이다. 그리고 빌드는 시간이 꽤 걸리는 작업인데(30초 이상 걸림) 빌드를 실행 시키고 나서 빌드가 될 때까지 기다리는 시간도 모아보면 엄청 길 것이다.

개발자의 시간은 소중하기 때문에 최대한 반복작업은 자동화 할 필요가 있다.

암튼 나도 손꾸락으로 빌드를 5개월쯤 하니 자동화를 안시킬 수가 없었다. 수정하고 빌드하고 dev에 올리고 하는데 너무 시간을 많이 잡아먹기 때문이다.

Jenkins란?

위에서 이야기한 빌드를 자동화 해주는 툴이다.

Jenkins는 빌드를 자동화 시키기 위해 사용한다.

Jenkins를 안쓰게 되는 이유

https://namu.live/b/live?p=5

웹 접근성이란

- 접근하기 쉽게 / 이용하게 쉽게

웹 콘텐츠에 쉽게 접근할 수 있는 능력

분산 시스템을 설계 시 발생되는 문제점

- 분산된 시스템간의 정보를 어떻게 공유할것이고, 

- 클러스터에 있는 서버들의 상태를 체크할 필요가 있으며 

- 분산된 서버들간에 동기화를 위한 락(lock)을 처리하는 것

=> 이러한 문제를 해결하는 시스템을 코디네이션 서비스 시스템 (coordination service)라고 하는데, 

Apache Zookeeper가 대표적

- Zookeeper는 자체적으로 클러스터링을 제공하며, 장애에도 데이타 유실 없이 fail over/fail back이 가능.

코디네이션 서비스는 분산 시스템 내에서 중요한 상태 정보나 설정 정보 등을 유지하기 때문에, 

코디네이션 서비스의 장애로 인한 전체 시스템의 장애를 유발하는 경우

이중화 등을 통하여 고가용성을 제공해야 함

ZooKeeper는 이러한 특성을 잘 제공하고 있는데, 

그런 이유로 이미 유명한 분산 솔루션에 많이 사용되고 있다. 

NoSQL의 한종류인 Apache HBase, 대용량 분산 큐 시스템인 Kafka등이 그 대표적인 사례.

분산 시스템을 코디네이션 하는 용도로 디자인이 되었기 때문에, 

- 데이타 엑세스가 빨라야 하며, 

- 자체적으로 장애에 대한 대응성을 가져야 함

Apache Zookeeper의 기능

- 디렉토리 구조기반으로 znode라는 데이타 저장 객체를 제공하고, (key-value식). 

 . 이 객체에 데이타를 넣고 빼는 기능만을 제공

 . 디렉토리 형식을 사용하기 때문에 데이타를 계층화된 구조로 저장하기 용이.

데이타 모델

- 디렉토리 구조의 각 노드에 데이타를 저장

노드는 아래와 같이 기능에 따라 몇가지 종류로 나뉘어 지는데 

Persistent Node : 노드에 데이타를 저장하면 일부러 삭제하지 않는 이상 삭제되지 않고 영구히 저장된다.

Ephemeral Node : 노드를 생성한 클라이언트의 세션이 연결되어 있을 경우만 유효하다. 즉 클라이언트 연결이 끊어지는 순간 삭제 된다. 이를 통해서 클라이언트가 연결이 되어 있는지 아닌지를 판단하는데 사용할 수 있다. (클러스터를 구성할때 클러스터내에 서버가 들어오면, 이 Ephemeral Node로 등록하면 된다.)

Sequence Node : 노드를 생성할때 자동으로 sequence 번호가 붙는 노드이다. 주로 분산락을 구현하는데 이용된다.

Watcher

Watch 기능은 ZooKeeper 클라이언트가 특정 znode에 watch를 걸어놓으면, 해당 znode가 변경이 되었을때, 클라이언트로 callback 호출을 날려서 클라이언트에 해당 znode가 변경이 되었음을 알려준다. 그리고 해당 watcher는 삭제 된다. 

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

Redis 클러스터는 여러개의 Redis 노드들에 데이타를 자동으로 분배가 가능하도록 설치할수 있는 몇가지 방법을 제공 하며 또한 효율적인 파티션의 분활 방식을 제공
-> 어떤 노드들이 실패가 발생해서 통신을 할수 없는 경우에도 작업이 계속될 수 있는 기능

데이타들을 여러 노드에 자동으로 분배해 주는 기능
-> 일부 노드들이 실패하는 경우, 다른 클러스터들과 통신이 불가능 해도 운영을 계속할수 있는 기능