문제상황

gcp에 vcp를 새로 만들었고, 해당 vcp에 gce 리소스를 만들었다. 그리고 외부 ip로 ping을 날렸는데 동작하지 않는다. default로 생성된 vcp에 gce 리소스를 하나 만들어서 외부 ip를 날렸는데 동작한다. 무엇이 문제일까 확인한다.

확인사항

1 방화벽

처음 만들면 아래와 같은 사항들을 선택할 수 있다.

일단 vcp를 만들때 무시했다. 그리고 나서 모든 IP를 대상(0.0.0.0)으로 모든 포트(0-65535)를 오픈했다.

여기서 icmp가 무엇인지 확인한다.

1.1 icmp

네트워크 ICMP란?

위의 글에 따르면

• ICMP는 TCP/IP에서 IP 패킷을 처리할 때 발생되는 문제를 알려주는 프로토콜이라고 한다.
• IP에는 패킷을 목적지에 도달시키기 위한 내용들로만 구성되어져 있기 때문에 정상적으로 도달하지 못하는 경우에 대한 상황을 출발지 호스트로 알려주지 못하는 문제가 있다. 이걸 해결해주는게 ICMP라는 녀석이다.

그래서 ICMP는 언제사용되는가?

• 우리가 잘 쓰는 ping도 ICMP를 쓴다고 한다.
• 그래서 모든 포트에 대해서 icmp를 허용하도록 했더니 외부 ip로 ping을 하니 정상적으로 ping 확인이 된다.

참고

• GCP VPC 테스트

docker-compose로 올렸는데 로그인이 안되는 경우가 있다.

• sudo docker-compose run --rm superset ./docker/docker-init.sh
• --rm: Remove container after run.

파티션된 테이블

생성

• 파티션 필터는 최적화를 위해서 사용하는게 좋다. 참고 | BigQuery docs
• 파티션 만료시간 개념 참고 | BigQuery docs
• WriteToBigQuery에서 옵션은 어떻게 처리하지?

• How to Create Partition table at runtime over Apache Beam using Python | stack overflow
• apache_beam.io.gcp.bigquery module | Apache Beam docs
• REST Resource: tables | BigQuery docs

• 생성 시 삽질

• 파티션 날짜와 실제 데이터의 날짜가 다르면 아래의 에러가 발생함
• message: 'Some rows belong to different partitions rather than destination partition 20220112'

• 쿼리 방식 참고 | BigQuery docs

• 파티션 만료시간(Partition expiration) 무기한 처리

• Google Bigquery: How to update partition expiration time for a partitioned table? | stack overflow
• 테이블의 만료 타임스탬프 지우기 | BigQuery

ALTER TABLE `project_id`.dataset_id.table_id
SET OPTIONS (partition_expiration_days=NULL);

참고

• Managing partitioned table data | BigQuery | Google

join 없이 join맺은 테이블을 조회할 수 있으나 각각의 쿼리가 발생한다.(N + 1 이슈)
fetchjoin을 사용하면 뭉탱이로 쿼리를 날린다.

이건 따로 정리를 하자

도커를 쓰다보면 여유공간이 없어서 여러가지 장애가 발생하는 경우가 있다.

$ docker system prune -a
WARNING! This will remove:
  - all stopped containers
  - all networks not used by at least one container
  - all images without at least one container associated to them
  - all build cache

Are you sure you want to continue? [y/N] y

docker system prune -a

해당 명령어로 해결이 되기는하는데... 한번 어떤 이슈인지는 확인해볼 필요가 있다.

• trace를 남길 때에는 중앙에서 관리하도록 하는게 좋다. 왜냐하면 여러 곳에서 남길 경우 정보의 중복이 발생하고, 관리가 잘 안된다.
• 만약 로그를 남긴다면 trace를 남기지 말고 정보를 남겨라.

상황

• openfeign을 추가하려고 한다.
• 현재 spring boot 2.6.2인데 openfeign은 어떤 버전을 써야하나?

패키지 호환은 어떻게 알 수 있을까?

• 일단 spring-boot가 패키지 버전 호환을 고려해서 적당한 버전을 넣어주는게 기본이다. 그래서 보통은 버전을 명시할 일이 없다.
  • 그런데, 버전을 명시하지 않으면 안되는 경우가 있다. 이번처럼...
  • 그러면 버전을 찾으러 가야한다.
  • https://spring.io/projects/spring-cloud-openfeign#learn
  • 여기에 가보면 github 링크를 볼 수 있다. 여기서 pom.xml을 보자 보통은 여기까지 보면 확인이된다.
  • 그런데 4.0.0이라고 기록되어져 있지만 current 버전은 3.1.1이었다.
  • 다른 프로젝트처럼 implementation("org.springframework.cloud:spring-cloud-starter-openfeign:3.1.1:RELEASE") 라고 써봤다. 그런데 계속 import가 안된다..
• 패키지 임포트 현황을 보기 위해서 gradle > build dependencies를 사용해보자
• - 3.1.1RELEASE FAILED라고 쓰여있는걸 볼 수 있다. 그러면 어떻게 임포트하라는거지..? - 구글에 `org.springframework.cloud:spring-cloud-starter-openfeign` 통으로 검색해보니 [https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-starter-openfeign/3.1.1](https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-starter-openfeign/3.1.1) 여기에 들어갈 수 있었다... RELEASE를 빼고 입력하기 패키지 import 완료...!

추가로 spring-boot 2.6.2는 어떤 버전을 써야할까? 4.0.0 vs 3.1.1

• 일단 openfeign은 spring-cloud 프로젝트이다.
• 그러면 spring-cloud와 spring-boot의 버전 호환을 확인해야한다.
  • https://spring.io/projects/spring-cloud
  • 
  • 위의 표를 보니까 spring-cloud: 2021.0.x aka Jubilee > spring-boot: 2.6.x 이렇게 호환된다.
  • 4.0.0을 써야하는지 3.1.1을 써야하는지 어떻게 결정하는지는 잘 모르겠다. 일단 최신버전을 해보니 잘 된다;;

로그

[2021-11-21T00:00:31,906][INFO ][logstash.outputs.elasticsearch] retrying failed action with response code: 403 ({"type"=>"cluster_block_exception", "reason"=>"index [stb-2021.11.20] blocked by: [TOO_MANY_REQUESTS/12/index read-only / allow delete (api), FORBIDDEN/8/index write (api)];"}) | 2021-11-21T00:00:33.949Z

접근 및 해결 방법

1. 해당 로그가 무엇을 의미하는지 파악한다.

쓰기 불가, 읽기만 가능

2. 왜 이런 상황이 발생했는지 파악한다.

ES 스토리지 여유공간이 95% 이하가 되면 write lock 으로 상태가 변경됨

3. 근본적인 해결 방법 적용

ES 스토리지를 비우고, write lock을 해제한다.

4. 미리 파악할 수 있는 트리거를 추가한다.

cloudwatch에서 경보를 추가한다.

참고글

• https://goateedev.tistory.com/119
• https://darksharavim.tistory.com/586
• https://www.nakjunizm.com/2018/10/26/ElasticSearch_Cluster_block_exception/

문제상황

• 고객사에서 평상시와 다른 패턴으로 편성을 요구했다.
• 즉각적으로 편성되기를 원해서, 각 플레이어들의 다운로드 제한시간을 해제했다.
• CPU사용률이 3시간이상 30프로 이상을 유지하고 있었다.
• 평상시와는 다른 모습니다.

원인 조사

1. CPU 부하

• 평상시보다 CPU 사용량이 많았다.
• 평상시보다 네트워크에서 받은 요청이 많았다.
• 평상시보다 네트워크에서 쓰기 요청도 많았다.
  

2. I/O 부하�

• 평상시보다 메모리 사용량이 많았다.
  

3. DB 상태 확인
   

• 11/29 편성 테스트 때문에 스왑메모리가 사용된 것으로 보임
• 12/2 스왑메모리 사용량 증가, 여유 메모리 공간이 줄어들음, 이때 innodb_pool_size를 증가시켰음 (75% > 80%)
• pool_size는 캐시와 관련하여 읽고 쓰는 성능을 향상시킴

결론

• 사용가능한 메모리가 줄어들면서 애플리케이션의 지연이 발생한 것으로 확인

조치

• innodb_pool_size를 다시 줄였음. 이로 인해서 여유 메모리 공간이 확보됨. 경과는 살펴보아야함

문제상황

• celery worker가 task를 받은(status: received) 후에 실행을 하지 못함
• worker의 상태 또한 offline

원인

• 핵심적인 원인은 사용방식 때문이다.
• celery 사용시 과한 메모리 사용한다.
• ex. backend.mqtt.tasks.mqtt_from_screen
• 전달하는 데이터의 양이 매우 많다.
  

분석

• 지표 확인
  

• 메모리 사용이 100%에 가까워짐

• 로그 확인

• sqlalchemy.exc.StatementError: (sqlalchemy.exc.InvalidRequestError) Can't reconnect until invalid transaction is rolled back

• billiard.exceptions.WorkerLostError: Worker exited prematurely: signal 9 (SIGKILL) Job: 1918.

• ...

• [Errno 12] Cannot allocate memory

• 프로세스가 kill됨

• 메모리가 부족하게 되면서 프로세스를 강제로 종료함(oom killer)

• 프로세스가 죽으면서 CPU 사용률이 떨어지게됨

• 메모리 할당 불가

• 메모리에 여유가 생기면서 실행을 하려고 하지만 celery_once를 사용함에 따라 중복된 task를 실행할 수 없는 상태

• raise AlreadyQueued(ttl / 1000.)

문제 해결방식

• 워커에 할당된 리소스(CPU, Memory 2배)를 증가시킴

주의사항

• 브로커에 그간 쌓여있던 task 중에서 DB에 접근하는 task일 경우 전체 서비스에 영향을 줄 수 있음

그외 작업

• memory 사용량에 따른 알림 추가

앞으로 추가 작업

• 메모리를 많이 잡아먹는 로직을 개선할 필요가 있음
• ex. 데이터를 많이 전달받는 task

문제상황

dataflow에서 스케쥴은 잡히는데, airflow webserver ui에서는 task state가 no_state로 잡히는 문제

원인

동적으로 task_name을 설정하다보니 상태가 표시가 안된다.

태스크 인스턴스에서 이전 태스크의 상태를 확인할 수 있다. 백필을 고려해서 이렇게 태스크 이름을 처리한 것들이기는 한데...음...

문제상황

Dockerfile에 명령어가 들어가면 <ERROR!!!: Too old Airflow version !>를 뱉어버린다.

원인

Dockerfile
COPY ./${환경변수} .

여기서 환경변수가 제대로 넘어가지 않는 문제가 때문에 그랬다...허무하다...
로그를 보면...

COPY ./ .

local에서는 다음과 같은 커맨드로 환경변수가 넘어가지 않는다.

docker-compose --env-file <env/file/path> up

AIRFLOW_UID, AIRFLOW_HOME가 없으면 이런 문제가 발생하는 것 같다.

상황

• 자바 버전을 변경한다
• 1.8 > 11

해결

• 본인의 경우 자바 버전관리를 jenv로 하고 있다.
• local에 설치후 jenv에 설치 버전을 반영한다.
• ide로 intelliJ를 쓰는 경우 프로젝트의 jdk로 변경해야한다.

참고

• https://inma.tistory.com/157
• https://charliecharlie.tistory.com/315

크게 문제가 되는 부분은 없으나 shell 명령어를 새롭게 배움

• python3를 설치하더라도 python 명령어로 python3를 실행하지 않으므로 링크를 해주어야한다.

ln -s /usr/bin/python3 /usr/bin/python

• $1은 shell로 들어온 첫번째 인풋을 뜻한다.
• case 문이므로 $1인 var 이면 = var)이다
• 그렇게 되면 그 아래 명령을 실행하게 된다.
• exec는 그냥 쉘에서 명령어를 때리는 것과 조금 다르다. 끝나면 해당 쉘에서 나오지 않는다.

#!/usr/bin/env bash

var=$1

case $var in
  ad_platform_web)
    ./manage.py migrate
    exec gunicorn -c gunicorn_config.py 'config.wsgi:application'
    ;;
esac

updated_at에서 onupdate 옵션을 True로 두어서 sqlalchemy로 쿼리를 날리면 update_at이 바뀌는 상황

하지만 나는 update_at이 업데이트 되지 않으면서 일부 컬럼 값을 변경하고 싶었다.

한참 고민했고, 결국 sqlalchemy는 application 수준의 처리이기 때문에 raw sql을 사용하자는 아이디어!

실제로 raw sql을 사용하니 updated_at이 안바뀌었다.

참고로 maria db에서는 subquery에 limit을 쓸 수 없었다. 그래서 아래처럼 사용했다.

db.session.execute(
    'UPDATE playlist SET is_simple = 1 WHERE id IN (SELECT * FROM (SELECT id FROM playlist WHERE name = :val LIMIT 1000) as tmp)',
    {"val": "Digital Menu Board"}
)

https://stackoverflow.com/questions/19331497/set-environment-variables-from-file-of-key-value-pairs?page=1&tab=oldest#tab-top