“知らないと損をする!? クラウド運用の豆知識”
AWSに見るメンテナンスイベントへの対応

クラウドを利用するメリットの1つとして、運用負荷の軽減が挙げられることが多い。一方でサービスのメンテナンスなど、クラウド特有の運用にかかわるイベントを意識する必要があるのも事実だ。ここでは、特にAmazon Web Services(以下、AWS)を対象として、イベントの内容や求められる対応について見ていきたい。

知らないと損をする!? クラウド運用の豆知識” AWSに見るメンテナンスイベントへの対応:クラウドを利用するメリットの1つとして、運用負荷の軽減が挙げられることが多い。一方でサービスのメンテナンスなど、クラウド特有の運用にかかわるイベントを意識する必要があるのも事実だ。ここでは、特にAmazon Web Services(以下、AWS)を対象として、イベントの内容や求められる対応について見ていきたい。
研修が終わってようやく本番だね!よろしくお願いします!今日は知らないと損をするクラウド運用の豆知識を伝えておくよ。え クラウド運用の豆知識ですか…嫌か? い…いえ。クラウドにはメンテナンスなど運用にかかわるイベントを意識する必要があるんだ。イベントですか?
そう ではまずIaaS はい IaaSはハードウェア障害など発生した際クラウドベンダー側で自動的に対処されるんだ。それはいいですね。ただしメンテナンスなどのイベントを見逃せば予期せぬシステム停止につながるので注意も必要だ。えっ それは大変ですね。次にAmazon Web Servicesね Amazon Web Servicesもさまざまなサービスに対してメンテナンスやアップデートを行っている 内容によってはインスタンスの再起動やサービスの停止が伴う場合もあるんだ。そうなんですか。ちなみにAmazon Web Servicesはメール通知だけでなくAmazon Web ServicesマネジメントコンソールやPersonal Health Dashboardからもイベントを確認することができるんだ ※AWS…Amazon Web Services
イベントの具体的な対応についてEC2を参考にしてみよう。はい!EC2のメンテナンスにはインスタンスの再起動とシステムの再起動の2種類があるんだよ インスタンスの再起動であればコンソールから再起動をするだけでいいけどシステムの再起動の場合はちょっと大変だね。大変…何が大変なんですか?まずシステムを再起動する前には前もってインスタンスを停止しておく必要があるんだ
データベースをメンテナンス中インスタンスがオフラインになればサービスが接続できなくなるんだよ Amazon Web Servicesなどのサービス側からメンテナンスの案内から利用者側が事前にイベントを察知して適切に対応をする必要があるんだ。いろいろと対応が必要になるんですね 常にイベント情報を監視して毎回対応をするなんて私には無理です!だからうちはNTT Comにアウトソースしてるんだ。え!NTT ComのAWS導入支援・運用サービスがAmazon Web Services環境の運用を一元的にしてくれるんだ。それを早く言ってください!
続きを読む

クラウドを利用するメリットの1つとして、運用負荷の軽減が挙げられることが多い。一方でサービスのメンテナンスやセキュリティなど、クラウド特有の運用にかかわるイベントを意識する必要があるのも事実だ。ここでは、特にAmazon Web Services(以下、AWS)を対象として、イベントの内容や求められる対応について見ていきたい。

クラウド特有の運用管理業務

クラウドを利用するメリットの1つとして、運用負荷の軽減が挙げられることが多い。たとえばIaaSであればハードウェア障害などが発生した際、クラウドベンダー側で自動的に対処されるため、ユーザー側の負担が軽減するというわけだ。

これは間違いないのだが、一方でサービスのメンテナンスなど、クラウド特有の運用にかかわるイベントを意識する必要があるのも事実だ。もしメンテナンスに関するイベントが予定されていて、その通知を見逃せば予期せぬシステム停止につながりかねない。

ここでは、特にAmazon Web Services(以下、AWS)を対象として、イベントの内容や求められる対応について見ていきたい。

AWSにおけるイベントの事前通知

AWSではさまざまなサービスに対し、機能強化や性能改善、あるいは脆弱性への対応などを目的としたメンテナンスやアップデートを行っている。

このメンテナンスは透過的、つまりサービス提供を維持しながら行われる場合もあるが、内容によってはインスタンスの再起動やサービスの停止が伴う場合もある。

再起動が必要、あるいはサービス停止ともなれば、当然AWSを利用しているシステムの運用にも影響が生じるため、何らかの形で対応しなければならない。

そこで重要となるのは、メンテナンスやアップデートといったイベントの把握だ。AWSではメールでの通知のほか、「AWSマネジメントコンソール」や「Personal Health Dashboard」でイベントを確認することができる。

「AWS Health API」を利用すれば、API経由でHealth情報にアクセスし、各種イベントの情報を取得することが可能である。この情報を定期的に取得し、運用に利用しているメーリングリストのほか、ビジネス向けチャットツール「Slack」や、Office 365のハブとしてチャットやファイル共有、ビデオ通話も可能な「Microsoft Teams」で通知するなどといった利用が考えられるだろう。

AWSの運用で想定されるイベント

ここでは、AWSの運用中に想定される具体的なイベントの詳細を紹介する。

定常作業

定常作業は、それぞれのサービスで定期的に発生するイベントだ。サービスごとに、以下一覧のような定常作業が発生する。

サービス イベント
ACM(AWS Certificate Manager) 証明書の有効期限切れ/自動更新の失敗
Amazon Route 53 ドメインの有効期限切れ
Amazon EC2・Amazon RDS(Amazon Relational Database Service)など リザーブドインスタンスの有効期限切れ
AWS Trusted Advisor メール通知

ACMは、SSL証明書を発行するサービスのこと。ACMが発行する証明書の有効期限は1年で、13カ月を過ぎると自動更新される仕組みとなっている。しかし、場合によっては自動更新が失敗するケースがあり、証明書の有効期限切れや自動更新失敗のイベントが発生する。この場合、証明書の手動更新が必要だ。

Amazon Route 53は、エンドユーザーをサイトに接続するドメインネームシステム。Route 53で取得したドメインは1年ごとに更新が必要だ。自動更新を無効化している場合、有効期限の45日前にメールで通知が届くため、有効期限が切れる前に手動での更新をおこなわなければならない。期限までに更新がおこなわれなかった場合、ドメインが有効期限切れとなってしまう。

Amazon EC2やAmazon RDSには「リザーブドインスタンス」といわれる課金方式があり、1年もしくは3年の利用期間を指定して料金を前払いすると、最大で72%の割引が受けられる。この契約は自動更新されないため、1年もしくは3年の期間を過ぎるとリザーブドの有効期限切れが起きてしまう。継続利用する場合、忘れずにリザーブドインスタンスを購入しておく必要がある。

AWS Trusted Advisorは、ユーザーの利用状況をモニタリングし、よりよいプランを通知するサービス。通知が届いたら、提案内容に応じた対応を行う。ただし、あくまでも推奨のため必ずしも対応が必要なわけではなく、その都度ユーザーが実施可否を判断する必要がある。

申請作業

AWSでは利用状況や作業内容によって申請が必要なケースがある。申請しなければならない具体例として、以下一覧が挙げられる。

サービス イベント
ELB(Elastic Load Balancing) システムへの大量アクセスが想定される場合
AWS系サービス全般 ・負荷テストの実施
・侵入テストの実施
・リソース数の上限に抵触

ELBはAWSが提供するロードバランサで、リクエストを複数のサーバーに振り分けるサービス。メディアでの紹介など、システムへの大量なアクセスが予想される場合、申請を行うことで事前にスケールアウトが可能だ。

負荷テストや侵入テストを行う場合、事前に申請していなければ不正なアクセスと見なされてアカウントがロックされるおそれがある。そのため、これらのテストを実施する場合は忘れず申請しておかなければならない。

AWSはサービスごとにリソース数の上限が設けられており、その上限を超えて利用したい場合には申請が必要となる。リソースの種類によっては上限を増やせないものもあり、上限を増やせる場合でも無制限に緩和できるわけではない点に注意しなければならない。

緊急作業

AWSサーバーのメンテナンスやトラブル発生時には、以下一覧のような緊急作業のイベントが発生する。

サービス イベント
Amazon EC2 ・ホストのリタイアメント
・AMI(Amazon Machine Image)のリリース
Amazon RDS 緊急パッチのリリース
AWS Direct Connect 緊急もしくは計画的なメンテナンス
Amazon VPC(Amazon Virtual Private Cloud) VPN接続のメンテナンス

AWSのようなクラウドサービスは、ユーザーがサーバーを意識せずに利用できるのが特徴だ。しかし、クラウドの向こうでは当然ながら物理サーバーが稼働していて、次第に老朽化していく。AWSでは老朽化したサーバーを退役させる際にEC2インスタンスの停止と起動を行うようユーザーに通知する。この作業によって、インスタンスが別の物理サーバーへ移動するようになっている。

リレーショナルデータベースサービスであるRDSは、OSなどに脆弱性が発見されると強制適用の緊急パッチがリリースされるケースがある。その際、インスタンスを再起動しなければならない。

EC2インスタンスを作成する際、AMIといわれるOSやアカウントの権限などのテンプレートを指定する。このAMIはそれなりの頻度で更新され、状況に応じて対応が必要だ。例えばAuto Scalingの起動設定に公式のAMIを利用している場合、AMIを変更しなければAuto Scalingが機能しない可能性がある。

Direct Connectは、AWSとユーザーの拠点を専用回線で接続するサービス。不定期にメンテナンスが実施され、計画的な作業だけでなく緊急メンテナンスが実施されるケースもある。いずれの場合も、冗長化していればユーザー側での対応は特に必要ない。

VPCはAWS上に仮想ネットワークを構築できるサービスで、VPN接続のメンテナンスが発生する。VPNトンネルが冗長化されていれば、ユーザー側にメンテナンスの影響はほぼない。

属人作業

何らかのイレギュラーな事態が起きると、AWSから対応を求める通知が届く。例えば、以下一覧のようなケースだ。

サービス イベント
AWS系サービス全般 Abuse Report
Amazon SES(Simple Email Service) エンフォースメント
AWS Lambda ランタイムのサポート終了
AWS Elastic Beanstalk プラットフォームの更新
AWS Shield Advanced DDoS攻撃の検知
ELB セキュリティポリシーの廃止
Amazon EC2 OS(Amazon Linux)のサポートライフサイクル

サービスに関わらずAWSアカウント上で何らかの問題行動が検知されると、Abuse Reportが届くようになっている。例えば、SMTPサーバーがスパムメールの送信元になっていたり、DDoS攻撃の攻撃元になっていたりする場合だ。この通知が届いたら、状況に応じた早急な対応が求められる。

メール配信サービスであるSESは、配信したメールに対する苦情などが多い場合にエンフォースメントの通知を出すようになっている。例えば送信停止処分の執行猶予状態になった場合、送信停止措置が実行される前に問題を解消しなければならない。

Lambdaはプログラムの実行環境を提供するサービスで、ランタイムのサポートを終了するケースがある。利用中のランタイムがサポート終了となる場合は、別のランタイムへの移行が求められる。

サーバー構築時の設定を自動化できるElastic Beanstalkは、定期的にプラットフォームが更新される。メジャーバージョンアップなどの際には、手動での更新作業が必要になるケースがある。

Shelad AdvanceはDDoS攻撃の検知や遮断を行うサービスで、攻撃を検知すると通知を出すようになっている。通知が届いたら、攻撃への対応を実施しなければならない。

ELBでHTTPSを利用する際にセキュリティポリシーを指定するが、暗号化方式などに脆弱性が見つかるとそのセキュリティポリシーが廃止される可能性がある。その場合、必要に応じてクライアントの動作検証などを実施する。

AWSはLinux OSを提供しており、新たなOSがリリースされると従来のOSはサポートが終了する。例えば、Amazon Linux 2のサポート期間は2025年6月30日までだ。サポート終了までに、新たなOSへの移行やアプリケーションの動作検証などを行う必要がある。

EC2におけるメンテナンスへの対応

それではイベントに対する具体的な対応について、EC2を例に見ていこう。EC2のヘルプページによれば、Amazon EC2の予定されたメンテナンスにおける再起動には、インスタンスの再起動と、システムの再起動の2種類があるとしている。

システムの再起動は、インスタンスを実行している物理サーバーの再起動である。インスタンスの再起動であれば、ゲストOS上で再起動、あるいは「EC2 Management Console」で再起動を行うだけで済むが、システムの再起動であればインスタンスを一度Stopし、改めてStartを選択しなければならない。また、このようにシステムを再起動した場合、パブリックIPが変更になるため、Elastic IPの検討が必要だ。

なお再起動のスケジュールは自動で設定されるが、その前であればユーザー自身で再起動を行うことができる。

再起動による影響を最小限に抑えるためには、EC2で実行しているインスタンスに対するイベントを定期的にチェックし、再起動を伴うイベントが発生した際はメンテナンス時間を設定した上で事前に再起動を行うなどの対処が求められるだろう。

複雑なAmazon RDSのメンテナンスへの対応

AWSで構築したシステムのデータベースとして広く使われている、Amazon RDSでも当然ながらメンテナンスが行われている。

Amazon RDSのヘルプページを見てみると、「一部のメンテナンス項目では、Amazon RDSがDBインスタンスを少しの間オフラインにする必要があります」と記載している。つまりメンテナンスにより、アプリケーションサーバーなどからデータベースへ接続できないといった事態が生じる可能性があるわけだ。

なおAmazon RDSのメンテナンスには、ユーザーによる延期が不可能な「必須」、メンテナンスを実行可能だが自動的には行われない「利用可能」、次回のメンテナンスウィンドウ中に適用される「次のウィンドウ」、そしてメンテナンスアクションが適用中であることを示す「進行中」の4つのステータスがある。

ちなみに東京リージョンにおけるAmazon RDSでは、13:00~21:00 UTC(日本標準時で22時から6時)のうちの30分がメンテナンスウィンドウに割り当てられる。13:00~21:00のうちのどの30分かはランダムである。またDBインスタンス作成時にメンテナンスウィンドウの曜日を指定しなければ、ランダムで選択された曜日に30分のメンテナンスウィンドウが割り当てられる。

システムの内容や構成によってはデータベースのサービス停止の影響が大きくなるため、事前にイベントの情報を収集し、必要に応じてメンテナンスウィンドウの日時を指定したり、指定した日時と影響についてユーザーなどへ周知したりする対応が必要になるだろう。

クラウドであってもアウトソースを視野に

本記事で紹介したとおり、AWSでは各サービスごとにさまざまなイベントが発生する。このようなイベントに慌てずに対処するためには、イベントの種類ごとに対応を細かく決めておくといった運用設計が何よりも重要である。

しかしながらただ運用設計を行っていても、利用しているサービスやインスタンスの数が膨大になれば、すべてのイベントを把握して適切に対処することは容易ではない。そこで検討したいのが、AWSに精通しているITパートナーへの運用のアウトソースである。

たとえばNTTコミュニケーションズでは、複雑化・グローバル化するICTオペレーションを、デジタルの力を活用し、シンプルにRe-Designすることで、ビジネスのスピードに追随するアジリティの高いITへの変革を支援する「X Managed®」を提供している。

そのサービスメニューの1つに「AWS導入支援サービス」があり、AWS環境の運用を一元的に対応できる体制が整えられている。AWSを本格的に活用するのであれば、こうしたサービスの利用も検討すべきだ。

コラム一覧へ

このページのトップへ