시간나는대로 틈틈히 정리 합시다~~!!!

closure-compiler.appspot.com/home

KT 기본 DNS 서버 : 168.126.63.1 보조 DNS 서버 : 168.126.63.2 SK 기본 DNS 서버 : 210.220.163.82 보조 DNS 서버 : 219.250.36.130 LG 기본 DNS 서버 : 164.124.101.2 보조 DNS 서버 : 203.248.252.2 Google 기본 DNS 서버 : 8.8.8.8 보조 DNS 서버 : 8.8.4.4

1. Ftp 서버 연결용 윈도우 계정 생성 2. Ftp 서버 설치 3. Ftp 서버 셋팅 4. FTP 포트 방화벽 설정 5. 방화벽 설정 - 제어판 > Windows 방화벽 > 고급설정 > 인바운드 규칙 6. FTP 재시작

처음 Spring boot 프로젝트 생성 시 실행 되는 기본 파일에 보면 아래와 같이 @SpringBootApplication 이라고 붙어 있는걸 볼 수 있다. @SpringBootApplication public class MyApplication { public static void main (String[] args) { SpringApplication.run(MyApplication.class, args); } } 해당 애노테이션의 기능은 아래와 같다. - 컴포넌트 검색을 활성화해서 애플리케이션 클래스의 패키지와 모든 하위 패키지에서 스프링 컴포넌트와 구성 클래스를 검색한다. - 애플리케이션 클래스 자체를 구성 클래스로 만든다. - 자동 설정을 활성화해 스프링 부트가 설정 가능한 JAR파일을 클래..

1. 테스트 파일 생성 [root@hostname ~]# vi test.txt # 파일 내용 200 a 300 b 400 c 500 a 600 b 700 c 2. a 값 검색 [root@hostname ~]# grep 'a' ./test.txt # 결과 200 a 500 a

1. 파일 내용 입력 [root@hostname ~]# vi test.txt # 파일 내용 200 a 300 b 400 c 500 a 600 b 700 c 2. 파일 내용 null 로 덮어씀 [root@hostname ~]# cat /dev/null > ./test.txt [root@hostname ~]# vi test.txt 3. cat 명령어를 이용해 톰캣 로그 삭제 [root@hostname logs]# cat /dev/null > catalina.out

1. 문제점 - 응답 시간이나 하드웨어 자원 사용량이 지나치게 높은 경우 문제의 근본 원인을 찾는게 매우 어렵다. - 마이크로서비스별 하드웨어 자원 사용량을 분석할 수 있어야 한다. 2. 해결책 마이크로서비스 인스턴스가 사용하는 하드웨어 자원 사용량에 대한 메트릭(metric)을 수집하는 새 컴포넌트(모니터 서비스)를 시스템 환경에 추가한다. - 오토스케일링(auto-scaling)된 서버를 포함해 시스템 환경에서 사용하는 모든 서버의 메트릭을 수집해야 한다. - 서버에서 새로 시작된 마이크로서비스 인스턴스를 감지해 메트릭을 수집해야 한다. - 수집한 메트릭을 조회 및 분석하기 위한 API와 그래픽 도구를 제공해야 한다. 3. 구현된 오픈소스 도구 - 쿠버네티스 : 그라파나와 프로메테우스 (참고: 쿠버네..

1. 문제점 다수의 마이크로서비스 인스턴스가 여러 서버에 분산돼 있는 시스템 환경에선 중단되거나 지연된 마이크로서비스 인스턴스를 수동으로 감지하고 대처하는 것이 어렵다. 2. 해결책 - 시스템 환경의 상태를 관찰하는 새 컴포넌트(제어루프)를 시스템 환경에 추가한다. - 이 컴포넌트는 운영자가 지정한 상태와 실제 상태를 지속적으로 관찰하며, 두 상태가 다른 경우에는 현재 상태가 지정한 상태와 일치하도록 조치를 취한다. 3. 구현 참고 컨테이너를 기반으로 하는 환경에선 쿠버네티스와 같은 컨테이너 오케스트레이터로 구현한다. 4. 구현된 오픈소스 - 쿠버네티스 : 쿠버네티스의 컨트롤러 매니저(controller manager)

1. 문제점 - 동기 방식으로 상호 통신하는 마이크로서비스 시스템 환경은 연쇄 장애가 발생할 여지가 있다. - 하나의 마이크로서비스가 응답하지 않으면 이 마이크로서비스의 클라이언트 또한 또 다른 클라이언트의 요청에 응답하지 않게 된다. - 이 문제는 시스템 환경 전체에 재귀적으로 전파되어 중요한 부분까지 중단시킬 수 있다. 2. 참고사항 - 이런 문제는 블로킹 I/O를 사용해 동기식 요청을 실행하는 경우에 자주 발생한다. - 다수의 동시 요청이 발생한 상황에서 서비스의 응답이 예기치 않게 지연되면 스레드 풀이 빠르게 소진돼 호출이 지연되거나 중단된다. - 이런 장애는 클라이언트의 클라이언트에게 연쇄적으로 전파된다. 3. 해결책 대상 서비스에 문제가 있다는 것을 감지해 새 요청을 보내지 않도록 차단하는 서..

1. 문제점 시스템 환경에 대한 외부 호출을 처리하는 동안 마이크로서비스 사이에서 흐르는 요청 및 메시지를 추적 할 수 있어야 함 장애 시나리오 예시 - 최종 사용자가 특정 장애에 대한 해결을 요청했을 때 문제를 일으킨 마이크로서비스를 찾고 근본 원인을 밝히려면 어떻게 해야 하는가? - 특정 엔티티와 관련된 문제를 지원하고자 이와 관련된 모든 로그 메시지를 찾고 싶다. 예를 들어, 어떤 주문 번호에 대한 문제가 발생했을 때 해당 주문의 처리에 관여한 모든 마이크로서비스의 로그 메시지를 찾으려면 어떻게 해야 하는가? 2. 해결책 - 공조 마이크로서비스 사이의 처리 과정을 추적하려면 관련된 모든 요청 및 메시지에 상관 ID를 넣어야 하고, 모든 로그 이벤트에 상관 ID가 있어야 한다. (correlation..