HealthCare.gov 구조 10주년

 (pauladamsmith.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 2013년 10월 18일, 출시 직후 멈춰 선 HealthCare.gov를 되살리기 위해 소규모 기술팀이 백악관에서 첫 현장 점검을 시작했고, 이 작업은 나중에 “tech surge”로 불림
  • 사이트는 2013년 10월 1일 공개됐지만 제대로 동작하지 않았고, 같은 날 시작된 연방정부 셧다운 탓에 외부 지원은 10월 17일 이후에야 투입 가능했음
  • 첫날 팀은 백악관, HHS, CMS, Exchange Operations Center, CGI 사무실을 차례로 돌며 계약·구성요소·업무 규칙·배포 절차가 얽힌 대형 시스템의 병목을 파악함
  • 현장에서는 수동 테스트, 긴 야간 배포와 롤백, 느린 리소스 프로비저닝, 스키마 없는 핵심 데이터 계층, 실시간 모니터링 부재가 주요 위험으로 드러남
  • CGI 사무실에서 일부 서버에 New Relic을 직접 설치한 뒤 지연 시간, 오류율, 요청 수가 처음 보이기 시작했고, 이후 약 2개월 반 동안 구조 작업이 확대되어 사이트 개선에 기여함

2013년 10월 18일, 구조 작업의 시작

  • HealthCare.gov 복구 작업은 2013년 10월 18일 금요일 오전 7시 15분, 백악관 West Wing 입구 근처에 모인 작은 그룹에서 본격화됨
  • 초기 그룹에는 Todd Park, Brian Holcomb, Gabriel Burt, Ryan Panchadsaram, Greg Gershman, Paul Smith가 있었고, 그날 늦게 Mikey Dickerson이 장시간 스피커폰 통화로 합류함
  • 일부는 정부 외부에서 왔고 일부는 당시 정부에서 일하고 있었지만, 모두 스타트업이나 대형 기술 조직 경험을 가진 기술 전문가였음
  • 당시 미국 CTO였던 Todd Park는 HealthCare.gov를 만든 정부 직원과 계약업체 팀을 보강하기 위해 이들을 선별함
  • 임무는 “기병대처럼 돌진”하는 방식이 아니라, 이미 압박과 스트레스가 큰 현장에 조용히 들어가 정보를 모으고 평가하는 저자세 지원에 가까웠음
  • Todd Park는 다음 30일이 중요하다고 말했고, 목표는 공개 등록 기간이 끝나는 2014년 3월 31일까지 700만 명을 등록시키는 것이었음

셧다운과 출시 실패가 만든 공백

  • HealthCare.gov는 2013년 10월 1일 출시됐지만 제대로 작동하지 않았고, 같은 날 연방정부 셧다운이 시작됨
  • 셧다운 때문에 HealthCare.gov 핵심 팀 바깥의 인력이 도움을 주러 들어올 수 없었음
  • 그 사이 뉴스는 셧다운과 느리게 진행되는 출시 재난으로 채워졌고, 정보 공백과 추측, 우려가 커짐
  • 백악관은 HealthCare.gov에 무엇이 잘못됐는지 파악하지 못했고, 사이트가 실패하면 Affordable Care Act 혜택을 수백만 명에게 전달하는 핵심 수단이 흔들릴 수 있었음
  • 셧다운은 10월 17일 끝났고, 외부 기술팀은 그제야 실제 상황을 확인하고 작업을 시작할 수 있었음

첫날 오전에 파악한 시스템의 큰 그림

  • 팀은 백악관 Navy Mess에서 아침을 먹은 뒤 Chief of Staff 사무실로 올라가 Denis McDonough를 만남
  • Denis McDonough는 “고칠 수 있느냐”고 직접 물었고, 팀원 일부는 긴장한 상태에서 “그렇다”고 답함
  • 이후 HHS 본부인 Hubert H. Humphrey Building으로 이동해 CMS 책임자인 Marilyn Tavenner와 참모진을 만남
  • 이 자리에서 HealthCare.gov의 구조, 주요 기능 구성요소, CMS 리더십이 알고 있던 장애 위치와 고수준 성능 문제가 공유됨
  • CMS 리더십은 보건정책 전문가와 행정가였기 때문에, 전달된 정보는 주로 사이트의 비즈니스 지표와 고수준 성능 설명에 가까웠음
  • 오전 후반에는 메릴랜드 Woodlawn의 CMS 본부로 이동해 Michelle Snyder, Henry Chao, Dave Nelson 등 HealthCare.gov 리더십을 만남
  • 이곳에서 배포 문제, 병목, 사용자가 사이트에서 “막히는” 지점, MarkLogic XML 데이터베이스, 배포 아키텍처와 서버 유형에 대한 정보가 조금씩 드러남

XOC에서 드러난 운영 현실

  • 오후에는 Columbia, Maryland의 Exchange Operations Center, 즉 XOC로 이동함
  • XOC는 HealthCare.gov 운영을 위한 미션 컨트롤식 허브였고, 팀은 그곳에서 사이트를 직접 다루는 기술자들의 이야기를 들음
  • 현장에서 확인한 문제는 초기 예상보다 훨씬 심각했음
    • 소스 코드 변경에 대한 신뢰 부족이 있었음
    • 사이트의 많은 부분이 복잡한 코드 생성 절차에 의해 만들어졌고, 팀 간 세심한 조율이 필요했음
    • 테스트는 대체로 수동 프로세스였음
    • 릴리스와 배포는 긴 야간 다운타임을 요구했고, 실패하면 긴 롤백이 뒤따랐음
    • 핵심 데이터 계층에는 스키마가 없었음
    • 호스팅 리소스 프로비저닝은 느리고 자동화되어 있지 않았음
    • APM은 물론 CPU·메모리·디스크·네트워크 같은 기본 지표도 팀이 볼 수 있는 형태로 갖춰져 있지 않았음
  • 이 시점에 팀은 상황이 처음 예상보다 훨씬 나쁘다는 점을 받아들였고, Paul Smith는 Moleskine 노트에 들은 내용을 급히 적어둠

CGI 사무실에서 New Relic을 붙인 밤

  • 저녁에는 버지니아 Herndon의 CGI 사무실로 이동함
  • CGI는 HealthCare.gov의 주 계약업체였고, 팀은 리더십과 기술팀을 만나 질문을 던짐
  • 이 만남에서는 외부 기술팀이 CGI 팀의 신뢰를 얻는 일이 중요했음
    • CGI 팀은 압박을 받고 지쳐 있었음
    • 구조팀은 비난하러 온 것이 아니라 돕기 위해 왔다는 점을 강조함
    • 고트래픽 웹사이트 경험을 바탕으로 엔지니어링 역량을 보여주려 함
  • 핵심 질문은 “사이트에 무엇이 잘못됐고, 그것을 어떻게 아느냐”였지만, CMS와 CGI는 시스템 내부에서 특정 구성요소가 기대대로 동작하지 않는 지점을 대부분 보여주지 못했음
  • 팀은 익숙한 APM 스타일 모니터링 서비스인 New Relic을 일부 서버에 설치해보자고 제안함
  • 일반 릴리스 절차를 우회해 선택한 서버 일부에 에이전트를 직접 설치했고, CMS 리더가 이미 New Relic 라이선스가 있음을 확인한 뒤 승인함
  • 자정 가까운 시간까지 남아 있던 사람들이 변경을 진행했고, 회의실 화면의 New Relic 관리자 화면에는 선택된 “red shard” 서버들이 곧 지표를 보내기 시작함
  • 처음으로 요청 지연 시간 급증, 오류율, 분당 요청 수 같은 실시간 운영 지표가 보였고, 이전까지 사실상 보이지 않던 시스템 상태가 드러남
  • 이 지표 덕분에 비즈니스 지표와 시스템 상태를 연결해 보고, 가장 큰 개선을 낼 수정과 조치의 우선순위를 정할 기반이 생김

18시간짜리 첫날 이후

  • Herndon을 떠난 뒤 팀은 새벽 2시쯤 조용한 백악관 Roosevelt Room에서 짧게 회고함
  • 이 시점에 팀은 문제가 단기간 조언만으로 끝날 규모가 아니며, 사이트가 회복될 때까지 당분간 이 작업에 매달려야 한다고 받아들임
  • 몇 시간 잠을 잔 뒤 다음 날 아침 다시 Herndon으로 향함
  • 첫날 일정은 약 18시간이었고, 이후에도 비슷한 마라톤이 이어짐
  • 12월 말까지 약 2개월 반 동안 tech surge는 확대되고 새 팀원들이 합류했으며, HealthCare.gov 개선에 도움을 줌
  • 그해 수백만 명이 건강보험 보장에 등록했고, 많은 사람에게는 처음 있는 일이었음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 원래 의도는 각 주가 자체 거래소를 운영하고, 거부한 주의 주민만 연방 거래소를 쓰게 하는 것이었음
    처음에는 36개 주가 자체 거래소를 만들지 않았고 0, 현재는 D.C.를 포함해 20개 주가 자체 마켓플레이스를 운영하는 것으로 보임 1
    HealthCare.gov 주 팀 외부 인력이 도우러 들어오지 못하게 만든 2013년 정부 셧다운은 Ted Cruz 상원의원이 ACA를 방해하려는 목적으로 주도한 일이었음 2

    • 주 정부 기관을 운영하는 입장이라면, 연방 정부가 자기 시스템을 그냥 쓰라고 할 때 굳이 주 예산을 들이지 않고 연방 시스템을 택했을 것 같음
      미국의 “주는 각자 독립적”이라는 원칙이 가끔은 너무 멀리 간다고 느낌
    • 주 운영 거래소 자체가 공화당과 경계선에 있던 민주당, 특히 Arlen Specter를 위한 타협안이었음
      이들은 연방 의료 시스템이 결국 보편적 의료보험으로 이어질까 봐 걱정했고, 타협을 얻어낸 뒤에는 법이 죽기를 바라며 거래소 구현을 거부했음
      하지만 법은 죽지 않았고, 아직도 그걸 못마땅해함
    • 주가 마켓플레이스를 운영한다는 얘기를 보니 Clinton 시절의 실패한 복지 “개혁”이 떠오름
      연방 자금을 주 단위 포괄보조금으로 넘기고, TANF 같은 프로그램과 자격 심사를 주가 맡게 한 결과 1, 연방 예산 1달러가 실제 지원으로 이어지는 효율도, 지원받는 사람 수와 금액도 크게 나빠졌음
      ACA의 주 마켓플레이스 근거는 모르겠지만, 역사적으로 주를 끼워 넣으면 중간자가 프로그램을 망치고 돈을 다른 곳으로 돌릴 여지가 커졌음
      예를 들어 Texas는 Medicaid 확대를 위해 연방 정부가 주려던 연간 50~60억 달러의 공짜 돈을 거절했음 2
    • 이 일이 시작되고 1~2년쯤 뒤에, 개별 주 마켓플레이스에서 보험사들이 빠져나간다는 기사들이 한동안 많이 나왔던 걸로 확실히 기억함
      어떤 보험사가 치료비가 매우 비싼 소수 환자 때문에 손해를 봤고, 그 비용이 너무 커져 가격을 올리자 아무도 그 상품을 사려 하지 않았다는 내용이 여러 번 나왔던 것 같음
      최근에 그 기사들을 찾아봤는데 더는 못 찾겠어서, 내가 상상한 일인지 헷갈림
    • Nevada 거래소는 쓸 수 없는 수준이라, 작년에 가입에 성공했는데도 지금은 무보험 상태가 됐음
      돈도 있고 거래할 의지도 있는데 할 수가 없으니, 이 시스템은 실패임

  • 이걸 고치려고 모두 끌려 들어갔을 때 이 사람들과 같이 일했던 기억이 남아 있음
    Gabe는 VIM으로 코딩하는 모습이 마치 명 바이올리니스트 같았고, Mikey와 일하면서 지표와 SRE의 힘을 봤음
    방 안의 모두가 다음 벤더를 손가락질하던 상태에서 병목의 일부를 실제로 찾아내는 쪽으로 바뀌었음
    대체로 망가진 시스템을 큰 리팩터링을 위해 오프라인으로 내리지도 못한 채 고치는 건 조깅하는 사람을 수술하는 것 같았고, 정말 거친 경험이었음

    • 2014년쯤 Velocity 컨퍼런스에서 Mikey가 이 이야기를 발표하는 걸 봤는데, 그가 설명하는 과정을 듣는 게 정말 흥미로웠음

  • D.C.의 작은 스타트업이 프런트 랜딩 페이지를 맡은 하청의 하청의 하청 정도였는데, 그래도 사람들이 healthcare.gov에서 500 오류 페이지가 아니라 실제 페이지에 도착하게 만들 수 있었던 일이 좋게 기억남
    기억이 맞다면 Jekyll을 쓰는 단일 서버 하나와 백업 하나 덕분이었음

    • 현재 정부 기술 쪽 계약자로 일하는 입장에서, 조달 규칙 때문에 연방 기관이 자체 소프트웨어 개발을 거의 못 하게 되고 대부분이 말 그대로 다단계 하청으로 나간다는 걸 더 많은 미국인이 알아야 한다고 느낌
    • 거래소 출시 전의 초기 healthcare.gov는 D.C.의 작은 웹 개발사 Development Seed가 만든 정보성 소형 사이트였음
      지금 표현으로는 “정적 페이지 생성” 방식이었고, 그래서 작은 하드웨어에서도 호스팅할 수 있었음
      당시에는 꽤 앞선 전술로 여겨졌고, 아마 이걸 떠올린 것 같음
      내가 알기로 그 사이트는 연방 거래소가 열리면서 완전히 교체됐고, 랜딩 페이지 자체는 개인정보를 받거나 처리하지 않았기 때문에 제공에 큰 난관은 없었음
      모든 것이 멈춘 건 사용자가 실제로 보험 상품을 찾으려 하기 시작한 뒤였음
      Development Seed는 나중에 들어봤을 법한 또 다른 프로젝트인 Mapbox도 만들었고, 결국 회사 전체가 그쪽으로 전환했음

  • 어느 팟캐스트에서 “백엔드 시간 초과” 실패를 오류로 보여주는 대신, 데이터를 이메일로 보내고 사용자에게 “좋습니다, 받았습니다. 나중에 와서 확인하세요”라고 안내하는 방식으로 바꿨다는 얘기를 들은 기억이 있음
    아주 영리하다고 생각했고, 나중에 비상시에 써먹을 수 있는 방식으로 기억해 뒀음
    WebTV에서 데이터베이스 과부하가 났을 때도 비슷한 일이 있었는데, 데이터베이스 연결이 필요하던 마지막 단계 메일 전달 서버들을 모두 내려서 메일이 인바운드 SMTP 서버에 큐잉되게 했고, 이후 데이터베이스 과부하가 풀렸을 때 비웠음
    교훈은 트랜잭션 방식으로 동작하도록 설계됐지만 실패 중인 시스템의 부하를 줄이려면, 큐에서 처리하는 배치 지향 처리를 쓰라는 것임

    • 맞음, 기억하기로는 Go로 서버의 평문 파일에 쓰고 있었고, 그 파일이 해당 프로세스의 큐처럼 동작했음
    • 다른 곳에서 언급된 Changelog 팟캐스트 36:16 지점에 설명되어 있음

  • 이 주제로 나온 “Go Time” 팟캐스트 에피소드가 훌륭했고, 사이트 일부를 서비스하는 데 Go를 어떻게 썼는지 다룸
    이 에피소드와 팟캐스트를 강력 추천함
    https://changelog.com/gotime/154

  • 흥미로운 기술 논의일 줄 알고 눌렀는데, 기술 얘기는 꽤 뒤에야 나왔음
    대신 프로세스의 무대 뒤 모습이 예상 밖으로 매우 흥미로웠고, 다음 편이 정말 기대됨

  • 이 글을 읽는 게 정말 좋았음
    10년 전 HN에서 웹사이트의 GitHub 소스 코드를 샅샅이 뜯어보던 일이 기억남: https://news.ycombinator.com/item?id=6540993

  • 실제로 벌어진 일은 이상적이지 않았지만, 이 회고 외에 정확히 무슨 일이 있었고 어떻게 해결됐는지 더 자세히 설명한 자료가 있는지 궁금함
    이 시리즈의 다음 글들도 계속 찾아볼 생각임
    약간 엔지니어링 역량 포르노 같은 느낌이지만 이런 이야기를 좋아함
    몇 년 전에 The Phoenix Project를 읽었는데, 소설화되어 있고 Agile과 DevOps를 꽤 노골적으로 소개하는 책이었지만 데이터 분석가인 나에게는 새로워서 좋았고, 비슷한 추천이 있으면 읽어보고 싶음

    • Time, 맞아 그 Time Magazine이 이 일을 꽤 잘 다뤘음: https://time.com/10228/obamas-trauma-team/
      좋은 발췌를 하나 들면, Dickerson은 통제실 바로 밖 벽에 규칙을 붙였음
      규칙 1: “워룸과 회의는 문제를 해결하기 위한 곳이다. 책임 전가에 창의적 에너지를 쓰는 곳은 얼마든지 따로 있다.”
      규칙 2: “어떤 사안에 대해 말해야 하는 사람은 직급이 가장 높은 사람이 아니라 그 사안을 가장 잘 아는 사람이다. 관리진과 임원이 덜 정확한 정보로 말하는 동안 누군가 수동적으로 앉아 있다면 우리는 궤도를 벗어난 것이고, 나는 그걸 알고 싶다.” Dickerson은 나중에 “관리자들을 치우면 엔지니어들은 문제를 해결하고 싶어 한다”고 설명했음
      규칙 3: “앞으로 24~48시간 안에 우리에게 피해를 줄 가장 긴급한 사안에 집중해야 한다.”

  • 해법은 이런 일을 같은 회사들에 계속 맡기지 않는 것임
    CGI, IBM 같은 회사들이 충분히 유능하지 않다는 건 분명해 보이는데, 왜 비슷한 향후 계약에서 입찰 금지를 당하지 않는지 모르겠음
    계약을 망치면 향후 10년간 모든 정부 계약에서 배제하면 됨
    그러면 쓰레기 같은 결과물이 계속 순환하는 대신 실제로 동작하는 기술을 갖게 될 것임

    • 유럽 공공 부문 여러 산업에서 IT 컨설팅을 해본 경험으로는, 계약 경쟁을 열 때 같은 산업의 대규모 프로젝트 경험이 있으면 점수를 받거나 아예 필수 요건이 되기도 함
      그래서 작은 회사들은 경쟁에 참여하기 어려워짐
    • “모든 정부 계약에서 금지”라고 해도 회사 이름만 바꾸면 됨
      아니면 팀을 섞어버리면 됨
    • 정부가 말도 안 되는 요구사항으로 실패를 보장하는 경우가 많음
      곧 일을 맡을 사람이 아무도 남지 않게 될 것임

  • “MarkLogic이라는 XML 데이터베이스를 포함한 특정 기술들”이라니, 3억 명이 쓰는 핵심 서비스에 XML 데이터베이스라니?
    으스스함

    • 그때가 NoSQL의 고조기쯤이긴 했지만, 설마 말 그대로였을 리는 없다고 봄
      아마 비즈니스 규칙이 XML에 있고 사실상 읽기 전용이며, 동적 데이터는 관계형 데이터베이스에 있었던 게 아닐까 싶음
      어쩌면 그냥 희망 섞인 추측일 수도 있음
    • 그게 주 데이터 저장소였을 것 같지는 않음
      설정 데이터베이스였을 수는 있는데, 문제가 비즈니스 로직에서 나온 것처럼 들리니 그 자체로도 문제가 됐을 수 있음
답변달기