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

Transcript

1. 運用について 2020サマーインターンシップ Chatwork株式会社 開発本部 副本部長 兼フロントエンド開発部MGR 田中 佑樹
2. アジェンダ 1. SaaSシステムにおける運用とは？ 2. 運用を侮るなかれ 3. メトリクスとモニタリング 4. 緊急対応（オンコール対応） 5. セキュリティ 6. まとめ 2
3. 01 SaaSシステムにおける運用とは？
4. 01 SaaSシステムにおける運用とは？
5. SaaSとは？
6. SaaSとは？ Software as a Service • ソフトウェアをパッケージとして利用するのではなく、クラウド（インターネッ ト）経由で利用する形態のこと • ChatworkもSaaS 6
7. SaaSのメリット • 必要な分だけ利用する ◦ → コストが安く抑えられる • 需要の急増に対応しやすい • スポットでの利用もしやすい 7
8. SaaSのデメリット • SaaSシステムがダウンしていると、そのシステムを利用できなくなる ◦ → 自社業務がSaaS運営母体依存となってしまう • クラウド経由での利用となるため、ネットワークコストがかかる • セキュリティ上の懸念 8
9. 運用とは？
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 > システム運用（システムうんよう）はシステムがもつ機能を発揮させ用いること、 また継続的に発揮させるためにシステムを維持管理することである
11. SaaSにとって運用は生命線 • SaaSの特性上、1つのシステムを長期間に渡って安定稼働させることが至上命題 • 長期間にわたって安定稼働させるために重要なことはなにか？ ◦ いろいろある ◦ いろいろあるが、その1つが運用設計 11
12. • 抽象的にいうと ◦ Check <-> Do の仕組みづくり • 具体的にいうと ◦ 監視システム設計（Checkの仕組み） ◦ 運用体制の確立（Doの仕組み） 運用設計でやること 12
13. • 問題が発生している（あるいは発生しそうな）ことを検知できず、なにもせずに 「システムがとまりました！」じゃ済まされない • 稼働中のシステムに問題がないか？を検知する仕組み ◦ → システム監視、モニタリング、メトリクス 監視システム設計 13
14. • 運用メンバー選定 ◦ ボランティア運用は必ず破綻する ▪ 役割の明確化とそのインセンティブ設計が非常に重要 • 発生しうる運用業務のリストアップ • それらの運用業務フローの設計 ◦ 障害対応手順フロー確立 ◦ マニュアル / ドキュメンテーションの整備 ◦ etc... 運用体制の確立 14
15. • 使用している各種ライブラリの定期的な棚卸し、バージョンアップデートの定型化 • 使用している外部システムの棚卸しの定型化 • アカウントの棚卸しの定型化 • etc... ほかにもあるよ！運用設計でやること 15
16. • 運用設計をもとにした運用業務が日々ついてまわる ◦ → システムが増えれば増えるほど、運用業務は重くのしかかってくる 運用業務 16
17. • 組織体制の代表的なものとして、機能別組織と機能横断型組織がある • 機能別組織 ◦ 能力で別れている ▪ サーバーサイド部 ▪ フロントエンド部 ▪ プロダクトマネジメント部 ▪ ・・・ • 機能横断型組織 ◦ ある目的をもった、職能・職種を横断して結成したチーム ▪ APIチーム ▪ 管理画面チーム ▪ ・・・ Appendix. 機能別組織と機能横断型組織 17
18. Appendix. 機能別組織と機能横断型組織 機能別組織のメリット • 特定の技能に関する専門性が高めやすい • 運用に必要な技術をチーム内で確立しやす い 18 機能別組織のデメリット • 複数システムを運用している場合、 1チームでの運用対象のシステムが多く なってしまう → 運用コスト増 • 複数のシステムを1チームで運用すること で、責任の所在が不明確になりやすい
19. Appendix. 機能別組織と機能横断型組織 機能横断型組織のメリット • システムごとにチームが紐付いているた め、開発と運用がセットで考えられやすい （DevOps） 19 機能横断型組織のデメリット • チームごとの垣根は高くなり、知識の共有 がしにくくなる • 各チームで車輪の再発明が行われやすい
20. • Chatworkは現在、機能別組織の体制 ◦ これは、アーキテクチャ上の背景や歴史的背景が要因 • 現在、運用観点、あるいはオーナーシップをもったPM＆Dev共同のチームを作り上 げるために機能横断型組織を目指している Appendix. 機能別組織と機能横断型組織 20 機能別組織 / 機能横断型組織について、 くわしくはこちらの本をチェック！ https://www.amazon.co.jp/dp/B079TLW41L/r ef=dp-kindle-redirect?_encoding=UTF8&btkr =1
21. 02 運用を侮るなかれ
22. • 「運用」は軽視されがちな気がする ◦ これはきっと「運用」というもの自体に技術的な面白みがなく、それよりも 「機能開発」に注力したくなるエンジニアの性ではないでしょうか （※個人の感想です） 運用を侮るなかれ 22
23. • 「運用」というものどう取り扱うかより、 「運用」というものをなるべく発生させないことに注目が置かれやすい （これはこれで正しい） • ただし、この考えが行き過ぎると、 だれも「運用」ということに向き合わない組織ができてしまう 運用を侮るなかれ 23
24. よくあること
25. • 運用業務が重くなってくる・・・ • → 自動化しよう！ よくあること 25
26. • → 自動化が進む・・・ • → ピタゴラスイッチシステムが出来上がる よくあること 26
27. • → ピタゴラスイッチシステムが突然動かなくなる • → ピタゴラスイッチシステムがどう稼働していたのかわからない・・・ よくあること 27
28. εε=ヽ(　`Д´)ﾉ ｳﾜｧｧｧﾝ
29. 結局、運用が必要 29 • ピタゴラスイッチシステム自体もシステムになるので、 このシステム自体の「運用」も考える必要がある • 「運用」を軽くしようとしたはずなのに、 結局また「運用」が必要になってくる・・・
30. 我々は運用から逃れることはできない 結論
31. ・・・ということで、運用というものは必ずついてまわる話になります。 例にあげたものは一例ですが、それでも全てを自動化というのは夢のまた夢、 ドラ◦もんが叶えてくれるまで待ちましょう。 （※個人の感想です） 結局、運用が必要 31
32. 現状、技術力を伸ばしたいと思ってる人が多いと思いますが、 それと同じくらい、もしかしたらそれ以上に 「運用設計力」 というものは必要になってきます。 （※個人の感想です） エンジニアとして必要なスキルとは？ 32
33. 運用設計力とはなにか？
34. よくわからない
35. よくわからないが経験上、おそらく下記のような能力。 • 状況分析力、課題設定力 • 現実的な業務フローの設計力 • 業務フロー図の作成（PlantUMLなど）等のドキュメンテーション力 • 定義した業務フローを現場に落とし込む説得力、政治力、プレゼン力 ならべると、基本的なビジネススキルっぽい。 運用設計力？ 35
36. おそらく、この中にも 「エンジニアとして生きていくには、技術力さえ上げていればいい」 と考えている人はいるのではないでしょうか？ エンジニアとして必要なスキルとは？ 36
37. しかし、現実そんなに甘くはない
38. もちろん、先述したようなことをやらない働き方もあるかと思います。 ただ、伝えたいこととしては、先述のような運用まわりのことを しっかりできるエンジニアは非常に重宝されます。 （※個人の感想です） エンジニアとして必要なスキルとは？ 38
39. 03 メトリクスとモニタリング
40. メトリクスとモニタリングはなぜ重要か？ 何が起こっているのか、問題が発生していないか把握するため。 40
41. メトリクスとモニタリングはなぜ重要か？ 何が起こっているか、何もわからない世界線 41 ユーザー 「サーバー落ちてる！」 「クソアプリやん！」 「なにも問題ないな！」 「ヨシ！」 エンジニア
42. メトリクスとモニタリングはなぜ重要か？ 要するに、状況把握のためのツール。 状況把握ができれば課題発見につながり、 課題発見ができればやるべきアクションは自ずと見えてくる。 42
43. Chatworkの事例
44. Datadog 外部監視サービスの1つ • AWSとのIntegrationがしやすく、ダッシュボードをかんたんに作れるのが特徴。 Dashboard例 https://p.datadoghq.com/sb/df22702ab-290bf9e3fb 44
45. Datadog 45
46. NewRelic 外部監視サービスの1つ • Datadogとかぶる部分は多い • Datadogのほうが細かく設定してダッシュボードを作れるのと、AWSともシームレ スな連携が可能 • NewRelicは何もしなくてもある程度のメトリクスが俯瞰できる • いろいろカスタマイズしたい！ → Datadog • なにも考えたくない！ → NewRelic Chatworkはどちらも使ってます 46
47. NewRelic Webサーバーメトリクス 47
48. NewRelic Browserメトリクス 48
49. PagerDuty オンコール対応のためのツール • 各種ツールと連携し、エラーレートが高まったら 決まった人に電話がかかる悪魔のようなシステム • Chatworkではオンコール当番をローテーションしていて、 24時間365日すぐ対応できるようにしている 49
50. BigQuery アプリログ保管場所 • TB、PB級のログを即座に解析できる • 状況調査のときにBigQueryを用いてログ解析、 エラー等の特定イベントの調査をする • Google App Scriptを用いて定期的にBigQueryから エラーログを抽出し、Chatwork上に通知している 50
51. 04 緊急対応（オンコール対応）
52. Chatworkでは先述のようなモニタリングの仕組みを用いて、 24/365 の監視体制を敷いている。 24/365で運用しなければいけないSaaSシステムにおいて、 また重要になってくるのが緊急対応です。 緊急対応（オンコール対応） 52
53. その時は突然やってきます。 社内ユーザーからの報告や、監視ツールのアラート通知など、さまざまな角度から 報告が上がってきます。 たいへんだ！Chatworkが危ない！ 53
54. サービスダウンするとどうなるか？
55. Twitterで「帰る」という報告が来る もう、仕事できないので帰りますね 今日は帰るしかないですね・・・ 55
56. Yahooトレンドにのる 56 • ダウンタイム15分程で3位 • 緊急地震速報より上
57. RocketNewsに載る https://rocketnews24.com/2016/11/21/838345/ 57
58. Chatworkの障害対応フロー
59. • ざっくり ◦ 異常事態に気づいたら報告 ◦ 障害対応チームがビデオ会議にてコミュニケーションを取る ▪ コミュニケーションリーダーを決める ◦ 開発 ▪ 復旧に向けた調査＆アクション ◦ ビジネスサイド（PM & サポート & 広報） ▪ ユーザーコミュニケーション方法の決定、実施 ◦ コミュニケーションリーダー ▪ 復旧の状況をヒアリング、ビジネスサイドへの報告 ▪ その他もろもろのファシリテート Chatworkの障害対応フロー 59
60. • 障害が落ち着いたら ◦ 臨時のChatworkのグループチャットを作成 ◦ そのグループチャットで障害に関するコミュニケーション、再発防止策につい ての議論 Chatworkの障害対応フロー 60
61. 05 セキュリティ
62. セキュリティ対策の重要性 • 昨今、セキュリティに関する関心が非常に高まっている • 背景 ◦ 高度化するサイバー手口 ◦ 多数の情報漏えい等のセキュリティインシデントの事例 62
63. セキュリティインシデント事例 Coincheck事件 • 2018年1月26日、仮想通貨取引所「Coincheck」が 外部からのハッキング攻撃を受ける • 580億円相当の仮想通貨「NEM（ネム）」が盗難された • 事件後はマネックス傘下で経営再建 63
64. セキュリティインシデント事例 7pay事件 • サービスローンチ3日目に不正利用が発生 • 他ユーザーになりすまし決済ができてしまう、 致命的なセキュリティホールがあった • ローンチからわずか2ヶ月後にサービス停止を発表 64
65. セキュリティインシデント事例 これらは対岸の火事ではない。 当然どんな企業にだってありえる話、もちろんChatworkも例外ではない。 65
66. • セキュリティインシデントは起こったら一発アウト ◦ リスク管理の一環として定期的なセキュリティリスクの棚卸しをするべき セキュリティ運用 66
67. セキュリティの運用とは？ • 抽象的にいうと ◦ Check <-> Do の仕組みづくり • 具体的にいうと ◦ リスク管理（Checkの仕組み） ◦ リスクに対するアクション（Doの仕組み） セキュリティ運用 67
68. リスク管理 • 脆弱性診断 ◦ 定期的なセキュリティスキャンの実施 • 脆弱性情報の収集 • 権限棚卸し ◦ システムのアカウント等の権限を定期的にチェック ◦ 不必要なアカウントがないか、権限がないか ◦ 退職者などの権限はすべて削除されているか • etc... セキュリティ運用 68
69. リスクに対するアクション • セキュリティホールに対するプログラム修正 • 開発フローの標準化 • これらを専任に対応するチームの設立 • etc…本当に色々 セキュリティ運用 69
70. Chatworkにおけるセキュリティ対策
71. Chatworkにおけるセキュリティ対策 最近、ようやくセキュリティチームを立ち上げた 今まで • なにかあったら後追いで穴を塞ぐ対応 • 攻めのセキュリティ対策ができていなかった これから（予定） • リスク管理、それに対するアクションを回す ◦ 定期的なセキュリティスキャン ◦ セキュリティコンサルとの定例 71
72. Chatworkにおけるセキュリティ対策 BugBounty運用 • BugBountyとは？ > 「脆弱性報奨金制度」や「バグ報奨金制度」と呼ばれています。公開しているプログ ラムにバグがあることを想定して報奨金をかけて公開し、一般人（ホワイトハッカー） がバグを発見して脆弱性を報告して報奨金を受け取るという制度になっています。 72 引用）https://cybersecurity-jp.com/column/27759
73. Chatworkにおけるセキュリティ対策 BugBounty.jpというサービスに登録 • 月だいたい30件程度の報告があり • その中で、だいたい1~2件を脆弱性として認定し、報奨金を与えている • ほとんどが海外からの報告、英語でのやり取り 73
74. Chatworkにおけるセキュリティ対策 開発フロー標準化（予定） • ログ出力指針の策定 • データの取扱についての指針を策定 ◦ データ暗号化指針 ◦ ハッシュアルゴリズムのルール決め ◦ etc… 74
75. 06 まとめ
76. 運用重要だよ • 運用の重要な要素の一つとして、システム監視と緊急対応について紹介したよ • Chatworkがやってることとして、セキュリティの運用を紹介したよ まとめ 76
77. まとめ これらの運用は非常に重たい、本当に重たい。 きっと積極的にやりたい人はいないはず。 いないけど、経営として非常に重要。 経営としてこの重要性をみんなに理解を得て、みんなでやっていくという姿勢が大事。 ボランティア運用はかならず破綻する（大切なことなので2回いいました） 77
78. 働くをもっと楽しく、創造的に