잠보

fail2ban

무차별 비밀번호 대입을 통해 로그인을 시도하는 프로그램 및 해커들로부터 서버를 보호해준다.

똑같은 IP로 n번 로그인 실패를 했을 경우 정해진 시간동안 접속이 불가능하게 설정도 가능하다.

보통 SSH에 많이 적용하고 클라우드 상에서 fail2ban을 사용해서 접속을 막는 방법도 많이 사용한다.

왜 사용할까?

journalctl -f

해당 명령어를 통해 우리의 서버에 침투중인 상황을 실시간으로 볼 수 있다. 계속 로그가 올라오는게 침입 시도이다.

ctrl + c를 활용하여 빠져나올 수 있다.

설치 방법

sudo apt install fail2ban

설치와 동시에 시작되어 방어를 해준다.

설정 방법

sudo vi /etc/fail2ban/jail.local

이란 파일을 만든 뒤 내용을 작성하여 적용해 줘야한다.

형식 

[DEFAULT]

ignoreip=192.168.0.0/24

bantime=100000

maxretry=3

findtime=100000

[sshd]

enabled = true

port=22

filter=sshd

logpath=/var/log/auth.log

# (선택) 메일 알림 기능

destemail = 사용자 이메일 ex) user@naver.com

sender = fail2ban@my-server.com

mta = sendmail

action = %(action_mwl)s

[DEFAULT] : fail2ban에 지정할 모든 서비스에 대한 설정

ignoreip : 설정을 적용하지 않을 IP 리스트. 보통 내부에서의 접속들은 적용하지 않는다.

bantime : 이상 접속을 감지한 경우 접속을 불가능하게 할 초 단위.

maxretry : 허용 접속 가능한 횟수.

findtime : 이상 접속의 횟수를 총괄 낼 초 단위 시간

[sshd] : ssh 접속 서비스에 대한 설정.

enable : 동작 여부를 나타낸다

port : 감지할 포트. 여러 포트를 사용할 경우 ex) port=22,23,24

filter : 이상 동작이라고 판단할 문자열. 정규식 사용 가능.

logpath : 필터링 할 전체 문자열 파일.

형식 전체 해석 : logpath에서 filter 항목을 찾아 findtime 시간 동안 maxretry 횟수 만큼 접속을 시도한 IP를 batime 만큼 차단한다.

작성 끝난 후 service fail2ban restart

현재 차단 현황 보는 방법과 풀어주기

현황보기 : sudo fail2ban-client status sshd

차단 풀어주기 : sudo fail2ban-client set sshd unbanip ip주소

변경 이유는?

인터넷에 서버를 공개하게 되면 즉, 로컬 서버로 서비스를 내게 되면 수많은 악성 프로그램들이 자동으로  로그인을 시도한다. 그러면 서버 부하로 인해 자신의 프로그램을 돌리기 힘들거나 전기세도 많이 나갑니다.
그래서 외부에서 SSH로 서버에 접속 가능한 계정 정보가 노출되더라도 기본 포트(22번)보다 변경된 포트를 사용하는 그나마 보안상 좋기 때문이다.

변경 방법

1. sudo vi /etc/ssh/sshd_config
2. Port 22 부분은 원하는 포트로 변경 후 저장 ex) Port 2022
3. service sshd restart 로 ssh 재시작

만약 도메인을 구입하거나 클라우드 서비스를 이용하는게 아닌 로컬 서버인 경우 iptime 공유기 설정 화면에 들어간다

그 후 고급 설정 - NAT/라우터 관리 - 포트포워드 설정 항목에서 새 규칙을 추가한다.

ex)

규칙 이름 : 서버_ssh

내부 IP : 서버 주소(IP)

프로토콜 : TCP

외부 포트 : 새로 변경한 포트 번호 ~ 새로 변경한 포트 번호

내부 포트 : 새로 변경한 포트 번호 ~ 새로 변경한 포트 번호

변경 후 재접속 해봤는데 접속이 안될경우

ufw 방화벽으로 인해 해당 포트가 잠겨 있을 수 있으므로

ufw allow 새로 변경한 포트번호 ex) ufw allow 13212

하고 재접속을 시도하면 된다.

외부 접속 기록을 확인하는 방법

1. 접속 시도 기록 : cat /var/log/auth.log
2. 로그인 기록 : last

1. 네이버 검색 창에 IP 주소 검색 후 브라우저 창에 검색하여 IP time 로그인 창에 접속하기
2. 보통 초기 설정으로 아이디와 비밀번호가 admin, admin이기 때문에 입력 후 접속하기
3. 고급 설정 - 네트워크 관리 - DHCP 서버 설정에서 IP 주소 대여 범위가 예를 들어 192.168.123.2 ~ 192.168.123.233으로 되어 있다고 하면 앞의 IP 주소는 놔두고 뒤의 IP 주소를 192.168.123.199(199는 제 임의의 값입니다 마음대로 설정 가능)로 설정하여 200번 이후는 고정 IP설정이 필요한 기기들을 위해 DHCP 서버가 할당하지 못하도록 설정
4. NAS, 네트워크 프린터, 포트 포워딩 설정 등 고정 IP가 필요한 기기들을 200번 이후로 설정하면 된다
5. 설정이 필요한 기기의 IP 주소를 알아낸 후 (예로 리눅스 서버의 ifconfig를 통해 알아낸 IP 주소) DHCP 설정 아래 부분의 사용중인 IP 주소 정보에 해당하는 항목을 클릭 후 수동 주소 입력 부분란에 192.168.123.200 ~ 부터 할당하고 싶은 IP 주소를 입력하여 할당하면 된다. ex) 나의 로컬 서버는 192.168.123.200 를 입력하여 할당. 
6.  그 옆의 값들은 MAC 주소로 건들지 말 것. 그러면 설정이 필요한 기기가 재부팅 되어 원래라면 계속 IP가 자동 할당 되어 접속에 혼란을 만들었지만 해당 MAC 주소를 기반으로 아까 설정해 놓은 IP 주소(192.168.123.200)으로 고정 IP로 설정되어 접속 혼란을 막을 수 있다.
7. 5번에서 할당 후 재부팅하여 다시 기기의 IP 주소를 확인해보면 성공적으로 할당 되어 있는 것을 확인 가능

1. iTerm 실행
2. 메뉴의 Profiles - Open Profiles - Edit Profiles 클릭
3. Name에 호스트 이름 적기, Tags(필수 x) 호스트 특징 태그 달기, Title은 Job으로 고정
4. Command 항목에서 Login Shell을 Command로 변경 후 ssh user_name@ip address 형식으로 적어준 후 닫기(자동 저장)
5. 그리고 다시 메뉴의 Window - Password Manager 클릭
6. + 버튼 클릭 후 클릭 하여 Account Name(호스트 이름 추천), User name(유저명), Edit Password를 눌러 Password 부분에    비밀번호 입력
7. 마지막으로 트리거 설정을 위해 Profiles - Open Profiles -호스트 클릭 후 Edit Profiles 클릭
8. General, Colors, Text ... Advances에서 Advances 클릭 후 Trigeers에서 Eddit 클릭
9. + 버튼 클릭 후 클릭하여 Regular Expression에 password로 적고 Action은 Open Password Manager로 변경 Parameters에는 아까 비밀번호 Account Name에 설정 해두었던 것을 클릭 후 마지막으로 Instant 체크 후 Close.
10. iTerm을 종료 후 다시 키면 자동으로 ssh 접속이 실행되며 창이 나오며 Password Manager에서 비밀번호를 선택 후 Enter Password를 눌러 로그인을 손쉽게 가능하게 한다.

안드로이드 (android)

1.   마스터 계정 : 애플과 비슷한 이유. 앱을 전체적으로 확일할 수 있는 마스터 계정. 또는 기능들을 볼 수 있는 각각의 계정. (사전출시보고서에 입력)

2.   신고 기능 : 커뮤니티 앱일 경우 글 신고, 사용자 신고 기능 필요.

3.   이용약관 : 이용약관 및 사용자 정책에 불쾌감을 주는 콘텐츠와 행동을 정의.

4.   디지털 콘텐츠인데 인앱 결제 대신 PG결제를 붙인 경우 : 게임, 소개팅, 자체 콘텐츠 서비스 등의 경우 개별 콘텐츠 마다 원가가 들어가지 않기 때문에 3-%의 인앱 결제 수수료를 받아들일 수 있다. 만약 수수료 부담이 클 경우 비지니스 모델과 상품 원가에 대해 적극적으로 소명해서 인앱 결제 대상 제외를 요청하거나 결제 페이지를 앱 밖으로 꺼내야함.

5.   회원 가입 시 생년월일, 성별 등의 부가정보를 필수로 요구하는 경우 : 이 정보가 어떻게 쓰이는지 소명해야함. 안되면 선택입력.

6.   스토어 실적 및 순위가 표시된 이미지 또는 텍스트 사용할 경우.

7.   가격과 홍보 정보가 표시된 이미지 또는 텍스를 사용할 경우.

8.   소셜로그인만 존재할 시. 앱 내에서 자체 회원가입 필요. 로그인 안하고도 기능 사용가능하게 만드는 우회 가능.

아이폰 (ios)

1.   앱 완성도 : 작동이 잘 안되거나 빈 페이지가 있을 경우

2.   ATT 권한 : 앱스토어 등록 시 개인정보 수집 설정을 했을 경우 유저에게 관련 권한 팝업을 받거나 개인정보를 수집하지 않는 것으로 앱스토어 등록 내용을 수정해야한다.

3.   애플 로그인 : 애플을 영어로 써야하며, 애플 + 다른 단어 합성어 불가. (만약 아이폰 배포 시 애플 로그인이 없고 달느 구글 로그인이나, 다른 SNS로그인만 있을 경우에도 리젝사유)

4.   마스터 계정 : 로그인이 필요한 앱일 경우 모든 기능을 살펴볼 수 있는 마스터 계정 또는 분리될 경우 각각 기능 사용 가능한 테스트 계정 제공.

5.   권한 설명: 사진 및 카메라에 접근시에 시스템 팝업의 권한에 대한 설명 부족.

ð 계정 인증 및 커뮤니티 사진 등록과 더 나은 사용자 경험을 제공하기 위해 필요합니다. 설정에서 이를 구성할 수 있습니다. 자세하게 설명.

6.   신고 기능 : 커뮤니티는 사용자에게 불쾌감을 줄 수 있으므로 신고를 위한 기능이 있어야함. (글 신고, 사용자 신고 두개 다)

7.   디지털 콘텐츠인데 인앱 결제 대신 PG결제를 붙인 경우 : 게임, 소개팅, 자체 콘텐츠 서비스 등의 경우 개별 콘텐츠 마다 원가가 들어가지 않기 때문에 3-%의 인앱 결제 수수료를 받아들일 수 있다. 만약 수수료 부담이 클 경우 비지니스 모델과 상품 원가에 대해 적극적으로 소명해서 인앱 결제 대상 제외를 요청하거나 결제 페이지를 앱 밖으로 꺼내야함.

8.   회원 가입 시 생년월일, 성별 등의 부가정보를 필수로 요구하는 경우 : 이 정보가 어떻게 쓰이는지 소명해야함. 안되면 선택입력.

9.   푸시 알림 강요 : 푸시 알림은 사용자가 수신을 취소 가능하게 제공해야한다.

10.리워드 증정 금지 : 친구 초대 또는 리뷰 작성 시 보상을 증정하는 리워드 금지.

11.웹뷰앱 : 웹뷰는 모바일 기능이 앱으로서 기능을 하는지 여부를 묻는다. 손쉬운 통과를 위해서 푸시 알림 넣기, 카메라 기능 넣기 등이 있다.

12.소스상 사용하지 않는 이미지가 있을 경우.

13.국내 본인인증 서비스등을 사용할 경우 : 신규 사용자 등록 프로세스 비디오 등을 만들어놓는게 좋다.

14.음란 컨텐츠에 대한 차단 및 검수 여부 : 해당 컨텐츠에 대한 필터링 및 검수 프로세스를 요청할 수 있음.

15.타사 플랫폼 언급 : 애플 플랫폼 외의 안드로이드, 구글플레이 등과 관련된 문구나 이미지가 포함되면 거절될 수 있다. 안드로이드가 탑재된 기기의 이미지 사용도 위험.

16. 저작권/상표권 침해 : 허가받지 않은 타사의 상표를 콘텐츠에 포함시키거나 저작권을 위반한 콘텐츠가 포함될 경우 등록 거절 사유가 될 수 있다.

17. 소셜로그인만 존재할 시. 앱 내에서 자체 회원가입 필요. 로그인 안하고도 기능 사용가능하게 만드는 우회 가능.

1. AWS 로그인 
2. 상단 메뉴바의 제품에 커서 이동 
3. 보안, 자격 증명 및 규정 준수 커서 이동 
4. AWS Identity and Access Management(IAM) 클릭 후 시작하기 
5. MFA 추가 -> 가상 MFA 디바이스 선택 후 계속 
6. 호환 애플리케이션 목록 클릭 후 원하는 어플리케이션 다운받기(필자는 Microsoft Authenticator 다운받음 추천아님)
7. Microsoft Authenticator 앱바의 점이 세개 있는 메뉴 클릭 후 계정 추가 
8. 회사 또는 학교 계정 클릭
9. QR코드 스캔 누른 후 화면의 QR코드 스캔하면 aws 계정이 앱에 자동으로 추가 된다.
10. 그 후 해당 아마존 웹 서비스 계정을 클릭하면 일회성 암호 코드가 나오는데 그 코드를 MFA 코드 1과 2에 추가하면 된다.(한번 추가하면 30초 기다리고 그 다음 나오는 번호를 2번째에 기입)
11. 그 후 로그인 할때마다 아이디와 비밀번호를 입력하면 키 인증 페이지가 나오며 앱을 켜서 해당 아마존 웹 서비스 계정 클릭 후 모바일 화면에 나오는 인증 코드를 입력하면 된다.

이렇게 간단하게 2단계 보안을 걸어 발생할 수 있는 대규모 금액 청구를 조금이나 막을 수 있기를 바란다!

엘라스틱 서치란?

엘라스틱 서치란 아파치 루씬기반의 오픈소스 실시간 분산 검색 엔진이다.

즉, 텍스트, 숫자, 위치 기반 정보, 정형 및 비정형 데이터 등 모든 유형의 데이터를 위한 무료 검색 및 분석 엔진이다.

서버 확장이 매우 편리하며, 실시간 검색 서비스 지원, 분산 및 병렬 처리, 멀티테넌시 기능을 제공하고 다양한 플러그인 지원, 클러스터로 

구성 가능하여 검색 대상의 용량이 증가했을 때 대응하기가 매우 수월하다.

엘라스틱 서치는 검색을 위해 단독으로 사용되기도 하며 ELK 스택으로 사용되기도 한다.

ELK 스택 구성

1. Logstash : 다양한 소스(DB, csv 파일 등)의 로그 또는 트랜잭션 데이터를 수집, 집계, 파싱하여 ElasticSearch로 전달.

2. ElasticSearch : Logstash로부터 받은 데이터를 검색 및 집계하여 필요한 정보를 획득.

3. Kibana : ElasticSearch의 빠른 검색을 통해 데이터를 시각화 및 모니터링.

특징

1. 오픈소스 
2. 분산 시스템, 확장성 : 엘라스틱 서치는 네트워크상에 있는 노드들과 바인딩 되어있어 클러스터를 구성할 수 있다. 샤드를 기반으로 색인 데이터를 관리하고 운영중에도 노드가 추가되면 샤드를 새로운 노드로 적절히 재분배하여 유지하기 때문에 쉽게 스케일 아웃(확장)이 가능하다.
3. 고가용성 : 샤드는 기본적으로 하나 이상의 복제본을 중복되지 않는 서로 다른 노드에 배치한다. 그러므로 시스템 운영 중 어느 한 노드가 다운되더라도 데이터 유실 없이 동일한 검색 결과를 얻을 수 있다.
4. 실시간 검색 : 실시간에 가까운 속도로 색인된 데이터의 검색과 분석이 가능하다. 클러서가 실행되는 동안 계속해서 데이터가 입력된다(즉, 색인 과정)
5. JSON 문서 기반 : 질의에 사용되는 쿼리문과 결과 모두 JSON이라 직관적이다.
6. RESTful API : REST API를 기본을 지원하며 모든 데이터의 연산 과정을 HTTP 프로토콜 메소드를 통해 처리한다.

단점

1. 진입 장벽이 있다.
2. Document 간의 조인을 수행할 수 없다. (두번 쿼리로 해결 가능)
3. 트랜잭션 및 롤백이 제공되지 않는다.
4. 실시간 처리가 불가능 (색인되 데이터가 1초 뒤에나 검색이 가능)

RDBMS와 비교

※ 클러스터 : 엘라스틱 서치에서 가장 큰 시스템 단위를 의미하며, 최소 하나 이상의 노드로 이루어진 노드의 집합. 서로 다른 클러스터는 서로 접근할 수 없는 독립적인 시스템으로 유지되며, 여러 대의 서버가 하나의 클러스터를 구성할 수 있고 한 서버에 여러 개의 클러스터가 존재할 수 있다.

※ 노드 : 클러스터에 포함된 단일 서버로서 데이터를 저장하고 클러스터의 색인화 및 검색 기능에 참여한다. 노드는 역할에 따라 Master-eligible, Data, Ingest, Coordinating 노드로 구분할 수 있다.

(1) Master-eligible 노드 : 클러스터를 제어하는 마스터로 선택할 수 있는 노드. 역할로는 인덱스 생성 및 삭제, 클러스터 노드의 추적 및 관리, 데이터 입력 시 할당한 샤드 선택이 있다.

(2) Data 노드 : 데이터가 저장되는 노드이며 데이터가 분산 저장되는 물리적 공간인 샤드가 배치되는 노드이다. 많은 리소스(CPU, 메모리 등)이 필요하며 마스터 노드와는 분리해야한다. 모니터링 작업도 필요.

(3) Ingest 노드 : 데이터를 변환하는 등 사전 처리 파이프라인을 실행하는 역할.

(4) Coordinating 노드 : 사용자의 요청을 받고 라운드 로빈 방식으로 분산을 하는 노드로 클러스터에 관련된 것은 마스터 노드로 넘기고 데이터와 관련된 것은 데이터 노드로 놈긴다. 로드밸런싱 역할.

※ 샤드 : 인덱스 내부에는 색인된 데이터를이 존재하는데 이 데이터들은 하나로 뭉쳐서 존재하지 않고 물리적 공간에 여러 부분으로 나뉘어 존재한다. 이러한 부분을 샤드라고 한다. 스케일 아웃(확장)을 위해 하나의 인덱스를 여러 샤드로 나누었다고 생각하면 된다.

샤드는 프라이머리 샤드와 레플리카 샤드로 나뉜다.

(1) 프라이머리 샤드 : 데이터의 원본. 엘라스틱 서치에서 데이터 업데이트 요청을 날리면 프라이머리 샤드에 요청하게 되고 해당 내용은 레플리카 샤드에 복제된다. 검색 성능 향상을 위해 클러스터의 샤드 개수를 조정하기도 한다.

(2) 레플리카 샤드 : 프라이머리 샤드의 복제본이다. 기존 원본 데이터가 위험해졌을 때 그 대신 사용하면서 장애를 극복한느 역할을 수행.

프라이머리 샤드와는 다른 노드에 배정.

프록시 서버란?

프록시 서버란 클라이언트와 서버 사이에 위치하여 중개인처럼 동작하는 서버이다.

프록시 서버 사용 예시

• 어린이 필터 : 성인 콘텐츠 차단. 부적절한 사이트의 접근을 거부할 수 있다.
• 보안 방화벽 
• 웹 캐시 : 자주 사용하는 콘텐츠를 저장해놨던 요청 시 빠르게 응답할 수 있다. CDN 서버가 대표적.
• 익명화 프록시 : HTTP 메세지에서 신원을 식별할 수 있는 특성들(IP, From header, Referer header, 쿠키 등)을 제거함으로써 개인 정보 보호와 익명성 보장에 기여할 수 있다.
• 트랜스 코더 : 콘텐츠를 클라이언트에게 전달하기 전에 포맷을 수정할 수 있다.
• 콘텐츠 라우터 : 트래픽 조건과 콘텐츠의 종류에 따라 요청을 특정 웹 서버로 유도하는 라우터로 동작 가능하다. CDN 서버가 대표적.
• 대리 프록시 : 리버스 프록시라고 불리며 웹 서버나 다른 프록시 서버와 요청하게 되는 서버이며 로드 밸런싱과 웹 서버의 보안을 위해 사용된다.
• 문서 접근 제어자 : 많은 웹 서버들과 웹 리소스에 대한 단일한 접근 제어 전략을 구현하고 감사 추적을 할 수 있다.

프록시 서버의 종류

1. Forward Proxy

일반적으로 프록시라고 말하면 Forward Proxy를 뜻한다.

클라이언트 요청 시 바로 서버로 가는게 아닌 프록시 서버를 거쳐서 요청된다. 이 경우 서버는 클라이언트의 IP를 받는게 아닌 프록시 서버의 IP를 받는다. 즉, 서버에게 클라이언트가 누구인지를 감추는 프록시.

특징과 역할

(1) Cache : 동일한 요청이 여러 번 들어올 경우 프록시 서버에 캐싱된 내용을 전달해줌으로써 성능을 향상시킬 수 있다.

(2) IP 우회 : 서버에서 클라이언트의 IP를 받는게 아닌 프록시 서버의 IP를 받게 되어 클라이언트의 정보를 숨길 수 있다.

(3) 제한 : 보안이 중요한 사내망에서 정해진 사이트에만 연결할 수 있도록 설정하는 등의 환경을 제한할 수 있다.

2. Reverse Proxy

한 대 이상의 서버로부터 자원을 추출해주는 프록시 서버이다. 그런 다음 이런 자원들이 웹 서버 자체에서 나온 것처럼 클라이언트에게 반환시켜준다. 즉, Forward Proxy와는 달리 클라이언트가 본 서버를 호출하는게 아니라 프록시 서버를 통해 호출하기 때문에 본 서버를 감추는 역할을 한다. 또한 하나의 IP로 다수의 웹 서비스를 수행할 수 있다.

특징과 역할

(1) 로드 밸런싱 : Reverse Proxy 뒤에 여러 개의 WAS를 사용함으로써 사용자 요청을 분산 처리할 수 있다.

(2) 본 서버로의 직접적인 접근 차단 : 클라이언트가 셀지 본 서버를 직접 호출하는게 아닌 Proxy Server를 통해 호출하므로 보안이 좋다.

웹 서버란?

웹 서버란 클라이언트로부터 HTTP 프로토콜로 요청을 받아 HTML 문서 등과 같은 정적 웹 페이지를 응답해주는 소프트웨어.

하드웨어 측면 : 컴포넌트 파일(html, images, css, javascript 등)들을 저장하는 컴퓨터. 도메인 이름을 통해 접속 가능.

소프트웨어 측면 : 웹 사용자가 어떻게 호스트 파일들에 접근하는지를 관리.

흔히 웹 서버라고 부르면 정적 웹 서버를 생각하면 되고 동적 웹 서버는 WAS를 생각하면 될 듯 하다.

웹 서버의 분류

1. 정적 웹 서버 : 서버가 클라이언트가 요청한 파일을 가지고 있어 그래도 전송해주는 것.
2. 동적 웹 서버 : 서버가 클라이언트가 요청한 것을 기반으로 컨텐츠를 데이터베이스로부터 생성하거나 처리하여 제공하는 것.

웹 서버의 종류

1. Apache : 오래전부터 사용되어 온 웹 서버. 멀티 프로세스 모듈 방식 처리. 다양하고 검증된 기능을 사용하고 하는 경우.
2. Nginx : 이벤트 처리. Apache의 점유율을 따라잡고 있다. 성능과 가벼움을 중요시하는 서비스에 많이 사용.
3. IIS : 윈도우 서버

WAS란?

WAS란 일종의 미들웨어로 동적 서버 콘텐츠를 수행하는 서버이다. 

예를 들어 웹 서버(Nginx)와 웹 애플리케이션(Django)간의 연결을 중계한다.

대표적으로 Tomcat, Jetty, Undertow 등이 있다.

여기서는 의문점으로는 Apache나 Nginx도 동적 처리가 가능하며 Tomcat 등 WAS들도 정적 처리를 할 수 있는데 왜 분리할까? 라는

의문이 있을 수 있는데 옛날에는 각각 처리 속도가 달라서 의미가 있었지만 지금은 빨라져서 의미가 없으며 그래서 이유로는 

Apache나 Nginx는 reverse proxy 기능을 사용하여 서버의 IP를 숨기는 기능을 사용할 수 있고 다양한 보안 기능들을 제공하며 또한

로드밸런싱을 제공하여 분산 처리를 가능하게 여러 개의 WAS에 일 분담을 시킬 수 있다. 그리고 캐싱을 사용하여 캐시 안에 있는 데이터의 

경우 빠르게 제공하는 기능까지 제공하여 웹 서버와 WAS는 기능적인 측면으로 분리하며 보안 과정도 생각한다고 보면 된다.

레디스란?

레디스(REmote Dictionary Server)란 Key와 Value를 가진 NoSQL DBMS이다.

In-memory 데이터 저장소이며, 보통 DB, 캐시, 메시지 브로커 등의 용도로 사용하는 NoSQL DBMS.

초당 10만 ~ 15만건의 명령을 수행 가능하며, 파이프링을 통해 리눅스 시스템에서 초당 100만건의 요청도 수행이 가능하다.

레디스의 특징

• In-memory 데이터 구조 : 디스크가 아닌 메모리 기반으로 한 데이터 구조 안에 데이터를 저장한다.
• 디스크에 접근할 필요를 없애 검색 시간으로 인한 지연을 방지하며 CPU 명령을 적게 사용하는 좀 더 간단한 알고리즘으로 접근 가능하다.
• Pub/Sub을 사용하여 메시징 시스템에 유용하며 불필요한 데이터를 채우지 않게하는데 유용.
• 캐시를 사용하여 속도가 빠르다.
• 싱글 스레드 기반 명령 수행 : Atomic operations을 보장하며 동시성을 지원한다.
• 다양한 데이터 타입 지원 : strings, hashes, lists, sets, sorted sets, bitmaps, hyperloglogs, geospatitial indexes, streams 등을 지원하며 lists의 경우 일반적인 RDB와 비교하면 10배 빠른 속도를 지원.
• Master-Slave 구성 가능 : Master-Slave와 같은 Redis Replication뿐만 아닌 Redis cluster를 이용한 분산처리, Redis Sentinel을 이용한 장애복구 시스템도 제공한다.