소셜로그인 중단 안내

계정으로 로그인 기능이 2023년 11월 16일 중단되었습니다.

아이보스 계정이 사라지는 것은 절대 아니며, 계정의 이메일 주소를 이용해 로그인 하실 수 있습니다.

▶️ 자세한 공지사항 확인

네이버 시스템은 왜 일관적인 결과를 보여주지 않는 것처럼 느껴질까?

2015.09.01 19:23

큰곰

조회수 3,757

댓글 6

나는 개인이고 아직 최초의 저품질 블로그 포함 이제 5개로 여러가지 테스트 중이기 때문에 많은 현상들을 직접 겪지는 않았지만 대신 블로그를 다수 운영하시는 분들의 리포트를 보면 다음과 같은 해석이 흔히 있는 것으로 받아들여진다.

 

비슷한 환경에서 포스팅해도 블로그마다 반영되는 게 다르고 키워드마다 다르다...그런데 몇 시간이나 몇 일 지나면 또 문제가 있던 블로그들도 다 해결되어 있으므로 그것은 내 문제가 아니란 증거이니 결국은 네이버 오류고...서버롤백이다... 

 

 

젊었을 때 잠시 ISP에 있기도 했지만 소규모였기 때문에 한 국가를 상대로 한 초대형 서비스인 네이버를 멋대로 상상한다는 건 좀 무리가 있겠으나 뭐 어쨌든 가려서들 읽으시겠지...

 

1. 대형시스템에 대한 큰 그림

 

최전방에서 접속을 받는 시스템으로부터 실제 데이타를 갖고 있는 시스템까지의 경로가 적어도 3단계 이상이며 내부 시스템은 인터넷에서 관찰이 불가능할 수도 있고 수십대에서 수백대가 된다.

네이버 같은 경우 우리가 포스팅시 올리는 이미지들을 받는 서버가 postfiles16.naver.net 과 같이 외부에서 관찰가능한 호스트명만 16개이며 이 하나하나당 IP가 3개인 것으로 봐서 아마도 2개는 백업/로드발랜싱으로 돌아갈 것인데 이조차도 실제 postfiles16 호스트가 이미지저장의 마지막 시스템인지 아니면 그 안에 또 있는지 알 수 없다.

 

2. 그게 뭐 어쨌다고? 온라인 게임에만 들어가도 서버가 20~30대씩 된다. 

 

시스템을 15년 쯤 운영하면 중간에 개편을 하고 통합을 해도 모든 서버들이 조금씩 다 다르다.

예를 들어 리눅스 커널 2.6으로 쇼핑물을 운영하다가 너무 오래되었다고 커널 4.2로 시스템을 갈아엎는 일? 관리자들이 싫어하는 일이며 아무리 잘 해도 뜻하지 않은 오류, 삽질을 겪을 수 밖에 없는 작업이 된다. 시스템 하나만 바꾸면 되는 쇼핑몰도 이런데 대형시스템들은 한 번 구축하면 그걸 통째로 바꾼다는 건 거의 없는 일이다.

이를 윈도우식으로 표현하면

윈도우 98로 돌아가는 서버도 있고,NT도 있고 7도 있고 8도 있는데 윈도우 98로 만들어진 시스템이 현재 서비스하는데 해결할 수 없는 문제가 발생하지 않는 한 PC처럼 운영체제를 쉽게 바꾸지 않는다는 점이다. 즉 해결할 수 있는 문제는 모두 땜빵땜빵땜빵...으로 버팀.

 

3. 많은 시스템들이 따로 논다. 

 

이전에 말한 키워드DB(물론 내 글에서 이런 용어들은 내 멋대로 붙인 것이다)를 예로 들면

일반적으로 쓰는 오라클이나 MySQL, MS-SQL 같은 것들을 소규모로 운영하면 한 시스템에 그냥 RAID로 디스크가 붙어 있고 서버 프로세서가 돌아가면서 웹서버나 로그인서버의 질의를 받아 디스크를 검색해 응답을 돌려주는 구조가 된다.

그런데 이게 대형 시스템이 되면 설계하는 방식에 따라 다르지만 멋대로 지껄여보면(네이버 같은 데는 범용DB가 아닐 것이지만) 

가 ~ 기 ▶ 1번 서버

나 ~ 니 ▶ 2번 서버  

다 ~ 디 ▶ 3번 서버............

로 시스템이 분산되어 있다.

가정/고민/구속 등의 키워드들은 1번에 테이블이 있고  놀이/나눔/누나 등은 2번에 있고....

이렇게 되면 시스템간, 키워드간의 부하가 전부 다르다. 인기 키워드에 대해서는 중간에 조절하기도 하지만 그렇다해도 트렌드나 어떤 사건으로 키워드간 트래픽 차이가 일시적으로 심한 것을 일일이 조절하는 것은 사실 삽질이므로 설계가 잘 바뀌지는 않는다.

이 경우 블로거의 포스팅을 받은 임시서버에서 본문을 키워드별로 낱낱이 뜯어 해당 키워드가 있는 서버의 테이블에 1줄씩 추가해야 작업이 완료되는데 '가을' 이라는 키워드테이블을 업데이트하고자 시스템부하를 측정하니 1번서버가 로드 80%다...그럼 작업을 정지하느냐?

물론 정지할 수도 있는데 정지하면 놀게 되고, 놀게 되면 유저는 계속 포스팅을 해대고... 서버에 해야할 리스트는 계속 누적되면 결국 나중에 문제가 커지니 '가을' 만 건너뛸 수도 있다는 말이다.

이 경우 외부에서 우리가 관찰하면 다른 놈은 잘 되는데 '가을' 이라는 키워드를 검색으로 잡았을 때만 정확도에서 누락이 발생한다. 따라서 가을로 검색을 하지 않은 사람은 아무 문제를 발견하지 못함.

 

이는 하나의 예일 뿐 DB 설계에 따라 완전히 다른 구성이 될 수 있다.

 

4. 여러 경우에 임시값을 제출할 수 있다.

 

위의 경우 1번 서버 업데이트가 보류된 상태이며 보류된 것은 서버 부하가 일정 수준으로 떨어지면 다시 재시도를 한다.

그런데 이미 업데이트 된 상태에서 응답이 늦을 경우도 있다.

그럴 때 사용자 화면에 모래시계를 띄운다? 물론 소형 사이트면 그래도 된다. 하지만 네이버 정도 되면 말이 안 되니까 1번 서버의 부하가 80%일 때 누군가 '기차' 로 검색을 하면 1번 서버에는 물어보지도 않고 메모리에 있는(캐싱값) 기존 검색결과를 그대로 리턴해버리는 구현도 있다.

=========== 09/08 추가 ==========

이 경우 캐싱값이 없으면  

'검색결과가 없습니다 어쩌구~'

와 같은 황당한 출력이 나오게 된다.

캐싱값이 없다는 것은 메모리값이 없다는 말로 기차로 최근 아무도 검색하지 않았거나 아니면 누군가 검색은 했지만 그 값이 유효기간이 지났다는 의미.

이 경우 언뜻 검색결과가 없다는 황당한 답변은 중대한 네이버오류처럼 생각될 수 있으나 내가 설계자라도 시스템부하가 심한 서버에 질의하는 것보다는 그냥 이걸 제출하겠다. 역시 '기차' 를 검색한 그 사람에게만 한정되는 일시적인 것이니까. 다른 사람은 전혀 네이버를 이용하는데 문제가 없으니까.

============================== 

서버 부하가 80%인 놈에 대고 자꾸 질의를 날려봤자 부하만 증가하지 쥐어짠다고 나오는 게 기계가 아니니까. 이 때 외부에서 관찰하면 3번과 동일하게 '기차' 로 올린 최근 글이 검색되지 않는 문제가 발견된다. 하지만 모래시계를 띄우거나 "죄송합니다 사용자가 많습니다. 잠시 후 다시 검색해 주십시요~" 보다는 이게 낫다. 기차로 최근 글을 올린 사람 이외에는 전혀 문제없이 서비스이용이 가능하기 때문.

 

5. 이는 검색결과의 일시적인 오류로 보일 때도 있다.

 

예를 들어 '기차' 같은 단일 키워드는 1번 서버의 테이블에서 최신순이라면 맨 아래부터, 정확도 순이라면 지수순으로 출력하면 되고 업데이트가 지연되었건 메모리값이든 일단 제출되는 값은 순서가 엉키지 않지만

'기차 + '여행' 의 경우 1번 서버와 8번서버의 테이블 조인이 일어나야 한다.

이 때 8번 서버는 정상동작 중이고 여행으로 신규 등록한 리스트도 많고 그 중 지수가 높은 놈도 많다....그럴 경우 1번이 정상동작하기 전과 후의 검색결과가 많이 달라질 수 있다. 새로운 경쟁자가 등장하기 전과 후의 순위변화라고 표현할까...

 

6. 외부에서 이런 현상들의 원인을 파악하는 건 어렵다. 

 

어렵기 때문에 시스템오류다 점검이다 업데이트다 심지어 서버롤백이다...라는 이야기를 하게 된다.

평소에 짜집기 문서를 발행하던 사람은 혹시 이게 뭔 로직을 건드렸나? VPN을 사용하던 사람은 혹시 IP가 오염되었나? 광고를 올리던 사람은 혹시 이 키워드가 수검인가?...

하는 불안감에 몇 시간 안절부절하다가 자기 게시물을 삭제하거나 비공처리하거나 수정하거나...삽질 시작.

이런 삽질을 하지 않으려면 단답보다는 원리를 알아야 한다. 뭐 그렇다는 얘기.

 

7. 시스템적으로 완벽하게 일관적인 응답을 하는 것은 네이버도 불가능하고 구글도 불가능하다.

 

뭐 100명이 이용하는 서비스에 1000명을 서비스할 수 있는 시스템자원,인력,돈을 투입하면 가능하다.

그러나 그런 장사는 망하기 마련이기 때문에 불가능하다.

 

8. 우리가 힌트로 삼을 수 있는 것도 있다.

 

  • 시스템부하를 증가시키는 포스팅도 마이너스 맞을 수 있다. 그 대표적인 게 이미지과다 동영상과다 잦은 수정. 그리고 일반적으로 알려진 어뷰징 + 광고수익에 도움이 되지 않는 트래픽
    이를 프로그램이 자동으로 지수를 매길 때, 비록 당신 컨텐츠가 독보적인 것이라 하더라도 마이너스를 피하기 어렵다.
  • 시스템을 가볍게 만들기 위한 쓰레기처리 로직이 있을 수 있다. 유저 데이타를 함부로 지울 수는 없으니까 뭔 짓을 하건 마이너스를 때려 서비스 탈퇴를 유도하는 로직...탈퇴하면 쓰레기는 지울 수 있으니까.
  • 위의 연장선에서 ID 로직이 더 빡빡해질 수 있다. 마이너스 때려서 탈퇴시키는 걸로는 부족하므로 ID 생성에 먼저 시비를 거는 경우. 이 부분에 문제가 있다는 걸 발견하면 네이버가 임의로 쓰레기처리를 할 수 있는 좋은 방편이기 때문.
  • 시중에 나와 있는 오토 감지로직의 강화. 이를 서비스방해로 규정해 멋대로 쓰레기처리할 수 있다.

 

9. 네이버가 내실에 치중할수록 8번은 더 빡세게 적용된다.

 

독자적인 ISP, 220Gbps 가 넘는 전용망, 점유율 70%,,, 이 좁은 나라를 대상으로 하는 서비스에서 시스템을 더 늘이고 인터넷선을 더 깔 수 있을까? 그런다고 수익이 더 늘어날까?

이제 내부의 쓰레기를 청소하는 게 더 중요하지 않을까...

 

 

 

 

블로그마케팅

스크랩

공유하기

신고

하트 아이콘매크모님 외 5명이 좋아합니다.

목록글쓰기
댓글 6
댓글 새로고침
로그인 후 더욱 많은 기능을 이용하세요!아이보스 로그인