障害が起きたWebサービスは個人で運営しているサービスです。
2016年2月、障害から20日後にサービス再開しましたがアクティブユーザは以前の18%です。未だ回復の目処は立っていません。冗長化していないサーバがウイルス感染し、その後の対応も後手後手に回ってしまいました。
2016年1月末に起こるべくして起こった障害について記事にしてみました。ご迷惑をお掛けしてしまい本当に申し訳ありません。
■ ユーザは、もう戻ってこない
どんなウイルスに感染したのか
SYNフラッド攻撃（SYN Flood Attack）を他のWebサイトに行うウイルスに感染して、確認していませんが他のサービスをSYNフラッド攻撃していたと思います。またウイルス感染時にサーバのsshdを書き換えられsshで接続できなくなりました。感染後にコンソールログインして書き換えられた醜い authorized_keys を見た時ゾッとした。
起こるべくして起こった障害
振り返ると今回の障害は起こるべくして起こった障害でした。
・ウイルス感染したサーバの設定は、ファイアーウォールがOFFだった
・サーバが冗長化されていなかった
・障害期間中に簡易Webサーバを立てて、経緯をユーザ報告すべきだった。放置して404Errorを返していた
・障害担当エンジニアは俺一人だった
・唯一の担当Eは障害発覚直後にインターネットに接続できない地域(キューバ)に移動した
20日間Webサービスが停止すると数値はどう変化するのか
■ Google Search Consoleのデータ
この失敗から学んだ教訓
今回の失敗で学んだ教訓は、Webサービス運営において基本的なことだと思います。長期間のサイト停止は既存ユーザからもGoogleからもページ評価を不可逆的に大きく損ない、復旧後も長期間に渡って信用ならないサイトとして扱われ続けます。
サービス中断の影響が大きいため各サーバは2系統用意して冗長化したシステムを構築すべきしょう。また2016年のインターネット上には無数のウィルスが存在しています。ファイアーウォールは必ず有効にすべきです。十分に吟味したセキュアなサーバをもって挑むべきでしょう。
可能であれば、エンジニアも2系統いれば皆幸せになるんじゃあないかな。
そのとき何が起こっていたのか
自分で作ったサービスは愛着があります。だから毎日使っていました。右肩上がりを続けるPV数を眺めるのは楽しいものです。承認要求が満たされ続ける日々でした。気付けば1日3度はGoogle Analyticsを眺める生活。休暇を取り海外で過ごしていたある日、空港のWiFiからサイトに接続してみたところ何故か応答が返ってきません。パソコン開いてsshで接続するもアクセス出来ませんでした。
何かあるなとメールを開くとクラウドサーバを運営している会社から、次のような連絡がありました。
このたびお客様にご利用いただいております、VPSにおきまして
高パケット通信が生じている状況を確認いたしました。
転送量におきまして上限値は設けておりませんが、収容ホストに
負荷が生じており、他のご利用者様への影響が懸念されましたため、
緊急措置として該当VPSをシャットダウンさせていただきました。
つれー、人気サービスつれーわー、と思いながら停止されたサーバを再起動して苦情メールを書きました。転送量不足なら対応はいきなりシャットダウンじゃなくて、帯域制限じゃないですか？と
次のような返事が結構早く返ってきました。
お問い合わせの件につきまして、弊社にて再度確認を行ったところ
外部への攻撃(SYN flood)と見受けられるような通信が発生し
高パケットとなっていたようでございます。
こちらの件につきまして、ご認識がない場合VPSのセキュリティ対策や
原因特定などを行っていただけますと幸いでございます。
運営会社に平謝りしつつ、外部への攻撃は意図したものではなくウイルスのせいだ云々と言い訳し、サーバを今度は自分の手で停止しました。ウイルス感染した以上、再構築しかありません。残念ながら飛行機の時間が来たので構築は諦めてキューバへGO！ 海辺でモヒート飲みながら直してしまえば良いと当時は思っていました。
地上の楽園 = キューバ
ビーチリゾートとして有名なキューバ。空港で周りの乗客を見渡すと、みんな浮かれています。地上の楽園キューバは治安はよく、医療費は外国人観光客すら無料です、住民は学費も無料、配給制をとっており生活必需品はほぼ全て配給所でタダ同然の値段で手に入るため餓死者もいないとか。
■ ビーチでは、どこかのフリー素材みたいな写真が撮れた
そうです。キューバはガチ社会主義国なのです。ハバナの配給所では50mくらいの列が出来ていました。
また検閲国家ワースト7位という検閲が極めて激しい社会でして、インターネットは全て許可制 です。全て許可制なのです。振り返ると旅行中に発見したWiFiは空港職員用の暗号化された1箇所のみでした。
日本では私がWebサービスを監視する。
キューバではWebサービスが私を監視する。
キューバを歩く技術
■ 治安は極めてよいが、たまにHomeless Dog 1grp巡回してくるのでハイド避けスキルレベルは上げておいたほうがいい。発見されたら深夜のヤンキーと同じ対応をする『目を合わせないこと』
■ インターネットに接続する技術
1泊100ドルオーバーの外国人専用ホテルに宿泊すれば1時間500円くらいでインターネット使えると、どこかのブログに書いてあった。WiFiカフェは一度も発見できなかった。現地の暇な若者は野球を観てた。
■ CASA（民泊）を利用すると1泊15ドルくらいで泊まれる。インターネットはもちろん無い。アメリカと国交ないためアメリカ系サイトには登録されていないことが多い。イタリア語とかで検索したら大量に検索で引っ掛かった。シャワーからお湯が出る宿に当たる確率は50%(2回中1回)だった。どこも気のいいご婦人がオーナーで、めっちゃ親切。
↓ ご婦人が部屋に運んでくれた朝ご飯,オムレツと焼きバナナ
■ 換金(Exchange)
日本円を換金できるのは空港の両替所だけだった。ユーロなら繁華街でも換金できる。レートはどこもほぼ同じ。
■ 英語
英語堪能な人は観光地でも20人に1人くらいだった
■ 葉巻/買い物
正規ショップは1本500円オーバー。浮浪者からは3本1ドルで購入できたが2本はシケっていて火が付かなかった。
■ タクシーはぼったくられる
タクシーは20分交渉しても、宿で教えてもらった現地価格には下がらなかった。バスは30円くらいで超安い。全てメーターなしの事前交渉。最大の観光地Old Havanaで500m - 2kmの市内で値切って最安値600円。長距離乗り合い4人乗りタクシーが120kmで1人1700円。どれだけぼったくってるんだ... 医者よりタクシードライバーの方が給料いいらしい。
■ 飲料水の調達
水道水は飲めない。現地向けのショップで50円で2L。観光地向けのショップだと250円で2L。キューバ生まれのカクテルであるモヒート1杯は250〜350円くらい。日本人好みの味でうまい
1. 再発防止策
反省しました。同じ失敗を2度繰り返すことはエンジニアとして失格なので考えうる限りの対策をとってみました。
1-1. アプリサーバを冗長化した
アプリサーバが1台のみでした。複数台あれば片肺でサービスダウンは発生しなかったはずなので、ロードバランサを導入してアプリサーバを2台構成に変更しました。
1-2. サーバのセキュリティ設定を見直した
以前はノーガードでした。しかしAWSのようなセキュリティグループが存在しないクラウドサービスでは、Firewallなしでは危険すぎます。自分のサーバだと 1ヶ月でウイルス感染 してしまいました。よって設定を見直して、次のような設定に変更しました。
| No. | 設定内容 |
|---|---|
| 1 | firewalldを有効にした |
| 2 | firewalldにホワイトリスト式に利用するサービスのみ穴を開けた |
| 3 | ssh接続ポートを変更した |
1-3. nginxのエラーページ設定について確認した
httpサーバが死亡したときに、nginx単体でエラーページを表示するための設定確認と検証を行いました。
1-4. マシンイメージのバックアップを取った
サーバ再構築に時間が掛かってサービスの復旧が遅れたので、各サーバのマシンイメージ（スナップショット）を取得しました。特にPythonのpipファイルの設定に時間が掛かりました。依存関係やmysqlライブラリがバグっていたりと3系はバッドノウハウが多いです。
2. やっててよかった設定
2-1. 各ミドルウェアの設定ファイルのgit管理
各ミドルウェア間の試行錯誤が無くなったので迅速に復旧できました。
2-2. ロードバランサを導入可能なクラウドサービスを選んでいた
ロードバランサ 1,000円/月
ロードバランサは、Webからボタン1つで導入できました。
3. 設定に迷って、よく判らなかったところ
RDBの未停止バックアップってどうすればいいか判らない。AWSだとDBの自動バックアップがありポイントインタイムリカバリで簡単に好きなタイミングに戻せます。master, slave構成に分けてバックアップ時にslaveを切り離して、バックアップを取って戻してレプリケーションさせるといった、泥臭い方法しかないのかなぁ。正解がわからない。
こういったRDB周りの手間を良い感じでマネージドしてくれるAmazonのRDSは、やっぱ値段高いだけの付加価値が付いていて素晴らしいです。さらにマルチAZまである。と社内の先輩が教えてくれました。
障害が起きたWebサービスは個人で運営しているサービスです
この記事は2016年 独りで新規WEBサービスを開発・運用した際の知見の続編となります。こんな記事書くことになるとは思いませんでした。九死に一生を得たのはログインデータを持たないキュレーション系サービスであったため情報漏洩の発生を考慮せずに済んだことです。
ご迷惑をお掛けしてしまったユーザの皆様に本当に申し訳ない気持ちでいっぱいです。また事実確認は行えませんでしたが、私が管理しているサーバからSYN Flood攻撃を受けてしまったWebサーバ管理者のみなさま、本当に申し訳ありませんでした。m(＿＿)m
最後になりましたが、仮想サーバを運営されている運営会社のご担当者様、迅速なサポート対応とアドバイスありがとうございます。復旧対応で楽できました。