.

1. 목적

AS-IS AWS계정에서 TO-BE AWS계정으로 동일한 구성으로 그대로 마이그레이션

2. HBase 마이그레이션 방안

• 스냅샷을 뜨는 방식이고, 특정시점에 동일하게 HBase와 메타데이터 저장소인 pg도 스냅샷을 뜬다. hbase는 주테이블이 n개가 있고, 새벽시간에 뜰 예정이다. 서비스를 가장 적게 쓰는 시간대이기 때문이다.

• hbase export snapshot을 임시 s3 버킷을 만들어 거기에 올릴것이다.

• 스냅샷 인포는 해당 hbase의 스냅샷을 찍는 그 타임의 메타만 떠지는 것이다.

• 실질적으로 우리가 옮겨야 하는 것은 h파일이다. 스냅샷 방식은 스냅샷을 뜰때 그때쓰는 h파일의 정보만 뜬다는 것이다.

• export snapshot을 한다 그러면 그제서야 h파일이 넘어가게 된다. 이슈는 export snapshot job 작업을 해야하는 자원이 부족한 상태다. 가용할 수 있는 mapper 개수가 00~00개정도 밖에 안된다. mapreduce 개수를 늘릴 수 있는 방안을 강구하고 있다. 최대 00개를 원하고 있다.

• 맵리듀스의 매퍼 00개 100mb/s기준 00시간 이상으로 예상하고 있다. 전체 5테라바이트 예상하고 있음

• 스냅샷은 단점이 h파일이 변경(메이저 컴팩션)이 일어나면 안된다. 그게 현재 일배치로 일어나고 있다. 그거를 disable로 작업할때는 걸어줘야 한다. 스냅샷뜨기 직전에 메이저 컴팩션을 날려서 h파일 정리를 하고 snapshot 작업을 해줘야 한다.

• asis에서는 리스타트하는 작업이 두번 해줘야 한다. 메이저 컴팩션 disable때 한번 able때 한번.

• s3 -> hbase로 옮겨야 하는데 export snapshot를 이용한다. tobe는 그래도 매퍼개수를 마음대로 늘릴 수 있으니 최대 15개 밴드위스도 200mb/s로 조절할 수 있다.

• pg(메타스토어)도 마이그레이션이 되야한다. 동일한 시점에 red도 마이그레이션이 되야한다. 중요한점은 이 세개가 동일한 시점이어야 한다는 것이다.

• QA) 특정어플리케이션 중에 hbase의 데이터를 리드하고 거기에 플러스 또 새로운 데이터를 더해서 hbase에 들어가게 되면 hbase에 기존에 데이터가 있었어야하는거 아니냐

• A) rdb처럼 기존데이터를 서머리하거나 가공할 수 없다. hbase는 데이터를 쌓여나가는 거 밖에는 안된다. aggregation은 기본적으로 hbase에서는 하지 않는다.

• tobe로 데이터가 쌓일때 중간에 애러가 나면 asis -> s3를 s3-> tobe가 데이터 검증이 맞아야 한다.

• 1차검증 : h파일목록 같은지, 사이즈 같은지, 인포 같은지

• 2차검증 : 테이블 하나 리스토어해서 hbase에서 제공하는 hbcheck 기능을 이용해서 블락단위의 체크

• QA) asis-tobe간 hbase의 데이터의 검증은 어떻게 할것인지?

• A) 스냅샷으로 떠지는 h파일의 메타정보가 같느냐. 이 말은 스냅샷의 타입이 그 자체로 무결한가를 따지는 것이다.

• 스냅샷뜰때 asis 스냅샷인포와 tobe의 스냅샷인포를 비교해서 같다면 대략적으로는 파일이 안깨졌다고 판단할 수 있다.

• hbase 전체 차원에서 쪼가리 쪼가리 블락단위를 리스토어해서 파일시스템 체크처럼 돌려보는 작업을 해준다. 여기에 플러스 테이블에 대한 메타정보까지 체크해준다.

• 이렇게 하면 블락단위의 데이터가 깨지지 않았고, 실제 hbase 데이터도 깨지지 않았다고 판단할 수 있다.

• 비지니스적으로 데이터 정합성을 맞춰보는 것은 hbase rowcount정도 할 수 있는데 테이블을 풀스캔하는 것이고, 현재로써는 mapreduce자원이 부족해서 현재 상태로는 할 수 없는 것으로 판단했다.

• QA) 그러면 특정 날짜만 샘플링해서 그렇게 카운트 할수없냐 ?

• A) RDB는 인덱스로 그렇게 할 수 있는데 hbase는 인덱스가 없기 때문에 풀스캔할 수 밖에 없다. 따로 pkey가 있으면 날짜만 추려서 할 수 있겠는데 그게 없기 때문에 할 수없다.

• asis의 hbase는 두번 셧다운이 필요하고 12시간 이상의 시간이 필요하다. 현재 tobe hbase에 스키마는 만들어두었다. 수동으로 데이터를 인서트를 해서 어플리케이션을 테스트할 수도 있다

3. CDH의 HBase클러스터는 그냥 AMI 이미지를 떠서 옮기면 되는거 아니냐?

• 디스크만 옮긴다고해서 해결할 수 있는 문제가 아님

• HDFS라는 시스템을 생각해야 하는데 HDFS의 기본개념은 데이터를 블락단위로 쪼개고 3개이상 복제를 떠서 각 노드에 저장한다는 것인데 그렇게 하려면 네임노드라는 곳에서 각각의 노드정보를 알고 있어야 한다. 그런 정보는 Hadoop이 구동중일때는 항상 메모리에 갖고 있다가. 시스템을 내리게 되면 하드디스크에 저장하게된다.

• 어쨌든 네임노드는 데이터노드들의 정보와 거기에 뭐가 저장되어 있는지 알고 있는 곳인데 단순하게 디스크만 AMI로 떠서 마이그레이션을 한다고해서 버츄얼 머신의 시스템 정보들도 같이 마이그레이션을 하는게 아니기 때문에 AMI로 디스크만 떠서 옮겨봤자 소용이 없다는 말이다.

• 따라서 클라우드애라에서도 권고하는 것은 동일한 설정의 하둡시스템을 마이그레이션 할 플레이스에 먼저 띄우고 distcp 등의 기능을 이용해서 옮기라고 한다.

• 그렇게 되면 데이터만 특정 클러스터에서 다른 클러스터로 보내주게되고 네임노드에서 데이터를 받아서 그 클러스터 정보에 맞게 네임노드가 데이터노드에 데이터를 분산 저장한다는 것이다.

• HBase는 HDFS라는 로우한 시스템 위에서 작동하는 하이레벨 NoSQL 서비스일 뿐 결론은 HDFS라는 것이다.

• 그래서 이번 프로젝트의 핵심은 AS-IS의 네트워크 밴드위스를 얼마만큼 우리가 쓸 수 있냐에 따라 데이터 마이그레이션 속도가 달라진다는 것이다.

4. CDH 클러스터(HBase, Kafka 등) 분석

• Cloudera Manager 서(7180포트) 내로 접속해서 클러스터 내 인프라 현황(네트워크 등), 애코 서비스 config 등 분석 확인

• Default에 가까운 클러스터 설정(디폴트 설정 이외에 특별한 설정 없음, 커버로우 등 보안설정 없음)으로 확인

• 마이그래이션 시 특별한 이슈가 없이 무난할 것으로 예상

5. 분석했던 CDH 구성에서 문제점

1) 카프카와 주키퍼를 같은 호스트에 두고 사용하고 있는데 이는 좋은 방법은 아니다. 네트워크 부하가 서로 적은 편이 아니기 때문에 카프카와 주키퍼는 상태정보를 빠르게 빠르게 막 주고받는 구조인데 이 둘이 같은 호스트에 있다는 것은 네트워크 부하에 대한 부담이 훨씬 커진다는 말이다.

2) kafka 클러스터(노드 3대)의 config을 보면 num.partitions = 10이라고 되어있는데 설정이 지금 잘못들어가져 있는것이다. 카프카 작동에는 문제가 없으나 3(노드대수)의 배수로 파티션 숫자가 설정이 되야 노드에 고르게 부하가 가는데 파티션 숫자가 10이라는 것은 어떤 노드 하나에 불균형하게 부하가 더 간다는 것이다. 이는 운영상에서 저 노드 하나 때문에 연쇄적으로 클러스터가 문제가 될 수 있는 잠재소지가 될 수 있다. 하둡의 사상은 어떤 큰 데이터나 잡이 있으면 노드들이 고르게 동작해야 한다는 것이다. 불균형하면 안된다 노드 간에서 그래서 예를들어서 하둡의 HDFS 같은 경우도 데이터가 어느 특정노드에 더 많이 쌓이는 것을 고르게 쌓을 수 있도록 조절하는 옵션도 있다. 카프카는 하둡의 사상처럼 모든 노드가 균형있게 일을 해야한다는 기본적인 개념을 엔지니어는 알고 있어야 한다.