고객 사례

[Digital Native 고객 사례] Terraform, OPA 정책 기반 Shifting left with Google Cloud 모범 사례

2022년 9월 26일

https://storage.googleapis.com/gweb-cloudblog-publish/images/solution_infra_blog_1.max-2600x2600.png

Google Cloud Korea Team

Google Cloud 사용해 보기

$300의 무료 크레딧과 20개 이상의 항상 무료인 제품으로 Google Cloud 사용을 시작해보세요.

2022년 Google Cloud 와 함께 디지털 혁신을 이뤄낸 Digital Native 기업 Enlighten의 사례를 소개합니다. 이번 포스트에서는 Google Cloud와 함께 복잡한 서비스 인프라 관리 비용과 새로운 기능 구현을 위한 인프라 변경 작업 시간을 감소시키는 데 성공한 엔라이튼을 소개합니다.

기업소개 및 프로젝트 배경

엔라이튼은 다양한 신재생에너지를 연결해 시장에 없던 새로운 서비스를 만드는 국내 최대 에너지 IT 플랫폼 기업 중 하나입니다. 혁신적인 IT와 금융 역량을 바탕으로 태양광 밸류체인 통합 서비스를 제공할뿐 아니라 태양광 발전소를 원격 관리할 수 있는 '발전왕', 전기차 사용자들의 충전 도우미 '충전왕', 재생에너지 투자 플랫폼 '솔라브리지' 등 다양한 사업영역을 통해 모두가 새로운 에너지 생산과 소비 방식을 누릴 수 있는 미래를 그려나갑니다.

2020년 에너지 스타트업으로 유일하게 과학기술정보통신부 글로벌 ICT 미래 유니콘 기업에 선정됐으며, 같은 해 11월에는 금융위원회 및 과학기술정보통신부가 심사한 ICT 분야 '혁신기업 국가대표 1000'에 선정돼 에너지 효율 향상 관련 IT 기술력과 혁신성을 인정받았습니다. 2022년에는 국내 최초로 RE100과 CF100(24/7 Carbon-Free Energy) 동시 파트너사에 선정되어 지속가능한 사회에 기여하고 있습니다.

이러한 성장 속에 엔라이튼은 한가지 고민을 가지고 있었습니다. 그것은 사업이 점점 다양해지고 성장할수록 이를 지탱하는 서비스 인프라 아키텍처가 더 복잡해질 수 밖에 없었고 이를 관리하기 위한 인원 및 자원이 점점 많이 요구되고 있다는 점이었습니다.

기존 서비스 환경 및 프로젝트 목표

프로젝트 시작 전 엔라이튼 DevOps 팀의 서비스 인프라 아키텍처 관리 환경을 다음과 같이 그림으로 표현해보았습니다.

https://storage.googleapis.com/gweb-cloudblog-publish/images/image2_3.max-1400x1400.png

[그림1]

먼저 엔라이튼은 복잡해지는 인프라의 관리를 위하여, 전체 아키텍처 IaC 전환을 Terraform 을 기반으로 대부분 변경한 상태였습니다. 만약 새로운 인프라 변경에 대한 요청이 발생할 경우 이는 우선 GitHub 이슈를 이용해 DevOps 팀에게 전달됩니다. 그 후 내부 리뷰를 거친뒤 DevOps 팀원의 노트북에서 직접 terraform apply 명령을 실행하여 개발하고 운영 환경 인프라를 변경하는 구조였습니다. Terraform 이용으로 작업자 노트북에 생성되는 state 파일은 Terraform Cloud 와 동기화해서 보존하고, Terraform 코드는 GitHub 를 이용해 형상관리를 진행했습니다.

이러한 구조를 채택한 주된 원인으로는 On-prem 데이터센터를 포함한 다양한 환경에 배포를 진행할 때 사무실에서 네트워크 접근이 용이했던 점, 그리고 작업자 노트북에서 terraform apply 를 진행하기 때문에 빠른 에러 메시지 확인 후 수정이 가능했던 점 등이 있었습니다. Github Workflow 나 Terraform Cloud 와 같은 외부 실행환경을 이용하려는 아이디어도 있었지만, 성능과 네트워크 보안등의 문제로 인해 도입하지 못했습니다.

하지만 위 아키텍처에 대한 프로젝트 평가 미팅을 수차례 진행하면서, 엔라이튼이 겪고 있는 어려운 점들과 구글에서 제안드릴 수 있는 아키텍처 개선점을 발견할 수 있었습니다.

인프라 변경 작업 정보(예: state, log 등)가 작업자의 노트북에 있으므로 작업 기록을 남기기가 힘들며, 다른 팀원들과의 협업시 작업 정보 공유를 위한 추가적인 커뮤니케이션이 필요로 함.
시간이 지날수록 복잡해지는 인프라 코드에 대한 유지보수에 대한 난이도 증가로 이후 팀원이 늘어날 수록 기존 인프라에 대한 정보 공유가 어려워지며, 코드 변경시 실수가 발생할 여지가 늘어남.
인프라 변경에 대한 준비 완료 후 배포전 각 인프라 책임자의 교차 검토가 없어, 배포전 에러 발견이 어렵고 배포에 대한 책임이 오롯이 작업자에게 집중됨.

위의 개선점들을 고려하여 새로운 인프라 관리 환경 구성 목표는 다음과 같이 정하였습니다.

On-prem 데이터센터, GCP 뿐만 아니라 다양한 플랫폼 지원 - 계속해서 성장하는 엔라이튼의 사업을 고려 기존에 사용하고 있는 다양한 플랫폼 뿐만 아니라 새로운 플랫폼의 추가도 유연하게 가능할 것
새로운 인프라 변경에 대한 난이도 감소 및 빠른 에러 발견 - 인프라 변경 작업에 대한 난이도를 감소시켜 작업자의 부담을 줄이고, 만약에 실수를 하더라도 배포 이전에 발견하여 Try & Error 횟수를 줄일 것
다수의 팀원들과 원활한 협업 및 작업 인수인계 가능 - 앞으로 계속해서 커져가는 DevOps 팀 및 다른 팀들과의 협업시 지금보다 편하게 기존 작업 기록을 공유하고 의사결정 할 수 있을 것

목표 서비스 환경 구성 및 기대효과

새로운 인프라 관리 환경을 구상하면서 가장 염두에 둔 점은 어떻게 하면 앞서 결정한 목표를 만족하면서 복잡한 인프라 관리를 쉽게 할 수 있을지였습니다. 이를 위해여러 번의 브레인 스토밍과 회의를 거쳐 아래의 두가지에 집중한 새로운 아키텍처를 설계 할 수 있었습니다.

https://storage.googleapis.com/gweb-cloudblog-publish/images/image1_5.max-1600x1600.png

[그림2]

1. Policy as code - OPA, Rego, Conftest, Terraform

새로운 아키텍처를 디자인 하면서 첫번째로 고민 했던 점은, 복잡한 IaC 코드의 관리 였습니다. 특히 자주 발생하는 실수를 줄이고, 잘못된 코드가 운영환경에 배포될 가능성을 줄이는데 집중하였습니다. 고민 끝에 Policy as Code 개념을 OPA(Open Policy Agent)를 이용해 구현하여, Terraform 코드가 실제 배포되기 이전에 내부 정책을 만족하는지를 검증할 수 있도록 아키텍처를 디자인 하였습니다.

Terraform 코드를 검증할 수 있는 정책을 만드는 방법은 여러가지가 있었습니다. 그 중 OPA는 오픈소스 기반에 Kubernetes 의 자원 정책을 검증하는 Gatekeeper 로 사용되며 이미 운영환경에서 검증되었기 때문에 이것이 정책 검증 도구로써 가장 엔라이튼에 적합하다고 판단되었습니다. OPA 는 기본적으로 JSON 데이터를 Rego 라는 언어로 작성된 정책을 통해 검증하는 구조로 되어 있는데, 여기서는 HCL 로 작성된 Terraform 코드를 검증해야하므로 바로 OPA를 직접 사용할 수는 없었습니다.

OPA 를 이용해 Terraform 코드를 검증하는 예시¹가 있었지만, terraform plan 을 바이너리로 생성 후 JSON 으로 변경해 검증하는 방식이라 빠른 Terraform 코드 검증에는 적합하지 않아 다른 방법을 강구하여야 했습니다., 고민 끝에 OPA 기반에 HCL, HCL2 을 Rego 정책을 검증할 수 있는 Conftest² 라는 도구를 발견하여 이를 사용하기로 하였습니다.

아래는 GCP Firewall Rule 을 만드는 Terraform 코드를 검증하는 Rego 정책의 예시 코드입니다. 첫번째 코드 블럭은 Firewall Rule 을 작성할 경우 특정한 단어가 들어가는 이름 규칙을 지켰는지 확인하고, 두번째 코드 블럭은 Firewall Rule 에 Description 필드가 작성되어 있는지를 확인합니다. 해당 예시는 간단한 사례를 보여드리고 있지만, Rego 언어의 다양한 기능을 활용할 경우 실제 운영환경에게 필요한 복잡한 정책을 구현할 수 있었습니다.

로드 중...

위의 Rego 정책을 이용해 conftest 로 Terraform 코드를 검증하면 아래와 같이 FAIL 이 확인되면서, 그 이유를 바로 확인 할 수 있습니다. 또한 이를 pre-commit³ 기반으로 작업자 환경에서 자동적으로 검증하게 함으로써 이러한 오류를 빠르게 찾아내고 수정할 수 있게 되었습니다. (* 그림 2의 '1'부분)

이러한 정책을 통한 검증은 기존 인프라 운영 중 발생했던 실수를 코드로 명시적으로 작성하였습니다. 이를 통해 이전에는 교육을 통해서만 전달할 수 있었던 경험을 코드로 전달함으로써 의사소통의 비용을 줄이고, 실수를 미연에 방지하는 효과도 거둘 수 있게 되었습니다.

로드 중...

2. GitOps - Pull Request, Cloud build

두번째로 고민했던 점은 인프라 관리 작업 시 다양한 팀간의 원활한 협업이 가능한 구조를 만드는 것이었습니다. 기존의 구조에서는 작업자 환경에 모든 기록이 남아 다른 작업자가 중간에 작업을 인수인계 받기 힘들어 한명의 작업자에게 책임이 집중되는 어려움이 있었습니다. 이러한 어려움을 해결하기 위해서 GitOps 개념을 받아 들여, Github 의 Pull Request 로 인프라 코드를 각 책임자가 리뷰할 수 있도록 하였습니다. 그리고 Cloud Build 를 이용하여 추가적인 검토를 자동적으로 수행 후 개발 및 운영환경에 배포되는 구조를 설계하였습니다. (* 그림2의 '2'부분)

또한 Cloud Build 에서 Conftest 뿐만 아니라, Policy validation⁴ 을 통해 배포되는 Terraform Code 가 GCP Organization Policy 를 위반하지 않는지를 검증할 수 있습니다. 또한 필요하다면 terraform plan 을 OPA 로 리뷰하여 인프라 변경 작업에 대한 정책 검증을 진행함으로써 인프라 변경 작업의 Blast radius 를 관리하는 것도 가능하도록 설계하였습니다. (예: 멀티 클러스터 환경 변경 작업 시, 하나의 클러스터씩만 변경 가능하도록 강제)

또한 Cloud Build 에서 Conftest 뿐만 아니라, Policy validation 을 통해 배포되는 Terraform Code 가 GCP Organization Policy 를 위반하지 않는지를 검증할 수 있습니다. 더 나아가서 terraform plan 을 OPA 로 리뷰하여 인프라 변경 작업에 대한 정책 검증을 진행함으로써 인프라 변경 작업의 Blast radius 를 관리할 수 있도록 설계하였습니다. (예: 멀티 클러스터 환경 변경 작업 시, 하나의 클러스터씩만 변경 가능하도록 강제)

Cloud Build 에서 사용하는 검증 이미지는 DevOps 팀에서 표준 Docker Images를 만들어 Google Artifact Registry 저장해두고 활용하도록 하여, IaC Workflow 종료 시간을 단축하고 Terraform, conftest 등 다양한 도구의 버전 파편화를 방지할 수 있었습니다.

마지막으로 Terraform state 파일도 작업자의 환경을 거치지 않고, 바로 GCS 버킷에 저장하는 구조로 변경하여 state 정보를 한 곳에만 보관하도록 개선하였습니다. 그리고 Terraform apply 가 실행되는 곳이 작업자의 노트북에서 Cloud Build 로 변경됨으로써 모든 작업 수행 기록이 Cloud Log 에 자동적으로 기록되어, 각 작업에 대한 기록을 팀원들간에 따로 공유하지 않더라도 Cloud Console 에서 확인 및 조치가 가능해졌습니다.

결론

엔라이튼은 위와 같은 개선 과정을 통해 다음과 같은 비즈니스 이점과 Lessons-Learned를 얻을 수 있었다고 합니다.

비즈니스적 이점

복잡한 서비스 인프라 관리 비용 감소 및 새로운 기능 구현을 위한 인프라 변경 작업 시간 감소

새로운 서비스 인프라 관리 환경의 도입으로 인프라 관리 작업 복잡도가 감소하여, 비즈니스에서 필요한 신규 기능을 이전보다 신속하게 추가할 수 있게 되었습니다.
Polisy as Code 개념의 도입으로 인프라 코드의 에러 발견과 수정이 적은비용으로 가능해지면서 전체적인 인프라 관리 비용이 감소 되었습니다.
GitOps 를 통한 인프라 관리 커뮤니케이션 방법 개선 및 책임의 분산으로, 이전과 비교해 여러명의 작업자 간의 원활한 협업이 가능해져 추후 더 복잡해지는 인프라 관리에 대응할 수 있는 팀 확장이 가능해졌습니다.

Lessons-Learned

IaC 개념을 통해 인프라를 코드로 정의하는 것만으로는 복잡한 인프라 관리 문제가 해결되지 않습니다. 오히려 코드의 노후화, 인수인계의 부재등과 같은 이유로 IaC 이전보다 인프라 관리 비용이 증가할 수 있습니다.
애플리케이션 개발과 마찬가지로, 코드로 정의된 인프라도 자동화된 테스트와 지속적인 결합 및 배포를 통해 관리해야만 신속한 변경 적용 및 유지보수가 가능해집니다.

본 프로젝트에 적극 참여 및 기여해주신 다음 참여자 분들께 감사의 인사를 드립니다.