- 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のExchange Operations Center、すなわちXOCへ移動した
- XOCはHealthCare.gov運用のミッションコントロール型ハブであり、チームはそこでサイトを直接扱う技術者たちの話を聞いた
- 現場で確認した問題は、当初の想定よりはるかに深刻だった
- ソースコード変更に対する信頼不足があった
- サイトの多くの部分は複雑なコード生成手順によって作られており、チーム間の綿密な調整が必要だった
- テストはおおむね手動プロセスだった
- リリースとデプロイには長い夜間ダウンタイムが必要で、失敗すれば長いロールバックが続いた
- 中核データ層にはスキーマがなかった
- ホスティングリソースのプロビジョニングは遅く、自動化されていなかった
- APMはもちろん、CPU・メモリ・ディスク・ネットワークといった基本指標も、チームが確認できる形では整っていなかった
- この時点でチームは、状況が当初の想定よりはるかに悪いことを受け入れ、Paul SmithはMoleskineノートに聞いた内容を急いで書き留めた
CGIのオフィスでNew Relicを接続した夜
- 夕方にはバージニア州HerndonのCGIオフィスへ移動した
- CGIはHealthCare.govの主契約企業であり、チームはリーダー層と技術チームに会って質問を投げかけた
- この面談では、外部の技術チームがCGIチームの信頼を得ることが重要だった
- CGIチームはプレッシャーを受け、疲弊していた
- 救出チームは非難しに来たのではなく、支援するために来たのだと強調した
- 高トラフィックWebサイトの経験をもとに、エンジニアリング能力を示そうとした
- 中核となる問いは「サイトの何が問題で、それをどう把握しているのか」だったが、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の改善を支援した
- その年、数百万人が健康保険の保障に登録し、多くの人にとってそれは初めてのことだった
1件のコメント
Hacker News のコメント
もともとの意図は、各州が独自の取引所を運営し、拒否した州の住民だけが連邦取引所を使うようにすることだった
当初は36州が独自の取引所を作らず 0、現在は D.C. を含め20州が独自のマーケットプレイスを運営しているように見える 1
HealthCare.gov の州チーム以外の人員が支援に入れないようにした2013年の政府閉鎖は、Ted Cruz 上院議員がACAを妨害する目的で主導したものだった 2
アメリカの「州はそれぞれ独立している」という原則は、ときどき行き過ぎていると感じる
彼らは連邦医療制度が最終的にユニバーサル・ヘルスケアにつながるのではないかと心配しており、妥協を勝ち取った後は、法律が死ぬことを望んで取引所の実装を拒否した
しかし法律は死なず、いまだにそれを不満に思っている
連邦資金を州単位の包括補助金として渡し、TANF のようなプログラムと資格審査を州に任せた結果 1、連邦予算1ドルが実際の支援につながる効率も、支援を受ける人の数と金額も大きく悪化した
ACA の州マーケットプレイスの根拠は知らないが、歴史的に州を挟むと、中間者がプログラムを台無しにし、資金を別の場所へ回す余地が大きくなった
例えば Texas は、Medicaid 拡大のために連邦政府が州に渡すはずだった年間50〜60億ドルの無償資金を拒否した 2
ある保険会社が治療費の非常に高い少数の患者のせいで損失を出し、その費用が大きくなりすぎて価格を上げると、誰もその商品を買おうとしなかった、という内容が何度も出ていた気がする
最近その記事を探してみたがもう見つけられず、自分の想像だったのか混乱している
お金もあり、取引する意思もあるのにできないのだから、このシステムは失敗だ
これを直すために全員が引きずり込まれたとき、この人たちと一緒に働いた記憶が残っている
Gabe が VIM でコーディングする姿はまるで名バイオリニストのようで、Mikey と働きながら指標と SREの力を見た
部屋にいる全員が次のベンダーを指さしていた状態から、ボトルネックの一部を実際に見つけ出す方向へ変わっていった
概して、壊れたシステムを大規模リファクタリングのためにオフラインにすることもできないまま直すのは、ジョギング中の人を手術するようなもので、本当に荒っぽい経験だった
D.C. の小さなスタートアップが、フロントのランディングページを担当する下請けの下請けの下請けくらいの立場だったが、それでも人々が healthcare.gov で500エラーページではなく実際のページに到達できるようにできたことは、よい思い出として残っている
記憶が正しければ、Jekyll を使う単一サーバー1台とバックアップ1台のおかげだった
今の言い方では「静的ページ生成」方式で、そのため小さなハードウェアでもホスティングできた
当時としてはかなり先進的な戦術と見なされており、おそらくそれを思い出しているのだと思う
私の知る限り、そのサイトは連邦取引所の開設時に完全に置き換えられ、ランディングページ自体は個人情報を受け取ったり処理したりしなかったため、提供に大きな難関はなかった
すべてが止まったのは、ユーザーが実際に保険商品を探そうとし始めた後だった
Development Seed は、後に聞いたことがあるかもしれない別のプロジェクト、Mapboxも作り、最終的には会社全体がそちらへ転換した
あるポッドキャストで、「バックエンドのタイムアウト」失敗をエラーとして表示する代わりに、データをメールで送り、ユーザーに「大丈夫です、受け取りました。後で来て確認してください」と案内する方式に変えた、という話を聞いた記憶がある
とても賢いと思い、後で緊急時に使える方法として覚えておいた
WebTV でデータベース過負荷が起きたときも似たようなことがあり、データベース接続を必要としていた最終段のメール配送サーバーをすべて落として、メールがインバウンド SMTP サーバーにキューイングされるようにし、その後データベースの過負荷が解消されたときに処理した
教訓は、トランザクション方式で動くように設計されているが失敗中のシステムの負荷を下げるには、キューで処理するバッチ指向処理を使え、ということだ
この話題を扱った「Go Time」ポッドキャストのエピソードが素晴らしく、サイトの一部を提供するのに Go をどう使ったかを取り上げていた
このエピソードとポッドキャストを強くおすすめする
https://changelog.com/gotime/154
面白い技術的な議論だと思ってクリックしたが、技術の話はかなり後になってから出てきた
代わりに、プロセスの舞台裏が予想外にとても興味深く、次回が本当に楽しみになった
この記事を読むのは本当に楽しかった
10年前に HN でウェブサイトの GitHub ソースコードを隅々まで調べていたことを思い出す: https://news.ycombinator.com/item?id=6540993
実際に起きたことは理想的ではなかったが、この振り返り以外に、正確に何が起きてどう解決されたのかをもっと詳しく説明した資料があるのか気になる
このシリーズの次の記事も追い続けるつもり
ちょっとエンジニアリングの能力ポルノのような感じもするが、こういう話は好きだ
数年前に The Phoenix Project を読んだ。小説仕立てで、Agile と DevOps をかなり露骨に紹介する本だったが、データアナリストの自分には新鮮でよかった。似たようなおすすめがあれば読んでみたい
良い抜粋を一つ挙げると、Dickerson はコントロールルームのすぐ外の壁にルールを貼っていた
ルール1: 「ウォールームと会議は問題を解決するための場所である。責任転嫁に創造的エネルギーを使う場所なら、ほかにいくらでもある。」
ルール2: 「ある事案について発言すべきなのは、役職が最も高い人ではなく、その事案を最もよく知っている人である。管理職や幹部がより不正確な情報で話している間に、誰かが受け身で座っているなら、私たちは軌道を外れているということであり、私はそれを知りたい。」Dickerson は後に「マネージャーたちをどかせば、エンジニアは問題を解決したがる」と説明していた
ルール3: 「今後24〜48時間以内に私たちに損害を与える、最も緊急の事案に集中しなければならない。」
解決策は、こうした仕事を同じ会社たちに任せ続けないことだ
CGI や IBM のような会社が十分に有能でないのは明らかに見えるのに、なぜ同様の将来の契約で入札禁止にならないのかわからない
契約を台無しにしたら、今後10年間すべての政府契約から排除すればいい
そうすれば、ゴミのような成果物が循環し続ける代わりに、実際に動く技術を手にできるはずだ
そのため、小さな会社は競争に参加しにくくなる
あるいはチームを混ぜてしまえばいい
そのうち仕事を引き受ける人が誰も残らなくなるだろう
「MarkLogic という XML データベースを含む特定の技術」だなんて、3億人が使う中核サービスに XML データベース？
ぞっとする
おそらくビジネスルールが XML にあり、実質的に読み取り専用で、動的データはリレーショナルデータベースにあったのではないかと思う
もしかすると、単なる希望的観測かもしれない
設定データベースだった可能性はあるが、問題はビジネスロジックから出ていたように聞こえるので、それ自体でも問題になり得たはずだ