<aside> 💡 확장성과 성능, 모니터링 측면에서 기존에 사용하고 있던 AWS Opensearch 서비스에서 Elastic Cloud로 변경하는 것이 낫다고 판단, 기존에 있던 인덱스 데이터를 새로 배포할 ES 클러스터에 복원하기 위한 플로우를 정리하였다.

</aside>

Opesearch index 백업

사전작업

1. 스냅샷을 저장할 S3 버킷 만들기

   glacier가 아닌 버킷을 하나 만들어 주도록 하자

2. IAM Role 설정하기⭐

   • 먼저 S3에 대한 IAM Policy를 만들도록 하자
   • IAM Role에 위에 만든 정책을 연결한다.
   • 위에서 생성한 Role을 전달하고 ES에 PUT을 할 수 있는 권한을 추가로 매핑
   • 신뢰관계 편집 → a_w_s_security_token_service_exception

실제 작업

1. 호스트(컴퓨터) 권한부여

   API를 호출하여 ThePassSnapshotPolicy를 가지고 있는 Role, User를 설정하자.

   → aws configure로 설정을 하거나 VPC 안에 있는 EC2에 관련 권한을 부여하도록 하자

2. Opensearch에 스냅샷 역할 매핑

   Opensearch의 보안 구성 탭에 들어가서 해당 도메인으로 IAM 객체에 대한 작업(요청)을 허용하도록 하자

   

   IAM 사용자에 대한 권한을 허용하였다.

3. snapshot repository 생성

   권한 설정이 끝났다면 이제 REST API를 통해서 snapshot repository를 만들어야 한다.

   curl의 경우는 AWS의 요청 서명을 지원하지 않기 때문에 python, javascript와 같이 서명 지원을 하는 모듈을 다운로드하여 요청을 보내야 한다.

   • Python 클라이언트 코드

   성공시 아래와 같은 요청이 발생한다.

   

   • GET _snapshot?pretty를 통해서 현재 생성된 리포지토리를 볼 수 있다.

4. snapshot 백업

   생성된 리포지토리에 스냅샷을 백업하도록 하자 PUT 요청을 통해서 백업이 가능하다

   

   • /_snapshot/<repo_name>/_all?pretty을 통해서 조회가 가능하다.

Elastic Cloud Restore Snapshot

작업 흐름

1. Secret key 세팅

   마찬가지로 S3에 접근할 수 있는 권한이 있는 IAM user을 통해서 접근을 해야한다. Role은 AWS의 인스턴스에 부여를 할 수 있는 것이기 때문에 이 상황에서는 user의 access key와 secret key를 넣도록 하자

   

   deployment의 security에서 user key를 등록한 모습

   공식적인 문서에서 나온 내용은 아니지만 <instance_type>.client.<client_name>.access_key와 같은 방식으로 등록한다.

   • instance_type: s3가 대표적인 예일 수 있다.
   • client_name: kibana에서 등록할 snapshot repository의 클라이언트 이름

2. Kibana에서 Stack Management > Snapshot and Restore에 들어가서 repository 등록을 한다.

   

   등록 모습

   • 부가적인 옵션
   • 이외에 각종 옵션을 세팅한다. 이후에 Verify repository를 통해 S3와 연결이 원활한지 확일 할 수 있다.

3. S3에서 찾은 snapshot을 바탕으로 restore을 시작한다. 특별한 설정 없이 resotre을 진행하였다.

   

   restore이 완료된 모습이다.

   복원이 된 인덱스에 대해서는 추라고 Stack Monitoring에서 확인할 수 있다.

   

최종 구조도

• 핵심은 S3에 CRUD를 할 수 있는 권한 생성(Role)
• 그 권한을 전달할 수 있는 새로운 권한 생성(Policy)