Successfully reported this slideshow.
Your SlideShare is downloading. ×

チーム開発におけるDevとOpsのプラクティス

More Related Content

Slideshows for you

Similar to チーム開発におけるDevとOpsのプラクティス

Related Books

Free with a 30 day trial from Scribd

See all

チーム開発におけるDevとOpsのプラクティス

  1. 1. チーム開発におけるDevとOpsのプラクティス - Tech-on Meet Up #7 - Copyright © 2019 KDDI Corporation. All Rights Reserved プラットフォーム開発本部 アジャイル開発センター 廣田 翼
  2. 2. 自己紹介 Copyright © 2019 KDDI Corporation. All Rights Reserved 技術統括本部 プラットフォーム開発本部 アジャイル開発センター 様々なサービス/システムの開発を担当 1 廣田 翼 Hirota Tsubasa ネットワークスペシャリスト
  3. 3. アジェンダ 1. はじめに 2. チーム開発と運用の課題 3. 継続的障害訓練のススメ 4. まとめ Copyright © 2019 KDDI Corporation. All Rights Reserved 2
  4. 4. はじめに Copyright © 2019 KDDI Corporation. All Rights Reserved 3 KDDIでは、開発と運用で組織が分かれています。 この場合に、チーム開発を行う上で様々な課題に直面し、 1つずつ解決していきました。 本セッションでは開発と運用の異なる組織が、1つのサー ビス成功というゴールに向かうために行ってきたプラク ティスを紹介いたします。
  5. 5. チーム開発と運用の課題 Copyright © 2019 KDDI Corporation. All Rights Reserved 4
  6. 6. チーム開発と運用の課題 Copyright © 2019 KDDI Corporation. All Rights Reserved 5 ❏ 開発(スクラム)と運用(複数件運用)とでゴールが違う ❏ 開発と運用とでシステムの考え方にギャップがある ❏ 現代のシステムは分散化され複雑である
  7. 7. チーム開発と運用の課題 Copyright © 2019 KDDI Corporation. All Rights Reserved 6 ❏ 開発(スクラム)と運用(複数件運用)とでゴールが違う ❏ 開発と運用とでシステムの考え方にギャップがある ❏ 現代のシステムは分散化され複雑である
  8. 8. チーム開発と運用の課題 Copyright © 2019 KDDI Corporation. All Rights Reserved 7 ❏ 開発(スクラム)と運用(複数件運用)とでゴールが違う 開発者 運用者 監視もリリースも 自動化したい 監視統合システムに 沿うようにしたい システム復旧よりも サービス復旧を 障害原因を特定し 再発防止策を まずはユーザストーリ に直結するものを作 ろう 性能、監視要件を 満たそう チーム外の意見は後 回しにせざるを得ない どうしたら運用観点を 早くに注入できるんだ ろう
  9. 9. Copyright © 2019 KDDI Corporation. All Rights Reserved 8 ❏ 開発(スクラム)と運用(複数件運用)とでゴールが違う 解決策 ☞ 実際に運用するメンバを開発チームに入れる ☞ 最初から非機能要件の優先度をPOやチームと調整する ☞ 運用も開発チームの一員となり、サービスをより良 くするためのゴールを統一する チーム開発と運用の課題
  10. 10. チーム開発と運用の課題 Copyright © 2019 KDDI Corporation. All Rights Reserved 9 ❏ 開発(スクラム)と運用(複数件運用)とでゴールが違う ❏ 開発と運用とでシステムの考え方にギャップがある ❏ 現代のシステムは分散化され複雑である
  11. 11. Copyright © 2019 KDDI Corporation. All Rights Reserved 10 ❏ 開発と運用とでシステムの考え方にギャップがある  システム構成要素をペット扱いする  SaaSのSLAへのこだわり  メンテナンスし難い監視設定  リリース承認フローの硬化 チーム開発と運用の課題
  12. 12. Copyright © 2019 KDDI Corporation. All Rights Reserved 11  システム構成要素をペット扱いする  SaaSのSLAへのこだわり  メンテナンスし難い監視設定  リリース承認フローの硬化 チーム開発と運用の課題 ❏ 開発と運用とでシステムの考え方にギャップがある
  13. 13. Copyright © 2019 KDDI Corporation. All Rights Reserved 12  システム構成要素をペット扱いする、への解決策 Auto Scaling group Availability Zone #1 Availability Zone #2 web app server EC2 instance RDS instance RDS instance standby CloudWatchLogs EC2 instance web app server ログ転送 AWS Management Console 削除 EC2 instance web app server チーム開発と運用の課題 ❏ 開発と運用とでシステムの考え方にギャップがある
  14. 14. Copyright © 2019 KDDI Corporation. All Rights Reserved 13  メンテナンスし難い監視設定、への解決策 ↑はALB配下のヘルスチェック カウント数の監視設定のコード チーム開発と運用の課題 ❏ 開発と運用とでシステムの考え方にギャップがある
  15. 15. チーム開発と運用の課題 Copyright © 2019 KDDI Corporation. All Rights Reserved 14 ❏ 開発(スクラム)と運用(複数件運用)とでゴールが違う ❏ 開発と運用とでシステムの考え方にギャップがある ❏ 現代のシステムは分散化され複雑である
  16. 16. Copyright © 2019 KDDI Corporation. All Rights Reserved 15 ❏ 現代のシステムは分散化され複雑である au でんき チーム開発と運用の課題
  17. 17. Copyright © 2019 KDDI Corporation. All Rights Reserved 16 au HOME ❏ 現代のシステムは分散化され複雑である チーム開発と運用の課題
  18. 18. Copyright © 2019 KDDI Corporation. All Rights Reserved 17 ❏ 現代のシステムは分散化され複雑である  機能や連携先が増減すればシステム の構成要素も変化する  ユーザアクセス傾向も時期により 変化する  システムは変化するべきであり 運用方法も変化するべき チーム開発と運用の課題
  19. 19. Copyright © 2019 KDDI Corporation. All Rights Reserved 18  機能や連携先が増減すればシステムの構成要素も変化する ☞ 各コンポーネント障害が全体に及ぼす影響を把握できない  ユーザアクセス傾向も時期により変化する サービスイン前の重厚なテストはアクセス傾向が変われば無意 味になる ☞  システムは変化するべきであり運用方法も変化するべき ☞ 継続的に運用方法を見直すことが必要 チーム開発と運用の課題
  20. 20. 継続的障害訓練のススメ Copyright © 2019 KDDI Corporation. All Rights Reserved 19
  21. 21. 継続的障害訓練のススメ Copyright © 2019 KDDI Corporation. All Rights Reserved 20  障害訓練によってシステムの 弱点を把握し、対策できる  運用スキームの弱点も同様  継続的に行うことでシステム の変化に追随する
  22. 22. Copyright © 2019 KDDI Corporation. All Rights Reserved 21 ❏ 障害はプラットフォームからサーバ、NW、DB と全域に対して発生させたい ❏ 障害はGUIで発生させて、状況を可視化したい ❏ 複数障害パターンを記憶して簡単に障害を発生 させたい。自動化したい。 継続的障害訓練のススメ
  23. 23. Copyright © 2019 KDDI Corporation. All Rights Reserved 22 ❏ 障害はプラットフォームからサーバ、NW、DB と全域に対して発生させたい ❏ 障害はGUIで発生させて、状況を可視化したい ❏ 複数障害パターンを記憶して簡単に障害を発生 させたい。自動化したい。 継続的障害訓練のススメ 障害訓練を簡単に行える ツールを導入しました
  24. 24. Gremlin https://app.gremlin.com/
  25. 25. Gremlin https://app.gremlin.com/
  26. 26. Gremlin  リソース障害 • CPU:高負荷 • メモリ:領域占有 • IO:読み/書きを実施 • ディスク:書き込み  ネットワーク障害 • ブラックホール:指定したNWトラフィックをドロップ • 遅延:外向きのNWトラフィックを遅延させる • パケットロス:外向きのNWトラフィックをパケットロスさせる • DNS:DNSヘのアクセスをブロックする  ステート障害 • シャットダウン:OSを再起動または停止する • タイムトラベル:ホストのシステム時間を変更する • プロセスキル:特定のプロセスをキルする 2 5
  27. 27. 障害訓練の内容 Copyright © 2019 KDDI Corporation. All Rights Reserved 26 対象環境 対象設備 障害内容 auHOME Staging (複数プロジェクトで実施) ・APIサーバ ・踏み台サーバ ・など 計9台 ・メモリ負荷 ・時刻同期の解除 ・DBアクセスを遅延させる ・AWSリソースアクセスを70%失敗 ・外部システムアクセスを70%失敗 ・内部間アクセスを70%失敗  訓練は基本、開発チームと運用(障害対応チーム)と合同で実施した  障害対応者には何の障害をいつ発生させるかは伝えない  実際に障害が発生したと想定して障害対応する
  28. 28. 訓練参加者の声 Copyright © 2019 KDDI Corporation. All Rights Reserved 27 どの障害が起こる か不明なので現実 に近い 復旧対応に慣れて いないため時間が かかった 被疑箇所特定に はシステム構成を 理解する必要があ る 何も障害対応が出 来ないことが分かっ た アプリの不具合しか対 応出来ないことが分 かった APMツールの有効 性に気付いた 手順書の判断に 時間がかかった 復旧対応の順番を改 善することでよりサー ビス影響のないもの へと改善できた 開発 運用
  29. 29. 障害訓練の効果 Copyright © 2019 KDDI Corporation. All Rights Reserved 28 ❏ 各コンポーネント障害時のユーザ影響が分かる ❏ 障害手順の不備の修正や改善ができる ❏ 実際の障害状況に近い環境で訓練できる ❏ システムを改善できる機会が得られる
  30. 30. まとめ Copyright © 2019 KDDI Corporation. All Rights Reserved 29
  31. 31. Copyright © 2019 KDDI Corporation. All Rights Reserved 30 ❏ 運用要件もユーザストーリと同等に優先順位を付 けるために運用観点を持ったメンバを活用する ❏ チーム開発に適した運用方法をチーム内で確立し、 運用もクラウドやコード化の恩恵にあずかる ❏ 強硬化しがちな運用監視プラクティスをツールを 用いて柔軟にし、サービス品質を向上させる まとめ
  32. 32. ご静聴ありがとうございました

×