Data Center 업그레이드 가이드
모든 조직은 서로 다르며 마이그레이션 여정도 다릅니다. 단계별 업그레이드 가이드에 따라 Atlassian Server에서 Data Center로 원활하게 마이그레이션하세요.
펑가
조직마다 고유한 요구 사항이 있으므로 성공적인 업그레이드를 계획하려면 가능한 선택을 이해하는 것이 중요합니다.
아키텍처 및 인프라 요구 사항 이해
Data Center로 결정하셨습니까? 지원되는 Data Center 아키텍처 및 배포 구성을 파악해야 합니다.
Data Center는 단독 시스템 또는 클러스터형의 2가지 방식으로 배포할 수 있습니다. 둘 다 엔터프라이즈 기능을 활용할 수 있지만, 각 옵션에는 서로 다른 고려 사항이 있습니다. 비클러스터형과 클러스터형 아키텍처 간의 차이를 나타내는 표는 다음과 같습니다.
비클러스터형 권장
인프라 요구 사항
비클러스터형 아키텍처에서는 기존 인프라에서 Data Center로 업그레이드할 수 있어 인프라를 변경할 필요가 없습니다.
권장 사용 사례
모든 고객에게 단독형 업그레이드 경로를 사용하여 Data Center로 업그레이드할 것을 권장합니다. 필요한 경우 고객은 Data Center를 사용하여 클러스터형 아키텍처를 구현할 수 있습니다.
혜택
클러스터링에 의존하지 않는 Enterprise 기능을 활용합니다.
보통 많은 고객이 Data Center 여정을 시작하는 곳은 단독형 업그레이드입니다. 원활한 전환을 위해 2분 업그레이드를 활용하는 것이 좋습니다.
클러스터형
모든 고객에게 먼저 단독형 업그레이드 경로를 사용하여 Data Center로 업그레이드할 것을 권장합니다. Data Center를 성공적으로 업그레이드한 후 필요한 경우 고객은 클러스터형 아키텍처를 구현할 수 있습니다.
인프라 요구 사항
클러스터형에서 Data Center로 업그레이드하려면 다음 구성 요소가 필요합니다.
- 로드 밸런서
- 애플리케이션 노드
- 모든 애플리케이션 노드에서 액세스 가능한 파일 시스템
- ElasticSearch 노드(Bitbucket)
권장 사용 사례
- 고가용성이 필요한 경우
- 가동 중지 시간 없이 업그레이드하려는 경우
- 단기간에 매우 큰 규모의 확장이 예상되는 경우
혜택
클러스터링에서 제공할 수 있는 엔터프라이즈 기능을 잠금해제 하세요.
- 엔터프라이즈 기능
- 고가용성 및 장애 조치 – 애플리케이션 클러스터의 노드 하나가 작동 중단되면 다른 노드에 부하가 분산되어 사용자가 중단 없이 제품에 액세스할 수 있습니다.
- 즉각적인 확장성 – 가동 중지 시간 또는 추가 라이선싱 비용 없이 클러스터에 새 노드를 추가합니다. 인덱스와 앱은 자동으로 동기화됩니다.
- 재해 복구 – 전체 시스템 중단이 발생하더라도 비즈니스 연속성을 유지할 수 있도록 오프사이트 재해 복구 시스템을 배포할 수 있습니다. 공유 제품 인덱스를 통해 빠르게 백업하고 실행할 수 있습니다.
계획 및 준비
이제 Data Center 경로를 선택했으므로 세부적인 업그레이드 계획을 만들 준비가 되었습니다.
타임라인 작성 필수 사항
업그레이드 소요 시간을 예측하는 데 사용 가능한 기본 일정표입니다.
| | 비클러스터형 | 클러스터형 |
|---|---|---|
| 계획수립 | 비클러스터형 0–2주 | 클러스터형 1개월 이상 |
| 시험 실행 | 비클러스터형 0–1주 | 클러스터형 3–6개월 |
| 구현 | 비클러스터형 0–1주 | 클러스터형 ~6–9개월 |
포함된 일정은 Data Center로 성공적으로 업그레이드한 몇 개의 고객을 기반으로 하지만 실제 타임라인은 환경의 크기, 복잡도 및 준비 정도를 포함한 환경적 요소에 따라 달라질 수 있다는 점을 참고해야 합니다.
Data Center 환경 정의 필수 사항
애플리케이션 레이어
인스턴스 및 위치
- 인스턴스를 페더레이션하거나 통합하려고 하십니까?
- 향후의 성장은 어떤 모습입니까?
- 데이터 격리가 필요합니까?
- 팀에 스테이징 또는 프로덕션과 같은 환경이 몇 개 있습니까?
인스턴스 프로필
- 얼마나 많은 사용자가 인스턴스에 액세스합니까?
- 팀은 어디에 위치합니까?
- 현재 인스턴스에 있는 데이터의 양 및 인스턴스에 추가할 데이터의 양은 어느 정도입니까?
앱, 통합 및 사용자 지정
전부 필요합니까? 또는 이번이 단순화할 수 있는 기회입니까?
인프라 계층
인스턴스 크기 조정
- 향후 성장 전망은 어떻습니까?
- 사용자 트래픽 수준이 낮은 시간이 있습니까?
자세한 내용은 노드 크기 조정 개요를 참조하세요.
계정 구조
- 어떤 계정에 환경을 배포해야 합니까?
- 각 환경에 서로 다른 계정을 연결하려고 합니까?
- Data Center 제품에서 다른 CI/CD 또는 협업 도구와 같은 계정을 사용하려고 하십니까?
거버넌스 모델
- 거버넌스 모델은 무엇입니까?
- 최소 시스템 표준은 무엇입니까?
- 중앙 집중식 로깅을 사용하고 있습니까?
- 사용자 관리 요구 사항은 무엇입니까?
거버넌스 모델의 일부로 AWS 랜딩 존 및 AWS 시스템 관리자를 사용하는 것을 고려하세요.
VPC
-
새로운 VPC(가상 사설 클라우드)를 사용하려고 합니까?
새 VPC에 배포하거나 기존 VPC를 사용하려는 경우 ASI(Atlassian 표준 인프라) 템플릿을 활용할 수 있습니다.
- 사무실 및 VPN 네트워크 라우팅에 대해 공용 인터넷 액세스 및 내부 IP 주소 지정을 제한하는 등 변경하려는 네트워크 원칙이 있습니까?
- TLS 인증서를 사용해야 합니까?
지역
-
기존 VPC를 사용하는 경우 사무실 및 VPN 네트워크 액세스에 대한 계획을 세우셨습니까?
시간이 지남에 따라 제품 사용량이 증가할 가능성이 높으므로 모든 사무실과 VPN에 대한 액세스를 허용하는 것이 좋습니다.
Direct Connect
- 성능 및 보안을 위해 Direct Connect를 사용하려고 하십니까?
- Server 인스턴스에서 Data Center로 마이그레이션하는 데 필요한 데이터의 양은 어느 정도입니까?
AWS Snow Family는 대량의 데이터를 마이그레이션하는 경우 고려해볼 수 있는 리소스입니다.
비즈니스 연속성 및 재해 복구
백업
백업 전략은 어떻습니까?
기존 백업 전략과 AWS에서 기본적으로 제공하는 백업 기능을 함께 사용하는 것이 좋습니다. 자세한 내용은 다음을 참조하세요.
AWS는 단일 중단 가능성이 낮은 인프라 서비스를 제공합니다.
리전 장애 조치
다른 리전에 콜드 사이트, 웜 사이트 또는 핫 사이트를 구현해야 합니까?
일반적으로 재해 복구 요구 사항은 서비스를 여러 가용성 영역에서 실행하여 충족되지만 리전 중단도 완화하려 할 있습니다. 이러한 사이트를 다른 리전에서 구현할지 결정할 때 다음 사항을 고려하세요.
- 인프라 및 데이터 전송 비용
- AWS 대비 복구 속도 비교
- 복구 사이트의 유지 관리 및 테스트에 소요되는 시간
- 사이트 운영 비용
Data Center로 업그레이드(단독형) 권장
모든 고객에게 단독형 아키텍처를 사용하여 Data Center로 업그레이드할 것을 권장합니다. 단독형 업그레이드는 더 빠르고 간소화된 업그레이드 옵션으로 Data Center의 보안, 지원 및 엔터프라이즈 기능에 더욱 빠르게 액세스할 수 있습니다.
Data Center로 업그레이드(클러스터) 권장하지 않음
업그레이드가 복잡하기 때문에 클러스터형 아키텍처에서 Data Center로 초기 업그레이드하는 것은 권장하지 않습니다. 모든 고객에게 먼저 단독형 업그레이드 경로를 사용하여 Data Center로 업그레이드할 것을 권장합니다. 그 이후에 클러스터형 아키텍처가 필요한 고객은 구현을 시작할 수 있습니다.
단독형 아키텍처에서 Data Center로 업그레이드한 후에 높은 가용성이 필요한 경우 클러스터형 아키텍처를 구현할 수 있습니다.
클러스터에 필요한 인프라 확보
클러스터에 Data Center를 배포하려면 다음의 구성 요소가 필요합니다.
- 데이터베이스
- 로드 밸런서
- 애플리케이션 노드
- 공유 파일 시스템
- ElasticSearch 노드(Bitbucket)
로드 밸런서
클러스터에서 배포한 경우 사용자의 요청이 처음으로 닿는 것은 로드 밸런서입니다. 로드 밸런서에 요청이 들어오면 로드 밸런서는 각 요청을 애플리케이션 노드에 분산합니다. 로드 밸런서는 하드웨어 또는 소프트웨어 기반 모두 사용 가능합니다. 소프트웨어 및 하드웨어 솔루션 모두, 로드 밸런서는 높은 대역폭과 낮은 대기 시간을 보장하도록 고속 LAN 연결을 사용하여 애플리케이션 클러스터에 연결되어야 합니다. 모든 소프트웨어 로드 밸런서는 전용 머신에서 실행되어야 합니다.
Data Center 제품은 세션 중에 각 사용자의 요청이 같은 노드로 이동한다고 가정합니다. 요청이 다른 노드로 이동하면 사용자가 예기치 못하게 로그아웃될 수 있으며, 세션에 저장된 정보를 잃게 될 수도 있습니다. 따라서 로드 밸런서에 쿠키 기반의 '고정 세션'(또는 세션 선호도)을 사용 설정하여 세션을 같은 노드에 연결해야 합니다. 쿠키 기반의 고정 세션을 사용하면 제품에서 발행한 쿠키 또는 로드 밸런서에서 생성한 쿠키를 사용 가능합니다.
로드 밸런싱 솔루션에 이중화를 더해 더 강력하게 보호하고 로드 밸런서가 단일 실패 지점이 되는 것을 방지하세요. 이 작업은 로드 밸런서 2개에 걸친 가상 IP를 사용하여 로드 밸런서 2개를 액티브-패시브 구성으로 설정하여 가능합니다. 액티브 로드 밸런서가 실패하면 패시브 로드 밸런서로 장애 조치합니다.
자세한 정보는 부하 분산 장치 구성 옵션을 참조하세요.
애플리케이션 노드
실제 제품은 애플리케이션 노드에 있습니다. Data Center 클러스터의 각 노드는 같은 버전의 제품을 실행하고 지연 시간을 최소한으로 유지하기 위해 함께 위치해야 합니다. 하지만 CDN(콘텐츠 전송 네트워크)을 사용 설정하여 지역적으로 분산된 팀의 성과를 지원할 수 있습니다. 이러한 노드는 클러스터에 구성되어 하나로서 역할을 하여 사용자에게 제품을 제공해야 합니다. 클러스터에 있는 노드의 수는 요구 사항 및 제품을 구성하는 방법에 따라 다릅니다. 일반적으로 대부분의 클러스터에는 2~4개의 노드로 충분하지만 적합한 결정을 내리려면 노드 크기 가이드를 사용하세요.
Bitbucket에는 코드 검색을 지원하는 ElasticSearch 전용 추가 애플리케이션 노드가 필요합니다.
공유 파일 시스템
공유 파일 시스템은 첨부 파일 및 Git 리포지토리 등 모든 애플리케이션 노드에서 액세스할 수 있는 데이터를 저장하는 곳입니다.
Data Center 환경에서는 공유 파일 시스템을 자체적인 노드로 설정해야 합니다. 공유 파일 시스템에는 NFS 기반의 모든 NAS 또는 SAN 프로그램을 사용 가능하지만, 성능 유지를 위해서 NFS3을 권장합니다. DFS와 같은 분산된 프로토콜은 지원하지 않으므로 피하시기 바랍니다.
스테이징 환경 만들기
여러 노드로 성공적으로 업그레이드하려면 프로덕션에 구현하기 전에 스테이징 환경을 만들어 Data Center를 사용해 보는 것이 좋습니다.
스테이징 환경은 역방향 프록시, SSL 구성, 또는 부하 분산 장치를 포함하여 환경을 비슷하게 복제해야 합니다. 다른 물리적 서버나 가상 솔루션을 사용할 수도 있습니다. 중요한 점은 스테이징 환경이 프로덕션 환경의 적절한 복제본이어야 한다는 것입니다.
자세한 지침은 다음을 참조하세요.
전문가와 상담하기
마이그레이션 옵션 또는 경로와 관련해 질문이 있으십니까? 마이그레이션 전문가 팀의 전문적인 안내를 받으세요.