Extra Form
PHP PHP 7.2
CMS Rhymix 1.x

안녕하세요,

항상 질문으로 잘 답을 얻어가거나 이상하게도 질문을 만들고 해결하는 경우가 있어서 부끄러운 나날들입니다.

 

S3 버켓으로 업로드 하는 모듈 을 다운로드 받아 업로드 하여 모듈을 설정하려 하는데요.

 

엔드포인트 설정은 씌어져 있는대로는 잘 모르겠어서 https://docs.aws.amazon.com/ko_kr/general/latest/gr/rande.html 이 문서를 보고 예제처럼 https://s3.ap-northeast-1.amazonaws.com/ 만 넣으면 될거 같아 넣어두었고, 리전도 마찬가지로 ap-northeast-1를 넣었습니다.

 

Key와 Secret도 AWS의 내 자격증명에서 키를 발급 받으라는 내용이 있어 이 내용을 참고하여 키와 Secret 값을 입력해줬구요.

 

문제는 Bucket이름은 S3 버켓을 생성할때의 이름이라고 하더라도, S3 Domain은 어떻게 해야하는지 몰라 해메고 있습니다.

 

아니면 이 설정을 어디서 가져와야 하는지 명확하게 알 수 있는 방법이 있을까요?

 

평소 NCP에서 스토리지 가져와서 마운트 하는 작업등은 하드하게 하는것이니 명령어로 하기도 했지만 모듈로 설정하려고 처음으로 아마존으로 들어오니 할것이 뭔지 잘 모르겠습니다 ㅠ

 

묻고자 하는 것은

 

1. 제가 설정한대로 설정하면 되는것인지? (엔드포인트와 리전, 키&시크릿)

1-2. 만약 아니라면 어디에 어떤 값을 입력해야할지.. 막막합니다.

 

2. 모두 맞다면 S3 도메인 이름은 어디서 확인해야할까요?

 

 

감사합니다 (__)

  • profile

    질문의 구체적인 내용과는 관련없지만, RXE에서는 첨부파일 외부에 저장하는 거 아닙니다. 그런 기능을 제공한다고 주장하는 모듈이나 애드온 중 제대로 호환되는 것은 본 적이 없습니다.

  • profile profile
    AWS 인스턴스를 사용하는 경우에 여러 대의 서버를 가지고 분산 처리하려면 어떻게 하는게 좋을까요?

    고객은 S3같은 인스턴스를 쓰고 싶어하던데, lightsail로 가는게 좋을까요?
  • profile profile
    S3는 인스턴스가 아닙니다. EC2를 말씀하시는 건가요?

    그냥 일반적인 스타일로 서버 구축하고 AWS 썼다고 생색내기에는 라이트세일이 딱 좋습니다.

    EC2를 쓰신다면 적당히 2~3개의 인스턴스를 생성해서 하나는 웹서버, 하나는 DB서버(이건 EC2가 아니라 RDS를 쓰셔도 됩니다), 하나는 캐시서버, 등등 역할을 부여하시면 됩니다. 웹서버를 2개 이상으로 나누는 것은 일반적인 CMS 환경에서는 파일 공유 문제 때문에 효율이 수직하락하므로 권장하지 않습니다. X짜리 인스턴스 4개를 쓰는 것보다 4X짜리 인스턴스 1개를 쓰는 것이 훨씬 빠르고 안정적입니다.
  • profile profile
    아. 현재는 EC2 인스턴스를 사용하고 있고, DB는 RDS를 사용하고 있습니다.

    고객이 걱정하는 것은 시스템의 부하를 대비해서 나중에 파일을 외부에 보내고 싶다는 니즈가 있는거 같습니다.

    첫번째 대안이 나온것은 XETOWN에 과거에 나왔던 S3_UP 모듈을 사용해 S3버켓으로 파일을 올리고 보여주는 역할을 하려고 했지만 설정하는 법을 몰라 기로에 막혀 있습니다.

    조금 더 생각해보니 S3보다는 라이트세일이 조금 더 나은것 같고(기존의 글을 보아하니 S3보단 라이트세일이 더 많고, 만족하는 듯 해보이네요) 저렴한 것 같아 그쪽으로 갈까 고민은 하고 있습니다.

    하지만, 문서도 적어서 기진곰님이나 다른 서드파티 개발자님께 요청해야하는 문제가 있기도 하고요..

    라이믹스의 환경은 과거 XE처럼, 파일 디렉터리는 분리하지 않고 웹서버의 인스턴스와 함께 보관하는게 제일 BEST이고, 파일 디렉터리를 프록시 등으로 구성하는 것은 좋지 않다는 말씀으로 이해하면 될까요>
  • profile profile
    네, 맞습니다.

    파일은 부하를 일으키지 않습니다. (중요!!!) 파일은 그냥 디스크에 가만히 앉아 있을 뿐입니다. 용량이 늘어나는 만큼 디스크를 추가해 주기만 하면 됩니다. 요즘 16테라, 18테라짜리 하드도 나옵니다. 라이트세일도 몇 테라 정도는 손쉽게 추가할 수 있고요.

    동접 1만 명이 넘는 대형 커뮤니티도 RXE나 그누보드 등으로 만들었다면 로컬 디스크를 여러 개 넣고 RAID로 묶어서 사용하는 것이 일반적입니다. 물론 트래픽 분산이나 캐시 효율을 높이기 위해 별도의 캐시서버를 둘 수는 있습니다. 캐시서버의 역할을 전문적으로 해주는 클플 같은 서비스도 있고요. 그러나 어떤 경우에도 원본 파일은 웹서버의 로컬 디스크를 떠나지 않습니다.
  • profile profile
    오늘 고객을 설득해야겠네요..

    그렇다면 궁금해 지는 것은, 고객이 나중에 서버를 늘린다? 로드밸런싱을 할 수 있다고 하는데 그때에는 그냥 생성만 해주면 되는건가요?

    이 부분을 설명해야 설득을 할 수 있을 것 같은데, 로드밸런싱 보다는 그냥 인스턴스 크기를 늘리고 줄이는 오토스케일링(이건 솔직히 조금 오바같긴 합니다만..) 같은 걸 해놓는게 좋은거죠?

    꼭 오토가 아니더래도 수동으로 크기를 늘렸다가 줄인다거나 (특히 아마 램이 주 이슈겠지만요) 하는 작업이 있으면 문제가 없겠죠?

    저도 예전에 커뮤니티 운영할 때 큰 하드 여러개 RAID달고, 운영했던 기억이 있는데 그때도 메모리만 늘려주면 잘 돌아갔던 경험이 있긴 하거든요.

    기진곰님의 말씀이라면 누구도 납득(?) 할 수 있을 것 같아 여쭤보려 합니다.
  • profile profile
    고객이 생각하는 것을 먼저 파악을 하셔야할 것 같은데요?

    부하라고 표현하셨는데 왜 파일을 다른 곳에 저장해야 하는지??
    --> 이부분 부터 이해가 안가지 않습니까??

    파일을 덜어낼 생각을 했다는건 지금 운영하는 인스턴트에 달린 저장공간이 부족하거나 저장공간의 비용이 비싸다고 생각하셨던 거 아닌가요??

    그럼 뭔가 생각 자체가 잘못된 것 같구요.

    부하라는 표현이 정말 부하를 말한거라면...
    파일 저장을 다른 곳에 하는 것이 아닌 시스템을 증설하거나 혹은 메모리,CPU 등을 조정하는 것을 고려한다고 하셨어야 할 것 같은데 갑자기 파일의 저장공간을 다른 곳으로 하고 싶다가 왜 나온건지 납득이 안갑니다.


    혹시 트래픽 발생을 부하라고 표현해서 다른 곳에서 파일이 읽혀지면 트래픽이 그쪽 요금으로 발생하니 트래픽을 분산하고 싶다고 하신거라면...

    별도 저장이 아닌 트래픽 분산의 방법중 원본 파일을 다른 곳에 캐시해서 캐시된걸 방문자에게 보여주는 것을 구현해야 합니다.
  • profile profile
    부하라고 표현하셨는데 왜 파일을 다른 곳에 저장해야 하는지??

    -> 설명하시는 바로는 서버를 증설할 것이라고 합니다. 그래서 이 파일들이 다른 서버가 증설되더라도 볼 수 있는 방법이 있다면 좋고, 없다면 파일을 외부에 두고 계속 그 파일의 주소를 고정시키고 싶은가 봅니다.

    말 그대로 사이트의 동접자 등이 늘어나면 고려해야하는 것은 CPU와 RAM 그 자체일 뿐, 파일을 덜어낸다고 부하가 줄어들지 않는 다는 의미는 알게 되었습니다.

    다만 그 전에 말해둔게 있어 그걸 엎을만한 이야기를 해야하다보니.. 이곳저곳에서 찾아보면 사실 파일에 대한 부하는 진짜 잘쳐줘야 5%정도인것 같더군요..
  • profile profile

    "이 파일들이 다른 서버가 증설되더라도 볼 수 있는 방법이 있다면 좋고, 없다면 파일을 외부에 두고 계속 그 파일의 주소를 고정시키고 싶은가 봅니다."

    --> 서버를 증설과 기존 파일을 못보는 것과는 관련이 없지요. 증설은 말 그대로 있는 것 그대로 유지하면서 시스템의 규모를 키우는 거니까요. 저장장치가 되었던 메모리가 되었던 CPU가 되었던 말이죠.

    서버를 증설하고 싶다면 증설하시면 된다고 말씀하시면 될 것이고 증설해도 기존 데이터는 유지 된다라고 하면 간단한거 같은데요.

  • profile profile
    그러고보니.. 고객은 서버 증설의 개념을 인스턴스의 갯수를 늘리려는거 같은데, 여러대의 인스턴스 보다는 인스턴스의 크기를 키우고 캐싱을 잘 해놓으면 되겠죠?

    XE/RXE 캐시의 대가인 슈퍼캐시를 사용해서 메인페이지랑 위젯페이지 등등을 1분마다 캐싱하거나 30분마다 캐싱시켜서 보여주는게 부하를 줄이는 첫번째 방법이자 제일 베스트한 방법이겠죠?
  • profile profile

    캐시야 보완적으로 할 수 있는 추가적인 혜택이니 그건 할수도 안할 수도 있겠죠. 갱신 기간 동안 이전 데이터가 보여져도 무방한 경우 캐시가 100% 도움이 되겠죠.

    증설의 개념을 로드밸런싱과 같은 것을 하려면 복잡해지기도 하고 세션공유등의 문제부터 해결해야할 것들이 많을 겁니다.

    효율의 면이나 관리적인 측면에서 1대의 서버의 성능이 여러대의 서버 성능과 같다면 여러대에 분산하는 기술을 사용할 이유가 1도 없다고 봅니다. 그리고 라이믹스나,XE 등에서 쉽지 않구요.(불가능하다는 이야기는 아닙니다.)

     

    하물며 1대의 서버 성능이 여러대보다 효율면에서도 훨씬 높을 겁니다.

  • profile profile
    제가 미팅하면서 잘못 이해하고 있던 부분들이 많았군요..

    그러고보니 예전에도 서버를 증설한다 -> 인스턴스 갯수의 증가 는 없었는데..
    생각해보니 AWS의 인스턴스 최대 크기만큼 커질려면 그것도 그거 나름대로 백엔드가 효율이 구려야 가능할텐데 라이믹스는 그럴일이 없을 것이니.. 문제가 없겠군요.

    오늘 이야기 잘 해봐야겠습니다.
  • profile profile

    증설이라는 말을 흔히 두 가지 의미로 사용합니다.

    1. 서버 대수를 늘리는 것: 일반적으로 오토스케일링, 로드밸런싱이라고 하면 이쪽을 의미합니다.

    서버 대수가 많아지고 서버간 통신이 많아지면 네트워크에서 병목현상이 발생하고, 동기화로 인한 오버헤드도 심각해집니다. 따라서 이런 방식의 증설은 여러 사용자들이 서로의 정보를 많이 공유하지 않고 독립적으로 활동하는 서비스에 적합합니다.

    예를 들어 소수의 인원이 팀을 만들어서 하는 FPS 게임이나, 단순히 자기 정보를 관리하기 위한 앱이라면 사용자수가 100배 늘어나더라도 서버를 잔뜩 만들어 놓고 사용자나 팀마다 랜덤으로 서버를 배정하면 됩니다. 가끔 뭔가 공유할 때만 다른 서버에 정보를 전달하면 되지요. 그러나 수만 명이 동시에 참여하는 MMORPG 게임이라면 동기화 오버헤드가 심각한 문제가 됩니다. 초대형 MMORPG 게임을 운영하는 회사들의 기술력은 여기서 빛이 나지요.

    2. 서버 대수는 그대로 두고 사양을 높이는 것: 일반적으로 커뮤니티 사이트에서 서버 증설을 한다고 하면 이쪽을 의미합니다.

    커뮤니티 사이트는 모든 사용자가 모든 정보를 공유하는 극단적인 케이스입니다. 한 사람이 댓글을 달면 모든 사용자에게 즉시 보여야 하고, 한 사람이 프사를 변경하면 모든 사용자에게 즉시 보여야 하기 때문에 DB나 파일을 동기화하는 데 따르는 딜레이를 최소화하기 위해 소수의 고사양 서버를 이용하는 것이 좋습니다. 정말 안 되면 디씨처럼 게시판마다 다른 서버를 사용하고 회원 계정만 공유하는 식으로 발전하게 됩니다.

    그러나 최근에는 수백 코어짜리 서버도 구할 수 있고, 로컬 디스크 용량도 수십TB에 달하므로 RXE 기준으로 동접수 5~10만 명 정도까지는 서버 1대로도 충분히 커버할 수 있습니다. 고사양이라고 해봐야 4~8코어에 불과하던 10년 전 개념은 이제 버려야지요.

    그럼 저는 오늘도 128코어 서버 한 대 세팅해 드리러 슈웅~^^

  • profile profile
    정말 긴 답변 감사합니다 (__)

    RXE 개발 분들이나, 실제 대형 커뮤니티를 운영하시는 분들의 조언이 꽤 도움이 되었습니다.

    궁금한것이 그렇다면 2 Core 8GB RAM에서는 어느정도를 수용할 수 있을지, (슈퍼캐시는 전체 페이지 60초 캐시되어 있음) 약간 부하력? 에 대한 자료가 어디 정리 되어 있으면 좋을텐데 커뮤니티 쪽 자료는 찾기가 힘드네요.

    괜찮다면 과거의 일이나 경험담에 의한 자료 등이 있을까요?

    과거에 @웹지기 님께서도 서버 증설할 때의 그런 에피소드가 있었는지 궁금합니다.
  • profile profile

    여기 오시는 분들 대부분 소형 커뮤니티 정도 운영하시는 분이 대부분이십니다. 대형 커뮤니티의 운영자분의 사례를 직접 듣기는 어려울 것 같고 기진곰님께서 서버관리를 하시니 아마 도움되는 이야기를 많이 아실 수 있을 것 같습니다.

    https://xetown.com/topics/1184640

    위 링크에 실제 커뮤니티에서 회원들의 활동과 방문자의 접속이 함께 이루어지면서 동접으로 인한 대략적인 부하 그리고 요구되는 사양 정도를 확인하실 수 있을 겁니다. 단, 소규모 사이트의 사례입니다.

    말씀하신 2코어 8G 수준이면 라이믹스로 커뮤니티를 운영한다면 수백명의 동접은 문제 없고 잘 세팅하고 한다면 천단위까지도 가능할 것으로 보입니다.

  • profile profile
    웹지기님의 이야기는 과거 XE공식 홈에서 부터 눈팅하고 있을 정도로 운영에 대한 1선의 이야기를 들을 수 있어 흥미로웠는데, 역시 웹지기님의 글에서도 경험에 의해 쓰시는 내용이라는 게 와 닿습니다.

    웹지기님의 에피소드도 다시 찬찬히 읽어보고 새기겠습니다.

    소중한 경험 공유 감사합니다.
  • profile profile

    코어가 실제 2코어냐, 아니면 라이트세일처럼 명목상 성능의 10~20%밖에 안 나오는 뻥코어냐에 따라 어마어마한 차이가 날 수도 있습니다. 제 경험상 라이트세일은 최고 사양으로도 동접 500명을 감당하기 어렵고, 2코어로는 100명도 장담하기 어렵습니다. 반면, 실제 2코어에 램이 충분하다면 500명도 기대해 볼 수 있습니다.

    슈퍼캐시 모듈의 전체 화면 캐시는 로그인하지 않은 상태에서만 작동하므로, 대부분 비회원 상태로 글을 읽는 블로그나 홍보사이트, 랜딩페이지 등에서 효과가 좋습니다. 이상적인 경우라면 소규모 서버로 수만 명의 유입을 감당할 수 있을지도 모릅니다. 반면, 회원가입을 적극 유도하는 사이트라면 전체화면 캐시는 큰 의미가 없습니다. 회원가입을 받고 게시판이 활성화된 사이트라면 게시판 캐시 기능이 더 효과적입니다.

  • profile profile
    앗 그렇군요. EC2 인스턴스 처럼 실제 2코어라면 조금 더 큰 차이가 있을 수 있겠군요 (좋은 의미로써의)

    슈퍼캐시의 경우 전체화면은 비 로그인만 캐싱하는 것이고, 회원이 많은(또는 적극적으로 유치하는) 사이트 라면 게시판 캐시가 더 효과적이겠군요.

    그렇다면 위젯 효과도 더 효과가 있을까요?
  • profile profile
    EC2도 인스턴스 타입에 따라 다릅니다. T 타입은 라이트세일과 동급입니다. M, C, R 타입은 실제 코어에 좀더 가깝습니다. 그 밖의 클라우드 업체들도 shared 코어와 dedicated 코어를 구분하는 곳이 많으니 눈여겨보시고요.

    잘못 설계된 위젯 하나가 서버 부하의 90%를 차지하는 경우를 흔히 봅니다. 위젯 캐시를 잘 활용하면 이 부하를 줄일 수 있겠지요. 그러나 운나쁘게 동접수가 치솟는 순간 캐시가 만료된다면...?
  • profile profile
    제가 기억하기로는 m5.large 랑 db.m4.large 를 사용하는 것으로 알고 있어요.

    그렇다면 실제 코어에 가까울것이니, 조금 기대할만 하겠군요 +_+