엘라스틱서치에서 인덱스 생명주기 (elasticsearch- index_lifeCycle management) 설정

ES Version : 7.12 

kibana : 7.12 

요건 : 핫 노드에서 웜 노드로 하루 주기 설정하여 이동 및 read_only 설정했을때와 안했을때의 차이점

현재 핫 노드에서 한달 주기로 저장된 인덱스를 웜 노드로 이동시키고 있습니다.

단지 테스트를 위해서 하루 주기로 변경하였습니다. 

 

대략 한달 된 인덱스 xxxx_2023.08 의 데이터는 하루 대략 2천만건 씩 쌓여서 한달에 대략 6억건 정도가 쌓입니다.

용량으로는 7기가에서 8기가 사이 정도가  됩니다.

요구사항 : 처음 핫웜 아키텍쳐를 도입할때, 고객사에서 한달이 지난 데이터 즉, 웜노드에서도 드물게 읽기 및 검색 외에 업데이트를 원하였습니다.

 

index.lifeCycle management 에서 read_only를 기본설정으로 해놓았기때문에 검색 과 읽기 만 가능합니다. 

업데이트/데이터 삽입 불가

 

키바나에서 해당 인덱스를 업데이트 하려고 하면 밑에 구문처럼 에러가 발생합니다.

이러한 문제점을 해결하기 위해서 ILM에 read_only를 설정하지 말까에 대한 고민을 하였지만, 

warm 노드의 사용 이유와 여러 문제점에 노출이 될거같아서 드물게 해당 인덱스의 값을 변경 시킬거같아서 해당 인덱스만 변경해제 하는 방법을 찾았습니다.

 

"settings":{

"index.blocks.write" : false

} 를 사용하게 되면 해당 인덱스의 write가 가능해집니다. 

 

 

해당 인덱스에서 업데이트가 가능해집니다. 

 

반대로 

"settings":{

"index.blocks.write" : true

}  사용하면 원래대로 검색과 읽기 기능만 활성화 됩니다.

 

자바로 생성된 코드 
 public static void main(String[] args) throws IOException {
        // 해당하는 client port에 맞게 
        RestHighLevelClient client = new RestHighLevelClient(
              
        );

        // 인덱스명
        String indexName = "xxxx_2023.08.22";

        // settings 로 index.blocks.write 를 true 혹은 false로 변경가능
        Settings.Builder settingsBuilder = Settings.builder()
                .put("index.blocks.write", true);

        // 업데이트세팅으로 요청합니다.
        UpdateSettingsRequest request = new UpdateSettingsRequest(indexName)
                .settings(settingsBuilder)
                .timeout(TimeValue.timeValueMillis(5000)); // Set a timeout

        // 요청값을 acknowledgedResponse로 보냅니다.
        AcknowledgedResponse response = client.indices().putSettings(request, RequestOptions.DEFAULT);

        // 값 잘 들어갔는지 확인하는 구문
        if (response.isAcknowledged()) {
            System.out.println("Write block set to true for index: " + indexName);
        } else {
            System.out.println("Failed to set write block for index: " + indexName);
        }

        //항상 엘라 클라이언트 요청이 끝나면 close해줍니다.
        client.close();
    }

Warm 의 특징인 read_only 를 사용하는 이유

1. 저렴한 스토리지 활용 : Warm 노드는 주로 저렴한 스토리지를 사용하며, 오래된 데이터의 보관을 담당한다. 이로써 중요한 데이터를 더 빠르고 비싼 스토리지에 저장할 필요가 없어지며, 전체 클러스터의 비용을 절감 할 수 있습니다.
2. 검색 속도에 미치는 영향 감소 : warm 노드에 데이터를 욺겨놓으면, Hot 노드의 검색 성능이 영향을 받지 않게 됩니다. 즉, 데이터의 이동이나 삭제 작업이 Hot 노드에 영향을 미치지 않습니다.
3. 클러스터 성능 최적화 : Hot 노드는 주로 실시간 색인과 검색에 사용되므로, Warm 노드에 오래 된 데이터를 보관함으로써 클러스터의 전반적인 성능을 최적화할 수 있습니다.
4. 저널 과부하 감소 : Hot 노드에 저장하는 데이터가 많으면 많을수록 저널에 대한 I/O 부하가 발생할 수 있습니다. 이런 경우 Warm 노드를 사용하여 저널 과부하를 줄일 수 있습니다.

결론 : Warm 노드가 데이터를 Read_only로 관리하는 것은 해당 노드가 주로 검색에 사용되며 데이터가 변하지 않기 때문입니다.즉, 색인 작업은 Hot 노드에서 수행되고 Warm 노드는 데이터를 안정적인 보관을 담당합니다.

 

Warm 의 특징인 read_only를 사용하지 않을 경우

1. 데이터 무결성 위험 : Warm 노드에서 데이터가 계속 쓰기 작업을 수행하면 데이터의 무결성이 위험에 빠질수 있습니다. Warm 노드는 주로 읽기 및 검색 작업을 위해 사용되며, 데이터의 안정적인 보관이 주 목적입니다. 데이터를 무작위로 변경하면 검색 결과의 일관성이 훼손될 수 있습니다.
2. 성능 저하 : Warm 노드는 저렴한 스토리지를 사용하고 주로 읽기 작업에 최적화 되어 있습니다.
   따라서 쓰기 작업이 지속적으로 수행되면 스토리지와 I/O 부하가 증가할 수 있으며, 검색 성능에도 영향을 줄 수 있습니다.
3. Hot 노드의 역할 무시 : Hot 노드는 주로 새로운 데이터의 색인과 빠른 검색을 위해 사용됩니다. Warm노드에서 쓰기 작업을 수행하면 Hot 노드의 역할이 희석되고, 색인 작업과 검색 작업의 처리량이 감소할 수 있습니다.
4. 클러스터 부하 증가 : Warm 노드에서 쓰기 작업을 허용하면 전체 클러스터의 부하가 증가할 수 있습니다. 쓰기 작업은 더 많은 자원을 요구하며, 클러스터 전체의 안정성과 성능에 영향을 미칠 수 있습니다.

결론 : Warm 노드에서는 주로 읽기 작업에만 사용되도록 설정하여 데이터의 무결성과 검색 성능을 유지하는 것이 좋습니다. 쓰기 작업은 Hot 노드에서 수행하고, Warm 노드는 데이터의 안정적인 보관을 담당하도록 구성하는 것이 일반적인 아키텍처 입니다.