コラム

CTC教育サービス・ホーム　＞　コラム　＞　クラウド時代のサーバー運用入門　＞　第1回　クラウド時代の障害対応術 (1) コンピューターの部品をイメージしよう

クラウド時代のサーバー運用入門

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第1回　クラウド時代の障害対応術 (1) コンピューターの部品をイメージしよう (濱田康貴) 2017年10月

はじめに

みなさま初めまして。株式会社パイプラインの濱田と申します。このたび、「クラウド時代のサーバー運用入門」というタイトルでコラムを担当させていただくことになりました。サーバー運用担当者の「こんなときどうすればいいんだろう？」の疑問に少しでもお役に立てれば幸いです。

こんな方にお役立ていただきたい

私が想定している読者はこのような方々です。

はじめてサーバーエンジニアになった
サーバーエンジニアになってクラウドは使いこなせているが、オンプレミスな環境はほとんど経験がない
障害対応に強くなりたい

もはやクラウドは当たり前、サーバーレスすら身近になりつつある昨今、どうしてこのテーマを取り上げたのか、その理由をもう少し掘り下げますと、たとえクラウドと言えども必ず物理的なコンピューター(サーバー)の上にサービスが構築されています。しかも、クラウドだから、サーバーレスだからと言って障害と無縁でいられるというわけではなく、時には「ただ復旧を待つしかない」という状況におかれることすらあります。

このコラムを読まれている皆様は、エンジニアの方が多いと思いますので、「エンジニアとして」障害を正常化し、サービスの健全性を保つためのいくつかのアイデア、対応方法についてお伝えしたいと思います。最近では「Site Reliability Engineer (サイト信頼性エンジニア)」と呼ばれることが増えてきましたが、一体どんなミッションなのか、Googleの「What is SRE?」(https://landing.google.com/sre/) より引用してみますと

Our mission is to protect, provide for, and progress the software and systems behind all of Google's public services -- Google Search, Ads, Gmail, Android, YouTube, and AppEngine, to name just a few -- with an ever-watchful eye on their availability, latency, performance, and capacity.

私たちの使命は、Google Search、Ads、Gmail、Android、YouTube、AppEngineなど、Googleのすべてのパブリックサービスの背後にあるソフトウェアとシステムを保護し、提供し、進歩させることです。可用性、待ち時間、パフォーマンス、およびキャパシティを向上させます。

と訳してみました(間違ってたらごめんなさい)。もちろん上記に書いてある内容は障害対応を行う、ということだけを指しているのではなく、そもそも障害を起こさない、つまりできるだけサービスを正常稼働させるために日々活躍している、と私は解釈しています。

障害対応で何をしたらよいのか

いきなりそもそも論になってしまいますが、大事なことですので最初に書いておきますと、障害対応の究極の目的は「異常がおきたサービスの正常化」です。つまり、自分が担当するサービスは何をもってして正常としているのかを最初に理解しておかないといけません。セキュリティや性能の担保、開発環境やプロダクション環境のプロビジョニングなど、どんなに最善を尽くしても必ず障害は発生します。時々刻々と変化するカオスな状況に飲み込まれず、「このサービス、この機能はどうあるべきか」を忘れず対応することが肝要です。

障害対応アンチパターン

プログラミングにもアンチパターンがあるように、障害対応にもアンチパターンがあります。最初からいくつも挙げて理解の消化不良をおこしては本末転倒ですので、私の経験上もっとも大事なアンチパターンを1つだけ挙げますと、

やみくもに弄り倒さない

の一言に尽きると言えましょう。勿論、「こうしたら直るだろうか」と試さなければわからない気持ちは痛いほどわかりますが、復旧までの途中の過程を説明できなければ、

同じ原因で障害が再発しない、という確証が得られない
オペミスによる二次障害を引き起こしてしまう可能性がある
本来そのコマンドを実行する前提条件が揃っているという確証がないのに実行してしまうことで、さらに障害の深刻度や影響範囲を増やしてしまいかねない

という弊害があるので、やみくもに弄り倒すという行為は障害対応における最大のアンチパターンと言えましょう。

また、反対に安直なコマンド実行も二次障害の原因となり得ます。例えば「ディスク使用率が100％になってしまっていたので、大量にあったログを消しました」は、一見ディスク使用率異常の復旧に繋がったかも知れませんが、実は監査証跡として大事な消しちゃいけないログだった・・・という可能性だってあるのです。これもいわゆる「やみくもオペレーション」の1つですね。

どうしたら障害対応アンチパターンに陥らないか

「こうすれば一撃で障害被疑部位を特定できる」という銀の弾丸なんてありません。あったら私が悪魔に魂を売ってでもほしいくらいです。という冗談はさておいて、コンピューターの部品をイメージして障害被疑部位を特定することで、障害発生原因と最短最良の解決に近づくことができます。

それでは、あらためてコンピューターの部品はどんなものがあるか、を整理してみましょう(WEB上で提供するサービスに関係あるもの、関係が深いものだけをチョイスしています)。

電源
CPU
メモリ
記憶媒体 (SSD、ハードディスク)
ネットワークインターフェイス

もちろん、途中の経路上にあるルーターやスイッチ、ロードバランサー、ファイアウォールやDNSサーバーなど、サーバー本体外に障害の原因があるケースも想定できます。こと、コンピューター本体の障害に限って言えば、そもそも電源が故障していたりオペミスでシャットダウンしていたりしていれば、それ以上「ディスクがいっぱいになっていやしないか？」「ネットワークインターフェイスが壊れてないか？」なんて調べようがないですし、電源異常を解決しなければ、その他の原因について現状で調査しようとすること自体が無意味なくらいです。

このように、ハードウェアに起因する障害は、単純に「障害被疑部位の交換」で復旧することが可能ですが、一方でソフトウェア的な障害は、原因特定までの道筋が複雑化する傾向にあり、時にはOSやミドルウェアに対する深い知見、サービス仕様の把握など、高いスキルが求められる傾向にあります。

また、単にコマンドの使い方を知っていたからと言って、安直な解決を図ろうとすることは「やみくもオペレーション」であることは先にも述べましたが、コマンドを実行した結果(コマンドの出力結果、終了ステータス、そして業務影響)を想定できるかどうか、これが正しいオペレーションに繋がるでしょう。

厳選！障害対応お役立ちツール

ほとんどのIaaS環境やオンプレミスのWEBサービスは、ディストリビューションの種類を問わず、Linux上で動いていることが多いでしょう。このため、障害対象ホストへログインしたり、監視サーバーなどから障害対象ホストへコマンドラインで調査を行うにあたり、私の場合以下のコマンドを使うことが多いです。

curl df dig du fuser ip last lsof nc ping ps ss telnet top vmstat w whois

上に挙げたそれぞれのコマンドの使いどころについては、スペースの都合上次回以降にご紹介したいと思いますが、単にコマンドを実行したあとの表示だけを見て「こうでした」ではダメで、コマンドラインの組み合わせをどれだけ使いこなせるかが解決への早道となるでしょう。そして、いざ実戦で慌てないためにも、これらコマンドがコンピューターの部品のどこを見るコマンドなのか、を意識するとよいでしょう。

次回をお楽しみに！