Backendはつらいよ - 複雑性をコントロールする技術/Backend_is_Hard_-_Techniques_for_Controlling_Complexity.pdf

以下のイベントでの登壇資料です

Backendを語る会 in 福岡 #1
https://backend-fk.connpass.com/event/391337

Transcript

1. BACKEND はつらいよ 〜 複雑性をコントロールする技術 〜 LINEヤフー株式会社 平井 ⼀史
2. 平井 ⼀史 (Hirai Kazushi) LINEヤフー株式会社 コンテンツ＆メンバーシップドメイン所属 LINE STORE、LINEスタンプ関連を担当 興味：家族、マラソン、体を動かすこと バックエンドの複雑性と⽇々向き合っています 自己紹介
3. ⼤規模プラットフォームの運⽤ LINEのエコシステムを⽀える主要なバックエンドシステムを担当 LINE STORE スタンプ‧着せかえ等、LINEの デジタルアイテムを販売する公式 オンラインストア。 収益基盤となるプラットフォー ム。 担当プロダクトとシステム規模 システム規模 数千万規模の⼤量データを扱う、 極めてスケーラブルなアーキテク チャ。 トラフィック 秒間数万リクエストの⾼負荷環境 下で、低遅延かつ⾼可⽤性を 維持。
4.  Application Java / Kotlin Spring Boot Armeria  Data / Cache MySQL / MongoDB Elasticsearch Redis / Kafka  Infrastructure Verda (Private Cloud) Kubernetes / VM Microservices 技術スタック
5.  実装のコモディティ化 CRUD処理程度であれば、AIが⼀瞬でコードを⽣ 成する時代。表⾯的な「実装」のハードルはかつ てなく下がっている。  バックエンドの本質 しかし、「つらさ」の本質はそこにない。真の仕 事は、AIには代替できない「複雑性の制御」にあ る。 AIがコードを書く時代の開発
6. バックエンドの「つらさ」の正体 スケール 膨⼤なトラフィックと増⼤するデータへの対応 運⽤ リリース後から始まる「終わりのない戦い」 時間 データ量増加、技術の陳腐化（EOL） 組織 プロダクト開発 vs 技術的負債 「これら4つの複雑性をコントロールすることこそが、 バックエンドエンジニアの真の職務である。」
7. スケールのつらさ：大量データの罠 Q. 1000万件のバッチ処理 1件の処理に10秒かかる場合、完了までにどのくらいが必要か？ 1,000万件 × 10秒 ＝ 約3年 24時間回し続けても終わらない... 並列度10でも約116⽇、1000は約28時間だが... 並列化だけでは解決しない 並列度を上げれば解決するように⾒えるが：  CPUリソースの限界  外部DB/APIへの負荷増⼤  サーバー増設によるコストの壁
8. 「1件を速くする」のが正攻法 ボトルネックの徹底追求 10s → 1s → 0.1s → 0.01sへと叩く。 クエリ最適化 インデックス追加、N+1問題の解消。 通信コスト削減 外部APIをローカル処理やキャッシュに寄せる。 基礎体⼒の向上 1件の速さがスケール戦略の「限界値」を決定する。 「1件の速さ」の積み重ねこそが、 巨⼤なスケールを⽀える唯⼀の道。
9. 運用のつらさ： リリースの先にある本番 終わりのない運⽤戦 開発期間はライフサイクル全体のごくわずか。真の戦いはリ リースから始まる。⽪⾁にも障害の多くは「開発者の操作」か ら⽣まれる。 操作ミス、設定不備による障害 他プロダクトの予期せぬ仕様変更 リリース作業そのものが持つリスク 防御策 問題の早期発⾒：アラートの整備が不可⽋   
10.  緊急性のレベル分け ERROR: 即対応が必要なもの。オンコールエンジニアが⼀次 対応すべきもの。 WARN: 様⼦⾒。翌営業⽇に確認すべき、潜在的な問題の 兆候。 INFO: ログ保存のみ  RUNBOOKの整備 アラートに対する⼿順書。背景と対処⼿順を明確にして、開 発者のパニックを防ぎ、誰でも対応可能にする。 アラート通知にRUNBOOKへのリンクを設置すると初動対応 が迅速化。 アラートを形骸化させない 過剰なアラートは「オオカミ少年」状態を招き、重要な通知の軽視や無視に繋がる。
11. 今⽇は動いても、未来は壊れる 時間はバックエンドにとって最も残酷な変数。 データの増⼤: ⾼速だったクエリが低速化。 技術の⾵化: フレームワークやミドルウェア、OSのEOL。 バージョンアップ: 破壊的変更に伴う⼤規模改修。 時間のつらさ：技術的負債   
12. 運⽤負荷の「構造的な」増⼤ マイクロサービス化による分割でスケーラビリティは向上し たが、代償として運⽤負荷が増加 管理すべきサーバやDB数の増加 EOL対応やパッチ適⽤の⼯数が増加。 ⽌められないサービスや個⼈情報を含むDBバージョンアッ プは常に⾼リスク。 マイクロサービスの代償   
13.    ⼿順の⼀般化 ⾃動化の推進 運用負荷を手順・自動化・技術で抑え込む 職⼈芸を排し、⼿順書を整備。誰 でも対応可能な組織状態を構築。 ⼈による操作をなくして、ミスのリス クと作業⼯数を最⼩限に。再現性の ⾼い安全なプロセスの確⽴。 新技術によるリスク回避 新技術により、作業のリスクを回避また は最⼩化。DBバージョンアップなどを サービス無停⽌‧即時ロールバック可能 に。 e.g. Kafka Connect
14. 「外部要因」という見えない壁 チームの意志とは無関係に、 サービス維持のために必須となる作業が発⽣ データ制約‧法規制 各国の法律や会社ルールの変更へ の対応。 セキュリティ要件 緊急度の⾼い最新の脆弱性 （CVE）への対応。
15. 未来は、誰にも予測できない。 「予測」して備えることには限界がある。情勢やビジネス⽅針は突然変わる。 前提は常に崩れ去る。 防御策：いかに後で変えられるかを重視する  疎結合 コンポーネントを独⽴させ、変化へ の柔軟性を確保する。 e.g. イベント駆動アーキテクチャ  分割 影響範囲を極⼩化し、予期せぬ副作 ⽤を封じ込める。 e.g. マイクロサービス  抽象化 実装の詳細に依存させず、インター フェースで変化を吸収する。 e.g. クリーンアーキテクチャ
16. 組織のつらさ：負債か、プロダクトか 相反する優先順位 「新機能を作りたい」ビジネス側と、「負債を返した い」開発側の対⽴。 「技術的負債の放置は、将来の成⻑を完全に⽌め る。これを組織として合意できるか。」 解決策：改善を専任とするチームを結成し、 組織として「負債返済」を仕組み化する。 ⼈的リソース確保が必要なため、組織への交渉と理解獲得が必要。
17. Backendはつらいよ だからこそ、エンジニアとしての価値がある。 ご清聴ありがとうございました。