본문 바로가기

분류 전체보기

강대명 <대용량 서버 구축을 위한 Memcached와 Redis> 후기 총 79페이지여서, 간단하게 읽기 좋은 책이다. 퇴근시간 때, 지하철에서 읽으니 술술 읽혔다 ㅎㅎ 처음에는 Memcached와 Redis의 차이, 캐시 사용 시 유의사항 같은 내용이 있을 거라 기대했다.그런데 웹 서비스를 확장할 때, 캐시를 사용해야하는 이유와 캐시가 동작되는 개념에 대해서 가볍게 써있단 느낌이 들었다. 최근 저자가 작성하신 "신입 사원을 위한 웹서비스 확장 전략"이라는 슬라이드 쉐어를 읽었었다. 그런데 책의 내용이 아래의 슬라이드 쉐어와 유사하단 느낌이 들었다. 웹서비스를 개발하는 초기 단계인 사람들이, 캐시를 왜 써야하는지, 뒷단에서 어떻게 돌아가는건지 이해하는 데에 도움이 되는 책인거 같다. webservice scaling for newbie from DaeMyung Kang
[beanstalk]eb cli으로 배포 시, 주의할점 1년간 빈스톡을 사용하면서, 배포할 때 주의해야했던 점들을 정리하고자 한다. 1. 빈스톡은 local git code를 배포한다. remote에 있는 git code를 땡겨다가 배포하는게 아니다. 그래서 배포하기 직전에, 최신 master code를 로컬로 땡겨온 다음에 배포해야한다. 2. 빈스톡에 있는 모든 인스턴스는 같은 애플리케이션 버전이여야한다. 터미널로 eb deploy 명령문을 실행해서 배포를 하던 도중, 실수를 한게 있어서 나도 모르게 command + c 버튼을 눌러서, 배포를 강제종료했던 적이 있다. 그런데 배포 강제 종료는 일을 더 꼬이게 만든다. 빈스톡에서는 모든 인스턴스의 버전이 같아야한다. 예를 들어 모든 인스턴스가 같은 버전으로 배포되기 전에, 배포를 중단시켜 버리면 최신 버전으..
[beanstalk]애플리케이션 버전 관리 Beanstalk Application Version 빈스톡은 배포 이력을 애플리케이션 버전으로 관리한다. 그래서 새로운 코드를 배포하면, 새로운 애플리케이션 버전이 생성된다. 애플리케이션 버전은 AWS Console 페이지에서 확인할 수 있다. 애플리케이션 버전으로 배포된 코드 이력을 확인할 수 있고, 롤백도 쉽게 할 수 있다. 나는 배포를 할 때, 애플리케이션의 Description을 추가해주고 있다. Description을 관리해줘야, 이 당시에 어떤 기능이 배포되었는지 이해하기가 쉽다. eb deploy -m "신규 기능 설명" 이런식으로 배포할 때, message 옵션을 넣어주면, 이 값이 application의 Description으로 추가된다. 참고 자료 AWS Elastic Beanstal..
[beanstalk]eb deploy timeout 옵션 현상 EB CLI 명령문으로 로컬에서 코드를 배포할 때, 시간이 오래걸리면 배포 로그가 터미널에 안보이는 현상이 발생한다. ( 이 때, timeout과 관련된 에러가 떠서 당황스러울 수 있다. 그런데 뒷단에서 배포가 잘 진행되고 있기 때문에, 당황할 필요는 없다. 그냥 배포 로그만 안보일 뿐이다. ) 방법 배포할 때, 아래처럼 timeout 옵션을 주는게 좋다. eb deploy -m "이슈번호-브랜치명" --timeout 100000
[Redis]라이브 환경에서 설정 변경하기 config set 명령문을 사용하면, 레디스 서버를 재가동하지 않아도, 환경 변수 값을 변경할 수 있다. redis.conf 파일에서 사용할 수 있는 모든 환경변수들을 config set 명령문으로 변경할 수 있다. 그래서 maxmemory, memory 관리 정책 등을 변경해줘야할 때, 이 명령문을 사용하면 redis를 재가동하지 않아도 된다. 예시 CONFIG SET MAXMEMORY 100000 참고 자료 https://redis.io/commands/config-set
[Redis]메모리 관리 방식 조사 배경TTL이 만기된 캐시키들이 삭제(evicted)되지 않는 현상을 발견하면서, 레디스에서 메모리를 관리하는 방법이 궁금해졌다 알게된 것* 레디스는 아래의 세가지 상황 때, 메모리를 정리한다. A. 만료된 키를 가져올 때 B. 샘플링한 데이터 중에 만료된 키가 있는 경우 C. 메모리 관리 정책을 설정했을 때, 논리적인 데이터 사용량이 maxmemory를 초과한 경우 => 실제 사용량으로 잡히는 rss를 기준으로 메모리를 정리하지 않는다. * 레디스는 jemalloc을 쓴다. * 용량이 큰 데이터를 자주 썼다가, 지우면 파편화가 발생하기 쉽다. 그리고 데이터의 크기 편차가 크면, 파편화가 생기기 쉽다. 실제 사용량보다 rss가 높게 나온다는 거다. 이 경우를 해결하려면, 장비를 이전하는게 낫다. 데뷰..
(읽을거리)엘라스틱 서치 쿼리 성능 최적화 읽을 거리 Optimizing Elasticsearch Searches https://www.elastic.co/blog/found-optimizing-elasticsearch-searches
[UDACITY]유다시티 볼 강의 찾기 Designing RESTful APIshttps://www.udacity.com/course/designing-restful-apis--ud388 Software Development Processhttps://www.udacity.com/course/software-development-process--ud805 Software Architecture & Designhttps://www.udacity.com/course/software-architecture-design--ud821 Applied Cryptographyhttps://www.udacity.com/course/applied-cryptography--cs387 Scalable Microservices with Kubernetes by Go..

티스토리툴바