今日は「アマゾンの頭脳流出」がAWSを危機に陥れた日

217日前原文(theregister.com)

概要

AWSの大規模障害の根本原因が DNS問題 であること
経験豊富なエンジニア の流出が障害対応力の低下を招いている懸念
DynamoDB など基幹サービスへの影響でインターネット全体に広範な障害発生
人材流出 と組織の知識喪失が、今後の信頼性に大きなリスク
技術の問題ではなく、 維持管理する人材の問題 が核心

「It's always DNS」AWS大規模障害の本質

システム管理者の間で有名な「It's always DNS」という言葉、 障害の多くがDNS関連 で発生する現実
2024年のAWS大規模障害も DNSが原因 で発生
AWSの ベテランエンジニアの流出 が障害対応の遅れに影響している疑念
2022年から2024年にかけて 27,000人以上のAmazon従業員がレイオフ、多くがAWSにも影響
DynamoDB が障害の中心となり、銀行、ゲーム、SNS、政府サービス、Amazon.com自体など 広範なサービス停止

障害発生から対応までの流れ

10月20日午前0:11（PDT）、 US-EAST-1リージョンで複数サービスのエラー率・遅延増加 をAWSが調査開始
約1時間後、 DynamoDBエンドポイントへのリクエストで重大なエラー率 を確認
2:01には DynamoDB APIエンドポイントのDNS解決が根本原因 と特定、他サービスへの連鎖障害発生
DynamoDBは基幹サービス であるため、障害の波及範囲が非常に大きい
AWSの障害情報ページでは 75分間「すべて正常」と表示 され、情報伝達の遅延が浮き彫り

技術力と人的資本の課題

AWSは インフラ運用のプロフェッショナル だが、 リージョン単位の障害でも世界的ニュース になる規模
障害の複雑さは 大規模運用ならでは で、単純な見落としではない
ベテランエンジニアの退職 が障害対応力の低下に直結
- Justin Garrison の退職時の指摘：「大規模障害（LSE）が増加、2024年にも重大障害が予想される」
- ノウハウの継承不足 が根深い問題
新規雇用では 過去の障害パターンや暗黙知の再獲得が困難
「人が辞めても問題ない」は幻想、実際には知識喪失が信頼性に直結

人材流出の実態と影響

AWS広報は「人材流出はない」と主張するが、 事実として大規模なレイオフと自発的離職が発生
社内資料によると「後悔離職率」69%〜81%、離職を惜しまれる人材の流出
Return to Office（出社回帰）施策 への不満が熟練エンジニアの離職要因
初期メンバーは市場価値が高く、AWSに留まる理由が減少

今後の展望と筆者の見解

転換点 を迎えたAWS、 深い障害モードを理解する人材の喪失 がクリティカル
新体制はコスト削減重視 だが、 復旧・検知の遅延 が目立つ
「フルガリティ（Frugality）」の本来の意味は「少ないリソースで多くを成し遂げる」だが、 今は「何もない状態で全てやる」状況
冗長で経験豊かな人材 がAWSの強みだったが、 人員削減で基本的な部分から崩壊
技術の古さではなく、維持する人材の新しさが問題
市場は今回の障害を許容するかもしれないが、 今後同様の障害が増加するリスク
「これは単発の事故」とAWSは説明するだろうが、 エンジニアの空洞化で再発リスクが高まる
次の障害は時間の問題、人材不足のチームがどのエッジケースでつまずくかが焦点

Hackerたちの意見

何かが売れたり修理されたりするには、その作り方を知っている人が必要だよね。

└

でも、人を大事にするよりも、PIPやスタックランク、出世ゲームを続ける方が大事なんだよね（笑）

└

プログラミングを理論構築として捉えることが大事だよね。[1] つまり、システムを構築することも理論構築の一環で、物事がどう機能するかのメンタルモデルが必要なんだ。メンタルモデルは人の頭の中にあって、彼らが出て行くときには消えちゃう。経営陣はこれを痛い目見て学ぶことになるよ。[2] [1] https://pages.cs.wisc.edu/~remzi/Naur.pdf [2] https://x.com/elonmusk/status/1980221072512635117

El Regの好きなところは、物事をはっきり言ってくれるところだね。

└

著者が作品にユーモアや個性を注入できるところも大好きだよ。

今こそ、人を大事にして、彼らが仕事をするための最良のツールを提供することが重要だと受け入れるべき時だよ。つまり、数十年変わらずそうなんだ。確かに、開発ツールは日々良くなってる。リストラもできるけど、すぐには実感できないよね。未来を担保にすることになるし、その利子は痛いほど高い。信じないことを一時停止しても、リストラがうまくいくわけじゃないから。

└

離職が悪いってことを知らないわけじゃないと思う。むしろ、業界がスタッフを均一化して、平凡さを好むようにデザインされてるんじゃないかな。そうすると、従業員が本当に交換可能になっちゃう。才能がカウボーイ的なものに例えられるところまで来てるよね。

└

いや、数十年前の「新しい」大手テック企業たちは、今まさにIBMのフェーズに入ったところだよ。

└

うまくいってるみたいだね。彼らはジュニアのプリンシパルエンジニアの4分の1を解雇したけど、株価は上がった。数ヶ月後に大規模な障害があったけど、また株価は上がった。今のところ、彼らの戦略はうまくいってるみたいだね。

実際の進展が、アメリカ西海岸の始業時間あたりから始まったのは確かに怪しいよね。それ以前の更新は「監視して対策中」みたいな一般的なものばかりで、具体的な内容はなかったし。

└

今朝Redditで読んだ投稿がすごく納得できる内容だった。

└

回復はシアトル時間の早朝（4時くらい）だと思ってたんだけど、始業は9時くらいだよね。もしかして、ニューヨーク時間で早朝（6時）に回復が始まったのかな？

まるで、制度的な知識って本当に存在するもので、BIG BRAIN MBAのスプレッドシートには載せられないって感じだね。

え、彼らのAIはもっと早く見つけられなかったの？RAGをちゃんと整えないとね。

スタートアップでもこれが起こるのを見たことあるよ。買収されると、トップの人たちがストックが権利確定するタイミングで辞めたり、メガコープが違う人を求めて追い出されたりするんだ。技術を知ってる人がいなくなって、維持できない混乱が残って、誰もそれを修正できなくなる。

「物事が壊れている」から「単一のサービスエンドポイントに絞り込んだが、まだ調査中」まで75分かかったって感じがする。これはちょっと苦い薬だね。75分って本当にそんなに長い時間なの？ウェブ開発の仕事はしてないから、もしかしたら単純すぎるのかも。でも、75分で単一のサービスエンドポイントを診断できるのはかなり良いと思う。ファームウェアの仕事をしてた時は、壊れてる部分を診断するのに何週間もかかってたから。

└

75分での対応は、どんな大きな問題でもかなりいいと思うよ。

└

アマゾンは業界で最高のインフラを持ってるはずだよ。だって他の会社もみんなそこを使ってるからね。こういう問題をすぐに解決できるSREの才能にアクセスできるはずだよ。

└

それに、アイデアを得るのにそれより短い時間がかかった可能性も高いけど、一般的には公のアップデートでは慎重になるべきだよ。そうしないと、ユーザーが誤解しちゃうからね。

そうだね。原因は特定するけど、その原因の背後にある原因まではわからないんじゃないかな。

エンジニアと倉庫作業員の間で、どれくらいの時間で「働きたい」と思っていた人たちを全員解雇しちゃうんだろうね。何十万のH1-Bエンジニアや何千万の不法移民の倉庫作業員がいるけど、こんな大企業がこんなに早く多くの人を解雇すると、選択肢が尽きる瞬間が来るんだよね。ロボットチキンのスケッチを思い出すよ。デススターの帝国軍の将校たちが、ダース・ベイダーにフォースで絞め殺されるふりをして、ライトセーバーで殺されるのを避けるってやつ。で、名前を変えて別の仕事に戻ってくるんだけど、アマゾンの場合はもっとひどいよ。誰も戻りたがらないから。

└

本当にそうだよ。二度とそこで働きたいと思うまともなエンジニアなんて知らないよ。

ハクソク