そのコード、書いたらいくら？消したらいくら？

【DMM×バイセル】若手エンジニアによる学生向けTech Study Summit（https://dmm-recruit.connpass.com/event/316914/）での登壇資料。

Transcript

1. そのコード、書いたらいくら？消したらいくら？ 2024/05/15 【DMM×バイセル】若手エンジニアによる学生向けTech Study Summit 株式会社BuySell Technologies　金澤滉典
2. 🪧 金澤滉典 カナザワヒロノリ 🎂 1998/07/28 生 の 23 新卒 󰳕 BEエンジニア（最近はインフラ） ❤ ガジェット・AI・ゲーム 2 自己紹介 X: @kanakana134569 GitHub: urban-side アサクリ、ウィッチャー、Cyberpunk2077わかる方、友達に なってください。R6Sでは8年半割職・現地職です。どうして現地に誰も居ないのはなあぜなあぜ？？？？？？？？ 静岡県富士市 出身
3. プロダクトエンジニア*が普段やっていること 現在進行形でリプレースされているプロダクト を運用しつつコストカットできるところはした いというニーズに対して何を考えてタスクを積 んでこなしているのか編　〜具体例を添えて〜 3 !? 今日お話しすること *弊社におけるプロダクトエンジニア: 機能開発全体を通して、事業と伴走しながらものづくりができるエンジニアを指す。
4. 実装が与えるコストを考えること ができるエンジニアは強みになるよ という話 4 　ぜひ「当たり前だ！」と言えるようになって 帰っていただければ幸いです 今日持って帰ってほしいこと
5. 5 今日のもくじ 1. 前提 ─────────── 6 2. 置かれてる現状 ─────────── 10 3. 事例紹介 ─────────── 16 4. まとめ ─────────── 23
6. 6 集客〜契約、在庫管理まで自社で行っています 集客 査定 予約 査定/買取 営業準備金管理 決済確認 売買契約 在庫管理・販売 予約 最適化 追客 問い合わせ対応 法人/宅配買取 Marketing インサイドセールス フィールドセールス セールスコンプライアンス
7. 7 集客 査定 予約 査定/買取 営業準備金管理 決済確認 売買契約 在庫管理・販売 （別システム） 予約 最適化 追客 問い合わせ対応 法人/宅配買取 Marketing インサイドセールス フィールドセールス セールスコンプライアンス 予約受付〜契約、商材連携までを担当するGYRO
8. 8 GYROはCosmos*へのリプレースが進んでいます 　基幹システムなだけあって、担当する領域が広い これを機能ごとバラして移管している *Cosmos: 弊社が開発中のプロダクト群「コスモス」。予約管理から在庫管理〜販売まで一気通貫で管理可能なリユースプラットフォーム。
9. 9 　基幹システムなだけあって、担当する領域が広い これを機能ごとバラして移管している *Cosmos: 弊社が開発中のプロダクト群「コスモス」。予約管理から在庫管理〜販売まで一気通貫で管理可能なリユースプラットフォーム。 GYROはCosmos*へのリプレースが進んでいます よくある話
10. 10 よくある話だけど...GYROが立ち向かうべき課題 [前提]基盤システムなので完全なリプレースはまだまだ先 • アーキテクチャがとにかく複雑ゆえに高コスト ◦ k8s、Cosmos連携による認可周り、マイクロサービス... ◦ 大変だった例: https://tech.buysell-technologies.com/entry/adventcalendar2023-12-09 • 向こう数年は使いそうなのにEOL対応が進んでない • 移管した機能を畳み、少しでもコスト削減とバージョンアップを 楽にしたい 　さて、どれからやればいいのでしょうか？
11. 少ない手数でコストを いくら減らせるか・増やせるか 11 何をやるべきかという指針
12. 少ない手数でコストを いくら減らせるか・増やせるか 12 何をやるべきかという指針 👍 ログ出力を1行消して 5万円/月 削減 🤔 1人月使って実装したロジックで 10万円/月 売上増 「下が一概に悪いという訳ではないが、一考の余地はありそう」 という肌感を持てれば、議論という次のステップに入るでしょう
13. 13 計測しましょう サーバー費削減を例に 推測するな
14. 14 青いサービスは減らせないか？2つのオレンジは何に使っているのか？ 自分の実装が与えるインパクトの規模感が掴めるでしょうか 図はあくまでイメージです 内訳をみて議論するのが第一歩
15. やるべきことが見えてきたら その数字で開発チーム、そして事業部に 提案・交渉しましょう 15 エンジニア組織だけで完結する話は思ったより少ない 事業部と伴走していることを忘れちゃいけない 実行前の最後のステップ
16. 16 チームでの事例を 3 つほどご紹介します ということで ＼ さらっと / どういう根拠で実施したのか、何に気を付けたのか を感じていただければと思います
17. 17 ① 機能移管時にオミットした部分を消す 削除可能である根拠・背景 CosmosCRM移管時に廃止された機能はGYROからも削除できる（保守コスト削減）。 現場からの『アプリ上の小さなGoogle Mapを使うことはない。』というヒアリング結 果（業務フロー的にもMap機能を削除できるという根拠）。 あるべき姿を考える [前提]GYROはCRMのエラー時に利用する可能性がある >> プランBだとしても使いやすいものであるべき 顧客応対時に別タブでMapページを開いているので、住所のコピーボタンを配置するこ とで業務フローとの連結が最低限の工数で楽になるようにしておく。 ただ削除するだけでなく、自身のプロダクトの立場を踏まえた改修 （あるべき姿）を見極めたい
18. 18 ② APIリクエストごとに走るログは不要かも？ *開発改善Day: GYROチームでは月末のスプリントで「開発環境・技術負債を改善するタスク」を意図的に消化することにしている。 意図的にこういうタスクを進める開発改善Day、結構好きなんですよね 削除可能である根拠・背景 サーバー費の内訳からCloud Loggingの割合が大きいことがわかった（計測結果による判断）。 認証基盤の変更時に仕込んだAPIリクエストごと出るログは、エラー調査時にも利用しておらず、む しろ邪魔になっていた（作業効率への寄与）。 たった1行削除するだけなので開発改善Day*でやってみる（コスパの良さ）。 必ずやるべきこと 実装後に効果を必ず計測すること。類似実装時の参考になるとともに、作業効率がXXXくらい増え るけどYYY円かける価値はなさそう、という判断ができるようになる（逆も然りです！！）。
19. 19 *k8s: Kubernetes。（誤解を恐れず言うと）コンテナのデプロイやスケーリングをいい感じに行うオーケストレーションシステムの一種。 せっかくなので、具体的な対応内容を見ていきましょう 👉 ③ k8s*のNode数をどうにか減らした話 削除可能である根拠・背景 GYROのサーバー費は全社でも高く、改善すれば全体のインフラ費用削減に大きく寄与できる。 GYROの費用内訳ではCompute Engineが5割を占めるため、改善による影響が大きいこちらから手 を付ける（計測結果による判断）。 留意点 全社の基盤システムであり、アプリケーションのパフォーマンスが業務効率、ひいては利益に繋 がっている。少なくとも改修前の挙動や使用感、パフォーマンスを維持したままリソースを最適化 する必要がある（インフラ費を削減して減収減益したら本末転倒）。
20. 20 Kubernetes Compute Engine Container Pod Kubernetes リクエストが捌ききれなくなったので、 設定に基づきPod数とNode数を自動で スケーリングします（GCEリソースドカ食い） リクエスト数　少 リクエスト数　多 コスト高の理由｜リクエスト数増大によってNode数が増えすぎた* GCEリソースを
 　　パクパクですわ〜
 Compute Engine Compute Engine Compute Engine Compute Engine スケーリング命令 *GKEはNodeのスケーリング時にGCEインスタンスを起動するため、設定によっては各Nodeに余裕があるのに数だけ増えてしまう。 Container Pod Compute Engine Container Pod Container Pod Container Pod Compute Engine Container Pod Container Pod
21. 21 Kubernetes Compute Engine Container Pod Kubernetes リクエストが捌ききれなくなったので、 設定v2に基づきPod数とNode数を自動で スケーリングします（リソース適切） スケーリング命令v2 Compute Engine Container Pod GCE分のサーバー費が半分に = 全体の 25 %が削減 リクエスト数　少 リクエスト数　多 対応内容｜設定を書き換えてスケール挙動をチューニング* Compute Engine Container Pod 各Nodeのリソースを使うように
 　　　　スケールしてくださいまし
 *スケール条件としてCPU・メモリの使用率やpodの最低起動数を適切に設定することで、NodeではなくPodが増えることによる処理不可対 応が実現する。このあたりのパラメータチューニングを日夜行っているk8sエンジニアの方には頭が上がりません。
22. 22 [技術的補足]設定v2で実際に行った内容について PodDisruptionBudget: PDBの設定を minAvailable: 2 → maxUnavailable: 10% に変更した。 結 論 起きていたこと スケーリングの設定はHorizontalPodAutoscaler: HPAでしていたが、その設定よりも少ない負荷であってもPodが 余剰に生成され、それに伴ってNodeのインスタンス数も増加した。 >> HPAには、PodのCPUおよびメモリ使用率が閾値を超えたら新たなPodを生成するように設定していた 原 因 DeNA 的 GKE 運用 ~ Pod 集約率編 ~ | スケールイン後の Pod 集約率改善 によると、PDBの設定が厳しすぎる場合 (今回の場合は minAvailable: 2 が相当)、HPAに記述したスケーリング設定が適用されないことがあるらしい。 *minAvailable: 起動しておかなければならないPodの最低数 **maxUnavailable: 利用不可能なことが許容されるPodの数（Deploymentに記載されているreplicasに対する割合）
23. 23 まとめ 自分の考えるプロダクトエンジニアのやることは 2 つ • ユーザーと会話してより良いものを「作る」こと • 事業（≒経営）に与えるインパクトを考えながら「消す」こと 今日話したのはこっち 使いやすいものを作ることだけがビジネスサイドに寄り添う視点ではなく、自分の実装が与えるさ まざまなコストについて考えることも同じくらい必要になる。 東奔西走して事業部側と交渉しつつ、効果が高い部分からデグレに気をつけて消していく。 そのための観点・手札が多ければ多いほど、優秀なエンジニアなんだと思います。 コスト勘定がパッとできる人は強いなあと感じる今日この頃でした
24. 実装が与えるコストを考えること ができるエンジニアは強みになるよ という話 24 [再掲]今日持って帰ってほしいこと
25. 実装が与えるコストを考えること ができるエンジニアは強みになるよ という話 25 あらためて、「当たり前だ！」と言えるようになって 帰っていただければ幸いです [再掲]今日持って帰ってほしいこと
26. THANK YOU 26