メンテナンスウィンドウを制してAWSを制す！

昨今、あらゆる業界におけるDXやデータドリブン型ビジネス、さらに生成AIにかかわる案件などの成長に伴い、国内パブリッククラウド市場が拡大を続けています。令和6年版情報通信白書によると、このまま順調に推移すると、国内のパブリッククラウドサービス市場は、売上額で2023年の3兆1,355億円から2028年には2倍以上の6兆5,146億円になると予測されています。

図表Ⅱ-1-8-5
日本のパブリッククラウドサービス市場規模（売上高）の推移及び予測

ちなみに、同調査で国内のパブリッククラウドサービス市場を牽引するのは、Amazon（Amazon Web Services：AWS）、Microsoft（Microsoft Azure ：Azure）、Google（Google Cloud：GCP）といったグローバルなIT企業です。市場で占めるシェアはAWSが37.4%、続いてAzureが30.6%、GCPが15.9%となっています。これらの海外プロバイダーは、国内ユーザーから信頼性とサービスラインナップの豊富さが高く評価されていて、なかでもAWSはそのレベルが高いと考えられます。

クラウドサービスを利用する際の大きなメリットの1つが、運用負荷の軽減です。たとえばIaaSであれば、故障が起きた場合でもクラウドベンダー側が自動で対処するので、ユーザー側にかかる稼働が軽減されます。そのうえ導入コストが抑えられる、設備導入不要ですぐに始めることができる、ユーザー間のデータ共有が容易になる、使い方によって柔軟に容量の拡張が可能といったメリットがありますが、クラウドサービスを利用するためには細心の注意も必要です。たとえば、クラウドサービスの運用にかかわるサービスメンテナンスやセキュリティといったイベントについて把握していなくてはなりません。なぜなら、利用しているクラウドサービスでメンテナンスに関するイベントが予定されていても、通知を見逃してしまうと、思わぬシステム停止につながることもあるためです。

クラウドサービスの導入や運用を検討しているならば、しっかりと運用にかかわるイベントを意識することが重要です。もちろん、ある程度の融通は効かせられますが、自社で運用するシステムほどの自由度はありません。賃貸のマンションやアパートに入居する際に家主の出す条件に従うことが求められるように、プロバイダー側の意向に沿うことがサービスを利用する際には求められるのです。今回はAWSを例に、イベントの詳細や求められる対応について解説します。

AWSでは、提供しているさまざまなサービスにおいて、機能強化や脆弱性への対応などを目的に、メンテナンスやアップデートなどのイベントを実施しています。イベントによっては、サービスの提供を維持しながら実施されることもあります。しかしながら、中にはシステムの再起動、インスタンスの再起動、さらにはサービス停止を余儀なくされるケースもあります。これらの事象はシステムの運用に大きな影響を与えるため、しっかりとした対応が必要です。そこで重要になってくるのが「メンテナンスウィンドウ」です。メンテナンスウィンドウとは、システムやサービスの変更や更新、ソフトウェアアップデートを行うために予約された時間帯のことです。

メンテナンスウィンドウ（時間帯）はユーザー側で任意に設定でき、アクションを定期的に実行するようなスケジューリングも可能です。また無期限に実行するか、特定の期間の後に停止するようなスケジューリングを設定することもできます。Windows PCのセキュリティアップデートや、OSのバージョンアップをイメージすれば分かりやすいのではないでしょうか。脆弱性への対応や、システムの機能強化により快適かつ安全にクラウドサービスを使い続けるためにも、メンテナンスウィンドウへの対応は絶対に避けては通れない道なのです。

なかでも、AWS本体やデータベースである「Amazon RDS（Amazon Relational Database Service）」、複数のデータベースをまとめた「DBクラスター」、仮想サーバーの「Amazon Elastic Compute Cloud（EC2）」などを利用する際は、メンテナンスウィンドウについてよりしっかりと理解する必要があります。データベース・ファイルを管理する一連のメモリー構造であるDBインスタンスを作成する際は、ユーザー側がメンテナンスウィンドウの曜日を指定しなければ、AWS側がランダムで曜日を選択して30分が割り当てられるようになっています。なお、東京リージョンのAmazon RDSの場合、日本時間の22時~6時の間のランダムで選択された曜日に30分が割り当てられています。

メンテナンスの実施によって、データベースへ接続できなくなるような事態を招いては、業務に支障をきたすことになりかねません。このような事態にならないように、事前にイベント情報を収集し、メンテナンスウィンドウを見据えて事前準備を進めておく必要があります。

イベントはメールでの通知に加え、サービス管理ツールである「AWSマネジメントコンソール」や、アカウントに関連するイベントや通知を提供するサービスである「Personal Health Dashboard」でも確認することができます。また、「AWS Health API」の利用により、APIを経由してHealth情報にアクセスすることで、イベント情報を取得することもできます。これらのイベント情報は、日々の業務の中で定期的に取得することが重要です。そこで得た情報は、運用にかかわるメーリングリストや「Microsoft Teams」などで通知するといいのではないでしょうか。

イベント情報を押さえた後のステップとしては、はじめに業務に影響を与えない深夜帯や週末の時間帯を選んだスケジュール設定を行う必要があります。続いて、事前にシステム管理者やユーザーへ通知を行い、万一のトラブルに備えたデータのバックアップといったリカバリープランを用意することも欠かせません。その際にはバックアップウィンドウ、いわゆるデータをバックアップする際に業務やシステムを停止できる時間帯を理解しておくことが重要です。さらに、メンテナンス作業が影響を与えるリソースやサービスについても確認し、影響を最小限に抑えるための対策を講じることも重要です。

ちなみに、AWSのリソースやオンプレミスサーバーを管理するためのツールである「AWS Systems Manager」のメンテナンスウィンドウ機能を活用により、OSなどへのパッチ適用、ソフトウェア更新、ドライバー更新などのスケジューリングもできます。加えて、AWS Lambdaを利用することで、特定の時間帯にアカウント内のリソースグループといった複数のターゲットに対するタスクの自動化、リソースの一括管理も可能です。

AWSが提供する仮想サーバーであるAmazon Elastic Compute Cloud（以下、EC2）には、メンテナンスが2種類あります。1つめのインスタンスの再起動は、ゲストOS上または「EC2 Management Console」での再起動だけで完了できます。しかしながら、もう1つのシステムの再起動では、少々事情が異なってきます。

システムの再起動では、インスタンスを実行している物理サーバー自体が再起動されます。そのため、メンテナンスの前に実際に稼働しているインスタンスを停止させる必要があります。なぜなら、インスタンスが一時的にオフラインになるシステムのメンテナンス中には、データベースへの接続ができないなどの不具合が生じるためです。この場合、いったんインスタンスを停止させておいて、メンテナンス終了後にスタートさせるのがセオリーです。さらに、システムの再起動に伴ってパブリックIPが変更されるので、Elastic IP（EC2インスタンスにアタッチするための静的なIPアドレス）についても検討しなければなりません。

通常、再起動は自動でスケジュールが設定されますが、事前にユーザー側で時間を指定することもできます。この再起動の影響を最小化するには、EC2のインスタンスに対するイベントの定期的な確認や、再起動のイベント発生する際にメンテナンス時間を設定した上で、事前に再起動するといった対処が必要になります。

Amazon RDSにおいても、EC2と同様、定期的なメンテナンスが実行されています。そのため、Amazon RDSのヘルプページには、「一部のメンテナンス項目に関しては、DBインスタンスを短時間オフラインにする必要がある」旨明記されています。つまりEC2同様、アプリケーションやサーバーからデータベースへ接続できなくなる事態を招く可能性があるのです。ちなみにAmazon RDSのメンテナンスには4つのステータスがあります。まず、「必須」はユーザーによる延期ができません。「利用可能」では、メンテナンスを実行できるものの自動的に実行されません。「次のウィンドウ」は次回のメンテナンスウィンドウ中に適用されます。そして「進行中」は、メンテナンスアクションが適用中であることを示すステータスです。

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

AWSでは、EC2やAmazon RDSのメンテナンスウィンドウに加えて、各サービスにおいて多種多様なイベントが発生します。そのため、各イベントの種類に対する対応方法を決めておくこと、そのような運用設計が重要になってきます。その場のなりゆきで対応するという事態は、極力避けるべきです。

サービスやインスタンスの数が膨大になるようならば、すべてのイベントに対して適切に対処することは困難かもしれません。相応の知見と稼働が求められるため、専門の人員やチームを社内に編成することが求められます。

そのような対応が困難ならば、ICTのプロフェッショナルに運用をアウトソースする選択肢を検討すべきかもしれません。たとえばドコモビジネスは、複雑化するICTオペレーションに対して、瞬発力に優れたICTへの変革を支援するトータルマネージドサービス「X Managed®」を提供しています。そのX Managed®のオプションサービスの1つとして、「AWS導入支援・運用サービス」を用意しています。AWS認定プロバイダーとして培ってきた経験やスキルを生かし、導入前のコンサルティングから、設計や構築、さらにライセンス提供や運用保守、維持管理、各種お問い合わせを受け付けるヘルプデスクまで、ワンストップでお届けしています。

ドコモビジネスでは、プロジェクトマネジメントが思うように機能していないなどの理由から、AWSの導入に想定以上の時間がかかる、せっかくAWSを導入したものの思わぬトラブルが多発している、AWSの豊富な拡張メニューが宝の持ち腐れになっているといったお悩みをまとめて解決します。

以下に主な提供メニューを紹介します。

• AWS導入コンサルティング
  ユーザーの用途に応じたAWSの構成に関する設計を行い、導入コストを試算します。
• AWS設計
  上記の設計を基盤に、ユーザーの運用しやすさも踏まえて、ユーザーのアカウント作成から、利用するサービス設定といった初期の構築を実施します。
• AWS構築
  お客さまのご要望に沿って、AWS上に最適なシステムを構築します。
• AWS課金代行・サポートサービス
  お客さまのAWSアカウントの発行や管理、支払いなどの代行を行います。加えてAWS基盤の故障および技術仕様に関するお問い合わせなどについてもサポートします。

• AWS監視
  運用状況を監視し、インシデント発生の際には速やかに報告します。
• ハイブリッド環境の一元運用
  AWSだけでなく、プライベートクラウドやオンプレミスなどの異なった環境を組み合わせたハイブリッドな環境に対しても、一元的な監視・運用サービスを提供します。
• AWSエンドユーザー サービスデスク
  サービスデスクの提供や、故障発生時の切り分けから復旧作業などを行います。それにより、ユーザーの運用負荷を軽減し、高い可用性の実現を図ります。

ドコモビジネスでは、2019年よりAWSが主催するAWS パートナーネットワークに参加し、AWSを活用した多様なソリューションを展開しています。AWSサービス認定、AWS認定資格にもとづく技術や、豊富な導入実績で培った知見、ノウハウ、1社ごとに技術担当者をアサインするといった強みを生かし、AWS環境の運用を一元的に対応できる体制を整備しています。今回紹介したメンテナンスウィンドウの適切な対応を含め、AWSの本格的な活用を視野に入れるのであれば、こうしたドコモビジネスの各サービスの利用を検討してみてはいかがでしょうか。