본문 바로가기

분류 전체보기

 (345)
Bootstrap - 부팅 설정의 자동 수집 ㅁ 풀어야 할 문제 서버 이미지에서 서버를 만드는 방법, 즉 Stamp패턴을 적용할 때 어느 정도의 빈도로 서버 이미지를 가지고 올 것인가는 운영 효율에 있어서 자주 거론되는 문제다 Stamp 패턴에서는 미들웨어부터 애플리케이션까지 전부 설정이 끝난 상태에서 서버를 가동하면 그대로 사용이 가능한 서버 이미지를 만들 수 있다. 이런 때 가상 서버의 가동은 굉장히 빠르지만, 미들웨어 중 하나를 업데이트해야 하거나 애플리케이션 설정을 바꿔야 할 때는 서버 이미지를 다시 만들어야 한다. ㅁ 해결/패턴 클라우드에서는 쉽게 서버 이미지를 만들 수 있으며, 가동할 때 파라미터를 설정할 수 있다. 이 기능을 사용하여 서버 구성에 필요한 파라미터를 전달하여 서버를 가동할 때 필요한 설정을 서버가 전달받아 설치, 가동, ..
Scheduled Autoscaling 패턴 - 배치 처리 서버의 자동 가동/정지 ㅁ 풀어야 할 문제 정해진 시간에 실행되는 배치 처리는 많은 시스템에서 이루어지고 있고, 그 방법으로는 항상 가동 중인 서버 위에 스케줄러(예를 들어 UNIX의 cron)를 사용하는 경우가 많다. 그러나 실제 배치 처리를 하는 시간은 짧고, 그 시간 이외의 서버 자원은 낭비가 되며 비용 효율이 낮아진다. 이런 용도의 일괄 처리 서버 자원을 얼마나 효율적으로 사용하는지가 항상 문제였다. ㅁ 해결/패턴 기존에는 정해진 시간에 실행되는 배치 처리 서버에도 당연히 항상 가동 중인 서버를 할당해야 했다. 그리고 다른 기능(처리)도 부여하여 서버 자원의 이용 효율을 높이려고 노력했다. 클라우드에는 필요할 때만 가상 서버를 이용할 수 있어 일괄 처리를 하는 경우에만 가상 서버를 가동할 수 있게 되었다. 정해진 시간에..
Job Observer - 작업 감시와 서버 추가 삭제 ㅁ 풀어야 할 문제 배치 처리 부하분산으로 작업 요청을 큐로 관리하고 큐의 작업 요청을 여러 대의 배치 서버가 병렬로 처리하는 방법이 있다. 그러나 준비한 배치 서버 수는 피크 수준에 맞춘 수이기 때문에 피크 외 시간대에는 배치 서버의 자원이 남아 비용 효율이 낮아진다. 또 예상 이외로 부하가 배치 시스템에 몰릴 경우 응답 성능이 떨어진다. ㅁ 해결/패턴 기존에는 서버 자원을 동적으로 추가하고 삭제할 수 없었기 때문에 피크나 허용 비용 범위 내에서 배치 서버를 준비했다. 비용 효율이 좋지 않아 예상하지 못한 부하에 대응할 수 없었다. 클라우드에서는 부하를 감시하고 가상 서버를 자동으로 줄이고 늘리는 구조를 제공하고 있다. 이 구조를 이용하면 부하에 따라 서버를 추가하고 삭제할 수 있게 되며, 비용 효율이..
Priority Queue - 작업 우선 순위 변경 ㅁ 풀어야 할 문제 많은 일괄 작업을 처리해야 하고 거기에 작업의 우선순위가 있는 경우를 생각할 수 있다. 예를 들어, 프레젠테이션 파일을 웹브라우저로 업로드하여 공개할 수 있는 서비스로, 무료 사용자와 회원 사용자의 서비스 레벨(공개까지 시간)이 다른 경우가 이 경우에 해당된다. 사용자가 프레젠테이션 파일을 업로드하면 시스템에서 공개하기 위해 변환 처리 등을 일괄 작업으로 하고, 변환 후 파일을 공개한다. 그 일괄 처리를 회원 종류별로 어떻게 우선 순위를 정할지가 문제다. ㅁ 해결/패턴 일괄 작업의 관리에는 큐를 사용할 수 있다. 큐를 우선순위 수만큼 준비하면 된다. 작업 요청을 큐로 관리하고, 큐의 작업 요청을 일괄 작업으로 처리한다. 클라우드에는 높은 신뢰성을 가진 큐 서비스가 제공되고 있고, 그것..
Queuing Chain - 큐를 통한 시스템간의 낮은 의존도 구성 ㅁ 풀어야 할 문제 여러 시스템에서 처리를 연계하여 순차적 처리(예를 들어, 이미지 처리의 경우에 이미지 업로드, 저장, 인코딩, 썸네일 작성 등의 순차 작업)를 할 때 시스템들이 밀접하게 결합되어 있다면, 성능 측면에서 병목 현상이 발생할 수 있다. 또, 장애 시 복구 작업이 복잡해 진다. 가능하면 시스템 간의 의존도를 낮게 하는 것이 성능이나 유지 및 보수 측면에서 바람직하다. ㅁ 해결/패턴 시스템 간의 의존도를 낮추는 하나의 방법은 시스템들을 큐로 연결하여 작업 전달을 큐 안에 있는 메시지를 통해 송수신하는 것이다. 이렇게 하면 비동기로 시스템 연계가 가능하다. 이 방법의 경우 메시지를 받고 처리하는 가상 서버 수를 늘려 병렬 처리를 할 수 있기 때문에 쉽게 병목 현상을 없앨 수 있다. 또, 가상 ..
Sharding Write - 쓰기 효율화 ㅁ 풀어야 할 문제 RDBMS의 읽기에 대한 고속화는 매우 중요하고 난이도가 높은 문제다. 스케일 업으로 낼 수 있는 이상의 성능을 내는 것은 당연히 여러 대의 데이터베이스 서버를 이용하면 되지만, 어떻게 해야 하는지는 언제나 고민이다. ㅁ 해결/패턴 여러 대의 데이터베이스 서버에 쓰기 성능을 높이는 방법으로 [샤딩]이 있다. 기본적으로 같은 구조의 데이터베이스를 만들어 테이블의 컬럼을 키로 사용해 분할하여 쓰기 처리를 분산한다. ㅁ 구현 AWS의 RDBMS 서비스인 [RDS]를 샤딩 백엔드 데이터베이스로 이용하면 가용성과 운영 효율을 높일 수 있다. - Spider 스토리지 엔진을 가지고 있는 MySQL 서버 등의 샤딩 소프트웨어를 EC2에 설치한다. - 여러 대의 RDS를 준비하여 샤딩 백엔드 데이터..
Inmemory DB Cache - 자주 사용되는 데이터 캐시화 ㅁ 풀어야 할 문제 데이터베이스 부하의 대부분은 읽기에 관한 것인 경우가 많다. 그 때문에 데이터베이스의 읽기 성능을 개선하면 시스템 전체의 성능 향상과 연결된다. ㅁ 해결/패턴 데이터베이스에서 읽기 성능을 높이는 방법으로 읽기에 자주 사용되는 데이터를 메모리에 캐시하는 것이 일반적이다. 한번 사용한 데이터를 캐시에 올려두고 다음에 사용할 때(디스크가 아닌)메모리에서 읽기 처리를 끝내는 방법이다. 캐시하는 데이터의 전형적인 예로, 데이터베이스 처리에 있어서 시간이 걸리는 쿼리 결과나 복잡한 계산 결과 등을 들 수 있다. ㅁ 구현 AWS의 ElastiCache는 메모리 캐시 서비스다 이 서비스는 장애 시의 자동 복구 기능 등도 가지고 있다. - 메모리 캐시를 준비한다. ElastiCache를 사용해도 되며..
Read Replica - 읽기 전용 레플리카를 통한 부하분산 ㅁ 풀어야 할 문제 데이터베이스의 액세스 빈도가 높아 DB 서버의 자원이 줄어들 때 서버의 사양을 높이는(즉, 스케일 업) 경우가 많다. 스케일 업이 힘들 때는 DB 서버를 수평 분산하는 스케일 아웃이 이루어지나, 일반적으로 어려워한다. 일반적으로 데이터베이스의 쓰기보다 읽기가 비교적 많기 때문에 읽기 처리를 분산하여 시스템 전체의 성능을 높이는 것이 요구된다. ㅁ 해결/패턴 읽기 성능을 높이기 위해서는 몇 가지 처리 방법이 있다. 이 패턴에서는 읽기를 여러 대의 Read Replica(읽기전용 레플리카)에 분산하는 것으로 전체 성능을 높인다. 읽기 전용 레플리카는 마스터에 대해 쓰기에 따라 자기 자신의 데이터에 반영한다. 읽기는 주로 읽기 전용 레플리카를 이용하는 것으로 마스터의 부하를 줄일 수 있다...

티스토리툴바