ブログ

初心者のためのAWS運用TIPS 保守 〜業務イメージ編〜

本ブログではAWSでのインフラ運用が初心者の方に向けて記載しています。

AWSにてサーバーを構築することを考えていらっしゃる方、オンプレミス環境から移行を考えていらっしゃる方、かつ、規模 [※1] として1~3台程度のWebサーバーの運用環境を想定いたします。

構築後の実運用イメージを持っていただき、その上で「ご自身による対応が可能」か、「保守サービスの依頼をすべき」かを判断するための情報サポートになれば幸いです。

[※1] 仮定する環境の規模として、EC2にWordPressをインストールし、Webサーバーを24時間、365日運用するものとします。データベースにはRDS for MySQLを使用いたします。

AWSにてサーバーを運用する場合に想定される保守業務

アプリケーションを運用する際、動かすためのインフラ(サーバーなど)が必要です。インフラ(サーバーなど)は構築が完了した後に運用、保守業務が必要となります。

運用業務と保守業務は定義が被ることも多いですが、本ブログではわかりやすくWebサーバーを24時間365日落ちることがない様にする業務として説明させていただきます。

いきなり前提を覆してしまいますが、24時間365日全く落とさない様にすることはできません。矛盾している様ですが、24時間365日運用させるために必要なメンテナンス作業を行うと、どうしてもダウンタイムが発生するためです。

業務に影響が発生しない様にダウンタイム発生時間を調整したり、想定できる障害回避策を行ったり、想定外の障害が発生した時に可能な限り早く復旧する業務が保守業務です。

保守業務は、下記の2種類に分けることができます。

1. 通常時保守業務

メンテナンス(AWSからのメンテナンス通知対応)

EC2 や RDS のハードウェアメンテナンスが行われる場合があります。これはAWSが老朽化したハードウェアを対象に行うため、対象のハードウェア上で起動している EC2 や RDS は全てメンテナンスの対象となります。

AWSからメンテナンス時間は事前に通知されるため、指定時間は業務影響を及ぼす場合、メンテナンス開始時間までに保守担当者が別のハードウェアを利用する様に対応を行う必要があります。業務影響がない、または可能な限り小さく済む時間にダウンタイムをずらす対応です。

サーバーのスペック管理(メモリやストレージ管理など)

EC2 や RDS はインスタンスタイプを選ぶことが可能で、それによってメモリやCPUの性能が代わります。また、ストレージを後から増やしたり、外すことも可能です。過剰なスペックを用意すると無駄に運用費がかかり、必要なスペックを下回るとWebサービスの運用に影響が出てしまい、サイトのダウンにつながります。サイト表示やCPU負荷などを確認して、適切なスペックを調整する必要があります。

セキュリティ設定

ファイアーウォールやネットワークレベルでのアクセス制限などはエンドユーザーの変更によって設定が変わることがあるため、管理する必要があります。また、 WAF やウィルス対策なども行い、異常発生時は保守担当へ通知させる様に設定しておくことが一般的です。

OSのバージョンアップ

EC2 にインストールしているOSや、RDS のOSは時にバージョンアップが必要となる場合があります。

一般的にサポート期限が切れる様な時期がきた場合にはAWSから通知が来るため、期限までに対応を実施することで管理が可能となります。また、RDS はマイナーバージョンアップを自動化する機能があります。こちらを有効にしておくことで、新しいバージョンが公開された際、事前に指定した時間 [※2] に自動でバージョンアップを行う様に設定が可能です。

[※2] メンテナンスウィンドウという機能を利用して、事前に指定した時間の範囲内にバージョンアップ実行を開始させることが可能です。

バックアップの管理

EC2 や RDS [※3] のバックアップを取得しておくことで、システムに致命的な障害が発生した時にバックアップからリストアすることが可能です。ただし、バックアップを保持すると当然維持費が発生してしまうため、過去何日分を保持するか、指定した期間をすぎたバックアップを削除する対応が必要です。

[※3] RDS は構築時にバックアップの日次取得時間や保持期間の設定が可能です。

アプリで使う機能のバージョン管理 [※4]

使用するアプリに依存するため、Apache や PHP のバージョンアップが必要かはアプリ開発者と連携をとる必要があります。脆弱性が発表されたバージョンなどは、バージョンアップ後にアプリが起動しないトラブルを避けるために事前にテストをして、バージョンアップを行うことが推奨されています。

[※4] 厳密にはインフラ(サーバーなど)の作業範囲ではありませんが、インフラ担当者が保守業務の一環として対応することが多いです。

2. 障害発生時保守業務

障害発生に気づくことができる様に監視設定

障害発生時の保守業務は監視設定をしておくことで速やかに対応することが可能となります。また、障害発生時はWebサイトへアクセスができなくなる場合が多く、可能な限り早く障害に気づく必要があります。そのため、監視設定は保守業務を行うために必ず必要な設定で、監視用のソフトウェアも世には多々存在します [※5]

しかしながら、AWS運用をするのであれば AWSの監視用サービスをご利用になると便利です。AWSの監視用サービスの機能説明や設定例は弊社のブログにもございます。本ブログの最後にリンクを記載しますので、よければ合わせてご覧くださいませ。

[※5] ソフトウェアは当然監視以外の機能も充実していますが、監視のために採用されるソフトウェアとして、オンプレだと以下が耳にしやすいかもしれません
・Zabbix ・hinemos ・Nagios ・mackerel

障害発生時の対応フロー管理(どんなエラーの時に誰が対応するか)

障害の原因は、ハードウェアからアプリの問題まで様々です。対応フローはもちろんですが、担当者レベルでは解決できない場合のエスカレーション先を決めておくことを推奨いたします。

例えば、Webサーバーが落ちた時に保守担当者が気づく様に監視設定をしておきます。保守担当者は Apache を再起動させるのか、 EC2 の再起動が必要なのか、最初に対応すべきフローを事前に決めておくことで、担当者のみで必要な対応を判断することができ、結果ダウンタイムが短くなります。

万が一用意しておいた対応フローでは解決しない様な想定外の障害だった場合、Webサーバーの構成に知見がある担当者へエスカレーションできる様に準備しておくことをお勧めいたします。

実際に障害が発生した場合の対応

事前に用意している対応フロー通りに対応をします。ダウンタイムを限りなく短くしたり、ヒューマンエラーを防ぐためにも対応フローを事前作成しておくことと、対応フローの手順通りに作業を行うことはとても大切です。

AWS運用の保守業務 を ご自身で対応する場合 〜想定される業務イメージ〜

保守業務をご自身で行う場合、通常時保守業務と障害発生時保守業務の対応ができる様に準備をしていただくことになります。

本ブログをご参照いただき、Webサービスを構築した開発者や、依頼している開発会社様と要件を確認しながらテスト運用していただくことをおすすめいたします。それによって予想していなかった障害が発生したり、スペック不足に事前に気づくことができるため、本番運用を開始してからダウンタイムを減らすことにつながります。

AWS運用の保守業務 を 代行サービスに依頼した場合 〜業務イメージ〜

保守業務のサービス範囲は、サポート会社によって異なります。

弊社の cloud link サービスでは、本ブログで紹介した保守業務のうち、「アプリで使う機能のバージョン管理」 以外全てサポートを行っております。

障害発生時の保守業務のみや、障害発生した事を通知する対応のみ、通常時保守業務を含む、含まないなどサポート会社が提供しているプランを確認して、どこまでご自身で対応が可能なのか調整しながら一部業務依頼することも方法の一つです。

また、運用サーバーが3台以下の小規模な環境であっても、夜間の対応が困難な場合に代行サービスをご利用いただくケースも多い様です。

弊社でも、夜間に障害が発生した場合に弊社で復旧作業を行った後にご報告の連絡を行うか、障害が発生した時点でご連絡させていただき、対応内容をご相談させていただきながら復旧作業を行うかをお選びいただいております。

AWS運用に必要な対応を認識して、保守業務のサポート依頼をするか判断ができるとベスト

保守業務のイメージを持ち、実際に運用テストを行ってみることで、運用しようとしているサービスに必要な設定が見えてきます。AWSは他の外部サービスを利用せずとも監視設定や自動化が行えることが利点です。

ご自身の業務環境が起因して保守業務が困難な場合はサポートを依頼しましょう。ご自身で保守業務を行うまでの設定に不安がある場合、コンサルを利用することも1つの手段です。

弊社でもコンサル業務は行っておりますので、ご自身で運用をするために必要な設定や障害対応をサポートさせていただき、対応が不要となりましたら契約を終了させていただくことも可能でございます。

また、下記リンクの記事を保守業務の設定にぜひお役立てください。

AWS運用でぜひ利用していただきたい監視設定 ──
AWS運用でお勧めする自動化設定 ──

元記事発行日: 2020年09月03日、最終更新日: 2024年02月28日

Related Articles