本文へジャンプします。

TOP
クラウド トップ>クラウドナビ>基礎知識>可用性を向上させるクラウドでのデザインパターン

基礎知識

可用性を向上させるクラウドでのデザインパターン

2020年10月22日


可用性を向上させるクラウドでのデザインパターン

可用性」とは、情報セキュリティの3要素の1つで、「システムが動き続けることができる能力」を指す言葉です。当然ですが、可用性は高いに越したことはありません。クラウド事業者では、サーバー・ディスク・ネットワークといったインフラの構成要素を冗長化したり、障害を起こしたサーバーを自動的に切り替える「自動フェイルオーバー(HA機能)」を実装したりなど、可用性を向上させるためのさまざまな対策を行っています。

しかし、エンタープライズの基幹システムのように非常に高い可用性を要求されるシステムも存在します。こうしたシステムでは、自動フェイルオーバー中のわずかな停止時間すらも許容できない場合があります。そのため、クラウド事業者が定義しているSLA以上のレベルが要求されるシステムでは、ユーザー側でさらなる可用性向上対策を実施することが必要になってきます。

本記事では、可用性を向上させるためにユーザー側で行える工夫の1つとして、高可用性クラウドデザインパターンを紹介します。

本記事をご覧いただいた方向けに、おすすめの記事をまとめました。こちらもあわせてご確認ください。

クラウドにおける可用性とは

クラウドサービスでは、クラウド事業者とユーザーの間に「責任分界点」が設定されています。責任分界点とは、ユーザーとクラウド事業者のそれぞれがインフラ基盤のどこからどこまでに対して責任を負うのかを定めた境界です。例えば、IaaSであればサーバーなどのハードウェアやネットワークといったインフラ基盤における責任は、クラウド事業者が負うことになっています。

ユーザーからは見えないため忘れがちですが、クラウドといえどもハードウェアの上で動作しています。ハードウェアは故障する可能性があるため、ハードウェアに起因する障害を完全に回避することは困難です。そのため、クラウド事業者は「ストレージ」を内部的に冗長化したり、ネットワークの経路を冗長化して障害時に切り替えるなど、システムの可用性を向上させるためのさまざまな対策を行っています。インフラ基盤におけるこうした対策は、クラウド事業者の責任範囲となるため、ユーザーが特別に意識する必要はありません。

このような可用性向上の対策が行われていたとしても、サーバーの自動再起動や自動フェイルオーバーなどにより、瞬間的にサービスが停止することが考えられます。一般的にSLAに定められた範囲内の停止時間が許容できるシステムであれば、こうした短時間のシステム停止が問題になることはほとんどないでしょう。しかし、わずかな停止も許容できないシステムやより高い可用性が必要となるサービスなどでは、ユーザー側でさらなる可用性向上対策を行う必要があります。

可用性を向上させるためには

可用性を向上させるためには、単一障害点(Single Point Of Failure、その部分が停止するとシステム全体が停止してしまうようなポイント)を無くす、あるいは少なくするアプローチが基本です。サーバー、ストレージ、ネットワークなど、システムを構成するそれぞれの要素において可用性を向上させるには、ハードウェアを冗長化したり、複数のリージョンやゾーンを利用するといった対策があります。

前述のようにストレージやネットワークなどは、クラウド事業者によって、すでに冗長化が行われているのが一般的です。これによって、SLAに定められた可用性は達成されますが、それ以上に可用性を向上させるには、ユーザー側で単一障害点(SPoF)を作らないようにシステムを設計する必要があります。

例えば、「同一の構成のサーバーを複数起動しておき、仮に1台のサーバーがダウンしてもサービスが停止しないようにする」といった設計が考えられます。この場合も単に複数のサーバーを用意するだけでは不十分で対策したい障害にあわせて、サーバーの配置の仕方までも考慮しなければなりません。

クラウド事業者が管理するハードウェアの故障に対応したいのであれば、複数の仮想サーバーがそれぞれ別のハードウェア上で起動されるように配置する必要があるでしょう(後述のサーバーセパレートパターン)。リージョン全体のネットワーク障害などに備えたいのであれば、サーバーを配置するリージョンを変える必要があります(後述のマルチリージョンパターン)。

ニフクラでの高可用性クラウドデザインパターン

クラウド上にシステムを設計・構築しようとすると、さまざまな「よくある問題」に直面します。こうした問題を解決するために考えられた典型的な設計パターンを「クラウドデザインパターン」と呼びます。これはソフトウェア開発において、典型的な設計に名前をつけてパターン化した「デザインパターン」の考え方をクラウドの設計に応用したものです。

可用性を上げるために単一障害点(SPoF)を無くしたいというのも、クラウド設計における「よくある問題」の1つです。当然、これを解決するためのパターンも用意されています。ニフクラで提供されている機能・サービスを利用すると、以下に挙げるようなクラウドデザインパターンを採用したシステムを組むことができます。

データの損失を防ぐ「ディスク冗長化パターン」

ニフクラでは、ディスクの障害によってデータが消失しないようにサーバーのディスクは内部でRAID6相当の冗長化が行われています。しかし、サーバーからディスクに到達するまでの経路上で物理的な障害が発生すると、ディスクそのものが無事であっても格納されているデータにアクセスできなくなる可能性があります。そこで、ディスクを冗長化する際に複数のディスクを物理的に異なるホストに格納することで、こうした障害を防ぐのが「ディスク冗長化パターン」です。

ニフクラの増設ディスクには、「標準フラッシュドライブ[A/B]」のようなA系統とB系統の2つのディスクを提供しているタイプが存在します。このタイプの増設ディスクでは、A系統とB系統のディスクが物理的に異なるホスト上に作成されることが保証されています。そのため、A系統/B系統の2つのディスクを組み合わせることで、ディスク冗長化パターンを手軽に実現できます。

インフラ基盤にトラブルが発生しても動き続ける「サーバーセパレートパターン」

クラウド事業者は障害を防ぐため、さまざまな対策を行っています。しかし、前述の通りハードウェアの故障による障害を完全に防ぐことはできません。

クラウド上にユーザーが作成した仮想サーバーは、そのリージョン内にあるいずれかの物理ホスト上で起動しますが、複数の仮想サーバーを作成した際にこれらのサーバーが偶然、同一の物理ホストに割り当てられてしまうことがあります。このような場合に物理ホストで障害が発生すると、そのホスト上で動作している複数のサーバーが同時に停止してしまう恐れがあります。つまり、単一障害点(SPoF)を無くすためにサーバーを冗長化したつもりでも、実際はユーザーの目に見えない部分で、物理ホストという新たな単一障害点(SPoF)が生まれてしまっていることがあるのです。

このような場合に有効なのが、「サーバーセパレートパターン」です。このパターンでは、複数の仮想サーバーを明示的に異なる物理ホストに割り当てることで、インフラ基盤側の物理的な障害に影響されないサービスを構築できます。

また、「マルチIPアドレス」の利用も有効です。マルチIPアドレスとは、確保した複数の仮想IPアドレスをニフクラ上のサーバーに対して自由に割り当てられるサービスです。具体的には、あるサーバーがダウンしてしまった際、そのサーバーに割り当てられていた仮想IPアドレスを別のサーバーに付け変えることでサービスの運用を継続できます。マルチIPアドレスとサーバーセパレートパターンとを組み合わせることで、さらに高い可用性が実現できます。

大規模災害でもサービスを止めない「マルチリージョンパターン」

クラウドサービスを実際に動かしているインフラ基盤は、「データセンター」と呼ばれる場所に集約されています。こうしたデータセンターは地理的なエリアごとに「リージョン」という単位に分割して運用されています。

クラウド事業者は、自然災害による影響も考慮してデータセンターを運用していますが、大規模な災害の影響でリージョン全体が機能を停止してしまう可能性は常に存在します。特に日本においては、地震や台風による影響は決して無視できません。そこで、地理的に離れた場所にある複数のリージョンに分散してサーバーを配置することで、特定のリージョンが被災した場合でもサービスの運用を継続できるようにするのが「マルチリージョンパターン」です。

ニフクラでは東日本、西日本、北米にある各リージョンを任意に選択し、自由に組み合わせることができます。

可用性向上のポイントをまとめたeBookを配布中

ニフクラでは、クラウドの可用性をわかりやすくまとめたeBookを無料で提供しています。クラウドでのシステム構築のポイントや可用性を向上させるデザインパターンもさらに詳しく解説していますので、クラウド上で高い可用性を実現する際にはぜひ参考にしてください。

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