해당 블로그는 KT UCloud의 지원을 받고 있습니다.
해당 글은 http://amix.dk/blog/post/19709 글을 발번역 한 것입니다. 안정적인 웹서비스를 만들려면 어떻게 해야할까요? 저에게 물어보시면, 기능, 성능, 안정성 이렇게 크게 3가지 팩터에서 접근을 해야하지 않을까 라고 생각합니다.
- 기능은 일단 기본적인 부분입니다. 이게 없으면 아예 서비스가 안됩니다.
- 성능은 아무리 기능이 좋아도 필요한 속도 이하가 나오기 시작하면, 외면 받을 수 밖에 없습니다.
- 안정성이 없다면, 역시 서비스는 외면 받게 됩니다. 페이스북이나 트위터가 매일 23시간 정도 장애가 난다면 누가 사용할까요?
그런데 이 모든 것을 아울르는게 “모니터링” 입니다. 기능이 정상적인지, 성능은 적당한지, 서비스가 다운되지는 않았는지? 이 모든 것이 모니터링 하고 연결이 됩니다. 그래서 대규모 서비스에서 사실 가장 중요한 것은 첫번째도 모니터링, 둘째도 모니터링, 셋째도 모니터링입니다. 필자의 의견도 저랑 비슷한거 같습니다. 그럼 오역에 주의하세요.
1년이 넘는 동안, 안정적인 웹 서비스를 개발하는 것에 대해서 많이 배우고 있습니다. 스타트업 부터 시작해서 수 십억의 페이지 뷰와 수백만의 사용자들로 확장되는 것도 경험했습니다. 어떤 언어든 어떤 웹사이트 간에 적용할 수 있는 몇 가지 팁을 공유할려고 합니다.
The general strategy
확장 가능하고 안정적인 서비스는 다음과 같은 내용으로 압축할 수 있습니다.
- 모니터링이 전부다!: 지금 무엇이 진행중인지 알 수 있는 명확한 뷰를 가져야 합니다. 과거의 성능은 어떠했는지?, 에러 로그, 어플리케이션의 키 매트릭스에 대한 로그, 네트웍 내의 모든 장비에 대한 시각화된 뷰를 가지고, 응답 시간에 대한 시각화된 뷰 등을 가지게 됩니다. Google Analytics 는 부족합니다. 좀 더 강력한 툴이 필요합니다.
- 능동적이 되어라!: 미래의 부하에 대한 예측과 백업은 더 능동적으로 해야 합니다. 만약 현재의 부하가 가용 성능의 최대치에 근접하면, 최적화를 하기 전에 웹사이트가 다운될 수 있습니다. 시스템에 대한 모든 것을 알아야 하고, 시스템이 얼마나 많은 사용자를 처리할 수 있는지에 대해서 어느 정도 지식을 가지고 추측한 값을 가지고 있어야 합니다. 만약 10배, 100배, 1000배로 현재 노드가 늘어나길 원한다면 어떤 전략이 필요할 지에 대해서 고민해야 합니다.(역자 주: 개인적으로 10배, 100배, 1000배 늘어나면, 해당 구조가 많이 바껴야 하기 때문에, 처음부터 이런 걸 고려한 설계를 하라는 아니고, 계속 계속 고민하고 있어라는 뜻 같습니다. 왜냐하면 초창기에 그 정도로 서비스르 구축하는 건 오버엔지니어링일 가능성이 높습니다.) Proactive vs. Reactive scaling 를 살펴보세요.
- 장애가 생겼을 때 통지를 받을 수 있게 하라.: Pingdom 이나 오픈 소스 라이브러리 crash_hound 를 이용한 SMS 통지를 받는 것은 쉽습니다.
The tools that you can use
제 도구 상자에는 제가 많이 사용하는 도구들이 있고, 강력하게 그것들을 추천합니다. 필요하지 않다면, 바퀴를 다시 발명할 필요는 없습니다.
Realtime monitoring of anything
Keeping Instagram up with over a million new users in twelve hours 라는 글에서 statsd 와 Graphite 에 대한 글을 읽었습니다.
그 글을 읽은 후에, statsd 와 Graphite 의 사용에 관심을 가지게 되고, 운영해보곤 했습니다. Graphite는 조금 셋업하기 복잡하지만, 투자하면 좋은 결과를 주고, 그건 내 삶을 바꿔버렸어라고 말 할 수 있습니다. 설치를 하면실시간으로 어떠한 성능 감소 없이(statsd 가 non-blocking UDP 연결을 사용하긴 하지만) 실시간으로 모든 것을 감시할 수 있습니다. 평균 응답 시간을 모니터링 하고, 에러 수와, 가입자 수, sync 명령의 수, 프로세스의 평균 응답 시간, sync 명령, 기타 등등을 서버들과 서비스들을 넘어서 모니터링 했습니다.
여러 프로세스를 배포해야할 때 해당 툴은 특별히 유용합니다. 마지막 배포에 에러가 발생하거나, 성능 이슈가 있는지 재빠릴 확인할 수 있습니다.
아래에 Graphite 대시보드 중의 하나가 있습니다.
Monitor performance and get notified when something crashes
Pingdom 은 여러 서비스로 부터 성능을 모니터링하는 꽤 유용한 툴입니다. 또한 서비스 장애시에 SMS 를 통해서 통지해 줄 수 있습니다. Pingdom은 공개이고, 유저의 서비스 지속시간과 성능을 측정할 수 있습니다.( 유저들을 위해서 매우 유용한 )
프로그램에서 통지를 할 때, 좀 더 강력한 기능을 위해서 crash_hound 를 사용합니다. 예를 들어, Worker queue가 처리 되지 않는다는 SMS를 받았을 때, 통지의 대부분은 10라인 이하의 작은 스크립트를 이용하여 구성됩니다.
Pingdom 모니터링 페이지 중의 하나는 다음과 같습니다.
Log every error
모든 에러 로그를 모으고, 한 군데서 보여주는 central logger 가 있습니다. 요청 환경에서 볼 수 있는 모든 에러를 보여주고, 에러와 버그들은 훨씬 쉽게 모니터링 할 수 있으므로, 어떤 웹 서비스에서도 반드시 가져야 하는 툴입니다.
central logger는 다음과 같이 생겼습니다.
이것을 잘 해주는 몇몇 오픈소스가 있을 꺼라고 확신합니다.( 그러나 우리가 필요한 것과 정혹하게 일치하는 것을 찾지 못해서, 우리는 그냥 스스로 구현했습니다. )
SQL and request logger
쿼리를 모으고, 누가 대부분의 시간을 사용하고, 누가 가장 비싼지 보여주는 SQL logger가 있습니다. 또한 요청에 대해 같은 정보를 보여주는 request logger 도 있습니다.
이 두 도구는 코드에서 어디를 최적화 해야하는지를 알고 싶을 때 매우 유용합니다.
이미 request logger 를 얼마전에 오픈 소스화 하였습니다.( 매우 간다하고 조금 독창적입니다.!)
아래에 스크린 샷이 있습니다.
Monitor your servers
AWS에서 좋은 모니터링 툴을 많이 제공하기 때문에(CPU 사용량, 필요한 리소스보다 더 사용하기 시작한 경우의 경고라든지), Amazon AWS 에서 호스팅 하는 것은 장점이 있습니다.
또한, 이용가능한 몇몇 오픈 소스들이 있습니다. Plurk에서는 Cacti 와 Nagios 를 사용하고 있습니다. Cacti 와 Nagios는 복잡하지만, 강력한 도구들입니다. 그러나 확실히 운영하는 서버와 서비스들에 대한 더 좋은 뷰를 제공해주기 때문에 시간을 투자할 가치가 있습니다.
여기에 Amazon 모니터링 툴에서 보여주는 몇가지 기능이 있습니다.
팁이 유용하기를 바랍니다. 근래에 SQL monitor 라든지 central logger 등의 툴박스를 오픈 소스로 공개하려고 합니다.
항상 튜닝할려고 노력하시기 바랍니다. 해피 해킹!
Charsyam's Blog 