[OpenTTD 공식 사이트 포스트 번역] 인프라 이전 완료

https://telk.kr/tb/free/2525
이 글은 OpenTTD 공식 사이트에 TrueBrain 개발자가 12월 1일에 올린 포스트를 번역한 것입니다.
OpenTTD가 모든 서비스를 AWS(아마존 웹 서비스)로 이전했다는 내용을 담고 있습니다.

오늘은 좋은 날입니다.
오늘은 openttd.org의 모든 서비스가 AWS에서 돌아가게 된 날입니다.
오늘은 마침내 우리의 옛 OVH 상설 서버를 내리는 날입니다.
오늘은 아래와 같은 소프트웨어에서 은퇴할 수 있게된 날입니다:
  • Django 1.2 (2010년 5월 공개)
  • Debian Etch (2007년 4월 공개)
  • MediaWik 1.12.0 (2008년 겨울 공개)
  • XenServer 6.5 (2015년 1월 공개)
  • 2016년 이후로 업그레이드나 리뉴얼된 적이 없었던 IRC 봇

이는 제작하는 데 11개월이나 걸린 가장 긴 이전 작업이었습니다. 하지만 우리는 드디어 해냈습니다!

이 대부분의 과정은 AWS 오픈 소스 크레딧을 받았기 때문에 가능한 일이었습니다. 이를 통해 AWS 서비스를 맛볼 수 있었고, 바보같은 짓도 할 수 있었습니다. (이게 없었다면 매월 500달러를 내야했을 겁니다.. 우리에겐 꽤 큰 돈이죠.) 이 모든 게 기부금만으로 충당할 수 없음을 알았지만 가능했습니다. (참고: 크레딧으로 2020년의 모든 비용을 충당했습니다). 안타깝게도, 2021년에는 AWS 오픈 소스 크레딧을 받지 못 할 것입니다 .. 이제 실험은 없다는 뜻이죠. 따라서 이제 지난 16년 동안, 특히 지난 2년간 일어났던 일을 기록하기 적합한 시간이라고 봅니다.

꽤 긴 글이 될 것 같습니다. 스크롤 압박에 주의하세요!


역사


약간의 역사에 대해 이야기해보죠.

2004년에 openttd.org는 웹 사이트이자 위키였고, 그게 다였습니다.
그 후 몇 년 간, 우리는 openttd.org 에서 제공하는 내용을 크게 확장시켰습니다.
  • 게임 내에서 서버 목록을 보여줄 수 있게 만들어주는 마스터 서버
  • NewGRF, 시나리오 등을 게임 내에서 다운로드받을 수 있게 해주는 콘텐츠 서비스
  • 버그 트래커
  • 메일
  • 메일리스트
  • IRC 봇
  • 개발자 공간
  • (예전에는 "미러"라고 불렸던) 콘텐츠 전송 네트워크(CDN)
  • NoAI 토너먼트 서버
  • 중앙 집중식 계정 관리
  • 서브버전(Subversion)

이게 전체 목록이 아니라고 확신합니다. 우린 이상한 것들을 만들었었고, 모든 생각이 다 살아남지는 않았지만, 그래요. 우린 바빴습니다.
2007년이 되자 대부분의 서비스가 다 만들어졌거나, 더 이상새로운 서비스를 개발하는 데 관심이 없어졌습니다.


11년 후


2018년에는 인프라 측면에서 큰 변화가 없었습니다.
약간의 추가 사항과 약간의 조정이 있었지만 실제로는 별 건 없었죠.
BaNaNaS가 아직도 2007년 때와 같은 소프트웨어로 굴러가고 있었습니다.
중앙 집중식 계정은 프로필 페이지에서 아직도 "출시 예정" 상태였죠.

그래서, 나쁜 일이었냐고요?


글쎄요, 그렇기도 하고 아니기도 하네요.
안정성의 관점에서 본다면 완벽한 상태였습니다.
우리는 심지어 이런 이상한 일도 다룰 수 있었습니다:
* slashdot에 포스팅되어 한때 slashdot 효과를 누렸습니다.
* 한 때 인기 있는 YouTube channel이 OpenTTD를 플레이하여 하룻밤 사이에 플레이어 숫자를 두 배로 늘려놓았습니다.
* 그리고 많은 (사소한) 이벤트

보통 이런 경우에는 많은 사람들이 웹 사이트에 방문하고 게임을 다운로드한다는 것입니다.
멋진 이야기이지만, 서비스에 부하를 주는 행위이기도 하죠.
종종 그런 경우를 볼 때마다, 사이트가 깨지거나 다운되기도 하죠.
하지만... openttd.org 는 그렇지 않았습니다.
우리 서비스는 그런 미칠 듯한 트래픽의 증가에서 살아남았습니다.
숫자로 얘기하자면, 이벤트에 따라 초당 5~15개의 요청에서 초당 60~200개의 요청 사이를 왔다갔다 했습니다.
그런데 openttd.org 는 이를 처리할 수 있었습니다.
단지 그런 이벤트가 있을 때 어떤 유저가 우리 코드에서 버그를 발견해서 서비스를 터트리는 시간만 빼고요.
재미있는 시간이었어요 :P

그래서, 나쁜 일이 아니라고요?


음, 아니요. 나쁜 일이 맞아요.

예를 들어드리죠.
우리의 메인 웹사이트는 심하게 수정이 가해진 Django 1.2를 사용해서 구동되고 있었습니다.
2007년에 공개된 거죠. 13년 전이에요.
Django 1.2에는 알려진 버그가 있었고, 우리는 그 버그를 수정해서 사용하고 있었지만... 점점 어려워지기 시작했습니다.
이는 누군가가 어떤 서비스에서든 보안 문제를 발견할 가능성이 높아진다는 걸 의미했습니다.
사고가 일어나기를 기다리는 꼴이었죠.
추가적으로, 오래된 코드가 베이스이다 보니 코드가 아무 곳에도 게시되지 않아서 다른 사람이 코드를 수정할 수 없었습니다.
오픈 소스에 친화적이지 않았죠.

물론 가끔씩 다른 소프트웨어를 업그레이드했습니다만... 모든 시스템에 패치를 진행하고 모든 게 잘 굴러가는지 확인하는 작업 등을 하기 위해 일주일(40시간) 씩이나 걸렸죠.
저 또한 이 작업을 무보수로 남는 자유 시간에 하는 것입니다만, 나이가 들면 들 수록 이게 어려워집니다.
그래서 작업이 점점 더 쌓여가기 시작하여 2016년부터 1개의 서비스가 실행되고 있음을 오늘에서야 알게 되었습니다.[1]
두루뭉실하게 말하자면, 괜찮지 않은 상황입니다.
이는 "만약"이 아니라, "언제" 일어날지 모르는 재난을 기다리는 것과 같습니다.

그래서, 네 말은 그런 문제가 너 때문에 일어났다는 거야?


도움을 줄 다른 사람을 찾으면 문제도 해결됩니다!

네, 네, 네. 수 천 번이라도 예라고 대답하겠습니다.
그게 정말 도움이 될 거에요.
하지만... 16년동안 이 일을 해오는 동안... 많은 사람들이 와서 "도와줄게요"라는 말을 해왔습니다.
그들이 조금 더 깊게 들어가면, 그들이 수행해야 할 엄청난 양의 작업량이나 매우 반복적인 작업(매월마다 시스템에 로그인해서, 소프트웨어를 모두 업데이트하고, 모든게 다 잘 돌아가는지 확인한 다음 로그 아웃하기) 뿐이라는 것을 깨닫게 됩니다.
예시를 몇 개 들어드리죠.
  • BaNaNaS는 BaNaNaS v2로 대체될 예정이었습니다.
2014년 쯤에 이 얘기를 처음 했던 걸로 생각합니다.BaNaNaS v1의 많은 문제를 해결해줄 거라고 생각했고 야심 가득한 계획이었죠.2017년에는 또다른 기회가 있었지만 결국 몇 개월 뒤에 멈춰버리고 말았어요.몇 가지 초기 코드(BaNaNaS v1.5에서 재사용된 코드, 나중에 자세히 설명함)가 있지만 그 이상은 아니었죠.
  • MediaWiki가 굉장히 오래된 버전으로 굴러가고 있었고, 몇 몇 사람들이 새로운 버전으로 업그레이드하는 걸 도와주겠다고 말했습니다.
사람들이 실험할 수 있도록 현재 버전의 가상 환경을 제공했습니다만, 그 어떠한 사람에게서도 회신을 받을 수 없었죠.
  1. .. 첫 제안과 얘기만 하고 그 이후엔 아무 응답이 없는 것 같았죠.

더 많은 예시가 있지만, 지금 쯤이면 제가 어떤 상황이었는지 이해하시리라고 생각합니다.
하지만 저를 오해하지 말아주세요. 도움을 주겠다고 제안한 사람은, 정말 최선의 의도를 가지고 도움을 제공하려고 했고 연락을 취해준 점에 대해 감사함을 느끼고 있답니다.
하지만 소프트웨어를 만들고 인프라를 유지하는 건 어려운 일입니다.
일요일 오후에 시작해서 뚝딱하고 완료할 수 있는 일이 아니죠.
40대를 향해 달려가는 저의 시간은 더 이상 충분히 많지 않습니다.
우리가 20대였을 때, 대학은 이런 미친 짓을 하기에 충분히 많은 시간을 허용해줬습니다.

변화가 오고 있다


그래서, 2018년에 우리는 변화를 줘야겠다고 생각했습니다.
몇 가지 드라마틱한 변화가 이루어졌고, 그 다음 2년 내에도 많은 변화가 있을 예정이었죠.

이제 해결해야 할 큰 문제로,
우리는 여태까지는 관리되지 않는 호스팅이라는 것을 사용해 왔습니다.
이는 우리가 서버에 접속할 수 있고 그 뒤에는 우리가 모든 것을 우리 스스로 해야하는 서비스였죠.
이는 매우 저렴하고, 이 서비스를 사용했던 주된 이유였습니다. 하지만 유지보수를 하기 위해 시간을 들여야한다는 뜻이기도 했죠.
그래서 우리는 관리 호스팅으로 넘어가고자 했습니다.
더 비싸지만, 우리가 스스로 작업할 필요가 없다는 것을 의미하죠.
관리 호스팅을 공급하는 공급자는 다음과 같은 많은 작업을 해줍니다:

Github


2018년에 얻을 수 있었던 가장 쉬운 소득 중 하나는 바로 Subversion에서 git으로 옮겨가 Github에서 이를 호스팅하는 것이었습니다.
이는 버전 관리 인프라를 우리가 유지보수할 필요가 없어졌다는 뜻이죠.
또한 버그 트래커 시스템도 Github으로 이전했습니다.
무슨 말이냐면, Github을 사용하려면 제대로 사용하거나 아니면 집에 가세요.

우리가 운영하는 다른 서비스는 어떤가?


몇 가지를 시도했지만 결국 클라우드 솔루션을 사용하는 것이 가장 좋다고 결정했습니다.
우리는 모든 클라우드 공급자에게 비용이 증가하는 타격을 막기 위해 오픈 소스 프로젝트에 제공하는 뭔가가 있는지 물어보았습니다.
많은 "재미있는" 대화를 했습니다... 운 좋게도 AWS가 AWS 오픈 소스 크레딧 프로그램이라는 것을 운영하고 있다고 유선 상을 통해 답변을 듣게 되었습니다.
AWS는 2020년에 우리에게 자금을 지원했고 우리는 모든 AWS 서비스를 실험할 수 있었습니다.
정말 큰 도움이 되었고 우리는 AWS로 이전하기 시작했습니다.

초기 작업은 2019년 1월에 시작되었지만, 당시에는 DigitalOceanKubernetes 솔루션을 염두에 두고 있었습니다.
여러 가지 이유로 이 작업은 이루어지지 않았습니다. (주로 Spaces에서 IPv6의 부족이 원인이었지만, 그 외에도 다른 여러 문제가 있었습니다)
그래도 DitigalOcean은 대단합니다. 오해하지 말아주세요. 꽤 괜찮은 품질의 저렴한 솔루션을 제공하고 있습니다.
단지 여러분이 저런 곳에서 openttd.org 같은 뭔가를 굴리려고 한다면, 한계에 다다르게 될 겁니다.
우리의 서비스는 복잡합니다. 나중에 더 자세히 다뤄보죠 :)


새로운 시작

2019년 12월에, 우리는 메인 웹 사이트를 AWS에서 작동하기 시작했습니다.
사이트를 Jekyll로 완전히 다시 짰고, 사람들이 포스트 등을 작성하는 게 더 용이하도록 만들었습니다.
사람들이 뉴스 포스트를 작성하지 않고 있었기 때문에 이는 매우 유익했습니다.

다음으로 더 쉬운 것들을 AWS로 옮겼습니다.
  • 문서
  • 도메인 리다이렉트 (예를 들어서 openttd.com 을 openttd.org 로 리다이렉트)

2020년 1월에, 우리는 모든 바이너리를 AWS에서 구동할 준비가 되었습니다.
이를 위해 자체 맞춤형 미러 네트워크를 구동하곤 했습니다.
무료 대역폭으로 우리를 후원해주신 이런 서버의 주인 분들에게 감사를 표할 수는 없습니다.
하지만 이제는 적절한 CDN(콘텐츠 전송 네트워크)을 사용할 때였습니다.
적절한 CDN을 사용하면 그 순간부터 게임 다운로드가 훨씬 빨라질 것이기 때문이죠.
CDN은 가까운 서버에서 다운로드를 제공하여 다운로드 속도를 대폭으로 향상시켜줍니다.


BaNaNaS


다음으로 큰 문제는 BaNaNaS였습니다.
앞서 언급했듯이, 오래된 물건이죠.
코드를 전혀 다시 짠 적이 없었죠... 그래서 우리는 이걸 어떻게 AWS에서 실행하고 유지보수가 쉽게 만들 수 있을까요?
여기서 frosch의 도움을 받았습니다. 우리는 BaNaNaS를 함께 바닥부터 다시 짰고, 모든 데이터를 GitHub(과 AWS S3)에 저장했습니다.
하지만 기능적으로 현재 버전과 똑같이 동작하게 유지했습니다.
이렇게 범위를 지정함으로써, 코드를 다시 짜는 게 가능했습니다.
큰 노력이 들어갔고, 완성하는 데 몇 주가 걸렸습니다.
우리는 이걸 BaNaNaS v1.5라는 이름을 붙였습니다. 우리가 바랬던 v2는 아니었지만, 지금의 v1보다는 분명히 좋아졌습니다.

2020년 4월에는, 이를 실 서비스에 적용했습니다.
BaNaNaS의 코드 또한 이제 Github에 올라갔고, 변경 사항을 즉시 배포할 수 있게 되었습니다.
과소평가하면 안 될 게, 이제 Github의 BaNaNaS에 대한 변경 사항을 5분 이내에 적용할 수 있게 되었습니다.
이는 엄청나게 삶의 질을 높여주고 더 많은 사람들이 작업 결과를 돕거나 직접 볼 수 있게 만들었습니다.
또한 openttd.org 에 대한 모든 서비스를 두 번 실행하도록 "스테이징 / 프로덕션" 설정을 적용했습니다.
이는 변경 사항이 예상한 대로인지 테스트할 수 있는 “스테이징”이라는 더 작은 버전과, 여러분이 실제로 접속하는 “프로덕션”이라는 풀 버전을 의미합니다.

이 시점에서 우리는 중앙 집중식 계정 시스템을 중단하고, GitHub OAuth2 플로우를 이용해서 유저를 인증하기로 했습니다.
이제 계정 관련 서비스를 운영할 필요가 없어졌고, 유저들의 메일 주소를 저장(하고 보호)할 필요가 없어졌다는 뜻입니다.
서로에게 좋은 일이죠.

BaNaNas를 AWS에 도입한 이후, 월 청구액이 급증했습니다.
일반적으로 인프라에 100달러를 지불했지만, 이제 500달러 이상이 들었습니다.

왜냐고요?
BaNaNaS에 업로드된 두 개의 콘텐츠인 abasezBase 때문입니다.
이 둘은 32bpp 기본 그래픽 세트입니다.
파일 크기가 (다른 것에 비해) 매우 큽니다.
둘을 합쳐서 매월 트래픽 비용만 300달러 가까이 듭니다.
이게 클라우드 솔루션의 단점입니다. 트래픽이 매우 비싸죠.
걱정하지 마세요. 이 실험에 자금을 지원하기 위해 오픈 소스 크레딧을 사용했기 때문에 비용을 지불할 필요가 없었습니다.
2021년 이전에는 이런 파일을 AWS 외부의 훨씬 저렴한 솔루션으로 제공할 것입니다.
우리는 후원만으로 이런 금액을 매월 지불할 수 없으니까요 ;) (불만은 아닙니다. 그저 관찰일 뿐이죠)


마스터 서버


다음으로 이전해야할 서비스는 마스터 서버였습니다.
이것 또한 약간 엉망이었습니다.
그래서 BaNaNaS와 동일한 접근 방식이 사용되었습니다.
2020년 9월에, 이 또한 AWS 위에서 돌아가게 되었습니다.
이 일에 대한 문제도 여러 번의 포스트를 통해 작성할 수 있습니다만... 그게 더 지루한 서비스 중 하나이기 때문에 지금은 넘어가도록 하죠.


Eints


Eints는 우리의 (게임) 번역 도구이고 다음으로 작업해야할 일이었스빈다.
frosch가 몇 번의 수정(주로 Github OAuth 플로우로 인증하는 기능)을 거친 후에는 대부분 어려움이 없었습니다.
2020년 10월에는 이를 실 서비스할 수 있었습니다.

위키


마지막 큰 고통은 ... 위키였습니다.
AWS에서 미디어위키를 굴리는 것은 거의 불가능합니다. 만약 가능했다면, 비쌌을 것이고 우리가 지불할 수 없는 비용이었을 겁니다.
또한, 위키의 콘텐츠는 수 년간 유지보수되지 않아서 큰 골칫덩이가 되었죠.
frosch는 처음에 gollum과 같은 다른 소프트웨어를 조사하여 이 문제를 "수정"하려고 시도했습니다.
이 툴은 데이터를 git으로 저장하기 때문에, 수정이 훨씬 용이했습니다.
몇 주간의 좌절 끝에 이 툴을 이용하는 게 어렵다는 결론이 내려졌습니다.
그래서 제 자신만의 위키 소프트웨어를 만드는 방식으로 이를 타파하기로 했고, TrueWiki가 탄생했습니다.
놀랍게도, 코드를 작성하는데 2주(40시간) 정도밖에 안 걸렸습니다. BaNaNaS보다 훨씬 적은 시간이었죠.
BaNaNaS와 마스터 서버의 코드를 작성할 때 썼던 트릭이 많은 도움을 줬습니다.
frosch는 그동안 위키를 완전히 재구성하기 시작했습니다.
그는 모든 페이지를 일일이 살펴보며 이전할 페이지를 골랐습니다.
저는 종종 인프라를 유지보수 하는 것을 지겨워합니다만, 제가 아니라 그가 이 일을 해준 것을 기쁘게 생각합니다.
그 광기에 대해 절대적으로 존경합니다.

2020년 11월에 새 위키를 공개했습니다.
우리가 개편한 모든 서비스 중에서 가장 원활하게 이루어진 이전이 아닙니다.
주로 google.com이 2020년 10월 이후 웹사이트 색인을 다시 생성하는데 문제가 있다는 점이 밝혀진 것과, 이 포스트를 쓰는 지금도 아직 위키가 색인되지 않았다는 게 그 이유입니다.
이로 인해 많은 유저들이 찾고 있는 내용이 포함되지 않은 위키 페이지에 방문하게 되었습니다.
거친 출시입니다만, 지금은 더 좋아보입니다.


정리


이제 남은 서비스가 몇 개 있었습니다:
  • 이제 Zernebok를 통해 친절히 호스팅되는 메일 서비스 (orudge에게 감사를 표합니다!)
  • IRC 봇은 제가 오늘 이전했습니다.

그래서 이제 이 이야기의 마지막에 도달하게 되었네요. 모든 서비스가 AWS 위에서 호스팅되게 되었습니다!


결과는...


이 서비스들을 유지보수하는 건 결코 쉬운 일이 아닙니다. 몇 가지만 하면 됩니다.
  • 매월 pyup.io는 모든 우리의 (Python) 소프트웨어의 종속 파일을 제공합니다.
Pull Request를 병합한 뒤에, 우리는 이를 스테이징에서 테스트할 수 있습니다.문제가 발견되지 않으면, 새 프로덕션을 공개할 수 있습니다.누구나 이를 할 수 있고, 저(TrueBrain)와 LordAro가 지난 몇 달동안 이 일을 해왔습니다.아무리 많아도 한 달에 몇 분 정도만 투자하면 됩니다.
  • 매월 AWS에 몇 가지 것들을 재배치해야 하므로, 최신 버전의 OS를 가져옵니다.
거의 완전히 자동화된 시스템입니다. 저는 4를 8로 바꿨다가 몇 분 뒤에 8을 다시 4로 바꿔야 합니다.자세히 말하자면, Auto-Scale 그룹 인스턴스 개수를 4개에서 8개로 확장했다가, 나중에 다시 8개에서 4개로 줄입니다.이는 시스템을 완전히 재설치하고 최신 버전을 얻기에 충분합니다.
  • 매 6개월마다 secret을 변경합니다.
네, 솔직히 가장 지루한 부분입니다. 4시간 정도 걸리거든요.

이제 우리가 어디까지 왔는가 볼까요, 모든 서비스를 유지보수하려면 한 달에 40시간이 걸리던 것이 1시간으로 줄었습니다.
극적인 차이죠.

또 누구나 이를 도울 수 있습니다!
따라서 버스 지수(문제가 발생하기 전에 버스에 치어야 하는 사람 수)[2]는 더 이상 1이 아닙니다. 아마도... 10명 이상이지 않을까요?

짧게 말해서 이 지수를 짧게 유지하는 데 완전히 실패했다는 것을 알고 있습니다. 아주 좋은 날이죠.
마침내 불가능한 인프라를 유지하는 부담이 사라졌습니다.

단점?

월별 청구액이 두 배가 되었기 때문에 어느 시점에서 모금 행사를 해야할 지도 모르겠네요. (여러분들이 그동안 후원해주신 덕분에 몇 년간 그렇게 하지 않았어요! 정말 감사합니다!)



향후 계획은?


이 모든 작업을 마침으로써, 향후 10년간 지속될 수 있는 인프라를 구축했다고 생각합니다.
마지막 인프라와 동일한 안정성을 갖기를 바랍니다.

이제 질문을 받게 되겠죠. 할 일이 아직 남아있나요?
글쎄요, 이전(마이그레이션) 같은 경우에는... 아니요.
하지만 선택할 수 있는 다른 게 남아있습니다.
예를 들어, 우리는 openttd.org에서 다운로드할 수 있는 OpenTTD 버전인 "바닐라"를 갖고 있습니다. 하지만 "바닐라"보다 더 멋진(혹은 더 굉장한) 다른 버전들이 있습니다.
아주 아주 많은 패치가 적용되어 있는 JGRPP 같은 예시를 들어보죠. (패치팩이라고 하죠)
이런 OpenTTD 버전은 더 많은 주목을 받을 만 합니다.
이상적으로는 openttd.org 서비스가 그런 버전과 더 잘 통합될 수 있는지 알아보고 싶습니다.
이를 위한 많은 작업이 백그라운드에서 수행되었고 이제 마침내 최종 사용자에게 보여줄 시간이 생겼습니다.

또한 제 머릿속에는 현실로 만들고 싶은 몇 가지 아이디어가 있습니다.
가장 큰 것은, 게임 내에서 로그인해서 세이브 파일을 온라인으로 저장하고 불러올 수 있는 "클라우드 저장"입니다 (물론 완전히 선택사항).
즉, 어디에 있든 OpenTTD를 다운로드하기만 하면 저장했던 게임을 계속 이어서 할 수 있게 되겠죠.
이를 금상첨화로 만들기 위해, OpenTTD를 브라우저에서 실행할 수 있도록 만드는 일부 초기 작업이 있습니다.
이 두 가지를 결합하면 언제 어디에서나 플레이할 수 있는 게임을 갖게 됩니다.
저에게, 이것은 우리가 제공하는 openttd.org 서비스의 멋진 추가 기능이 될 것입니다.
안타깝게도 이번 달에 AWS 오픈 소스 크레딧이 만료되고, 그런 추가 비용이 얼마나 들지 가늠하기 매우 어렵기 때문에 이게 실현될 수 있을지에 대해서는 확답을 드릴 수 없습니다.
시간이... 시간이 말해줄 것입니다!

기여하고 싶으신가요, 자신 만의 아이디가 있으신가요, 아니면 도움을 주실 수 있다고 생각하시나요? IRC (irc.oftc.net, #openttd)에 들러 채팅해주세요!

닫는 말


지금까지 이 긴 글을 읽어주셨다면, 칭찬합니다. 그리고 읽어주셔서 감사합니다.
또한 지난 10년 이상동안 멋진 서비스를 제공해준 OVH에 감사를 표합니다.
우리의 전용 서버에서 발생했던 문제는 종종 OVH 직원이 제가 알리기 전에 먼저 포착해서 짧은 시간 내에 해결해주셨습니다.
OVH는 굉장합니다!

또한 AWS 오픈 소스 프로그램에 감사를 표합니다. 그들 없이는 우리 서비스가 AWS에서 돌아갈 수 없었을 것입니다.

그리고 이 새로운 인프라를 같이 구축해준 frosch에게도 감사를 표합니다.
그는 심지어 위키 이전을 위해 휴가를 사용하기도 했습니다... 정말 대단한 헌신입니다!
그를 볼 때 사랑을 보내주시고, 가능하다면 (가상) 맥주를 사주세요.

  1. [1] (역자 주) 보안 상 위험한 서비스 하나가 2016년부터 계속 구동되고 있었다는 것을 오늘 알아챘다는 뜻으로 보임
  2. [2] 팀 구성원 간에 공유되지 않는 정보 및 기능으로 인한 위험을 버스에 부딪힐 경우를 대비하여 측정한 것. 프로젝트가 중단될 수 있는 팀 구성원의 최소 수

이모지를 이용해서 글에 반응해보세요!

댓글



꼬리표를 선택하세요


↑TOP

신고하기 ×

신고 종류
작성자
내용

신고 사유