grep

DevOps

AWS MSK PART4 — 운영은 어떻게 하고 있나요?

Fang여기어때

2022년 8월 31일

원문에서 보기 ↗

안녕하세요. 여기어때 서비스개발팀에서 백엔드 개발을 담당하고 있는 팡입니다😀

서비스개발팀은 여기어때 앱의 전시 데이터와 상품 데이터를 노출하고, 노출을 위한 각 도메인의 데이터를 동기화하는 서비스를 개발하고 운영하며, 여기어때 서비스 제일 앞단에서의 트래픽을 분산처리 하는 업무를 담당하고 있습니다.

“2년차 개발자와 함께하는 서비스개발팀 탐방기”에 상세한 설명이 있으니 많은 관심 부탁드립니다.

AWS MSK PART3 — 모니터링을 구축해볼까요? 글 재미있게 보셨나요?

이번 포스팅에서는 MSK 운영에 대해서 살펴보도록 하겠습니다.

AWS MSK PART 1 — MSK 도입 여정

AWS MSK PART 2 — 클러스터를 구축해볼까요?

AWS MSK PART 3 — 모니터링을 구축해볼까요?

AWS MSK PART 4 — 운영은 어떻게 하고 있나요? 👈

자동화

MSK를 운영하기 위해서 모니터링 시스템 구축도 필요하고, 관리를 위해 토픽 생성, ACL 설정 등의 업무를 진행해야 합니다. 설치와 관리를 수동으로 하게 된다면 개발, 스테이지, 상용 환경에 버전, 명령어, 설정 등의 차이가 발생하고 관리가 어려워질 것입니다. 개발자들도 쉽게 설치하고 관리 할 수 있도록 Kafka 설치, 모니터링 시스템 설치, Kafka 관리 명령어들에 대해 소스를 형상 관리하는 것을 목표로 하였습니다. 실제로 개발 환경의 모니터링 시스템을 구축하는 과정에서는 조금 힘들었지만, 스테이지/상용 환경은 설정만 변경해서 쉽게 구축할 수 있었습니다.

프로젝트의 구조는 다음과 같습니다.

https://gist.github.com/jhhwang4195/dda1a36d34c2a71645d39697954265f6#file-msk_project_structure-sh

환경 (개발/스테이지/상용) 별로 .bashrc 파일에 설정값만 설정해주면 되고, 개발 환경의 설정값을 아래와 같습니다. 위의 프로젝트 구조에서 env 디렉토리의 dev 파일의 내용입니다.

https://gist.github.com/jhhwang4195/bf5c61b2c4136bda8149de41a22fe28d#file-msk_bashrc

setup.sh 파일을 실행하면 kafka가 설치됩니다. start.sh 파일을 수행하면 AWS MSK PART 3 — 모니터링을 구축해볼까요?에서 살펴본 모니터링 시스템이 구축이 됩니다.

스크립트를 사용하여 토픽을 생성하고 ACL을 설정하는 예시를 살펴보도록 하겠습니다. 토픽을 생성하기 위해서 topic_create.sh 파일을 사용하면 됩니다. 결과는 슬랙으로 전송이 되어서 이력 관리도 가능합니다.

topic_create.sh만 입력하면 사용법을 보여주게 됩니다.

https://gist.github.com/jhhwang4195/7232027b42007cafa1a63fe2e37e0b61#file-topic_create1-sh

인자로 <TOPIC> <REPLICATION-FACTOR> <PARTITIONS>을 사용하면 되겠군요. 토픽 이름은 yeogi, 파티션 개수는 3개, Replication factor는 3으로 생성해 보겠습니다.

https://gist.github.com/jhhwang4195/3f9f438063da4ca5970591358d344fec#file-topic_create2-sh

토픽(yeogi)이 생성되면 슬랙으로 결과가 전송됩니다. 스테이지 환경의 IP는 10.0.83.153에서 2022/08/22 07:25:23에 명령어를 수행했고, 토픽(yeogi)이 생성된 것을 확인할 수 있습니다.

이제 ACL 설정을 해볼까요?

acl_add.sh만 입력하면 사용법을 보여주게 됩니다.

https://gist.github.com/jhhwang4195/5d08ae2b9181b1de18f3909ae26bdb94

인자로 <USER> <TOPIC> <OPERATION>을 사용하면 되겠군요.

syncer라는 계정에 yeogi 토픽에 Read 권한을 설정해보도록 하겠습니다.

https://gist.github.com/jhhwang4195/9b466467243f59cc90aacf98af3e42d0

ACL이 설정되면 슬랙으로 결과가 전송됩니다. 스테이지 환경의 IP는 10.0.83.153에서 2022/08/22 07:34:29에 명령어를 수행했고, syncer라는 계정에 yeogi 토픽의 Read 권한이 설정된 것을 확인할 수 있습니다.

MSK Best practice

효율적인 비용으로 MSK를 사용하기 위해서는 적정 크기의 클러스터가 필요합니다. 브로커 유형별 가질 수 있는 최대 파티션 수를 참고하고, 성능 테스트 과정이 필요합니다.

고가용성 클러스터를 설정하기 위해 다음 권장 사항을 따라야 합니다.

브로커 유형 또는 Apache Kafka 버전을 업데이트하는 경우 MSK 클러스터의 가용성을 높일 수 있습니다.

실제로 MSK를 운영하면서 MSK 클러스터 브로커의 운영체제 패치(보안 취약성 해결)가 진행되었고 약 2시간 소요되었습니다. 클라이언트 I/O 연속성 및 트래픽 유실을 방지하려면 고가용성 클러스터를 설정하기 위해 다음 권장 사항을 따라야 합니다.

아래 메일은 AWS로부터 수신한 메일입니다. GMT 기준이므로 우리시각으로는 +9시간을 하여 08/01 22시 ~ 08/02 02시 사이에 MSK 패치가 진행되었습니다.

MSK will patch the underlying operating system of brokers in your MSK cluster(s) with the latest OS updates between Mon, 1 Aug 2022 13:00:00 GMT and Mon, 1 Aug 2022 17:00:00 GMT. MSK patches brokers to address security vulnerabilities and to update software supporting the brokers. MSK uses an automated rolling update to patch one broker at a time, following Kafka best practices. To ensure client I/O continuity during the rolling update that is performed as part of the patching process, we recommend you review the configuration of your clients and your Apache Kafka topics as follows:

1. Ensuring the topic replication factor (RF) is at least 2 for two-AZ clusters and at least 3 for three-AZ clusters. An RF of 1 can lead to offline partitions during patching.

2. Set minimum in-sync replicas (minISR) to at most RF - 1 to ensure the partition replica set can tolerate one replica being offline or under-replicated

3. Ensure clients are configured to use multiple broker connection strings. Having multiple brokers in a client's connection string allows for failover if a specific broker supporting client I/O begins to be patched. For information about how to get a connection string with multiple brokers, see Getting the Bootstrap Brokers for an Amazon MSK Cluster [1].

Patching will occur on the following cluster:

arn:aws:kafka:ap-northeast-2:xxx:cluster/xxx/88a60d38-e465-48aa-aceb-dd969b7cc361-4

If you have questions or concerns, please contact AWS Support [2].

[1] https://docs.aws.amazon.com/msk/latest/developerguide/msk-get-bootstrap-brokers.html[2] https://aws.amazon.com/support

Amazon MSK는 브로커의 총 CPU 사용률(CPU User + CPU System)을 60% 미만으로 유지할 것을 강력히 권장합니다. 브로커의 CPU를 50% 이상 사용하는 경우 알람을 설정하여 브로커 유형 업데이트 또는 MSK 클러스터의 브로커 수를 확장하면 좋을 것 같습니다.

Amazon MSK 메시지를 위한 디스크 공간이 부족하지 않도록 하려면 KafkaDataLogsDiskUsed 지표를 감시하여 이 지표의 값이 85% 이상에 도달 시 다음 작업 중 하나 이상을 수행해야 합니다.

KafkaDataLogsDiskUsed 지표를 감시하여 70% 이상이면 알림을 받도록 구성하면 좋을 것 같습니다.

마치며

이번 글에서는 효율적으로 MSK를 운영하기 위한 Kafka 설치, 모니터링 시스템 설치, 소스 형상관리, 토픽 생성, ACL 등을 살펴보았습니다. 또한 MSK practice에서 고가용성 클러스터를 위한 권장 사항, MSK에 중요한 모니터링 지표인 CPU, DISK에 대해서도 살펴보았습니다.

Kafka를 구축할 때 Topic Naming Conventions 글을 보시고 토픽의 일관성 유지 및 표준화 방법에 대해서도 살펴보시면 도움이 될 것 같습니다.

Amazon MSK를 구축하는 것은 굉장히 쉽습니다. 버튼 몇 번 클릭하면 몇 시간 이내에 쉽게 구성할 수 있습니다. 하지만 잘 구축하려면 생각보다 많은 시간이 필요합니다. 제일 시간이 많이 들었던 부분은 SASL/SCRAM 인증, 모니터링 시스템 구축, 자동화 부분이었습니다. MSK를 구축하면서 Amazon MSK 문서를 3번 이상 정독한 것 같습니다. 꼭 정독하시는 것을 추천해 드리고 싶습니다.

상용 환경에서 MSK를 사용한 지 1개월이 조금 넘었지만 다행히 지금까지는 한 번도 이슈가 없었습니다. 앞으로 모니터링 지표에 대해 고도화하고, 모니터링 도구들을 Kubernetes에 올려서 사용하려고 계획 중에 있습니다.

MSK에 관해 관심이 있으시거나 구축하려고 하시는 분들에게 저의 글이 조금이라도 도움이 되었으면 좋겠습니다.

여기어때 서비스를 발전시키고 함께 성장하고 싶으신 개발자분들 많은 지원 부탁드릴게요!

끝까지 읽어주셔서 감사합니다.