XETOWN

하얀 언덕

웹사이트를 운영하면서 생긴 고민이나 노하우를 함께 나눠보세요.
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 댓글로 가기
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기

XE는 여러대의 서버를 사용하는 것에 대해서 크게 고려가 되어있지 않은 CMS 라서, 

서버를 스케일업하는데 상당히 고생을 많이 했습니다.

 

이래저래 체득한 내용에 대해서 다른 사용자 분들과 공유해보고자 합니다.

 

일단 서비스 상황은,

PHP 의 CPU 부족량이 너무 심각해서, PHP 전용 서버 1대에서 -> 3~4대까지 스케일업을 고려해야하는 상황이었습니다.

 

일단 XE, 라이믹스는 기본적으로 파일캐시를 상당히 많이 사용하기 때문에,

코드를 어떻게 공유하냐 부터 첫번째 문제에 봉착하게 되었습니다.

 

1. 코드를 git 같은 코드 관리 시스템을 쓰던, rsync 를 쓰던 공유하고, 파일 캐시는 전부 없앤다.

2. NFS 를 통해서 코드와 파일캐시를 공유한다.

 

둘다 작업을 해봤습니다만, 결과적으로 선택한건 2번이었습니다.

 

저도 1번이 훨씬 효율적이라고 생각했습니다만,

php7 버전 이상대에서 제공되는 opcache 의 성능이 워낙 좋아서, 파일캐시를 없애고 memcache 등에 서브하는것보다,

파일캐시로 그냥 NFS 로 주고받는것이 훨씬 큰 어려움없이 쉽게 구축할수 있고 성능도 크게 떨어지지 않았습니다.

다만 opcache 를 매번 요청할때마다 체크하는 형식이면 비효율성이 크게 늘어나기 때문에 opcache 를 수동으로 초기화하기전에는 체크하지 않도록 설정해 두는것이 필요합니다.

 

그후에 두번쨰 문제는 memcache 문제였습니다.

사실 논리적으로는 1대의 memcache 서버에 모든 php 서버가 접근하는것이 가장 문제가 적은 서비스 구조입니다만,

object cache 에 다량의 연결을 하는 XE 방식으로는, (한번에 필요한 캐시 데이터를 모아서 가져오지 않는)

private network 라고 해도 네트워크 상으로 연결하게 되면 생각보다 많은 지연시간을 잡아먹게 되더라구요.

 

그래서 서버별로 memcache 를 설치하고,

memcache 를 flush 하거나 put 할때, 각 서버에 모두 리퀘스트를 날리는 방향으로 cache 시스템을 개조했습니다. 

 

그 결과, php 서버 3대~4대 정도까지는 크게 서버 추가에 따른 큰 성능 저하 없이 다량의 리퀘스트를 처리할수 있었습니다.

글의 요점은,

 

1. php7 이상일경우 opcache 가 워낙 강력하게 커버해주기 때문에 그냥 NFS 연결같은걸로 편하게 붙여놓자.

2. memcache 등의 object cache 용도는 각 서버별로 연결해 두는것이 훨씬 좋다.

  • profile
    라엘 2017.07.02 21:15:51
    우와!
    현재 1번 방식과 2번 방식을 모두 운영중인데, 1번 방식이 다루기 더 까다롭습니다.
    혹시 2번 NFS 방식은 어떤 방식을 사용하셨나요? 참조할 만한 곳 있을까요?
  • profile
    銀童 2017.07.03 02:00:41
    NFS 는 딱히 뭐 특별한 방식을 사용하진 않았습니다. 그냥 비동기방식으로 평범하게 구현했어요.
  • profile
    기진곰 2017.07.02 23:32:59

    컴파일된 템플릿, 완전 딴판으로 변환된 XML 쿼리, 메뉴와 카테고리 캐시 등이 많아서 파일 캐시를 완전히 없애려면 보통 노가다가 아니지요;;;

    opcache가 좋긴 합니다만, XE에서 캐시파일을 갱신한 후에는 opcache_invalidate()를 반드시 호출해 주어야 하는데 이게 누락된 부분이 여기저기 있어요. 일반 사이트에서도 opcache 체크 주기를 조금만 길게 해두면 설정 변경 후 한참 지나야 적용되는 현상이 종종 보고되는데 이것 때문입니다. 서로 다른 서버의 opcache를 갱신해 주는 것은 더 복잡할 것 같은데, 어떻게 구현하셨는지 궁금하네요.

  • profile
    銀童 2017.07.03 01:51:55
    opcache_invalidate 등을 통해서 해당 파일의 캐시를 새로 만들도록 하는 별도 프로그램을 만들고 (private network 상에서만 실행되게 제약하구요.)

    파일캐시를 만드는부분에서 해당 서버의 프로그램을 CURL 등으로 호출하도록 짜봤습니다.
    어차피 파일캐시를 새롭게 만드는 경우는 많지 않아서 성능저하가 눈에 띄진 않더라구요.
  • profile
    銀童 2017.07.03 01:55:34
    그리고 opcache 를 통한 파일캐시가 memcache 나 apc 보다 더 효율적이기 떄문에,
    아예 파일캐시를 다 없애면 성능이 더 떨어지더군요.

    템플릿같은 경우는 memcache 나 apc 를 이용하는것보다 파일캐시가 압도적으로 빠릅니다.
    memcache <-> 파일캐시 <-> XE 의 형태로 만들어볼까.. 싶기도 한데 아직 그렇게까지 서비스에 필요하진 않아서..
  • profile
    기진곰 2017.07.03 09:56:32
    네, 예전에는 template cache를 apc로 하면 성능이 좋아진다는 소문이 있었는데, opcache 도입 후에는 그냥 다 php 파일로 만들어 놓고 자동으로 캐싱되도록 하는 편이 훨씬 빠르더군요. 라이믹스에서는 template cache 자체를 없애버렸습니다^^
  • profile
    銀童 2017.07.03 14:28:05
    object 캐시도 파일캐시로 대체하거나 중간 인터페이스를 넣는걸 고려중인데,
    이걸 어떻게 짜야 안정적으로 잘 돌아갈지 고민중입니다.

    예상으로는 웹 서버 반응을 한 20~30ms 정도는 떙길수 있을꺼 같은데 말이죠.

위로
서버에 요청 중입니다. 잠시만 기다려 주십시오...