글쓴이 보관물: Yuk SeungChan

Yuk SeungChan에 대하여

이음소시어스 서버 개발자입니다. 노는거 좋아하구요, 노는걸 좋아합니다.

IM8(아임에잇) 오토스케일링 적용기

안녕하세요. 이음소시어스 개발팀 서버개발자 육승찬(루)입니다.

오늘은 이음소시어스의 핫한 서비스 “IM8(아임에잇)“의 오토스케일링 적용경험을 공유하려고 합니다. 먼저 오토스케일링에 대한 이야기를 하기 앞서서, 아임에잇이 어떤 서비스인지 간단하게 설명하고 시작하겠습니다.

IM8 (아임에잇) ?

직장인을 위한 프리미엄 소개팅 서비스

im8_1

IM8은 2013년 10월에 런칭되어 “까다로운 신원인증으로 높은 매칭 신뢰도를 주자”를 목표로 열심히 발전해 왔습니다. IM8의 8은 8개의 회원 타입(스마트커리어비주얼유니크글로벌밀리언패밀리액티브)을 의미합니다.

im8_2

현재 아임에잇의 모든 서버는 AWS를 통해서 운용하고 있습니다. 그럼 본격적으로 AWS x IM8 오토스케일링 적용기를 공유해보겠습니다. GOGO~

기존 서버

처음에는 IM8 API 서버를 EC2(t2.medium) 한대로 운영해왔습니다. 이후 트래픽의 증가에 따라 ELB에 EC2(t2.medium) 서버 2대를 붙여 운영하는 구조로  발전했습니다. 하지만 점점 더 트래픽이 증가하면서 피크 시간대에 서버가 터지는 일이 발생하기 시작했습니다. 그래서 현재 서버구조의 문제점을 정리하고 문제점을 개선하기로 결정했습니다.

서버 증설 방법

1. ELB에 서버를 더 붙이자 OR 서버의 스팩을 올리자 !

하루 두 번 푸시가 갈 때 아임에잇에 가장 접속자가 많이 몰립니다. 왜냐하면, 실제 매칭이 되는 시점에 사용자가 들어와서 상대방의 프로필을 확인하는 구조이기 때문입니다. 그래서 일반시간대에는 많은 서버가 필요 없습니다. 이 방법의 장점은 적은 시간 안에 문제를 해결할 수 있다는 점입니다. 하지만 비용적인 측면에서 굉장히 안 좋다고 판단했습니다. 접속자가 많지 않아도 항상 여러 대의 서버가 띄워져 있고 비용을 계속 지불하기 때문입니다.

2. AutoScaling (v)

접속자가 별로 없는 시간에는 최소한의 서버를 유지하고 피크 시간대에 여러 서버를 유지하는 방법입니다. 하루 두 번 피크가 있는 아임에잇에게 아주 좋은 방법이라고 생각합니다. (대부분 서비스에 좋지 않을까하는 생각이.. 😀) 평상시에는 최소한의 서버를 유지하기 때문에 비용적인 측면에서도 굉장히 유리했습니다. 그래서 이번 기회에 아임에잇에 AutoScaling을 적용해보기로 했습니다.

AutoScaling 준비하기

  • 결제서버 분리
  • 통일된 인스턴스 만들기
  • Scaling되는 서버를 항상 최신으로 유지하기
  • Scaling Rule 정하기
  • 서버를 띄우는 시간이 있기 때문에 푸시가 나가기전에 미리 띄우기 (Pre-warm)

1. 결제서버 분리

아임에잇은 모바일과 웹에서 PG서비스를 붙여서 결제할 수 있도록 제공하고 있습니다. 특정 PG는 요청 가능한 서버의 IP를 제한하고 있는 경우가 있어서 결제서버를 분리해야 했습니다. 기존 서버에서 사용하던 IP를 결제서버에 붙이고 내부에서만 통신 가능한 결제서버를 만들었습니다.

  • 기존 서버구조
기존 서버 구조

기존 서버 구조

  • 결제서버를 분리한 구조
새로운 서버 구조

새로운 서버 구조

2. 통일된 인스턴스 만들기

AWS에서 제공하고 있는 오토스케일링 기능은 미리 정의한 규칙에 따라서 인스턴스가 띄워지고 내려가는 형태로 동작합니다. 인스턴스는 AutoScalingGroup에 등록해놓은 AMI를 이용하여 띄우게 됩니다. 원래 사용하고 있던 서버 2대는 완전히 같은 인스턴스가 아니였습니다. 하나를 나중에 띄웠기 때문에 시스템 라이브러리 같은 경우 조금씩 버전이 달랐습니다. 그래서 이번 기회에 통일된 인스턴스를 만들고자 했고, 구조는 아래와 같습니다.

server

  • 시스템 라이브러리 설치 (ex. git)
  • API Rails App 설정
  • Puma 설정
  • Nginx 설정
  • Papertrail 설정 (로그 수집)

3. 서버를 항상 최신으로 유지하기

오토스케일링 되고있는 서버들은 항상 최신의 코드를 유지해야 하고 같은 응답을 줄 수 있어야 합니다. 아임에잇은 Git으로 소스코드를 관리하고 배포에는 Capistrano를 사용합니다. 지금까지는 서버 2대만을 최신으로 유지하면 됐기 때문에 아래의 순서로 배포를 해왔습니다.

  • Git fetching
  • whenever에 등록된 스케줄링 crontab에 등록
  • Puma Reload

오토스케일링을 적용하기 시작하면 서버가 딱 몇 대라고 가정할 수 없습니다. 그래서 모든 서버를 항상 최신으로 유지하기 위한 아래 두 가지 정리해봤습니다.

  • EC2 Instance가 시작되는 시점에 최신으로 만들기

EC2 설정 중에 “User Data“라는 부분이 있습니다. 인스턴스가 띄워지는 시점에 명령어를 실행시킬 수 있도록 할 수 있습니다. 여기서 소스코드를 최신상태로 유지하고 puma를 띄우는 등의 명령을 할 수 있습니다. 이렇게 하면 스케일링 돼서 실행되는 서버도 최신코드를 유지할 수 있게 됩니다. 쉽고 빠르게 모든 서버의 최신상태로 유지할 수 있지만 매 서버가 띄워질 때마다 Ruby 라이브러리 설치(bundle install)하기 때문에 서버가 띄워지고도 최신상태로 유지하는데 시간이 더 걸린다는 단점이 있습니다.

  • 최신의 AMI를 사용하기

이 방법은 미리 최신의 AMI를 항상 유지하고 서버가 띄워지는 부분에 대해서는 신경을 쓰지 않아도 됩니다. 코드를 한 번만 최신으로 유지하면 되고 라이브러리 설치 시간도 매우 줄일 수 있다는 장점이 있습니다. Ruby 라이브러리 중에 ELBAS라는 라이브러리가 있습니다. Capistrano와 연동되어 배포시 실행되고 있는 인스턴스를 최신으로 만들어주고, AMI까지 만들어주는 아주 좋은 녀석입니다… 이 라이브러리를 사용하면 빠르고 쉽게 항상 최신의 AMI를 유지할 수 있습니다.

4. Scaling Rule 정하기

처음에 AutoScalingGroup만 만들면 아무리 기다려도 서버는 스케일링 되지 않습니다… 그래서 어떤 규칙에 의해서 스케일링 할 건지 정해줘야 합니다. 먼저 AutoScalingGroup 설정을 보시면 “Instances“, “Desired“, “Min“, “Max“가 있습니다. Instances는 현재 서버의 개수, Min은 최소 서버 수, Max는 최대 서버 수를 의미합니다. Desired는 스케일링이 돼서 현재 몇 대를 희망하고 있는지를 의미합니다. Desired와 Instances의 수가 같으면 더는 서버를 띄우거나 내릴 필요가 없다는 의미입니다.

아임에잇에서는 서버를 띄우는 규칙 2지와 서버를 내리는 규칙 2가지를 사용하고 있습니다.

  • Add 1 instance (CPUCreditBalance < 9)

10분안에 CPUCreditBalance의 수치가 9 미만이라는 알람 두번이 울리면 인스턴스를 띄워라!

이 규칙은 CPUCreditBalance 수치에 따라서 동작하게 됩니다. 아임에잇 서버는 현재 t2계열의 인스턴스를 사용하고 있습니다. T2계열의 인스턴스에는  CPUCredit라는 개념이 존재합니다. 크레딧이 부족하면 CPU 연산 능력이 매우 떨어지기 때문에 새로운 서버 한 대를 띄우도록 하고 있습니다.

  • Add 2 instances (CPUUtilization >= 60)

2분안에 CPUUtilization의 수치가 60% 이상이라는 알람 두번이 울리면 인스턴스를 띄워라!

평소에는 CPU 사용률이 평온하다가 피크시간이 되면 갑자기 막 올라갑니다. 그래서 CPU사용률이 60% 이상이 되면 인스턴스 2대를 띄우도록 하고 있습니다. (피크시간이 아니면 올라갈 일이 거의 없기 때문)

  • Delete 1 instance (CPUUtilization < 25), Delete 2 instances (CPUUtilization < 15)

1분에 한번씩 CPU 사용률이 낮다는 알람 10번이 울리면 인스턴스를 내려라 !

피크시간이 지나고 나면 급격히 사용률이 떨어지기 때문에 인스턴스를 내리기 시작합니다. 하지만 인스턴스를 내리는 옵션을 상당히 까다롭습니다. 알람이 울리는 10분은 같지만 연속적으로 10번이 울려야 하기 때문입니다. 이유는 인스턴스를 내려도 되는 상황인지 확실시 하고 싶었기 때문입니다. 대게 인스턴스를 띄워서 생기는 문제보다 내리면서 생기게 되는 문제가 많기 때문입니다..

5. Pre-warm

아마 대부분의 프로그래머분들은 장애를 원하지 않을 것 입니다. 이음소시어스 개발팀도 장애가 나지않게 하기 위해서 노력을 하고 있습니다. 아임에잇 서비스의 경우 12:30, 19:00에 푸시를 보내고 있습니다. 실제로 푸시를 보내고 나서 오토스케일링 룰에 따라 서버를 띄우기 시작하면 대처가 좀 늦습니다. 갑자기 들어오는 트래픽을 버티지 못하고 아예 서버 한대가 죽어버리는 일도 있었습니다. 그래서 12:20, 18:50에 서버를 미리 띄워놓고 있습니다.  서버를 미리 띄우는 코드는 Python으로 작성했고 Crontab에서 실행되도록 하고 있습니다.

 

정리

이번 포스팅에서 아임에잇의 오토스케일링 적용 경험을 적어보았습니다. 사실 이번 포스팅을 작성하면서 너무 뻔한 글이 되지 않을까 걱정이 많았습니다. 이미 오토스케일링에 대한 글도 많고 참고할 부분도 많아서 잘 쓸 수 있을지 고민이 되었기 때문입니다. 그래서 더 자세히, 숨김없이 써보려고 노력했습니다.

오토스케일링을 적용하면서 가장 크게 얻은 두 가지는 비용절감과 불안감이 사라졌다는 것입니다. 기존 서버 비용 보다 45%의 비용을 절감할 수 있었습니다. 그리고 평소보다 가입자가 많은 날은 트래픽에 서버가 죽을까 하는 불안감이 있었습니다. 오토스케일링이 만병통치약은 아니지만 룰에 의해서 확장하고 수축하는 구조 덕분에 더 많은 트래픽을 커버할 수 있게 되어 불안감이 해소되었습니다.

마치며..

이번 오토스케일링을 사용하면서 ELBAS라는 라이브러리가 참 좋다고 느꼈습니다. 너무 쉽게 AMI를 최신으로 유지할 수 있는 방법을 제공해줬기 때문인데요. 그래서 이 라이브러리의 핵심적인 부분을 파이썬 코드로 작성해봤습니다 (파이썬을 오래 쓰다보니 재밌는건 파이썬으로 구현해보고 싶은 맘이 생기네요..)

 

 

이음(I-UM) on AWS

안녕하세요. 이음소시어스 개발팀 서버개발자 육승찬(루)입니다.

바야흐로… 2010년 4월 소셜데이팅 서비스 “이음”을 베타 런칭했습니다. 이음은 5년 동안 베이론 서버 제작을 포함해서 많은 변화를 추구해 왔습니다. 앞서서 이음 서비스를 간단하게 설명하고 시작하겠습니다.

이음은 대한민국 대표 소셜데이팅 서비스이며, 현재 회원 110만 명, 일 평균 1,000쌍 이상의 상호 OK가 진행되고 있습니다. 그리고 150만 이상의 누적 앱 다운로드를 기록하고 있습니다.

스크린샷 2015-07-03 오후 2.22.01

이 포스팅에서는 이음이 AWS를 어떻게 사용하고 있는지 설명하려고 합니다. 이음은 2012년 6월부터 AWS를 사용해 왔습니다. 현재 사용하고 있는 서비스를 간략히 나열해보면 아래와 같습니다.

  • EC2
  • ELB
  • RDS
  • S3
  • CloudFront
  • Route53
  • CloudWatch
  • SES
  • SNS

이렇게 나열해보고 나니 생각보다 많이 쓰고 있었네요! 그럼, 각 서비스를 어떻게 사용하고 있는지 설명해 드릴게요.

나와랏.. 스피드웨건 !

나와랏.. 스피드웨건 !

EC2 & EBS & ELB

이음에서는 다수의 EC2 인스턴스를 사용하고 있습니다. API서버, 웹서버, 어드민서버, 통계서버, 개발서버, Redis, SMS 등을 EC2에 올려놓고 사용하기 때문입니다. EC2는 순식간에 가상 서버를 만들 수 있는 장점이 있습니다. 예로 이전의 포스팅했던 깃랩 업데이트 당시에도 테스트하기 위해 가상서버를 만들어서 진행했습니다. AMI로 인스턴스를 만드니 빠르게 테스트 할 수 있었습니다.

대부분의 EC2의 Volume으로 EBS General Purposed SSD(gp2)를 사용하고 있습니다.

API 서버와 웹서버 같은 경우는 ELB를 앞단에 두고 있습니다. API 서버는 Auto-Scaling 기능을 사용하여 자동으로 scale-out 됩니다. 어드민, 통계, Redis 같은 경우는 아직 scale-out 할 필요성이 없어서 순수 EC2만을 사용하여 구동하고 있습니다.

여담으로 내부적으로 T2 타입 인스턴스를 좋아하고 많이 사용합니다. T2 타입 인스터스는 인스턴스 크기를 기반으로 정해진 고정 비율에 따라 지속해서 CPU 크레딧을 받고, 크레딧을 사용하여 기본 CPU 성능을 넘은 “성능 순간 확장”이 가능합니다. 간단한 테스트 서버가 필요할 경우 T2 타입의 인스턴스를 사용하면 좋습니다 ^^

RDS

이음에서는 MYSQL을 사용하고 있습니다. RDS에서 Mysql Engine을 선택하여 Master 1대, Read Replica 1대를 사용하고 있습니다. 그리고 Provisioned IOPS 옵션은 2000으로 사용하고 있습니다.

RDS 인스턴스는 종료하지 않고 인스턴스 타입을 변경할 수 있습니다. (물론 다운타임은 있습니다) 또한, Replica를 생성할 수 있는 기능도 있어서 관리 측면에서는 매우 좋습니다. RDS는 다른 서비스에 비해 상당히 비싼 편입니다. 하지만 관리적인 측면에서 매우 편하기 때문에 사용하고 있습니다.

최근에 RDS 오로라 엔진이 나왔습니다. 오레곤 리전에 인스턴스를 만들어서 사용해보고 있습니다. 이음 개발팀에서는 긍정적으로 보고 있고 빨리 도쿄리전에서 사용할 수 있었으면 하는 바람입니다.

S3

S3는 장점이 매우 많아 활용도가 무궁무진한 서비스입니다. 비용이 매우 저렴하고 오브젝트에 설정할 수 있는 옵션도 많습니다. Bucket에 로깅 기능도 있기 때문에 쉽고 편하게 사용할 수 있습니다. 그래서 이음에서 사용하는 모든 이미지는 S3에 저장하고 static 이미지들 또한 S3에 업로드하여 사용합니다. 또 이벤트 페이지가 필요할 때, 마크업을 작성하여 S3에 올려서 배포하여 사용하고 있습니다.

관리 측면에서 보면 S3는 정말 좋은 서비스입니다. 보통 static 서버를 따로 구성하게 되면 용량이 찼을 때, 증설 작업을 해줘야 합니다. 하지만 S3는 scale-out, 용량 증설에 고민할 필요가 없습니다. 다양한 서비스에 붙여서 사용할 수 있는 아주 매력적인 서비스입니다. (제가 정말 좋아해요..)

CloudFront

CloudFront는 S3에 업로드된 오브젝트를 배포할 때 사용합니다. 한국을 비롯한 세계 각 리전에 엣지가 있고 S3와 연동 쉬워서 매우 편리합니다. 이음에서는 프로필 이미지, 뱃지 이미지를 포함한 대부분 이미지를 signed URL을 사용하여 배포되고 있습니다.

이음은 AWS와 향후 1년간 CDN 서비스로 CloudFront만 사용하겠다는 Exclusivity 계약을 맺고 사용하고 있습니다. 위 계약을 맺게 되면 비용절감을 할 수 있습니다.

Route53

서비스 도메인 i-um.net, i-um.com의 DNS 서비스를 Route53로 옮겨서 사용하고 있습니다.  Route53는 비용도 저렴하고, 도메인 구입 비용도 비싸지 않습니다. 그리고 AWS의 다른 서비스들과 같이 사용하면 매우 편합니다. ELB, S3 웹호스팅, EIP, CloudFront와 연동이 매우 쉬우므로 좋습니다. 도메인 연결을 AWS Console에서 할 수 있기 때문이기도 하고요.

CloudWatch

ELB, EC2, EBS, RDS, SNS, Auto-Scaling Group의 상태를 모니터링합니다.. 이음에서는 CPU, DISK 등 다양한 기준을 두고 해당 조건에 맞으면 이메일, SMS로 알려줍니다. 그리고 특정 조건에 Auto-Scaling 되도록 연동하여 사용하고 있습니다.

CPU 올라간다~

CPU 올라간다~

SES

SES를 사용하면서 크게 문제 있었던 적은 없었으나, 이메일 반환율 때문에 메일이 온 적이 있습니다. 메일 전송시 반환비율이 높아지면 경고 메일이 옵니다. 반환율이 일정 비율을 넘기면 SES 서비스가 블럭 되므로 평소에 잘 관리해야 합니다.

SNS

이음에서 전송하는 모든 푸쉬는 SNS를 통해서 나갑니다. 여러 디바이스에 한 번에 보낼 수 있어서 매우 편리합니다. PUSH뿐만 아니라 CloudWatch에서 설정한 Alarm을 메일 또는 메세지로 보내주기도 합니다. SNS 내에 SMS를 보내주는 기능이 없어서 SMS 서버를 만들었습니다. 그리고 SNS에서 HTTP로 Call 하도록 구성했습니다.

맺음말

마지막으로 이음에서 사용하는 모든 서비스를 그림으로 그려봤습니다.

스크린샷 2015-07-03 오전 11.05.44

현재 개발팀은 RDS 오로라와 람다 서비스에 많은 관심을 기울이고 있습니다. 오로라는 서베이 후 괜찮다 싶으면 시범적으로 사용해볼 예정입니다. 람다의 경우 아직 Javascript, Java밖에 지원하지 않는 점이 아쉽습니다. AWS는 운영하면서 중간중간 변화를 주는 묘미가 있고 틈나는 대로 구성을 변경하고 있습니다. 앞으로도 더 좋은 서비스가 나오기를 바라면서 마칩니다.

 

PS. 항상 도움을 주는 AWS 팀에게 감사드립니다.

고통과 함께한 GITLAB(깃랩) 업데이트

안녕하세요. 이음소시어스 개발팀 서버개발자 육승찬(루)입니다.

저희 개발팀에서는 깃랩을 사용하고 있습니다. 이번에 깃랩 버전을 업데이트하게 되었고, 그 과정에서 겪은 경험을 공유하면 좋을 것 같아 “고통과 함께한 GITLAB(깃랩) 업데이트” 주제를 가지고 포스트를 작성하게 되었습니다.

GITLAB ?

Create, review and deploy code together

GITLAB(깃랩)은 설치형 버전관리 시스템입니다. 오픈소스로 제작되었고 꾸준히 업데이트되고 있습니다. 깃랩은 CE(Community Edition), EE(Enterprise Edtion), GitLab.com(On gitlab server) 세 가지 형태로 존재합니다.  저희 개발팀에서는 CE를 사용하고 있기 때문에 CE기준으로 설명드리겠습니다.

UPDATE ?

저희 개발팀에서는 2년 전 깃랩 6.1을 BITNAMI로 설치하여 사용해오고 있었습니다.  현재 깃랩 최신 버전이 7.9.2라는 것을 보고 업데이트가 필요하다고 생각이 들기도 했고, 개인적으로 써보고 싶어서 팀장님께 깃랩 업데이트를 제안 드렸습니다.

daum_net_20150321_204544

팀장님도 좋다고 하셔서 업데이트하기로 했습니다. (이때 고통이 뒤따를지 생각지도 못했습니다)

최근의 깃랩은 gitlabhqomnibus-gitlab으로 배포되고 있습니다. gitlabhq를 이용하여 설치하면 DB, REDIS 등 여러 소프트웨어를 직접 설치하고 깃랩에 연결하여 사용했었습니다. 하지만 omnibus-gitlab는 필요한 소프트웨어가 포함되어 패키지 형태로 설치됩니다. 또한, omnibus-gitlab는 기타설정이 매우 쉬우므로 관리하기가 좋습니다.

그래서 개발 서버에 설치된 깃랩 6.1을 omnibus-gitlab으로 업데이트하고자 하였습니다.

HOW ?

  • 제가 생각했던 첫 번째 (실패한)방법입니다.

스크린샷 2015-04-15 오후 3.07.04

먼저 깃랩 6.1에서 데이터를 백업하고 omnibus-gitlab을 설치하여 데이터를 복구하는 것이었습니다. 깃랩은 데이터 백업과 복구기능을 지원하기 때문에 다음 명령어로 데이터를 백업할 수 있습니다.

백업이 완료되면 tmp/bakups 안에 [timestamp]_gitlab_backup.tar 형태의 파일이 저장됩니다.  백업이 완료된 후 omnibus-gitlab을 설치합니다. 패키지 형태로 배포되고 있기 때문에 설치가 매우 쉽습니다. 자세한 설치방법은 깃랩 홈페이지에 있습니다.

omnibus-gitlab 설치가 완료되면 /var/opt/gitlab/backups 안에 위에서 백업한 파일을 옮기고 아래 복구 명령어를 실행했습니다.

그러면 아래와 같은 에러가 발생합니다.

그렇습니다.. 깃랩 백업&복구는 버전이 다르면 적용할 수 없습니다.

으아니

아니 이게 무슨소리요…

  • 두 번째 (실패한)방법입니다.

스크린샷 2015-04-15 오후 3.26.57

 

깃랩은 버전별로 업데이트하는 가이드를 제공하고 있습니다.  저는 gitlab 6.x or 7.x to 7.9(해당 링크는 계속해서 업데이트 되기 때문에 링크가 깨질 수 있습니다. 만약 링크에서 404에러가 난다면 여기로 접속해보세요.) 업데이트 가이드를 참고했습니다. 가이드에 나와 있는 방법대로 업데이트를 진행하고 있었는데 문제가 하나 발생했습니다. 현재 서버에 설치되어있는 gitlab-shell 프로젝트가 깃 프로젝트가 아니었습니다. 일단 gitlab-shell 프로젝트 관련 내용을 넘기고 나머지 커맨드를 입력하고 있었는데 데이터베이스 마이그레이션 부분에서 gitlab-shell 관련해서 에러가 났습니다.

daetul_mung

결국 BITNAMI로 설치 된 깃랩을 업데이트하는 것을 포기했습니다.

  • 세 번째 (성공한)방법입니다.

스크린샷 2015-04-15 오후 3.37.45

 

처음 생각했던 것보다 많이 복잡해졌습니다.. 하지만 희망을 가지고 (BITMANI)깃랩 6.1에서 데이터를 백업하고, 임시로 가상 인스턴스를 만들어서 깃랩을 6.1로 설치했습니다. 그리고 앞에서 백업한 파일을 복구하고 버전 업데이트를 진행했습니다. 버전 업데이트는 두 번째 방법에서 참고한 가이드를 똑같이 따라 했습니다. 업데이트는 순조롭게 진행되었고 데이터 백업까지 할수 있었습니다.

그리고 omnibus-gitlab 7.9.2를 설치했고, 깃랩 7.9.2에서 백업한 데이터를 복구하려 했습니다. 하지만 또 다시 에러가 발생했습니다.. 에러 내용은 데이터베이스 관련 에러입니다. 구글에 조금 찾아보니 깃랩을 ommibus-gitlab으로 마이그레이션하는 방법이 있었습니다. 내용을 요약하면 이렇습니다.

omnibus-gitlab에서는 PostgreSQL를 사용합니다. 만약 이전에 MySQL을 사용했다면 백업한 mysql query를 PostgreSQL query로 변경해야 됩니다. 변경 방법은 mysql-postgresql-converter 프로젝트를 이용해서 변경할 수 있습니다. 그래서 백업한 tar를 풀어서 database.sql을 PostgreSQL query로 변경하고 다시 압축한 후에 복구 명령어를 실행하면 복구가 됩니다. 이 방법을 자세하게 설명한 블로그가 여기있습니다. 참고하세요 ^^

CONCLUSION

일단 업데이트를 완료하고 한숨부터 나오더라구요..

유병재_SNL코리아_극한직업_모음_보기qd

왜 사람들이 그냥 GitHub, BitBucket 서비스를 사용하는지 이해가 가기도 했고요. 글을 정리하면서 몇 가지 팁을 적어보겠습니다.

  • 업데이트를 계획하신다면 omnibus-gitlab으로 업데이트하세요. omnibus-gitlab을 적용하려고 하지 않았다면 과정이 단순해질 수도 있었습니다. 하지만 앞으로 사용하고 관리하는 데 있어서 omnibus-gitlat이 더 좋다고 판단하여 업데이트했습니다.
  • 업데이트는 반드시 임시 가상서버에서 진행해보고 실제 서버에 적용하세요. 만약 제가 실 서버에서 바로 적용했다면 개발팀이 힘들었을 것 같습니다.
  • 끝까지 힘을 내요! (슈퍼파월) 
rsz_1iumstellar

우린 답을 찾을 것이다. 늘 그랬듯이..