- あるエンジニアが、Snowflake のクエリ後の 10分間アイドル設定を短縮したところ、年間の予想データベース費用が約100万ドルから50万ドルに下がった
- 数年遅れた Advanced Analytics Platform は、リリース後もスプレッドシート、S3、Lambda、MongoDB、Snowflake、JavaScript ストアドプロシージャが絡み合う 複雑な ETL チェーンに依存していた
- コスト浪費の核心は、1日1TB未満のデータを処理しているだけなのに、平均 2秒のクエリの後もコンピュートが長時間オンのままになっていた構造だった
- 変更はまず一部のコンピュートに適用され、管理者は節約効果を認めながらも全面適用を遅らせようとし、PowerPoint では 利用パターン分析による最適化のように包装された
- 50万ドルを削減した後も報酬は不確実で、会議と報告の負担だけが増え、組織の非効率が個人の短時間の実行よりも大きな政治的コストを生む事例となった
数年先送りされた分析プラットフォーム
- 会社はより データドリブンに仕事を進めるとして分析プラットフォームを作ることにし、関連人材を採用した
- データサイエンティストとして入社したエンジニアは、実際のデータサイエンス業務を行えず、機械学習やデータパイプライン用のコンピュートのリクエストも Advanced Analytics Platform、つまり AAP のデプロイまで待つようにと言われた
- AAP は当初1月にリリース予定だったが3月に延期され、その後 Covid を理由に保留された
- 彼が会社を去ってから3年後に AAP はリリース準備を終えたが、実際に必要だった機能はそもそも計画に含まれていなかったことが判明した
- 同じ週にエンジニア4人が会社を辞め、彼は条件を提示したうえで AAP チームに加わった
リリース直後に露呈した技術的負債
- AAP はリリースから間もないにもかかわらず、技術的負債と運用リスクが多かった
- 新しく採用された同僚は初日から、プロジェクトリポジトリ内で誤ったフォルダに移動すると CI/CD パイプライン経由で本番環境を削除できるファイルを見つけた
- このファイルには管理者アカウントに必要なキーとパスワードも含まれていた
- データベースのアクセス権変更は、約2KBの CSV をアップロードする作業にもかかわらず、過度に長い経路をたどっていた
- スプレッドシートを Python がパースする
- 結果を S3 に入れる
- Lambda が再び S3 形式に変換する
- MongoDB が S3 ファイルを取り込む
- 別の Lambda が MongoDB レコードを S3 に渡す
- Snowpipe が S3 データを Snowflake に取り込む
- JavaScript ストアドプロシージャが Snowflake データをリレーショナル形式にピボットする
- セキュリティチームは悪性コンテンツを簡単にスキャンできる形式を求めたため、すべてが CSV に変換されたが、実際の スキャンツールはデプロイされなかった
- Lambda 関数は以前の実装の名残である
counter = 1 から始まり、この行がそのままコピーされ続けていた
- CI/CD テストは、デバッグ中に
tee コマンドを使ったことで失敗コードが上書きされ、数か月間失敗状態のまま残っていた
- API パスワードの取得も2段階にねじれていた
- AWS サービスで
service-password のようなキーを検索すると、値としても service-password が返ってくる
- その値を再び別のサービスで実際のパスワードを探すために使う
- パイプライン設定ファイル生成スクリプトは、後で必要になるかもしれないという理由でコメントアウトされた600行から始まっていた
コスト超過を生んだ Snowflake 設定
- プラットフォームは以前の運用モデルより何倍も高く、データベース費用の予算を大きく超過した
- 本来の年間運用費は約 20万ドル程度を想定していたようだが、実際の予想費用はほぼ100万ドルに近づいた
- データベースは Snowflake で、Snowflake はクエリを実行するコンピュータのサイズに応じて課金される
- コンピュートはオンになっている間だけ費用が発生する
- チームは週に数千件程度のクエリを実行しており、その大半はほとんど読まれない PowerBI レポートを少しずつ調整する開発者の実験用クエリだった
- 平均クエリ実行時間は約 2秒だったが、コンピュートはクエリ後10分間アイドル状態で残るよう設定されていた
- 彼は参加から約1か月後にこの設定を見つけ、調整しようと提案したが、調査作業が必要だという手続き上の議論だけが続き、実行されなかった
5分の変更と検証
- 数か月後、「Discovery: Optimise Costs」カードを受け取った彼は、次のスタンドアップで話す結果が必要だったため、既存の仮説を自分で確認することにした
- 別チームの有能そうな新しいエンジニアに管理者権限を与えたいと頼んだが、管理者は許可しなかった
- 代わりに管理者権限ではない低レベルのデータベース認証情報を共有し、そのエンジニアがコスト削減の可能性を 常識チェックした
- 週の最終日午後4時、彼は管理者のいないエンジニアのチャットルームで問題がないか確認したうえで設定を変更した
- 安全のため、すべてのコンピュートではなく 一部のコンピュートにだけ先に適用した
削減効果と組織の反応
- 翌月曜日、予想請求額は約100万ドルから 50万ドルに下がった
- チームはこれを大きなコスト削減成果として演出したが、彼の視点では、すでに浪費されていたお金を止めたに近かった
- 他チームは、新しく加わったエンジニアがこの削減と同じタイミングで来たことを問題視し、なぜ既存メンバーはこうした削減に気づかなかったのかと問いただした
- 管理者は喜びながらも、すべてのコンピュートに変更をすぐ適用すると部門が過度に注目され、望まない質問が生じる可能性があると考えた
- 変更が時間のかかった作業に見えるよう、ゆっくり適用しようという含みがあった
- 彼は PowerPoint を作成しなければならず、文言は「利用パターンに関する慎重な統計分析により、より効果的なリソース配分の機会が示された」といった形にまとめられた
- 実際の変更は、高価なコンピュートが一日中アイドル状態のまま残らないようにする設定調整だった
成果の後に残った負担
- 彼は、優秀なエンジニアを数人見つけて非公式に動いた結果、部門全体よりも簡単に大きな成果を出せたと考えた
- 有能な人たちは組織内にいるが、組織構造のせいで力を発揮できないと判断した
- 50万ドルを節約した後、3万ドルの昇給を求めたがメッセージは既読になったまま返答がなく、何も受け取れないか、せいぜい5千ドル程度だろうと予想した
- コスト削減について話すための会議がさらに増え、PowerPoint 作成の負担も生じた
- 彼は、何もしないほうが自分にとってはよかっただろうと述べ、5分間の行動でキャリア最大の成果を出したものの、すぐに追加の負担を背負うことになったと締めくくった
1件のコメント
Hacker News のコメント
この記事全体にとても共感します。
米海軍で、コスト削減として経歴に残った実績は5,000万ドル以上でした。何かをするたびに PowerPoint を作って将官たちに発表しなければならず、一度は上司に手柄を持っていかせなかったという理由で、ひどく処罰されそうになったこともあります。実際にはその上司は私が何をしたのかまったく知らず、手柄を取るつもりすらなかったのにです。
その一部は Lean Six-Sigma Black Belt として全社プロジェクトに取り組んでいた時期のものでしたが、その表現全体が嫌いになるほどです。文字どおり、DOD のコストをできる限り削ることが仕事で、キャリアの中で最悪の時期でした。数百万ドルを節約する問題解決を勝手にやり遂げたことへの報酬が、その仕事だったのです。
記事の最後の部分に同意します。職場で良いことをするのは慎重になるべきです。報酬はほとんどの場合お金ではなく、同じ給与でより多くの仕事として返ってきます。
以前はずっと良い場所にいて、私が自発的に動いて数百万ドルを節約すると、実際に祝福され、上司も手柄を認めてくれました。
有害な文化のある職場には絶対に留まるべきではありません。給料が良くても同じです。無能でみみっちい出世主義者や支配欲の強い人に押さえつけられることほど、魂をすり減らすものはありません。
要点は「米国政府の良いところは、あまりにも巨大なので、最適解が 30% 削減だとして、次善策で 29% しか削減できなくても、それでも数千万〜数億ドルを節約できるため、誰も気づかない」というものでした。
大きなプロジェクトの一つが、遠隔地の軍事キャンプのエネルギー効率でした。アフガニスタンの一部地域まで燃料を届けると 1 ガロンあたり約 100 ドルで、移動式発電機が容量の 20〜40% 程度で大量に動いていました。記憶では 70% くらいが最も効率的なのですが、小さな建物を作ったり、複数のテントを 1 台の発電機につないだりすることで、燃料使用量を大きく減らし、サービス品質も改善できました。
FAANG のエンジニアとしてお金の流れに直接関わる仕事をしたことがあり、役に立ちそうなさまざまな分野の経験もあります。
ただ、適切な人と取り組む領域を見つけることが、おそらく**仕事の 95%**になりそうだと思って、諦めてしまいます。
それなのに、そのコースを受けると昇進では素早く後押しされる仕組みでした。
安定したサラリーマンの仕事は欲しいのですが、自分がうまくやると、管理職はそれを余裕時間だと見なし、限界までさらに仕事を押しつけてくると分かっています。強欲な人たちは売上配分や利益分配には絶対に同意せず、ただ年 5% の昇給をやるから黙って働け、という態度です。
数社前の職場では、会社から私が積極的に保守しているプロジェクト名を書き出してほしいと言われ、標準フォントサイズの Excel でそのリストが画面丸々2枚分を埋めました。ひどい鬱になるほど燃え尽きました。
さらに悪いのは、転職活動という服従儀式のような茶番も嫌いだという点です。
Dan Luu の記事を思い出します: https://danluu.com/nothing-works/
チップ向けソフトウェアツールも似たようなものでした。大手 EDA ベンダーにツールを外注するのが標準でしたが、私たちが作ったカスタムツールは大きな効果を上げ、たいていは 1 人が作るか保守していました。
私がいた間、シミュレータのサイクルの大半は 1 人が保守していたカスタムシミュレータで回っており、そのおかげでシミュレータ費用を毎年数百万ドル削減できました。当時の標準価格はシミュレータライセンス 1 つにつき年数千ドルで、シミュレーション用のマシンファームは約 1,000 台ありました。
1 人が会社に毎年数百万ドルの価値があるツールを作ったり保守したりできるなら、競合他社も当然やりそうなものですが、実際にはほとんどそうしていませんでした。ウェハを開けて調べられる人を雇えば、より速く安く出荷できるのに、競合がそうしなかったのと同じです。
Dan Luu は「カクテルパーティー版の効率的市場仮説」について話していますが、「何も機能しない」の経済学版は https://en.wikipedia.org/wiki/The_Market_for_Lemons に近いです。市場における情報と情報の非対称性の役割を扱う話です。
効率的市場仮説は、完全な知識が不可能であり、逆選択が実際に存在するため失敗します。
元記事が描写しているものと正反対の会社もあります。そういう会社で一度働くと、悪い場所に再び甘んじることは不可能になります。
記事全体が金言
管理職たちは、自分たちの助けなしにどうやってそれほど大きく削減できたのかを尋ね、スライドの準備を求め、何が起きたのかを何度も聞いてきたし、小さなトグル1つで起きたことではなく、時間をかけて段階的に進めたように見えるよう、ゆっくり展開しなければならなかった。影響の大きさに見合う昇給を求めたが、実現しなかった。
本人のためにも、FAANGのようなところに応募したほうがよさそう。少なくとも、もっとまともに扱ってくれる可能性は高い。
それと、ブログに Twitterカードのメタデータ を入れると、Twitterでより見栄えよく表示されると思う。
「こんにちは。50万ドルの削減がどのように可能だったのかをご説明します。基本的には1日かけて、もともとのインフラがどれほどひどい形でデプロイされていたかを調べ、問題を引き起こしていたコードテスト機能を削除しました。開発、管理、テスト、あらゆる面で完全な見落としでした。全体として、このコードは可能な限り最悪に近い状態なのに、そのままリリースされていました。そして、全員の印象が悪くなるのでこういう話はしないように言われ、管理職が何か仕事をしたように見えるよう、段階的に展開しろと言われました」
そう言ってマイクを置き、ステージを去ったと思う。
正直、気にかける気持ちがものすごくなくなっていたと思う。ほぼ20年この仕事をしてきて、請求書を払い子どもたちに食べさせるために仕事を気にかけている立場の人間でもそう思う。
コストモデルのスプレッドシートを作って文書化し、上司に渡したら「検討してみる」と言われた。2週間後、見たかと聞くと「正しそうだね。よくやった」と言われた。試験適用するのかと聞いたら、その答えが傑作だった。
「いや、われわれはお金を節約するために給料をもらっているんじゃない。お金を使うために給料をもらっているんだ」
そのとき、政府の Cost+Award Fee 契約を本当に理解した。
欠点はおそらく、変更する前にその文書を書かなければならず、チーム全体のレビューを受けて「足並み」をそろえる必要があること。
偶然50万ドルを節約したのではなく、意図的に50万ドルを節約して、今それを後悔している。これは同じことではない。
大規模組織 はあまりにも非効率なので、どうやって競争できているのか驚くほどだが、資金が豊富で、規模の経済があり、そういったものがある。その過程で、ばかげた無駄や非効率に何百万ドルを燃やしても、誰もあまり気にしない。
それでもなお、価値あるサービスや製品を提供している。どれほど非効率でも、そもそも存在しないよりは効率的だ。だから競争がなくても、そうした組織は存在することになる。
小さな組織との競争はどうなのか、と聞くかもしれない。小さな組織は規模の効率では劣るが、他の面で効率的なら、ときには大企業と効果的に競争できる。しかし成長して大規模組織になると、結局は大規模組織の非効率を抱えることになる。
ただ、そういうものなのだ。誰も気にしていないのではなく、むしろ会社の所有者たちはものすごく気にしている。問題は文字どおり、誰も解決方法を知らないことにある。
大企業は、権威主義的な国家統制企業と似た失敗パターンに行き着きがちだ。中国がこの点で、統制と成長の綱渡りをどれほど上手にやってきたかも興味深い。
市場を締め上げながら、同時により非効率になっていく。
競争とは、MBAたちに新規事業を始めさせ、見かけ上は競争があるように見せるために語られるおとぎ話だ。そもそも彼らにチャンスなどなかった。
すべての無駄を最適化で取り除けるなら、コンピュータとビジネスプロセスが効率化され続ける間に、むしろ デフレ が起きていたのではないかと思う。
以前、バグを1つ見つけて年間 400万ドルの売上を回復したことがある
そのミスをそこまで長く放置したチームと役員たちを守るために、なかったことにされた。昇給はなかったが、何人か味方ができ、しばらくは気楽に過ごせた
2台のサーバーは何らかのフィードデータに関係していて、聞いていた機能説明とは違い、ケーブルの接続がおかしいことに気づいた
このシステムのダウンタイムの想定コストは、1分あたり約 700万ドルだった。担当者数名とネットワークチームに問題を指摘したが、「自分たちがそんなふうに接続したはずがない」という理由と、私が新人だという理由で完全に無視された
重要そうだったので週次のグループ会議で改めて問題を提起したところ、誰かが直接確認に行き、私の言ったとおりだったと戻ってきた。大事になり、ネットワークチームは問題をきれいに解決するために約2週間、緊急対応に追われた
みんな私に腹を立てた。会社の大惨事を防いだにもかかわらず、その件でみんなの面目をつぶしたし、特に私のチーム内での立場が低かったからだ。重要な教訓だった
バグ修正のために作ったシステムは、実質的には薬局の処方送信に対する 中間者攻撃だった。薬局が価格更新をまったく適用しなかったため、処方が保険会社のシステムに送られる直前に価格を付け直していた。小さな独立系薬局チェーンで働いていて、中央調剤システムはなかった
当時の無限の天才性により、そのシステムには片思いしていた相手の名前を付けた。本社がそれをとても気に入り、私のシステム名を冠した年次賞を作った。その結果、片思いしていた相手の名前を冠した賞になったが、本当の由来を言うにはあまりにも恥ずかしかった
25年前のことなのに、今でも毎年、昔の片思い相手の名前が刻まれたトロフィーが作られ授与されている。その人が知ったら卒倒しそうだ
こういうことは昔からずっとあった
昔、VT100端末が並ぶ部屋に入ると、学期末の週末で、退屈したCS学生たちがコンパイルの完了を待っていた。システムを見ると、すべてのコンパイルをバッチキューに入れていて、そのキューのデフォルト優先度が対話型ジョブより低かった。つまり、どこからでもキー入力1つがより高い優先度を持つため、人々が自分のコンパイルジョブの位置を確認すればするほど、さらに遅くなっていた
次の15分間、キュー先頭のジョブの優先度を上げ続けたところ、1時間後には全員が作業を終えて帰宅した。部屋は私のものになった。無許可システム管理者の勝利だった ;-)
数か月前、増え続けて月 8万ドルを食っているS3バケットを見つけ、会社に年間100万ドルを節約させた
調べてみると、もう使っていないシステムがそのバケットへファイルをコピーしていた。関係者に連絡し、彼らが停止してファイルを削除した
上層部はあまり気にしていないようだった。私の上司の上司は、本来これを見つけるべきだった別チームに連絡してみるよう言い、それで終わりだった
「たとえば、[table name deleted]_HOURLY に234,745回の INSERT を実行しましたが、すべて1000行未満でした」
私たちの組織のSnowflakeサポートSlackに実際に投稿された言葉で、ほぼ同じ問題だった。時間をかけて散らばった小さなトランザクションが、クラスターを起こし続けている状況だ。この製品は、少量の継続的ロードのような一般的なユースケース向けには作られていない
私は実務経験のあるデータウェアハウス管理者なので、人々がコスト超過を一つずつ経験しながら、私の職務内容を再発見していくのを見ている。彼らは「セルフマネージドだが、コストを監視し、ロードとクエリをより効率的に書き直す必要がある」といったことを真剣に言う。私が一日中何をしていると思っているのか、聞くのが怖い
はるか昔、遠い銀河で、N ×（Oracleライセンス + Sunサーバー）が必要だった仕事を、100行未満のPerlスクリプトとSunサーバー1台で置き換え、年間3億ドル以上を節約した
その過程でMapReduceも発明した。Googleより前だった
問題は、Webサーバーログから複数の統計を計算することだった。たとえば人気ページ上位10件のようなものだ。元の解決策は、ログが巨大なので複数のサーバーで動くOracleデータベースにすべてロードし、その後SQLクエリをいくつも実行し、毎日それを繰り返すというものだった
著者の記事に付いた印象的なHNコメントのギャラリーがすばらしい: https://ludic.mataroa.blog/compliments/
組織内の多くの人たちが、著者よりはるかに先を見ていた可能性も高い。同じグループのエンジニアやマネージャーが、コスト削減のタイミングで使うためにその非効率を温存していて、著者がその機会を台無しにした可能性のほうが高い。そうなると、削るものがなくなったときに、相当な苦痛と悪い人事評価が避けられなくなるかもしれない
おそらくHNの議論の水準が落ち、今ではほとんどすべてのコメントが対象になってしまうほどになったため、休眠状態なのだろう
[1] https://twitter.com/shit_hn_says