オンプレミスからAWSクラウドへ移行するまでのシミュレートは前回まででほぼひと通り完了した。最終回となる今回は、移行後のフェーズ、すなわちクラウドの運用フェーズにおける検討事項、とくに『障害対策で留意すべきポイント』を挙げておきたい。どんなシステムもそうだが、AWSクラウドはある意味、運用に入ってからが本当の勝負どころでもある。本連載でクラウドならではの運用ポイントを理解/把握し、読者の皆様がオンプレミスでは得られなかったメリットを存分に体感するきっかけになれば幸いである。
対象はリージョン単位の障害のみ – AWSのSLAとその例外
AWSでは以下の6つの主要サービスにおいて、サービスごとにサービスレベル合意（
SLA：Service Level Agreement）を定義している。
- Amazon EC2
- Amazon EBS
- Amazon RDS
- Amazon S3
- Amazon Cloud Front
- Amazon Route53
SLAで定義されているのは、サービスコミットの目標値と、AWSがそれを万が一守れなかった場合のサービスクレジット（返金）の割合だ。例えばEC2では、月間使用時間割合が99.0%以上99.95%未満であれば10%のサービスクレジット、99.0%未満の場合は30%と定義されている。1カ月＝30日で換算すると、1カ月で約21分以上サービスを使えなかった場合は月額利用料金の10%が、約7時間20分以上停止した場合は30%が返金されることになる。
ただしSLAには例外事由、すなわちサービスコミットメントが適用されないケースについても同時に定められている。以下、EC2の例外事由をそのまま引用する。
（i）AWS契約第6.1項に定めるサービス停止の結果である場合
（ii）不可抗力、Amazon EC2またはAmazon EBSの責任分界点の範囲外のインターネットアクセスまたは関連する問題を含む、アマゾンの合理的な支配の及ばない要因により生じたものである場合
（iii）回復ボリュームを認識することを怠った場合を含む、サービス利用者または第三者の作為もしくは不作為の結果である場合
（iv）サービス利用者の機器、ソフトウェアもしくはその他の技術、および/または第三者の機器、ソフトウェアもしくはその他の技術（アマゾンの直接支配の範囲にある第三者の機器を除く）により生じたものである場合
（v）地域（Region）使用不能に帰因するものでない、個別のインスタンスまたはボリュームの障害の結果生じたものである場合
（vi）AWS契約に従って規定されるメンテナンスの結果生じたものである場合
（vii）AWS契約に従ってAmazon EC2またはAmazon EBSを利用するサービス利用者の権利をアマゾンが停止もしくは終了させた結果である場合
ざっくり言うと「AWSに直接起因する、リージョン単位の障害」以外は返金対象とならないことになる。もちろん東京リージョンが丸一日落ちた（サービスを停止する）となればさすがに返金対象になるが、たとえば（v）にあるように、インスタンスやアベイラビリティゾーン（AZ）の障害が一部に留まる場合は使用不能時間に含まれない（例外事由に該当する）。AWS以外の回線事業者などが起こした障害、ユーザがAWSとは別に用意したハードウェア/ソフトウェアに起因する障害に関しても同様であり、返金の対象とはならない。
また、AWSに起因する障害であっても自動的に返金されるわけではないことに注意が必要だ。サービス停止がAWSに起因する場合、ユーザはその証拠をエラーログとして提出しなくてはならない。したがってAWSクラウドの運用にあたっては「障害がどういう事由に起因するのか」をつねに把握/監視できるモニタリング環境を用意すること、さらには、高いSLAが必要なシステムの構築時は、AZをまたいだ冗長構成を取ることが必須となる。これを実現するには、AWSが提供するクラウドモニタリングサービス「AWS CloudWatch」を利用したり、オープンソースのZabbixなどを使って監視システムを構築する方法がある。クラウドインテグレーションを得意とするパートナー企業であれば、独自の監視サービスを提供している場合もあるだろう。いずれにせよ、AWSクラウドを運用していく際、インスタンスの監視は、ユーザー側の必要な運用管理項目となる。
ハードウェアは故障するもの – 障害を”折り込み済み”にする理由
こうしてみるとAWSのSLAは、既存のデータセンター事業者やホスティング事業者などと比較して厳しく見えるかもしれない。SLAが定義されているサービスが6つだけというのも「少なすぎる」と感じる人もいるだろう。だが、ここであらためて覚えておいてほしいのは、AWSクラウドにおけるSLAの”A”はユーザとAWSの間で結ばれるAgreement（合意）であるという点だ。決してAWSがユーザに対して行うAssurance（保証）ではない。
前回でも言及したが、AWSクラウドは、基本的に「サーバーなどのハードウェアはいつか必ず壊れる」ことを前提にアーキテクチャが設計されている。インスタンスやアベイラビリティゾーン、データセンターに至っても同様だ。そういうものだと認識した上で、ユーザ側にも冗長構成や死活監視を求めているのである。これはオンプレミスしか運用したことがないインフラ担当者にはなかなか受け入れがたい概念かもしれない。
もちろんAWSも障害が起きないための最大限の努力を続けている。だが、AWSのビジネス規模や膨大なITリソースを考えれば、世界中の全リージョンが24時間365日に渡って1分1秒たりとも障害がおきることがないとするほうが非現実的であろう。「サーバーは故障するもの、クラウドも障害がおきるもの」であり、だからこそ前回も触れたとおり「障害がおきてもすぐに復旧できる」レジリエンスこそがAWSをAWSたらしめているのである。障害が発生したとしても、AWSだけでなくユーザ側も可用性を高めるための努力を継続していれば復旧までの時間を限りなく短縮できる。高いサービスレベルをAWSに求めるなら、ユーザ側もまた、それに見合った運用体制、つまり障害が発生することを折り込んだ運用体制を取ることを課せられていると考えるべきである。
cloudpackでは、マネージドサービスにおけるSLAとサービスレベル目標（SL0：Service Level Objective）を明確化した『cloudpackサポートデスクホワイトペーパー』を公開し、運用体制の全体像とプロセスを開示している。
cloudpackサポートデスクのご利用方法：障害発生時
お客様のシステムで障害が発生した際のフローを公開し、スムーズな復旧作業を行うことのできる体制を整えている。
冗長化をAZだけでなくリージョンをまたいで展開すれば、可用性はさらに高まり、サービスが利用できない時間をゼロに近づけることはできるが、オンプレミスで構築するほど高額ではないが、当然追加のコストがかかる。それよりも要件ごとにどこまでの可用性を担保すべきかを定め、あとは運用でカバーすることに徹したほうがクラウドらしいアプローチだといえる。オンプレミスを含め、100%ダウンしないITインフラなどはこの世に存在しない。だがAWSクラウドが登場するまで、それをはっきりと謳ったデータセンター事業者は存在しなかった。この割り切った思想を理解することが、AWSクラウドの運用において非常に重要であることを覚えておこう。
クラウド時代の”運用”のあり方
最後にAWSクラウドの障害対策で覚えておきたいもうひとつのポイントを紹介しておく。クラウドの運用に慣れてくると、障害が起こる”前兆”を感じ取ることができるようになる。運用しているインフラにひもづく、固有の”ブレ”があらわれてくるのだ。それはレイテンシーにあらわれたり、リソースの状況にあらわれたりする。この予兆を捉えたら、まずは本番環境から当該インスタンスを切り離し、原因を探るフェーズに入ることを推奨する。クラウドのメリットのひとつはリソースの切り離しが非常に容易に可能なことである。本番環境を止めることなく、障害のチェックが可能な点は大いに利用したい。こうした予兆を捉える経験を重ねることで、障害発生率そのものを低く抑えることが可能になる。
また、一見、関係ないようだがビジネス部門とIT部門が密に連携する体制を取ることも重要な障害対策のひとつである。連載の初回で触れたが、なぜクラウドを導入するのか、その原点をあらためて振り返ってみてほしい。「ビジネスに資するITインフラ」の構築こそがクラウド導入の最大の理由であり、そのためのITリソースを効率よく提供することがIT部門の仕事であり、落ちないインフラを構築することではない。ビジネス部門との連携をはからなければ、障害時の復旧対策や計画停止などもスムーズにはいかないのだ。AWSクラウドの運用方針は、ビジネス部門の意見も必ず取り入れるべきである。
AWSクラウドが世に出て10年以上が過ぎた。クラウドの普及はITの世界を変え、ビジネスの世界を変え、数多くのイノベーションを生み出した。それに伴い、運用の世界にもアジャイルやDevOps、自動化、責任共有モデルといった新たなトレンドが生まれ、オンプレミス時代のアプローチとは大きく異なりはじめている。運用担当者が人力でハードウェア/ソフトウェアを管理するあり方から、別の場所にあるリソースを付かず離れず見守っていくスタイルへ – クラウド時代の運用の軸足はそうした方向にシフトしていると言えるだろう。
AWS導入におけるあなたの不安や悩みを
cloudpackの「AWS導入相談会」で解決しませんか？
『AWS導入相談会』では、主にAWS導入の基礎知識を必要とする方々を対象に、AWS利用の疑問や不安を解消しながら、クラウド活用のメリットが得られるようなAWS導入およびオンプレミスからのスムーズなAWSへの移行を実現する情報を相談会形式で提供しています。
AWS活用の検討状況に応じて、これまでのcloudpackが手がけてきた導入事例や、大量に蓄積されたノウハウを踏まえた、適切なAWS導入フローなどをヒアリングすることができます。
各回1社限定なので気兼ねなく相談ができるとして、大変ご好評をいただいています。興味のある方は、ぜひご参加ください。
本記事は、『IT Leaders』に寄稿した原稿を一部編集して再掲したものです。
