[오픈스택 데이 발표자료] 클라우드 시대의 모니터닝및 성능 이야기

지난 오픈스택 데이 2017에 클라우드 시대의 모니터링및 성능 이야기 라는 주제로 와탭의 손영수님이 발표를 해주셨습니다.   많은 분이 자료를 요청해주셔서 공유를 해 드립니다.

와탭은 현재 15000대의 서버와  500개의 어플리케이션을  모니터링 하고 있으며,  국내 최조로 SaaS형 모니터링 솔루션을 개발해, 장애및 성능에 대한 많은 경험치를 가지고 있습니다.  와탭 팀원들의 여러  경험을 담아 만든 자료라고 보시면 됩니다.

직접 모니터링 솔루션을 구축하실때 어떠한 부분들을 고려하셔야 되는지 와탭의 고민과 경험들을 공유드립니다!

직접 구축하는 비용및 유지 보수 비용을 생각하신다면, 이러한 철학들이 반영된 와탭의 인프라스트럭쳐 모니터링과 어플리케이션 모니터링을  사용하시는게 좋겠죠.

Whatap APM 출시를 앞두며.. (제품의 철학 만들기 그리고 그 결과물)

SaaS형 실시간 APM (Application Performance  Management)  제품을 팔기 위해서 우리는 무엇을 해야 할까?  제품 기획시  김성조님(와탭 CTO / Scouter 리드 커미터 / 전 제니퍼 소프트 CTO) 과  대화중  크게 와 닿는 말이 있었습니다.

  • 고객에게는 제품의 철학을 파는 것이다.
  • 성능 개선에 관한 제품을 구입하는   고객의 입장에서 극단적으로 생각하면 “성능 분석에 대해서 잘 모르니, 내가 무엇부터 고치면 되는지 말해줘”   이다.  우리가 해답을 주어야 되는 솔루션이지 니가 알아서 판단해라고 여러 지표로 잔뜩 현상만 알려주는 것은  좋은 제품은 아니다.

철학이라는 말을 제목에 적었지만, 사실 제품이 존재하는 근본 이유에 대한 명쾌한 해답을 줄수 없다면 그건 좋은 소프트웨어가 아닙니다.

시장의 선두주자들이 가진 철학들.  

그림 1. App Dynamics (좌) vs New Relic (우)의 대시보드 화면

 

그림1 에서 보신것 처럼  SaaS형 APM 1위 업체인 New Relic (오른쪽 화면) 은 개별 서버 한대의 문제를 집중해서 보는 문제 해결 중심의 철학을 제공하고 있습니다. 2위 업체인   AppDynamics (왼쪽 화면)는 거대한 클라우드에서 전체를 조망하면서 개발 문제를 보는 철학을 제공하고 있습니다.

좀더 상세한 비교는  App Dynamics vs New Relic – Which Tool is Right For You?  를 참고해주세요.

시장은 누구의 손을 들어주었을까요?  결과적으로  New Relic이  SaaS형 기반  APM에서 매출/규모 면에서 1위의 자리를 지키고 있습니다. APM 은 (클라우드적인 관제의 관점 보다는 )문제를 해결이 가장 중요한 기본 철학이라는 것을  확인 시켜주는 데이터라고 생각하시면 됩니다.

New Relic 이 엄청난 격차로 매출을 이끌어 올리자, App Dynamics는 문제 해결 위주의 뷰를  적극적으로 수용해,  다시 격차를 줄이고 있습니다. New Relic역시 전체를 조망하지는 않지만 주위  Instance와 연관성을 보여주는 뷰를 제공하면서, 서로의 장점을 조금씩 흡수하고 있습니다.

결국 현재 1,2위 업체들이  서로의 장점을 흡수 하면서  닮아 가고 있지만, 결국 초기 제품의 핵심 가치및 철학이  무엇이냐가 지금의 격차를 가져왔다고 판단이 됩니다. 그만큼 철학이라는 것이 중요합니다.

Whatap APM 출시를 앞두며.. (제품의 철학 만들기 그리고 그 결과물) 더보기

Apple 개발자 계정 등록하기

Apple App Store 에 앱을 개발하여 올리기 위해서는, Apple 개발자 계정을 등록 하여여 합니다.

https://developer.apple.com

에서 개발자 계정을 만들수 있습니다.

capture-20160425-223911

현재는 6월에 예정된 Apple Worldwide Developers Conference (WWDC) 2016 안내를 해서, 평소와는 다소 다른 디자인으로 웹사이트에 보여지고 있습니다.

Apple 개발자 계정 등록하기 더보기

아마존 클라우드워치 로그 분석기능을 이용한 웹 서비스/워드 프레스 성능 모니터링/분석

아마존 EC2에서 소규모 혹은 대규모로 웹 서비스를 운영하게되면 필연적으로 다량의 웹 로그가 발생하게 됩니다. 이 로그에는 해당 서비스의 성능에 관한 가장 정확한 자료가 존재하지만 이것을 분석하는데는 생각보다 많은 시간과 비용이 발생합니다.

특히 대량으로 발생하는 데이터를 실시간으로 분석하려면 scale-out 가능한 로그 분석 툴을 갖추어야 되는데요. 컨텐츠나 기능개발에 바쁜 중소규모 개발팀에서 감당하기에는 많은 어려움이 있습니다.

전문 솔루션을 도입하는 결정을 내리기 전에 아마존 클라우드 워치의 로그 기능을 이용한 간단한 로그 분석에 대해 적어 보도록 하겠습니다.

1. 아마존 클라우드 워치 로그기능이란

로그 파일이 발생하는 모든 시스템이나 어플리케이션을 모니터링 하거나 장애 원인 분석하는데 활용할 수 있는 가입형 아마존 웹서비스 입니다. 수집한 로그는 원하는 만큼 유지할 수 있고 필터를 통해 대용량 데이터 분석 플랫폼인 아마존 kinesis 에 스트리밍 할 수 도 있습니다. 클라우드형 서비스이기 때문에 용량산정에 대한 큰 고민 없이 즉시 적용할 수 있다는 점이 가장 큰 장점이라고 생각합니다.

2. Amazon Linux 를 선택하여 VM을 생성

IAM 서비스에 접속하여 CloudWatch Log서비스에 업로드 할 수 있는 policy를 만듭니다.

https://console.aws.amazon.com/iam/home

Policies -> 상단의 Create Policy -> Create Your Own Policy -> Form 에 아래와 같이 입력

생성한 Policy 를 붙일 Role 생성

Roles -> 상단의 Create New Role -> Role Name 입력 -> 아무거나 선택 -> 위에서 생성한 policy 선택

EC2 서비스를 접속하여 Amazon Linux VM을 생성

https://console.aws.amazon.com/ec2/v2/home

EC2 Dashboard -> 중단의 Launch Instance -> Amazon Linux AMI 선택 -> Next: Configure Instance Details -> 중단 IAM role에 위에서 생성한 role을 선택 -> 우측 하단 Review and Launch -> 우측 하단 Launch -> ssh 키 선택 혹은 생성 -> Launch Instance

3. 워드프레스 설치

생성한 VM에 접속하여 워드프레스를 설치합니다.

해당 VM의 웹 주소로 접속하여 설치를 마무리 합니다. http://{public ip of vm}/wordpress

4. Cloudwatch Log Agent 설치 및 실행

이제 Cloudwatch Log Agent를 설치할 차례입니다.

5. 로그 수집 확인 및 필터 생성

아마존 클라우드 워치에 접속하여 로그가 수집되는지 확인합니다.

https://console.aws.amazon.com/cloudwatch/home

Logs -> 목록에서 4번 /etc/awslogs/awslogs.conf 에서 입력한 로그 그룹 이름을 클릭 -> 서버 이름 클릭 -> 수집된 로그 확인

20150910_AWS-CloudWatch-LogViewer

 

시간당 접속 카운트 Metric 입력

Logs -> 로그 그룹 이름 앞으 체크박스 선택 -> Create Metric Filter -> Filter Pattern 을 비워두고 Assign Metric -> 아래와 같이 폼 입력 -> Create Filter

시간당 다운로드 카운트 Metric 입력

Logs -> 로그 그룹 이름 앞으 체크박스 선택 -> Create Metric Filter -> Filter Pattern 을 [ip, id, user, timestamp, request, status_code, size, referer, agent ] -> Assign Metric -> 아래와 같이 폼 입력 -> Create Filter

6. 로그 파일에서 생성된 챠트 확인

시간당 접속수 확인

Logs -> 2 filter -> LogMetrics -> EventCount 선택 -> 챠트확인

시간당 다운로드 트래픽 확인

Logs -> 2 filter -> LogMetrics -> BytesTransferred 선택 -> 챠트확인

20150910_AWS-CloudWatch-BytesTransferred

마치면서

이렇게 하면 전문 툴을 도입하지 않고 간단하게 모니터링을 할 수 있습니다. 다만 전문 툴에서 제공하는 다양한 그룹 기능을 구현하자면 계속적인 학습이 필요합니다. 필자는 Amazon S3에서 발생하는 access log 를 클라우드 워치 로그에 업로드 하여 분석을 시도해 보았습니다. S3의 access 로그를 읽어서 업로드하는 간단한 코드만 있으면 가능하지만 해당 코드를 실행할 VM이 필요하여 비용발생면에서 불리하다고 판단 하였습니다.

AWS를 배우면서 항상 많은 기능들을 내 서비스에 즉시 적용할 수 있을것 같아 좋습니다. 개발자 감성으로 즐겁게 배우고 있습니다. 하지만 실제 업무 에서는 전문 솔루션의 기능과 비교하고 AWS에서 어떻게 구현할지 고민해야 된다는 점이 부담으로 느껴집니다. 여기에 적응하자면 업무를 AWS에 맞추거나 자체 솔루션을 도입하거나 해야 하겠지요.

CloudWatch Log기능을 사용해서 EC2에서 운영하는 웹서비스를 모니터링 하고 챠트를 즉시 볼 수 있어서 좋았습니다. AWS개발팀이 로그 필터 Metric을 다양하게 개발해서 원하는 통계정보를 DevOps들이 더 쉽게 볼 수 있게 되기를 기원합니다.

리눅스 명령어를 이용한 시스템 모니터링 하기

블로그를 이전하는 작업을 진행중입니다.
현재 해당하는 컨텐츠는 https://www.whatap.io/blog/10/ 로 이동하여 새롭게 다듬어져 있습니다.

와탭 블로그를 이용해주셔서 감사합니다.
앞으로도 유용한 컨텐츠를 제공하겠습니다.