トラブルシューティングの極意―達人に訊く問題解決のヒント

第8回 [クラウド編]SoftLayerの運用でわかったこと―クラウド環境でとくに必要な複数視点

この記事を読むのに必要な時間:およそ 3 分

クラウドネイティブが生まれてこようとしている時代です。サーバを実際に見たことがないという人も増えてくるかと思います。しかしながら,世の中からサーバやケーブルがなくなったわけでもありません。クラウドという抽象化されたサービスになりOSがどのような環境で動作しているか見えにくくなっていますが,クラウド企業のデータセンタの中では確かにサーバが存在しています。

トラシュー事例(初級編)
システム面からだけでは解決できないトラブル

これからクラウドコンピューティングを学ぼうとしてる人にとってクラウドコンピューティング環境と仮想化環境とでは何が違うのか,という点は疑問を持たれる人が多いかと思います。普段使っていても,意識しないとその差は表面的には見えないと思います。

新人「先輩,何も問題がないのにアクセスできません!」

あるとき,とあるサーバでパフォーマンスの問題が発生しました。そのシステムはWebシステムで,従来のオンプレミスで構築するように,負荷分散装置(Load Balancer)を経由して,Webサーバにアクセスされるように設計されています。アクセス数が増えることを想定してサーバのCPUやメモリを見積もり,運用中はモニタリングをしていました。ところが,ユーザからシステムにつながらないという問い合わせが多数ありました。実際にSEがWebサーバを確認してもやはりその時間につながらないと通知が来ていますが,Webサーバ側にはゆるいアクセスしかない状況です。またHTTPサーバを調べてみても,リクエストに対して正常に応答しているログしか見つけることができませんでした。

見えるところと見えないところ

さてクラウド上のサーバを利用していると忘れがちですが,クラウドサービスの多くは「パフォーマンス」「トランザクション」などの指標で契約を行うことが多くあります。クラウドとオンプレミスの違いとして「最大のパフォーマンス」を常に利用者が享受できるわけではないということがあります。同じ仮想化のしくみとしても,オンプレミスの場合にはリソースをすべてユーザが自由に利用できます。また,クライアントからサーバに至るまでのさまざまな経路を調査することもできます。ところがクラウドの場合にはユーザから見えるのは提供されるリソースだけになります。今回のケースではエンジニアが調べられる範囲は非常に狭く,Webサーバしか実際には調べることができません。

問題に立ち返ってみましょう

今回のケースは「システム的なトラブルはないのに利用者にサービスを提供できていない」という事象にあたります。クラウドは「共有サービス」ですのでパフォーマンスが安定しないという話がよく出たりしますが,早合点をしてはいけません。実は今回のトラブルの原因は,⁠負荷分散装置を『低リソース』で契約していたこと」だったのです。筆者が勤める会社でも,昨年から利用しているパブリッククラウドのSoftLayerではLoad Balancerが「同時接続数」で契約されます。つまりどんなにWebサーバのリソースを強化して分散させても,そもそも契約上の制約で処理ができないとうオチでした図1)⁠今回の新人君へは,

  • 「まず環境をキチンと理解する必要があるよ。とくにクラウドの場合にはどのようなサービスとして利用しているか最初に把握したほうがいい。それと障害分析もブラックボックスになりがちなのでサポートセンターとは密に連絡を取るほうがいいよ。通信できない,ケーブル挿せよっていうレベルの話を見落としがちだからね」

とアドバイスしたいと思います。

図1 初級編のトラブルの概要

図1 初級編の想定システム

クラウド時代のトラブルシューティングの基礎

クラウドとは高度に抽象化された世界で実現されています。システムの基本となるネットワーク,ストレージそしてコンピュートノードすべてが仮想化されて動いています。これはオンプレミスで仮想化環境を作っても同じことが言えます。クラウドサービスを利用すると,この抽象化がどのように実装されているか利用者からはまったく見えないため「見えている」範囲で問題を解決していく必要があります図2)⁠

図2 クラウドサービスの見え方

図2 クラウドサービスの見え方

実際には,オンプレミスでも原因を追跡するのは本当に難しい問題です。また,いかにオープンに見えるクラウドでも実際のハードウェアレベルまで行くと実装は非公開です。クラウドというのは実はプロプライエタリな環境であったりします。したがってトラブルが発生した際には,まず「クラウドサービス側で問題が発生していないか,原因はどこにあると推測できるのか」をサポートに確認してみることをお勧めします。

基礎的な知識が想像力を産む

たとえばクラウドサービスの基盤側で障害が発生していたとします。その情報はすばやくユーザに提供されると良いのですが,実際には提供されるとしても少し遅れて通知されると思います。その期間ユーザには何が起こっているでしょうか? もしかしたら顧客に提供しているWebサービスが利用できない状態になっているかもしれません。場合によっては保守用のネットワークが利用できず開発者が困っているかもしれません。

これらの「症状」を利用者が認識してからトラブルシューティングをしていくことになります。オンプレミスで構築され,すべてが把握されている状態と違い,原因や影響範囲をクラウド事業者が連絡してくれない場合には,その「症状」から何が問題であるかを紐解いていく必要があります。まずはユーザが管理できる範囲の対象で「エラー」「警告」が出ていないかをチェックしたり,前日との変更点を調査したりしていきます。しかしながら,問題の原因はどうもアプリケーションでもOSでもなさそうだとなり,今回のようにそれ以外の個所で発生しているようだとわかるケースがあります。

クラウドサービスは,一見どのように動いているかわからない場合でも実際に「雲」であることはなく,何らかの技術で作られたシステムなのです。突然にパケットが別の場所にワープすることはないので,オンプレミス環境でこれまで得た知見を活用して該当個所を推測していくことが重要です。クラウドになったのでインフラの知識が不要になるわけではなく,逆にどのような仮想化技術が使われているのだろうと想像力を働かせて利用していく必要があります。むしろ見えないからこそ,基礎をしっかり理解しておく必要があります。

著者プロフィール

常田秀明(ときたひであき)

日本情報通信 クラウドエバンジェリスト

ネットワークエンジニアや大規模システムの運用マネージメントを経て,現在はクラウドエンジニアとしてIBMのBluemixをおもに担当しています。お客様のクラウド化支援や昨今のチャットボットなどの最近のアプリケーション開発支援を担う傍ら,エバンジェリストとして社外講演やユーザコミュニティ運営などに携わっています。2017年よりBluemix Users Group代表。

バックナンバー

トラブルシューティングの極意―達人に訊く問題解決のヒント

バックナンバー一覧

コメント

コメントの記入