2021 05 03

2021-05-03¶

인프라 2단계¶

Application Log - 애플리케이션의 상태를 로그로 남기자 - 무엇을 로그로 남겨야 하는가? - 로그를 어찌 관리해야 하는가?

로그란? - 컴퓨터 등에 접속한 기록 등이 컴퓨터 내에 남아 있는 것 - 네트워크 접속 시 IP 주소나 접속한 OS 등이 서버 컴퓨터에 남음 - OS나 다른 SW가 실행중에 발생하는 이벤트나 각기 다른 사용자의 통신 SW간의 메시지 기록한 파일

로깅 공식문서 - 참고: https://docs.spring.io/spring-boot/docs/2.2.7.RELEASE/reference/html/spring-boot-features.html#boot-features-logging - 스프링 부트는 Commons Logging을 통해 내부 로깅을 진행 - 기본적으로는 Logback, 기타 Commons Logging, Log4J, SLF4J 등이 사용가능 - 로그 포맷 > 2019-03-05 10:57:51.112 INFO 45469 --- [ main] org.apache.catalina.core.StandardEngine : Starting Servlet Engine: Apache Tomcat/7.0.52
2019-03-05 10:57:51.253 INFO 45469 --- [ost-startStop-1] o.a.c.c.C.[Tomcat].[localhost].[/] : Initializing Spring embedded WebApplicationContext
2019-03-05 10:57:51.253 INFO 45469 --- [ost-startStop-1] o.s.web.context.ContextLoader : Root WebApplicationContext: initialization completed in 1358 ms
2019-03-05 10:57:51.698 INFO 45469 --- [ost-startStop-1] o.s.b.c.e.ServletRegistrationBean : Mapping servlet: 'dispatcherServlet' to [/]
2019-03-05 10:57:51.702 INFO 45469 --- [ost-startStop-1] o.s.b.c.embedded.FilterRegistrationBean : Mapping filter: 'hiddenHttpMethodFilter' to: [/*]
```
  - 시간&날짜 -- Log 레벨: ERROR/WARN/INFO/DEBUG/TRACE -- 프로세스 ID -- [쓰레드 이름] -- 로거 이름 -- 로그 메시지
```

로깅 전략 - 참고: https://meetup.toast.com/posts/149 - spring-boot에서는 Logback을 확장하여 편리한 logging 설정을 할 수 있다 - Logger 등록과 Level 설정 - spring-boot에서는 application.yml의 설정만으로 logger와 level을 지정할 수 있음 - application.yml에 정의한 properties로도 logging이 동작하도록 지원
```
logging:  
    level:  
        root: warn  
        com.parfait.study.simplelogging.service.SomeService: info  
```

cAdvisor - 컨테이너의 리소스 사용과 퍼포먼스 현황을 알려줌 - 데몬으로 컨테이너 정보를 수집/집계/처리 함 - 각 컨테이너에 대해 리소스 분리, 리소스 사용량, 리소스 사용 히스토 그램을 유지

CloudWatch - 클라우드 와치는 AWS에서 동작하는 애플리케이션의 상태를 모니터링하는 도구 - 애플리케이션: EC2, RDS, ElasticCache 등 - 모니터링: 머신의 CPU 점유율, 남은 메모리의 용량 등

운영하기 질문 답변¶

Qs. CPU 사용률 100%는 장애를 의미하지 않아요. 그럼에도 파악하는 이유는 무엇일까요? - CPU 사용률 100%는 자원이 최대로 효율적이게 사용되고 있다는 뜻 - 하지만 이 상태에서 추가 요청이 들어온다면, 부하가 발생하게 된다는 뜻 - 서버의 부하는 낮은 상태로 유지하는 것이 좋음 - Close wait 등의 에러가 발생할 수 있기 떄문

Qs. 메모리가 고갈되면 어떤 상황이 발생할까요? - 참고: https://k39335.tistory.com/36 - 각각의 프로세스는 독립된 메모리 공간을 가짐 - 프로세스의 메모리 주소 중 현재 처리중인 일부분이 메모리에서 사용 중 - 사용되고 있는 프로세스 메모리의 일부분을 "페이지"라고 함 - 메모리가 여러개의 페이지로 꽉 차서, 더 이상 프로세스의 페이지가 메모리를 할당 받을 수 없다면, "페이징"이 일어남 - "페이징"은 잠시 메모리에서 프로세스의 페이지를 제거해 디스크에 저장해두는 방식 - 페이징을 통해 부족한 메모리에 비해 더 많은 프로세스를 실행할 수 있다는 장점이 있음 - 하지만, page-in/page-out은 오버헤드를 발생시킴 - 페이징(스와핑)은 결국 물리 메모리가 부족하다는 증거이기에, 실제 물리 메모리 영역(RES)을 많이 차지하고 있는 프로세스를 확인해 볼 필요가 있음 - 메모리 관리 전략을 다시 잡아야 할 것 - I/O 대기와 Block 상태의 프로세스가 있는 지 확인해 볼 것

Qs. 디스크가 꽉 차면 어떤 현상이 발생할까요? 그리고 어떤 파일들부터 지우면 좋을까요? - 참고: https://medium.com/@EJSohn/out-of-memory-killer-%ED%9A%8C%ED%94%BC%ED%95%98%EA%B8%B0-9efc65f88c92 - 디스크의 스왑 공간이 꽉 찼다면, 즉 시스템의 실제 메모리와 가상 메모리 공간을 모두 사용해 새로운 메모리 공간을 확보할 수 없다면, Linux 커널이 프로세스를 종료시켜 여유 메모리를 확보하는 omm-killer가 발생함 - OOM-killer는 시스템을 위해 하나 이상의 프로세스들을 다음과 같은 기준으로 희생시킴 1. 완료된 작업의 수를 최대로 유지할 수 있게 한다 2. 많은 양의 메모리를 복구한다 3. 메모리를 많이 소비하지 않는 프로세스는 죽이지 않는다 4. 최소한의 프로세스만 희생시킨다 5. 개발자가 생각했을 때 죽어도 놀랍지 않을 프로세스를 죽이려고 한다 - OOM-killer는 희생시킬 프로세스를 고르기 위해 각 프로세스에 점수를 매기는 과정을 거침 - 할당된 메모리 양, fork()된 자식 프로세스의 메모리, 얼마나 오래돌고 있는 프로세스 인지, 실행 권한 등을 고려
- 참고: https://unix.stackexchange.com/questions/63408/what-happens-when-a-hard-drive-fills-up - 디스크가 꽉 찼다고 시스템의 어플리케이션이 중단되지는 않음 - 다만 새로운 정보를 저장할 공간이 없기 때문에 새로운 파일 생성 (로그 파일 등)은 불가할 것 - 지워야 할 파일은, 1. 크기가 큰 파일 삭제를 고려해본다. 2. 불필요한 로그 파일 삭제를 고려해본다. 3. vim을 통해 파일을 열때 자동으로 생성되는 .swp가 너무 많은지 확인해본다. - 도움 주신 분: 포츈 :)

Qs. Reverse Proxy를 별도로 구성함으로써 얻는 이점을 설명해주세요. - 참고: https://www.lesstif.com/system-admin/forward-proxy-reverse-proxy-21430345.html - 클라이언트가 데이터를 요청하면, Reverse Proxy는 요청을 받아서, 내부 서버에서 데이터를 받은 후에, 이 데이터를 클라이언트에 전달 - 이를 통해 보안을 강화할 수 있음 - 내부 서버에 직접적으로 접근할 수 있도록 개방하면, 보안에 취약해짐 - ex. WAS에 접속 가능해지면, DB까지 위험해진다. - 아파치 웹 서버가 해킹 당해도 웹 서버 권한 만으로는 내부망 연결이 불가능하게 만들어야 안전함 - 또한, 상황에 맞게 Web Server와 WAS를 유연하게 늘릴 수 있는 장점이 있음