본문 바로가기

[Cloud]/[GCP]

[GCP] Cloud Monitoring 로 VM 인스턴스 로그 수집하기 - 1.시작

728x90

    이번 포스팅은 사실 사이드 프로젝트를 진행하면서, Cloud monitoring을 적용시켜보게 된 이유를 설명하고, 그 과정을 기록으로 남기기 위한 것이라, Cloud-Monitoring에 대한 내용은 이어서 포스팅하도록 하겠다.

[ 목적 ]

    만들려는 서비스는 간단했다. 바로 거대한 플랫폼 서비스에 들어갈 Notification server를 비동기식 micro-service 형태로 만드는 것. 당연히 제대로 알고 하는 것도 아니고, 알음알음 이것저것 뒤져보면서, 이왕이면 지속적으로 확장가능하도록  만들려고 했다. 아래 두 글은 현재 내가 참고하고 있는 포스팅 들이다.

medium.com/swlh/architecting-a-scalable-notification-service-778c6fb3ac28

 

Architecting a Scalable Notification Service

This post can serve as a reference document that highlights some of the best practices in architecting a Notification Service…

medium.com

medium.com/azimolabs/migrating-notifications-from-a-monolith-to-a-microservice-c01e4a042e10

 

Migrating notifications from a monolith to a microservice

Like many tech companies founded around a decade ago, Azimo built its first application as a PHP monolith. As we grew into a company that…

medium.com

 

[ ...시작 ]

    처음에는 그냥 Notification, 그것도 그냥 메인서버의 부하를 줄이기 위한 목적으로, 포스트에 댓글이 달리면 해당 사이트에 웹훅(Webhook)을 걸어놓은 마이크로 서비스가(내가 만들려는 것) 그 알람을 유저에게 전송해 주는 용도로 시작하기로 했다. 플랫폼이 python 언어가 메인 프레임이라 flask를 사용해서 정말 간.단.하게 서버를 팠다. 아래는 테스트용으로 사용중인 플라스크 서버이다. 

from flask import jsonify
from flask import request
from flask import Blueprint
import requests
from . import api

@api.route('/notice' , methods=['GET','POST'])
def notice():
    data = request.get_json()
    if request.method == 'POST':
        res = requests.post('http://c43b4a5ee64d.ngrok.io',
        json=data
        , headers={'Content-Type': 'application/json'})

    elif request.method == 'GET':
        pass
    
    return jsonify(data)

# curl
# curl -d "{\"posts_id\":\"p1\",\"posts_title\":\"p2\",\"comments_id\":\"cm1\",\"comments_created_at\":\"cm2\"}" \
# -H "Content-Type: application/json" \
# -X POST http://127.0.0.1:5001/api/v1/notice

  비동기식으로 동작한다고 말할순 없다. flask에서는 비동기식 처리방식으로 Celery 모듈을 많이 사용하던데, 이를 집어넣지도 않았다. 단순히 비교하고 싶은 욕심에...  Celery나 Thread를 나누어 모니터링을 한 결과를 보고싶은 것이다!! -> 이게 Cloud-Monitoring을 사용하려는 주 목적이다.

 

[ 삽질중인 내용 ]

   메인 프로젝트가 아직 미완성인 관계로, 웹훅을 걸 서버 또한 직접 만들어서 사용하고 있다. 일단 코드를 보면 ngrok을 열어놓은 것을 확인할 수 있다. 지금 상황을 그림으로 표현하면 다음과 같다. Postman에서 json데이터를 쏴보고 있는데 이 부분은 메인 백엔드가 될 예정이고, microserver에서 notice를 주는 server(ngrok부분)는 프론트엔드쪽이 될 예정이다. 현재는 데이터의 수신을 콘솔창에서 확인하고 있는데, micro-server와 ngrok부분을 둘다 gcp에 올려 확인하려고 한다. 그리고 microserver의 외부IP에 postman으로 json데이터를 전송해 보고, 이쪽을 부하테스트를 해서 micro-server를 어떻게 확장시키면 좋을지 생각해보고자 한다. 

 

[ 클라우드 상에 구현  & 로컬에서 접속 가능하도록 설정]

    위 내용을 클라우드에 구현하면 다음과 같이 생성된다. 먼저 Server part & Target part는 다음과 같다. 

실제로 동작과정을 나타내보면 다음과 같다.
1. 먼저 Postman에서 Notice Server로 json데이터를 전송한다.

2. 이어서 notice 서버와 receive 서버에 나타나는 값은 각각 다음과 같다.

Postman에서 전송된 json데이터가 notice 서버를 거쳐 무사히 receive 서버에 도착하는 것을 확인할 수 있다.

3. 동작은 끝났지만 세팅할 내용은 아직 남아있다. 일단 로컬에서 접속하기 위해  먼저 ssh-keygen로 public key를 생성한다.

4. id_rsa.pub로 이동해서 public-key를 복사한다. (사진은 rsa의 일부다! .pub과는 다른 키이다)

5. 이어서 public-key를 ssh키에 등록한다. 

6. notice에 접속해서 nohup을 통해 쉘 백그라운드로 실행시켜준다. 또한 아래 명령어로 백그라운드에서 실행중인 앱을 확인할 수 있다.

ps -aux | grep app.py

    원래 receive server도 동일한 방법으로 적용시킬 수 있지만, 어짜피 receive부분은 나중에 프론트 서버로 대체되기 때문에 (귀찮아서) 따로 로컬에 키를 받지는 않고, 브라우저 ssh에서 백그라운드로 돌아가게 하겠다. nohup.out의 출력물을 살펴보면 다음과 같이 정상적으로 잘 동작하고 있음을 알 수 있다.


이어서 이 뼈대를 기준으로 부하 테스트를 해보자. 생각해둔 툴은 Jmeter나 오픈소스 툴인 locust이다.
벌써부터 기대가 된다 ㅎㅎㅎ

728x90