1. TTL (time to live) 지정가능
- 데이터가 살아남는 시간을 지정하여, 해당 시간동안만 메모리에 존재하도록 지정할 수 있다
2. lpush, rpush
3. mget -> multiple get
4. string, hash, set등
5. smove기능
6. lpop, rpop기능
7. ltrim 이용해서 원하는 range의 데이터만 정제할 수 있다
8. 트랜잭션 기능
1) error났을 경우 - 해당 트랜잭션 aborted되어 처리안됨
2) 다른 유저에 의해서 동시에 진행될 경우- aborted되어 처리안됨
9. .redis어쩌구~_history 파일에서 지금까지 친 명령어 확인가능
ex) tail -100 .redis해당파일이름
10. /var/log/redis안에 기본적으로 로그파일 저장되어서 들어감
11. /etc/redis의 redis.conf에서 포트번호 로그파일저장경로 등등 커스터마이징가능
1. 빠르다
1) 인메모리 데이터베이스
2)C언어 기반
3)key-value store (자바의 map, 파이썬의 dict와 비슷)
2. 오픈소스이다 (무료)
3. 인메모리이면 -> 그럼 shutdown되면 어떻게 되는가 ? -> disk에도 저장하기 때문에 data persistence를 보장한다
4. 고가용성
- 분산 노드 배치로 하나가 죽어도 다른애가 대신 service가능 ㅇㅇ
5. 확장성
- 노드의 추가 삭제가 자유롭다
6. 기타
- 다양한 key를 지원하며 이 key로 value를 손쉽게 빠르게 찾아올 수 있다
7. 단점
- 인메모리기반이기때문에 저장될수있는 데이터의 양에 한계가 있을수있다(RAM사이즈에 따라서)
1. 확장성
- elastic
- 유연하게 추가/삭제가 가능해야한다
2. 장애회복성
- single point of failure가 없어야 한다.
- 최소 2개 이상. 이중화가 되어있어야 한다.
- 이중화의 대상? 웹서버, db서버는 물론
- 하드웨어 장비들 (라우터, 스위치) 도 이중화가 되어야 한다.
- 스위치의 bandwidth보다 많은양의 트래픽이 들어올 경우 장애가 발생할 수 있다.
3. 자동화
- automation
-사람이 수동으로 하는 부분에서는 실수가 발생할수있다.
- infrastructure as code 로서 , 모든것은 스크립트 하나로 복제가 가능하여 누구나가 손쉽게 동일한 환경을 구성할 수 있어야 한다.
- 이를 위한 다양한 툴이 존재한다 (ansible, terraform 등)
4. 모니터링
- 항시 모니터링 되어야 한다.
(apach서버를 기준으로 한다.)
1. root권한으로 운영되지 않도록 전용 데몬으로 구동
2. 관리서버 디렉토리 (/usr/local/apache)의 접근 권한 확인.
- 일반 사용자가 접근할 수 없도록한다 750이하
3. 설정파일 권한 확인
- apach설치 디렉터리/conf내 디렉토리의 *.conf파일 권한 설정 확인
- 설정 파일의 indexes옵션을 삭제한다
- 디렉토리 검색기능 -> 해당 디렉토리에 존재하는 모든 파일이 리스팅 되므로 웹서버구조 노출 및 주요 설정파일의 내용이 유출될 가능성이 있다
4. 상위 디렉토리 이동제한 설정
- 상위 경로로 이동하는 것이 가능할 경우. 접근하고자 하는 디렉토리의 하위 경로에 접속하여 상위경로로 이동함으로써 악의적인 목적을 가진 사용자의 접근이 가능해짐
5. 로그 디렉토리 권한 설정
- apache설치 디렉터리/logs/ 및의 파일들
- 톰캣의 경우
catalina base디렉터리/conf/web.xml 에서
<servlet> ...
<init-param>
<param-name>listings</param-name>
<param-value>flase</param-value>
</init-param>
</servlet>
설정한다!
(기본적으로 . 설치하게 되면 false설정이라고 한다)
6. 적절한 로그 포맷설정
- referer설정, user-agent설정, 등 공격자 위치를 파악할 수 있는 포맷설정을 해야 함
7. 헤더 정보 사용 불가능하도록 설정
- Server에 대한 정보가 헤더에 나타나지 않도록 설정해야 함
8. 불필요한 메서드 금지
9. 파일 업로드, 다운로드 용량 제한
10. DocumentRoot디렉토리 설정 변경
11. 세션 타임아웃 설정
12. 관리자 콘솔 접근 통제 :
- 불필요한 경우 프로세스 종료
- 필요한경우 어려운 port로 변경
13. 관리자 디폴트 계정 명 변경
- 기본유저, 패스워드를 삭제하거나 주석으로 처리하여 기본유저로의 로그인이 불가능하도록 설정한다.
- 톰캣디렉터리/conf/tomcat-users.xml설정에서 변경
- 유추하기 쉬운 계정명 사용시 brute - forth공격에 노출되기 쉽다
14. 복잡한 패스워드 설정
- 공통기준)
- 길이: 9자리 이상, 3종류의 문자이상
- 변경주기: 3개월/ 중요 시스템의 경우 1개월
- 재사용 금지: 직전 1개 패스워드
- 계정 잠금 : 10회 실패시 .
- null패스워드 사용금지, 문자또는 숫자만으로 구성 금지, 사용자 id와 동일한 패스워드 금지, 연속적인 문자 사용금지(1111, abcd, 1234등)
- 주기적인 패스워드 재사용 금지
- 전화번호, 생일같이 추측하기 쉬운 개인정보를 패스워드로 사용 금지
- 초기 패스워드는 사용자에게 부여한 후 최초 접속시 반드시 변경하도록 설계
- 패스워드는 마스킹 처리하여 화면상에서 읽을수없도록 표시
- 패스워드 관리기능)
- 패스워드 분실로 인한 신규 패스워드 발급 절차 적용
- 패스워드 분실시 패스워드 초기화 처리후 로그인하여 패스워드 변경을 유도 한다.
- tomcat-users.xml파일 의 권한 설정 확인(600)
1. 디폴트 계정,scott계정등 불필요한 계정 삭제
2. 원격에서 db서버로의 접속 제한
- 지정된 ip주소에서만 접근 가능하도록 제한해야 하고, 비인가자가 내부망에 접근할수있는 위험을 없애야 함.
3. mysql명령 히스토리 검사
- 로컬시스템에서 mysql명령을 사용하여 db에 접근할때 명령어 행에 계정 및 패스워드를 붙여서 사용하는 경우 쉘 히스토리 (.history/.sh_history)파일에 기록이 남는다.
- history파일의 권한설정(600이하)를 확인하고,
- mysql명령어 사용시 명령어 사용시 계정/패스워드 입력하지 말고 mysql -u 계정명 -p명령만 입력한후 패스워드를 개별적으로 입력할 수 있도록 한다.
4. mysql 실행파일, 데이터 파일에 대한 권한 확인
5. 개발시스템, 운영시스템의 분리 확인
- 하드웨어적으로 분리되어있어야 하며. 원칙적으로 개발자와 운영자가 분리되어야 함. 개발자의 운영시스템으로의 접근을 제한
6. 패스워드 정책 확인
7. GRANT_OPTION이 일반사용자에게 설정되어있지 않은지 점검
1. root계정으로 telnet, ssh서비스에 직접 접근이 가능한지 점검
- root계정으로 직접 접근하여 사용 x, 일반계정으로 접속후에 루트계정으로 전환하여 (su) 사용할것
2. 패스워드 복잡성 설정 여부 확인
3. 로그인 실패 임계값을 설정하여 -> 잠금이 되도록 계정 보호
4. 패스워드 파일 보호
-> etc/password가 아니라 shadow 파일에저장되고있는지 확인.
etc/password에는 평문으로 저장되기도..
반드시 암호화하여 shadow파일에 저장한다
5. root이외의 uid가 0인 다른 계정이 있는지 점검
-> 해킹의 위협으로 심어진 다른 계정일수도 있고.
"/etc/passwd" 파일 내 UID 확인 (세 번째 필드 값)
루트 이외의 사용자가 슈퍼유저 권한을 가지고 있으면 권한이 중복되기도 하고 감사가 어려워지므로, 삭제하거나 적절한 uid를 100이상의 번호로 등록한다.
6. su권한 제한
- 그룹별로 권한을 제한하여. su명령어를 사용할수있는 그룹을 제한한다
7. 패스워드 최소길이 설정
- 8자 이상으로 설정되어있는지 점검
8. 패스워드 최소 사용기간 설정 여부 확인
- 패스워드 최대 사용기간 지난 후 패스워드 변경, 이후 다시 바로 이전패스워드로 변경하는 것을 방지하기 위한 설정이 필요함. 최소사용기간은 1일 이상으로.
9. 불필요한 계정 제거
- 퇴직자, 휴직자, 계약 해지자 등의 불필요한 계정, 미사용 계정 삭제
- 프로그램 설치시 디폴트로 생성되는 계정들 삭제
10. 관리자 그룹에는 최소한의 계정만 포함
11. 동일한 uid로 설정된 계정이 존재하는지 확인
- 동일한 uid를 쓰는 계정이 존재하는 경우. 타계정 소유의 파일 및 디렉터리에 접근이 가능하게 되어 침해사고가 발생할 수 있음
12. 로그인이 필요하지 않은 계정에 로그인권한이 있는지 점검.
- uid가 100dlgkdlrjsk 60000이상인 시스템계정 -> nologin설정
13. 세션 타임아웃 설정
- 5분 이내로 설정 권고.
14. root 홈, PATH 디렉터리 권한 및 PATH 설정
PATH환경변수에 .(현재디렉토리)있을경우 root계정으로 su 해서 사용할 때 비의도적으로 현재 디렉토리에 위치하고 있는 명령어가 실행될 수 있다
15. etc/passwd , etc/shadow파일의 소유자 설정 확인
- etc/passwd에서 두번째 필드가 x여야함.
- etc/shadow파일은 root계정만 읽을수있어야 함.
16. /etc/hosts파일 소유자 및 권한 설정
- /etc/hosts파일의 권한이 600인지 확인
- 소유자가 root인지 확인
- ip 주소와 hostname을 맵핑하는데 사용되는 파일. 이 파일의 접근권한 설정이 잘못되어있을 경우 악의적인 시스템을 신뢰할 수 있어 쓰기 권한을 제거해야 한다.
17. 인터넷 슈퍼데몬 서비스 설정파일 (/etc/(x)inetd.conf)파일 소유자 및 권한 설정
- 쓰기 권한 없도록 600,
- 소유자 root인지 확인
18. /etc/syslog.conf파일 소유자 및 권한 설정
- 설정 변조를 통해 침입자의 흔적 또는 시스템 오류를 방지하기 힘들게 만들 수 있다. 644이하 및 소유자 root확인
19. etc/services 파일 권한 확인
- 설정 변조를 통해 운영 포트 번호를 변경하여 불필요한 서비스 혹은 악성 서비스를 실행할 수 있다. 644이하 및 root소유자 확인
20. setuid, setguid설정 확인
21. 환경변수 파일 소유자 및 권한 설정
- .profile , .bashrc, .bash_profile등 환경변수 설정 파일의 타사용자 쓰기 권한을 제거
22. /dev디렉토리 내 불필요한 device존재 여부 점검
23. 접속을 허용할 ssh의. ip주소 및 포트 점검 (telnet과 같은 서비스를 사용하여 접근할 수 없도록 제한)
24. umask설정값 확인 . 022를 권장
25. finger서비스 이용가능한지 확인
- etc/passwd파일을 조회가능한 명령어. 사용 불가능하도록 설정
26. anonymous FTP사용중인지 점검
인터넷에서 FTP를 사용할 때 anonymous FTP는 사용자들이 서버에 자신을 식별시키지 않고서도 파일에 접근할 수 있는 방법을 제공한다. 보통의 FTP 사이트들은 오직 적법한 사용자 아이디와 패스워드를 가진 사람만이 이용할 수 있는데 반해, anonymous FTP는 파일을 보거나 다운로드하기 위해 해당 서버에서 부여된 사용자 아이디나 패스워드가 없더라도 작업이 가능하기 때문에 anonymous 라고 부른다. Anonymous FTP 서버에 접속한 뒤 사용자 아이디로 "anonymous" 라고 입력하고, 패스워드에는 자신의 이메일 주소를 입력하면 로그인이 허용된다 (이때, 패스워드를 넣지 않거나 어떤 내용을 넣더라도 로그인 하는데 문제가 없지만, 대개 자신의 이메일 주소를 쳐 넣는 것이 통신상의 예의로 되어있다). |
- 불필요한 사용자, 악의적인 사용자가 시스템에 대한 정보를 획득하게 되는 것을 방지한다.
27. Cron관련 파일들의 권한이 640이하인지 확인
28. dos공격에 취약한 명령어 사용하지 않도록 제한
- echo
-chargen
- finger
- nntp
- ntalk 등.
29. nts서비스 확인
30. 불필요한 rpc서비스 사용하고 있는지 점검
31.ftp서비스 사용하고 있는지 점검 , 불가능하도록 한다 (sftp를 이용)
- 설정이전. curl 메소드로 확인한다.
Allow 헤더 출력되지 않고 있다.
1. 파일업로드
1) 확장자 체크는 화이트 리스트로 관리하기
2) 파일명저장될때 임의의 문자열을 덧붙이기
3) 업로드 디렉터리를 제한하고, 첨부파일이 저장된 디렉터리의 실행권한 chmod제한하기
2. XSS
1) 종류
a) 반사 XSS: 서버를 이용하지 않고, link를 이용하여 스크립트를 실행 (이미지, 비디오, a href 등)
b) 저장 XSS : 서버를 이용한 스크립트 실행. 일단 서버를 타고 한번 데이터베이스에 저장되고, 저장된값이 그대로 다시 브라우저로 노출되면서 스크립트가 실행된다.
2) 방어
- 스크립트 치환 라이브러리 사용
3. SQL injection
- prepared statement 사용.
prepared statement의 경우 미리 sql질의문을 정적으로 컴파일 한 후에, 파라메터가 들어갈 자리만 남겨둔다. 동적으로 생성되는 파라메터는 문자열로 취급되어 들어가기 때문에 안전하다. 일반 statement의 경우 파라메터와 함께 그 순간 동적으로 쿼리를 생성하기때문에 위험하다.
4. 취약한 패스워드 정책
- 세가지 종류 이상의 문자구성, 8자리 이상의 길이
-혹은 두가지 종류 이상의 문자구성, 10자리 이상의 길이
5. 자동화 공격
- brute-forth 공격을 자동화하여 패스워드 크래킹이 가능하므로, 이것을 방지하기 위해서는 인증시도 횟수를 제한하여야 한다.
- 패스워드만 틀린것인지, 아이디/패스워드 둘다 틀린것인지 구별할 수 있어야 한다.
6. 취약한 관리자 페이지 접근
- 관리자 로그인 페이지 주소 변경
- 관리자 로그인 페이지 접근 레벨 -> ip주소로 설정. 반드시 사내ip에서만 접근 가능해야 한다. tomcat-users
7 백업 및 테스트파일 존재
- 공개형 솔루션의 샘플파일
- 불필요한 테스트 페이지 혹은 개발페이지
- 삭제, 디렉토리 경로변경, 접근제한 설정 등.
8 세션 재사용 및 타임아웃 설정
- 로그인마다 동일한 세션아이디가 생성될경우 취약
- 일정시간이 지난 후 재접속시에도 로그인 상태가 유지될 경우 취약(권고: 30분)
- 쿠키 제거 & 세션 제거 함께 해야한다.
-로그인 시마다 새로운 세션 아이디가 발급될 수 있도록 해야한다.
이것을 단순히 for문 돌려서 char로 바꾸어보니 값이 많이 깨졌다 (아스키코드값은 다 양수이니까)
해결하기 위하여 Base64Util을 사용하여 String 으로 반환하도록 한다.
참고로 expire time설정되어있어서 일정시간 지나면 다시 새로받아야하는 번거로움이 있다..
{
"code": "2ffd133a-d17a-431d-a6a5",
"scope": "login inquiry transfer",
"client_info": "test",
"state": "b80BLsfigm9OokPTjy03elbJqRHOfGSY"
}코드발급 완료
ARS 인증을 진행하고 code를 이용해서 토큰을 발급받는다
{
"access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiIxMTAxMDAyNTg3Iiwic2NvcGUiOlsiaW5xdWlyeSIsImxvZ2luIiwidHJhbnNmZXIiXSwiaXNzIjoiaHR0cHM6Ly93d3cub3BlbmJhbmtpbmcub3Iua3IiLCJleHAiOjE2NDk3NjYxMzAsImp0aSI6ImI0ZDZiMTFmLThkZGEtNDk2NC1hMWFkLTA1ODk5MTkyY2JiZCJ9.0qaWuuG23GpeQPdlIt4Hg1uXuylpedYkbM9KnaAXkcQ",
"token_type": "Bearer",
"refresh_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiIxMTAxMDAyNTg3Iiwic2NvcGUiOlsiaW5xdWlyeSIsImxvZ2luIiwidHJhbnNmZXIiXSwiaXNzIjoiaHR0cHM6Ly93d3cub3BlbmJhbmtpbmcub3Iua3IiLCJleHAiOjE2NTA2MzAxMzAsImp0aSI6ImM1NGY0MzVmLWQzYWQtNGY4My1iZjY3LTFjZDk0MmJkYmRjOCJ9.13Vbe8ded-R7ezEoNzvxJozEoVTZJKGVvqO1sLPqXYw",
"expires_in": 7775999,
"scope": "inquiry login transfer",
"user_seq_no": "1101002587"
}- CompletionService는 Executor의 기능과 BlockingQueue의 기능을 하나로 모은 인터페이스이다. 완료된 결과값을 쌓아둘 블로킹큐를 생성하고. 작업이 완료된 순서대로 이 큐에 쌓이게 된다.
<중단정책>
- interrupt : 해당 스레드에게 중지를 요청하는것 . 이 요청을 받은 스레드는 스스로 적절하게 종료할수있게끔 행동해야한다
- 가장 기본적인 취소정책은 cancel메소드 호출 -> volatile로 선언한 취소플래그를 true로 변경-> 작업 종료 하는 것이다
- 그러나 블로킹큐의 put , take 같은 블로킹메서드를 호출하는 경우 반복문 작업 내부에서 취소요청이 들어왔는지 확인하지 못하는 경우가 생길 수 있다. 이런 경우 while 반복문의 조건확인 부분에서 인터럽트 여부를 직접확인 하는 방법으로 응답속도를 개선할 수 있다.
<인터럽트에 대한 대응>
- 호출 스택의 상위메소드로 예외를 던져서 상위메소드에서 처리할수있도록 넘긴다. (throws InterruptException 한다)
- 호출 스택의 상단에 위치한 메소드가 직접 처리할 수 있도록 인터럽트 상태를 유지한다. ( Thread.currentThread.interrupt()를 하여 인터럽트 상태 유지. 상위 메서드가 얘를 관리할수있도록 한다.)
- 스레드 풀에 들어있는 스레드에 함부로 인터럽트를 걸면 안된다. 해당 스레드에 인터럽트가 걸리는 시점에 어떤 작업을 실행하고 있을지 알수없기 때문이다. 따라서 작업을 중단하려 할 때는 항상 스레드에 직접 인터럽트를 거는 대신 Future의 cancel메소드를 사용해야 한다.
<스레드 기반 서비스 중단>
- 스레드를 소유하는 객체는 대부분 해당 스레드를 생성한 객체라고 볼 수 있다. 스레드 풀을 예로 들면, 스레드 풀에 들어있는 모든 작업 스레드는 해당하는 스레드 풀이 소유한다고 볼 수 있고, 따라서 개별 스레드에 인터럽트를 걸어야 하는 상황이 된다면 그 작업은 스레드를 소유한 스레드 풀에서 책임을 줘야 한다.
- 애플리케이션이 직접 개별스레드에 액세스하는 대신 스레드 기반 서비스가 스레드의 시작부터 종료까지 모든 기능에 해당하는 메서드를 직접 제공해야 한다. 그러면 애플리케이션이 스레드 기반 서비스만 종료시키면 스레드 기반 서비스는 스스로가 소유한 모든 작업 스레드를 종료시키게 된다. 좋은 예로 ExecutorService인터페이스는 shutdown메소드와 shutdownNow메소드를 제공한다.
<비정상적인 스레드 종료 상황 처리>
-예상할 수없었던 예외로 인하여 스레드가 비정상적으로 종료되는 경우 . 자바에서 기본적으로 제공하는 스레드풀에서는 작업에서 예상치 못한 예외가 발생했을때 해당 스레드가 종료되도록 하면서, try-finally구문을 사용해 스레드가 종료되기 전에 스레드 풀에 종료된다는 사실을 알려 다른 스레드를 대체해 실행할 수 있도록 하고 있다.
- UncaughtExceptionHandler를 디폴트로 셋팅해주거나. 혹은 afterExecute메소드를 활용한다.
- 단 Callable로 작업결과를 받는 경우 ExecutionException에 감싸여진 상태로 예외가 넘어오므로 여기에서 처리해주어야 한다.
<JVM종료>
- ExecutorService를 컴포지션으로 사용하는 클래스의 start()부분에 종료훅을 등록하여 자원을 모두 해제한후 stop할수있도록 한다.
- 종료 훅이 여러개 등록되어 있는 경우에는 여러개의 종료 훅이 서로 동시에 실행 되기 때문에 다른 종료 훅에서 해당 서비스를 사용하고 있었다면(즉 힙메모리에서 해당 객체를 공유하고 있었다면) 이미 다른 곳에서 종료되어 문제가 발생할 수 있다. 이런 경우를 예방 하려면. 서비스별로 종료훅을 등록하기 보다는 모든 서비스를 정리할 수 있는 하나의 종료 훅을 사용해 각 서비스를 의존성에 맞춰 순서대로 정리하는 것도 방법이다. 실제로 서비스 간의 종속성이 명확히 보이는 어플리케이션이라면 종료시점의 마무리 절차를 순차적으로 처리하도록 하여 올바른 순서대로 서비스를 종료하고 마무리할 수 있다.
- 데몬 스레드는 예고 없이 종료될 수 있기 때문에 애플리케이션 내부에서 시작시키고 종료시키며 사용하기에는 그다지 좋은 방법이 아니다.
---
<스레드부족 데드락> Thread Starvation Deadlock
- 특정 자원을 확보하고자 계속해서 대기하거나 풀 내부의 다른 작업이 실행되어야 알 수 있는 조건이 만족하기를 기다리는 것처럼 끝없이 대기할 가능성이 있는 기능을 사용하는 작업이 풀에 등록된 경우 발생할 수 있다.
- 다른 작업에 의존성을 가지고 있는 작업을 실행시키는 경우.
- 스레드 풀의 크기는 직접적으로 지정하는 것 이외에도 스레드 풀에서 필요로 하는 자원이 제한되어 원하는 크기보다 작은 수준에서 동작하는 경우도 있다. 예를 들어 10개짜리 JDBC커넥션풀을 사용해야 한다면. 결국 실제로 수행될 수 있는 양은 JDBC풀의 크기인 10개에 불과한 셈이다.
---
- 적절한 스레드 풀 사이즈
- 집중대응정책 : 적절한 큐 사이즈 조정 및 거부정책
- 스레드 팩토리 : 직접작성하여 커스터마이징할 수 있다. 스레드 이름을 의미있게 짓는다거나 로그기능을 포함하는 스레드를 넘긴다거나..
-----
<데드락>
- 상대가 자원을 놓기만을 기다리는 상태
- JVM은 데드락을 스스로 해결해주지못한다
- 데이터베이스 시스템의 경우 데드락상황에서 복구하는 기능을 가지고있다. (한쪽을 희생양으로 해서 트랜잭션을 강제종료)
- 락의 순서를 제어하여 데드락을 방지한다.
- 암묵적인 락 대신에 명시적인 락을 사용하고, 타임아웃을 지정하여 락을 확보하려는 시점에서 시간제한이 걸리면 이미 확보했던 락을 풀어주고 잠시 기다리다가 다시 작업을 시도해볼수있다.
<오픈호출>
- 락을 전혀 확보하지 않은 상태에서 메소드를 호출하는 것
- 데드락을 미연에 방지하고자 사용할 수 있다
- open call
<라이브 락>
- 특정작업의 결과를 받아와야 다음 단계로 넘어갈 수 있는작업이 실패할수밖에 없는 기능을 계속해서 재시도하는 경우에 볼수있다.
- 메시지를 제대로 전송하지 못했을 때 해당 전송 트랜잭션을 롤백하고 실패한 메시지를 큐의 맨 뒤에 쌓아두는 트랜잭션 메시지 전송 어플리케이션에서 자주 나타난다. 특정 메시지를 큐에서 뽑아 핸들러에 넘겼을때 핸들러는 같은 에러 결과를 내면서 계속해서 호출된다.
- 에러를 너무 완벽하게 처리하고자 회복 불가능한 오류를 회복 가능하다고 판단해 계속해서 재시도 하는 과정에서 나타난다.
- 프로듀서 컨슈머 패턴: 블로킹 큐를 이용하면 좀더 편하게 구현할 수 있다
재사용성이 높아지고 성능의 측면에서도 이득을 볼 수 있다. 프로듀서가 디스크, 네트워크 i/o에 시간을 많이 소비하고 컨슈머가 cpu를 많이 소비한다면- 둘 클래스로 분리, 단일 스레드에서 순차적으로 실행하는 것보다 성능이 크게 높아질 수 있다.
- 객체풀: 풀 내부에 소유하고 있던 객체를 외부에 공개할 때 적절한 동기화 작업이 되어있고, 그와 함께 풀에서 객체를 빌려다 사용하는 스레드 역시 외부에 공개하지 않는다. 적절하게 소유권이 이전되며. 새로운 스레드 내부에 객체가 완전히 한정된다.
- 작업 가로채기 패턴 : 컨슈머가 각자 덱을 가지며, 자신의 덱이 비었을 경우 다른 컨슈머의 덱을 살펴보고 맨 뒤에있는 작업을 자기 덱으로 가져온다. 맨뒤에있는 것을 가져오기때문에 해당 덱의 원 소유자와 경쟁이 생기지 않으며 규모가 큰 시스템에서 적절하다 . 컨슈머가 여러가지 작업을 해야 하는 경우 작업에 작업이 꼬리를 물며 쌓일수있는데 이러한 경우에 적합하다.
- 블로킹: i/o를 기다리거나, 락이 해제되기를 기다리거나, sleep등에 걸리거나 -> waiting, blocked , timed-waiting 상태에 들어간다.
- interrupt : 여러 스레드가 협력하며 작업하기 위한 방법. 강제로 멈추는 것이 아니라 중단을 '요청'한다.
- 세마포어 활용 : connection풀 관리 - 컬렉션의 크기에 제한을 두고 . 남은 객체가 없을 때 다른 스레드가 확보했던 객체를 반납받아 사용할 수 있을 때까지 대기하도록 할수있다.
- BoundedHashset : 컬렉션 크기가 가질 수 있는 최대 크기로 세마포어를 초기화 한다. add하기 전에 acquire하여 추가할 여유가 있는지 확인하고 add 해본다 . 만약 추가에 실패했다면 realease한다. 비슷하게 , remove는 remove하기 전에 release하여 세마포어에 퍼밋을 반납하여 남은 공간에 객체를 추가할 수 있도록 해준다.
- 스레드 안전성 확보 방법
1) 스레드 한정 :
-ThreadLocal 이용하기 .
- 스택한정(지역변수로만 사용)
2) 변경불가능한 객체로 만든다. 불변객체
- 모든 변수를 final로 선언
- 적절하게 초기화한다 ( 생성자에서 this를 노출하지 않는다. )
- 변경할수있는 메서드 제공x
* 값을 읽을때 -> 새로운 불변객체를 만들어 리턴한다
* 값을 변경할때 -> 새로운 불변객체를 만들어 리턴한다
읽을때와 변경할때 둘다 단일연산이 되어야한다
volatile은 변경하는 스레드가 한개일 경우에만 유효하게 된다
3) 동기화 한다.
- 올바르게 초기화해야한다. 쓰레기 혹은 잔여값이 들어있다. 자바의 경우 모든객체가 Object를 상속하므로 여기에 따른 쓰레기값이 들어있을수있다.
- 어떤 객체의 상태 state 조합. 은 해당 객체가 가지고 있는 변수의 개수 * 그 변수의 상태범위.
- 불변객체의 경우 한번 넣은 변수값이 바뀌지 않으므로 상태범위가 1개이다. 따라서 올바른상태인지 올바르지 않은 상태인지 검증하기 매우쉬워진다
- 상태범위가 좁아질수록 올바르지 않은 상태인지 검증하기 쉽다
- 올바르지 않은 상태를 가질수있다면( 다른 스레드에 의해 값이 변경되거나. ) 반드시 단일연산처럼 동작하도록 동기화해야한다
- 만약 여러개의 변수를 통하여 객체의 상태를 정의한다면 그 여러개의 변수를 변경하는 과정 전체를 단일연산으로 동작하도록 만들어야 한다. 개개의 AtomicInteger는 단일연산을 지원하지만 그 각기 여러개를 변수로 가지고 있는 클래스라면 하나의 변수를 바꾸고 다른 변수를바꾸려는 과정에서 다른 스레드가 끼어들 수 있다는 것이다.
- 객체의 상태는 해당 객체에 포함되는 모든 객체와 변수가 가질 수 있는 전체 상태의 부분집합이다.
- 객체 자체의 암묵적인 락을 사용하여 동기화할 수도 있고, 락으로 활용하기 위한 private객체를 준비하여 락으로 사용할 수 있다.
만약 이 객체를 외부에서 접근할수있는 수단을 제공한다면 함께 동기화 작업에 참여할수도있다.
- 스레드 안전한 객체 : 복사본을 제공한다.
성능에 문제가 될수있다(매번 새로운 객체 생성) , 요구사항에 따라서는 적합하지 않을 수 있다. 시시각각으로 변하는 데이터를 받기를 원하는 경우.
- 각각의 변수가 모두 스레드 안전한 클래스라고 할지라도 전체적으로는 스레드 안전성을 잃을 수 있다. 내부 변수간에 의존성을 가지고 있는 경우가 그러하다.
- 기능추가 : 1) 해당 라이브러리 직접수정 2) extends이용. 그러나 해당 라이브러리가 변경될경우 쥐도새도모르게 내 코드의 안전성이 파괴될 위험이 있다.
3) 도우미 클래스작성 -> composition을 활용한다- 위험!
4) 도우미 클래스 작성, implements를 활용한다
-재진입성 (reentrant): 동기화 메서드는 스레드 단위로 진입한다. 요청 단위가 아니다
- volatile 키워드 : 이 변수는 공유변수이며 재배치되서는 안된다는 뜻. 캐싱되지않는다
가시성만 보장한다
연산의 단일성은 보장하지 않음(약하다)
- 락은 연산의 단일성 및 가시성 둘다 보장
Situations when constructors are not thread safe are for example :
static variable from within a constructor without proper synchronization mechanismthis reference from within constructor before the object is fully initialized and can be accessed by other threads.
파티션 3으로 나누었음
데이터가 파티션별로 슉슉 들어간다.
컨슈머가 꺼져있는 동안 lag가 발생하는것확인할수있음
더불어 다시 키면- 파티션전부 subscribe하고있었기 때문에 순서 보장없이 막들어온다
순서를 보장하려면?? 파티션을 1개만 만들고.. 할당한다!
./bin/kafka-console-consumer.sh --bootstrap-server 13.124.113.23:9092 -topic test-02 --from-beginning
./bin/kafka-console-producer.sh --bootstrap-server 13.124.113.23:9092 --topic test-02
.\bin\windows\kafka-console-producer.bat --bootstrap-server 13.124.113.23:9092 --topic test-01
- 직렬화- 역직렬화 할때 allargsconstructor 가 없으면 에러가 발생한다
호스트 os 13306->3306 도커 컨테이너로 마리아db 데이터베이스 접속해보기
!!
호스트 ip와 포트번호를 직접 지정해서. 들어갈수있다!!!
현재 empty password 옵션주었기때문에 그냥 엔터치면 들어가짐 헤헤
- 도커를 다운로드
컨테이너 가상화기술.
도커 실행후
docker info 로 확인
docker ps -a
docker pull 이미지명
레지스트리로부터 이미지를 다운받는다.
docker container rm 컨테이너명
run 명령어를 통해서 컨테이너 생성및 실행 동시에 할 수 있음.
- 옵션
- p 포트포워딩. 호스트 os를 컨테이너의 os 와 연결시켜주는 통로를 뚫는다
--name 옵션지정하면 원하는 이름으로가능
-d detached mode 데몬으로 백그라운드 실행
-e environment 기타 환경변수 넣을 수 있다.
- msa 서비스는 하나의 서비스가 다른 여러 서비스들을 호출하고. 또 그것이 비동기적으로 다른스레드로 요청되기 때문에 하나의 트랜잭션을 추적하기에 어려움이 있다
- 이것을 도와주는 것이 sleuth 라는 라이브러리
- 하나의 요청 단위를 trace Id로, 스레드별로 id를 두개
traceId는 하나의 요청단위에 있어서 유니크하며 이것은 서비스간 소통을 할때에도 동일하게 유지된다 (신기하군. AOP 로 구현할수있을것같음 )
위 이미지에서보듯이 스레드가 달라졌다 - feignClient 이용한 비동기요청
그러나 traceId 는 유지된다.
이것을 zipkin서버와 연동하여 시각화 하면 더 좋다고는 하는데!!zipkin자체서버를 또 만들어야한다는 부담은 있다.. sleuth 만 넣어줘도. 좋을듯??
근데 - 결국에는 로그를 계속 심어줘야해서.... -> 이부분 어짜피 AOP로 해야되니까 걍 sleuth 안쓰고 다 AOP직접 구현해서 할수있을것도 같네...
1. homebrew install mariadb
2 . 초기의 경우 공백의 패스워드로 접근 가능
mysql.server start
한후
mysql -u root -p
로 접속하고 그냥 패스워드는 앤터
3. 패스워드 재설정
set password for 'root'@'localhost' = password('새로운 패스워드');
4. select host, user, authentication_string from user;
하면 패스워드가 암호화되어 들어가있는것확인할수있음!
1. 아파치 홈페이지 혹은 homebrew 이용하여 카프카 설치
2. 주키퍼 실행( 브로커들을 관리하고, 리더 브로커를 선출하는 역할)
- 이전에, localhost 가 listen 할수있도록 config 파일을 수정한다.
3. 카프카 서버 실행
4. 카프카 토픽생성
- 카프카의 장점:
다양한 데이터 소스가 있을수있다. 몽고 DB같은 형식, RDB형식등등.. 프로듀서도 다양하고 컨슈머도 다양하다. 프로듀서 입장에서 일일이 이 컨슈머의 타입에 맞추어서 convert 하기란 이만저만 복잡한것이 아니다. 일일이 컨버터를 구현하고 커스터마이징해야하므로
- 이때 카프카와 같은 미들웨어를 사용하면 . 보내는 쪽도 받는쪽도 커스터마이징 필요없이 카프카만 상대하면 된다. !!
다운로드
2. https://rabbitmq.com/install-windows.html#installer
서버 버전 다운로드. 윈도우 인스톨러 이용
3. 윈도우 환경변수 > 시스템 환경변수 > Path 에 각각 추가
4. ELRANG_HOME 시스템 환경변수 추가
5. 윈도우 커맨드 창 관리자 권한으로 실행 후
rabbitmq-plugins enable rabbitmq_management
명령어 실행으로 플러그인 설치
6. 서비스 에서 rabbitMQ설치확인
