[GCP] Cloud Monitoring 로 VM 인스턴스 로그 수집하기 - 4. 중간 점검,앞으로 할 일 정리

[ 발생한 문제 정리 ]    

  1. 원래는 한창 celery에 관한 포스팅을 준비하고 있었는데 갑자기 문제가 터졌다. 여러가지 서비스를 이제 클라우드상에 배포할 예정인데 다음과 같이 Static IP에 대한 charge가 꾸준하게 발생하기 시작했다. 내부에는 팀원이 올린 vm인스턴스 하나와, 테스트용 마이크로서버2개가 있다. 따라서 이번에는 Cloud NAT를 이용해 외부로 공개되는 IP의 개수를 줄여 보안성을 높이고, 동시에 비용도 절감하려고 한다. 

실제로 static ip를 사용하는 일반 vm과 nat를 사용하는 vm은 각각 시간당 0.004$ vs $0.0014$로 세배에 가까운 가격차이가 난다. 아래 링크에 들어가면 정확한 과금정책을 확인할 수 있다. 

cloud.google.com/nat/pricing?hl=ko

Cloud NAT 가격 책정  |  Google Cloud

cloud.google.com/compute/network-pricing?hl=ko

네트워크 가격 책정  |  Compute Engine 문서  |  Google Cloud

 

  2. 사실 문제는 하나가 더 있다. 지금까지 locust로 해온 부하테스트가 사실 서버에 대한 부하테스트가 아니라, 당연히 그렇게 나올 수 밖에 없었던 것임을 깨달았다. 아래의 포스팅에서 나는 locust 부하테스트를 로컬->GCP의 VM Instance(notice)로 쏘아 결과를 확인하는 방식이였다. 하지만 실제로 notice서버와 backend 서버는 둘다 같은 GCP의 VPC내에 설치되기 때문에  GCP의 내부 IP 주소를 대상으로 한 인그레스는 머신이 허용하는 만큼 넉넉하다는 것과, 외부 IP로의 이그레스 또한 제한이 걸리는 점(이것이 dump의 원인!!)을 간과했다. (즉, 내부의 vm끼리의 부하테스트를 위해서는 locust를 gcp 내부에 설치해서 돌려야 의미가 있다! ) 결국 아래의, 내가 없애고자 했던  dump는 의미가 없을 수 있겠다는... 생각이... 들었다... 젠장...
buildabetterworld.tistory.com/124?category=859595

[GCP] Cloud Monitoring 로 VM 인스턴스 로그 수집하기 - 2. 부하테스트(Locust)

cloud.google.com/compute/docs/network-bandwidth?hl=ko

네트워크 대역폭  |  Compute Engine 문서  |  Google Cloud

 

[ 할 일 정리 ] 

1. Cloud NAT 적용
2. Cloud NAT을 통한 부하테스트 & Celery적용
3. 공부좀해라!