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