Inside ArenaNet: Live Game Outage Analysis

유럽 그날의 기억.하루 반나절 접속불가 초유의 사태  출처 : 길드워2 뉴스, 인사이드 아레나넷 : '라이브 게임 중단 분석'<<a href="https://www.guildwars2.com/en/news/inside-arenanet-live-game-outage-analysis/" target="_blank" class="ke-link">https://www.guildwars2.com/en/news/inside-arenanet-live-game-outage-analysis/</a>>구글 번역  ===================================================== <div class="figure-img" data-ke-type="image" data-ke-style="alignCenter" data-ke-mobilestyle="widthOrigin"><img src="https://t1.daumcdn.net/cafeattach/1Z7o7/4332f55906a156742f0e32ababfb0f5b2b73091e" class="txc-image" width="590" height="332" data-img-src="https://t1.daumcdn.net/cafeattach/1Z7o7/4332f55906a156742f0e32ababfb0f5b2b73091e" data-origin-width="590" data-origin-height="332"></div>안녕하세요! 저는 ArenaNet의 플랫폼 팀 리더인 Robert Neckorcuk입니다. 우리 팀은 로그인 서버, 채팅 서버, 웹사이트 등 Guild Wars® 프랜차이즈를 위한 다양한 백엔드 네트워크 서비스를 운영하고 있습니다. 우리는 백엔드 서비스 그룹으로서 Game Operations 및 Release Management라는 두 개의 다른 팀과 매우 긴밀하게 협력합니다. 또한 게임 플레이, 분석, 고객 지원 등과 협력하지만 핵심 초점은 게임 및 해당 인프라의 라이브 상태를 유지하는 것입니다. 길드 워 프랜차이즈가 인상적인 온라인 가용성을 인정 받고 있습니다. 인프라의 성공을 축하하지만 우리는 또한 도전에 직면했습니다. 오늘 저는 마지막 주요 사건에 대한 세부 사항과 귀하에 대한 약속을 계속 개선하기 위해 배운 교훈을 공유할 것입니다.2020년 5월 11일 월요일 오전 6시(태평양 표준시)에 전화를 받았습니다. 장담할 수 있습니다. 이 날짜를 찾을 필요가 없었습니다. 이 날짜는 여전히 저에게 매우 생생한 기억입니다. 우리 게임 운영 팀은 라이브 Guild Wars 2 데이터베이스가 롤백되었고 플레이어는 게임 서버에서 일관되지 않은 정보를 얻었고 우리 내부 도구에는 수많은 기타 관련 경보 및 오류가 표시되었다는 페이지가 있었습니다.아, 새끼 고양이.나는 덜 신나는 월요일을 보냈다. 사실 나는 덜 신나는 월요일을 더 좋아한다. 내 작업 컴퓨터에 로그온하여 나는 무슨 일이 일어났는지, 그리고 게임을 정상 상태로 되돌리기 위해 우리가 할 수 있는 일을 조사하는 사람들과 합류했습니다. 목표가 "항상 온라인"인 팀과 회사의 경우 조사 결과 데이터를 양호한 상태로 복원하려면 게임을 종료해야 한다는 최악의 두려움이 있었습니다. 이런 사건은 처음이라 어떤 승인이 필요한지 파악하는 데 시간이 걸렸습니다. 오전 9시가 조금 넘어서 유럽 지역에서 게임 로그인을 비활성화하고 서버를 종료하는 Guild Wars 2 서버를 종료하는 변경 사항을 제출했습니다 .끊임없이 반복이 서비스 중단 기간 동안 Guild Wars 2 는 유럽 데이터 센터에서 20시간 넘게 중단되었습니다. 몇 분 동안의 짧은 순간을 제외하고 이전 Guild Wars 2 종료는 2016년 8월 23일에 발생했습니다. 실제 영향을 미치는 문제를 처리하는 것은 결코 즐거운 일이 아니지만 이러한 사건을 인프라를 개선하고 인프라를 개선하기 위한 학습 기회로 사용할 수 있습니다. 프로세스. 당사의 사고 프로세스는 게임 업계 안팎의 많은 라이브 서비스 회사의 프로세스를 따릅니다.<ul style="list-style-type: disc;" data-ke-list-type="disc"><li>문제의 범위를 식별합니다. 하나의 서버, 하나의 데이터 센터 또는 하나의 빌드에서 발생합니까? 조사 범위를 더 작은 서비스 또는 지역으로 좁힐 수 있는지 확인하십시오.</li><li>가능한 한 빨리 서비스를 실행할 수 있는 경로를 식별하십시오. 이는 정확성과 가용성 간의 균형입니다. 우리가 무언가를 함께 해킹하여 서비스를 작동시키면 다른 무언가가 깨질까요?</li><li>서비스가 다시 실행되면 사건 보고서를 작성하십시오. 이 보고서는 발생한 일, 문제에 대한 정보, 취한 조치 및 영향을 받은 사람을 자세히 설명해야 합니다.</li><li>나중에 정규 업무 시간 동안 주요 이해 관계자와 회의를 설정하여 사건 보고서를 검토하고 후속 항목에 대한 작업을 생성합니다. 조치 항목은 경고 또는 감지 개선, 문서 또는 자동화 프로세스 업데이트, 또는 새 도구 구축일 수 있습니다. .</li></ul>우리는 우리의 프로세스와 절차를 살펴보고 변경하는 것은 사고 중에만 아닙니다. 2017년 ArenaNet은 AWS 인프라를 활용하여(다운타임 없이!) 현장 데이터 센터에서 클라우드 기반으로 마이그레이션하기로 결정했습니다. 2020년에 원격 작업에 적응한 후 분석 로깅 파이프라인을 하드웨어 기반 제공업체에서 클라우드 제공업체로 마이그레이션하는 작업을 완료했습니다.이러한 모든 클라우드 마이그레이션의 이유는 유연성을 제공하기 때문입니다. 인프라를 지속적으로 빠르고 원활하게 변경하고 수정할 수 있는 옵션이 있습니다. 2020년 초에 우리는 개발 상거래 서버에서 라이브 PvP 예약 서버에 이르기까지 실행 중인 모든 서버의 비용과 옵션을 살펴보고 전체적인 내부 AWS 업그레이드를 시작했습니다. AWS는 지속적으로 새로운 서비스와 새로운 하드웨어 유형을 제공하고 있으며 2017년 이후로 전체 감사를 수행하지 않았습니다. 이 계획을 통해 우리는 라이브 게임에서 플레이어 경험을 개선하고 개발 환경을 라이브 게임에 맞추기 위해 변경하고, 여러 백엔드 도구를 개선합니다. 또한 2017년 마이그레이션 이후로 한 번도 변경되지 않았거나 다시 시작되지 않은 몇 대의 서버도 업데이트했습니다!큰 프로젝트를 다룰 때 가장 효과적인 전략 중 하나는 프로젝트를 더 작고 관리하기 쉬운 덩어리로 나누는 것입니다. 마치 큰 피자를 썰듯이 말입니다! 우리는 모든 AWS 인스턴스를 살펴보고 싶었고 다행히 게임 서버, 데이터베이스 서버, 상거래 서버 등 다양한 인스턴스 유형의 "버킷"이 이미 여러 개 있었습니다. 우리의 계획은 이러한 각 인스턴스를 한 번에 하나씩 살펴보고 변경하는 것이었습니다. , 다음 그룹으로 이동합니다. 각 변경 세트에 대해 내부 개발 서버를 마이그레이션하는 것으로 시작했습니다. 프로세스를 문서화하고 동작을 확인하는 Runbook을 작성한 다음 Runbook 단계에 따라 준비 및 라이브 환경을 마이그레이션합니다.모든 제품과 회사에서 반복 능력은 절대적으로 중요합니다. 자신의 뒤뜰에 물건을 만들고, 부숴 버리고, 가능한 한 자주 이상하게 부수십시오. 내부적으로 모든 것을 수정하고 나면 대중에게 공개될 때 꽤 탄력적이어야 합니다. 플랫폼 및 게임 운영 팀의 경우 이 "플레이 방식 연습" 프로세스는 서비스 품질을 지원하는 벨트의 또 다른 도구입니다. 그렇긴 해도 개발 서버와 라이브 게임 서버는 비용과 규모 면에서 크게 다르므로 모든 것이 동일하게 작동하기를 바라는 한 매우 독특합니다.데이터베이스에 대한 몇 가지 (매우 단순화된!) 배경: 기본 서버와 보조 서버의 두 대가 있습니다. 데이터베이스에 쓸 때 "이 변경을 수행하십시오"라는 메시지가 기본 인스턴스로 전송됩니다. 그런 다음 주 서버는 "이 변경을 수행하십시오"라는 메시지를 보조(또는 미러)에 보낸 다음 변경 내용을 자체에 적용합니다. 기본 인스턴스에 "나쁜 일"이 발생하면 보조 인스턴스가 자동으로 인계받아 기본 인스턴스로 보고합니다. 즉, 다운타임이나 데이터 손실이 없으며 새 기본이 "나쁜 것"에서 복구되면 "새 보조"에 보낼 메시지를 대기열에 넣습니다. 인스턴스를 업그레이드하려면 기본 및 보조 데이터베이스의 연결을 수동으로 끊고 보조 데이터베이스를 업그레이드한 다음 다시 연결합니다.추적할 수 있는 중요한 데이터 포인트 중 하나는 보조가 기본에서 대기 중인 모든 메시지를 수신하고 데이터 패리티로 돌아가는 데 걸리는 시간입니다. 다른 로드 및 상태 메트릭과 결합하여 서버가 건강한지 여부를 알려줄 수 있으며 개인적으로 그래프가 매우 매력적입니다. 그런 다음 1차와 2차를 교체하고 헹구고 반복합니다. 이제 완전히 업그레이드된 환경과 함께 훨씬 더 예쁜 그래프가 생겼습니다. 개발 환경에서는 모든 것이 원활하게 실행되었습니다. 우리의 스테이징 환경은 프로세스를 종단 간 실행할 수 있는 또 다른 기회를 제공했으며 원활하게 실행되었습니다. 2020년 5월 6일 수요일에 유럽 지역 서버로 라이브 게임 업그레이드를 시작했습니다.   나쁜 일들이 있는 곳<div class="figure-img" data-ke-type="image" data-ke-style="alignCenter" data-ke-mobilestyle="widthOrigin"><img src="https://t1.daumcdn.net/cafeattach/1Z7o7/7e5ef363aa4dba5b4ab830a6f08845e93acf9e5d" class="txc-image" width="590" height="318" data-img-src="https://t1.daumcdn.net/cafeattach/1Z7o7/7e5ef363aa4dba5b4ab830a6f08845e93acf9e5d" data-origin-width="590" data-origin-height="318"></div>5월 6일에 실제 업그레이드가 계획대로 진행되었습니다. 연결을 끊고 보조를 업그레이드한 다음 연결을 다시 설정했습니다. 대기열에 있는 메시지를 복사하고 기본 및 보조를 교환하고 해당 작업을 다시 한 번 반복했습니다. 메시지 복사는 개발 환경에서 실행하는 것보다 약간 느렸지만 라이브 게임의 트래픽 볼륨을 감안할 때 훨씬 더 큰 대기열이 있었습니다.5월 7일 목요일에 "디스크 공간이 거의 꽉 찼습니다" 경보가 발생했습니다. 우리는 최근에 데이터를 추가로 백업하여 공간을 약간 차지했지만 모범 사례에 따라 디스크 볼륨을 확장하는 데 관계없이 지시했습니다. 스토리지는 저렴하고 AWS에서는 몇 번의 마우스 클릭으로 로그 및 백업 드라이브 크기를 두 배로 늘릴 수 있습니다. 게임 운영 팀의 한 구성원이 마우스를 몇 번 클릭했지만 확장된 스토리지 크기가 마술처럼 나타나지 않았습니다. 금요일에 AWS에 지원 티켓을 제출했으며 AWS는 문제를 해결하기 위해 다시 시작할 것을 권장했습니다. 이 서버가 현재 기본 서버였으므로 다시 시작하기 전에 보조 서버로 교체해야 합니다.뒤돌아보고 명백한 실수를 인식하는 것은 매우 쉽지만 당시 우리는 우리가 몰랐던 것을 몰랐습니다. 금요일 오후에 우리는 빠른 재시작을 수행할 수 있도록 1차와 2차를 바꾸려고 했습니다. 그러나 당시에는 1차에서 2차로의 메시지 큐가 비어 있지 않았고 여전히 느리게 복사되고 있었습니다. 일부 계산에 따르면 주말에는 하드 드라이브가 완전히 채워지지 않아 월요일 아침에 돌아와 대기열에 있는 메시지를 살펴보고 서버를 교체하고 다시 시작할 수 있습니다.우리는 확실히 월요일에 돌아왔습니다…대기열에 있는 메시지가 느리게 전송되고 있음을 인식했지만("거북이 속도" 생각) 대기열이 증가하는 속도("제트팩 거북이 속도" 생각)를 고려하지 못했습니다. 기본 데이터베이스에 "나쁜 일"이 발생하면 보조 데이터베이스가 자동으로 새 기본 데이터베이스로 인계된다는 다소 정확한 진술을 상기하십시오. 자동 장애 조치를 유발하는 "나쁜 일" 중 하나는 이 메시지 대기열이 너무 커지는 것입니다.5월 11일 월요일 오전 2시 41분에 "나쁜 일" 임계값이 초과되었고 데이터베이스가 기본 및 미러로 바뀌었습니다. 데이터베이스 업데이트 메시지가 모두 다른 서버의 대기열에 있었기 때문에 데이터베이스가 장애 조치되었을 때 갑자기 플레이어는 금요일 저녁 이후의 모든 진행 상황이 지워지면서 갑자기 시간 여행(좋은 종류가 아님)을 경험했습니다. 고통스러운 세 시간 후인 오전 5시 40분에 플레이어 보고가 증가하자 게임 운영 팀이 호출되었습니다. 나는 오전 6시에 전화를 받았고 게임은 오전 9시에 종료되었습니다.게임이 다운되자마자 우리의 첫 번째 단계 중 하나는 주 서버를 다시 시작하는 것이었고 예상대로 확장된 디스크 볼륨이 나타났습니다! 좋은 소식입니다. 새로 확장된 디스크에서 가장 최근의 자동 백업 파일과 대기 중인 모든 메시지가 포함된 로그를 찾았습니다(오전 2시 41분까지).백업을 저장하는 것이 좋습니다. 스토리지가 저렴하고 데이터 복구 옵션이 있으면 안심할 수 있으며 자동 백업을 예약하기가 매우 쉽습니다. 그러나 실제로 해당 백업을 사용하여 데이터를 복원하는 것은 다른 이야기입니다. 주로 자주 하지 않기 때문입니다. 한편으로는 데이터베이스에 부하가 없었기 때문에 모든 것을 해체하고 필요할 경우 다시 시작할 수 있었습니다. 반면에 게임이 중단되었고 게임을 다시 실행하기 위해 데이터를 빠르고 정확하게 복원해야 한다는 엄청난 압박감을 느꼈습니다.(참고: 저는 메인 스토리 스레드에 초점을 맞출 것이지만 이 시점에서도 Trading Post, Gem Store, 새 계정 생성 등에 더 큰 영향을 미치는 것에 대한 일련의 부수적인 조사가 있었습니다. 많은 일이 일어났습니다. 이 사건 동안 많은 다른 팀의 의견을 들었습니다. 이 하나의 사건에 대한 작은 이야기의 전체 책을 쓸 수 있을 것 같은 느낌이 듭니다!)솔직히 복원 프로세스는 꽤 지루했고 모범 사례 가이드를 따랐습니다. 관리 유틸리티에서 버튼을 몇 번만 클릭하면 서버가 빠르게 작동하기 시작했습니다. 시작하기 전에 백업 파일과 로그 파일을 두 번째 서버에 복사하여 둘 다에서 동일한 데이터를 복원하는지 확인해야 했습니다. 그런 다음 서버는 데이터베이스의 상태를 백업 파일에 포함된 모든 것으로 설정합니다. 이 과정은 몇 시간이 걸렸습니다. 그런 다음 기록된 모든 메시지를 적용하므로 결국 두 데이터베이스는 모두 오전 2시 41분까지 정확합니다. 이 작업도 오랜 시간이 걸렸습니다. 첫 번째 서버는 오전 1시 37분에, 두 번째 서버는 오전 4시 30분에 완료되었습니다.(참고 2: 실제로 하는 일 외에 회사나 팀을 선택하는 데 가장 중요한 것은 함께 일하는 사람들일 것입니다. 우리 중 소수가 5시 30분 또는 6시부터 온라인에 접속했습니다. 오전, 낮잠만 자고 다른 방법으로 다음날 이른 시간까지 프로세스를 진행합니다. 일부 서버 베이비시터는 확실히 발생했습니다! 전쟁실의 모든 사람들이 상황을 심각하게 받아들이면서도 스스로를 관리하고 약간의 장난기를 가질 수 있는 능력 이벤트 내내 우리 모두는 과소 평가할 수 없습니다. 이 팀은 그들이하는 일과 그것을 수행하는 방법에 대해 놀랍습니다.)길드 워 2 인프라도 매우 놀랍습니다. 다운타임 없이 업데이트할 수 있으며 악용 방지, 충돌 방지 또는 빌드 없이도 동적 이벤트의 난이도 변경을 위해 게임의 다양한 기능이나 콘텐츠에 영향을 줄 수 있는 돌리고 당기는 많은 손잡이와 레버가 포함되어 있습니다! 5월 12일, 우리는 2016년 이후에 볼 수 없었던 게임의 또 다른 기능인 라이브를 시작하지 않고 라이브를 시작하는 기능을 활용했습니다. 게임은 완전히 온라인 상태가 되어 개발자는 입장할 수 있지만 공개 플레이어는 입장할 수 없습니다.오전 4시 55분에 게임을 "켜고" 내부 개발자, QA 분석가 및 소수의 EU 파트너가 게임에 로그인했습니다. 몇 분 만에 플레이어가 이미 게임이 라이브 테스트 중임을 확인하고 진행 상황이 월요일 아침으로 복원되었다는 사실에 깊은 인상을 받았습니다. 우리가 API를 사용할 수 있게 하면 이런 일이 발생한다고 생각합니다!데이터베이스 상태와 메시지 대기열을 확인하는 라이브 환경의 스모크 테스트 후, 우리는 종료 후 20시간이 넘는 오전 5시 37분에 서버를 공개했습니다. 팀의 모든 사람들은 나를 포함하여 모두가 그들이 사랑하는 세계로 돌아갈 수 있도록 도울 수 있음에 감사했습니다. 나는 또한 몇 시간 더 자는 것이 기뻤다.아휴.몇 시간 동안 휴식을 취한 후 우리 모두는 정확히 실패의 근본 원인이 무엇인지 이해하기 위해 다시 로그인했습니다. 그날 오후, 우리 EU 지역에서 경보가 발생했습니다. 데이터베이스 메시지 대기열 볼륨이 너무 높습니다.고양이 새끼. 다시.새로 발견된 이러한 실패 지점에 대한 몇 가지 경고 메커니즘을 올바르게 식별하고 추가했습니다. 다음 이틀 동안 우리는 데이터베이스 미러링과 기본 및 보조 간의 연결을 수동으로 관리했습니다. AWS의 데이터베이스 관리자, 네트워크 운영자 및 기술 계정 관리자와 이야기를 나눴습니다. 메시지 대기열, 볼륨, 저장소 및 로그와 관련하여 가능한 모든 설정을 구성했습니다. 며칠 동안 문서를 읽고, 전문가로부터 지식을 수집하고, 변경을 시도한 끝에 금요일에 마침내 돌파구를 찾았습니다.드럼 롤 주세요!근본 원인은 드라이버였습니다.드라이버는 소프트웨어 운영 체제가 연결된 장치와 통신할 수 있도록 하는 것입니다. 게임용 마우스나 드로잉 태블릿과 같은 주변 장치가 있는 경우 특정 드라이버를 다운로드했을 것입니다. 이 경우 서버의 운영 체제에는 하드 드라이브와 인터페이스할 수 있는 최신 통신 방법이 없었습니다. 디스크에 데이터를 읽고 쓰는 것이 전체 존재 이유의 99%인 데이터베이스에서는 좋지 않습니다. (나머지 1%는 "와우" 요인입니다. 와우, 데이터베이스가 있습니까? 멋지네요.)우리가 서버를 업그레이드할 때 AWS의 4세대에서 5세대 서버로 이동하고 있었고 그에 따라 서버가 연결된 장치와 상호 작용하는 방식에 차이가 생겼습니다(시스템 작동 방식을 완전히 이해하지 못하지만 AWS에는 멋진 기능이 있습니다. 기반 기술의 이름: Nitro!). 우리의 드라이버 버전은 AWS에서 제공하는 기본 버전보다 앞서 있었기 때문에 추가 업데이트가 필요하지 않을 것이라고 예상했습니다. 게다가 우리의 개발 환경에서는 이것이 전혀 문제가 되지 않았습니다! 그러나 우리는 라이브 게임에서와 같이 부하 근처에 아무데도 없었습니다. 또 다른 금요일이고 실패한 드라이버 업데이트의 결과를 인식했음에도 불구하고 우리는 계속 진행하기로 결정했습니다. 이전과 마찬가지로 데이터베이스 간의 연결을 끊고 드라이버 업데이트를 실행한 다음 다시 연결했습니다.대기열은 즉시 거의 소진되었습니다.데이터 쓰기 속도는 이전에 보았던 700Kbps에서 향상된 초당 100,000킬로비트로 측정되었습니다.나는 미소 지었다. 나는 (다소 주체할 수 없을 정도로) 웃었다.우리는 다른 서버에서 프로세스를 반복했습니다. 역시나 눈 깜짝할 사이에 대기열이 소진되었습니다.나는 그 주말에 잤다. 그리고 그 이후로 나는 많은 좋은 월요일 아침을 보냈습니다.뒤돌아보고 앞으로그래서 그것이 실제로 일어났고, 우리가 놓친 것과 사건이 발생한 이유입니다. 다음은 제가 개인적으로 제 직업을 좋아하는 부분입니다. 우리는 어떤 교훈을 얻었습니까? 성장과 개선을 위해 어떻게 사용했습니까? 우리는 길에서 어떤 친구를 만났습니까?음, 무엇보다도 이것은 개발 환경과 라이브 환경이 얼마나 다른지에 대한 확실한 알림이었습니다. 개발 환경은 특정 성능 지표를 연습하고 기록하는 등의 작업에 적합합니다. 그러나 일부 변경 사항의 경우 여러 시스템에 대한 부하 테스트 및 스트레스 테스트와 같은 핵심 도구가 여전히 필요합니다.둘째, 항상 가정을 확인하고 무언가가 예상대로 작동하지 않는 경우 매크로 보기를 살펴보기 위해 한 걸음 물러나라는 알림이었습니다. 우리는 정전 이전에 실사를 했지만 문제의 잘못된 부분에 집중했습니다. 다른 사람과 체크인하는 것은 다른 관점을 제공하고 문제가 될 수 있는지 여부를 결정하기 위해 보고 있던 불규칙성을 방어해야 할 필요성을 제공했을 것입니다.데이터베이스에 가장 영향을 미친 변경 사항은 CPU 또는 하드 드라이브 공간과 같은 시스템 메트릭뿐만 아니라 주요 데이터베이스 메트릭에 대한 경고를 증가시킨 것입니다. 라이브 작업의 경우 향후 문제에 대한 응답 시간을 개선하기 위해 타사 도구에 여러 알림을 추가했습니다. 그리고 일반 운영의 경우 AWS 인프라의 기록 보관을 개선하여 이제 단순한 인스턴스 유형 이상을 추적합니다. 이제 보고서에 인스턴스 유형, 생성, 드라이버 및 스토리지 유형이 포함됩니다. 특정 드라이버 버전을 포함하는 모든 새 서버에 설치할 공통 패키지를 구축했습니다. 향후 마이그레이션 계획은 이 공통 패키지를 업데이트하여 이 문제를 다시 반복하지 않도록 합니다.나머지 모든 데이터베이스 인스턴스 등에 대한 마이그레이션을 완료하여 향상된 서비스를 위한 더 높은 성능을 제공합니다. 지난 14개월 동안 우리는 99.98%의 가동 시간을 기록했으며 사용자 로그인에 영향을 미치는 사소한 서비스 중단은 단 5번이었습니다.우리의 지속적인 노력은 항상 최고의 서비스 경험과 사용성을 제공하는 것을 목표로 합니다. 우리는 우리 이전의 사람들이 설계한 디자인과 세계적 수준의 가동 시간을 유지하기 위해 사용하는 도구 및 프로세스를 축하하는 것을 좋아하며 현재의 가용성 행진을 1년을 넘어 다시 가져오게 된 것을 기쁘게 생각합니다. 우리는 우리가 완벽을 달성할 수 없다는 것을 알고 있지만, 우리는 미래의 모든 절차와 배포에서 확실히 그것을 위해 노력할 것입니다. Guild Wars 2 게임 플레이 및 디자인 팀이 제공 하는 흥미진진한 새로운 기능과 프로젝트를 기대하면서 항상 로그인하여 즐길 수 있도록 뒤에서 끊임없이 노력하고 있습니다.와우, 그래서 나는 많은 코드를 작성할 수 있다는 것을 압니다. 분명히, 나는 꽤 긴 블로그 게시물도 쓸 수 있습니다. 나는 당신이 독서를 즐겼기를 바랍니다. 누군가에게는 이 게시물이 작성하는 데 오랜 시간이 걸릴 수 있지만 실제로 이와 같은 이야기를 여러분과 공유할 수 있게 되어 매우 기쁩니다. 이러한 유형의 게시물에 대한 귀하의 생각과 피드백을 읽고 싶기 때문에 공식 포럼에 <a href="https://en-forum.guildwars2.com/topic/98080-inside-arenanet-live-game-outage-analysis/" target="_top" class="ke-link">토론 스레드</a> 를 마련했습니다 !Tyria에서 온라인으로 만나요, 로버트