クラウドネイティブが生まれてこようとしている時代です。サーバを実際に見たことがないという人も増えてくるかと思います。しかしながら、世の中からサーバやケーブルがなくなったわけでもありません。クラウドという抽象化されたサービスになりOSがどのような環境で動作しているか見えにくくなっていますが、クラウド企業のデータセンタの中では確かにサーバが存在しています。
トラシュー事例（初級編）
システム面からだけでは解決できないトラブル
これからクラウドコンピューティングを学ぼうとしてる人にとってクラウドコンピューティング環境と仮想化環境とでは何が違うのか、という点は疑問を持たれる人が多いかと思います。普段使っていても、意識しないとその差は表面的には見えないと思います。
新人「先輩、何も問題がないのにアクセスできません！」
あるとき、とあるサーバでパフォーマンスの問題が発生しました。そのシステムはWebシステムで、従来のオンプレミスで構築するように、負荷分散装置（Load Balancer）を経由して、Webサーバにアクセスされるように設計されています。アクセス数が増えることを想定してサーバのCPUやメモリを見積もり、運用中はモニタリングをしていました。ところが、ユーザからシステムにつながらないという問い合わせが多数ありました。実際にSEがWebサーバを確認してもやはりその時間につながらないと通知が来ていますが、Webサーバ側にはゆるいアクセスしかない状況です。またHTTPサーバを調べてみても、リクエストに対して正常に応答しているログしか見つけることができませんでした。
見えるところと見えないところ
さてクラウド上のサーバを利用していると忘れがちですが、クラウドサービスの多くは「パフォーマンス」や「トランザクション」などの指標で契約を行うことが多くあります。クラウドとオンプレミスの違いとして「最大のパフォーマンス」を常に利用者が享受できるわけではないということがあります。同じ仮想化のしくみとしても、オンプレミスの場合にはリソースをすべてユーザが自由に利用できます。また、クライアントからサーバに至るまでのさまざまな経路を調査することもできます。ところがクラウドの場合にはユーザから見えるのは提供されるリソースだけになります。今回のケースではエンジニアが調べられる範囲は非常に狭く、Webサーバしか実際には調べることができません。
問題に立ち返ってみましょう
今回のケースは「システム的なトラブルはないのに利用者にサービスを提供できていない」という事象にあたります。クラウドは「共有サービス」ですのでパフォーマンスが安定しないという話がよく出たりしますが、早合点をしてはいけません。実は今回のトラブルの原因は、「負荷分散装置を『低リソース』で契約していたこと」だったのです。筆者が勤める会社でも、昨年から利用しているパブリッククラウドのSoftLayerではLoad Balancerが「同時接続数」で契約されます。つまりどんなにWebサーバのリソースを強化して分散させても、そもそも契約上の制約で処理ができないとうオチでした（図1）。今回の新人君へは、
- 「まず環境をキチンと理解する必要があるよ。とくにクラウドの場合にはどのようなサービスとして利用しているか最初に把握したほうがいい。それと障害分析もブラックボックスになりがちなのでサポートセンターとは密に連絡を取るほうがいいよ。通信できない、ケーブル挿せよっていうレベルの話を見落としがちだからね」
とアドバイスしたいと思います。
図1 初級編のトラブルの概要
クラウド時代のトラブルシューティングの基礎
クラウドとは高度に抽象化された世界で実現されています。システムの基本となるネットワーク、ストレージそしてコンピュートノードすべてが仮想化されて動いています。これはオンプレミスで仮想化環境を作っても同じことが言えます。クラウドサービスを利用すると、この抽象化がどのように実装されているか利用者からはまったく見えないため「見えている」範囲で問題を解決していく必要があります（図2）。
図2 クラウドサービスの見え方
実際には、オンプレミスでも原因を追跡するのは本当に難しい問題です。また、いかにオープンに見えるクラウドでも実際のハードウェアレベルまで行くと実装は非公開です。クラウドというのは実はプロプライエタリな環境であったりします。したがってトラブルが発生した際には、まず「クラウドサービス側で問題が発生していないか、原因はどこにあると推測できるのか」をサポートに確認してみることをお勧めします。
基礎的な知識が想像力を産む
たとえばクラウドサービスの基盤側で障害が発生していたとします。その情報はすばやくユーザに提供されると良いのですが、実際には提供されるとしても少し遅れて通知されると思います。その期間ユーザには何が起こっているでしょうか？ もしかしたら顧客に提供しているWebサービスが利用できない状態になっているかもしれません。場合によっては保守用のネットワークが利用できず開発者が困っているかもしれません。
これらの「症状」を利用者が認識してからトラブルシューティングをしていくことになります。オンプレミスで構築され、すべてが把握されている状態と違い、原因や影響範囲をクラウド事業者が連絡してくれない場合には、その「症状」から何が問題であるかを紐解いていく必要があります。まずはユーザが管理できる範囲の対象で「エラー」や「警告」が出ていないかをチェックしたり、前日との変更点を調査したりしていきます。しかしながら、問題の原因はどうもアプリケーションでもOSでもなさそうだとなり、今回のようにそれ以外の個所で発生しているようだとわかるケースがあります。
クラウドサービスは、一見どのように動いているかわからない場合でも実際に「雲」であることはなく、何らかの技術で作られたシステムなのです。突然にパケットが別の場所にワープすることはないので、オンプレミス環境でこれまで得た知見を活用して該当個所を推測していくことが重要です。クラウドになったのでインフラの知識が不要になるわけではなく、逆にどのような仮想化技術が使われているのだろうと想像力を働かせて利用していく必要があります。むしろ見えないからこそ、基礎をしっかり理解しておく必要があります。
トラシュー事例（上級編）
トラブル発生時の初動を考える
筆者がよく取り扱っているIBM SoftLayerでは昨年末に東京データセンタが利用可能になりました。SoftLayerでは標準で端末からのSSL-VPN接続が利用できるのですが、接続先のPOPアドレスが「新データセンタ設立工事」のために変更になっていました。実際にはメールなどで通知があるにせよ、利用者としてはすべてをチェックしているわけもなく「接続障害」と認識してしまう」というケースがけっこう多いので、問題が発生した際には「IaaS」としてのサービスがどのようなコンディションなのかをチェックするというのが大事な初動であると思います。
「正常」という状態を把握せよ
トラブルシューティングを行うためには情報が多いに越したことがありません。また「正常」である状態とはどのような状態なのかを正しく把握しておくことが大切です。IaaSではAPIを経由してさまざまな情報を取得することができます。とくにAWSではCloudWatchという非常に優れた監視サービスが提供されています。また、SoftLayerの場合にはAPI経由で各種モニタリング情報にアクセスすることができます。これらの情報から利用者はこれまでと同様に（一部はこれまで以上に）独自の監視システムを構築することができます（図3）。
図3 クラウドでの監視のしくみ
こういったサービスを利用して日々状況を把握しておくことが、問題が発生したときに「正しい異常」であるかを確認する手助けになります。加えて、実際の利用者のネットワークからの監視もお勧めします。たとえばクラウドサービスと、自社がネットワークで常時接続している場合にはサービス（たとえば、HTTPのResponseからの監視）を利用者の立場から監視することで初動を適切に行うことができるようになります。従来のプロセスである「起動／停止」レベルの監視はクラウドの環境内部から実施しますが、ユーザのネットワークからは応答時間やスループットなどの、システムが提供するサービスレベルでの測定をしていきたいものです。
適切な判断を決めておく
サービス事業者は障害が発生したときに、「確実」に障害となっていないと「問題ない」と回答してくるケースが多いと思います。したがって利用者としては、起こっている問題がクラウドにあることを証明することが重要になりますが、いずれにしてもオンプレミスで自社のエンジニアが対応することと違い、自分たちの望むペースでは問題は解消されないケースがあります。また原因についても明確には連絡されないことも多々あります。したがって、なかなか実現するのは難しいですが「停止しても良い作り」にしておくことが一番重要になってきます。運用の現場としては、障害解決を優先させるのか、現状復帰を優先させるのかをあらかじめ業務レベルに応じて定義しておくことが必要です。
クラウドのシステムの障害対応の基本は「ブラックボックス」なものに対しての出入りをきちんと認識し、その中で何が起こっているかを把握することです。そしてクラウドサービスは「時間」などの品質面が甘いため、トラブル発生時には復旧優先での対応をしたほうが望ましいと考えます。仮に、「ルータを再起動すれば直る」障害が発生した場合でも、実際には「いつ」実施されるのか不明です。そういった意味でも障害が発生している中でそのシステムを業務上どのように動かしていけばよいかという議論はしておくべきでしょう。
これからのインフラ設計
クラウドを利用した運用が始まってきていますが利用部門がこれまでと同程度の品質を求めてしまい余剰な構成になっているケースもあります。クラウドを利用するにあたり運用レベルなどの見直しも行うことで、トラブル発生時の負荷を減らしていくことが可能になってくると思います。難しいケースが多いですが、やはり「構築」する段階でどのようにシステムをデザインするかは非常に大切になってきます。これまでフォールトトレランスを実現するために高価なハードウェアで二重化などを実現してきたかと思います。これからはもっと、ソフトウェアレベルでどのように障害に耐えられる設計を行えるか、ということになっていくのではないでしょうか。最後に「運用でカバー」せずにシステム・デザインの段階で運用上の問題や課題をきちんと網羅したインフラ設計が必要になってきます。またインフラについては「壊れても大丈夫」な環境を目標としてデザインを作っていきたいですね。
ここまでクラウドサービスを利用する観点から書いてきましたが本当の意味でトラブルが発生したときに最初にすべきことは何でしょうか。自分がIT担当者の場合でも、サーバを保守するエンジニアの場合でも、サービスを提供しているプログラマの場合でも、一番最初にしなければいけないことは唯ひとつです。それは、「問題を正確に把握しましょう」ということです。
長年IT業界でいろいろなシステムの運用に携わってきてとくに感じるのは、誰が一番最初に障害を認識したかによって、そのあとの動きが非常に変わってくるということです。とくに、「動かない」「遅い」などのキーワードは「主語」「述語」などを明確にしていく必要があります。
最近あったトラブルでは、「クラウドにサーバをマイグレーションしているが動作が遅い」という問題が報告されました。この連絡を受けたサービス担当者は、利用者がSSL-VPN経由で利用していたこともあり「インターネット接続が遅い」ということだと思い込んでしまったのです。実際にはこれは、アプリケーションのコーディングの問題であったのですが、初動で基盤上の問題であると報告され実際に速度を測定したりと、かなりの工数をかけてトラブル対応した結果「問題はない」という報告をした経緯がありました。このようにトラブル自体が何であるかを正しく報告者と合意して確認しないと、結果的に大きく遠回りをすることになったりします。
そうすれば確実に一歩ずつ問題の原因にたどり着くことができます。
- 第1特集
MySQL アプリ開発者の必修5科目
不意なトラブルに困らないためのRDB基礎知識
- 第2特集
「知りたい」「使いたい」「発信したい」をかなえる
OSSソースコードリーディングのススメ
- 特別企画
企業のシステムを支えるOSとエコシステムの全貌
［特別企画］Red Hat Enterprise Linux 9最新ガイド
- 短期連載
今さら聞けないSSH
［前編］リモートログインとコマンドの実行
- 短期連載
MySQLで学ぶ文字コード
［最終回］文字コードのハマりどころTips集
- 短期連載
新生「Ansible」徹底解説
［4］Playbookの実行環境（基礎編）
