smith3015 의 기술 블로그

 미 정보국에서 작성된 파일이라고 떠 도는 이미지이다. 실제로 이런 사람들이 조직에 대단히 많다. 그것도 고위직급에 많이 존재한다. 이글을 추적해보니 보다 세세하게 많은 내용이 있다. 내가 그동안 경험 했던 곳의 관리자는 대부분 이랬다. 아닌 사람을 찾기가 힘들 정도이다. 원문은 이곳에 있다. http://svn.cacert.org/CAcert/CAcert_Inc/Board/oss/OSS_Simple_Sabotage_Manual.pdf 주변에 공작원이 많은가 보다. 자생적 공작원이라고 해야 하나.... 조직이 굴러 가는게 신기할 정도이니....

  예전 레미콘 회사에 다닐 때 일이다. 주로 아파트 공사 현장에 갔었다. 이때만 해도 LH 만 규정대로 진행했었다. 물론 레미콘 회사 입장에서는 일이 많이 힘들었다. 우리끼리 아파트는 LH에 입주해야 한다고 말했었다. 그렇게 규정을 지키고 상식을 지키는 사람들이 그립다. 조직에서 규정과 상식 그리고 양심에 따라 일을 하다보면 미운 털이 박히는거 같다. 그렇게 조금씩 조금씩 조직을 좀 먹어 이제는 커다란 구멍으로 다가오는게 아닌가 싶다. 이제는 규정과 상식을 지키는 사람들이 바보 되는 세상이 되어 버린게 아닌가? 암만 망해가는 나라에도 충신은 열 이상 나온다고 하지 않았던가? 전문가들이 왜 있는가? 그저 직급이 높다고 아무것도 모르면서 업체들이 하는 말을 듣고 진실을 외치는 하위직급 전문가의 말을 외면해서 작금의 사태가 발생한게 아닌가. 그저 안타까울 뿐이다.

하루에 데이터가 약 140만건 정도 쌓이는 서비스 이었다. 처음엔 몽고디비 하나로만 이를 처리하였다. 데이터 쌓이는 것은 잘 쌓였다. 웹 모듈에서 모바일에서 전송하는 데이터를 받아서 몽고디비에 쌓는 로직으로 구성했다. 갑자기 로그 파일 생성에 욕심이 생겨서 이를 추가해보았다. 하지만 서버에 로그 파일 생성하는 부분에서 의외로 오류가 많이 발생하였다. 웹 모듈이 죽는 상태가 많이 발생하였다. crontab 에 웹 모듈 실행여부를 체크하여 프로세스가 죽어 있으면 다시 실행시키는 스크립트를 생성해서 돌렸으나 작동되지 않았다. 스크립트는 복잡한 로직은 작동이 되지 않는거 같았다. 이런 내용을 실행하는 프로그램을 작성해서 돌렸다. 이렇게 몇달 운영하다 보니 매우 비효율적이란 생각이 들었다. 웹 모듈에서 자체 제공하는 로그를 이용하기로 하고 이렇게 구성했더니 로그는 훨씬 원활하게 돌아갔다. 진작에 웹 모듈에서 제공하는 로그를 사용할 껄 그랬다. 몽고디비에서 쌓이는 데이터를 가지고 대시보드를 작성하기 위한 서비스를 개발했다. 이때 문제가 발생했다. 디비에 계속 쌓이는 모듈에 데이터를 검색할 때마다 부하를 주어서 데이터 누락이 발생했다. 몽고디비 자체가 성능을 위해서 데이터 정합성을 포기하도록 설계되었다는 것이다. 문제를 해결하기 위해서는 상태 모니터링용은 관계형 데이터베이스를 사용하기로 했다. 마이에스큐엘을 설치하고 웹 모듈에서 상태 모니터링용 데이터는 마이에스큐엘에 저장하도록 분기 하였다. 대시보드용 서비스는 마이에스큐엘에서 데이터를 가져와 보여주었다. 오래된 데이터에서 이력을 보는데는 몽고디비에서 바로 검색해도 성능 저하는 없었다. 컬렉션을 날짜별로 저장되도록 구성하였는데 현재 저장되는 컬렉션에서 검색을 할 경우 성능저하가 발생하였다. 현재 저장되고 있는 않는 어제나 지난 날의 컬렉션의 자룔 검색하면 성능저하는 발생되지 않았다. 결국 데이터베이스는 두개로 운영되었다. 관계형 데이터베이스는 현황용 데이터를 저장하고  몽고디비는 저장용 데이터를 저장하도록 설계하였다. 이런

 서버 한대에서 서비스를 하고자 할 때 보통 최대한 능력으로 사용하지 않는다. 이런 서버를 여러대 운영하다 보면 비효율적이란 생각이 든다. X86 서버 한대에 웹서비스를 운영한 경험이 있다. 1초에 한번씩 API를 호출하는 안드로이드 앱이 6천대 정도가 실행되는 환경이었다. 서버는 단 한대...., 보안 때문에 비용 때문에 각각의 이유로.... 그러한 서비스를 받아줄 서버는 X86 서버 한대 뿐이었다. 일단 API 서비스를 만들었다. 경량웹서비스인 Perfect 웹 프레임워크를 이용해서 만들었다. 스위프트 언어를 사용할 수 있어서 고차함수를 사용하면 아무래도 서비스를 좀 더 효율적으로 만들 수 있는 장점이 있다. 그리고 아이폰 개발자에게 좀 더 쉽게 다가갈 수 있었다. 또한 많이 사용하는 프레임워크가 아니라 보안에 우수한 장점이 있다. 웹서비스를 포트로 여러개를 만들어서 컴파일 했다. web_perfect_8100, web_perfect_8101,.... 이런 식으로... 필요한 서비스를 확장시켰다. 그리고 서버에 haproxy 를 설치했다. 외부에서 접속하는 것은 443 포트만 열었으며 나머지는 닫았다. haproxy 설정에서 각 서비스를 체크해서 분기하도록 설정했다. 서버의 상태를 보면서 이 서비스를 확장시켰다. 최대한 사용하도록 했더니 한대로 서비스를 해도 충분했다. 6천대가 사용하는데 동시접속은 거의 1천대 정도 되었으며 세션은 항상 10만개 정도 붙어 있었다. 그 이상 더 늘릴 수 있는데 못한 것은 데이터베이스 서버가 그 이상을 늘렸을 경우 응답속도가 급격히 저하되었다. 다음에 시간이 되면 데이터베이스 최적화한 경험을 이야기 해볼까 한다.

아이폰 및 안드로이드 앱을 개발하여 앱스토어와 구글 플레이이에 업로드 하였다. 문제는 다운로드 수가 거의 없는 것이다. 앱을 양쪽 다 만드는데도 많은 우여곡절이 있었지만 서버와 데이터베이스까지 모두 하느라 진이 다 빠졌다. 이제는 마케팅이 문제인데..... 구글 애드를 사용해서 앱 다운로드 수를 늘려보고자 하였다. 일단 10만원만 해 보았다. 약 170여개가 깔린다고 구글 애드에 나온다. 앱을 설치하면 디비에 기록되게 하였다. 대부분이 설치만 하고 실행을 하지 않는거 같다. 설치도 디비 기준으로는 약 100개 정도로 서로 상이 하였다. 어찌 되었건 구글 플레이에서 다운로드 수와 별이 적으면 아예 설치 자체를 하지 않는다. 별점이 적은 앱은 버리고 새로운 앱으로 등록하여 다시 별점을 지인 찬스를 통해서 5개에서 시작하였다. 광고 금액 조달이 문제다. 보통 만개 이상이 되어야 주목을 받는데 그럴려면 적어도 천만원 정도의 광고비용을 지불해야 할꺼 같다.