대통령 탄핵 청원으로 본 아고라의 기술적 도전

이 글은 5월 8일 작성되었으나 외압에 대한 논쟁이 있었던 바 어느 정도 이슈가 잠잠해 진 후 공개합니다.본 글은 개인적인 의견일 뿐 다음의 공식 입장이 아니며 아래 기술 구조도 Daum의 것과 명확히 일치하지는 않습니다.

사용자 삽입 이미지
황금같은 연휴가 시작되는 5월 2일 저녁에 퇴근하는 데 몇 명의 개발자들이 심각하게 이야기를 하고 있더군요. 바로 Daum의 아고라를 담당하는 개발자들이었습니다. 쇠고기 문제에 따라 ‘대통령 탄핵 청원’과 토론방에 대한 트래픽이 점점 늘어나서 한 두 서버가 버티지 못하고 있으니 서버 장비 세트를 더 추가할 것인지 의논하고 있었습니다.

아니나 다를까 그날 새벽 아고라 토론방은 장애를 겪고 장애 처리를 위해 밤새 담당 개발자들이 회사에 나와 있었습니다. 뿐만 아니라 두번째 촛불집회가 있었던 3일 밤에도 촛불 집회 후 접속한 네티즌들 덕분에 급작스런 트래픽 때문에 장애를 겪었습니다. 급기야 5월 7일에는 추천/반대 기능 일시 중단과 서버 추가 등의 긴급 조치를 취하였습니다.

게다가 대통령 탄핵 청원 숫자가 감소하고 있다는 네티즌들의 제보가 잇다르면서 정치적 압력에 의한 조작이 이루어지는 것은 아닌가 하는 의심까지 하고 있습니다. 진실은 ‘기술적 장애’인데 결과는 ‘정치적 압력’으로 나타나고 있으니 회사 담당자나 개발자도 답답할 노릇입니다.

미디어 다음에 있는 UCC섹션인 아고라는 주로 토론이나 댓글로서 소통하는 곳입니다. 우리가 사용하는 일반 웹 서비스는 읽기를 주로 이루고 쓰기는 아주 적게 이루어집니다. 게시판을 생각해 봐도 ‘글 조회’가 ‘글 쓰기’ 보다 많으니까요. 만약 조회보다 쓰기가 계속해서 더 많아진다면? 아고라의 기술적 문제는 바로 여기에서 시작합니다.

아고라 토론방, 끝없는 쓰기의 행진!
 일반적으로 웹 서비스가 부하가 걸리더라도 처리가 되도록 데이터를 저장하는 DB 서버와 이를 읽어와 서비스하는 웹 서버를 분산합니다. 또한, 사용자들은 로드 밸런서라는 장비를 통해 접속 시 마다 분산된 여러 웹 서버에서 정보를 받아 오는 구조입니다. 이렇게 해서 기본적으로 웹 서버가 하나 죽더라도 다른 웹서버에서 서비스를 받을 수 있게 됩니다.

DB 서버도 비슷한 방법으로 기능에 따라 분산되어 있습니다. 마스터(Master) DB서버는 웹 서버로 부터 오는 요청 중 주로 쓰거나(Insert) 갱신(Update) 및 삭제(Delete)하는 기능을 맡고 그렇게 변경된 부분은 슬레이브(Slave) DB서버로 빠르게 복사(Replication)해 주어 웹 서버들이 읽어서(Select) 서비스를 합니다. DB 요청 중 일반적으로 읽기가 쓰기,변경,삭제보다 월등이 많기 때문이죠.

사용자 삽입 이미지
하지만 이런 경우라도 쓰기와 갱신이 갑자기 많아지면 마스터 DB서버도 장애를 겪을 수 있기 때문에 각 웹 서버에는 자주 갱신되는 데이터를 모아 두게 됩니다. 예를 들어, 게시판글이 조회될 때마다 올라가는 ‘조회수’나 아고라 청원의 ‘서명자수’, 각 글의 찬성/반대 투표 수 같은 것들이 그것입니다.

사용자들이 액션을 할때 마다 마스터 DB에 +1 혹은 -1을 하게 되면 부하가 상당하기 때문에 이 숫자를 모아뒀다가 한꺼번에 DB 서버에 보내는 ‘캐시’라는 저장소가 별도로 있습니다. 평상시에는 웹 서버 캐시 데이터를 DB에 반영하는 갱신 주기가 매우 빠르고, 마스터 DB의 변경 사항이 슬레이브 DB로 빠르게 옮겨지기 때문에 거의 정확한 결과를 웹 서버로 전달 합니다.

데이터의 정확성보다는 소통의 기능으로
하지만 특수한 임계점 즉 서버 구조의 예외를 넘는 상황이 생기면 사용자 입장에서는 데이터의 교란이 일어나는 것 처럼 보이기 시작합니다. 예를 들어, 특정 시간대에 마스터 DB 부하가 늘어나 각 슬레이브 DB로 합산 데이터 전달이 느려지는 경우 각 웹 서버 사용자는 각기 다른 결과를 보게 됩니다.

즉, 글 조회수나 청원 서명수, 찬/반 투표수 같은 숫자가 줄어드는 것처럽 보입니다. 예를 들어, 트래픽이 집중 될 때 웹 서버가 접속하는 슬레이브 DB에 따라 10~30 정도씩 서명숫자가 감소됩니다.

사용자 삽입 이미지
게다가 아고라 청원에는 잘 모르는 문제점이 하나 있습니다. 바로 서명을 삭제할 수 있는 것인데 이걸 아는 분들도 거의 없습니다. 현실 세상에서는 서명을 하고 다시 와서 지워 달라는 사람이 거의 없지만 아고라에서는 서명 댓글 삭제 버튼을 누르면 서명이 지워집니다.

따라서 -1 정도의 변화는 평상시에도 실시간으로 잘 나타납니다. 의외로 서명 후  삭제하는 사람이 많다고 합니다. 솔직히 많은 분들이 새로 고침을 통한 실시간 캡쳐를 통해 조작 증거를 보여 주셨는데 사실 F5 안눌러 주시는게 아고라 서비스를 도와 주는 길입니다. ㅎㅎ

사용자 삽입 이미지
뿐만 아니라 Daum은 회원 가입 시 주민등록번호를 필수로 받지 않기 때문에 휴대폰 인증만으로도 여러개의 아이디를 만들 수 있습니다. 따라서 1백만개 아이디가 곧 1백만명을 뜻하지는 않습니다. 한 사람이 여러 아이디를 통해 서명이 가능하기 때문이죠. (물론 게시판 본인 확인제 때문에 서명을 하려면 주민 번호를 적어야 하긴 합니다. 우리도 길거리 서명을 할 때 여기서도 하고 저기서도 하고 합니다.)

하지만, 대통령 탄핵 청원이 있기 전 가장 높은 서명을 했던 청원이 20만인것을 감안하면, 130만의 서명이 한 두주 사이에 이루어진 것은 놀랄 만한 일입니다. 특히 4월 26일에 5~6만임을 감안하면 며칠 사이에 백만건의 서명이 이루어 진 것입니다. 이는 숫자가 조금 줄고 늘고를 떠나서 Daum 아고라의 사회적 소통 기능에도 새로운 분수령이 되었다고 생각합니다. 또한, 아고라를 개발하고 서비스하는 Daum 기술진들에게도 새로운 도전이었죠.

짧은 시간내에 수십만개 글들, 수백만번의 조회수, 수천개의 댓글이 달리고 있는 이런 현상은 지금껏 어느 나라 인터넷 역사에서도 유래가 없는 현상들이니까요. Daum 아고라는 유래가 없는 온라인 민주적 소통 시스템의 기술적 도전에 직면해 있습니다.

여러분의 생각

  1. 한동안 글이 없으셔서 어디 멀리 가셨나 했습니다.
    저도 아고라를 보면서 참 답답했는데..
    이런 일이 있었군요. 🙂

  2. 매우 흥미로운 내용이네요. 제가 분산시스템 관련 공부를 하고 있기 때문에요. 주변 외국인 친구들한테도 보여주고 싶은데, 조만간 영어 버전으로도 올려주시리라 믿습니다. ^^

  3. 재밌는 내용이네요.
    담아갑니다~

  4. 실제로 노출되는 카운트가 줄 수도 있는 거군여.
    전 사용자분들의 착각이 아닐까 했는데 말이죠.

    단지, 문제가 발생한 여지가 있는 것을 찾아 사고 전에 대처하는 것도 서비스 제공자의 몫이겠지요^^

    이렇게 부하가 2, 3배가 되면 감장 못하는 게 인지상정이기도 하지만요.

    좋은 글 감사하고,
    더 좋고 안정적인 서비스 부탁 드립니다.

  5. 소통의 새로운 도전이라고 해도 무방할 것 같습니다. 기획력에 뒷받침된 뒤늦은 용솟음?

    개발하시는 분들의 새로운 도전에 박수를 보내며 아고라의 번창에 또 한번의 박수를 보냅니다.

  6. 미안하다 오해했다….

  7. 한번 만나뵈면 이 이슈를 물어보려고 했는데, 명확하게 설명해주셨네요…

    이 사실을 널리 알려야겠는데요~

  8. 지금 배우는 전공내용들이 이렇게 설명이 될수 있다는 것이군요. 🙂
    트랙백하여 글 씁니다.
    저는 이쪽으로 공부를 준비하는 대학원진학예정자로서 흥미있는 내용을 알려주셨군요.

  9. 재미있는 사실이군요..

  10. 일본 2ch이 초기에 겪었던 문제와 비슷하군요. 그쪽도 수백만건의 게시물, 몇 분만에 수천건씩 늘어나는 댓글로 골치를 겪은 것 같던데.

    결국 2ch은 한 게시물당 댓글은 1000번까지만 달게 하고, 게시물에 그래픽 파일 등 용량이 나가는 파일은 최소화시키며 오래된 게시물은 압축시켜서 일반 브라우저에서는 보일 수 없게 하는 등의 방법으로 해결한 것 같습니다.

    (그래서 과거 한국의 디씨와 일본의 2ch에 DDoS 공격을 받았을 때에도 2ch은 안 무너졌다죠..)

  11. 저 위에 쓰신 구조도가 정확한 것입니까?
    다음에서 사용하는 시스템 구조도가 어떤 지 모르겠는데
    Oracle 3-node RAC 구성을 가정하면 저런 현상이 발생하지 않는다고 생각합니다.

    그리고 Slave DB라는 것은 DR이나 replication 목적으로 두는 것이지
    commit된 데이터가 다르게 읽힌다면
    구성 자체가 잘못된 것이고

    웬만한 금융권들의 시스템은
    하루에 평균 1~2천만건의 트랜잭션을 처리할 수 있는데
    하루에 5~6만건으로 어려워하는 시스템이라면
    정말 싸구려를 쓴다는 말이지
    기술적인 한계에 부딪힌다고는 볼 수 없네요.

  12. 자세한 것은 별도로 알려 드리겠습니다. 아고라의 현재 lvs cps가 몇천 단위입니다. 트랜잭션에 대해서도 댓글 하나 쓸 때, 또는 추천 버튼 하나 누를 때 count +1에 들어가는 iud 트래픽이 얼마나 될지 한번 고려해 보셨으면 합니다.

  13. 금융권시스템과 비교하기에는 좀… 그쪽에 비하면 싸구려 맞을걸요. 벌어들이는 수익도 중요도도 다르지 않습니까?

의견 쓰기

이름* 이메일* 홈페이지(선택)