[AWSの運用] 障害復旧(一次対応)

AWSの運用代行サービスの中身 大公開

AWS環境を自社で運用するポイントや、ディーネットの運用サービスをご紹介。

文章ではなく、スライドでパパっと見たい人は、Instagramがおススメです。

障害復旧とは

障害復旧とは
障害復旧とは

WEBサービスの運用をしていると、突然動作不良に陥ることがあります。

その時に、取り急ぎ正常な状態に戻すことを障害復旧といいます。「取り急ぎ」と書いたのは、根本原因の解消ではなく、復旧を優先するからです。

復旧方法は大きく分けて2種類あります。
・動作不良の場合
・過負荷の場合

以降でそれぞれの場合の、代表的な復旧方法について解説していきます。

復旧手順

動作不良の場合の復旧手順

動作不良の場合の復旧方法
動作不良の場合の復旧方法

何かしらの原因で動作不良となってしまった場合は、再起動で復旧を行います。可能な限り影響範囲が狭い「プロセス再起動」での復旧をおすすめしています。

■プロセス再起動
動作不良を起こしているプロセスを再起動します。
メリットは停止時間の短さと、影響範囲の狭さです。デメリットとしては、インスタンスへのログインが必要になります。問題プロセスの特定や再起動手順など、一定の技術力が必要になります。

■インスタンス再起動
AWSのマネジメントコンソール、またはEC2ログイン後のリブートコマンドにてインスタンスの再起動を行います。パソコンの動作が不安定なときに再起動するのと同じ要領です。
メリットは、ブラウザベースでどこからでも実行できる点です。ただし、相応の時間がかかります。メモリ情報もクリアされてしまうので、起動直後に過負荷となる懸念もあります。

過負荷の場合の復旧手順

過負荷の場合の復旧方法
過負荷の場合の復旧方法

アクセス数の増加などの過負荷による障害の場合は、再起動では復旧しないことがあります。その場合は次のように対応します。

■スケールアウト(アップ)
インスタンスの台数を増やす、または上位のタイプに変更することでキャパシティの追加を行います。必要なときに、必要なキャパシティを調達できるのはクラウドを利用するメリットでもあります。AWSではインフラキャパシティを大幅に増やすことができます。ただし、「システム全体のキャパシティ」と考えるとどこかで頭打ちとなります。システムが最初に頭打ちになる原因を事前に把握することが重要です。

■原因排除
過負荷には必ず原因があります。原因を特定し排除することで過負荷の状態から復旧させます。よくあるケースとしては、BOTによるアクセスです。WEBサービスには、人以外にも、BOTのような機械的なアクセスが日常的に発生しています。短時間に集中して望まないBOTがアクセスしてくるケースも多く、BOTのアクセスを拒否するなどして対応します。

復旧方法

自動復旧

自動復旧
自動復旧

まず初めに検討したいのが自動復旧です。

自動復旧の仕組みを作ることで、いつでも、早く、正確に復旧させることができます。自動復旧では、あらかじめ再起動させるためのトリガーを決めておきます。トリガーが起動したときに行う操作内容についても事前に決めます。

たとえば、CloudWatchを利用した自動復旧を考えます。

CloudWatchで、インスタンスの監視を行います。インスタンス内のプロセス監視を行う場合は、CloudWatchAgentのインストールが必要です。

CloudWatchにて異常を検知した場合はCloudWatch Alarmへ通知しインスタンスの再起動等の操作を実行させます。AWS System Managerを組み合わせることで、プロセス再起動も可能です。

手動復旧

手動復旧
手動復旧

自動復旧が実装できない、事前に想定していなかったため復旧しなかった場合は、手動で復旧させる必要があります。

手動の場合は人によって対応のばらつきが出やすくなります。誰でも一定の品質で対応ができるようにあらかじめ手順書を作っておきましょう。

手動の場合も自動の場合と同様にアラート通知を受けて対応が開始されます。CloudWatchなどの監視システムやユーザーからの問い合わせの場合もあります。

自動復旧ではイレギュラーな事象が発生した場合に対応できませんが、手動復旧の場合は柔軟な対応が可能になります。ただし、対応者のスキルに大きく依存します。

お客様にて障害復旧を行うポイント

お客様にて障害復旧をするポイント
お客様にて障害復旧をするポイント

お客様にて障害復旧対応をする場合は、システムの特性に合わせて復旧方法を使い分けてみましょう。

■自動復旧のポイント
自動復旧を行う場合は、事前の準備が重要になります。「想定外」が少なくなるような設計はもちろん、CloudWatchやSSM、AutoScaling、Zabbixなど様々な技術要素を組み合わせることも重要です。また、AutoScalingを使う場合は、正常に対応可能なインフラ環境を事前準備する必要があります。

■手動復旧のポイント
手動復旧を行う場合は、体制構築がポイントとなります。昼夜問わず一定レベル以上の対応ができる体制をいかに構築するかが重要になります。

ディーネットの運用代行サービスでは

ディーネットの障害復旧対応
ディーネットの障害復旧対応

ディーネットがお客様にかわり、障害復旧対応の代行をいたします。お客様にAWSの技術知識や体制は不要です。

お客様が運用するサービスの特性に合わせて、エンジニアが監視設計から設定、復旧対応まで実施いたします。24時間365日体制のテクニカルサポートが支援するため、昼夜問わず対応します。

また、お客様にて構築しブラックボックス化してしまった環境や、復旧手順書がない場合は、弊社にて復旧手順書の作成を代行も可能です。

まとめ

最後までご覧いただきありがとうございます
最後までご覧いただきありがとうございます

この記事では、AWS上で動かすWEBサービスで発生した障害の復旧手順について解説しました。

障害は昼夜問わず発生します。いつ起きるかもわかりません。

自動復旧や手動復旧など復旧方法はいくつかありますが、いずれも事前に可能な限りの用意をしておくことが重要です。

自社で対応が難しい場合は、ディーネットまでお問い合わせください。24時間365日体制のテクニカルサポートがご支援いたします。

ミドルウェア含めた一気通貫のサポート

ディーネットはAWSのアドバンストコンサルティングパートナーです。

AWSの提案から運用監視まですべてお任せください。

AWS運用代行サービスの詳細は、こちらをご確認ください。