システムを継続的に安定稼働させる「4つのポイント」

　システムをAWSで新たに構築したり、オンプレミスから移行したりした後に検討すべき事項は、いかにしてシステムを継続的かつ安定的に稼働させるかという「運用設計」です。この課題は、システムを運用する組織にいる方であれば、誰もが常に気に留めている点でしょう。今回は、次の4つの観点からAWS運用設計のポイントを解説します。

（1）障害が発生した場合を想定し、影響を最小限にとどめるための設計

　オンプレミスでのシステム構築が当たり前だった時代の運用設計は「システムに障害を起こさせないためにどうするか？」という点を考慮することに重きが置かれてきました。一方、AWSの運用設計では「障害は必ず起きるもの」という前提に立ちながら、いかにビジネスへの影響を減らすかという視点で運用設計することが重要になってきます。

　また、AWSの運用設計をする前に「オンプレミスのシステムをAWSに置き換えたとき、両者の技術にはどのような違いがあり、どのような仕組みになっているのか」という点をしっかり把握しておくことが重要です。AWSでは、例えばデータべースやストレージをひとつ取っても、ボタン1つで生成できてしまいます。システム構築や移行が容易になった一方で、その背後にある技術や仕組みが見えづらくなるため、障害が発生したときに、理解できていない箇所で発生した障害に対応しきれない可能性があります。

　そこで運用設計時におすすめしたいのが、AWSのベストプラクティスを活用することです。ベストプラクティスとは、端的にいえば「標準サービスを正しく使うためのルールブック」のようなものですので、サービスを正しく使うルールを理解する助けになるでしょう。

（2）障害が発生した場合、速やかに発生箇所を切り分ける監視

　2つ目のポイントは、実際にAWSに障害が発生した際に「一体何を確認すれば、発生箇所を切り分けられるのか？」という点を把握しておくことです。

　ここで重要になるのが、AWSのリソースとAWS上で実行されているアプリケーションをモニタリングする「Amazon CloudWatch（以下、CloudWatch）」に代表される、モニタリングサービスを活用することです。

　CloudWatchを十分に活用するためには、メトリクス（監視項目に対するエラーの回数）の意味を理解し、問題発生時にどの部分が経験値として影響を受けるのかという点を事前に知っておくとよいでしょう。メトリクスを監視対象としてモニタリングしておくことで、「ネットワークに関する障害なら、この部分を見る」、あるいは「サーバーに関する障害なら、この部分を見る」というように、当たりをつけて原因を特定できるようになります。


　ここで意識すべきは、マクロ的な視点で「サービスやシステムの変化点に注意を払うこと」です。もっといえば、単にAWSを運用設計するインフラエンジニアの視点だけでなく、普段からビジネス視点に立つということです。

　新規開発したアプリケーションをデプロイしたり、マーケティングが新しいキャンぺーンを打ったりしたときなどには、システムに一時的なアクセス増加が発生します。こうしたビジネス上のイベントは、AWS運用の観点でいえば障害発生のトリガーにもなりかねません。情シス部門がビジネス部門の間で綿密にコミュニケーションを取り、これらの変化点に注意を払うことは、障害発生の原因を特定しやすくなるだけでなく、最終的にはビジネス部門を巻き込むことにつながり、社内からの信頼を勝ち取ることにもつながるはずです。

（3）障害を速やかに解消させる復旧手法

　3つ目のポイントは、障害発生後にサービスを速やかに復旧できるようにすることです。

　オンプレミスのシステムに障害が発生したときには、場合によってはサーバーやストレージ、ネットワークスイッチなどの物理的な障害からの復旧を考えなければなりませんでした。一方で、AWSの場合、物理的な障害への対応をせずに、迅速にサービス復旧・再開ができたりします。

　障害が起こった際には、仮想サーバーのイメージコピーから新しいサーバーを起動し、障害が発生しているサーバーと入れ替えたりすることがあります。このように、暫定策としてサービスの復旧を優先して、恒久策をじっくりと検討するという手法もあるわけです。AWSで運用する際の利点ともいえるでしょう。


　仮に原因をすぐに特定できなくても慌てることはありません。まず、サーバーの台数やスペックを調整して性能を向上し、具体的な効果が見られれば、逆にそこから原因を辿れることもあります。

【次ページ】いかに障害を起きないようにするか？「未然予防」のポイント