AWS로 워드프레스 호스팅시 주의사항

순전히 나의 fails를 case studies로 바꾸기 위한 기록. 눈물 없인 읽을수 없을껄!!!

거의 프리티어 php EB 기준입니다.

한동안 내 목표 = 이 글 업데이트 안해도될만큼 fail study 쌓는것 ^.^ ㅜ.ㅜ

일단은 이 슬라이드를 읽고 오자. 온갖 실패를 겪고 나니, 이 슬라이드가 얼마나 잘 만든 것인지 비로소 보임.

잘 이해가 안 되면 이제부터 아래를 읽도록 합니다.

• 기본적으로 AWS는 “너는 서버를 굴릴 줄 알고 우리는 남는 서버가 있으니 우리 한 번 잘해보자”의 방침임. AWS가 나쁜놈인 케이스는 거의 없고 나의 서버 구축 운용 지식의 문제인 경우가 대다수.
  
  
• 엘라스틱 빈스톡일 경우, 로컬에서 테스트 끝난 소스를 deploy하는 것이 기본. 워드프레스 관리자 메뉴에서 플러그인, 테마 등을 바로 받아 서버에 추가로 설치하는 것들은 version으로 관리가 안 된다. 따라서 오토 스케일링이 작동되거나 인스턴스가 재부팅되고 나면 추가 설치했던 요소들은 다 날아가고 없어짐.
  싫으면 위에 소개한 슬라이드에 설명된 대로, ①원하는 추가변경 작업 완료 → ②백업 플러그인으로 내려받기 → ③그걸 다시 application version으로써 deploy 를 하도록 한다. 해봤는데, 생각 이상으로 문제없이 깔쌈하게 돌아가서 매우 놀람.
  
  
• 일반 EC2의 경우는 모르겠는데, EB로 환경 구성했을 경우 DeliciousBrain에서 만든 Amazon Web Service와 WP S3 Offload는 필수로 깔아야 함. 안그러면 이미지 올릴 때마다 EB를 돌리기 때문에 맨날 WARN 뜨고 degraded됨.
  
  
• 이미지를 S3로 처리하게 해놨다 하더라도, user avatar와 featured images는 기본적으로 home_url() 기반으로 세팅하는 것이 wp의 철학임. 따라서 인스턴스를 새로 구성하거나 버전을 EB에서 다시 deploy할 경우 다른 이미지는 남는데 유저 아바타와 특성이미지는 날아가는 경우가 있을 수 있다. 영어로는 dead라고 부름. 일반 호스팅 업체에서는 s3 개념이 없으므로 아무 문제가 없었을 것이다.
  
  
• 프리티어가 뭘 돌리든 월 750시간 무료라고 하는데, 이게 총합에 대해서 그렇다는 말임. RDS 물린 environment를 한달 내내 4개 켜놓으면 유료 결제되는 사용량은 = EC2 3개 * 750시간 * 1시간비용 + RDS 3개 * 750시간 * 1시간비용 = 요금폭탄!!!
  
  
• 프리티어 첫 과금이 깜짝 놀랄 정도로 발생했을 경우 침착하게 다음 순서에 따른다.
  1. 결제 물려놓은 카드의 잔액을 없애거나 해외결제를 중지한다. (이건뭐 각자 알아서들 하시라. 일단 결제를 시도하기 때문에...)
  2. 내가 뭘 create해봤다 싶은 모든 서비스에 들어가 불필요한 인스턴스를 모두 terminate할것. 특히 월초 시작됐을 경우. 지금 이 시간에도 과금은 되고 있으므로
  3. 우상단의 support center로 가서 create case를 눌러 자초지종을 영어로 설명하도록 한다. "나 프리티어인데 요금이 너무 많이 부과가 됐다 어떻게 하면 좋으냐" 정도의 의사를 전달하고, 답장 받는 방식을 web으로 지정해 전송.
  이후 기다리다 보면 알아서 처리해줌. 첫 청구는 거의 대부분 캔슬해 준다고 함. 내 경우에는 답장 받는 데 5일 걸림. 한번 100불 넘는 청구를 받아보고 나면 정신이 확 든다. 수시로 우상단의 (자기이름) > billing & cost management를 확인하도록 한다. 이번 달 청구요금이 별로 없거나 줄어들어 있는 것을 확인하면 정신 건강에 도움이 된다.
  
  
• 일반 웹호스팅 때 하던 나쁜 버릇이 문제가 된다. 예컨대 예전 호스팅 업체 쓸 땐 루트폴더에 phpmyadmin도 깔고 codeigniter도 깔아서 썼었는데(물론 아무 문제가 없다) 이걸 워드프레스와 같이 묶어서 버전으로 배치하려니 개노답.
  RDS 따로 쓰기 싫고 이것저것 자기 맘대로 하고 싶다면 그냥 EC2에 콘솔로 DB, 언어 등등을 다 깔아 구축하든지 차라리 코드이그나이터만 굴리는 AWS 계정을 하나 새로 만들어서 쓰는 게 훨씬 건강에 도움이 된다. (그냥 돈을 내고 새 환경 하나 구축해도 되긴 됨…)
  
  
• 파일 이름이 한글로 된 이미지 등이 제대로 올라가지 않는다. 뭐 모든게 ascii latin-1로 맞춰져 있는 동네이니 당연한 일인데, 다음 두 가지 방법을 병행하면 도움이 된다.
  1. non-latin 파일명 통제 플러그인 설치. 난이도 낮음, 효과 큼, 문제해결력 작음. 내 경우에는 안형우님이 만든 플러그인을 쓴다.
  2. RDS(데이터베이스)의 파라미터 그룹 고쳐주기. 난이도 중간, 효과 중간, 문제해결력 큼. RDS 콘솔의 좌측 메뉴에서 Parameter Groups를 누르면 default.mysql.5.6 어쩌구 하는 것 하나만 보일 것이다. 이 밑에 비슷한 걸 하나 더 만드는데 다만 character_set_ 부분과 collation_ 부분을 죄다 utf8(-general-ci)로 고쳐준다. 저장한 다음 원하는 RDS에 적용하고 reboot 한번 해주면 됨. 다른 블로그 글들을 검색해서 하는 게 더 정확한데, (다행히 난 안 그랬지만) 인코딩 설정을 기존 환경과 충돌하게 설정하고 reboot하면 몇십 분간 in-sync로 안돌아온다는 케이스 문의들도 있었다. 주의해서 해볼일인듯.
  
  
• Route53을 쓴다면 기본 요금으로 매달 50센트는 낸다고 보면 된다.
  
  
• 한 달 좀 넘게 이리저리 굴러 봤는데, 결론을 말하자면 이미지(미디어) 호스팅만 S3로 받고 애플리케이션(코드)은 일반 웹호스팅으로 받는 조합이 가장 적절하다는 것이 내 생각.
  AWS가 지향(상정)하는 웹애플리케이션 개념에 워드프레스는 해당되지 않는다. 문제의 워드프레스가 기본 트래픽이 아주 높아서 일반 서버호스팅으로 비용 감당이 안 되거나, 상당한 양의 real-time 서비스를 한다거나 하지 않는 이상에는, 코드와 저장소와 DB를 모두 AWS에 넣어놓는 워드프레스는 확실히 '가성비 꽝'이다. 워드프레스는 24시 꾸준하게 운영되는 서버에서 대단히 정적으로 움직이는 CMS이기 때문에.
  
  
• 다시 일반 웹호스팅으로 옮길 때는 DB 테이블 설정에 주의하도록 하자. 나의 경우에는 닷홈으로 다시 옮기고 나서 1주 정도 간격으로 자꾸 테이블 "일부"가 없어지는 기현상을 겪었는데, 문제를 해결하고 원인을 파악하다 보니 AWS에서 넘어온 데이터베이스의 테이블들이 다 InnoDB로 되어 있다는 사실을 발견. 나머지 안 날아가는 테이블들은 MyISAM이길래 모두 MyISAM으로 맞췄고, 현재까지는 문제 반복 안됨.

내가 앞으로 라이브 서비스 서버를 바꾸느니 종교를 바꾼다 ^_T