Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
企業向け
クラウドサービスの
開発・運用
悩みどころの
パターンと対策
サイボウズ株式会社 大阪開発部
三苫 亮
本日のアジェンダ
お伝えしたいこと👈
自己紹介
クラウドサービスの悩み
パターンと対策
まとめ
2
お伝えしたいこと
クラウドサービスの開発・運用に
おいても、当然銀の弾丸はない
問題を自分たちのコンテキストで
解決していくしかない
3
お伝えしたいこと
とはいえ、多くの現場で同じように
起きる問題もたくさんあります
👨悩んでいるのは弊社だけでは…
👨どこも似たようなことに悩んでるんだな
4
お伝えしたいこと
このセッションを聞いた後、
こう考えるきっかけになれば幸いです
👨自分たちの場合、どう対応できるだろう?
👨どこも似たようなことに悩んでるんだな
5
本日のアジェンダ
お伝えしたいこと✅
自己紹介👈
クラウドサービスの悩み
パターンと対策
まとめ
6
自己紹介
三苫 亮(みとま りょう)
@mitomasan
サーバーサイドエンジニア
 Java, DB周りが好き
週3回在宅、週2回出社
7
自己紹介
三苫 亮(みとま りょう)
2005~ 自社サービス開発(時々SI)
 メール配信/CRMシステム
2015~ サイボウズ入社
 kintone開発(自社サービス)
 大阪にも開発部があります!
8
kintone(キントーン)
9
本日のアジェンダ
お伝えしたいこと✅
自己紹介✅
クラウドサービスの悩み👈
パターンと対策
まとめ
10
クラウドサービスの悩み
利用者数や負荷が急激に変化したり
企画・開発時には考えもしなかった
使い方をする顧客がいたり
課金対象としてどの指標を使うか
機能にどのような制限するのか
etc…
11
お話しするクラウドサービス
業務システム
スキーマ不定データベース
大量データの検索・集計
マルチテナント
12
お話しするクラウドサービス
業務システム
 求められること
 顧客の業務を止めない
 セキュリティ
 データの完全性・堅牢性
13
お話しするクラウドサービス
スキーマ不定データベース
 顧客ごとに項目設計できるような
データベース
名前 性別 地域 趣味
A木 一太郎 男 京都 旅行
B山 花子 女 大阪 読書
性 名 学年 学部
A木 一太郎 1 工学部
B山 花子...
お話しするクラウドサービス
大量データの検索・集計
 スキーマの不定なデータを
顧客の指定した項目で行いたい
👨 近畿在住の三苫さんを探したい
👨 日次の売り上げの中央値が欲しい
15
お話しするクラウドサービス
マルチテナント
 複数の企業
 複数のユーザー
🏢企業
👥ユーザー
☁ サービス
🏢企業
👥ユーザー
16
それって・・・
じゃぁ今日の話は kintone のこと?
 一つのサービスに限った話では
ありません
 似たような機能を持ったサービスでも
同様に起きていたパターンを
お話しします
17
本日のアジェンダ
お伝えしたいこと✅
自己紹介✅
クラウドサービスの悩み✅
パターンと対策👈
まとめ
18
パターンスタイルで紹介
経験
 クラウドサービスの開発・運用のなかで起きたこと
課題
 どういう事が課題として持ち上がってくるか
理想
 その課題に対してどうありたいのか
対策
 理想に近づくためにやったこと・やりたかったこと
19
パターンと対策
 性能系
 見積れない性能要件
 想定外の
ヘビーユーザー
 事前チューニング困難
 サービスのありかた
 どこからお金を
いただこう?
 個別カスタマイズ
 新機能 vs 利便性
 リリース・運用系
 無停...
見積れない
性能要件
性能系 1
21
見積れない性能要件
経験
 ビジネス側に性能要件を
リクエストしても出てこない
 開発側でとりあえず雰囲気で
性能目標を作ってそれを達成する
 性能問題が発生
 ゴール未設定のチューニングタスクが登場する
 「とにかく速くして!」
...
見積れない性能要件
課題
 必要な性能要件を見積れない
理想
 見積らなくても性能問題で
深刻な問題を起こさずに済むようにする
対策
 スケールアウトできる
アーキテクチャを選択しておく
23
見積れない性能要件
なぜ見積れないか?
サービスの最終的な伸びは
ビジネス側も予測できるわけがない
スモールスタートしたい
とはいえ、利用が伸びてきたら
それに合わせてスケールしてほしい
24
見積れない性能要件
だから
パフォーマンス増強が
すばやく行える
アーキテクチャを選択する
25
見積れない性能要件
アプリケーションサーバー
スケールアウトで負荷の増加に
対応できるように
 セッション管理の検討を忘れずに
 セッションレプリケーション
 DBに保存
26
見積れない性能要件
セッションレプリケーション
 メモリ上のセッション情報を同期
アプリ
サーバー
セッション情報
アプリ
サーバー
セッション情報
アプリ
サーバー
セッション情報
同期
27
見積れない性能要件
セッション情報を外部管理
 DB や memcached, yrmcds
セッション
管理DB
アプリ
サーバー
セッション
管理DB
アプリ
サーバー
アプリ
サーバー
※yrmcds はサイボウズが開発するOSS
me...
見積れない性能要件
データベース
 スケールアウトできる構成にする
 スケールアウトできる構成にできなければ予算
の許す限りハイスペックなものを
選びスケールアップで対応するしかない
 スケールアップは(オンプレでは)大変
 IaaS使...
見積れない性能要件
テナント毎に分離例
 テナントの増加に合わせて増強できるように
テナント
管理DB
テナントDB
1
アプリ
サーバー
テナント
管理DB
テナントDB
1
アプリ
サーバー
テナントDB
2
大規模なデータを持つ顧客向け...
想定外の
ヘビーユーザー
性能系 2
31
想定外のヘビーユーザー
経験
 上限値を設定せずにいたら
無制限にデータが作られる
 数回使われる程度で想定していた機能を
想定の数百倍使われる
 スキーマ不定データベースあるある
 正規化せずに数百カラム作ったら
サービスが重いんです...
想定外のヘビーユーザー
課題
 制限されていない機能は必ず
想定を超えた利用をされる
理想
 想定を超える利用が制限されている
対策
 ニッチ機能であっても想定を超えた
利用をされるので利用上限を設ける
33
事前チューニング
困難
性能系 3
34
事前チューニング困難
経験
 リリース前にパフォーマンス測定と
チューニングを試みる
 いくつか問題は見つかるが、不安が残る
 パターンを洗い出そうとするが
スキーマ・検索・集計が自由なサービスのため
組み合わせ爆発して人知を超える
(の...
事前チューニング困難
課題
 ボトルネックをリリース前に特定できない
理想
 ボトルネック発生時に
チューニングのための情報がそろっている
対策
 事前対策はあきらめて発生時に
素早く対応できる準備を整える
36
事前チューニング困難
事前チューニングはあきらめる
 明らかな(想像できる)
ユースケースだけを対応
 あとは素早く対応できる準備を整える
 顧客のスキーマやデータ量が分からないと
何もできない
 レスポンスタイムやクエリログの記録
...
どこからお金を
いただこう?
サービスのありかた 1
38
どこからお金をいただこう?
経験
 作るサービスは決まった
 お金のとり方は決まっていない
 どの指標を使って課金する
 ユーザー数?レコード数?通信料?利用時間?
メール数?アクセス数?保存データ量?
 サービスのリリースが近づき
...
どこからお金をいただこう?
例えば
「その月のレコード数」
に対して課金しよう
 リアルタイム?その日の終わり?月末?
 例えば100万件のデータの入れ替えを
するときに作業順序で価格は変わる?
 100万件登録→100万件削除
 1...
どこからお金をいただこう?
課題
 課金対象の指標が決まらない・取れない
理想
 課金対象の指標が取れる
対策
 指標をとるのにも開発が必要な場合が
あることを認識してサービス設計する
41
個別カスタマイズ
サービスのありかた 2
42
個別カスタマイズ
経験
カスタマイズと称して
クラウドサービスのコードに
○○社様対応フラグを入れる
ある環境だけ謎のバッチが動いている
新機能追加時にカスタマイズの
考慮もれ発生
43
個別カスタマイズ
課題
 製品を特定顧客に特化した要望を
入れるとコードが複雑化する
理想
 特定顧客のカスタマイズが
製品をいびつにしない
対策
 APIや拡張ポイントを用意する
44
個別カスタマイズ
筋の悪い個別カスタマイズは避ける
 サービスをスケールさせることが
できなくなる
 安易にカスタマイズをすると
自分たちに負債が返ってくる
 筋の良いカスタマイズ機能を
設計してサービスに組み込みましょう
 API を...
新機能
vs
利便性
サービスのありかた 3
46
新機能 vs 利便性
経験
 新機能開発に追われて、
製品の使い勝手がずっと向上しない
 しかし、その新機能の利用は伸びない
 ちょっとしたUI改善だけで
多くのお客様から喜びの声が上がる
 しかし、改善のためのリソースは増えない
47
新機能 vs 利便性
課題
 どちらを優先するか、常に対立がある
理想
 その時一番効果的な開発を選択できる
対策
 立場の弱いほうにも、
最小限のリソースを割り当てておく
48
新機能 vs 利便性
新機能優先はしかたがない
多くの場合は分かりやすい
機能搭載のほうが優先される
業務システムなので利便性の
優先度はどうしても低くなる
 課題を解決できることが重要なので
良い気分で、楽々解決というのはその次
49
新機能 vs 利便性
けど弊害が大きい
 開発側が自分たちでサービスを改善できる
と思わなくなり改善意欲が衰える
 NOばかり言われるとやがて何も言わなくなる
 利便性で解決できる問題が新機能の利用を
ブロッキングしていたりする
 本当...
新機能 vs 利便性
利便性改善のリソースは
少しでも、必ず計画にのせるようにする
 作った新機能だって必ず仮説を
検証した後の修正が必要
 とりあえず作ったがその後は放置の
中途半端機能をドンドン搭載した
覚えはありませんか?
 リリー...
無停止リリース
リリース・運用系 1
52
無停止リリース
経験
無停止リリースを実現するため
リリース手順の作成・検証に多くの
リソースが割かれる
無停止リリースがうまくいかず
障害扱いの停止が発生する
53
無停止リリース
課題
 サービスを停めないと安定したリリースは難しい
 サービスを停めると顧客の満足度は低下する
理想
 無停止かつ安定したリリース
対策
 効果を見極めてできるところから
54
無停止リリース
サービスを止めずにリリースするには
基本は歯を食いしばる道しかない
 リハーサル環境を用意する
 リリース手順の自動化
 ブルーグリーンデプロイメント
 DDL発行時にロックを最小化する
 影響範囲・依存関係を丁寧に...
無停止リリース
そのシステムは
本当に止めてはいけないか?
 リスクがあるなら交渉や調整をしよう
 絶対大丈夫と言える?と言われて
「はい」と言い切れない場合だってある
 悩ましいときは顧客への価値を
一番に考えよう
 計画停止 vs ...
無停止リリース
やるならいつから目指すか
 ローンチ直後からサービスを
無停止リリースを始めるのは大変
 無停止リリースの準備にかかるコストと
機能開発・安定化に割くコストの
効果が逆転するまでは停止リリースがよい
 リスクの大きなリリー...
障害調査と
セキュリティ
リリース・運用系 2
58
障害調査とセキュリティ
経験
 障害調査に必要な情報が取れない
 ログは運用の人しか見られない
 顧客の機密情報がDBに入ってるから
見られない・同意をとるのに時間がかかる
 システムに詳しい人間が直接調査できない
 コンソールルーム...
障害調査とセキュリティ
課題
 迅速な障害調査がセキュリティ体制に阻害される
理想
 最適な人が必要な情報を取得する
権限をもったうえで調査に携われる
対策
 障害対応のエースが運用サーバーに入れるようにする
 機密情報をつぶして取得す...
障害調査とセキュリティ
どうすればいいか
 短期的には障害対応のエースが
直接データを見れるよう手配するのが早い
 もちろんきちんとトレーニングを
受けさせるなどセキュリティの基準は
クリアさせる
 長期的には機密情報をつぶしたデータを取...
障害調査とセキュリティ
注意点
「DevOps!」と唱えて垣根を
取り払ってしまうだけだと
結構すぐに弊害が出てきてしまう
 カウボーイが本番サーバーを
触れるようにするのだけはやめよう
62
継続的デリバリー
vs
定期更新希望
リリース・運用系 3
63
継続的デリバリー vs 定期更新希望
経験
 リリースサイクルは速めたい
 継続的デリバリー勉強会の輪講や
他社事例を読んで機運を高める開発陣
 それを望まない顧客がいる
 UIを頻繁に変えられると
こちらの業務も変わってしまう
 N...
継続的デリバリー vs 定期更新希望
課題
 どちらに倒しても、不満の声が上がる
理想
 どちらからも大きな不満が出ない
対策
 外から見えるリリースサイクルを
変えられるようにしておく
65
継続的デリバリー vs 定期更新希望
どうするか
 基本的にはそのときどきで
サービスのスタンスを決めるしかない
 今は新機能を次々打ち出すことが
大事なのか
 利用者を混乱させずに満足度を
上げていくのが大事なのか
 スタンスを決めず...
継続的デリバリー vs 定期更新希望
どうするか
 開発は要求が低くても
継続的デリバリーに取り組んでおく
 外からみえるリリースサイクルを
急に下げることはできても
急に上げることはできない
 テストチームに継続的デリバリー
するだけで...
パターンから
ふりかえり
68
パターンをだしてみて
 クラウドサービスに限らない話
 当たり前な話が多い
 「今だと○○で解決できるよ」という話も多い
 けれど、サービス開発は正しい道を
最初から気づけなかったり
選べなかったりすることだらけ
 勉強不足や知識不足...
元上司のいい話
昔、確信のもてない、批判意見もある
アーキテクチャ上の選択を行った
ことがあります。
その選択自体は大きなトラブルを
起こすことがなかったが
それが正しい判断だったのか
ずっと気になっていました。
70
元上司のいい話
上司にポツリと言った時の返事
「あとから分かった事実からベストはこうだった
という事は誰にでもできること。
我々は当時、自分たちの知りうる知識の範囲で
最善と判断した選択をしたことは間違いないし
実際それでうまくいった。
なので...
お伝えしたいこと
クラウドサービスの開発・運用に
おいても、当然銀の弾丸はない
問題を自分たちのコンテキストで
解決していくしかない
72
本日のアジェンダ
お伝えしたいこと✅
自己紹介✅
クラウドサービスの悩み✅
パターンと対策✅
まとめ👈
73
まとめ
お伝えしたいこと
 銀の弾丸はない
 自分たちのコンテキストで
解決していこう
クラウドサービスの悩み
 パターンと対策
 クラウドに限らない話も多い
74
以上
Upcoming SlideShare
Loading in …5
×

企業向けクラウドサービスの開発・運用 悩みどころのパターンと対策

3,027 views

Published on

デブサミ関西2016資料の資料です。
http://event.shoeisha.jp/devsumi/20160916/session/1176/

Published in: Technology
  • Be the first to comment

企業向けクラウドサービスの開発・運用 悩みどころのパターンと対策

  1. 1. 企業向け クラウドサービスの 開発・運用 悩みどころの パターンと対策 サイボウズ株式会社 大阪開発部 三苫 亮
  2. 2. 本日のアジェンダ お伝えしたいこと👈 自己紹介 クラウドサービスの悩み パターンと対策 まとめ 2
  3. 3. お伝えしたいこと クラウドサービスの開発・運用に おいても、当然銀の弾丸はない 問題を自分たちのコンテキストで 解決していくしかない 3
  4. 4. お伝えしたいこと とはいえ、多くの現場で同じように 起きる問題もたくさんあります 👨悩んでいるのは弊社だけでは… 👨どこも似たようなことに悩んでるんだな 4
  5. 5. お伝えしたいこと このセッションを聞いた後、 こう考えるきっかけになれば幸いです 👨自分たちの場合、どう対応できるだろう? 👨どこも似たようなことに悩んでるんだな 5
  6. 6. 本日のアジェンダ お伝えしたいこと✅ 自己紹介👈 クラウドサービスの悩み パターンと対策 まとめ 6
  7. 7. 自己紹介 三苫 亮(みとま りょう) @mitomasan サーバーサイドエンジニア  Java, DB周りが好き 週3回在宅、週2回出社 7
  8. 8. 自己紹介 三苫 亮(みとま りょう) 2005~ 自社サービス開発(時々SI)  メール配信/CRMシステム 2015~ サイボウズ入社  kintone開発(自社サービス)  大阪にも開発部があります! 8
  9. 9. kintone(キントーン) 9
  10. 10. 本日のアジェンダ お伝えしたいこと✅ 自己紹介✅ クラウドサービスの悩み👈 パターンと対策 まとめ 10
  11. 11. クラウドサービスの悩み 利用者数や負荷が急激に変化したり 企画・開発時には考えもしなかった 使い方をする顧客がいたり 課金対象としてどの指標を使うか 機能にどのような制限するのか etc… 11
  12. 12. お話しするクラウドサービス 業務システム スキーマ不定データベース 大量データの検索・集計 マルチテナント 12
  13. 13. お話しするクラウドサービス 業務システム  求められること  顧客の業務を止めない  セキュリティ  データの完全性・堅牢性 13
  14. 14. お話しするクラウドサービス スキーマ不定データベース  顧客ごとに項目設計できるような データベース 名前 性別 地域 趣味 A木 一太郎 男 京都 旅行 B山 花子 女 大阪 読書 性 名 学年 学部 A木 一太郎 1 工学部 B山 花子 4 文学部 A社テーブル B社テーブル 14
  15. 15. お話しするクラウドサービス 大量データの検索・集計  スキーマの不定なデータを 顧客の指定した項目で行いたい 👨 近畿在住の三苫さんを探したい 👨 日次の売り上げの中央値が欲しい 15
  16. 16. お話しするクラウドサービス マルチテナント  複数の企業  複数のユーザー 🏢企業 👥ユーザー ☁ サービス 🏢企業 👥ユーザー 16
  17. 17. それって・・・ じゃぁ今日の話は kintone のこと?  一つのサービスに限った話では ありません  似たような機能を持ったサービスでも 同様に起きていたパターンを お話しします 17
  18. 18. 本日のアジェンダ お伝えしたいこと✅ 自己紹介✅ クラウドサービスの悩み✅ パターンと対策👈 まとめ 18
  19. 19. パターンスタイルで紹介 経験  クラウドサービスの開発・運用のなかで起きたこと 課題  どういう事が課題として持ち上がってくるか 理想  その課題に対してどうありたいのか 対策  理想に近づくためにやったこと・やりたかったこと 19
  20. 20. パターンと対策  性能系  見積れない性能要件  想定外の ヘビーユーザー  事前チューニング困難  サービスのありかた  どこからお金を いただこう?  個別カスタマイズ  新機能 vs 利便性  リリース・運用系  無停止リリース  障害調査と セキュリティ  継続的デリバリー vs 定期更新希望 20
  21. 21. 見積れない 性能要件 性能系 1 21
  22. 22. 見積れない性能要件 経験  ビジネス側に性能要件を リクエストしても出てこない  開発側でとりあえず雰囲気で 性能目標を作ってそれを達成する  性能問題が発生  ゴール未設定のチューニングタスクが登場する  「とにかく速くして!」  スケールアップのために 想定外の機材の入れ替えが発生する 22
  23. 23. 見積れない性能要件 課題  必要な性能要件を見積れない 理想  見積らなくても性能問題で 深刻な問題を起こさずに済むようにする 対策  スケールアウトできる アーキテクチャを選択しておく 23
  24. 24. 見積れない性能要件 なぜ見積れないか? サービスの最終的な伸びは ビジネス側も予測できるわけがない スモールスタートしたい とはいえ、利用が伸びてきたら それに合わせてスケールしてほしい 24
  25. 25. 見積れない性能要件 だから パフォーマンス増強が すばやく行える アーキテクチャを選択する 25
  26. 26. 見積れない性能要件 アプリケーションサーバー スケールアウトで負荷の増加に 対応できるように  セッション管理の検討を忘れずに  セッションレプリケーション  DBに保存 26
  27. 27. 見積れない性能要件 セッションレプリケーション  メモリ上のセッション情報を同期 アプリ サーバー セッション情報 アプリ サーバー セッション情報 アプリ サーバー セッション情報 同期 27
  28. 28. 見積れない性能要件 セッション情報を外部管理  DB や memcached, yrmcds セッション 管理DB アプリ サーバー セッション 管理DB アプリ サーバー アプリ サーバー ※yrmcds はサイボウズが開発するOSS memcached 互換の分散KVS 28
  29. 29. 見積れない性能要件 データベース  スケールアウトできる構成にする  スケールアウトできる構成にできなければ予算 の許す限りハイスペックなものを 選びスケールアップで対応するしかない  スケールアップは(オンプレでは)大変  IaaS使う場合はだいぶ楽になってきた  テナント毎にDBを分離できるよう設計しておく  テナントのデータは複数のDBのいずれかに あるという構成をとる 29
  30. 30. 見積れない性能要件 テナント毎に分離例  テナントの増加に合わせて増強できるように テナント 管理DB テナントDB 1 アプリ サーバー テナント 管理DB テナントDB 1 アプリ サーバー テナントDB 2 大規模なデータを持つ顧客向け対応や 顧客毎のデータ分離の観点でも 有利なアーキテクチャ 30
  31. 31. 想定外の ヘビーユーザー 性能系 2 31
  32. 32. 想定外のヘビーユーザー 経験  上限値を設定せずにいたら 無制限にデータが作られる  数回使われる程度で想定していた機能を 想定の数百倍使われる  スキーマ不定データベースあるある  正規化せずに数百カラム作ったら サービスが重いんですが・・・!  前職でも現職でもあった 32
  33. 33. 想定外のヘビーユーザー 課題  制限されていない機能は必ず 想定を超えた利用をされる 理想  想定を超える利用が制限されている 対策  ニッチ機能であっても想定を超えた 利用をされるので利用上限を設ける 33
  34. 34. 事前チューニング 困難 性能系 3 34
  35. 35. 事前チューニング困難 経験  リリース前にパフォーマンス測定と チューニングを試みる  いくつか問題は見つかるが、不安が残る  パターンを洗い出そうとするが スキーマ・検索・集計が自由なサービスのため 組み合わせ爆発して人知を超える (ので、あきらめる)  パフォーマンス問題を見て 「そのパターンがあったか~」 と、感心する 35
  36. 36. 事前チューニング困難 課題  ボトルネックをリリース前に特定できない 理想  ボトルネック発生時に チューニングのための情報がそろっている 対策  事前対策はあきらめて発生時に 素早く対応できる準備を整える 36
  37. 37. 事前チューニング困難 事前チューニングはあきらめる  明らかな(想像できる) ユースケースだけを対応  あとは素早く対応できる準備を整える  顧客のスキーマやデータ量が分からないと 何もできない  レスポンスタイムやクエリログの記録  スキーマの概要やデータ量を素早く 取得するツール・手順を準備する 37
  38. 38. どこからお金を いただこう? サービスのありかた 1 38
  39. 39. どこからお金をいただこう? 経験  作るサービスは決まった  お金のとり方は決まっていない  どの指標を使って課金する  ユーザー数?レコード数?通信料?利用時間? メール数?アクセス数?保存データ量?  サービスのリリースが近づき お金のとり方が決まったが  その指標を集計するのが 大変だったり、無理だったり・・・ 39
  40. 40. どこからお金をいただこう? 例えば 「その月のレコード数」 に対して課金しよう  リアルタイム?その日の終わり?月末?  例えば100万件のデータの入れ替えを するときに作業順序で価格は変わる?  100万件登録→100万件削除  100万件削除→100万件登録 0 1000 2000 3000 4000 5000 1 6 11 16 21 26 レコード数 40
  41. 41. どこからお金をいただこう? 課題  課金対象の指標が決まらない・取れない 理想  課金対象の指標が取れる 対策  指標をとるのにも開発が必要な場合が あることを認識してサービス設計する 41
  42. 42. 個別カスタマイズ サービスのありかた 2 42
  43. 43. 個別カスタマイズ 経験 カスタマイズと称して クラウドサービスのコードに ○○社様対応フラグを入れる ある環境だけ謎のバッチが動いている 新機能追加時にカスタマイズの 考慮もれ発生 43
  44. 44. 個別カスタマイズ 課題  製品を特定顧客に特化した要望を 入れるとコードが複雑化する 理想  特定顧客のカスタマイズが 製品をいびつにしない 対策  APIや拡張ポイントを用意する 44
  45. 45. 個別カスタマイズ 筋の悪い個別カスタマイズは避ける  サービスをスケールさせることが できなくなる  安易にカスタマイズをすると 自分たちに負債が返ってくる  筋の良いカスタマイズ機能を 設計してサービスに組み込みましょう  API を提供する  拡張ポイントを用意する 45
  46. 46. 新機能 vs 利便性 サービスのありかた 3 46
  47. 47. 新機能 vs 利便性 経験  新機能開発に追われて、 製品の使い勝手がずっと向上しない  しかし、その新機能の利用は伸びない  ちょっとしたUI改善だけで 多くのお客様から喜びの声が上がる  しかし、改善のためのリソースは増えない 47
  48. 48. 新機能 vs 利便性 課題  どちらを優先するか、常に対立がある 理想  その時一番効果的な開発を選択できる 対策  立場の弱いほうにも、 最小限のリソースを割り当てておく 48
  49. 49. 新機能 vs 利便性 新機能優先はしかたがない 多くの場合は分かりやすい 機能搭載のほうが優先される 業務システムなので利便性の 優先度はどうしても低くなる  課題を解決できることが重要なので 良い気分で、楽々解決というのはその次 49
  50. 50. 新機能 vs 利便性 けど弊害が大きい  開発側が自分たちでサービスを改善できる と思わなくなり改善意欲が衰える  NOばかり言われるとやがて何も言わなくなる  利便性で解決できる問題が新機能の利用を ブロッキングしていたりする  本当はデータ入力しにくいことが問題なのに 連携サービスが必要という話になったり 50
  51. 51. 新機能 vs 利便性 利便性改善のリソースは 少しでも、必ず計画にのせるようにする  作った新機能だって必ず仮説を 検証した後の修正が必要  とりあえず作ったがその後は放置の 中途半端機能をドンドン搭載した 覚えはありませんか?  リリースしてそこで開発終わりにできる 機能なんてほとんどない 51
  52. 52. 無停止リリース リリース・運用系 1 52
  53. 53. 無停止リリース 経験 無停止リリースを実現するため リリース手順の作成・検証に多くの リソースが割かれる 無停止リリースがうまくいかず 障害扱いの停止が発生する 53
  54. 54. 無停止リリース 課題  サービスを停めないと安定したリリースは難しい  サービスを停めると顧客の満足度は低下する 理想  無停止かつ安定したリリース 対策  効果を見極めてできるところから 54
  55. 55. 無停止リリース サービスを止めずにリリースするには 基本は歯を食いしばる道しかない  リハーサル環境を用意する  リリース手順の自動化  ブルーグリーンデプロイメント  DDL発行時にロックを最小化する  影響範囲・依存関係を丁寧に見ていく 55
  56. 56. 無停止リリース そのシステムは 本当に止めてはいけないか?  リスクがあるなら交渉や調整をしよう  絶対大丈夫と言える?と言われて 「はい」と言い切れない場合だってある  悩ましいときは顧客への価値を 一番に考えよう  計画停止 vs 障害停止 どっちがいい? 56
  57. 57. 無停止リリース やるならいつから目指すか  ローンチ直後からサービスを 無停止リリースを始めるのは大変  無停止リリースの準備にかかるコストと 機能開発・安定化に割くコストの 効果が逆転するまでは停止リリースがよい  リスクの大きなリリースは停止リリースする 軽微な修正は無停止リリースする レベルごとにフローを分けるところから  停止リリースとアナウンスしつつ 裏側では無停止リリースの経験を何度か積んで、 安定してから無停止リリースを宣言しよう 57
  58. 58. 障害調査と セキュリティ リリース・運用系 2 58
  59. 59. 障害調査とセキュリティ 経験  障害調査に必要な情報が取れない  ログは運用の人しか見られない  顧客の機密情報がDBに入ってるから 見られない・同意をとるのに時間がかかる  システムに詳しい人間が直接調査できない  コンソールルームやサーバーに 開発メンバーが入れない  探索的な調査で部署間ピンポンが始まる 59
  60. 60. 障害調査とセキュリティ 課題  迅速な障害調査がセキュリティ体制に阻害される 理想  最適な人が必要な情報を取得する 権限をもったうえで調査に携われる 対策  障害対応のエースが運用サーバーに入れるようにする  機密情報をつぶして取得する仕組みを製品に入れる 60
  61. 61. 障害調査とセキュリティ どうすればいいか  短期的には障害対応のエースが 直接データを見れるよう手配するのが早い  もちろんきちんとトレーニングを 受けさせるなどセキュリティの基準は クリアさせる  長期的には機密情報をつぶしたデータを取り出せ る仕組みを製品に入れる  障害情報を取得する枠組みの整備をすすめると、 対応速度も早まるし知識共有の素材に使いやすい 61
  62. 62. 障害調査とセキュリティ 注意点 「DevOps!」と唱えて垣根を 取り払ってしまうだけだと 結構すぐに弊害が出てきてしまう  カウボーイが本番サーバーを 触れるようにするのだけはやめよう 62
  63. 63. 継続的デリバリー vs 定期更新希望 リリース・運用系 3 63
  64. 64. 継続的デリバリー vs 定期更新希望 経験  リリースサイクルは速めたい  継続的デリバリー勉強会の輪講や 他社事例を読んで機運を高める開発陣  それを望まない顧客がいる  UIを頻繁に変えられると こちらの業務も変わってしまう  Nか月前には連絡してほしい 64
  65. 65. 継続的デリバリー vs 定期更新希望 課題  どちらに倒しても、不満の声が上がる 理想  どちらからも大きな不満が出ない 対策  外から見えるリリースサイクルを 変えられるようにしておく 65
  66. 66. 継続的デリバリー vs 定期更新希望 どうするか  基本的にはそのときどきで サービスのスタンスを決めるしかない  今は新機能を次々打ち出すことが 大事なのか  利用者を混乱させずに満足度を 上げていくのが大事なのか  スタンスを決めずに顧客要望に 振り回されるのが一番だめ 66
  67. 67. 継続的デリバリー vs 定期更新希望 どうするか  開発は要求が低くても 継続的デリバリーに取り組んでおく  外からみえるリリースサイクルを 急に下げることはできても 急に上げることはできない  テストチームに継続的デリバリー するだけでも品質は大きく変わる  体力が出てきたときに環境を分けて個別に 安定環境を提供することができるかもしれない 67
  68. 68. パターンから ふりかえり 68
  69. 69. パターンをだしてみて  クラウドサービスに限らない話  当たり前な話が多い  「今だと○○で解決できるよ」という話も多い  けれど、サービス開発は正しい道を 最初から気づけなかったり 選べなかったりすることだらけ  勉強不足や知識不足から 最適なアーキテクチャを選択したか 自信を持てない時も多々ある 69
  70. 70. 元上司のいい話 昔、確信のもてない、批判意見もある アーキテクチャ上の選択を行った ことがあります。 その選択自体は大きなトラブルを 起こすことがなかったが それが正しい判断だったのか ずっと気になっていました。 70
  71. 71. 元上司のいい話 上司にポツリと言った時の返事 「あとから分かった事実からベストはこうだった という事は誰にでもできること。 我々は当時、自分たちの知りうる知識の範囲で 最善と判断した選択をしたことは間違いないし 実際それでうまくいった。 なので、この件についてどのような 批判があっても耳を貸す必要はない」 71
  72. 72. お伝えしたいこと クラウドサービスの開発・運用に おいても、当然銀の弾丸はない 問題を自分たちのコンテキストで 解決していくしかない 72
  73. 73. 本日のアジェンダ お伝えしたいこと✅ 自己紹介✅ クラウドサービスの悩み✅ パターンと対策✅ まとめ👈 73
  74. 74. まとめ お伝えしたいこと  銀の弾丸はない  自分たちのコンテキストで 解決していこう クラウドサービスの悩み  パターンと対策  クラウドに限らない話も多い 74
  75. 75. 以上

×