走り続けるための技術(仮)

Presentation slides for: 某クローズドイベントにおける発表
Session Title: 走り続けるための技術(仮) 〜 技術も人も変化する中でシステムを健全に維持していくためのヒント
Date: 2024/12/20

Transcript

1. All rights reserved by Postman Inc 走り続けるための技術 (仮) 技術も人も変化する中でシステムを健全に 維持していくためのヒント 川崎庸市 Postman株式会社
2. テクノロジー・エバンジェリスト Postman株式会社 川崎 庸市 / Yoichi Kawasaki @yokawasa @postman_japan
3. All rights reserved by Postman Inc Postman とは？ 全世界3,500 万人以上のユーザーに使われている APIを構 築して利用するための API プラットフォームです。 API ライフサイクルの各ステップを簡単に行えるようになり、 API の共有と開発コラボレーションを効率化できます。
4. THE GLOBAL, DEVELOPER-CHOSEN STANDARD FOR API WORK 6.4M 42% 0.8M 19% 2.3M 21% 7.5M 31% 13.8M 29% 0.5M 35% 14 40% Postmanを活用してAPI開発・テスト活動に取り組む開発者 The prize for fastest growing developer app goes to Postman…as the clear growth leader, displaying YoY growth of 78% by customers and 168% by unique users.ˮ Businesses at Work 2023 Developers’ Best of Show Fortune 500企業 98% 開発者 35M
5. Postman API Platform Landscape @postman_japan
6. Postmanイベント Postman API Night(勉強会)＆ワークショップ https://postman.connpass.com/ Please Follow us - Postman イベント情報 Postman Japan X https://twitter.com/postman_japan
7. Postman Japan コミュニティ Discord Discord サーバーを開設しました！ 今後 Postman のプロダクトアップデートやイベン ト情報の配信や、みなさんとの交流の場として活 用していきたいと思います。 https://discord.gg/G4SQWDDqVa @postman_japan
9. NoOps = No Uncomfortable Ops システム運用の “嬉しくないˮ をなくそう
10. デブサミ2018にて https://codezine.jp/article/detail/10716
11. https://noopsjapan.github.io NoOps Japan Community
12. What is NoOps? Why does it matter? 5年前のスライドを元におこしてます
13. システムは「価値」と「負担」でできている 価値 負担 利用者 提供者
14. 理想 価値 負担 利用者 提供者 価値は大きく 負担は軽い
15. 現実 価値 負担 利用者 提供者 価値はそこそこ、 重い負担
16. 現実 価値 負担 利用者 提供者 Ops • 監視 • 障害対応 • 監査 • リリース • 報告 • パッチ適用 • データ抽出 • 夜間呼び出し • 保守切れ対応 • etc… • これらに伴う費用 負担だらけで 身も心も、 競争力も 消耗…
17. 現実 価値 負担 利用者 提供者 Ops • 監視 • 障害対応 • 監査 • リリース • 報告 • パッチ適用 • データ抽出 • 夜間呼び出し • 保守切れ対応 • etc… • これらに伴う費用 負担だらけで 身も心も、 競争力も 消耗… NoOps = No “Uncomfortableˮ Ops 運用のˮ嬉しくないˮを、なくそう
18. 攻めの NoOps 守りの NoOps
19. Defensive NoOps 価値 負担 利用者 提供者 負担 自動化、効率化を進めて、 Ops環境を改善する 守りの NoOps • 監視・通知の自動化 • リトライの自動化 • 構成変更の自動化 • 方式の標準化 • 状態の可視化 SRE活動など
20. Offensive NoOps 価値 利用者 提供者 負担 構造的にOps不要な システムとして設計する 価値 負担 攻めの NoOps Microservices Container Serverless
21. Resiliency 価値 利用者 提供者 負担 「高い回復性」によって、 価値向上と負担軽減を獲得可能 価値 負担 • 停止時間ゼロ • バーストも無問題 • 安定したスループット • システム予算低減 • 自己回復 • 弾力的なリソース割当 • 動的構成変更 • トイル削減
22. 攻めの NoOps 守りの NoOps
23. Design for NoOps Less Ops NoOps に向けた設計思想の転換 NoOps ≠ No Ops 人間による運用はゼロにはならない
24. Resiliency 高い回復性 Observability 可観測性 Configurability Automation Ops Safety Safety 安全性の担保 Monitor/Detect Resilience Less Toil トイル削減 Predictability 構成可能性 予測可能性 NoOps活動の分類
25. Resiliency ③高い回復性 Observability ① 監視・検知 Configurability ② 自動構成 Automation Event /Monitor Running 正常稼働 Detect Resilience NoOps Failure Failureから30秒以内に回復 障害〜回復までのライフサイクルで考える
26. https://github.com/noopsjapan/community/blob/master/DEFINITIO N.md

27. 時は流れ、やがて気づく 初期のNoOps定義に 欠けているもの、見落としていたもの
28. 長期的な成長させ、健全に維持していくのに、技術だけでは補いきれな い部分： • 事業・ビジネスを交えた立体的な観点 • コスト最適化（価値に対する消費リソースの最適化） • 組織・人の練度（練度に応じた適切な選択） • 知恵の継承
29. いよいよ本題 走り続けるための技術 技術も人も変化する中でシステムを健全に 維持していくためのヒント をご紹介します
30. 価値あるドキュメントを残す 組織やプロジェクトの効率と品質を持続的に向上させるために必要なもの
31. 価値あるドキュメントとは？ @postman_japan 価値が高い ドキュメント 目的が明確でわかりやすい ユーザー・読者目線 可読性が高い アクセスしやすい 持続的に改善され続ける 使いやすい構造 （機械が読める）
32. なぜドキュメントを残すのか？ @postman_japan ドキュメント 知識の共有・伝達、学び 意思決定の記録 オンボーディング 一貫性の維持 コンプライアンス 品質の維持
33. 2023 State of the API Report https://www.postman.com/state-of-api/executing-on-apis/#obstacles-to-consuming-apis #1 ドキュメント不足 52% #2 APIの発見が困難 32% #3 時間がない28% #4 知識不足26% #5 予算不足23% #6 人員不足22% #7 APIの再利用が困難 19% Web API利用における障壁
34. 例: Web APIの開発・テストにおけるドキュメント • 開発者やテスターなど API 開発関係者にとって「仕様書」であり、「テスト設計」の起点となる • 良質なドキュメントがあれば API仕様とテストコードのズレを回避しやすくなる • 仕様の認識の齟齬を防ぎ、効率的なコラボレーションが可能になる
35. 例: アーキテクチャ選定、技術選定の記録 あるプロダクトの刷新プロジェクトにおいて遭遇したプロジェクト継続性に関わる闇深い問題 • 過去のアーキテクチャに関する包括的な結論が記載された資料はあるものの、そこに至るまでの設計意 図やトレードオフについて整理されたものが存在しない • 過去に行われた関連 MTGの議事録やSlackの関連会話の中に内容が断片的に残ってはいるものの、埋 もれてしまっている • プロジェクト初期から参画している人でさえもその意図を忘れてしまっている（時間の経過による記憶の風 化）。思い出そうにも残っている記録が断片的すぎて判断がつかない。 ⇒ 後から参画した担当者は、過去の経緯・意図が分からず意思決定の判断が難しい状態。さらに初期参画者で すらその意図を忘れてしまっている。プロダクトに関する意思決定の記憶が失われてしまっている
36. アーキテクチャ選定、技術選定 いかなる決定においてもその背景に関連する議論、トレードオフ、計画などがあるはず。アーキテクチャや技術 の選定においては、その選定理由や結論に至るまでに行ったトレードオフがとても重要 • フレームワーク • API仕様設計ツール • 認証・認可の仕組み • モノリス、マイクロサービスアーキテクチャ • イベント駆動型アーキテクチャ • データベース構成、トランザクション分離レベル • Cache構成 • シングル、マルチリージョン • 可用性構成、回復性機能 • セキュリティ対策 • etc
37. そこで導入したのが ADR（Architecture Decision Record） ADRはいつ書くもの？ リリース前後関係なくアーキテクチャ上重要な決定があればす べて記録として残すことが推奨されている Spotifyの記事「When Should I Write an Architecture Decision Record」での説明： • 「開発するソフトウェアに影響を与えうる重要な決断を下 すとき」に該当するときにADRを書く • 大きな変更、小さな変更に関わらずADRを残すべき。な お、上記の通り変更がなくても重要な決断であれば残す べき • 既に下された決定についてその記録がない場合にも後 からでも書く（backfill）べき • ドキュメント（記録）が残されていないことの代償のほう が大きい Wantedly Engineering Handbook - アーキテクチャディシジョンレコード ADR https://docs.wantedly.dev/fields/dev-process/adr 重要なアーキテクチャ上の決定事項を、その背景や結果とともに記録するための手法
38. 必要のないものは作らない 同じような内容をこちらでも発表しています 「作りすぎない技術」 https://speakerdeck.com/yokawasa/thinking-about-the-state-of-development-efforts-in-the-api-era
39. ここでの「必要のないもの」とは • 本質的な課題を解決しないもの • 利用者のユースケースを実現しないもの • 冗長なもの • 代替可能なもの • 過剰なもの（将来的に不要になる） • 維持管理が難しいもの（将来的に不要になる） @postman_japan イシューからはじめよ ――知的生産の「シンプルな本質」 https://amzn.to/3XK87VU
40. YAGNI - 必要になるまで作らない YAGNI You ain't gonna need it) 実際に必要となるまでは追加しない方がよいとするExtreme Programming XPにお ける原則 Yagni https://martinfowler.com/bliki/Yagni.html 推定・仮説に基づいて作る機能の3つの分類とそれぞれ YAGNIを無視した場合に発生する4種類のコスト • 構築コスト • 修理コスト • 維持コスト • 遅延コスト • 正しくない機能 • 間違って作られた正しい機能 • 正しく作られた正しい機能 @postman_japan
41. 標準化されている / 相互運用性のあるものを選ぶ • 標準化 / 相互運用性のあるもの ◦ インターフェース、フォーマット、プロトコル ◦ 世界標準、組織標準 • 標準化 / 相互運用性のある世界はスケールする ◦ 学習コスト、コラボレーションコスト低減 ◦ 柔軟性、拡張性の向上 ◦ エコシステムの有効活用 / 巨人の肩の上に立つ • 独自技術・仕様のデメリット ◦ (将来的に) コスト高、属人化、技術的負債 @postman_japan
42. その時点でのベストな技術スタックを選ぶ 技術的にイケてる（卓越）かどうかだけでなく、チーム 能力、制約などのバランスも加味する • 技術的な卓越性 ◦ 将来性、成熟度、パフォーマンス、セキュリティ、サポー ト、エコシステム • チームスキル・経験（練度） ◦ チーム練度、学習曲線、外部リソースが調達可能か • 制約事項（コスト・スケジュール） ◦ 保守性、開発・運用・ライセンス費用など ◦ 時間的制約 https://speakerdeck.com/twada/understanding-the-spiral-of -technologies-2023-edition 技術 卓越性 チーム スキル 制約 事項 @postman_japan 技術 選定 …
43. 車輪の再発明をしない @postman_japan
44. 組織的開発における重複を排除する 組織開発における重複や重複がもたらす不要な開発の例 • 機能の重複開発 ◦ リソースの無駄遣い ◦ 統合時に互換性や一貫性の問題の原因になる • ドキュメンテーションの重複 ◦ リソースの無駄遣い ◦ 互換性や一貫性の問題の原因になる • ツールやプロセスの重複 ◦ 全体的な効率低下、一貫性低下 ◦ 組織全体の改善が進みにくくなる @postman_japan
45. 組織内における重複を排除する 重複 / 車輪の再開発を排除するための施策例 • コミュニケーション強化 ◦ チーム間インタラクションを通じた知識・スキル・自立性の向上、重複排除 • ツールとシステムの統合 ◦ 一貫性、効率性向上につながる • 標準化とガイドラインの策定 ◦ 同じ目的のツール、プロセスの標準化 ◦ 一貫性、効率性向上につながる @postman_japan
46. 80点を目指す 「100点の品質」よりも「ほどよい品質 80点)」を「継続的に改善」するアプローチで 同じような内容をこちらでも発表しています 「作りすぎない技術」 https://speakerdeck.com/yokawasa/thinking-about-the-state-of-development-efforts-in-the-api-era
47. 注意: 80点は目安。必ずしも合格点ではない • 製品やサービスの性質 ◦ 医療機器、航空機制御などミッションクリティカル系では最高水準の品質が求められる • ユーザーの期待とニーズ ◦ 特定の市場や顧客セグメントでは、高い品質が要求される • リスクとコスト ◦ バグや不具合が発生した場合のインパクト ◦ リソースやコストの制約 前置き @postman_japan
48. 100点の品質の追求は難しい 複雑で不確実性が多い今日のシステム環境において、100点の品質追求は難しく、また 割に合わないことが多い • 多様な技術の統合・連携 ◦ クラウド、オンプレミス、モバイル、 IoTデバイスなど ◦ 異る技術の統合は複雑性を増大させる（サービス障害、ネットワーク遅延・断絶） • 継続的に更新される環境 ◦ クラウド、クラウドネイティブなプロダクトは頻繁なアップデートが前提 ◦ それに依存するシステムは頻繁なアップデートに追従が必要 • 急速な技術進化 ◦ 新しいツール、フレームワーク、プログラミング言語など前よりもよいものが日々登場 ◦ それに伴いアーキテクチャの正攻法も変化 • ビジネス環境の変動 ◦ 市場の変動、競争の激化、新しい規制や法令の導入など ◦ システムの適用を難しくし、不確実性を増大 @postman_japan
49. ほどよい80点の品質を目指す戦略 100%の品質よりもほどよい80点の品質を高速かつ継続的に改善するアプローチ • 堅牢性よりも機動性と回復性 ◦ 障害の発生は可能な限り早期に検知する ◦ 障害から迅速に回復しダウンタイム時間を抑える (自己回復力や冗長性 ) • 継続的テスト・改善 （Shift Left、Fail Fast） ◦ ライフサイクルの早いフェーズからテスト ◦ フィードバックを迅速に反映して逐次改善する • 目標設定と優先度付け ◦ どの程度の追求すべきか目標設定と優先度付けを行う @postman_japan
50. “Done is better than perfect” – Mark Zuckerberg Design for Failure - Running Containerized Microservices on AWS (amazon.com) https://docs.aws.amazon.com/whitepapers/latest/running-containerized-microservices/design-for-failure.html “Everything fails all the time.ˮ – Werner Vogels Done is better than perfect https://medium.com/@chihweitang/done-is-better-than-perfect-6cc86635ccdd @postman_japan
51. 機動性と回復性を重視する 障害は可能な限り早期に検知し被害を最小限に抑えることを目指す • MTTR (平均復旧時間)：障害発生〜復旧までの平均時間 • 可観測性（オブザーバビリティ） MTTR = Mean Time To Repair MTBF = Mean Time Between Failures どれだけ早く復旧するか どれだけ壊れにくいか UP DOWN 復旧 MTTR MTBF @postman_japan
52. 機動性と回復性を重視する • リリースまでのリードタイムを短くして、高速フィードバックループを回す ◦ コード化（x-as-code）、継続的テスト、CI/CD • ある程度完成したら一部をリリースして様子をみて、ダメなら戻す ◦ Blue/Green、カナリアリリース • 障害の発生は可能な限り早期に検知し回復へのアクションに移す ◦ 監視・観測、セルフヒーリング、オートスケール @postman_japan
53. Fail Fast - 問題の早期発見と対処 実践方法 - APIファースト APIの場合) - テスト駆動開発 TDD - 継続的インテグレーション CI - スクラム ⇒ アジャイル開発の基本理念と一致 Fail Fastの目的 - 問題の早期発見と対処 - リスクの最小化 - フィードバックの迅速化 - 継続的な改善 @postman_japan
54. Shift Left • できるだけAPIライフサイクルの早い段階で実施するようにしましょう。早期にバグや問題を発見し、修正 コストを削減できます • セキュリティ、パフォーマンス面のような非機能要件のテストおいては、 APIライフサイクルの後ろの フェーズで実施される例が多く見られるが、このような非機能要件に関する問題は致命的な事が多い @postman_japan 定義 設計 開発 テスト デプロイ 監視 観測 配布 check check 致命的な 問題発見 デザイン変更 APIライフサイクルにおける後半フェーズで問題が発見されたイメージ
55. フィードバックループと新陳代謝 • 一度作った終わりではなく、ソフトウェアライフサイクルにおける課題をフィードバッ クを元に継続的に改善させる • システムを新陳代謝させていくことが生存の鍵 • そのためには新陳代謝しやすい構造にしておくことが重要 計画 設計 テスト 実装 デプロイ 監視 観測 問題 対処 要件定義 RTO/RPO 障害識別 回復性実装 信頼性のある デプロイ フィードバック 改善 分析 ポストモー テム 回復性テスト 反応＆対処 アラート @postman_japan
56. OODAループ - 意思決定のフレームワーク • John R. Boyd 元米軍大佐が提案した戦場で勝利するためのフレームワーク • OODAObserve-Orient-Decide-Act) を継続的に繰り返し、迅速に意思決定を行う • 不確実性の高い状況においては PDCA Plan-Do-Check-Act)よりも常にシステムの課題や存在意義 を 認識し、方向づけ、意思決定、行動を繰り返す OODAループがフィットしていると言われている ◦ OODAループ: 計画ではなく先に観察。迅速な意思決定が必要な時に適している ◦ PDCA : ゴールや工程がはっきりしている時に適している https://en.wikipedia.org/wiki/OODA_loop John Boydʼs OODA loop 観察 方向づけ 意思決定 行動 参考情報 @postman_japan
57. 目標設定と優先度付け リソースは有限。目標設定と優先度付けしてほどよい品質を目指す • 必要以上の自動化、コード化はやらない ◦ 頻繁に変更される部分 ◦ 繰り返しテストされるが、手動テストが困難または時間がかかる部分 ◦ バグや障害による影響が大きい部分 ◦ 共通機能 • SLO / SLAによる品質目標の定量化 ◦ 追求すべき品質目標の定量化と、リソースの配分や優先順位付けを行う ◦ SLO Service Level Objective): 期待されるパフォーマンスレベルの定義 (例: 99.9%の稼働時間、 応答時間が1秒以下など) ◦ SLA Service Level Agreement): 品質レベルやサービスレベルを文書化した契約 @postman_japan
58. まとめ
59. 我々のリソースは有限です。その中で効率的、効果的、かつ健全にシステムを維持し ていくために役に立つ３つのポイントを紹介しました。 • 価値あるドキュメントを残す ◦ 曖昧さを減らし、誰もが迷わない環境を作ろう • 必要のないものは作らない ◦ 本当に重要なことに集中しよう • 80点を目指す 完璧を求めるよりも、継続的に改善にアプローチで みなさまの今後の参考になりましたら幸いです。 @postman_japan
60. ご清聴いただき、ありがとうございました @postman_japan