CodeZine(コードジン)

特集ページ一覧

Amazon EC2のイベント対応を楽にするためのアイデアと「Design for Failure」の考え方

AWSの深いところ見せちゃいます! by AWSクラウドサポートエンジニア 第5回

  • LINEで送る
  • このエントリーをはてなブックマークに追加

目次

Design for Failureに向けて

 さて、ここまで「どうすればEC2インスタンスのイベント対応を楽にできるか」というテーマで、いくつか運用に組み込めるアイデアをご紹介させていただきました。繰り返しとはなりますが、EC2インスタンスを利用する上でイベントとそれに伴うインスタンス停止というのは避けられないものです。このため、発生した場合にいかに影響を小さくするか、素早く楽に対処するか、ということを運用設計の段階で検討することが重要になります。

 こういった、インスタンス停止を前提としたシステム設計の考え方は「Design for Failure」というクラウド環境でのアーキテクチャ設計思想に則ったものです。Design for Failureは先ほどご紹介したCloud Design Patternの中でも基本原則の一つに掲げられています。

故障のための設計(Design For Failure)

 バグは出さない方がいいし、サーバは故障しない方がいい。しかしあらゆるものは壊れるのだから、壊れたときどうするかという対応品質を高めるのが大事。クラウドを使うと対応品質が上がる。例えば、サーバが落ちたらすぐ別のサーバを起動して対応し、障害復帰できる。

 現実的に、コンポーネントが故障しても稼働し続け、しかもオンラインのまま故障したコンポーネントを交換して稼働状態を維持できるような高信頼性のハードウェアというのは非常に高価です。また、仮に一台の物理ハードウェアが高い耐久性・信頼性を持っていたとしても、地域的な災害など外部的な要因によって利用できなくなってしまう可能性もあります。

 AWSはそうした広域にわたる障害も考慮し、「リージョン」「アベイラビリティゾーン(AZ)」という形でデータセンター群を構成することにより、地域レベルでの冗長化が可能なように設計されています(詳細は本連載第1回の記事を読んでみてください)。

 このような背景もあり、Amazon EC2においても、個々のハードウェアの耐久性に過度にこだわる形ではなく、データセンターや地域レベルで冗長化を行うということが利用する上での前提となっています。

 ただ、AWSのデータセンター群が複数の地域に分布していてもその環境をうまく利用してサービスを冗長構成にできていなければ意味がありません。そして、AZ間での冗長構成を検討する際には、すでにご案内したELBやAMIといったサービスを欠かすことができません。

 ぜひEC2インスタンスを冗長構成にしていくためのツールとして、ELBやAMIの利用を積極的にご検討いただければと思います。

 もう一つ、Design for Failureを実現していく上での重要な視点が障害発生時の自動復旧の実現です。冗長化されたコンポーネントに障害が発生した場合に、これを検知して自動で復旧させることができれば、障害対応はとても楽になるはずです。

 AWSではAuto ScalingやEC2 Auto recoveryといったEC2インスタンスの障害復旧に特化した機能からCloudWatch Eventsのような汎用的なイベントドリブンの処理実行基盤まで、さまざまな形で、AWS基盤上で起きた問題の自動復旧に使える機能が提供されています。これらの機能をシステムに組み込んでいただくことで、障害発生時も自動で復旧して継続的に稼働するしなやかなシステムを実現していくことができます。

Design for Failureの事例:Netflix社

 ここで、Design for Failureを実践している事例として、Netflix社のケースをご紹介したいと思います。

 Netflix社は、世界190カ国でビデオストリーミングサービスを展開している企業です。日本でも2015年9月からサービスが提供されています(個人的にも子供と一緒に映画を見たり、とてもお世話になっているサービスです)。

 同社はオンプレミスからの移行を行うためのクラウド基盤としてAWSを採用し、2009年から2016まで7年をかけてシステム基盤を移行してきました。その経緯はNetflix社のブログで公開されており、日本語翻訳も読むことができます。

 記事の中では、サービスの拡大にあたり拡張性や信頼性の高いインフラ基盤が必要になったことがクラウドへの移行の主な要因であったと述べられています。実際に同社はAWS上でマルチリージョンの冗長構成とコンポーネントの自動復旧機構を実装し、99.99%の高い可用性を実現しているそうです。それだけでなく、実際に本番環境で意図的に障害を起こすソフトウェアを開発し、冗長化や自動復旧が有効に機能しているかを日常的にテストしています。

 そして、こうした障害テストの考え方をChaos Engineeringと呼び、同社が開発したツール群と共に公開をしています。

 同社はこうしたChaos Engineeringの成果として、実際にAWSで発生したEC2のメンテナンスに関する記事も公開しています。

 2014年9月、AWSはXen Security Announcementで公開される予定となっていたセキュリティアップデートの適用のため、EC2インスタンスの少量(10%以下)を対象に再起動を伴うメンテナンスを実施しました。

 Netflix社でも2700台を超える本番環境のCassandraクラスターノードのうち、218台がこのメンテナンスの対象となっていたそうです。

 そして、実際にメンテナンスが行われた週末。対象となっていたノードのうち22台が再起動に失敗したにも関わらず、自動復旧機構によってこれらのノードは代替ノードと入れ替えられました。

 この結果、この記事では人手作業やサービスのダウンタイムが発生することなくこのメンテナンスを乗り切った、と報告されています。このエピソードは、Design for Failureの実践がクラウド上でのサービス高可用性の実現のためいかに重要であるかを示す良い例ではないかと思います。

 AWSを使ったシステム構成を検討していく中で、可用性というのは常に重要な課題として取り上げられる項目ではないかと思います。そんな時にメンテナンス対策という観点から少し視点を広げ、こうしたDesign for Failureの考え方を積極的に取り入れて、サービスに必要な可用性の実現に繋げていただければ幸いです。


  • LINEで送る
  • このエントリーをはてなブックマークに追加

バックナンバー

連載:AWSの深いところ見せちゃいます! by AWSクラウドサポートエンジニア

著者プロフィール

あなたにオススメ

All contents copyright © 2005-2022 Shoeisha Co., Ltd. All rights reserved. ver.1.5