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

チーム開発におけるDevとOpsのプラクティス
- Tech-on Meet Up #7 -
Copyright © 2019 KDDI Corporation. All Rights Reserved
プラットフォーム開発本部
アジャイル開発センター
廣田翼

自己紹介
技術統括本部
プラットフォーム開発本部
アジャイル開発センター
様々なサービス/システムの開発を担当
1
廣田翼
Hirota Tsubasa
ネットワークスペシャリスト

アジェンダ
1. はじめに
2. チーム開発と運用の課題
3. 継続的障害訓練のススメ
4. まとめ
2

はじめに
3
KDDIでは、開発と運用で組織が分かれています。
この場合に、チーム開発を行う上で様々な課題に直面し、
１つずつ解決していきました。
本セッションでは開発と運用の異なる組織が、1つのサー
ビス成功というゴールに向かうために行ってきたプラク
ティスを紹介いたします。

チーム開発と運用の課題
4

5
❏ 開発(スクラム)と運用(複数件運用)とでゴールが違う
❏ 開発と運用とでシステムの考え方にギャップがある
❏ 現代のシステムは分散化され複雑である

6

7
開発者運用者
監視もリリースも
自動化したい
監視統合システムに
沿うようにしたい
システム復旧よりも
サービス復旧を
障害原因を特定し
再発防止策を
まずはユーザストーリ
に直結するものを作
ろう
性能、監視要件を
満たそう
チーム外の意見は後
回しにせざるを得ない
どうしたら運用観点を
早くに注入できるんだ
ろう

8
解決策
☞ 実際に運用するメンバを開発チームに入れる
☞ 最初から非機能要件の優先度をPOやチームと調整する
☞ 運用も開発チームの一員となり、サービスをより良
くするためのゴールを統一する

9

10
 システム構成要素をペット扱いする
 SaaSのSLAへのこだわり
 メンテナンスし難い監視設定
 リリース承認フローの硬化

11
 システム構成要素をペット扱いする
 SaaSのSLAへのこだわり
 メンテナンスし難い監視設定
 リリース承認フローの硬化

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

13
 メンテナンスし難い監視設定、への解決策
↑はALB配下のヘルスチェック
カウント数の監視設定のコード

14

15
au でんき

16
au HOME

17
 機能や連携先が増減すればシステム
の構成要素も変化する
 ユーザアクセス傾向も時期により
変化する
 システムは変化するべきであり
運用方法も変化するべき

18
 機能や連携先が増減すればシステムの構成要素も変化する
☞ 各コンポーネント障害が全体に及ぼす影響を把握できない
 ユーザアクセス傾向も時期により変化する
サービスイン前の重厚なテストはアクセス傾向が変われば無意
味になる
☞
 システムは変化するべきであり運用方法も変化するべき
☞ 継続的に運用方法を見直すことが必要

継続的障害訓練のススメ
19

20
 障害訓練によってシステムの
弱点を把握し、対策できる
 運用スキームの弱点も同様
 継続的に行うことでシステム
の変化に追随する

21
❏ 障害はプラットフォームからサーバ、NW、DB
と全域に対して発生させたい
❏ 障害はGUIで発生させて、状況を可視化したい
❏ 複数障害パターンを記憶して簡単に障害を発生
させたい。自動化したい。

22
❏ 障害はプラットフォームからサーバ、NW、DB
と全域に対して発生させたい
❏ 障害はGUIで発生させて、状況を可視化したい
❏ 複数障害パターンを記憶して簡単に障害を発生
させたい。自動化したい。
障害訓練を簡単に行える
ツールを導入しました

Gremlin
https://app.gremlin.com/

Gremlin
 リソース障害
• CPU：高負荷
• メモリ：領域占有
• IO：読み/書きを実施
• ディスク：書き込み
 ネットワーク障害
• ブラックホール：指定したNWトラフィックをドロップ
• 遅延：外向きのNWトラフィックを遅延させる
• パケットロス：外向きのNWトラフィックをパケットロスさせる
• DNS：DNSヘのアクセスをブロックする
 ステート障害
• シャットダウン：OSを再起動または停止する
• タイムトラベル：ホストのシステム時間を変更する
• プロセスキル：特定のプロセスをキルする
2
5

障害訓練の内容
26
対象環境対象設備障害内容
auHOME Staging
(複数プロジェクトで実施)
・APIサーバ
・踏み台サーバ
・など
計9台
・メモリ負荷
・時刻同期の解除
・DBアクセスを遅延させる
・AWSリソースアクセスを70%失敗
・外部システムアクセスを70%失敗
・内部間アクセスを70%失敗
 訓練は基本、開発チームと運用(障害対応チーム)と合同で実施した
 障害対応者には何の障害をいつ発生させるかは伝えない
 実際に障害が発生したと想定して障害対応する

訓練参加者の声
27
どの障害が起こる
か不明なので現実
に近い
復旧対応に慣れて
いないため時間が
かかった
被疑箇所特定に
はシステム構成を
理解する必要があ
る
何も障害対応が出
来ないことが分かっ
た
アプリの不具合しか対
応出来ないことが分
かった
APMツールの有効
性に気付いた
手順書の判断に
時間がかかった
復旧対応の順番を改
善することでよりサー
ビス影響のないもの
へと改善できた
開発
運用

障害訓練の効果
28
❏ 各コンポーネント障害時のユーザ影響が分かる
❏ 障害手順の不備の修正や改善ができる
❏ 実際の障害状況に近い環境で訓練できる
❏ システムを改善できる機会が得られる

まとめ
29

30
❏ 運用要件もユーザストーリと同等に優先順位を付
けるために運用観点を持ったメンバを活用する
❏ チーム開発に適した運用方法をチーム内で確立し、
運用もクラウドやコード化の恩恵にあずかる
❏ 強硬化しがちな運用監視プラクティスをツールを
用いて柔軟にし、サービス品質を向上させる
まとめ

ご静聴ありがとうございました

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

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

Ähnlich wie チーム開発におけるDevとOpsのプラクティス (20)

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