일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- bfs
- spring
- 스타트업
- 주니어
- 자료구조
- Java
- Linux
- dfs
- 백엔드
- 개발자
- 도커
- 이직
- 배열
- 스프링부트
- 문자열
- 스프링
- docker
- 프로그래머스
- 구현
- HashMap
- 스프링 부트
- 해결
- HTTP
- 인텔리제이
- 해시맵
- spring boot
- 구름LEVEL
- IntelliJ
- 명령어
- 코딩테스트
- Today
- Total
목록개발지식 (50)
마이의 개발 블로그
배경지정된 사양에서의 부하테스트를 위해 도커가 사용하는 로컬머신의 코어와 메모리를 제한할 필요가 있었습니다. 하나의 도커 컨테이너만 동작시킨다면 실행 옵션에 명령어를 사용하는 방법도 있겠습니다만, 10개 이상의 도커 컨테이너가 도커 컴포즈로 동작하는 상황이었기 때문에 자원을 유동적으로 공유해서 사용해야하므로 OS에서 도커에게 할당하는 자원을 제한하는 편이 낫다고 판단했습니다. 여기서는 cgroups 명령어를 통해 도커 사용 자원을 제한하는 방법을 소개하고자 합니다. cgroups 명령어를 통해 도커 사용 자원을 제한하는 방법1. cgroups 디렉토리 생성(디렉토리명: docker_limit)sudo cgcreate -g memory,cpu:/docker_limit2. CPU, 메모리 제한 설정 추가//..
배경납품한 솔루션 WAS의 응답이 피크 시간대에 느려지는 현상이 관찰되었습니다. 초당 약 600개 이상의 페이지 요청이 지속적으로 발생함을 모니터링할 수 있었는데 이는 기존 고객사들 대비 많은 처리량을 요구하다보니 별도의 조치가 필요했습니다. 이에 따라 제한된 자원 내에서 수평 스케일(scale-out)에 대한 부하 테스트를 수행하여 적당한 타협점을 도출해낼 수 있었는데, 그 과정과 결과를 공유하고자 합니다. 로드밸런싱은 도커와 Nginx를 이용하여 수행했습니다.테스트 수행 방식- JMeter 이용- OS에서 도커 자원 제한: 8코어 16GB 메모리 (다수 컨테이너가 공유함)- 가장 많은 부하가 걸리는 WAS의 API에 대해 초당 요청 수를 증가시켜가며 평균, 최대 응답시간 측정테스트 결과*결과표의 'C..
배경도커 관련 의존성과 설정 파일들을 삭제한 후에도 도커 네트워크 인터페이스가 남아있는 경우가 있었습니다. 도커가 아직 설치되어있는 상태라면 docker network ls, docker network rm 명령어를 통해 네트워크 인터페이스도 함께 삭제할 수 있지만, 도커를 사용할 수 없는 경우 도커 네트워크 삭제를 위해 사용 가능한 간단한 명령어를 소개합니다.방법- iproute 설치: yum install iproute- 명령어 입력:ip -o link show | awk '/02:42/ && /docker0|br-/ {print $2}' | sed 's/://g' | xargs -I {} ip link delete {}명령어 설명1) ip -o link show- 현재 시스템의 네트워크 인터페이스..
배경도커 동작 중 방화벽 적용을 위해 리눅스의 방화벽 프로그램인 firewalld를 켜면 서비스가 동작하지 않는 현상이 관찰되었습니다. 처음에는 방화벽 정책때문에 도커 네트워크가 차단되는 문제라고 생각되어 방화벽 정책을 들여다보았고, 이후 컨테이너 재시작 시 출력되는 '기존에 생성해놓은 도커 네트워크 인터페이스를 찾을 수 없다'는 오류메시지를 관찰한 후에는 도커 네트워크가 관리되는 부분을 살펴봐야겠다고 판단했습니다. 문제의 원인은 도커 네트워크 인터페이스는 디폴트로 iptables에서 관리되는데 반해 firewalld는 nftables를 디폴트로 사용하기 때문이었습니다. 방화벽이 내려가있을 때는 도커가 도커용 네트워크 인터페이스(docker0, br-... 등)정보를 iptables에 등록하게 되는데, ..
배경솔루션 설치 중 특정 구간에서 모든 요청에 대한 쿼리스트링이 사라지는 현상이 관찰되었습니다. 서버 A(웹 서버) -> 서버 B(솔루션서버) 로의 요청 시 A의 로그에는 쿼리스트링이 정상적으로 찍히는 반면 서버 B의 로그에서는 쿼리스트링만 사라진 채로 HTTP 요청이 들어오는 것을 확인할 수 있었는데 이상한 건 쿼리스트링만 사라진다는 점이었습니다. 예를 들어, https://www.example.com/solution/user?id=11 호출A (www.example.com에 해당하는 웹서버)-> B(/solution 경로에 리버스 프록시로 맵핑된 솔루션 서버) 호출B에는 www.example.com/solution/user 만 전달됨이런식으로 쿼리스트링이 없어지는 경우 소프트웨어의 정상적인 동작을 기..