障害を防ぎ、サービスを守るために #gotandapm

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.
障害を防ぎ、
サービスを守るために
Gotanda.pm #6
Sep. 17, 2015
Kiyoshi Yasutake
DeNA Co., Ltd.

自己紹介
 安武貴世志
 @key_amb (きいあむ)
 DeNA でインフラやってます。
 日々、障害/アラートと戦ってい
ます。
 DeNA 歴 7年弱
⁃ 1年目 => EC 開発
⁃ 2〜3年目 => ソシャゲ開発
⁃ 4年目〜 => インフラ
2

障害について
3

「障害は起こる」
by @papix
4

大事なこと(今日のアジェンダ)
 障害が起こる可能性を減らす
 起こり得る障害の影響を最小化する
 障害が起こったら、最速で収束させる
 同じ障害を繰り返さない
5

そもそも、障害とは
 辞書的な意味:「あることをするのに妨げとなるものや状況」
=> 「サービスが正常に利用できない状況」
 サービス利用者に不利益のある状況も障害となり得る
⁃ 例) ガチャの確率設定のミスでレアアイテムが出づらい状態だった
6

これは障害ではない
 サーバ故障 => エンドユーザに影響が出ていなければ障害ではない
 LOAD や CPU などのアラート => 同上
 監視漏れ … 障害に気づかないような監視漏れは無視できない
 コードが汚い … (実害がないので後回しにされがち)
7

本編
8

障害が起こる
可能性を減らす
9

障害が起こる可能性を減らす
 クラスタ化・冗長化
 負荷・エラーのモニタリング
 負荷・トラフィックの予測と見積り
 作業ミスを防ぐ
 テスト
⁃ 継続的インテグレーション
 レビュー
⁃ 開発 … 設計、実装(コーディング)
⁃ 運用
10
今日話すのは主にこの２つ

クラスタ化・冗長化
 SPOF をなくす(減らす)
⁃ クラスタ化する
• LB, レプリケーション, 分散システム, etc.
⁃ SPOF のない製品を選ぶ
• Mroonga => Elasticsearch
• RDB => NoSQL
 N+1, N+2, 2N
⁃ N … サービス提供に必要な台数
⁃ N+M … M が予備台数
• 基本は N+1 だが、稀に N+2 にすることもある
⁃ 例) 最小構成でも web は 3台にする
• 2N … DR (Disaster Recovery) 構成
11

負荷・エラーのモニタリング
 障害を未然に or 水際で食い止める
 Haikanko … エラー監視, ログ可視化
⁃ https://github.com/sonots/haikanko
⁃ Web UI から Fluentd クラスタを構築して、任
意のホストの任意のログを監視するツール
12
agent
agent
agentworker serializer
Yohoushi
Mail
IRC
図: Haikanko – Fluentd クラスタ略図

Haikanko + Yohoushi によるログ可視化
 Yohoushi
⁃ https://github.com/yohoushi/yohoushi
⁃ Haikanko の Web UI で設定を書いてメトリクスを取れる
13

負荷・エラーのモニタリング
 他に…
⁃ Nagios, CloudForecast
⁃ DB/Web KPI 収集ツール
• daemon で性能指標を DB に突っ込む
• JAWS-UG Meguro #1 で少し触れました
 チームでやっていること
⁃ 週次の定点観測
• 傾向や異常値を確認して、必要に応じて調査や負荷対策を行う
14

起こり得る障害の
影響を最小化する
15

起こり得る障害の影響を最小化する
 冗長化時に、同じコンポーネントをばらばらの母艦やラック、AZに配置
する
 冗長化できないところをどうするか
⁃ DB Master=> MHA … ダウンタイムを最小化
 フェールセーフにしておく(安全弁を設ける)
⁃ 例) KVS が落ちても DB にフォールバックさせる
 Disaster Recovery
⁃ データセンターも絶対ではない
 AWS でも障害はある
⁃ インスタンス, EBS, 母艦障害
⁃ AWS 自体の障害
16

Memcached の複数プロセス化
 ※実施時期は2012〜2013年ごろ
 Before
⁃ 1サーバに Memcached 1プロセス
⁃ 問題点 … 1台が落ちた時の影響が大きい
• 1プロセスのメモリ割当てが大きいので
 After
⁃ 1サーバに Memcached 複数プロセス
• 複数クラスタのプロセスを1サーバに同居させる
⁃ 1プロセスあたりのメモリ割当て(=データ格納量)を小さく
⁃ クラスタ全体としての Memcached プロセス数を増やす
=> 1台が落ちたときの影響を減らす
⁃ おまけ: リソース効率がよくなった
17

Memcached の複数プロセス化
18
memd
memd
サーバ
クラスタA
クラスタB
memd
memd
memd
memd
クラスタB
クラスタB
クラスタA
クラスタA

障害が起こったら
最速で収束させる
19

障害が起こったら、最速で収束させる
 検知
⁃ 監視 => 異常通知(Mail, Slack, Tel)
 一次対応
⁃ 例) 異常のあったノードをサービスアウト, エラーの早期復旧
 その後 => 同じ障害を繰り返さない
20

PagerDuty
 https://www.pagerduty.com/
 Fatal => 架電
⁃ アラートと同時に担当者を起こす
 PagerDuty へのアラート送信
⁃ Nagios
⁃ Haikanko
⁃ アラートメール時にBccでPagerDutyにメール
 API を利用して週次で担当者をローテーション
21

check_slave (DeNA 内製デーモン)
 概要
⁃ MyDNS 環境用の死活監視 + 自動サービスイン/アウトツール
⁃ 元は DB Slave 用だったようだ => 名前の由来
⁃ 今は DB 以外も監視対象
⁃ 中身はゴリゴリ Perl で書いてます。
 何ができるか
⁃ 落ちたときに自動でサービスアウト
⁃ 復帰したときに自動でサービスイン
⁃ MyDNS エントリに対して LB や HAProxy 相当のことができる
⁃ 検知と一次対応が同時に出来るのがうれしい
 注意点
⁃ アプリケーション側で DNS キャッシュや永続接続されないように
注意が必要
22

check_slave
23
check_slave
MyDNS
<slave.foo.db>
mysql
http:9200
<bar.elasticsearch>
S-out
DEAD

check_slave
24
check_slave
<slave.foo.db>
mysql
http:9200
<bar.elasticsearch>
S-in
RECOVER
MyDNS

いざ障害が発生したら
 Webエンジニアが知っておきた
いインフラの基本(馬場俊彰)
 (引用)大障害のときの心構え
⁃ チームで役割分担する
• 司令塔は一人
⁃ 二次災害を起こさない
 同書の他のコンテンツ:
⁃ 障害を防ぐための冗長化や
監視
⁃ etc.
25

同じ障害を
繰り返さない
26

同じ障害を繰り返さない
 二度あることは三度ある
 恒久対応・再発防止を確実に
 振り返りも大事
27

まとめ
28

まとめ
 「障害は起こる」
 大事なこと
⁃ 未然に防ぐ
⁃ 影響を小さくする
⁃ 起こったときの対策・体制を整える
⁃ 繰り返さない
29

〜 We Are Hiring!! 〜
30
 http://dena.com/jp/recruit/career/engineer/
 http://denagames-tokyo.jp/

31
Thank You!!

参考
 Haikanko rubykaigi 20130531 (SlideShare)
 Yohoushi という分散 GrowthForecast グラフツールを作りました -
sonots:blog
 とある AWS サービスの運用移管〜データストア編〜 #jawsmeguro
 Webエンジニアが知っておきたいインフラの基本(馬場俊彰)
32

障害を防ぎ、サービスを守るために #gotandapm

More Related Content

What's hot

Viewers also liked

Similar to 障害を防ぎ、サービスを守るために #gotandapm

More from IKEDA Kiyoshi

障害を防ぎ、サービスを守るために #gotandapm