1 개요
호토모에 등대 프로젝트는 호토모에가 꺼지지 않게 하자는 의미를 담아서 지어진 이름입니다.
최근 하드웨어 노후화로 인한 잦은 장애를 겪었기 때문에 이를 방지하고, 겸사겸사 많은 개선을 진행하고자 합니다.
2 무엇이 바뀌는가?
일단 사용자가 체감할 수 있는 변화는 다음과 같은 것이 있을 것이라고 예상합니다.
- 다운타임(=서비스를 이용할 수 없는 시간)의 효과적인 억제
- 물리 서버 사용의 중단 및 모든 인프라 VPS로 이전 2024년 1월 11일 (목) 08:32 (JST)
별도 네트워크 인프라 구축 (165.140.23.0/24 사용 예정) 2024년 1월 11일 (목) 08:32 (JST)(취소) 2024년 2월 18일 (일) 06:38 (JST)
- 미국 리전 추가를 통한 해외 사용자의 접속 환경 개선
자동으로 배포되는 미스키 신버전(취소) 2024년 1월 11일 (목) 08:32 (JST)
사용자가 체감할 수 없는, 기술적인 부분의 변화는 다음과 같은 것이 있을 것이라고 예상합니다.
- 쿠버네티스 도입
- DB 서버 이중화
Anycast 적용을 통한 seamless region change 구현(취소) 2024년 2월 18일 (일) 06:37 (JST)
3 우려점
3.1 미스키는 과연 믿을만한가?
정확히는 "미스키 신버전이 자동으로 배포해도 될만큼 신뢰되는가?"의 문제입니다. 호토모에는 다른 인스턴스에 비해 꽤나 느린 업데이트 주기를 가지고 있는데요, 이는 제가 다른 소프트웨어들의 신버전이 나오자마자 올리면 항상 뒤통수를 맞았기 때문에... 경험에서 나오는 선택입니다.
이런 상황에서 미스키 신버전이 나왔을 때 자동으로 업데이트를 한다는건 꽤나 두려운 선택이 될 수 있습니다. 물론 나오자마자 하게 하진 않을테고, 아마 최소 5~10일간의 주시 기간을 가지고 다른 인스턴스들의 상황을 본 뒤 위험하다 싶으면 수동 배포로 전환하겠지만 배포 프로세스만 자동화 하고 자동으로 신버전을 인식해서 배포할 필요는 없지 않을까 하는 생각도 가지고 있습니다.
위와 같은 우려에 따라, 자동 업데이트를 도입하지 않기로 결정했습니다. 2024년 1월 11일 (목) 08:32 (JST)
3.2 쿠버네티스 도입
디중 서버의 컨테이너를 관리해야 하고, Blue/Green 배포도 도입하고자 하는 상황에서 쿠버네티스 도입을 검토하고 있습니다만, 이 또한 제가 써보지 않은 도구로 구성에서 실수가 있을 수 있다는 것을 간과할 수 없습니다. 물론 이 쪽은 구성을 잘못하면 애초에 서비스가 동작하지 않을 가능성이 높기 때문에 일찍 바로잡을 수 있을 가능성이 높다고 생각합니다...만 그렇지 않을 가능성도 있다는 우려는 있습니다.
3.3 DB 이중화 구성
Misskey는 DB로 PostgreSQL을 사용하고 있습니다. 문제는 제가 PostgreSQL 서버 운용 경험이 많지 않다는 것인데요, 이런 상황에서 이중화 구성까지 하는 것은 잘못된 구성으로 데이터 유실이 일어나는 가능성을 간과할 수 없습니다.
3.4 Anycast에 관해서
미국 리전의 추가는 Anycast를 이용하여 진행하고자 합니다. Anycast가 무엇이냐 하면... 적당히 짧게 말하면 "IP 주소를 여러 서버에 할당하는 것"이라고 할 수 있겠습니다. 일단 기본적으로 같은 IP 주소는 여러 곳에 할당 할 수 없다고 알고 계시겠지만 인터넷에서는 어느정도 가능합니다. 좀 복잡할 뿐이지... 이런 경우 통신사는 자신이 가지고 있는 여러 경로 중에서 가장 합리적이라고 "생각되는" 경로를 통해서 접근합니다.
근데 이 경로가 실제로 합리적인진 모릅니다. 이 "합리적"의 기준도 통신사마다 다릅니다. 그래서 만약에 호토모에 서버가 일본과 미국에 있을 때, 한국의 사용자가 접속하는데 미국으로 가버릴 수도 있습니다. 이런 경우엔 골치가 아프겠죠. 극단적으로는 미국의 어떤 통신사가 경로 선택을 잘못 해서 일본 서버로 갈 수도 있는거고요.
이런 경우엔 시행착오를 통해서 제가 직접 그 라우팅을 사용하지 말라고 정책을 배포해야 합니다. 이게 우려점인 이유는, 시행착오를 반드시 겪어야, 그리고 제가 쓰는 통신사가 아니라면 그 시행착오의 불편을 특정 사용자층이 겪어야지만 해결이 가능합니다. 물론 해결된 이후에 그게 영구적이라고 보기도 힘듭니다. 물론 그게 그렇게 자주 바뀌진 않겠지만요.
하지만 시행착오를 겪는 것보다도 가치가 있다고 판단했습니다. 극단적으로 만약 일본에 있는 IDC에 불이 난다거나 하면 일반적인 구성에선 꼼짝없이 장기적인 장애로 이어질 수밖에 없습니다. 최악의 상황에선 데이터의 일부 또는 전체 유실도 각오해야겠죠. 하지만 이렇게 두개의 region에서 서버를 구성하면 한 쪽 서버가 완전히 박살나도 나머지 한 쪽으로 정상 동작이 가능합니다.
문제가 있어서 Anycast의 도입은 취소했습니다. 다만 미국 리전의 도입은 서브도메인 방식을 통해 진행합니다. Region DNS 방식도 고민하고 있습니다.
어찌됐던 왜 안했느냐? 여러가지 문제가 있었습니다.
일단 미스키가 Anycast로 띄웠을 때 뭔가 잘 안됐습니다. 왜인진 모르겠는데 로컬에 미스키 3개 띄우고 테스트 하니까 잘 안되더라고요. 원인도 모르겠고...
뭣보다 위에서 적은 "최적 경로의 신뢰성" 문제도 발목을 잡았습니다. 한국에서 미국으로 가버린다거나 하는 일이 생기면 골머리가 아프기 때문에...
그리고 Anycast Deamon만 살아있고 Misskey가 죽었을 때는 아무런 의미가 없습니다. 오히려 미국 서버가 살아있는데 접속할 방법이 없는 상황이 발생할 수도 있죠.
그래서 미국 리전은 서브도메인을 이용하기로 했습니다. 미스키가 이런 방식으로 서버 여러개를 키는건 됐던걸로 기억을 합니다. 프론트엔드 버전을 잘 맞춰줘야겠지만. 2024년 2월 18일 (일) 06:37 (JST)
4 마치며
이번 프로젝트는 필연적으로 운영 비용의 증가가 발생합니다. 현재는 전기료 정도입니다만, 이제 전기료는 별도고 서버 임대료가 발생하게 됩니다. 원래 호토모에는 "전기료 정도는 그냥 내면 되지!" 해서 후원을 따로 받진 않았던 것인데, 이렇게 된다면 후원을 여는 것도 검토해봐야 할 것 같습니다.