KDDIが考える顧客へ本当の価値を届けるための開発手法

KDDIが考える
顧客へ”本当の価値”を届けるための開発手法
Copyright © 2017 KDDI Corporation. All Rights Reserved

自己紹介
技術統括本部
プラットフォーム開発本部
アジャイル開発センター
au系、法人系サービスの開発を担当
1
運用グループ
課長補佐
運用グループ
廣田翼
Hirota Tsubasa
ネットワークスペシャリスト

Agenda
1. KDDIについて
2. アジャイルとDevOpsの採用
3. 強いアーキテクチャと運用を目指す
4. 取り組みの振り返り
5. まとめ
2

事業内容
パーソナル
バリュー
ビジネス
グローバル
個人向け通信サービスの提供
個人向けコンテンツ・決済サービス
などの提供
企業向け通信・ソリューション/
クラウド型サービスの提供
海外での企業・個人向け通信、
ソリューション/クラウド型サービスの提供
セグメント
4

KDDI 事業戦略
5

au経済圏の最大化
6

アジャイルとDevOpsの採用

変革を実現するための取り組み
 高速な企画〜開発〜価値提供サイクル
 変更しやすい柔軟なサービス開発
 短い周期で新機能をリリース
 シンプルな復旧オペレーション
8

9
企画設計開発試験提供
企画
設計
開発
試験
提供企画
設計
開発
試験
提供企画
設計
開発
試験
提供
以前の手法
採用した手法

10
auでんきプロジェクトの場合
プロジェクト期間
パートナー様▲
へのお声がけ
（5ヶ月前）
開発期間
新規事業の場合8ヶ月以上
（チームビルドからローンチまで）
６ヶ月
４ヶ月
(実質3ヶ月)
事業計画から業務準備
他の新規事業の場合1年以上
● アプリで電気をもっと身近に
● アプリで便利に省エネ
● 節電グッズを簡単にご購入

11
新技術採用で効率化！
新機能追加！
ちょっとだけ設定変更！
枯れた技術を採用しよう！
サービス断リスクは排除！
作業連絡しなさい！
開発者運用者

引き継ぎ
12
ビジネス要件
アプリケーション
品質確保
開
発
テ
ス
ト
リ
リ
|
ス
開発者
SLA
問合せ対応
インフラ
運用開始
運用者
基本設計書
障害対応手順
アラート対応表
詳細設計書
運用引き継ぎ負荷によってシステムは硬直する

13
開
発
テ
ス
ト
リ
リ
|
ス
DevもOpsも同じチームで
改善策
運
用
開
始
開発者運用者
アラート対応表各設計書障害対応手順

14
リリース手順は複雑になりがち
仰々しく緊張が張り詰める
誰でも簡単にリリース可能にしたい

15
とあるリリース手順書
①
②
③ Webサーバを停止
④
⑤
⑥ Webアプリを差替え
⑦
⑧
⑨
⑩ Webサーバを起動

人間の代わりにプログラム
に行わせる
自動化プログラムをツール
から呼び出す
16
drone.io

17
①押すだけでリリース
とあるジョブ管理ツールのWeb画面

18
Build
格納先
検知
格納
アプリ
構築
サーバ群
プログラム配備
コントローラ
インフラの構築と
アプリの配備(ジョブ②)
アプリの展開
Release!!
マスタープログラム
を更新
ジョブ②を実行
プログラムのビルドと
テストと格納(ジョブ①)
ジョブ管理ツールジョブ管理ツール
ソースコード
管理ツール
テスト
成功
アプリ

19
app app
サーバ群
Blue(Current)
サーバ群
アプリ
Blue Green Deployment
簡単に切り戻し可能
インフラのコード化
ロードバランサ
①インフラの構築
Terraform
②プログラム
の配備
アプリアプリ
Codedeploy
Green(New)
③切り替え
アプリ

20
複雑なコマンド操作はしない
SSHログインなしで復旧させる
クラウド管理コンソールやジョブ
管理ツールから実行

21
ペットではなく家畜のように扱う
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

変革を実現するための取り組み
 変更を許す柔軟なサービス開発
22

強いアーキテクチャと運用を目指す

24
障害パターンを想定する
design for failure
未知の障害に対処するための訓練

25
障害パターンの洗い出しと障害試験
コンポーネント名冗長方式障害内容復旧方法復旧時間ユーザ影響
App Multi-AZ +
AutoScaling
仮想マシンOS
ダウン・ハングアップ
インスタンス再構築
(AutoScaling)
5分未満一部ユーザは
利用不可
javaプロセス
(AutoScaling)
利用不可
ディスク領域(/)の
使用率が100%
(AutoScaling)
利用不可
Bastion シングル構成 sshプロセス
インスタンス再起動
(AWSコンソール)
5分未満影響なし
RDS(MySQL) Multi-AZ RDS系切替
（MySQL障害による
系切替）
Standbyが昇格する
(フェールオーバ)
5分未満系切替中は
利用不可

26
障害パターンの洗い出しと障害試験
どうしても複雑箇所は残る
弱点に対策を打てる
サービスに関わるところと
そうでないところ

27
障害発生を前提として設計する
Auto Scaling
group
Availability
Zone
EC2 instances
web app
server
RDS instance
Master/Slave
Amazon
S3
Amazon
CloudFront
クラウドサービスを積極的に利用する

28
想定できない障害にどう備えるか
実際の障害を想定した訓練
ランダムに障害を起こす
障害時フローの確認と訓練
よりリアリティを持った障害試験

30
auでんきプロジェクトの場合
プロジェクト期間
パートナー様▲
へのお声がけ
（5ヶ月前）
開発期間
新規事業の場合8ヶ月以上
（チームビルドからローンチまで）
６ヶ月
４ヶ月
(実質3ヶ月)
事業計画から業務準備
他の新規事業の場合1年以上
● アプリで電気をもっと身近に
● アプリで便利に省エネ
● 節電グッズを簡単にご購入
課題もまだまだあります

取り組みの振り返り
31
チームのペースと会社のペース
他システムとの連携
非機能要件の扱い

32
企画設計開発試験提供
企画
設計
開発
試験
提供企画
設計
開発
試験
提供企画
設計
開発
試験
提供
以前の手法
採用した手法

33
会社のペースが優先
そして文化を浸透させる

34
他システムとの連携
 システム開発全般の課題
 必要な連携を早期に洗い出しておく
 できるだけ早く結合試験を

35
非機能要件の扱い
要求項目内容要求仕様
可用性サービスを継続的に提供
できる能力
最低でもサービスに関わるコンポー
ネントは冗長化すること
拡張性機能追加を容易にする今後の機能追加を見積もり、追加
に対応できる構成であること
性能サービスへの要求を処理
する能力
ピーク時の要求量を見積もり、全て
処理できること
運用保守問題発生時にもサービス
影響なく解消できる能力
SLAを定義し、これを満たすこと
セキュリティシステム内のデータの安
全性を確保する
システムアクセスを制限し、監査証
跡可能な施策を行うこと

36
非機能要件や運用監視の扱い
ビジネスサイドに伝える
どのサービスにも必ず必要
あらかじめタスクとして認識

38
 お客様へ本当の価値を届けるためには
☞ アジャイルとDevOpsの採用は必然
 お客様のためのサービス
☞ 開発と運用は同じ方向を向くべきである
 さらなるサービス品質向上のために
☞ システムと人を鍛える
 アジャイル、DevOpsを振り返って
☞ 会社文化に応じた手法の確立
まとめ

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

KDDIが考える顧客へ本当の価値を届けるための開発手法

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie KDDIが考える顧客へ本当の価値を届けるための開発手法

Ähnlich wie KDDIが考える顧客へ本当の価値を届けるための開発手法 (20)

KDDIが考える顧客へ本当の価値を届けるための開発手法

Hinweis der Redaktion