“Private Cloud 구독 삭제가 두 지역 모두의 삭제를 유발했다”는 건 단일 장애점이라고 부르는 것이고, 안전을 책임져본 사람이라면 누구나 악몽처럼 여길 일임

구독을 닫거나 삭제하자마자 전 세계적으로 연쇄 삭제되는 구조는 재앙의 조리법처럼 들림. 왜 삭제 표시만 해두고 하루나 일주일 뒤에 지우지 않는지 모르겠음

월 사용액이 큰 회사에서 대체 이런 일이 어떻게 생기는지 모르겠음. 이전 직장에서 AWS에서 의심스러운 워크로드가 돌았을 때는 TAM이 조치 전에 먼저 연락했음
이번 건은 뭔가 잘못된 AI 자동화였고, GCP가 사람에게 실제로 연락해 응답받는 걸 싫어하는 듯해서 외주 인력이 몇 시간 뒤 지원 큐에서 보고 정형 답변만 보낸 상황 아니었을까 싶음

GCP 지원과 관련된 일이라면 이제 아무것도 놀랍지 않음. 우리에게는 전혀 필요 없지만 지난 6년 동안 Account Executive가 12명 넘게 바뀌었고, 모두 완전히 쓸모없었음
매번 자기소개를 하고 엔지니어링 인력과 미팅을 잡아달라고 하며, 우리와 전혀 상관없는 정형 슬라이드 덱을 들고 와서 웃음만 나왔고, 다음 연락은 새 AE가 배정됐을 때였음
GCP와 그 서비스들은 좋아하고 수년간 만족했지만, 사람 쪽은 정말 형편없고 왜 굳이 운영하는지도 모르겠음

다른 스레드에도 의미 있는 답변이 있었던 것 같음. 우리도 계정을 다시 되찾긴 했지만, Account Rep과 CSM이 있어도 무슨 일이 벌어진 건지 파악하는 데 시간이 걸렸음
담당자가 없었다면 더 나빴을 수도 있음

Google이니까 그럼. 서비스를 쓰게 해주다가, 네가 규범에서 벗어나는 순간 정지시킴

공개 API를 운영하는 입장에서 Railway IP에서 오는 스팸이 말도 안 되게 많음. 남용 방지가 형편없고, 이번 일이 운영을 개선하는 계기가 됐으면 함

호스팅 회사를 운영할 때 핵심 충돌이 바로 이거임. 가입을 쉽게 만들면 신규 사용자가 많이 오지만 남용도 많이 들어옴
남용 방지책을 넣으면 시끄러운 오탐이 생기고, 이번 GCP 건도 그럴 수 있음
호스팅 회사를 운영하는 사람은 부럽지 않음. 인터넷은 표면 아래가 정말 지저분함
덧붙이면 AWS는 이 부분을 정말 잘함. 약 30년간의 소매 사기와 남용 대응 경험 덕분일 듯함

잠깐, Railway가 GCP 위에서 돌아가는 거였나? “다른 클라우드 위에 클라우드를 만들지 않는다”고 크게 말하지 않았나?
아니면 VPS를 빌리는 게 아니라 클라우드 제공자에게서 베어메탈만 빌린다는 뜻이었나?
적어도 하이퍼스케일러 중 하나에 돈만 내는 게 아니라 코로케이션을 하고 스택을 더 많이 소유하는 다른 제공자가 생겼다고 생각해서 기대했음 https://blog.railway.com/p/heroku-walked-railway-run

Wayback Machine으로 본 연결된 글에는 이렇게 되어 있음
“첫날부터 이 생각을 최전선에 두고 있었다.
또 우리가 직감한 건 다른 클라우드 위에 클라우드를 만들 수 없다는 것이다. Railway의 비즈니스, 결국 고객의 비즈니스가 가능한 한 견고하도록 자체 서버를 운영하고 다른 클라우드와 잘 공존하는 실무에 수년을 쏟았다.”

맞고, 그래서 화남. 그들은 거짓말했음. GCP에 완전히 의존하고 있었음
이제 조사를 좀 해야겠음. 이것보다 좀 더 안정적이고, 한 회사의 변덕에 덜 의존하는 게 필요함
Railway 입장에서도 안 좋은 일인 게, 그들의 큰 주장인 평화로운 소프트웨어 배포의 핵심을 바로 찌르기 때문임. 이건 혼돈임

Vercel은 그걸 해내는 것처럼 보임. PlanetScale도 데이터베이스 한정으로는 그렇고, 어차피 모든 것은 데이터베이스임

Railway에 가입할 때 시스템 남용, 암호화폐 채굴 등에 관한 약관을 읽고 이해했는지 확인하는 방식이 특이함
추측하자면 많은 사용자가 무료 티어를 남용해서 서비스 제공자와 문제를 일으키는 듯함
경쟁사 입장이어도 Railway가 이런 타격을 받는 걸 즐겁게 보진 않지만, 무료 컴퓨트는 온갖 이상한 사용자를 끌어들임. 우리도 겪어봤고, 유입 상단이 줄어들더라도 초기에 무료 컴퓨트를 피하기로 했음

Google만 탓하기는 어렵다고 봄. Railway는 플랫폼 안정성을 유지하는 데 점점 더 어려움을 겪는 것처럼 보임
이런 일이 전체 서비스를 내려서는 안 됨. 말 그대로 안정적인 백엔드를 제공하는 게 사업이라면 백업이 있어야 함. 내 눈에는 부실한 계획으로 보임

무슨 뜻인지 잘 모르겠음. Railway가 모든 고객 프로젝트를 호스팅하기 위해 멀티 클라우드 아키텍처를 써야 한다고 정말 기대하는 건가? 전체적으로 보면 그게 오히려 가용성을 낮출 것 같음