運用について - 2020 Chatwork サマーインターンシップ

Transcript

1. 運用について
   2020サマーインターンシップ
   Chatwork株式会社
   開発本部 副本部長 兼フロントエンド開発部MGR
   田中 佑樹
   

   View Slide

2. アジェンダ
   1. SaaSシステムにおける運用とは？
   2. 運用を侮るなかれ
   3. メトリクスとモニタリング
   4. 緊急対応（オンコール対応）
   5. セキュリティ
   6. まとめ
   2
   

   View Slide

3. 01
   SaaSシステムにおける運用とは？
   

   View Slide

4. 01
   SaaSシステムにおける運用とは？
   

   View Slide

5. SaaSとは？
   

   View Slide

6. SaaSとは？
   Software as a Service
   ● ソフトウェアをパッケージとして利用するのではなく、クラウド（インターネッ
   ト）経由で利用する形態のこと
   ● ChatworkもSaaS
   6
   

   View Slide

7. SaaSのメリット
   ● 必要な分だけ利用する
   ○ → コストが安く抑えられる
   ● 需要の急増に対応しやすい
   ● スポットでの利用もしやすい
   7
   

   View Slide

8. SaaSのデメリット
   ● SaaSシステムがダウンしていると、そのシステムを利用できなくなる
   ○ → 自社業務がSaaS運営母体依存となってしまう
   ● クラウド経由での利用となるため、ネットワークコストがかかる
   ● セキュリティ上の懸念
   8
   

   View Slide

9. 運用とは？
   

   View Slide

10. 運用とは？
    10
    引用）
    https://ja.wikipedia.org/wiki/%E3%82%B7%E3%82%B9%E
    3%83%86%E3%83%A0%E9%81%8B%E7%94%A8
    > システム運用（システムうんよう）はシステムがもつ機能を発揮させ用いること、
    また継続的に発揮させるためにシステムを維持管理することである
    

    View Slide

11. SaaSにとって運用は生命線
    ● SaaSの特性上、1つのシステムを長期間に渡って安定稼働させることが至上命題
    ● 長期間にわたって安定稼働させるために重要なことはなにか？
    ○ いろいろある
    ○ いろいろあるが、その1つが運用設計
    11
    

    View Slide

12. ● 抽象的にいうと
    ○ Check <-> Do の仕組みづくり
    ● 具体的にいうと
    ○ 監視システム設計（Checkの仕組み）
    ○ 運用体制の確立（Doの仕組み）
    運用設計でやること
    12
    

    View Slide

13. ● 問題が発生している（あるいは発生しそうな）ことを検知できず、なにもせずに
    「システムがとまりました！」じゃ済まされない
    ● 稼働中のシステムに問題がないか？を検知する仕組み
    ○ → システム監視、モニタリング、メトリクス
    監視システム設計
    13
    

    View Slide

14. ● 運用メンバー選定
    ○ ボランティア運用は必ず破綻する
    ■ 役割の明確化とそのインセンティブ設計が非常に重要
    ● 発生しうる運用業務のリストアップ
    ● それらの運用業務フローの設計
    ○ 障害対応手順フロー確立
    ○ マニュアル / ドキュメンテーションの整備
    ○ etc...
    運用体制の確立
    14
    

    View Slide

15. ● 使用している各種ライブラリの定期的な棚卸し、バージョンアップデートの定型化
    ● 使用している外部システムの棚卸しの定型化
    ● アカウントの棚卸しの定型化
    ● etc...
    ほかにもあるよ！運用設計でやること
    15
    

    View Slide

16. ● 運用設計をもとにした運用業務が日々ついてまわる
    ○ → システムが増えれば増えるほど、運用業務は重くのしかかってくる
    運用業務
    16
    

    View Slide

17. ● 組織体制の代表的なものとして、機能別組織と機能横断型組織がある
    ● 機能別組織
    ○ 能力で別れている
    ■ サーバーサイド部
    ■ フロントエンド部
    ■ プロダクトマネジメント部
    ■ ・・・
    ● 機能横断型組織
    ○ ある目的をもった、職能・職種を横断して結成したチーム
    ■ APIチーム
    ■ 管理画面チーム
    ■ ・・・
    Appendix. 機能別組織と機能横断型組織
    17
    

    View Slide

18. Appendix. 機能別組織と機能横断型組織
    機能別組織のメリット
    ● 特定の技能に関する専門性が高めやすい
    ● 運用に必要な技術をチーム内で確立しやす
    い
    18
    機能別組織のデメリット
    ● 複数システムを運用している場合、
    1チームでの運用対象のシステムが多く
    なってしまう → 運用コスト増
    ● 複数のシステムを1チームで運用すること
    で、責任の所在が不明確になりやすい
    

    View Slide

19. Appendix. 機能別組織と機能横断型組織
    機能横断型組織のメリット
    ● システムごとにチームが紐付いているた
    め、開発と運用がセットで考えられやすい
    （DevOps）
    19
    機能横断型組織のデメリット
    ● チームごとの垣根は高くなり、知識の共有
    がしにくくなる
    ● 各チームで車輪の再発明が行われやすい
    

    View Slide

20. ● Chatworkは現在、機能別組織の体制
    ○ これは、アーキテクチャ上の背景や歴史的背景が要因
    ● 現在、運用観点、あるいはオーナーシップをもったPM＆Dev共同のチームを作り上
    げるために機能横断型組織を目指している
    Appendix. 機能別組織と機能横断型組織
    20
    機能別組織 / 機能横断型組織について、
    くわしくはこちらの本をチェック！
    https://www.amazon.co.jp/dp/B079TLW41L/r
    ef=dp-kindle-redirect?_encoding=UTF8&btkr
    =1
    

    View Slide

21. 02
    運用を侮るなかれ
    

    View Slide

22. ● 「運用」は軽視されがちな気がする
    ○ これはきっと「運用」というもの自体に技術的な面白みがなく、それよりも
    「機能開発」に注力したくなるエンジニアの性ではないでしょうか
    （※個人の感想です）
    運用を侮るなかれ
    22
    

    View Slide

23. ● 「運用」というものどう取り扱うかより、
    「運用」というものをなるべく発生させないことに注目が置かれやすい
    （これはこれで正しい）
    ● ただし、この考えが行き過ぎると、
    だれも「運用」ということに向き合わない組織ができてしまう
    運用を侮るなかれ
    23
    

    View Slide

24. よくあること
    

    View Slide

25. ● 運用業務が重くなってくる・・・
    ● → 自動化しよう！
    よくあること
    25
    

    View Slide

26. ● → 自動化が進む・・・
    ● → ピタゴラスイッチシステムが出来上がる
    よくあること
    26
    

    View Slide

27. ● → ピタゴラスイッチシステムが突然動かなくなる
    ● → ピタゴラスイッチシステムがどう稼働していたのかわからない・・・
    よくあること
    27
    

    View Slide

28. εε=ヽ(　`Д´)ﾉ ｳﾜｧｧｧﾝ
    

    View Slide

29. 結局、運用が必要
    29
    ● ピタゴラスイッチシステム自体もシステムになるので、
    このシステム自体の「運用」も考える必要がある
    ● 「運用」を軽くしようとしたはずなのに、
    結局また「運用」が必要になってくる・・・
    

    View Slide

30. 我々は運用から逃れることはできない
    結論
    

    View Slide

31. ・・・ということで、運用というものは必ずついてまわる話になります。
    例にあげたものは一例ですが、それでも全てを自動化というのは夢のまた夢、
    ドラ○もんが叶えてくれるまで待ちましょう。
    （※個人の感想です）
    結局、運用が必要
    31
    

    View Slide

32. 現状、技術力を伸ばしたいと思ってる人が多いと思いますが、
    それと同じくらい、もしかしたらそれ以上に
    「運用設計力」
    というものは必要になってきます。
    （※個人の感想です）
    エンジニアとして必要なスキルとは？
    32
    

    View Slide

33. 運用設計力とはなにか？
    

    View Slide

34. よくわからない
    

    View Slide

35. よくわからないが経験上、おそらく下記のような能力。
    ● 状況分析力、課題設定力
    ● 現実的な業務フローの設計力
    ● 業務フロー図の作成（PlantUMLなど）等のドキュメンテーション力
    ● 定義した業務フローを現場に落とし込む説得力、政治力、プレゼン力
    ならべると、基本的なビジネススキルっぽい。
    運用設計力？
    35
    

    View Slide

36. おそらく、この中にも
    「エンジニアとして生きていくには、技術力さえ上げていればいい」
    と考えている人はいるのではないでしょうか？
    エンジニアとして必要なスキルとは？
    36
    

    View Slide

37. しかし、現実そんなに甘くはない
    

    View Slide

38. もちろん、先述したようなことをやらない働き方もあるかと思います。
    ただ、伝えたいこととしては、先述のような運用まわりのことを
    しっかりできるエンジニアは非常に重宝されます。
    （※個人の感想です）
    エンジニアとして必要なスキルとは？
    38
    

    View Slide

39. 03
    メトリクスとモニタリング
    

    View Slide

40. メトリクスとモニタリングはなぜ重要か？
    何が起こっているのか、問題が発生していないか把握するため。
    40
    

    View Slide

41. メトリクスとモニタリングはなぜ重要か？
    何が起こっているか、何もわからない世界線
    41
    ユーザー
    「サーバー落ちてる！」
    「クソアプリやん！」
    「なにも問題ないな！」
    「ヨシ！」
    エンジニア
    

    View Slide

42. メトリクスとモニタリングはなぜ重要か？
    要するに、状況把握のためのツール。
    状況把握ができれば課題発見につながり、
    課題発見ができればやるべきアクションは自ずと見えてくる。
    42
    

    View Slide

43. Chatworkの事例
    

    View Slide

44. Datadog
    外部監視サービスの1つ
    ● AWSとのIntegrationがしやすく、ダッシュボードをかんたんに作れるのが特徴。
    Dashboard例
    https://p.datadoghq.com/sb/df22702ab-290bf9e3fb
    44
    

    View Slide

45. Datadog
    45
    

    View Slide

46. NewRelic
    外部監視サービスの1つ
    ● Datadogとかぶる部分は多い
    ● Datadogのほうが細かく設定してダッシュボードを作れるのと、AWSともシームレ
    スな連携が可能
    ● NewRelicは何もしなくてもある程度のメトリクスが俯瞰できる
    ● いろいろカスタマイズしたい！ → Datadog
    ● なにも考えたくない！ → NewRelic
    Chatworkはどちらも使ってます
    46
    

    View Slide

47. NewRelic
    Webサーバーメトリクス
    47
    

    View Slide

48. NewRelic
    Browserメトリクス
    48
    

    View Slide

49. PagerDuty
    オンコール対応のためのツール
    ● 各種ツールと連携し、エラーレートが高まったら
    決まった人に電話がかかる悪魔のようなシステム
    ● Chatworkではオンコール当番をローテーションしていて、
    24時間365日すぐ対応できるようにしている
    49
    

    View Slide

50. BigQuery
    アプリログ保管場所
    ● TB、PB級のログを即座に解析できる
    ● 状況調査のときにBigQueryを用いてログ解析、
    エラー等の特定イベントの調査をする
    ● Google App Scriptを用いて定期的にBigQueryから
    エラーログを抽出し、Chatwork上に通知している
    50
    

    View Slide

51. 04
    緊急対応（オンコール対応）
    

    View Slide

52. Chatworkでは先述のようなモニタリングの仕組みを用いて、
    24/365 の監視体制を敷いている。
    24/365で運用しなければいけないSaaSシステムにおいて、
    また重要になってくるのが緊急対応です。
    緊急対応（オンコール対応）
    52
    

    View Slide

53. その時は突然やってきます。
    社内ユーザーからの報告や、監視ツールのアラート通知など、さまざまな角度から
    報告が上がってきます。
    たいへんだ！Chatworkが危ない！
    53
    

    View Slide

54. サービスダウンするとどうなるか？
    

    View Slide

55. Twitterで「帰る」という報告が来る
    もう、仕事できないので帰りますね
    今日は帰るしかないですね・・・
    55
    

    View Slide

56. Yahooトレンドにのる
    56
    ● ダウンタイム15分程で3位
    ● 緊急地震速報より上
    

    View Slide

57. RocketNewsに載る
    https://rocketnews24.com/2016/11/21/838345/
    57
    

    View Slide

58. Chatworkの障害対応フロー
    

    View Slide

59. ● ざっくり
    ○ 異常事態に気づいたら報告
    ○ 障害対応チームがビデオ会議にてコミュニケーションを取る
    ■ コミュニケーションリーダーを決める
    ○ 開発
    ■ 復旧に向けた調査＆アクション
    ○ ビジネスサイド（PM & サポート & 広報）
    ■ ユーザーコミュニケーション方法の決定、実施
    ○ コミュニケーションリーダー
    ■ 復旧の状況をヒアリング、ビジネスサイドへの報告
    ■ その他もろもろのファシリテート
    Chatworkの障害対応フロー
    59
    

    View Slide

60. ● 障害が落ち着いたら
    ○ 臨時のChatworkのグループチャットを作成
    ○ そのグループチャットで障害に関するコミュニケーション、再発防止策につい
    ての議論
    Chatworkの障害対応フロー
    60
    

    View Slide

61. 05
    セキュリティ
    

    View Slide

62. セキュリティ対策の重要性
    ● 昨今、セキュリティに関する関心が非常に高まっている
    ● 背景
    ○ 高度化するサイバー手口
    ○ 多数の情報漏えい等のセキュリティインシデントの事例
    62
    

    View Slide

63. セキュリティインシデント事例
    Coincheck事件
    ● 2018年1月26日、仮想通貨取引所「Coincheck」が
    外部からのハッキング攻撃を受ける
    ● 580億円相当の仮想通貨「NEM（ネム）」が盗難された
    ● 事件後はマネックス傘下で経営再建
    63
    

    View Slide

64. セキュリティインシデント事例
    7pay事件
    ● サービスローンチ3日目に不正利用が発生
    ● 他ユーザーになりすまし決済ができてしまう、
    致命的なセキュリティホールがあった
    ● ローンチからわずか2ヶ月後にサービス停止を発表
    64
    

    View Slide

65. セキュリティインシデント事例
    これらは対岸の火事ではない。
    当然どんな企業にだってありえる話、もちろんChatworkも例外ではない。
    65
    

    View Slide

66. ● セキュリティインシデントは起こったら一発アウト
    ○ リスク管理の一環として定期的なセキュリティリスクの棚卸しをするべき
    セキュリティ運用
    66
    

    View Slide

67. セキュリティの運用とは？
    ● 抽象的にいうと
    ○ Check <-> Do の仕組みづくり
    ● 具体的にいうと
    ○ リスク管理（Checkの仕組み）
    ○ リスクに対するアクション（Doの仕組み）
    セキュリティ運用
    67
    

    View Slide

68. リスク管理
    ● 脆弱性診断
    ○ 定期的なセキュリティスキャンの実施
    ● 脆弱性情報の収集
    ● 権限棚卸し
    ○ システムのアカウント等の権限を定期的にチェック
    ○ 不必要なアカウントがないか、権限がないか
    ○ 退職者などの権限はすべて削除されているか
    ● etc...
    セキュリティ運用
    68
    

    View Slide

69. リスクに対するアクション
    ● セキュリティホールに対するプログラム修正
    ● 開発フローの標準化
    ● これらを専任に対応するチームの設立
    ● etc…本当に色々
    セキュリティ運用
    69
    

    View Slide

70. Chatworkにおけるセキュリティ対策
    

    View Slide

71. Chatworkにおけるセキュリティ対策
    最近、ようやくセキュリティチームを立ち上げた
    今まで
    ● なにかあったら後追いで穴を塞ぐ対応
    ● 攻めのセキュリティ対策ができていなかった
    これから（予定）
    ● リスク管理、それに対するアクションを回す
    ○ 定期的なセキュリティスキャン
    ○ セキュリティコンサルとの定例
    71
    

    View Slide

72. Chatworkにおけるセキュリティ対策
    BugBounty運用
    ● BugBountyとは？
    > 「脆弱性報奨金制度」や「バグ報奨金制度」と呼ばれています。公開しているプログ
    ラムにバグがあることを想定して報奨金をかけて公開し、一般人（ホワイトハッカー）
    がバグを発見して脆弱性を報告して報奨金を受け取るという制度になっています。
    72
    引用）https://cybersecurity-jp.com/column/27759
    

    View Slide

73. Chatworkにおけるセキュリティ対策
    BugBounty.jpというサービスに登録
    ● 月だいたい30件程度の報告があり
    ● その中で、だいたい1~2件を脆弱性として認定し、報奨金を与えている
    ● ほとんどが海外からの報告、英語でのやり取り
    73
    

    View Slide

74. Chatworkにおけるセキュリティ対策
    開発フロー標準化（予定）
    ● ログ出力指針の策定
    ● データの取扱についての指針を策定
    ○ データ暗号化指針
    ○ ハッシュアルゴリズムのルール決め
    ○ etc…
    74
    

    View Slide

75. 06
    まとめ
    

    View Slide

76. 運用重要だよ
    ● 運用の重要な要素の一つとして、システム監視と緊急対応について紹介したよ
    ● Chatworkがやってることとして、セキュリティの運用を紹介したよ
    まとめ
    76
    

    View Slide

77. まとめ
    これらの運用は非常に重たい、本当に重たい。
    きっと積極的にやりたい人はいないはず。
    いないけど、経営として非常に重要。
    経営としてこの重要性をみんなに理解を得て、みんなでやっていくという姿勢が大事。
    ボランティア運用はかならず破綻する（大切なことなので2回いいました）
    77
    

    View Slide

78. 働くをもっと楽しく、創造的に
    

    View Slide