작성자 : 최정인 (K-DEVCON DAEJEON 매니저)
안녕하세요~ K-DEVCON(k-devcon.com) 입니다. 😊
지난 포스팅에 이어 < 데브콘 대전 : 삼월엔 데이터! > 행사의 2부 포스팅을 시작하겠습니다.
혹시 <데브콘 대전 : 이월엔 데이터! > 행사 1부가 궁금하신 분은 이 링크를 통해 확인하실 수 있습니다!
두번째 세션 : 대용량 트래픽에도 견고한 데이터베이스 시스템 구축하기
두번째 세션은 NOWCOM에서 시니어 DBOps로 재직중이며, K-Devcon의 FOUNDER이신 강성욱님이 진행해주셨습니다. 성욱님은 NEXON 및 NHN, AWS 등을 거쳐 시니어 DBA, 데이터 엔지니어, DBOps로 다양한 영역을 넘나들고 계시며 현재는 SW Maestro 멘토도 겸하고 계십니다.😊
이번 세션은 그야말로 데이터를 위한 솔루션에 집중된 발표였는데요!
그 주제는 다음과 같습니다.
1. 다양한 아키텍쳐에 대하여
2. DB 성능 확장이 어려운 이유
3. ProxySQL이란
시작 전, 성욱님은 몇가지 주의점을 말씀해주셨는데요. 이번 내용이 인프라 관련 내용이 많고(정말 많았습니다..!), 기본 개념을 위주로 설명하며, 특정 환경에서의 아키텍처이므로 전체를 대변하지 않는 점을 강조하셨습니다.
[ 1. 다양한 아키텍쳐에 대하여 ]
모놀리식 아키텍처(MA)와 마이크로서비스 아키텍처(MSA)
첫번째 주제는 아키텍처였는데요. 모놀리식 아키텍처와 마이크로서비스 아키텍처에 대해 설명해주셨습니다.
모놀리식 애플리케이션은 단일 통합 단위로 구축되는 아키텍처입니다. 하나의 서비스에 모든 것이 다 구축되어 있기 때문에 배포가 빠른 반면, 서버가 죽으면 모든 기능이 다운된다는 단점이 있습니다.
반면 마이크로서비스 아키텍처는 독립적으로 배포 가능한 더 작은 서비스 모음입니다. 기능이 분리되어 있으므로 어느 하나에 문제가 생겨도 모든 기능이 다운되진 않지만, 인프라 관리가 어렵다는 단점이 있습니다.
성욱님은 각 아키텍처마다 장단점이 있으므로 서비스에 맞게 구축해야 한다고 말씀하셨습니다.
그러나 대부분의 아키텍처는 단일 장애지점(Single Point Of Failure)이 존재할 수 밖에 없으며, 이 부분을 어떻게 해소할 것인가가 관건이라고 합니다.
(출처:https://akfpartners.com/growth-blog/single-points-of-failure-never-trust-and-always-void, https://medium.com/@interviewready/single-point-of-failure-591f853ee5aa )
또한 성욱님은 시스템 아키텍처에 따라 단일 장애지점은 모두 다르며, 단일 지점의 문제점을 보완하여 하여 내구성(가용성)을 강화하는 것이 중요하다고 하셨습니다.
[ 2. DB 성능 확장이 어려운 이유 ]
다음으로 성욱님은 DB 성능 확장이 어려운 이유에 대하여, 다음과 같은 것들이 있다고 하셨습니다.
1) 물리적으로 데이터를 저장해야 하므로 제한적인 것이 많음, 2) 디스크 사이즈가 큼, 3)데이터 재배치 작업에 대한 오버헤드, 4) 트랜잭션을 보장해야 함, 5) 커넥션 요청 관리가 쉽지 않음.
복제(Replication)와 샤딩( Sharding)
복제(Replication)와 샤딩( Sharding)은 DB의 성능과 가용성을 확보하는 방법입니다.
복제는 같은 데이터를 복사해 여러 노드에 분산하는 방법이며, 크게 마스터-슬레이브 (혹은 main-replica )와 peer-to-peer가 있다고 합니다.
샤딩은 테이블을 특정 기준으로 나눠서 저장 및 검색하는 방법입니다. 각 노드마다 다른 데이터를 저장하면서, 읽기 작업의 부하를 줄일 수 있다고 합니다.
쳇바퀴 돌듯 반복되는 고민
대용량 트래픽 요청에 대응하기 위한 일반적인 방법으로는 Primary-Secondary Model이 있습니다. 그러나 사용자 요청시 마다 DB에 커넥션을 시도하는 번거로움이 있으므로 Connection Pool - Pool을 사용한 연결을 활용하는 방안을 적용할 수 있습니다. 그러나 요청수가 증가하면 그에 따른 커넥션 개수 문제가 다시 발생하게 됩니다.
때문에 "다양한 환경에서 유연한 구현(운영)할 방법이 없을까?" 라는 고민에 빠지게 될 수 있습니다.
[ 3. ProxySQL이란 ]
이러한 문제의 대안으로, 성욱님은 PROXY를 도입하여 커넥션 처리를 대신 하는 방법을 소개해주셨습니다.
ProxySQL 홈페이지에 들어가면 가장 먼저 다음과 같은 문장이 눈에 띄는데요.
이처럼 ProxySQL은 쿼리 라우팅 기능을 제공하는 MySQL(또는 MariaDB)의 오픈소스 프록시입니다.
ProxySQL에서 제공하는 기능으로는 1) Connection Multiplexing, 2) Query Rules, 3) Deploy it anywhere, 4) Zero vendor lock in가 있다고 합니다.
성욱님은 ProxySQL 을 사용하기 위해서는 관리할 수 있는 아키텍처로 구성해야하며, 그 솔루션으로 다음과 같은 것을 제안했습니다.
1. ProxySQL을 클러스터로 구성
2. Orchestrator를 사용하여 자동 페일 오버 구성
3. MySQL Galera Cluster + ProxySQL
그리고 ProxySQL을 활용한 다양한 구성 방법으로 , 1) One ProxySQL instance per application server, 2) 2. Multiple ProxySQL hosts, 3) Silos approach, 4) Silos + Multi-layers, 5) Keepalived + VIP, 6) Multi-layer + Keepalived + VIP + LVS 를 소개해주셨습니다.
여기까지가 성욱님의 대용량 트래픽에도 견고한 데이터베이스 시스템 구축하기였습니다. 아키텍처에 익숙하지 않는 분들에게는 다소 어려울 수 있는 내용이었는데요! 특정 사례에 대한 문제 원인 파악부터 다양한 솔루션까지 배울 수 있는 매우 유익한 시간이었습니다. 😊
세번째 세션: 패널 토크
이어서 세번째 세션에서는 연사자님들과 함께 패털 토크를 진행했습니다!
패털토크는 자유롭게 질문을 받기 위해 참석자분들께 익명으로 질문을 받고, 답변을 드리는 방식으로 진행되었습니다.
그 질문 중 일부는 다음과 같았습니다.
1. 디비가 언제 왜 죽는지 케이스를 알 수 있을까요
2. 진짜 회선이 고장나는 경우가 많은가요?
3. 해결하지 못하거나 해결중인 케이스가 있는지?
1. DB가 언제 왜 죽는지 케이스를 알 수 있을까요
이에 대하여 성욱님은 DB의 스펙을 알아야 정확한 분석이 가능하다고 하셨습니다. 그리고 실무 환경에서는 기본적으로 DB를 모니터링 하면서 현재 메모리 사용과 리퀘스트 처리량 등을 파악하여 예측하긴 하나 완벽히 알수는 없다고 말씀하셨습니다. 추가적으로 정우님은 DB를 다운시키는 것은 마음만 먹으면 가능하므로 개발자는 DB를 잘 쓸 수 있도록 최소한의 정보를 알고 있는 것이 좋다고 조언하셨습니다.
2. 진짜 회선이 고장나는 경우가 많은가요?
이에 대하여 성욱님은 꽤 많았다고 하셨습니다. 의도치 않게 트래픽이 늘어나서 고장나거나, 하이퍼바이저에 문제가 생겨서 죽기도 하며, 흔치는 않지만 IDC의 스위치가 나간적도 있다고 하십니다.
3. 해결하지 못하거나 해결중인 케이스가 있는지?
이 질문에 대해서는 연사자님께서 재밌는 경험담을 들려주셨는데요!
성욱님이 게임 회사에서 일을 하셨을 때라고 합니다. 인도네시아에 게임을 팔았는데, 비만 오면 장애가 나고, 특정 시간에 계속 서버가 꺼지는 문제가 발생했다고 합니다. 어쨋든 게임을 팔았으니 인도네시아까지 출장을 갔는데, 알고보니 비가오면 장비 위로 누수가 되서 장애가 발생한 거였고, 특정 시간에 서버가 꺼지는 것은 청소하는 분이 청소하면서 서버의 전기 코드를 빼서 꺼졌던 것이었습니다.
이처럼 비가 오는 날에 장애가 발생하는 것은 패턴이 있어서 찾기가 쉬운 편인데, 후자의 문제는 패턴이 없어서 원인을 찾기까지 상당히 어려웠다고 합니다.
정우님도 인도네시아 비자 센터 서비스를 만들었을 때의 경험에 대하여 말씀해주셨는데요!(또 인도네시아..!) 그때 서버에 문제가 발생했는데, 그 원인이 전력이 부족해서 서버가 꺼졌던 것이라고 합니다. 이처럼 국가 기반 시설이 부족하거나 특정 이슈 때문인 경우 극복이 쉽지 않고, 원인을 찾는데까지도 시간이 오래걸린다고 합니다.
이외에도 많은 질문이 오갔었는데요! kdevcon 행사에 참여하시면 블로그에 담지 못한 경험담을 들을 수 있을 뿐 아니라 패널토크에 직접 참여하실 수도 있답니다 :>
이것으로 세번째 세션, 정우님과 성욱님의 패털토크까지 마무리 되었습니다. 현장에서 직접 질문과 답변을 주고 받으니 연사님들의 재밌는 경험담을 들을 수 있어서 너무 좋은 시간이었습니다.😊
네트워킹 및 경품 추천
마지막으로 네트워킹 및 경품 추천시간이 다가왔습니다!
참가자분들께 추첨을 통해 신간 IT 도서를 증정하는 것인데요.
이번에는 IT 실용도서 전문 출판사 이지스퍼블리싱과 Golden Rabbit사에서 소중한 도서를 후원해주셨습니다.😊
Do it! 웹 사이트 기획 입문
Do it! 파이썬 생활 프로그래밍
Do it! 웹디자인 교과서
데이터 과학자 원칙
프로덕트 매니저 원칙
멋진 책을 후원해주신 이지스퍼블리싱과 Golden Rabbit사에 다시한번 감사드립니다~🤗
오랜만에 운영진분들의 모습을 담아봤습니다. 😊
컨디션이 좋지 않은 와중에서 행사를 도와주신 지윤님 감사합니다!
모두들 고생하셨어요~!
여기까지 <데브콘 대전 : 삼월엔 데이터!> 행사에 대한 이야기를 적어보았습니다!
벌써 4월이 왔습니다. 이번 달에는 가족과 친구들과의 소중한 시간을 보내며 행복한 순간을 만들어 나가는 한 달이 되길 바랍니다. 모두들 환절기에 감기 조심하시고, 다음 행사때 많은 관심 부탁드려요!
언제나 여러분들의 성장을 응원하는 K-Devcon이었습니다 ~ 🙌
(끝)
K-DEVCON은 IT 전문가 커뮤니티 그룹으로 다양한 IT 기술을 연구하며 회원간의 소통을 공유하는 모임 입니다. 현재 IT업계에 종사하고 있거나, 종사할 예정이거나, IT를 공부하는 학생 그리고 IT에 관심이 있다면 누구나 함께할 수 있습니다.
기술 세미나, 스터디, 토론 등 다양한 활동을 하고 있으며, 주요 소통 및 이벤트 공유는 오픈챗 및 홈페이지 등을 통해서 공유하고 있습니다.
소프트웨어 엔지니어, 데이터 엔지니어, 머신러닝 엔지니어, 시스템 엔지니어, 시큐리티 엔지니어, 데브옵스, SRE, PM, Educator, UI/UX, 스타트업, 대학생 등 다양한 구성원이 활동 중입니다.
homepage : https://k-devcon.com
contact : info@k-devcon.com
'데브콘 행사 후기' 카테고리의 다른 글
| [Review] 2024-05-30(목) K-DEVCON 서울 : 오월엔 AI (0) | 2024.06.11 |
|---|---|
| [Review] 2024-04-25(목) K-DEVCON 서울 : 사월엔 브랜딩 (0) | 2024.04.30 |
| [Review] 2024-03-28(목) K-DEVCON 서울 : 삼월엔 일을 제대로 하자! (0) | 2024.04.02 |
| [Review] 2024-03-23 K-DEVCON Deajeon : 삼월엔 데이터! (1) (0) | 2024.03.31 |
| [Review] 2024-02-24 K-DEVCON Deajeon : 이월엔 지오! (3) (0) | 2024.03.23 |