전체 글 (86) 썸네일형 리스트형 AWS CM과 로드 밸런스로 HTTPS로 변환하기 HTTPS를 변환하는 방법에는 크게 1) 웹서버를 사용하는 방식과 2) AWS를 사용하는 방법이 있다. 두 개의 공통점 모두 SSL/TLS 인증서가 필요하다. 이 포스팅에서는 AWS를 사용하여 HTTPS로 변환하는 방법을 소개하고자 한다. 참고로 웹서버(NGINX) HTTPS 변환은 Certbot으로 SSL 발급, Nginx로 HTTPS로 리다이렉트 nginx HTTP 로 들어오면 강제로 HTTPS 로 전환하도록 설정하기(force redirect to SSL) www.lesstif.com 위의 두 블로그 글을 참고하길 바란다. 1. 도메인 생성 SSL을 발급하려면 먼저 도메인을 생성해야 한다. 필자는 대표적인 도메인 사이트 가비아를 사용하였다. (꼭 가비아가 아니라 무료 도메인 사이트를 사용해도 상관이.. Redis 성능 튜닝 1. Eviction 정책 메모리가 한계에 도달할 때 어떤 조치가 일어날지 결정하는 것을 뜻한다. 처음부터 메모리가 부족한 상황을 많들지 않는 게 중요하고, 캐시로 사용할 때는 적절한 eviction policy가 사용된다. 1.1 Redis의 메모리 관리 maxmemory 100mb Memory의 사용 한도를 설정한다. 지정하지 않으면 32bit에서는 3GB, 64bit에서는 0(무제한)으로 설정된다. 32bit OS에서는 사용하는 게 제한됐기 때문에 3GB밖에 못 쓴다. maxmemory-policy noeviction maxmemory일 경우에 eviction 정책을 설정한다. 1.2 maxmemory-policy 옵션 Redis는 메모리를 어떻게 다루는지가 정말 중요하다. 이에 관한 옵션이 있다... Redis 클러스터 1. 확장성과 분산 확장성은 서비스가 커질 때 대응할 수 있는 능력을 뜻한다. 주로 규모에 대한 확장성을 의미한다. 방식은 수직 확장(Scale-up)과 수평 확장(Scale-out)이 있다. 1.1 수직 확장(Scale-up) 단일 하드웨어의 리소스(CPU, 메모리, 네트워크 어댑터 등)를 추가하거나, 기존 하드웨어를 고성능으로 교체하는 것을 의미한다. 1.2 수평 확장(Scale-out) 서버를 여러 개를 둬서 작업을 분산한다. 이론적으로 무한대로 확장이 가능하다. 그러나 수직 확장에 비해 매우 까다롭다. 수평 확장을 하면 아래와 같은 개발 복잡성이 많아진다. 부분 장애 네트워크 실패 데이터 동기화 로드밸런싱 개발 및 관리의 복잡성 그럼에도 서비스 복잡도와 규모의 증가로 분산은 피할 수 없기에 많이 .. Redis 백업과 장애 복구 1. RDB 백업 특정 시점의 스냅샷으로 데이터를 복구한다. 재시작 시 RDB 파일이 있으면 복구한다. 장점으로는 작은 파일 사이즈로 버전 관리를 할 수 있어서 백업 관리가 용이하고, fork를 통해 백업해서 child process가 서비스 중인 프로세스는 성능에 영향이 없다. 단점으로는 틈이 있을 수 있어서 데이터 유실이 있을 수가 있고, fork를 사용해서 시간이 오래 걸려 CPU와 메모리 자원을 많이 소모한다. 그래서 데이터 무결성이나 정합성 요구가 크지 않을 때 사용한다. 1.1 RDB 설정 설정 파일이 없어도 기본값으로 RDB가 활성화됐다. 설정 파일을 만들려면 템플릿을 받아 사용해야 한다. 저장 주기 설정(ex: 60초마다 5개 이상 변경) save 60 5 스냅샷 저장 파일 이름 .dump.. API Gateway 개념 1. 나오게 된 배경 고객 서비스를 위한 다양한 클라이언트가 나오기 시작했고, 서비스를 위해 필요한 다양한 정보들을 요구하기 시작했다. 이에 MSA가 유행하기 시작한다. 여기서 MSA란 마이크로하게 나눈 독립적인 서비스를 의미한다. 하지만 문제점이 발생한다. 클라이언트와 MSA간의 강한 결합이 있고, 너무 많은 통신을 요구하게 된다. 개별 서비스의 엣지 기능 제공 및 구현(보안, 로깅, 모니터링, 캐싱 등)이 어려워졌다. 무엇보다 결합이 크면 변경이 어렵기에 새로운 무언가가 필요했다. 이를 해결하기 위해 API Gateway 패턴이 등장한다. 2. API Gateway란? 크게 두 가지 기능을 제공한다. 첫 번째는 단일접점으로 마이크로 서비스를 모아서 단일접점을 제공한다. 두 번째는 캡슐화로 클라이언트 .. Pub/Sub 패턴으로 채팅방 구현 1. Pub/Sub 패턴 메시징 모델 중 하나로 발행(Publish)과 구독(Subscribe) 역할을 개념화 한 패턴이다. 발행자와 구독자는 서로에 관한 정보 없이 특정 토픽을 매개로 송수신한다. 2. 메시징 미들웨어와 Redis의 Pub/Sub 차이점 보통 kafaka, RabbitMQ, ActiveMQ 같은 메시징 미들웨어의 장점은 낮은 결합도로 직접 서로 의존치 않고 미들웨어에 의존한다. 두 번째는 탄력성으로 느슨한 연결로 인해 장애가 일부 생겨도 영향이 최소화된다. 세 번째는 통신을 비동기 처리해서 API 호출을 제거하여 처리 시간을 감소한다. 반면 Redis의 Pub/Sub은 메시지가 큐에 저장하지 않고, kafaka의 컨슈머 그룹 같은 분산 처리 개념이 없다. 또한 메시지 발행 시 push .. Sorted Sets으로 리더보드 구현 1. 리더보드(Leaderboard)의 특성 게임이나 경쟁에서 상위 참가자의 랭킹과 점수를 보여준다. 그룹 상위 랭킹 혹은 특정 대상의 순위를 나타낸다. 최다 구매 상품, 리뷰 순위 등의 순위로 나타낼 수 있는 다양한 부분에서 응용이 가능하다. 구매 상품의 뷰, 댓글 등을 계산할 수 있다. 2. API 관점에서 리더보드의 동작 점수 생성 및 업데이트를 구할 때 SetScore로 점수를 구하거나, 상위 랭크 조회 시 범위 기반으로 getRange를 사용하던가, 아니면 특정 대상 순위 조회를 할 때 값 기반 조회로 getRank를 사용한다. 리더보드의 핵심은 빠른 업데이트와 빠른 조회이다. 관계형 DB 등의 레코드 구조를 사용했을 때 데이터 구조와 성능에 문제가 발생한다. 업데이트 시 한 행에만 접근하기에 .. Redis로 캐시 레이어 구현 1. 캐싱의 원리와 목적 캐시는 성능 향상을 위해 값을 복사한 임시 기억 장치이다. 위로 갈수록 속도가 빠르며, 가격이 비싸다. 캐시에 복사본을 저장하고 읽음으로써 속도가 느린 장치의 접근 횟수를 줄인다. Cache의 데이터는 원본이 아니라 언제든 사라질 수 있다. 이에 데이터 일관성 문제를 해결해야 한다. 캐시는 어디든 적용이 가능하다. 네트워크 지연 속도를 감소하거나, 서버 리소스 사용 감소, 병목현상을 감소할 수 있다. DB는 무한정 늘어날 수 없어서 병목이 된다. 그런데 캐시는 이런 병목 현상을 줄일 수가 있다. 캐싱 개념들은 아래와 같다. 캐시 적중(Cache Hit): 캐시에 접근해 데이터를 발견한다. 캐시 미스(Cache miss): 캐시에 접근했으나 데이터를 발견 못 함. 캐시 삭제 정책(.. 이전 1 2 3 4 ··· 11 다음
