장애? docker 컨테이너에서 block I/O가 너무 심하다

AWS ec2 인스턴스로 t3a.small에 docker container를 2개 띄웠다. elasticsearch와 kibana를

kibana 컨테이너가 12.97%, elasticsearch 컨테이너가 66.53% 메모리를 점유하고 있었다. 여기에 하나라도 더 올라가는 순간...

elasticsearch와 kibana를 구동 시키니 둘이 합해서 거의 80%에 달하는 메모리를 점유하고 있었다.

여기에 spring boot 이미지를 컨테이너까지 구동시키니 터미널에서 ec2 접속이 먹통이 되어서 부랴부랴 ec2 인스턴스를 종료시킬 수 밖에 없었다.

어제 장애 현상 발견하고 오늘 확인을 해 보니 아무래도 컨테이너가 점유중인 메모리의 한계에 다다라 그런 것이라 생각했다. 애초에 2gib 뿐인 인스턴스이기도 하고...

그래서 elasticsearch와 kibana만 ec2에 띄우고, spring boot는 로컬 노트북에서 컨테이너로 동작시키기로 했다. spring boot 동작 시 환경 변수로 elasticsearch가 동작하는 컨테이너의 호스트 ip (= ec2의 public ipv4 주소)를 -e 파라미터를 통해 전달하면 되겠다 싶었다

생각했던 대로 로컬에서 동작하는 spring boot 컨테이너와 ec2 인스턴스의 elasticsearch 컨테이너는 잘 연결 되었다

라고 생각한건 얼마 지나지 않아 오산이었다

폭풍 전야. block I/O는 아직까지 평화롭지만..

이게 잘 동작하고 있구만 이라고 생각했던 때의 resource 모니터링 로그이고 (docker stats로 실시간 파악)

으아아악 이게뭐야

kibana에 데이터들이 잘 입력 되나 확인해 보려던 찰나 새로 고침을 하려니 랙이 걸려서 resource 로그를 보니 뜨문뜨문 로그들이 올라오는 것이었다. 다른 stats들은 윗 사진과 다를 바 없었으나, 한가지 BLOCK I/O가 9.22GB로 팍 튀어 버린걸 발견했다. 갑자기 단위가 MB에서 달라져 버린걸 보고 상당히 의아하긴 했는데 아직 원인 파악을 못했다.

consumer lag도 난리가 나버렸다. 로컬에서 테스트 할 때에는 10 이상을 넘기지 않았던거 같은데.....

elasticsearch가 제대로 동작을 안하니 데이터를 제대로 소비하지 못해 consumer lag가 무섭게 쌓여가는 모습이다. BLOCK I/O의 뜻을 찾아보니 disk 입출력을 의미하던데 (헷갈리게 DISK I/O라 안하고 왜.....) kafka에서 subscribe 하려던 데이터들을 elasticsearch에 쓰던 과정에서 병목이 생겼던 것일까? 그래봤자 초당 트래픽이 많아야 5kb 뿐이던데...? 아직 공부가 더 필요한거 같다. partition 갯수를 늘려봐야 할까? confluent basic 에디션이라 10개까지만 무료인데.....