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