Azure 아키텍처, External Configuration Store Pattern

설정 파일 또는 웹서버 파일들을 일관성 있게?

우리가 사용하는 많은 툴들은 설정 파일을 가지고 있는 경우가 많다. 또는 웹서버에서 사용되는 html, css, js 파일들 또한 scaling out 되어있는 상태에서 동일한 정적 파일을 전달하기 위해서는 고민이 필요한 부분이 있다. 이렇게 scaling out 되는 서버들 또는 서버 내부가 아닌 외부에 설정 파일이나 웹서버 파일들을 관리하고 싶을땐 방법이 없을까?

External Configuration Store Pattern이란?

Overview

External Configuration Store Pattern은 단순하게 보자면, config 파일이나 웹서버에 사용되는 파일들을 각각의 Virtaul Machine 안에 두는 것이 아닌 외부에 두는 것이 포인트이다. 여러가지 방법들이 있으나, 오늘은 크게 Virtual Machine과 AKS에서의 사용을 중점으로 기록할까 한다.

기본적인 구조

Virtual Machine

위의 간단한 구조와 같이, Virtual Machine에서는 여러가지 방법이 있겠지만 저장소를 mount 하는 방법이 가장 사용하기 쉽고 보편적인 방법일 것 같다. Disk를 마운트하는 방법도 좋지만, Storage Account의 Files 또는 Blob을 통해 손쉽게 관리를 하는 것도 좋은 방법이다.

Kubernetes

Kubernetes라고 크게 다를 부분은 없다. Kubernetes 또한 configmap, secret, disk 또는 Storage Account를 사용하여 mount 한다. 하나의 source를 관리하며 여러 pod에 배포되길 원하니 당연히 하나의 소스를 mount해서 사용한다.

실제 환경에서는?

현재 진행하고 있는 프로젝트에서는 위의 2가지 방법이 모두 사용되고 있다. Virtual Machine에 Azure Files를 마운트해서 사용하는 방법은 흔히들 알고 있는 방법과는 다르니, AKS 쪽을 조금 깊게 다뤄볼까 한다.

AKS에서 External Configuration Store Pattern 활용하기

이 글에서 소개하고 싶은 부분은 일반적인 configmap이라던가 일반적인 secret 보다는 조금 더 Azure를 조금 더 활용하여 손쉬운 운영을 원하시는 사람들에게 도움이 될만한 방법이 될 것이라 생각한다.

현재 프로젝트에서는 pgbouncer를 Azure PostgreSQL에서 제공하는 부분이 아닌, 따로 pod로 띄워서 운영하고 있다.

예를 들어 아래와 같은 pgbouncer.ini와 userlist.txt 있다고 했을 때,

pgbouncer.ini

[databases]
* = host=wonchul123.postgres.database.azure.com port=5432

[pgbouncer]
listen_addr = 0.0.0.0
listen_port = 5432
unix_socket_dir =
user = postgres
auth_file = /etc/pgbouncer/userlist.txt
auth_type = md5
pool_mode = transaction
max_client_conn = 500
ignore_startup_parameters = extra_float_digits

# Log settings
admin_users = postgres

userlist.txt

"user1" "p@ssw0rd"
"user2" "p@ssw0rd"

위와 같은 pgboucer.ini 파일이 있을 때, pgbouncer.ini 파일은 비교적 노출되어도 문제가 없을것 같지만, userlist.txt는 누가봐도 노출되면 보안사고다.

위와 같은 상황에서 AKS에서의 External Configuration Store Pattern은 아래와 같이 사용하고 있다.

1. Azure Key Vault를 csi를 통해서 AKS에서 활용할 수 있는 방법이 있다. 이전에 썼던 이 글을 참고 해보자.
2. userlist.txt를 AKS 내부에서 secret으로 관리하는 것이 아닌, SecretProviderClass를 통해 해당 secret을 Azure Key Vault와 연동되게 하여 사용한다.

위와 같은 시나리오로 사용되고 있는 부분을 argocd로 보면 아래와 같다.

SecretProviderClassPodStatus라는 것이 pod가 생성될 때 생성이 되며, 동시에 SecretProviderClass에서 생성한 secret을 사용할 수 있게 된다.

이러한 구조에서 가질 수 있는 장점은 아래와 같다.

1. secret안에 있는 configuration을 secret yaml 수정이 아닌 Azure Key Vault에서 ini 파일만 교체해서 넣으면 된다. 즉 변경 접근성이 매우 용이해지며 접근 권한도 Azure에서 컨트롤하기에 한결 편해진다.
2. yaml을 변경 안해도 된다는 포인트는, 다른 뜻으로 해석하자면, gitops 환경에서 git에 base64인코딩만 시킨 나의 credential들을 올릴 필요가 없다는 뜻이다. (굳이 gitops가 아니더라도 yaml은 관리할테니 보안적으로는 전체적으로 좋아질 수 밖에 없다.)

그냥 간단히 secret 작성하여 사용하는 것보다는 조금 더 손이 많이 가지만 보안적으로 좋아진다는 점과, 초기 배포를 제외하고 운영면에서는 위와 같은 방법이 훨씬 편하다. 경험담이다.

고려해야할 점

이러한 외부 저장소들의 여러가지 포인트들이 고려되어야 한다.

• 저장소가 고가용성을 제공하는가?
• 저장소가 혹시 Zone dependency가 있어 특정 zone에 배포된 Virtual Machine 또는 node에만 연결이 되는 것은 아닌가?
• 저장소의 백업은 쉬운가?
• 저장소의 용량의 확장성은 편리한가? 확장할 때 다운타임이 필요한가?

위와 같은 몇가지 고려 포인트들로 인해, 나는 일반적으로 paas형 제품들을 많이 활용하는 편이다. 특히나 Storage Account는 위의 고려사항들을 대부분 해소해준다. 특히나 Azure Files가 용량 전체로 점유 비용으로 나와서 가끔 고민했었는데 최근 blob fuse가 나오고비용 관련된 고민도 많이 해소가 되었다.

마치며

External Configuration Store Pattern은 config와 같은 파일들을 Virtual Machine 내부가 아닌 외부에 저장하여 공유함으로써 관리의 용이성과 동시성을 높일 수 있는 디자인 패턴이다. 흔히들 웹서버를 구축할때 많이들 사용하였지만, AKS 안에서 보안성이 필요한 파일들을 Azure Key Vault와 함께 사용할 수 있는 부분들을 알아 보았다. 특히나 요즘 거의 대부분의 프로젝트들이 gitops 구조로 가기에, credential을 git에 저장하지 않기 위해선 위와 같은 방법들이 사용되면 좋을 것 같다.