2018-2019年のサービス障害を振り返る

ときどき思い出したように書いている障害事例まとめです。こういうのをやるならせめて年1回くらいはまとめないとダメだね……。昔の記事だと経緯や内容を覚えていないし、ニュース記事 (特に新聞社の記事や企業の障害に関するリリース記事) が消えてしまっていたりする。年末にまとめてドカッと振り返るのはしんどい。

基本的には自分がブックマーク等でクリップしたものをもとにまとめています。主要なニュースソースはこの辺です。

以下、障害事象の発生日時をベースに並べていますがあまり正確ではありません: 海外事例で正確な発生日時が不明なものについては、ニュース記事の発行日でつけているものがあります。また海外事例については時差表記を統一しておらず、日本時間だったり現地時間だったりまちまちです(目安程度につけているだけなので統一できていません。)

2018年の事例

2019年の事例

2019/6-7月にかけてはこうしたクラウドサービスや通信事業者の大規模な障害が複数起きていてこんな記事も出ました : インターネットにとって最悪の1カ月 | TechCrunch Japan

個人的な所感

  • BGPルート漏洩などによる広域での障害は相変わらずだけど、中国政府がチャイナテレコムを通してBGPハイジャックを実行--研究者が指摘 - CNET Japan みたいな話があって不穏な気配が。
  • 銀行・金融系と、あと地方自治体システムでのトラブルが目立つようになってきた。役所でのクラウドサービス利用などが進行している分影響が目に見えるようになってきたんだろうか。
    • いずれにせよこの辺、バックエンドに SIer がいてやっていると思われるサービスとかについてはとにかく情報が出てない。もうちょっとなんかあってもいいのでは……(まあしがらみがあるのはわかるんだけど)。でも、ほかの会社が報告出してるかというと必ずしもそうでもないんだよな。Facebook他、障害があったことしかわからないのがいくつかあったし。
  • 大規模障害後の余波で 2 次障害 3 次障害と起きるケースがいくつか。システムの大規模化・複雑化が進んでいる・システム全体の挙動が読み切れない (どうしても予期しない事象が起きる) というのがあるんだろう。読み切れないものに対してどこまで被害を抑えられるかが今後の力の入れどころになると思われる。
    • 自動化されていることによる影響拡大というのは前も書いたけど、ソフトウェアによる誤検知 (false positive) が広くなってしまって障害に発展する……みたいな、よりアプリケーションよりの障害が増えてきた印象。
  • 2018-2019は、国内はどうしても災害とは切っても切り離せないですね。大阪北部や北海道胆振東部の地震もあったし大型台風も頻発した。ここではそれらに起因した障害は特にあがっていないけど、サービス運用の人たちは緊張の連続だったんじゃないだろうか。お疲れさまでした。
    • 自分自身が胆振地方出身だし、北海道東部の地震にはいろいろ思うところがありました。
    • 災害対応と今後 :: JANOG43 など。JANOG では災害時の対応報告なんかが上がっているので検索してみるとよいと思います。
  • それにしても、同時期に独立したサービスで障害がかたまって起きるのはなぜなんだろうか。2019/6-7月におきた大手クラウドサービスの障害連発とか、2019/11月の国内 DC サービス電源障害の連発とか。不思議だ。

オマケ

[2020-01-04] どれも情報系サービスってわけじゃないのと、ひとつ追記忘れていたものを見つけたのでちょっとよけます。生物起因の停電みっつ。ネズミはデータセンタとかでも何回か聞いたことがあるけど、ナメクジとかヤモリとかは珍しいね。

ネットワークプログラマビリティ勉強会 #npstudy #15 参加メモ

ネットワークプログラマビリティ勉強会に参加してきたのでいつものメモです。

ネットワークプログラマビリティ勉強会

趣旨

  • NWの課題、システムエンジニアリングだけではなくソフトウェアエンジニアリングで解決する時代に
  • NWエンジニアもソフトウェアやOSSの知識が必要
  • みんなで知見やノウハウを共有しましょう

募集

  • スピーカーがいると次回早く開催できます
  • LTは公募割と早く埋まるので、確定してないネタでも声をかけてもらえると
  • スタッフも募集してます。
  • 会場も探してます

Lagopus Router, hibitomo さん

余談: MSのすごいところ

Lagopus

  • NTTの研究所で開発している。OSSプロジェクト。
  • 2013年から。SDN/NFVというキーワードで。DPDKで10Gワイヤレート、ソフトウェアで汎用サーバの上で。
    • コスト効果、time-to-market の短縮
  • 最初は総務省のプロジェクト。今はNTTと大学とか。
  • 2017/8月にLagopus software router (alpha), 今頃には beta が出てるはずだったんだけど社内手続きを勘違いしていてちょっとずれる…

Lagopus switch

  • OpenFlow1.3 + Tunnel Extension

OpenFlow?

  • パケットをマッチしていろいろいじる
  • 弱点: ステートを持てない (ステートはコントローラでしか持てない)
    • よく考えないとフローが爆発しがち
  • ユースケース
    • SDN-IX (Interop), DDoS対策とか。
  • ユースケース要望きくとOFだとつらい
    • VRRPとか。自発的にパケットを出す・ステートを持つ

Lagopus switch → Lagopus routerへ

  • NWエンジニアが使いやすいものを作ろう
  • 方針
    • コントローラ--スイッチ間が埋まりがち → 経路交換とかの機能は「箱」のほうへ。コントローラ側は提供したいサービスアプリのみに注力しよう。
    • lagopus で実証実験 → 良ければベンダとかで

中身の話

  • Lagopus project 側の思いからは、モジュールを作ってみてほしい → router architecture について。
  • 中身はマイクロサービスみたいな感じ
    • モジュール間が gRPC とかで切れてる
    • Zebra2.0 で使っている config manager を利用。(config datastore)
      • demo
    • config datastore → agent (routing, vrrp, ike, mat) → dataplane
      • DP間I/Fは gRPC, NetLink の agent がある

Dataplane module

  • Fast path → DPDK, Slow path → Golang で記述
    • Go/DP(Clang)間はRING, (2016 の dpdk user space (ダブリン) の資料を参照)
    • alpha → beta で中身が変わる。2018年度頭リリースの時にモジュールの書き方とかのドキュメントを追加して公開予定。

Config datastore

  • Openconfigd
    • YANGを突っ込むとCLI/APIを生成してくれる
    • YANGのconfig sub tree に対して、agent が subscribe すると push してくれる。
    • CLI も他とか commit とかつかえる
      • validation して subscribe しているモジュールがみんなOKならcommitになる
    • openconfigd でオレオレCLIを書こう (IW2017 BoF 浅間さん)

Openconfigd Demo

  • YANG の leaf を足すだけで CLI ができる
  • "birdwatcher" (公開予定)
    • config に条件をしたいことがある。依存関係の解決
    • OpenStack Congress (ポリシーエンジン) みたいなの
      • 「このルータでL2の設定は許さない」
    • config datastore とだけやりとりして validation する
    • commit → validation error → birdwatcher で validation log を確認できる
    • 依存関係を定義すると CLI の依存関係を解決する仕組みが書ける
      • 本体201行! ルールは変数定義だけ。
      • Golang, openconfigd すごい!

Roadmap

  • 2月か3月に出す予定だったが…来年度に。
  • beta release (L3/L2, match&action)
  • 2Qあたりに ipsec
  • future work
    • nat, ipv6, mpls, bgp flowspec, acl, xflow
    • 来年度中… 少なくとも NATは。ipv6もいれないとshownetにはいらないので…
  • みなさん CLI つくりましょう

QA

  • lagopus arch, agent は golang の別のプロセスで動いている?
    • routing agent は linux kernel
    • vrrp agent とかは dataplane module とは別プロセス
  • スレッドのつかいかた、switch は dpdk pipeline model, router は?
    • 基本的には pipeline model にちかいけど、スケジューラがいて仕事を割り振る感じ。

ここ3年におけるサイバーエージェントのネットワークを取り巻く環境の変化 ~API/SDN/kubernetes~, 山本さん

CyberAgent

  • ゲーム・メディア事業
  • アドテク本部
    • インターネット広告
  • アドテクスタジオ
    • いろんな広告をまとめて開発していく(掲載媒体より・広告出したい人向け、広告競売、などのシステムがある
    • 遅延の少ないネットワークが求められる

アドテクスタジオのインフラ?

  • 広告プロダクト…25-30ある。200名くらいのエンジニア(ほとんどアプリ。インフラは10人くらい。)
  • インフラはプロダクトで選択できる。GCP < AWS < Private cloud (インスタンス数)
    • GCP増えてきてる

プライベートクラウド

  • 本番用 OpenStack (ふたつあって新旧移行中)
  • コンテナ基盤
  • CI (Circle CI)
    • Circle CI 2.0 で苦労しています
  • 物理マシンはMAAS (Ironic)
  • 個人開発用クラウド (OpenStack Mille + Midonet)
  • 分析基盤: tableau, Hadoop (OpenStack)

ここ3年

  • 2014/3
    • 1U物理サーバを並べる + KVMVMを数台。
    • サーバ担当がラックつくってNW担当がスイッチ設定してOS入れてVM作って…とかを申請ベースに手作業
    • ヒューマンエラー, 作業分断
  • 2014/8
    • OpenStackでセルフサービス
    • 当時の neutron L3 がアレだったのでL2構成
      • L3終端とLBが物理で取り残される → 申請作業が残る (より問題が顕著に)
    • インフラ用 API gateway を作成して API を公開 → ルータ・スイッチ・LB, neutron の設定をapi経由で
      • 学習コスト/標準化 → 機器固有の違いを覚えなくてもよい, JOB組み込みがしやすい・申請ベースの問題を解消
    • chatbot も導入。chatでインフラ操作。NWのグラフとってくるのとか面倒な操作も。
  • 2015/2
    • 個人開発環境をMidonetで。当時OSS化されたばかりくらい。
    • VTEP → サーバになる。NW は L3 reachability だけあればよい。
    • トラブルシュートが変わってくる…範囲をどこに絞るか。物理NW? Linux NW? zookeeper で管理しているところ? midonet bug だと scala
    • NWとサーバの守備範囲の変化…垣根がなくなってくる
  • 2016/11
    • コンテナ使いたい → GKE → k8s-aaS ("AKE")
    • private cloud, パフォーマンスとか見てもコストメリットがあったので。
    • k8s 構築がつらい問題→k8sクラスタを簡単にデプロイ。動的な永続ボリュームの提供。
      • OpenStack上で必要なリソースを展開...HEATの話とかもトラブルシュートする上では必要
    • type:LoadBalancerの壁…OpenStackでは neutron LBaaS, Octavia : でも アドテクのOpenStackはL2構成…
      • k8s cloud provider の openstack pkg を回収 → LB用IP払い出してAXCをたたくように変更
    • 物理の世界だけでは生きていけない
    • chatbot も進化: ヘルスチェックやアラート応答

まとめ

  • NWエンジニアの領域は変わってきている
  • openstack, sdn, k8s による変化にどれくらいNWEが食い込んでいけるか
  • 申請処理などの単純作業から解放されれば他のことがやれる
  • 情報交換を

Azure のネットワークはブラックボックスじゃない!, 山本さん

Azure

  • サービス8年。IaaS/PaaS, AKS
  • Enterprise Cloud : 固い会社とよくやっている
  • 世界中にDCがあるよ
  • 5月~欧州で個人情報保護系の法律(GDPR)にも対応
  • Openなクラウドです!

NWがブラックボックス?

  • Azure NW, 世界中のDCにいろんな回線引いてる。backbone NW つよいよ
  • IaaSのNWイメージ
    • 仮想マシンごとに NW Sec Gr (NSG)(per NIC) + vNETでも Sec Gr
    • PaaSとvNetでつなぐこともできるようになったよ
  • NWの可視化 : Network Watcher
    • 有料だけどゴミのような値段!
  • demo
    • VMNIC→IP,NSG
    • Network watcher → トポロジ → NW図を表示 (defaultでやれる + download topology すると visio で編集可能なファイルが落とせる)
    • Network watcher → IPフロー確認(ping), packet captuer
    • PowerBIにNWログ食わせる(Windows)。テンプレートがある。とってきた情報のままレポートが書ける
    • Security center: NWの推奨値とかが出てくる。ポリシあてたりとかいろいろ。
    • Just in Time VM preview: 普段は全部閉じたFWポリシ。要求タイミングで特定プロトコルを指定時間・指定範囲で空けることができる。(まだGUIでの入力)

分離されたネットワークでの複合機/プリンターの共有, @otahi さん

オフィスでのネットワークの課題とその対策。

  • 総務省が自治体に、ネットワークの分離を求めている。住基ネット/LGWAN/インターネットをわけてそれぞれで情報が簡単にやり取りできないように。
    • 複数のネットワークから複合機とかプリンタを安全に利用したい
  • NWごとにプリンタ置けばいいんだけど場所の問題もあるしそうもいかない

複数のNWからプリンタ使いたい

  • USBプリントサーバ
    • 2系統までなら簡単
  • インタフェースボックスタイプ (今回の話はこれ)
    • 3系統までの有線LANに対応
    • scan-to-folder 可能
    • 個人認証/私書箱プリント対応
    • Tag VLAN対応(10VLANまで) (プリンタはtag対応しない)

しくみ

  • いままでのNWはそのまま
  • 他のNWは NAPT...プリンタが source になるときのルーティングとかNW間制御とかでSDN的に

USBプリントサーバだと快癒ところに手が届かないところに対応

pyATSをつかったテストの自動化, 緒勝さん

pyATS?

  • python based framework
  • pytest + netomico
  • もうちょっとすると testfms 込み見たいなフレームワーク
  • まだ OSS としてソースコードが公開されていない
    • 公開されるかどうかはまだわからない。
  • 発表はいちユーザとして。
  • pyATS + Genie
    • 現在は netomico 的モジュール(genie), 今後は REST, parser lib 都下も出てくる予定。

テストケースをクラスで書いて、メソッドでステップを刻んでいく

  • ベーシックなテストケースを書いて、子classでoverrideしてバリエーション

いいとこ

  • cisco で結構長くつかわれてる。
    • ATS: 前身は tcl → python
    • testbed file: 機器のアクセス情報、トポロジ、初期条件などを書ける
    • genie framework: 機器抽象化ライブラリ
    • unicon package...ssh/telnet による機器アクセスサポート
    • roadmap
      • Parsergen, YANG.connector, REST.connector, Genie.Telemetry

Testbed file

NSOで自動化した処理の試験を自動化する - pyATS →(REST)→ NSO → config → test - CLIでやったけど XML でやったほうがらくだったかな

関連情報

次回

  • 2か月後くらい?
  • ネタがある人は声をかけてください

2016-2017年のサービス障害を振り返る

最近全然ブログとか書けてないなーと思いつつ 2018 年を迎えてしまいました。本年もよろしくお願いいたします。

以前、DC/クラウド/通信事業者サービスの障害事例よせあつめ という記事を書いたところ意外と反響があったので、続きを書こうかなと年末考えていたのですが、結局 2017 年中は書けませんでしたね。いろいろあったんですよ。個人的な話なんで別にどうでもいいんですけど。そんなわけで年明けに書きます。

この記事は 2016 年アタマの GMO の障害とか github のサービス障害をきっかけに書いたものでした。その後、世の中的にはどんなサービス障害が起きているのかをざっとおさらいしてみたいと思います。いまシステムやサービスを作っていく中で、こういう原因で死ぬのか…というのを見ていくことは、ひいては「そこまで予見できなかった」あるいは「そこからは回復させられなかった」ってことを考えることなんですよね。落ちた = ダメじゃん、という話でおわるのはなくて、ここまでやられて初めて落ちるんか…とか、こういう可能性まで見込んで何か考えないとイカンのか…とか、こういう状況でもうまく逃げ切るための方法って何なのか…とか、発展的な話を考えるための材料だと思っていただければ。

挙げる事例については私がウォッチして見つけているものなので当然偏りがあります。その点はご承知おきください。他にもこういう事例があるよってのがあったら是非教えていただきたく。

参考資料

ニュースソース

ツイッターとかでも拾っていますがこの辺を見ることが多いですね。いろいろ時事ネタや速報だしてくれています。ありがたや。

参考記事

2016年の事例

2017年の事例

おわりに

個人的な所感としてはこんな感じです。

  • 相変わらず DC 設備系のトラブルはおきる : 停電・ケーブル切断などファシリティ・設備レベルの話はやっぱりゼロにはならない。
  • パブリッククラウドクラウド上のサービス(XaaS)ではソフトウェアで自動化されることによって障害が増幅される : 自動化してレバレッジをかける……一度に大量のサーバを操作したり処理を実行できる。ただ、これは誤った手順・オペミスのリスクを拡大する方向にも働く。実行するツールの選択ミス・パラメタ設定ミスなどをどう防ぐか → オペレーションの妥当性・正当性をどう保証するか、というのは課題になるだろう。それと大規模にやらかしたときにどうやって復旧するか、という話。両面での対策検討が必要になると思われる。
    • 複数のサイト(リージョン)やサービスをまたがるような障害にどう対処するか?
  • ネットワークエンジニア的には、この 1-2 年は BGP 操作による大規模障害が目立つのが気になるところ。とはいえこれ、upstream でやられちゃうと、エッジにいる側からはなかなか対処ができないんだよな。せめて問題検知や切り分け・状態の把握を早期にやれるようにするくらいか?