Web系から業務系まで，さまざまなシステムがクラウドで構築されるようになりましたが，システムの基盤がオンプレミスからクラウドに移行しただけで，トラブルや障害がなくなるわけではありません。今回は，Amazon Web Services（以下，AWS）上で構築されたシステムに関するトラブルシューティングについて，実例を交えて解説します。

トラシュー事例（初級編）
本番環境に突然ログインできなくなった！

AWSでシステムを運用している場合，サーバ内部のメンテナンスはSSHやRDPといった技術を使ってリモートログインしてから行うようになり，オンプレミス環境での電源OFF／ONなどの物理的な作業はAPIやAWS Management Consoleから操作するようになりました。

初級編のトラブルは図1のようにWebサーバ，アプリケーションサーバ（App⁠）⁠，データベースサーバ（DB）をAmazon EC2（以下，EC2）を使って構築したシステムで発生したものを想定します。ある日，サーバのメンテナンスを目的としてメンテナンス拠点からログインしようとしましたが，ログインできませんでした。監視サーバは異常を検知しておらず，サービスにも影響は出ていないようですが，メンテナンスができなくなったので急遽原因の調査をすることになりました。

原因調査と対策例

トラブル対応時にまずやるべきことは，表示されているエラー，ログ，監視サーバの監視状況などから現状を把握することです。今回のケースはサーバにログインすることができない状況ですが，リモートからログインを試みて失敗したときのエラー内容からも解決の糸口をつかむことができます。またサーバ内のログをサーバ外部に転送している場合は，転送されたログの内容からも手がかりをつかめます。今回の場合，SSHでログインを試みると次のようなエラーが出力されていました。

ssh: connect to host web.example.com port 22: No route to host

発生しているトラブルの内容から，次のような仮説を立てることができると思います。

• ① 名前解決はできているが，メンテナス拠点からEC2インスタンスの22番ポートにアクセスができない
• ② メンテナス拠点，監視拠点からともにサービスにアクセスできるので，EC2インスタンスがダウンしている可能性は低い
• ③ メンテナンス拠点からサービスを利用できるため，メンテナス拠点からEC2インスタンスへのルーティング設定に問題がある可能性は低い
• ④ 監視拠点からはサービスの利用，SSHアクセスともにできていることから，SSHサーバのプロセスがダウンしている可能性は低い

しかし，情報に誤りがあって間違った仮説を立てている可能性もあります。そのため，このような仮説が間違っていないことを順序立てて確認することも大切です。

トラブル発生時の仮説検証や問題切り分けの進め方としては，クラウド環境でも低いレイヤから行ったほうがわかりやすいように思います。

オンプレミス環境での物理的障害に近いものからチェックを始めます。EC2インスタンスも仮想サーバを稼働させている物理ホストの影響を受けてダウンする場合もありますが，そのような場合は監視サーバからもアクセスができなくなり障害を検知するはずです。EC2インスタンスが正常に稼働しているか確認するためには次のような情報をAPIやManagement Consoleでチェックすると判断がつくかと思います。

• Instance Stateがrunning状態にあること
• System status ckecksがpassed（0）状態であること

また，EC2インスタンスのパブリックIPを固定化する機能であるElastic IPの状態もチェックしてみてください。誤ってこれを取り外してしまうとアクセスができなくなりますが，そのような状態であった場合，監視サーバからもアクセスが失敗するはずですので原因となっている可能性は低いです。

EC2インスタンスがダウンしていないことが確認できたら，次の確認に移ります。EC2インスタンスはAmazon VPC（以下，VPC）と呼ばれるユーザ専用の仮想ネットワーク空間上で稼働しています。VPCの中ではユーザが好きなようにルーティング設定ができるようになっており，VPCから直接インターネットにアクセスする場合はインターネットゲートウェイへ正しくルーティングされている必要があります。ルーティング設定が誤っている場合はメンテナンス拠点からのSSH以外のプロトコルも通信に失敗するため，この点についても問題となっている可能性は低いですが，低レイヤの確認事項としてチェックしましょう。

設定ミスによって思わぬトラブルにつながる

ここまでで物理的，ネットワーク的には問題がないことが再確認できましたので，さらに上のレイヤをチェックしましょう。レイヤ3，レイヤ4のアクセス制御としてEC2にはSecurity Groupという機能があります（注1⁠）⁠。これはアクセス元，アクセス先のIPアドレスや，プロトコル，ポート番号による制御を可能にします。Security Groupについてチェックしたいポイントは次の2点となります。

• EC2インスタンスに正しいSecurity Groupが割り当てられているか
• 割り当てられているSecurity Groupにメンテナンス拠点からのアクセスが許可されているか

この段階で「メンテナンス拠点のアクセス許可ルールを誤って削除してしまったためトラブルへとつながった」ことがわかりました。

注1）

その他ネットワークレベルのアクセス制御としてNetworks ACLという機能があります。

IAMによる権限設定とAWS Config，Cloud Trailによる追跡

AWSにはIAMという権限管理のサービスもあります。Security Groupのルール設定は適切な権限を持つ人にのみ付与して，それ以外の人は参照のみ可能というように制限することができます。この機能を活用することで，適切な権限を持つ管理者だけがSecurity Groupのルールを削除可能，ということを実現できます。

また，AWS Configを利用することでAWSリソースの変更を追跡をすることや，CloudTrailを利用することでAWSリソースの操作などをログとして保管することも可能となります。トラブルが発生したときに原因を追う手がかりにもなりますので，これらはぜひ有効にしたい機能です。

AWSに限らずクラウドサービスではAPIが提供されているものが数多くあります。筆者が担当しているサービスではAWS SDK for RubyとRSpecを使ってAWSアカウントのあるべき状態をテストコードに定義して，AWSリソースに意図しない変化が発生した場合にはテストが失敗するようになっています（注2⁠）⁠。このような工夫をすることでトラブルの早期発見と防止につなげられると思います。

注2）

サンプルコードをhttps://github.com/serverworks/aws-specに公開しています。