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

1. 企業向けクラウドサービスの開発・運用悩みどころのパターンと対策サイボウズ株式会社大阪開発部三苫亮

2. 本日のアジェンダ お伝えしたいこと👈 自己紹介 クラウドサービスの悩み パターンと対策 まとめ 2

3. お伝えしたいこと クラウドサービスの開発・運用においても、当然銀の弾丸はない 問題を自分たちのコンテキストで解決していくしかない 3

4. お伝えしたいこと とはいえ、多くの現場で同じように起きる問題もたくさんあります 👨悩んでいるのは弊社だけでは… 👨どこも似たようなことに悩んでるんだな 4

5. お伝えしたいこと このセッションを聞いた後、こう考えるきっかけになれば幸いです 👨自分たちの場合、どう対応できるだろう？ 👨どこも似たようなことに悩んでるんだな 5

6. 本日のアジェンダ お伝えしたいこと✅ 自己紹介👈 クラウドサービスの悩み パターンと対策 まとめ 6

7. 自己紹介三苫亮（みとまりょう） @mitomasan サーバーサイドエンジニア  Java, DB周りが好き 週３回在宅、週２回出社 7

8. 自己紹介三苫亮（みとまりょう） 2005～自社サービス開発（時々SI）  メール配信/CRMシステム 2015～サイボウズ入社  kintone開発（自社サービス）  大阪にも開発部があります！ 8

9. kintone（キントーン） 9

10. 本日のアジェンダ お伝えしたいこと✅ 自己紹介✅ クラウドサービスの悩み👈 パターンと対策 まとめ 10

11. クラウドサービスの悩み 利用者数や負荷が急激に変化したり 企画・開発時には考えもしなかった使い方をする顧客がいたり 課金対象としてどの指標を使うか 機能にどのような制限するのか etc… 11

12. お話しするクラウドサービス 業務システム スキーマ不定データベース 大量データの検索・集計 マルチテナント 12

13. お話しするクラウドサービス 業務システム  求められること  顧客の業務を止めない  セキュリティ  データの完全性・堅牢性 13

14. お話しするクラウドサービス スキーマ不定データベース  顧客ごとに項目設計できるようなデータベース名前性別地域趣味Ａ木一太郎男京都旅行Ｂ山花子女大阪読書性名学年学部Ａ木一太郎 1 工学部Ｂ山花子 4 文学部Ａ社テーブルＢ社テーブル 14

15. お話しするクラウドサービス 大量データの検索・集計  スキーマの不定なデータを顧客の指定した項目で行いたい 👨 近畿在住の三苫さんを探したい 👨 日次の売り上げの中央値が欲しい 15

16. お話しするクラウドサービス マルチテナント  複数の企業  複数のユーザー 🏢企業 👥ユーザー ☁ サービス 🏢企業 👥ユーザー 16

17. それって・・・ じゃぁ今日の話は kintone のこと？  一つのサービスに限った話ではありません  似たような機能を持ったサービスでも同様に起きていたパターンをお話しします 17

18. 本日のアジェンダ お伝えしたいこと✅ 自己紹介✅ クラウドサービスの悩み✅ パターンと対策👈 まとめ 18

19. パターンスタイルで紹介経験  クラウドサービスの開発・運用のなかで起きたこと課題  どういう事が課題として持ち上がってくるか理想  その課題に対してどうありたいのか対策  理想に近づくためにやったこと・やりたかったこと 19

20. パターンと対策  性能系  見積れない性能要件  想定外のヘビーユーザー  事前チューニング困難  サービスのありかた  どこからお金をいただこう？  個別カスタマイズ  新機能 vs 利便性  リリース・運用系  無停止リリース  障害調査とセキュリティ  継続的デリバリー vs 定期更新希望 20

21. 見積れない性能要件性能系 1 21

22. 見積れない性能要件経験  ビジネス側に性能要件をリクエストしても出てこない  開発側でとりあえず雰囲気で性能目標を作ってそれを達成する  性能問題が発生  ゴール未設定のチューニングタスクが登場する  「とにかく速くして！」  スケールアップのために想定外の機材の入れ替えが発生する 22

23. 見積れない性能要件課題  必要な性能要件を見積れない理想  見積らなくても性能問題で深刻な問題を起こさずに済むようにする対策  スケールアウトできるアーキテクチャを選択しておく 23

24. 見積れない性能要件なぜ見積れないか？ サービスの最終的な伸びはビジネス側も予測できるわけがない スモールスタートしたい とはいえ、利用が伸びてきたらそれに合わせてスケールしてほしい 24

25. 見積れない性能要件だから パフォーマンス増強がすばやく行えるアーキテクチャを選択する 25

26. 見積れない性能要件アプリケーションサーバー スケールアウトで負荷の増加に対応できるように  セッション管理の検討を忘れずに  セッションレプリケーション  DBに保存 26

27. 見積れない性能要件セッションレプリケーション  メモリ上のセッション情報を同期アプリサーバーセッション情報アプリサーバーセッション情報アプリサーバーセッション情報同期 27

28. 見積れない性能要件セッション情報を外部管理  DB や memcached, yrmcds セッション管理DB アプリサーバーセッション管理DB アプリサーバーアプリサーバー ※yrmcds はサイボウズが開発するOSS memcached 互換の分散KVS 28

29. 見積れない性能要件データベース  スケールアウトできる構成にする  スケールアウトできる構成にできなければ予算の許す限りハイスペックなものを選びスケールアップで対応するしかない  スケールアップは（オンプレでは）大変  IaaS使う場合はだいぶ楽になってきた  テナント毎にDBを分離できるよう設計しておく  テナントのデータは複数のDBのいずれかにあるという構成をとる 29

30. 見積れない性能要件テナント毎に分離例  テナントの増加に合わせて増強できるようにテナント管理DB テナントDB 1 アプリサーバーテナント管理DB テナントDB 1 アプリサーバーテナントDB 2 大規模なデータを持つ顧客向け対応や顧客毎のデータ分離の観点でも有利なアーキテクチャ 30

31. 想定外のヘビーユーザー性能系 2 31

32. 想定外のヘビーユーザー経験  上限値を設定せずにいたら無制限にデータが作られる  数回使われる程度で想定していた機能を想定の数百倍使われる  スキーマ不定データベースあるある  正規化せずに数百カラム作ったらサービスが重いんですが・・・！  前職でも現職でもあった 32

33. 想定外のヘビーユーザー課題  制限されていない機能は必ず想定を超えた利用をされる理想  想定を超える利用が制限されている対策  ニッチ機能であっても想定を超えた利用をされるので利用上限を設ける 33

34. 事前チューニング困難性能系 3 34

35. 事前チューニング困難経験  リリース前にパフォーマンス測定とチューニングを試みる  いくつか問題は見つかるが、不安が残る  パターンを洗い出そうとするがスキーマ・検索・集計が自由なサービスのため組み合わせ爆発して人知を超える（ので、あきらめる）  パフォーマンス問題を見て「そのパターンがあったか～」と、感心する 35

36. 事前チューニング困難課題  ボトルネックをリリース前に特定できない理想  ボトルネック発生時にチューニングのための情報がそろっている対策  事前対策はあきらめて発生時に素早く対応できる準備を整える 36

37. 事前チューニング困難事前チューニングはあきらめる  明らかな（想像できる）ユースケースだけを対応  あとは素早く対応できる準備を整える  顧客のスキーマやデータ量が分からないと何もできない  レスポンスタイムやクエリログの記録  スキーマの概要やデータ量を素早く取得するツール・手順を準備する 37

38. どこからお金をいただこう？サービスのありかた 1 38

39. どこからお金をいただこう？経験  作るサービスは決まった  お金のとり方は決まっていない  どの指標を使って課金する  ユーザー数？レコード数？通信料？利用時間？メール数？アクセス数？保存データ量？  サービスのリリースが近づきお金のとり方が決まったが  その指標を集計するのが大変だったり、無理だったり・・・ 39

40. どこからお金をいただこう？例えば 「その月のレコード数」に対して課金しよう  リアルタイム？その日の終わり？月末？  例えば100万件のデータの入れ替えをするときに作業順序で価格は変わる？  100万件登録→100万件削除  100万件削除→100万件登録 0 1000 2000 3000 4000 5000 1 6 11 16 21 26 レコード数 40

41. どこからお金をいただこう？課題  課金対象の指標が決まらない・取れない理想  課金対象の指標が取れる対策  指標をとるのにも開発が必要な場合があることを認識してサービス設計する 41

42. 個別カスタマイズサービスのありかた 2 42

43. 個別カスタマイズ経験 カスタマイズと称してクラウドサービスのコードに ○○社様対応フラグを入れる ある環境だけ謎のバッチが動いている 新機能追加時にカスタマイズの考慮もれ発生 43

44. 個別カスタマイズ課題  製品を特定顧客に特化した要望を入れるとコードが複雑化する理想  特定顧客のカスタマイズが製品をいびつにしない対策  APIや拡張ポイントを用意する 44

45. 個別カスタマイズ筋の悪い個別カスタマイズは避ける  サービスをスケールさせることができなくなる  安易にカスタマイズをすると自分たちに負債が返ってくる  筋の良いカスタマイズ機能を設計してサービスに組み込みましょう  API を提供する  拡張ポイントを用意する 45

46. 新機能 vs 利便性サービスのありかた 3 46

47. 新機能 vs 利便性経験  新機能開発に追われて、製品の使い勝手がずっと向上しない  しかし、その新機能の利用は伸びない  ちょっとしたUI改善だけで多くのお客様から喜びの声が上がる  しかし、改善のためのリソースは増えない 47

48. 新機能 vs 利便性課題  どちらを優先するか、常に対立がある理想  その時一番効果的な開発を選択できる対策  立場の弱いほうにも、最小限のリソースを割り当てておく 48

49. 新機能 vs 利便性新機能優先はしかたがない 多くの場合は分かりやすい機能搭載のほうが優先される 業務システムなので利便性の優先度はどうしても低くなる  課題を解決できることが重要なので良い気分で、楽々解決というのはその次 49

50. 新機能 vs 利便性けど弊害が大きい  開発側が自分たちでサービスを改善できると思わなくなり改善意欲が衰える  NOばかり言われるとやがて何も言わなくなる  利便性で解決できる問題が新機能の利用をブロッキングしていたりする  本当はデータ入力しにくいことが問題なのに連携サービスが必要という話になったり 50

51. 新機能 vs 利便性利便性改善のリソースは少しでも、必ず計画にのせるようにする  作った新機能だって必ず仮説を検証した後の修正が必要  とりあえず作ったがその後は放置の中途半端機能をドンドン搭載した覚えはありませんか？  リリースしてそこで開発終わりにできる機能なんてほとんどない 51

52. 無停止リリースリリース・運用系 1 52

53. 無停止リリース経験 無停止リリースを実現するためリリース手順の作成・検証に多くのリソースが割かれる 無停止リリースがうまくいかず障害扱いの停止が発生する 53

54. 無停止リリース課題  サービスを停めないと安定したリリースは難しい  サービスを停めると顧客の満足度は低下する理想  無停止かつ安定したリリース対策  効果を見極めてできるところから 54

55. 無停止リリースサービスを止めずにリリースするには 基本は歯を食いしばる道しかない  リハーサル環境を用意する  リリース手順の自動化  ブルーグリーンデプロイメント  DDL発行時にロックを最小化する  影響範囲・依存関係を丁寧に見ていく 55

56. 無停止リリースそのシステムは本当に止めてはいけないか？  リスクがあるなら交渉や調整をしよう  絶対大丈夫と言える？と言われて「はい」と言い切れない場合だってある  悩ましいときは顧客への価値を一番に考えよう  計画停止 vs 障害停止どっちがいい？ 56

57. 無停止リリースやるならいつから目指すか  ローンチ直後からサービスを無停止リリースを始めるのは大変  無停止リリースの準備にかかるコストと機能開発・安定化に割くコストの効果が逆転するまでは停止リリースがよい  リスクの大きなリリースは停止リリースする軽微な修正は無停止リリースするレベルごとにフローを分けるところから  停止リリースとアナウンスしつつ裏側では無停止リリースの経験を何度か積んで、安定してから無停止リリースを宣言しよう 57

58. 障害調査とセキュリティリリース・運用系 2 58

59. 障害調査とセキュリティ経験  障害調査に必要な情報が取れない  ログは運用の人しか見られない  顧客の機密情報がDBに入ってるから見られない・同意をとるのに時間がかかる  システムに詳しい人間が直接調査できない  コンソールルームやサーバーに開発メンバーが入れない  探索的な調査で部署間ピンポンが始まる 59

60. 障害調査とセキュリティ課題  迅速な障害調査がセキュリティ体制に阻害される理想  最適な人が必要な情報を取得する権限をもったうえで調査に携われる対策  障害対応のエースが運用サーバーに入れるようにする  機密情報をつぶして取得する仕組みを製品に入れる 60

61. 障害調査とセキュリティどうすればいいか  短期的には障害対応のエースが直接データを見れるよう手配するのが早い  もちろんきちんとトレーニングを受けさせるなどセキュリティの基準はクリアさせる  長期的には機密情報をつぶしたデータを取り出せる仕組みを製品に入れる  障害情報を取得する枠組みの整備をすすめると、対応速度も早まるし知識共有の素材に使いやすい 61

62. 障害調査とセキュリティ注意点 「DevOps!」と唱えて垣根を取り払ってしまうだけだと結構すぐに弊害が出てきてしまう  カウボーイが本番サーバーを触れるようにするのだけはやめよう 62

63. 継続的デリバリー vs 定期更新希望リリース・運用系 3 63

64. 継続的デリバリー vs 定期更新希望経験  リリースサイクルは速めたい  継続的デリバリー勉強会の輪講や他社事例を読んで機運を高める開発陣  それを望まない顧客がいる  UIを頻繁に変えられるとこちらの業務も変わってしまう  Nか月前には連絡してほしい 64

65. 継続的デリバリー vs 定期更新希望課題  どちらに倒しても、不満の声が上がる理想  どちらからも大きな不満が出ない対策  外から見えるリリースサイクルを変えられるようにしておく 65

66. 継続的デリバリー vs 定期更新希望どうするか  基本的にはそのときどきでサービスのスタンスを決めるしかない  今は新機能を次々打ち出すことが大事なのか  利用者を混乱させずに満足度を上げていくのが大事なのか  スタンスを決めずに顧客要望に振り回されるのが一番だめ 66

67. 継続的デリバリー vs 定期更新希望どうするか  開発は要求が低くても継続的デリバリーに取り組んでおく  外からみえるリリースサイクルを急に下げることはできても急に上げることはできない  テストチームに継続的デリバリーするだけでも品質は大きく変わる  体力が出てきたときに環境を分けて個別に安定環境を提供することができるかもしれない 67

68. パターンからふりかえり 68

69. パターンをだしてみて  クラウドサービスに限らない話  当たり前な話が多い  「今だと○○で解決できるよ」という話も多い  けれど、サービス開発は正しい道を最初から気づけなかったり選べなかったりすることだらけ  勉強不足や知識不足から最適なアーキテクチャを選択したか自信を持てない時も多々ある 69

70. 元上司のいい話昔、確信のもてない、批判意見もあるアーキテクチャ上の選択を行ったことがあります。その選択自体は大きなトラブルを起こすことがなかったがそれが正しい判断だったのかずっと気になっていました。 70

71. 元上司のいい話上司にポツリと言った時の返事「あとから分かった事実からベストはこうだったという事は誰にでもできること。我々は当時、自分たちの知りうる知識の範囲で最善と判断した選択をしたことは間違いないし実際それでうまくいった。なので、この件についてどのような批判があっても耳を貸す必要はない」 71

72. お伝えしたいこと クラウドサービスの開発・運用においても、当然銀の弾丸はない 問題を自分たちのコンテキストで解決していくしかない 72

73. 本日のアジェンダ お伝えしたいこと✅ 自己紹介✅ クラウドサービスの悩み✅ パターンと対策✅ まとめ👈 73

74. まとめ お伝えしたいこと  銀の弾丸はない  自分たちのコンテキストで解決していこう クラウドサービスの悩み  パターンと対策  クラウドに限らない話も多い 74

75. 以上

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

You are reading a preview.

Check these out next

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

More Related Content

Slideshows for you (20)

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

More from Ryo Mitoma (10)

Recently uploaded (20)