데이터 센터

데이터센터란?

리소스를 넣어놓는 것산업에서 발생하는 모든 정보(리소스)를 저장하고 처리하는 중심 역할


리소스를 활용하려면 측정이 가장 중요하지만
여러사람이 리소스를 쓸 때 측정하기 어렵다.

에이전트

- 바이너리를 깔아서 돌아가는 구조다.                    
  - 새로운게 os가 들어오면 계속 업그레이드를 해야한다 
                        - 매번 버전을 바꾸면 가능할 수 있지만 os에 대한 버전도 바뀌기 때문에 
                                            os업데이트, 에이전트 업데이트를 동시에 상황에 맞는 에이전트가 계속 등장해야한다.
                               - 에이전트가 죽거나 오류가 나지 않기 위해 신경써 기술과 복잡도가 상승한다.

클라우드는 측정하는게 중요하기 때문에 
단일화된 방법으로 조회, 삽입 다 같은 방법으로 해야 한다

---

람다 아키텍쳐 (Lambda Architecture)
    - 로그 소킷으로 데이터가 앱 데이터를 카프카에 모을 수 있다
- 카프카의 서비스 디스커버리가 주키퍼이다                  
- 퍼시던트 데이터에서 데이터를 배치해줘야 한다           
  ㄴ  여러군데로 펼쳐지면서 하는 구조이다

카파 아키텍쳐 (Kappa Architecture)
카프카에 모든 데이터를 넣고 카프카 클러스터에서 그때그때 계산해서 주는 방식

퍼시던트(persistence) : 데이터는 보관기간이 길지만 속도가 그저 그런, 아주 많은 리드가 필요하다

카파,람다 아키텍쳐 공통점
유니파인드 방식으로 들어와 적재를 하고 조회하는 부분을 단일화한다.

Low Latency : 실시간 데이터
Persisence : 장기 데이터

---

텔레메트리 구조

인제스트                 스토어                 언엘리시스                 프레젠트       
   데이터 받기             데이터 저장             데이터 분석             데이터 보기          

---

인제스트

프로메테우스 (prometheus)
에이전트를 달지 않아도 프로메테우스로 주고받는 표준화가 되어있기 때문에
어플리케이션만 바꾸면 내부에있는 클라이언트 라이브러리가 백엔드 라이브러리에 쌓아둬
필요할 때 끌고올 수 있어 어플리케이션을 어떻게 전송할지 걱정하지않아도 된다

프런트디 (fluentd)
프런트디가 나오기 전 아주 복잡한 구조를 가지고 있었지만
프런트디가 나오면서 모든 정보가 프런트디로 들어오게끔 표준화가 됨

    아팟치 플럼     =     프런트디
              넣는 과정이 복잡      성능,플러그인이 더 많음

프로메테우스
장점
- 인제스트이자 저장소이다                 
- 간단하게 저장 가능하다                   
                      - 별도의 쿼리언어가 따로 있어서 sql을 쓸 수 있다면 쉽다
단점
                   - 클러스터링이 안되있어서 프로메테우스에서 다운될경우 데이터가 날아갈 수 있다
- 데이터를 유지할 수 있는 방법이 어렵다                                  

---

스토어

open TSDB
- 강력함 (확장성이 좋다 성능이 좋다)              
             - 클러스터링(clustering)과 ha(high availability)를 해결된다
                                   - 특정 서버가 죽거나 특정노드가 죽어도 전체 데이터에 영향을 받지 않는다
- hbase를 써야하기때문에 복잡하다               

로깅용 데이터 : 일레스틱 서치(ES / Elastic Search)
-  간단하다                            
- 쉽게 스케일링아웃 가능하다    
- gui가 잘되어 있다                 
                                   (kibana에서 차트를 만들어 커스텀음악을 쓸 수 있음)
         - 커스터마이징 하기도 좋고 속도 빠르다
    - 리얼타임데이터 서포트하기도 좋다

---

언엘리시스 

구조가 복잡하지만 기존 빅데이터 방식과 비슷하다

---

프레젠트

메세지 큐
A가 B에게 메시지를 보낼 때 직접 보내는게 아니라 메시지큐안에 넣어서 
B가 원할 때 꺼내볼 수 있는 것

카프카
각자 메시지를 관리하고 메시지큐만 카프카가 관리하기 때문에 속도가 빠름
메트릭,로직 동일
특정기간동안 메시지가 유실되지 않는 기간은 카프카가 유지해줌

가장 많이 쓰는 방식 : 모든 데이터를 카프카에 파이프처럼 연결

 

 

---

정온 Tistory

이 티스토리는 학생이 제작하고 있습니다
수정사항이 있다면 댓글이나 방명록에 남겨주세요

!https://blog.kakaocdn.net/dn/cIPqVo/btq4H96tBD3/0IYJAieuFzgQgazblLH1BK/img.png

데이터센터란?

리소스를 넣어놓는 것산업에서 발생하는 모든 정보(리소스)를 저장하고 처리하는 중심 역할

리소스를 활용하려면 측정이 가장 중요하지만

여러사람이 리소스를 쓸 때 측정하기 어렵다.

에이전트

• 바이너리를 깔아서 돌아가는 구조다.
• 새로운게 os가 들어오면 계속 업그레이드를 해야한다
• 매번 버전을 바꾸면 가능할 수 있지만 os에 대한 버전도 바뀌기 때문에

os업데이트, 에이전트 업데이트를 동시에 상황에 맞는 에이전트가 계속 등장해야한다.

• 에이전트가 죽거나 오류가 나지 않기 위해 신경써 기술과 복잡도가 상승한다.

!https://blog.kakaocdn.net/dn/c57yNm/btq4HHP0Xdd/OYDxH1zen35Fvn7ljmWrB0/img.png

클라우드는 측정하는게 중요하기 때문에

단일화된 방법으로 조회, 삽입 다 같은 방법으로 해야 한다

---

!https://blog.kakaocdn.net/dn/0PA5X/btq4Je0D0Ys/BLs7kZdpD6vnPwbcl6mkP1/img.png

람다 아키텍쳐 (Lambda Architecture)

• 로그 소킷으로 데이터가 앱 데이터를 카프카에 모을 수 있다
• 카프카의 서비스 디스커버리가 주키퍼이다
• 퍼시던트 데이터에서 데이터를 배치해줘야 한다

ㄴ  여러군데로 펼쳐지면서 하는 구조이다

카파 아키텍쳐 (Kappa Architecture)

카프카에 모든 데이터를 넣고 카프카 클러스터에서 그때그때 계산해서 주는 방식

퍼시던트(persistence) : 데이터는 보관기간이 길지만 속도가 그저 그런, 아주 많은 리드가 필요하다

카파,람다 아키텍쳐 공통점

유니파인드 방식으로 들어와 적재를 하고 조회하는 부분을 단일화한다.

Low Latency : 실시간 데이터

Persisence : 장기 데이터

---

텔레메트리 구조

!https://blog.kakaocdn.net/dn/I2WJg/btq4HvWtINU/8BroULtkF4NwWAn8VupOo0/img.png

인제스트                 스토어                 언엘리시스                 프레젠트

데이터 받기             데이터 저장             데이터 분석             데이터 보기

---

인제스트

!https://blog.kakaocdn.net/dn/snRjN/btq4CDBgCWn/3Nq91he2XK8Tcfnw0vQrx1/img.png

프로메테우스 (prometheus)

에이전트를 달지 않아도 프로메테우스로 주고받는 표준화가 되어있기 때문에

어플리케이션만 바꾸면 내부에있는 클라이언트 라이브러리가 백엔드 라이브러리에 쌓아둬

필요할 때 끌고올 수 있어 어플리케이션을 어떻게 전송할지 걱정하지않아도 된다

!https://blog.kakaocdn.net/dn/YsLrI/btq4HNo3spt/1OFA29uJGK9uTThvRorxD1/img.png

프런트디 (fluentd)프런트디가 나오기 전 아주 복잡한 구조를 가지고 있었지만프런트디가 나오면서 모든 정보가 프런트디로 들어오게끔 표준화가 됨    아팟치 플럼     =     프런트디              넣는 과정이 복잡      성능,플러그인이 더 많음프로메테우스장점- 인제스트이자 저장소이다                 - 간단하게 저장 가능하다                                         - 별도의 쿼리언어가 따로 있어서 sql을 쓸 수 있다면 쉽다단점                   - 클러스터링이 안되있어서 프로메테우스에서 다운될경우 데이터가 날아갈 수 있다- 데이터를 유지할 수 있는 방법이 어렵다

---

스토어

open TSDB- 강력함 (확장성이 좋다 성능이 좋다)                           - 클러스터링(clustering)과 ha(high availability)를 해결된다                                   - 특정 서버가 죽거나 특정노드가 죽어도 전체 데이터에 영향을 받지 않는다- hbase를 써야하기때문에 복잡하다

로깅용 데이터 : 일레스틱 서치(ES / Elastic Search)

• 간단하다
• 쉽게 스케일링아웃 가능하다
• gui가 잘되어 있다

(kibana에서 차트를 만들어 커스텀음악을 쓸 수 있음)

• 커스터마이징 하기도 좋고 속도 빠르다
• 리얼타임데이터 서포트하기도 좋다

---

!https://blog.kakaocdn.net/dn/bgvygr/btq4F7Pdnle/4RTBNNVIKyimNsKCKGBg4k/img.png

언엘리시스

구조가 복잡하지만 기존 빅데이터 방식과 비슷하다

---

!https://blog.kakaocdn.net/dn/bwORjb/btq4IadhT67/Vx8sOTryw2jV26Rv85oNR1/img.png

프레젠트

메세지 큐

A가 B에게 메시지를 보낼 때 직접 보내는게 아니라 메시지큐안에 넣어서

B가 원할 때 꺼내볼 수 있는 것

카프카

각자 메시지를 관리하고 메시지큐만 카프카가 관리하기 때문에 속도가 빠름

메트릭,로직 동일

특정기간동안 메시지가 유실되지 않는 기간은 카프카가 유지해줌

가장 많이 쓰는 방식 : 모든 데이터를 카프카에 파이프처럼 연결

---

정온 Tistory

이 티스토리는 학생이 제작하고 있습니다

수정사항이 있다면 댓글이나 방명록에 남겨주세요