몬스터 스트라이크’(http://kr.monster-strike.com/ )는 일본의 모바일 게임으로 퍼즐 앤 드래곤을 밀어낸 초 히트 게임이다.

 

서버 OS:                     Ubuntu Server

데이터베이스:               MariaDB

캐시서버:                     memcached

Web 애플리케이션 서버:  Nginx, Unicorn

메시지 큐잉 서버:          Resque

 

개발 언어:                    Ruby

프레임워크:                  Padrino

소스 코드 관리             GitHub

CI:                             Jenkins

가상 환경 구축:             Vagrant

커뮤니케이션:                Slack

 

운용 상황 가시화:          CloudForecast, GrowthForecast

운용 감시, 이상 감지:      Nagios, PagerDuty

로그 관리:                    fluentd, Elasticsearch, Kibana, Norikra

배포:                          Capistrano

 


출처: https://twitter.com/nacl/status/735324653950996480

 

저작자 표시
신고
by 흥배 2016.06.17 08:00

관련 영상: https://www.youtube.com/watch?v=jQNCuD_hxdQ

 

Pinterest Marty Weiner goto; conference 2014의 강연.

 

"web 사이트 어떻게 만들어 왔나?"라는 창업기부터 현재에 이르기까지 단계적으로 테크놀로지 스택이 어떻게 진화했는지

현재의 Pinterest 시스템 아키텍처의 전체 모습.

개별 기술의 선택 이유.

등을 말한 45분짜리 비디오로 goto;conference 사이트에서 슬라이드 PDF 다운로드(첫날의 10:20 ) 할 수 있으니 그쪽을 봐도 좋다

 

"사이트가 다운되면서 어떤 의미로 자연스럽게 배우게 되었다"라고 하는데, "이를 들어주는 여러분이 자신들과 같은 실패를 하지 않기 위해서"라는 것이 Marty가 전해 주고 싶은 포인트.

 

 

테크놀로지를 선택할 때 자문해야 할 것은

1. 자신들의 욕구를 충족하고 있나?

 

2. 그 기술은 성숙해 있는가?

"성숙(피와 땀이 쏠린 볼륨÷복잡함"이다. , 개발에 수많은 시간이 소비된 테크놀로지도 그 진화에 따른 복잡성이 해소해 나가지 않으면 "성숙" 이라고 할 수 없다. MongoDB가 유행하고 있어서 손을 내밀어 많은 사람이 대응했으나(자신들에게 있어서 복잡성이 해소되지 않고, 잘 다룰 수 있지 않아서)우리에게는 실패였다.

 

3. 일반적으로 많이 쓰이고 있는 것? 그 기술 경험자를 고용할 수 있는가?

예를 들어 MySQL의 경험자라면 Palo Alto의 거리에서 큰 소리로 부르면 주위에 굴러다니다.

 

4. 그 테크놀로지의 개발자 커뮤니티는 활발한가?

개발자 커뮤니티에 질문을 던졌을 때 바로 답 글이 달리나?

세벽 2시에 사이트가 다운되어 고립 무관했을 때 구글에서 많은 기사를 찾을 수 있거나 Stackoverflow에서 많이 다루고 있으면 문제 해결에 큰 도움이 된다.

 

5. 장애 내성 and/or 장애 복구를 고려하고 있는가?

 

6. 잘 확장 할 수 있을까? 자신의 서비스가 그 테크놀로지의 최대 사용자가 돼도 불안하지 않는가?

 

7. 디버깅 툴은 충실하고 있는가? 프로파일러는? 백업 소프트웨어는 있는가?

 

8. 비용에 알맞을까?

 

 

만약 시계 바늘을 돌려서 Pinterest를 다시 만들 수 있다면 ?

1. 첫날부터 했어야 할 것은

로그를 모은다. 모든 요청, 이벤트, 유저 등록 등.

기본적인 분석 도구나 nagios에서 경고 등.

장애로부터의 데이터 복구를 고려하고 만든다.

 

2. 더 시기를 앞당겨야 했던 것은

MySQL의 샤딩. 슬레이브에서 읽기에 의존하게 된 시점에서 장래 장애의 시한 폭탄 카운트다운이 시작되고 있다고 생각해야 한다.

오퍼레이션 엔지니어의 채용 시기.

Chef / Puppet

빌드에 Jenkins를 이용한 유닛 테스트

A/B시험. 단계적인 release나 금방 롤백 할 수 있는 구조.

 

 

출처: http://wazanova.jp/items/1597

 

저작자 표시
신고
by 흥배 2014.10.27 10:26























저작자 표시
신고
by 흥배 2014.05.22 08:00

오라클 사가 9.21~23에 주최한 이벤트에서 발표된 자료

 

 

Facebook은 기본적으로 그래프이다.

그래프에는 Vertices과 Edge가 있다.

빅데이터라고 부르는 분야에서 나온 Hadoop나 데이터웨어하우스의 대부분은 배치 처리로 데이터가 분석된다.

그러나 Facebook의 MySQL 데이터는 리얼타임으로 접근하고 있다. Facebook 페이지 상에서 친구 리스트를 참조하는 것은 MySQL에서 나온 것일 수 있다.

 

피크 시의 최대 처리 속도. 대부분이 사진이나 댓글 이라는 유저에 의해 생성된 데이터이며, 이것들이 MySQL에서 처리된다. 이 처리에는 추가, 업데이트, 삭제도 있다.

 

유저들의 요청 양

 

캐시 후의 데이터 읽기만으로 이 정도의 수가 유저에게 전달 된다.

 

 

마스터와 슬레이브로 크게 2개로 나누어지며, 이 2개는 지리적으로 떨어져 있다.

각각의 리젼에는 복수의 Front End Cluster와 Back End Cluster가 있다.

Front End Cluster에는 웹서버가 있고, HPHP가 동작하고 있다. 클라스터마다 캐시도 준비 되어 있다.

Back End Cluster에는 MySQL 데이터 베이스가 있고 캐시도 있다. 마스터 리젼과 슬레이브 리젼 사이에는 MySQL 레플리케이션이 돌아가고 있다.

 

 

Facebook 독자적인 PHP

HPHP는 Facebook이 만든 것으로 성능 향상을 위해서이다. HPHP에는 2개의 버전이 있으며 하나는 컴파일 버전으로 PHP를 C++로 변환하여 그것을 바이너리로 컴파일 하여 실행 시 처리가 가볍게 된다.

또 하나는 JavaVM과 같은 PHP를 바이트 코드로 변환하여 VM 상에서 실행하는 것. 이것도 CPU 처리 부하를 가볍게 해준다.

 

 

캐시에는 Memcache를 사용

Front End Cluster에는 Cluster Cache가 있으며 여기에는 아주 뜨거운 최신 데이터가 들어가 있다. 예를 들면 (미국 아이돌)져스틴 비버가 사진을 투고하면 아주 많은 주목을 받을 것을 알고 있으므로 이 데이터는 각각의 클래스터의 Cluster Cache에 들어가고 각각의 클래스터는 여기에 접근한다.

Cluster Cache는 부하를 분산하는 것이 역할이기 때문에 Web 서버에 가까이 있는 것이 중요하다.

Region Cache는 데이터 베이스로의 접근을 회피하여 고속화 하기 위한 캐시이다.

TAO는 우리들이 개발한 것으로 기본적으로는 Memcache를 베이스로 한 자작 그래프 서버이다. Facebook의 그래프 모델을 이해하고 있다.

Wormhole에는 Pub/Sub 시스템으로 MySQL이 로그를 여기에 쓰면 이 내용을 다른 디스트리뷰로 간다.

 

 

MySQL 운용 자동화 툴을 이용

수천 수만대의 MySQL을 관리하고 있기 때문에 툴인 MySQL Pool Scanner를 만들었다.

이것은 자동화 시스템으로 새 서버가 배치되면 OS 등 이미지를 넣어서 MySQL을 설치하고, 필요한 데이터를 서버에 복사해서 실전에 투입한다. 실전 가동 중에는 모니터링을 하고, 부서지면 수리하여 다시 이미지를 넣어서 고친다.

 

 

스토리지 활용을 위한 압축이 중요

Flash/Flachcache 2 종류의 스토리지를 사용하고 있다.

Facebook에서는 고속 스토리지로 100% SSD를 사용한 시스템을 채용하고 있다.

그러나 비용이 비싸기 때문에 SSD와 거대 용량의 HDD를 합쳐서 대용량이며 SSD로 고속 접근을 실현한다.

 

압축은 아주 중요. 왜냐하면 많은 플래시 스토리지를 사용하고 있으며 여기에는 용량적인 제약이 있기 때문이다.

이 제약을 뛰어 넘기 위해 압축은 아주 중요하다. 지금까지 실 데이터는 대부분 압축을 하고 있다.

뛰어난 압축을 위해서 리소스를 투입하고 있으며 현재 아주 잘 동작하고 있다.

 

 

 

출처: http://www.publickey1.jp/blog/13/facebookmysqlmysql_connect_2013.html

 

 

신고
by 흥배 2013.12.30 08:00



저작자 표시
신고
by 흥배 2013.12.10 08:00
| 1 |