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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

テクノロジー・エバンジェリスト Postman株式会社川崎庸市 / Yoichi Kawasaki @yokawasa @postman_japan

Slide 3

Slide 3 text

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

Postman API Platform Landscape @postman_japan

Slide 6

Slide 6 text

Postmanイベント Postman API Night(勉強会)＆ワークショップ https://postman.connpass.com/ Please Follow us - Postman イベント情報 Postman Japan X https://twitter.com/postman_japan

Slide 7

Slide 7 text

Postman Japan コミュニティ Discord Discord サーバーを開設しました！今後 Postman のプロダクトアップデートやイベント情報の配信や、みなさんとの交流の場として活用していきたいと思います。 https://discord.gg/G4SQWDDqVa @postman_japan

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

NoOps = No Uncomfortable Ops システム運用の “嬉しくないˮ をなくそう

Slide 10

Slide 10 text

デブサミ2018にて https://codezine.jp/article/detail/10716

Slide 11

Slide 11 text

https://noopsjapan.github.io NoOps Japan Community

Slide 12

Slide 12 text

What is NoOps? Why does it matter? 5年前のスライドを元におこしてます

Slide 13

Slide 13 text

システムは「価値」と「負担」でできている価値負担利用者提供者

Slide 14

Slide 14 text

理想価値負担利用者提供者価値は大きく負担は軽い

Slide 15

Slide 15 text

現実価値負担利用者提供者価値はそこそこ、重い負担

Slide 16

Slide 16 text

現実価値負担利用者提供者 Ops • 監視 • 障害対応 • 監査 • リリース • 報告 • パッチ適用 • データ抽出 • 夜間呼び出し • 保守切れ対応 • etc… • これらに伴う費用負担だらけで身も心も、競争力も消耗…

Slide 17

Slide 17 text

現実価値負担利用者提供者 Ops • 監視 • 障害対応 • 監査 • リリース • 報告 • パッチ適用 • データ抽出 • 夜間呼び出し • 保守切れ対応 • etc… • これらに伴う費用負担だらけで身も心も、競争力も消耗… NoOps = No “Uncomfortableˮ Ops 運用のˮ嬉しくないˮを、なくそう

Slide 18

Slide 18 text

攻めの NoOps 守りの NoOps

Slide 19

Slide 19 text

Defensive NoOps 価値負担利用者提供者負担自動化、効率化を進めて、 Ops環境を改善する守りの NoOps • 監視・通知の自動化 • リトライの自動化 • 構成変更の自動化 • 方式の標準化 • 状態の可視化 SRE活動など

Slide 20

Slide 20 text

Offensive NoOps 価値利用者提供者負担構造的にOps不要なシステムとして設計する価値負担攻めの NoOps Microservices Container Serverless

Slide 21

Slide 21 text

Resiliency 価値利用者提供者負担「高い回復性」によって、価値向上と負担軽減を獲得可能価値負担 • 停止時間ゼロ • バーストも無問題 • 安定したスループット • システム予算低減 • 自己回復 • 弾力的なリソース割当 • 動的構成変更 • トイル削減

Slide 22

Slide 22 text

攻めの NoOps 守りの NoOps

Slide 23

Slide 23 text

Design for NoOps Less Ops NoOps に向けた設計思想の転換 NoOps ≠ No Ops 人間による運用はゼロにはならない

Slide 24

Slide 24 text

Resiliency 高い回復性 Observability 可観測性 Configurability Automation Ops Safety Safety 安全性の担保 Monitor/Detect Resilience Less Toil トイル削減 Predictability 構成可能性予測可能性 NoOps活動の分類

Slide 25

Slide 25 text

Resiliency ③高い回復性 Observability ① 監視・検知 Configurability ② 自動構成 Automation Event /Monitor Running 正常稼働 Detect Resilience NoOps Failure Failureから30秒以内に回復障害〜回復までのライフサイクルで考える

Slide 26

Slide 26 text

https://github.com/noopsjapan/community/blob/master/DEFINITIO N.md 

Slide 27

Slide 27 text

時は流れ、やがて気づく初期のNoOps定義に欠けているもの、見落としていたもの

Slide 28

Slide 28 text

長期的な成長させ、健全に維持していくのに、技術だけでは補いきれない部分： ● 事業・ビジネスを交えた立体的な観点 ● コスト最適化（価値に対する消費リソースの最適化） ● 組織・人の練度（練度に応じた適切な選択） ● 知恵の継承

Slide 29

Slide 29 text

いよいよ本題走り続けるための技術技術も人も変化する中でシステムを健全に維持していくためのヒントをご紹介します

Slide 30

Slide 30 text

価値あるドキュメントを残す組織やプロジェクトの効率と品質を持続的に向上させるために必要なもの

Slide 31

Slide 31 text

価値あるドキュメントとは？ @postman_japan 価値が高いドキュメント目的が明確でわかりやすいユーザー・読者目線可読性が高いアクセスしやすい持続的に改善され続ける使いやすい構造（機械が読める）

Slide 32

Slide 32 text

なぜドキュメントを残すのか？ @postman_japan ドキュメント知識の共有・伝達、学び意思決定の記録オンボーディング一貫性の維持コンプライアンス品質の維持

Slide 33

Slide 33 text

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利用における障壁

Slide 34

Slide 34 text

例: Web APIの開発・テストにおけるドキュメント ● 開発者やテスターなど API 開発関係者にとって「仕様書」であり、「テスト設計」の起点となる ● 良質なドキュメントがあれば API仕様とテストコードのズレを回避しやすくなる ● 仕様の認識の齟齬を防ぎ、効率的なコラボレーションが可能になる

Slide 35

Slide 35 text

例: アーキテクチャ選定、技術選定の記録あるプロダクトの刷新プロジェクトにおいて遭遇したプロジェクト継続性に関わる闇深い問題 ● 過去のアーキテクチャに関する包括的な結論が記載された資料はあるものの、そこに至るまでの設計意図やトレードオフについて整理されたものが存在しない ● 過去に行われた関連 MTGの議事録やSlackの関連会話の中に内容が断片的に残ってはいるものの、埋もれてしまっている ● プロジェクト初期から参画している人でさえもその意図を忘れてしまっている（時間の経過による記憶の風化）。思い出そうにも残っている記録が断片的すぎて判断がつかない。 ⇒ 後から参画した担当者は、過去の経緯・意図が分からず意思決定の判断が難しい状態。さらに初期参画者ですらその意図を忘れてしまっている。プロダクトに関する意思決定の記憶が失われてしまっている

Slide 36

Slide 36 text

アーキテクチャ選定、技術選定いかなる決定においてもその背景に関連する議論、トレードオフ、計画などがあるはず。アーキテクチャや技術の選定においては、その選定理由や結論に至るまでに行ったトレードオフがとても重要 ● フレームワーク ● API仕様設計ツール ● 認証・認可の仕組み ● モノリス、マイクロサービスアーキテクチャ ● イベント駆動型アーキテクチャ ● データベース構成、トランザクション分離レベル ● Cache構成 ● シングル、マルチリージョン ● 可用性構成、回復性機能 ● セキュリティ対策 ● etc

Slide 37

Slide 37 text

そこで導入したのが 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 重要なアーキテクチャ上の決定事項を、その背景や結果とともに記録するための手法

Slide 38

Slide 38 text

必要のないものは作らない同じような内容をこちらでも発表しています「作りすぎない技術」 https://speakerdeck.com/yokawasa/thinking-about-the-state-of-development-efforts-in-the-api-era

Slide 39

Slide 39 text

ここでの「必要のないもの」とは ● 本質的な課題を解決しないもの ● 利用者のユースケースを実現しないもの ● 冗長なもの ● 代替可能なもの ● 過剰なもの（将来的に不要になる） ● 維持管理が難しいもの（将来的に不要になる） @postman_japan イシューからはじめよ ――知的生産の「シンプルな本質」 https://amzn.to/3XK87VU

Slide 40

Slide 40 text

YAGNI - 必要になるまで作らない YAGNI You ain't gonna need it) 実際に必要となるまでは追加しない方がよいとするExtreme Programming XPにおける原則 Yagni https://martinfowler.com/bliki/Yagni.html 推定・仮説に基づいて作る機能の3つの分類とそれぞれ YAGNIを無視した場合に発生する4種類のコスト ● 構築コスト ● 修理コスト ● 維持コスト ● 遅延コスト ● 正しくない機能 ● 間違って作られた正しい機能 ● 正しく作られた正しい機能 @postman_japan

Slide 41

Slide 41 text

標準化されている / 相互運用性のあるものを選ぶ ● 標準化 / 相互運用性のあるもの ○ インターフェース、フォーマット、プロトコル ○ 世界標準、組織標準 ● 標準化 / 相互運用性のある世界はスケールする ○ 学習コスト、コラボレーションコスト低減 ○ 柔軟性、拡張性の向上 ○ エコシステムの有効活用 / 巨人の肩の上に立つ ● 独自技術・仕様のデメリット ○ (将来的に) コスト高、属人化、技術的負債 @postman_japan

Slide 42

Slide 42 text

その時点でのベストな技術スタックを選ぶ技術的にイケてる（卓越）かどうかだけでなく、チーム能力、制約などのバランスも加味する ● 技術的な卓越性 ○ 将来性、成熟度、パフォーマンス、セキュリティ、サポート、エコシステム ● チームスキル・経験（練度） ○ チーム練度、学習曲線、外部リソースが調達可能か ● 制約事項（コスト・スケジュール） ○ 保守性、開発・運用・ライセンス費用など ○ 時間的制約 https://speakerdeck.com/twada/understanding-the-spiral-of -technologies-2023-edition 技術卓越性チームスキル制約事項 @postman_japan 技術選定 …

Slide 43

Slide 43 text

車輪の再発明をしない @postman_japan

Slide 44

Slide 44 text

組織的開発における重複を排除する組織開発における重複や重複がもたらす不要な開発の例 ● 機能の重複開発 ○ リソースの無駄遣い ○ 統合時に互換性や一貫性の問題の原因になる ● ドキュメンテーションの重複 ○ リソースの無駄遣い ○ 互換性や一貫性の問題の原因になる ● ツールやプロセスの重複 ○ 全体的な効率低下、一貫性低下 ○ 組織全体の改善が進みにくくなる @postman_japan

Slide 45

Slide 45 text

組織内における重複を排除する重複 / 車輪の再開発を排除するための施策例 ● コミュニケーション強化 ○ チーム間インタラクションを通じた知識・スキル・自立性の向上、重複排除 ● ツールとシステムの統合 ○ 一貫性、効率性向上につながる ● 標準化とガイドラインの策定 ○ 同じ目的のツール、プロセスの標準化 ○ 一貫性、効率性向上につながる @postman_japan

Slide 46

Slide 46 text

80点を目指す「100点の品質」よりも「ほどよい品質 80点)」を「継続的に改善」するアプローチで同じような内容をこちらでも発表しています「作りすぎない技術」 https://speakerdeck.com/yokawasa/thinking-about-the-state-of-development-efforts-in-the-api-era

Slide 47

Slide 47 text

注意: 80点は目安。必ずしも合格点ではない ● 製品やサービスの性質 ○ 医療機器、航空機制御などミッションクリティカル系では最高水準の品質が求められる ● ユーザーの期待とニーズ ○ 特定の市場や顧客セグメントでは、高い品質が要求される ● リスクとコスト ○ バグや不具合が発生した場合のインパクト ○ リソースやコストの制約前置き @postman_japan

Slide 48

Slide 48 text

100点の品質の追求は難しい複雑で不確実性が多い今日のシステム環境において、100点の品質追求は難しく、また割に合わないことが多い ● 多様な技術の統合・連携 ○ クラウド、オンプレミス、モバイル、 IoTデバイスなど ○ 異る技術の統合は複雑性を増大させる（サービス障害、ネットワーク遅延・断絶） ● 継続的に更新される環境 ○ クラウド、クラウドネイティブなプロダクトは頻繁なアップデートが前提 ○ それに依存するシステムは頻繁なアップデートに追従が必要 ● 急速な技術進化 ○ 新しいツール、フレームワーク、プログラミング言語など前よりもよいものが日々登場 ○ それに伴いアーキテクチャの正攻法も変化 ● ビジネス環境の変動 ○ 市場の変動、競争の激化、新しい規制や法令の導入など ○ システムの適用を難しくし、不確実性を増大 @postman_japan

Slide 49

Slide 49 text

ほどよい80点の品質を目指す戦略 100%の品質よりもほどよい80点の品質を高速かつ継続的に改善するアプローチ ● 堅牢性よりも機動性と回復性 ○ 障害の発生は可能な限り早期に検知する ○ 障害から迅速に回復しダウンタイム時間を抑える (自己回復力や冗長性 ) ● 継続的テスト・改善（Shift Left、Fail Fast） ○ ライフサイクルの早いフェーズからテスト ○ フィードバックを迅速に反映して逐次改善する ● 目標設定と優先度付け ○ どの程度の追求すべきか目標設定と優先度付けを行う @postman_japan

Slide 50

Slide 50 text

“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

Slide 51

Slide 51 text

機動性と回復性を重視する障害は可能な限り早期に検知し被害を最小限に抑えることを目指す ● MTTR (平均復旧時間)：障害発生〜復旧までの平均時間 ● 可観測性（オブザーバビリティ） MTTR = Mean Time To Repair MTBF = Mean Time Between Failures どれだけ早く復旧するかどれだけ壊れにくいか UP DOWN 復旧 MTTR MTBF @postman_japan

Slide 52

Slide 52 text

機動性と回復性を重視する ● リリースまでのリードタイムを短くして、高速フィードバックループを回す ○ コード化（x-as-code）、継続的テスト、CI/CD ● ある程度完成したら一部をリリースして様子をみて、ダメなら戻す ○ Blue/Green、カナリアリリース ● 障害の発生は可能な限り早期に検知し回復へのアクションに移す ○ 監視・観測、セルフヒーリング、オートスケール @postman_japan

Slide 53

Slide 53 text

Fail Fast - 問題の早期発見と対処実践方法 - APIファースト APIの場合) - テスト駆動開発 TDD - 継続的インテグレーション CI - スクラム ⇒ アジャイル開発の基本理念と一致 Fail Fastの目的 - 問題の早期発見と対処 - リスクの最小化 - フィードバックの迅速化 - 継続的な改善 @postman_japan

Slide 54

Slide 54 text

Shift Left ● できるだけAPIライフサイクルの早い段階で実施するようにしましょう。早期にバグや問題を発見し、修正コストを削減できます ● セキュリティ、パフォーマンス面のような非機能要件のテストおいては、 APIライフサイクルの後ろのフェーズで実施される例が多く見られるが、このような非機能要件に関する問題は致命的な事が多い @postman_japan 定義設計開発テストデプロイ監視観測配布 check check 致命的な問題発見デザイン変更 APIライフサイクルにおける後半フェーズで問題が発見されたイメージ

Slide 55

Slide 55 text

フィードバックループと新陳代謝 ● 一度作った終わりではなく、ソフトウェアライフサイクルにおける課題をフィードバックを元に継続的に改善させる ● システムを新陳代謝させていくことが生存の鍵 ● そのためには新陳代謝しやすい構造にしておくことが重要計画設計テスト実装デプロイ監視観測問題対処要件定義 RTO/RPO 障害識別回復性実装信頼性のあるデプロイフィードバック改善分析ポストモーテム回復性テスト反応＆対処アラート @postman_japan

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

目標設定と優先度付けリソースは有限。目標設定と優先度付けしてほどよい品質を目指す ● 必要以上の自動化、コード化はやらない ○ 頻繁に変更される部分 ○ 繰り返しテストされるが、手動テストが困難または時間がかかる部分 ○ バグや障害による影響が大きい部分 ○ 共通機能 ● SLO / SLAによる品質目標の定量化 ○ 追求すべき品質目標の定量化と、リソースの配分や優先順位付けを行う ○ SLO Service Level Objective): 期待されるパフォーマンスレベルの定義 (例: 99.9%の稼働時間、応答時間が1秒以下など) ○ SLA Service Level Agreement): 品質レベルやサービスレベルを文書化した契約 @postman_japan

Slide 58

Slide 58 text

まとめ

Slide 59

Slide 59 text

我々のリソースは有限です。その中で効率的、効果的、かつ健全にシステムを維持していくために役に立つ３つのポイントを紹介しました。 ● 価値あるドキュメントを残す ○ 曖昧さを減らし、誰もが迷わない環境を作ろう ● 必要のないものは作らない ○ 本当に重要なことに集中しよう ● 80点を目指す完璧を求めるよりも、継続的に改善にアプローチでみなさまの今後の参考になりましたら幸いです。 @postman_japan

Slide 60

Slide 60 text

ご清聴いただき、ありがとうございました @postman_japan