開閉ボタン
ユーザーメニュー
ユーザーメニューコンテンツ
ログイン

  • 会員限定
  • 2016/12/15

AWS運用設計フェーズの基本を解説、システムを「安定稼働」させる4つのポイント

CIOのためのAWS解説(3)

これまでの連載では、AWSの基本からサーバーレス・アーキテクチャの考え方、オンプレミスからAWSへの移行のポイントについて解説してきました。第3回目の連載で取り上げるのは「AWSの運用設計」です。AWSではシステムの構築もさることながら、その運用も重要です。今回はAWSを継続的に安定稼働させるための4つのポイントとして(1)障害が発生した場合を想定し、影響を最小限にとどめるための運用設計(2)障害が発生した場合の問題の切り分け(3)障害から復旧させる方法(4)障害を未然に防ぐためのモニタリングについて解説します。

アイレット(cloudpack)ディビジョンリーダー
ソリューションアーキテクト 石田知也

アイレット(cloudpack)ディビジョンリーダー
ソリューションアーキテクト 石田知也

前職では大手製造業をターゲットとするコンサルティング・ファーム系SIerにて、グローバル向けの大規模Web、メール、モバイル、セキュリティ分野の戦略立案などに従事。2014年よりcloudpackに参画し、AWSの導入および運用に関するコンサルティング・インテグレーションを担当。AWSの特性を活かした大規模配信案件のインテグレーション・運用を得意としており、「徹底的な自動化と人による運用」がモットー。

photo
知っておきたいAWS「運用設計」のポイント
(© apinan – Fotolia)



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

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

画像
これだけは押さえておきたい、システムを継続的に安定稼働させる4つの勘所

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

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

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

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

画像
AWSのベストプラクティスの一例。EBSとインスタンス・ストア・ストレージの相違点や使い分けを理解する


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

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

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

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

画像
AWSの標準モニタリングサービス「CloudWatch」でシステムの挙動をモニタリング。その際に各メトリクスの意味を理解し、必要な監視対象に設定しておく

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

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

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

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

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

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

画像
障害を速やかに解消させる復旧方法

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

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

データセンター・ホスティングサービス... ジャンルのセミナー

データセンター・ホスティングサービス... ジャンルのトピックス

データセンター・ホスティングサービス... ジャンルのIT導入支援情報

PR

ビジネス+IT 会員登録で、会員限定コンテンツやメルマガを購読可能、スペシャルセミナーにもご招待!