[Dynamics365] BYOD(Bring your own database) 설정하기

Dynamics365 ERP를 다루다보면 Power BI나 타 시스템과의 인터페이스를 위해 BYOD 를 사용해야할 때가 있다.

이번 글에서는 BYOD가 어떤 것인지, 언제 써야하는지, 어떻게 설정하는지에 대해 알아본다.

 

1. BYOD란?

MS 공식 문서 : Bring your own database (BYOD) - Finance & Operations | Dynamics 365 | Microsoft Learn

Bring your own database (BYOD) - Finance & Operations | Dynamics 365

MS 공식문서에 나와있듯이 BYOD는 Data entity를 Azure SQL Database 에 Export 하는 기술이다.

MS 문서

 

1-1. BYOD Push option

BYOD를 설정할 때에 옵션 중에 Full push 를 할 것이냐 Incremental push를 할 것이냐가 굉장히 중요하다.

Full push (전체 푸시)	모든 데이터를 삭제 후 입력하는 방법
Incremental push (증분 푸시)	변경이 일어난 데이터에 대해서만 변경 및 삭제하는 방법

 

각각 방법에 대해 장단점이 있으니 적절한 정책을 갖고 운영하여야 한다.

Full push		Incremental push
장점	단점	장점	단점
Export할 때마다 전체 데이터를 복사하기 때문에 복사된 데이터에 대한 정확도가 높다.	모든 데이터에 대해 입력하기 때문에 시간이 매우 길게 소요될 수 있다. (특히 InventTrans나, GeneralJournalAccountEntry 같은 테이블이 있다면 더더욱)	변경된 데이터에 대해서만 Export 를 하기 때문에 시간적으로 효율적이다.	데이터의 정확성을 보장할 수 없다.

 

1-2. BYOD 증분 푸쉬의 치명적인 단점

위 표를 보면 굉장히 치명적인 말이 있다.

"데이터의 정확도를 보장할 수 없다."

 

아니 증분 푸쉬를 한다고 해서 왜 데이터의 정확도를 보장할 수 없는 것인가!?

 

증분 푸쉬는 기본적으로 Change tracking 이 Enabled 된 Entity만 설정할 수 있다는 것을 알아야한다.

그래서 Change tracking key값을 기준으로 입력, 삭제, 변경에 대한 작업을 수행하게 되는데, 만약 Export 중 배포와 같이 시스템이 다운되는 일이 발생했다면?

Dynamics365 가 기본적으로 이러한 경우에 대비해 시스템이 정상적으로 돌아오면 다시 종료됐던 시점부터 작업을 시작하게끔 하는 기능이 있지만.. Change tracking key를 놓치는 경우가 아주 가끔 발생하게 된다.

그렇게 되면 데이터가 통채로 사라지는 등 데이터의 정확도를 보장할 수 없는 경우가 발생하는 것이다.

BYOD를 통해 BI와 같은 데이터를 제공했다면 그래도 다행이겠지만, 만약 인터페이스 용으로 사용하고 있었다면 그것은 굉장히 치명적인 오류가 될 수도 있다.

 

따라서 증분 push 를 사용하더라도 주기적으로 Full push 를 통해 데이터의 정확도를 보장하거나 지속적인 모니터링이 필요할 것이다.

---

2. BYOD 사용목적

그렇다면 왜 굳이 Dynamics365 ERP에 직접 Database를 접근하지 않고 BYOD를 통해 Data를 Export를 할까?

 

1) 운영상의 이유

Dynamcis365 ERP가 Production(운영) 환경 부터는 직접적인 Database 접근을 허용하지 않기 때문에 외부에 data를 복사하여 접근하여야 한다.

 

2) 성능상의 이유

특히 Power BI가 Dynamics365 ERP의 데이터를 바라보는 방법 중에 Data Entity를 직접 OData로 접근하는 방법이 있다. 이 방법을 채택할 경우 Dynamics365 성능뿐만 아니라 Power BI의 성능에도 좋지 않을 수 있기 때문에 Database 를 따로 생성하여 데이터를 복사하는 것이다.

 

3) 인터페이스 구현의 이유

Power BI 뿐만 아니라 DB to DB 인터페이스 구현을 위해 BYOD를 사용하는 경우다 있다.

---

3. BYOD 에 대한 개인적인 견해

사실 BYOD는 위에서 서술했던 데이터 정확도의 이슈와 Export를 하는 동안 ERP의 리소스를 사용하기 때문에 ERP의 성능상에도 문제가 발생하기 때문에 잘 권장하지는 않는다. (이를 대체하기 위해 Azure Synapse Link 라는 기술을 사용하면 되지만, 잘못하면 비용이 굉장히 많이 발생하는 경우가 생긴다.)

그럼에도 불구하고 BYOD는 설정이 아주 쉽고 다른 Azure 솔루션을 사용할 필요가 없으며 비용적으로 아주 우수하다는 장점이 있기 때문에, 데이터양이 크지 않거나 중요도가 낮은 데이터를 복사할 때에는 고려해볼만한 매력적인 솔루션임에는 틀림없다.

---

4. BYOD 설정 방법

BYOD는 크게 다음과 같은 설정방법으로 이루어진다.

다른 블로그에서 잘 정리된 설정 방법

 

4-1. Azure SQL Database 생성

Azure SQL Database 를 생성하면 된다. Azure VM와 연동되는 Azure SQL 이던, PaaS형태의 Azure SQL 이던, Elastic Pool 을 사용하던 상관은 없으나 성능은 꼭 고려하여 생성하여야한다. 

MS 문서에서는 최소 성능을 아래표로 구현하라고 하지만 실제로 가이드 대로 구현하면 비용적으로 몹시 부담이 클 수 있기 때문에, 최소 사양으로 생성 후 모니터링하며 성능을 서서히 올려보는 것을 권장한다.

MS 추천 SQL 성능

4-2. Entity export option 구성

Data management > Configure entity export to database 에 접근한다.

Data management

Record를 새로 생성 후 적절한 Source name과 설명을 적어준 뒤 Connection string 을 정확히 작성해야한다.

Entity store

Connection string 에 뭘 적어야할지 모르겠다면, Azure SQL 리소스의 설정 > 연결 문자열에 가면 인증방법에 따른 문자열 예시가 있으니 복사해서 사용하면 된다.

Azure 설정

 

Connection string을 정상적으로 작성했다면 Validate 버튼을 클릭했을 때 다음과 같은 문구가 나오면 성공이다.

 

4-3. Publish

이제 구성된 Entity store 에 Entity를 게시하여야 한다.

상단에 Publish 버튼을 클릭하면 Entity Grid 가 나오는데, Export 하고자 하는 Entity를 찾아서 Publish 한다.

 

4-4. Data management 작성

이제 Export 를 하기 위한 모든 사전작업은 완료되었고, Data management 에서 Export Entity를 작성하면 된다.

Export project

Entity name : 4-3에서 게시했던 Entity 중 하나

Target data format : 4-2에서 생성했던 Entity store 명

Default refresh type : 증분 혹은 전체 푸쉬 선

추가적으로 Project catrgory는 다른 프로젝트와의 구분 때문에 Integration으로 하는 것을 권장하나 필수는 아니다.

 

이제 모든 설정이 끝났으면 Export 작업을 실행해서 정상적으로 Database 에 Export 되는지 확인하면 된다.

---

위에서 설명한 방법 말고도 Change tracking 활성화나 Time out 과 같은 설정방법에 대해서도 MS 문서에서 설명하고 있으니 문서를 잘 참고했으면 좋겠다.