1. 목적
트래픽과 사용자 증가에 대응 가능한 시스템을 설계하고자 합니다.
2. 로드 밸런서 사용
ELB와 ALB는 다릅니다. ELB는 TCP/IP 계층과만 통신하는 L4지만 ALB는 L7입니다. 따라서 IP와 포트뿐 아니라 HTTP 등의 프로토콜도 인식할 수 있습니다. 특히 ALB를 사용하면 특정 경로에 대한 요청을 특정 서버로 라우팅할 수 있습니다.
ALB에 대해 보다 자세히 얘기하면 API 요청을 분리하여 개별 서비스로 갈 수 있도록 할 수 있습니다.
3. 오프라인 & 비동기 처리
실시간으로 처리하지 않도록 변경하는 것이 핵심입니다. 대표적인 예는 좋아요 버튼입니다. 좋아요 버튼을 누르면 클릭 아이콘의 색상이 바로 변경되지만 그 외의 작업(게시자에게 본인에게 좋아요가 클릭되었다는 사실 전달, 게시물의 내부 점수 상승 등)은 나중에 발생할 수 있습니다. 앱 내부에서는 관련된 메시지를 큐에 전달하게 되고, 다른 시스템은 큐의 내용을 읽어 관련 정보를 처리하게 됩니다. DB 작업도 응용과 DB 중간에 큐를 두면 일정한 패턴을 유지할 수 있습니다.
AWS에서 큐를 사용하기 위한 옵션은 SQS와 키네시스 등이 있습니다.
| SQS | 키네시스 |
| 완전 관리형 Pull 방식 서비스 | 대규모 데이터의 실시간 처리 (스트리밍 수집 서비스) |
|
신뢰성 (여러 AZ에 걸친 메시지 저장 확장성 (수백만의 메시지를 저장, 대응) 처리량 (메시지 증가에도 지속적인 처리량) 비용 (매월 무료 제공 + 종량제) |
대규모 데이터의 실시간 처리 (스트리밍 수집 서비스) 처리량 (데이터 스트림 내 샤드 수 증가로 확장 가능) 비용 (샤드 당 시간당 비용 + 페이로드) |
|
메시지의 순서 보장은 없음 적어도 한번은 메시지 전달이 보장되지만 두번 이상도 전달 가능 단, FIFO 대기열 사용하면 순서 보장 + 1회 전달 보장 |
기본적으로 24시간 보관, 최대 7일 보관 가능 리전당 샤드 수 소프트 리밋 기타 샤드 당 용량 제한 존재하니 확인 필요 |
|
메시지마다 확인/실패가 필요한 경우 수신자에게 Push 기능은 없으므로 Pull 처리 필요 하나의 메시지가 여러 수신자에게 전달 불가 |
로그, 모바일, 클릭 스트림 수집/분석 실시간 분석 처리된 메시지를 다른 앱이 다시 처리 |
4. 서버리스
EC2는 가상화된 호스트 서비스이기 때문에 운영체제 및 확장에 대한 고민이 필요하다. 그러나 람다는 가상화이긴 하나 그런 고민을 할 필요가 없다. Node.js, 파이썬, 자바, C# 등 함수(펑션)라고 불리는 코드를 생성한 후 실행할 수 있다. 그리고 람다는 코드 파이프라인, S3, 키네시스 등 많은 서비스와 통합된다.
