4강 14분51초 질문 있습니다!

인덱스 템플릿 예제를 보면 프라이머리 샤드3개, 레플리카 샤드 6개로 구성하셨는데요.

하루에 30GB 정도 쌓이는 로그를 인덱스에 저장해야하는데, 만약 클러스터 내 1개의 노드만 존재한다면, 프라이머리, 레플리카 샤드를 몇 개씩 배치하는게 좋을까요?
참고로 로그는 저장하는 용도입니다. 키바나에서만 조회합니다!
만약 하나의 클러스터 내 10개의 노드가 존재한다면, 총 10개의 EC2가 꼭 필요할까요? 하나의 EC2에서 2~3개의 노드를 만들 수 있을까요? 만들 수 있다면 이게 올바른 설계인지도 궁금합니다!
6개월 정도 로그를 쌓으면 약 180개의 인덱스가 일자별로 생성이 될텐데, 인덱스의 개수가 100개가 넘어가면 자동으로 가장 오래된 인덱스부터 삭제할 수 있는 방법이 있을까요?

질문이 많네요ㅠㅠ

샤드 하나의 크기를 몇으로 가져가느냐에 대한 문제인데 사실 이게 정답이 없습니다. 하루 30GB 쌓이는 로그라면, 만약에 저라면 노드의 증설을 고려해서 프라이머리 샤드 3개 정도로 시작해 볼 것 같습니다. 그리고 클러스터에 노드가 1개만 존재한다면 레플리카 샤드는 아무곳에도 배치 되지 않고 클러스터의 상태가 yellow 를 계속 유지하게 될 겁니다. 그래서 클러스터에 노드가 1개라면 레플리카 샤드는 사실상 사용할 수 없는 것과 마찬가지 입니다.
저도 예전에 비슷한 생각을 했었고 하나의 서버 내에 포트를 나눠서 여러 개의 ES 인스턴스를 작동 시켰었습니다. (https://brunch.co.kr/@alden/34) 이 구조는 비용을 줄이거나 서버의 사용량을 극대화 하는 것에는 도움이 될지 모르겠지만 운영적인 측면에서는 복잡도가 상당히 올라가는 구조 입니다. 왜냐하면 하나의 EC2 서버에 운영을 위한 리부팅 작업 같은 게 필요할 때 영향 받는 ES 인스턴스가 여러가지가 되기 때문에 소통 비용도 늘고 고민해야 할 것들이 늘어나게 됩니다. 올바른 설계이냐 아니냐 까지는 모르겠지만 분명히 운영 복잡도를 높이는 설계이긴 합니다.
Index Lifecycle Management (ILM, https://www.elastic.co/guide/en/elasticsearch/reference/current/index-lifecycle-management.html) 을 참고하셔서 정책을 만들면 가능 합니다. 전체 인덱스 개수를 트리거링 기준으로 삼을 수 있을지는 모르겠지만, 생성된지 특정 기간이 넘어간 인덱스들 (예를 들어 1개월 이상 된 인덱스)을 트리거링 기준으로 삼아서 해당 인덱스들의 스냅샷을 생성하고 백업한 후에 지우게 하는, 일종의 라이프사이클 작업을 설정할 수 있습니다.

인프런 커뮤니티 질문&답변