大規模障害に備えるパブリッククラウド上でのシステム運用

この記事は

NTTドコモテクニカルジャーナルVol.29No.1大規模障害に備えるパブリッククラウド上でのシステム運用の筆者による解説記事です。

概要

パブリッククラウドが普及し、多くの組織や団体でパブリッククラウドが利用されています。社会インフラとなりつつあるパブリッククラウドは、ひとたび停止すると社会全体に大きな影響を与えかねず、クラウドを利用したシステム運用の重要性は増してきています。ドコモでは長年大規模にパブリッククラウドを利用してきた経験から、大規模障害を想定したシステムの設計や運用ノウハウを蓄積してきました。また大規模障害発生時に会社内の情報連携をスムーズに行えるツールも開発し運用してきました。

システム障害に対する考え方

可用性の高いシステム構成

システムには障害がつきものです。全く壊れない完璧なシステムは存在しません。そのため、システムを構築する場合は、それらを構成する各要素で障害が発生した場合でもシステム全体としての可用性を維持するようなシステム構成をとることが重要になってきます。
これには単純なサーバーやネットワーク機器の冗長化に加え、アプリケーション領域でも非同期処理を採用してシステムの疎結合化を図ることで障害影響範囲を限定する実装や、リトライ処理の実装なども挙げられます。近年注目されているマイクロサービスも、サービス単位でシステムが独立しており疎結合化が図られているため、結果として障害範囲を限定した可用性の高いシステムを構成することもできると考えられます。

パブリッククラウドにおける責任共有モデル

パブリッククラウドを利用する場合、利用者と事業者の間で責任範囲を明確にし、双方でシステム全体の可用性を担保していく「責任共有モデル」が採用されることが多くなっています。
近年ではパブリッククラウドのIaaSのみを利用してシステムを構成することは少なくなってきており、各社が提供するPaaSやSaaSの機能を活用してシステムを構成することが多くなってきています。PaaSやSaaSは責任共有モデルにおいて事業者側の責任範囲において、あらかじめ高可用性を実現するような構成がとられていることが多いため、利用者側は積極的にそれらの機能を活用してシステム構築を行うようになってきています。

利用者が考慮しておくべきこと

障害発生を前提とする

パブリッククラウド自体もシステムである以上、障害発生をゼロにすることはできません。利用者がこの事実を十分に把握しておくことは非常に重要です。仮にこの事実を把握せずにパブリッククラウドを利用してしまうと、十分なシステム設計と運用設計ができていないことが要因で大きな損失を出してしまうことも考えられます。開発者や運用者だけでなく、ビジネスオーナーや経営層含めてこの事実を理解しておくことが重要になります。

ベストプラクティスを活用する

多くのパブリッククラウド事業者は可用性や信頼性を維持するためのシステム設計を利用者に推奨すると同時に、それらを利用者がより実現しやすいようにさまざまな機能やオプションを提供している。また幸いにもパブリッククラウドは世界中にすでに多くの利用者が存在しており、あらゆるユースケースで採用されてきた設計パターンがベストプラクティスとして公開されています。そのため、それらのベストプラクティスを採用して設計や運用を行なっていくことで、リスクの低減を図ることが可能です。

障害に備える運用設計をする

対策を実施しても障害をゼロにすることは難しいため、実際に障害が発生した際に迅速に原因を特定し、リカバリできるように運用を設計しておくことも重要です。

システムの可観測性をあげる

監視は安定的なシステム運用において重要です。さらに近年ではシステムの構成がIaaS/PaaS/SaaSなどにまたがることも多く、さらにコンテナやマイクロサービスの採用が一般化してきているため、これまで以上にシステムの可観測性を高めていくことが重要です。単なる死活監視だけでなく、分散トレーシングといった手法でシステムの挙動をより詳細に把握することが注目を浴びているのはこのような背景があります。

想定外の障害リスクを下げる

発生する障害が全て想定内のものであれば、あらかじめ十分な備えをすることで障害リスクを最小化することは可能です。時間やコストが許す限り、あらゆるケースを想定して普段からサービス停止時のリカバリ試験やシミュレーションをしておくことは重要です。Chaos Engineeringはパブリッククラウドならではのユニークな障害リスク低減手法です。
Chaos Engineeringは、システムの本番環境で意図的に障害を発生させ、システム全体への影響を観測するという手法です。これにより、システムの耐障害性を確認するとともに想定外のシステム影響があった場合には、それに対する対策を実施することで耐障害性の向上を図るという手法です。本手法は本番環境で行われるため、十分な耐障害性をもったシステムに対して実施しなければ、意図せぬ顧客影響を発生させる可能性もあり、実施にはハードルが高そうな印象もあります。一方で2021年にAWSはChaos Engineeringを実施するマネージドサービスとしてAWS Fault Injection Simulatorの一般提供を開始しています。これにより、クラウド利用者はより簡単にChaos Engineeringを実践できるようになることが考えられます。

Support Visualizerの開発と提供

ドコモでも多くのプロジェクトで利用しているAWSにおいて、実際に実践しているパブリッククラウドの障害発生時に社内の情報収集を円滑化する取り組みについて紹介します。

AWS大規模障害で判明した課題

ドコモではさまざまなワークロードでAWSを活用しています。ワークロードによりシステム要件やアプリ利用者数、データ量が異なるのでシステム設計や運用はシステム単体で独立していることが多く、利用するサービスもプロジェクトにより異なっています。そのため、AWSで障害が発生した場合の影響範囲はシステムによって異なります。実際にこれまでAWSで大規模な障害が発生した際に、全く影響がなかったシステムもあれば、大きな影響があったシステムもあります。
これらの障害発生時に、次のような課題が判明しました。

会社全体での情報収集

障害影響は個別のシステムにより異なるため、会社としてはいち早く各システムへの影響を把握し、社内外へ適切にアナウンスを行う必要があります。一方で各システムは前述のように独立して運用しており、障害発生時は現場も復旧対応に追われていることから、迅速に情報を集約することが難しいという課題がありました。

影響範囲の特定と対処

個別のシステムの運用担当者は、障害発生時に迅速に障害原因を特定して復旧対処を行う必要があります。障害原因にはさまざまなものがあり、基盤となるパブリッククラウドの障害発生時には、障害原因がパブリッククラウドの障害に起因するものなのか、もしくは個別のシステムで固有に発生しているものなのかの切り分けが難しく、原因特定と対処に時間がかかってしまうといった課題が発生しました。
通常パブリッククラウド事業者は提供するサービスに障害が発生した場合は、サービスステータスを利用者に公開して影響範囲などを利用者に情報発信しています。ただしこれまでの経験上、これらのスタータスが必ずしもリアルタイムに発生している障害を全て示しているわけではなく、利用者は事業者から提供されるこれらの情報をもとにあらゆる可能性を検討したながら復旧対応をしていく必要があります。

Support Visualizer

前述したような課題に対処するために、ドコモ社内ではSupport Visualizerというツールを開発して運用を行なっています。これはドコモ内で利用されているAWSアカウントのサポートケースの情報を集約するツールです。
障害発生時は個別のAWSアカウントで復旧対応をしていますが、AWS自体の障害の場合は各アカウントからサポートケースが起票されて、AWSのサポートチームとのやりとりがされます。これらのやりとりの情報を集約することで、会社全体での障害影響情報の迅速な集約が可能となり、かつ個別のシステム担当者もその他のプロジェクトの影響範囲を確認することができ、自身のプロジェクトで発生している問題が他のプロジェクトでも発生しているのか、その場合にすでにやりとりされた既知の対処方法がないか等を確認することができるようになります。

Support Visualizerのアーキテクチャ概要は下記の通りです。各AWSアカウントのサポートケース情報はAPIを通じて取得され、Amazon Elasticsearch Serviceに集約されています。

集約されたサポートケース情報はCloud Center of Excellence（CCOE）チームによって監視されており、緊急度の高いサポートケースなどが起票された場合はアラート通知されるようになっています。
また社内の各AWSアカウント管理者や運用担当者には集約したサポートケース情報が検索・閲覧できるように下図のようなダッシュボードを提供しています。
これにより、AWSの障害が発生した場合にサポートケースのやりとりから類似の障害影響の確認等を行い、迅速な原因特定と復旧対応につなげることが可能になります。

またSupport Visualizerにより、普段から社内の技術的な問い合わせなどが集約されるようになるため、結果として社内のクラウド利用時の技術ノウハウが集約できるになったという副次効果もありました。

さいごに

本記事では、システムを運用する上で避けて通れない障害発生時の対応について、特にパブリッククラウドの大規模障害発生時に着目して、ドコモでの取り組みなどを紹介しました。